Opc сервер своими руками

Группа: Участники форума
Сообщений: 26
Регистрация: 20.8.2010
Пользователь №: 69013

Доброго времени суток!

Меня очень интересует ОРС для LON. Думаю был бы одним из первых покупателей. Хотелось бы узнать удалось ли его написать? Сам я далёк от прикладного программирования но с ОРС серверами работаю плотно. И у меня основной вопрос: удалось ли обойти создание LNS базы или ОРС который вы хотите написать это средство обращения к LNS базе?

Здравствуйте! Собирался полностью бесплатный продукт написать. В связи со сложностью (под свободные компиляторы не компилируются исходники, также есть вопросы по некоторым моментам) решил выкручиваться средствами SCADA.
На данный момент есть получение данных средствами ООП (Visual Basic for Application, например Excel или Word). Но это всё из LNS базы.

Без LNS базы — совсем другой уровень (анализ пакетов, подделка запросов и ответов).

Так как своими силами я не справился (не справляюсь) с OPC — предлагаю однократно вложиться в труд программиста и заиметь бесплатный OPC LON сервер. Если будут энтузиасты помимо меня и которым это надо (я 10 лет на одной и той же СКАДА) — буду рад войти в долю.

Группа: Участники форума
Сообщений: 26
Регистрация: 20.8.2010
Пользователь №: 69013

Итак, сервер написан [огромная благодарность Украине за программистов!] ))
работает так (бета версия):

подключается к БД лонмейкера, читает интерфейсы, проэкты, выбирает тот который нужно и выдаёт в качестве дерева прямо в скаду.

данные выдаёт не текстом, а сразу числами и разбивает по полям.

расчитывалось на скаду которая при сбое сервера самостоятельно перезапускает его, поэтому сервер при ошибках обмена данными выпадает.

Сообщение отредактировал GregorySoft — 11.3.2012, 18:29

Группа: Участники форума
Сообщений: 830
Регистрация: 27.2.2008
Пользователь №: 16012

Группа: Участники форума
Сообщений: 26
Регистрация: 20.8.2010
Пользователь №: 69013

привет всем. свершилось.

Группа: Участники форума
Сообщений: 26
Регистрация: 20.8.2010
Пользователь №: 69013

Уважаемые интеграторы!
От разработчика поступила просьба отписаться тем кто использует или пробовал данный OPC сервер на LON.
Работает или нет, какие сложности, что бы хотелось, возможные ошибки.

Пишите или сюда или по адресам указанным на странице загрузки.

Группа: Участники форума
Сообщений: 830
Регистрация: 27.2.2008
Пользователь №: 16012

Застостопорился на этапе инстталляции. Приложение выдает сообщение.
Запускаю с правами администратора.
Win7, 32bit

Подскажите что необходимо сделать для запуска приложения. Как должна выглядеть удачная установка — это приложение в ПрограмФайлс, это некая утилита что висит в памяти тогда как она называется, или еще как?
ЯМожно ли ее конфигурировать саму по себе или же она видится только из ОРС-клиента (СКАДА)?

Сори,
был невнимателен, ведь сверху ссылка с рекомендациями http://casey.at.ua/index/lon_opc_server/0-19

Группа: Участники форума
Сообщений: 830
Регистрация: 27.2.2008
Пользователь №: 16012

По указанной ссылке выполнил:
п.1 — выполнился ОК
п.2 — распаковал архив в С:\lonopc
п.3 — регистрация сопровождается вышеприведенной ошибкой (см. картинку выше)
пробовал комманды «C:\lonopc\lonopc.exe /r» и «lonopc.exe /r» — завершается ошибкой

Группа: New
Сообщений: 1
Регистрация: 27.7.2012
Пользователь №: 158012

Группа: Участники форума
Сообщений: 35
Регистрация: 19.10.2010
Из: Саратов
Пользователь №: 76954

Источник

Opc сервер для чайников

Опубликована в журнале Automatizace, No. 10/2000

Эта статья посвящена обзору технологии OPC. Она описывает основные понятия данной технологии, причины ее разработки и описывает архитектуру и спецификации ОРС.

1. Что такое OPC?

OPC (OLE for Process Control) – промышленный стандарт, созданный консорциумом всемирно известных производителей оборудования и программного обеспечения при участии Microsoft. Этот стандарт описывает интерфейс обмена данными между устройствами управления технологическими процессами. Главной целью было предоставить разработчикам систем диспетчеризации некоторую независимость от конкретного типа контроллеров. OPC основывается на технологии OLE/COM/DCOM компании Microsoft, Inc.

2. Основные причины создания OPC?

Довольно много программ-клиентов может получать данные из различных источников и делать их доступными для драйверов независимых разработчиков. Но при этом возникают следующие проблемы:

Каждая программа диспетчеризации должна иметь драйвер для конкретного устройства АСУ (Рисунок 1) .
Возникают конфликты между драйверами различных разработчиков, что приводит к тому, что какие-то режимы или параметры работы оборудования не поддерживаются всеми разработчиками ПО.
Модификации оборудования могут привести к потере функциональности драйвера.
Конфликты при обращении к устройству – различные программы диспетчеризации не могут получить доступ к одному устройству одновременно из-за использования различных драйверов.

Рисунок 1a: Пример схемы работы «множества различных драйверов» .

Рисунок 1b: . и решения на базе OPC

Производители оборудования стараются решить эту проблему с помощью разработки дополнительных драйверов. Однако эти попытки встречают сильное сопротивление разработчиков систем диспетчеризации, которые должны, в этом случае, усложнять свои клиентские протоколы.

OPC проводит четкую разграничительную линию между производителями оборудования и разработчиками драйверов. Данная технология предоставляет механизм сбора данных из различных источников и передачу этих данных любой клиентской программе вне зависимости от типа используемого оборудования. Это позволяет разработчикам сосредоточиться на производительности и оптимизации работы серверной части, которая отвечает за сбор данных.

3. Преимущества технологии OPC

OPC был разработан для обеспечения доступа клиентской программы к нижнему уровню технологического процесса в наиболее удобной форме. Широкое распространение технологии OPC в промышленности имеет следующие преимущества:

Независимость в применении систем диспетчеризации от используемого в конкретном проекте оборудования.
Разработчики программного обеспечения не должны постоянно модифицировать свои продукты из-за модификации оборудования или выпуска новых изделий.
Заказчик получает свободу выбора между поставщиками оборудования, а также имеет возможность интегрировать это оборудование в информационную систему предприятия, которая может охватывать всю систему производства, управления и логистики.

4. Стандарты и спецификации OPC, OPC Foundation

Разработку стандартов OPC, их описание, поддержку и пропаганду взяло на себя OPC Foundation, добровольная международная организация, расположенная в Boca Raton, Флорида, США. Сейчас организация насчитывает более 250 членов, в число которых входят компании, занимающие лидирующие позиции в разработке программ для мониторинга, визуализации и диспетчеризации, а также других приложений для управления технологическими процессами, такие как Honeywell, Fisher-Rosemount, Siemens, Wonderware, Intellution и другие. Microsoft, Inc. также является членом OPC Foundation, принимая участие в разработке новых спецификаций. Компания Merz, s.r.o. – единственный представитель Чехии в OPC Foundation.

5. Архитектура OPC

Стандарт обмена данными OPC базируется на распространенной общепринятой схеме Клиент-Сервер. Эта архитектура позволяет подключить множество клиентов к одному серверу. И наоборот, данный стандарт позволяет использования одним клиентом различных ОРС-серверов.

Рисунок 2: Архитектура OPC-клиент/ OPC-сервер в промышленной информационной системе.

5.1. Применение OPC в промышленных информационных системах.

Коммуникационный стандарт OPC позволяет использовать его для обмена данными в индустриальных информационных системах ( Рисунок 2 ). В нижней части рисунка 2 ( Field Management ), показаны три компьютера с установленными OPC-серверами , которые поддерживают различные спецификации OPC (см. далее). Каждый компьютер может иметь OPC-сервера с различными спецификациями. Существуют сервера, которые обмениваются данными с АСУ, построенной на ПЛК ( ПЛК – Программируемые Логические Контроллеры ). Они разработаны на базе коммуникационного протокола (например, AS511, RK512, S-bus, Modbus, DF1 и т.д.), и «распознаются» подключенным оборудованием (например, ПЛК). Доступ к протоколам, хранящимся в базе данных, обеспечивается OPC-серверами, соответствующими спецификациям OPC Historical Data Access.

В центральной части иллюстрации ( Process Management ) показаны еще три компьютера. На этих компьютерах установлен OPC-клиент – программа диспетчеризации – SCADA HMI ( Supervisory Control And Data Acquisition Human Machine Interface ). Соединение с OPC-серверами происходит через локальную сеть (LAN), что расширяет возможности в построении топологии сбора данных при помощи OPC-серверов.

OPC-серверы опираются на коммуникационный протокол представленного оборудования (например, ПЛК). Не смотря на попытки увеличить в коммуникациях долю стандартных протоколов (Profibus, Interbus, CANBus и т.д.), сейчас трудно сказать, на основании чего лучше строить системы обмена данными: на базе специфических протоколов производителей оборудования или более стандартных протоколов полевых шин. По этой причине номенклатура OPC-серверов практически копирует номенклатуру наиболее популярных систем автоматического управления.

В дальнейшем данные могут подыматься выше уровня Process Management для использования в системах управления и планирования производством, например ERP (Enterprise Resource Planning) или MES (Manufacturing Execution Systems) на уровне Business Management . Это позволяет использовать реальные данные всеми подразделениями предприятия, которые в них нуждаются.

5.2. Типы спецификаций OPC

Стандарт OPC был создан на базе спецификаций OPC. В настоящее время получили наибольшее распространение следующие спецификации:

OPC Data Access 1.0 и 2.0 – обеспечивает доступ к данным в режиме «реального времени».
OPC Alarm & Events – обеспечивает OPC-клиента информацией о специальных происшествиях и тревогах.
OPC Historical Data Access – обеспечивает доступ к протоколам и хроникам, хранящимся в базах данных.
OPC Batch – отправляет рецепты дозирования в технологический процесс и отслеживает их выполнение.

Сейчас в разработке находятся еще две специфиации:

Рисунок 2 демонстрирует пример связи OPC-сервера и OPC-клиента при использовании одной OPC спецификации. Однако в спецификации OPC Data Access необходимо следить за использованием версии данной спецификации: сервер OPC Data Access 1.0 может общаться только с клиентом OPC Data Access 1.0 client. Поэтому удобней, если OPC-сервер поддерживает несколько версий OPC-спецификации.

5.3. Написание ОРС-модулей на разных языках программирования

С точки зрения программирования, существует несколько языков программирования для написания клиентской программы: C/C++, Visual Basic, Delphi и т.д.. Чтобы соответствовать современным требованиям к средам разработки, спецификации OPC содержат 2 различных подхода к написанию OPC-клиента. Для внедрения его в программу, написанную на C/C++, используется Custom interface , а для программ на Visual Basic, используйте Automation interface . В основном, OPC-сервера пишутся на C/C++. Для установки надежного соединения между OPC-сервером и OPC-клиентом, написанными на разных языках, используется OPC Automation Wrapper . Он организует взаимосвязь между OPC-сервером, написанным на C/C++ и приложением на Visual Basic.

5.4. OPC и Internet

В настоящее время, OPC Foundation разрабатывает новую спецификацию – OPC XML. Ее цель – разработать гибкий и удобный интерфейс для обмена данными через OPC, используя XML (Extensible Markup Language) в приложениях Internet/Intranet. Функции XML позволяют очень легко записывать любые структуры данных и, в то же время, передавать данные в виде XML-файлов, удобных для пересылки через Internet.

5.5. OPC и управление дозированием

OPC Batch – другая спецификация OPC, которая уже широко применяется в автоматике. Ее используют для посылки пропорций дозирования в технологические процессы и отслеживания выполнения этих пропорций (лабораторные системы, дозаторы, весовые системы и т.п.). Очень важный факт состоит в том, что каждый OPC Batch сервер (клиент) одновременно является OPC Data Access 2.0 сервером (клиентом). Другими словами, OPC Batch сервер (клиент) включает в себя, кроме спецификации OPC Batch, также и спецификацию OPC Data Access 2.0, включая некоторые дополнительные интерфейсы (например, загрузка переменных).

6. Операционные системы

Один из необходимых компонентов для работы OPC-коммуникаций – COM и его сетевая версия DCOM. DCOM – стандартный компонент для операционных систем Windows NT 4.0, Windows 2000 и Windows 98. Для работы в Windows 95 DCOM нужно установить. Все эти операционные системы позволяют передавать данные в рамках одного компьютера или через локальную сеть. В Windows CE сетевые возможности появились в версии 3.0. Сейчас стандарт OPC был разработан и для операционной системы Linux.

7. Связь OPC-сервера с процессом

Первый шаг в конфигурации OPC-клиента – установить на компьютер OPC-сервер (локальный или сетевой). При установлении связи OPC-сервера к OPC-клиенту, технология COM предоставляет механизм сканирования доступных OPC-серверов на указанном компьютере. Это позволяет быстро установить соединение с OPC-сервером. Это сканирование называется OPC server browsing .

Второй шаг – это связать данные из конфигурации OPC-сервера с конфигурацией OPC-клиента. Обеспечивается это с помощью загрузки данных, которая поддерживается и OPC-сервером и OPC-клиентом. После этого необходимо связать данные из OPC-клиента с данными из OPC-сервера по адресному пространству. Если OPC-сервер или OPC-клиент не поддерживают загрузку данных/item browsing , конфигурирование OPC-клиента превращается в довольно длительную работу.

Динамическое добавление данных/Dynamic adding of items предоставляет еще более удобную методику конфигурирования OPC-клиента. С ее помощью можно создавать (или удалять) и сразу же устанавливать связь с новыми источниками данных в OPC-сервере, не останавливая ни сервер, ни клиент. В настоящее время, эта функция реализована всего в нескольких OPC серверах (клиентах), но удобство, которая она предоставляет при конфигурировании OPC-клиента, должно привести к ее широкому распространению.

8. Заключение

Какое же будущее у технологии OPC? OPC-сервера включаются в оборудование все большего числа производителей. В то же время, увеличивается число разработчиков систем диспетчеризации, которые поддерживают сбор данных через OPC-сервер с помощью собственных OPC-клиентов. И если так пойдет и дальше, то технология OPC постепенно станет всемирным стандартом для обмена данными в промышленных информационных системах.

9. Дополнительная информация

[1] Каталог продукции / Спецификации OPC, март 2000. CD-ROM, OPC Foundation
[2] http://www.opcfoundation.org/
[3] http://www.opceurope.org/

Опубликовано в журнале Automatizace, No. 10/2000

Данный топик просвещен проблеме обмена данными в системах промышленной автоматизации му ПЛК и различным программном обеспечении. Прежде чем приступить непосредственному к изложению, хочу сказать, что нахожусь в дурацком положении… Дело в том, что основная часть моих коллег по цеху не являются ИТ-специалистами и работаю в рамках тех инструментальных средств, которые являются стандартом «де-факто» — SCADA пакеты, среды разработки для ПЛК и OPC сервера. Мало кого из них интересует, что находится под «капотом» этих инструментов, хотя большинство проблем, об которые они спотыкаются, кроются именно там и заложены в базовых технологиях. С другой стороны АСУ ТП довольно специфичная область и я не уверен, что программист без опыта работы в данной сфере сможет проникнутся тем, что я попытаюсь донести в этом посте. Вот и получается, что данный топик предназначен для небольшого процента специалистов, которые разбираются в ИТ и АСУ ТП одновременно.

Критика OPC

С развитием АСУ ТП перед производителями ПЛК и программного обеспечения встала проблема взаимодействия му устройствами и ПО работающими по разным протоколам. Решением этой проблемы по инициативе Microsoft стал протокол OPC в основе которого первоначально лежала DCOM технология. Данный протокол на текущий момент используется повсеместно и не смотря на довольно развитую номенклатуру спецификаций, подавляющее большинство реализаций основывается на DCOM технологии, что и стало причиной множества проблем:

Работа в сети. OPC имеет клиент северную архитектуру на базе DCOM технологии компании Microsoft. Поддержка обмена данными по сети в DCOM ограничена и требует дополнительной настройки безопасности узлов. Таким образом внедрение OPC в многоуровневых корпоративных сетях Intranet затруднено, а передача данных через Internet просто невозможна. Данный недостаток критичен при построении систем уровня MES или ERP, что приводит к необходимости внедрения специальных шлюзов, которые транслируют данные между собой в своём формате не ограниченным DCOM и предоставляют данные по OPC.
Привязка к Windows. DCOM технология поддерживает только ОС Windows, что не позволяет разворачивать OPC сервера в контроллерной части и создавать клиентское ПО АСУТП для мобильных устройств (на базе iOS, Android и т. д.). По той же причине нет возможности использовать устойчивые к вирусным атакам системы на базе Unix(Linux) для сбора и хранения данных.
Конфигурация. Основным понятием OPC технологии является тег, чтобы получить данные о каком либо сигнале необходимо «завести» его в конфигурации OPC сервера и в конфигурации каждого клиентского ПО. Таким образом затраты на конфигурацию возрастают пропорционально количеству клиентов и уровней в системе автоматизации. Кроме того, часто эти уровни или клиенты обслуживаются разными организациями, которые просто могут не узнать оперативно о новых данных, что приводит к неактуальности показаний их систем.
Закрытость протокола. Технология OPC позиционируется как «открытая» технология, но это совсем не так. Доступ к спецификации и к инструментам для разработки предоставляется только членам OPC Fundation на платной основе. Такая бизнес модель сплотила между собой крупные компании производители, а все остальные стали потребителями уже готовых продуктов. Даже для тривиальной задачи в области АСУ ТП на базе OPC приходится что-то покупать.

Как видите проблем достаточно много, чтобы начать поиск альтернативы.

REST в промышленной автоматизации

Когда я в качестве хобби занимался разработкой веб приложений на RubyOnRails, я был поражен как просто решаются задачи передачи данных с помощью REST модели! Тогда я задумался о возможности применения такого подхода в АСУ ТП. Как позже оказалась, что данная идея уже сформулирована специалистом из Австралии Томом Тoденхэмом, здесь можно прочитать его труд по этой теме (или мой перевод). Чтобы пробудить интерес к этой идеи, приведу тезисы о ее преимуществах:

Работа в сети. Использование HTTP протокол, как транспорт, позволяет передавать данные через интернет и многоуровневые корпоративные сети. Так же он не требует дополнительной настройки узлов в отличие от OPC технологии.
Независимость от платформы. HTTP поддерживаться всеми операционными системами, что позволяет создавать клиенты под мобильные устройства. К тому же, ввиду простоты HTTP возможно реализовывать REST сервера на уровне контроллеров и снимать с них данные без промежуточных шлюзов.
Конфигурация. Так как основным понятием REST является ресурс, то возможен групповой доступ к данным (подобно доступу к таблице в SQL), таким образом, новые данные в системе могут обрабатываться автоматически без дополнительной конфигурации. Так же стоит отметить, что HTTP позволяет не только получать данные с ресурсов, но и создавать и настраивать их, что позволяет управлять REST сервером со стороны клиентской части с помощью универсальных методов.
Открытость. REST использует открытые стандарты передачи и представления данных (HTTP, HTML, XML, JSON …), которые поддерживаются всеми языками программирования и платформами, что позволяет создавать приложения автоматизации с минимальными вложениями в инструментальные средства.

Как пример простой реализации на Ruby, можете почитать мою статью. Так же есть проект для REST доступа к периферии Arduino — RESTdunio

OPC (аббр. от англ. Open Platform Communications [1] , ранее англ. OLE for Process Control ) — семейство программных технологий, предоставляющих единый интерфейс для управления объектами автоматизации и технологическими процессами. Многие из OPC протоколов базируются на Windows-технологиях: OLE, ActiveX, COM/DCOM. Такие OPC протоколы, как OPC XML DA и OPC UA, являются платформонезависимыми.

Создание и поддержку спецификаций OPC координирует международная некоммерческая организация OPC Foundation, созданная в 1994 году ведущими производителями средств промышленной автоматизации.

Девиз OPC Foundation — «Открытые коммуникации по открытым протоколам».

Содержание

Стандарты [ править | править код ]

OPC — набор спецификаций стандартов. Каждый стандарт описывает набор функций определенного назначения. Текущие стандарты:

OPC DA (Data Access) — основной и наиболее востребованный стандарт. Описывает набор функций обмена данными в реальном времени с ПЛК, РСУ, ЧМИ, ЧПУ и другими устройствами.
OPC AE (Alarms & Events) — предоставляет функции уведомления по требованию о различных событиях: аварийные ситуации, действия оператора, информационные сообщения и другие.
OPC Batch — предоставляет функции шагового и рецептурного управления технологическим процессом (в соответствии с стандартом S88.01)
OPC DX (Data eXchange) — предоставляет функции организации обмена данными между OPC-серверами через сеть Ethernet. Основное назначение — создание шлюзов для обмена данными между устройствами и программами разных производителей.
OPC HDA (Historical Data Access) — в то время как OPC Data Access предоставляет доступ к данным изменяющимся в реальном времени, OPC Historical Data Access предоставляет доступ к уже сохраненным данным.
OPC Security — определяет функции организации прав доступа клиентов к данным системы управления через OPC-сервер.
OPC XML-DA (XML-Data Access) — предоставляет гибкий, управляемый правилами формат обмена данными через SOAP и HTTP.
OPC UA (Unified Architecture) — последняя по времени выпуска спецификация, которая основана не на технологии Microsoft COM, что предоставляет кросс-платформенную совместимость.

Назначение [ править | править код ]

Стандарт OPC разрабатывался с целью сократить затраты на создание и сопровождение приложений промышленной автоматизации. В начале 1990 года у разработчиков промышленного ПО возникла потребность в универсальном инструменте обмена данными с устройствами разных производителей или по разным протоколам обмена данными.

Суть OPC проста — предоставить разработчикам промышленных программ универсальный фиксированный интерфейс (то есть набор функций) обмена данными с любыми устройствами. В то же время разработчики устройств предоставляют программу, реализующую этот интерфейс (набор функций).

Версии [ править | править код ]

На данный момент последней версией спецификации OPC DA является версия 3.0, однако наиболее распространенной пока является версия 2.05a. Недавно разработанный стандарт OPC UA (Unified Architecture) унифицирует набор функций для обмена данными, регистрации событий, хранения данных, обеспечения безопасности данных.

OPC DA Version 2.05a [ править | править код ]

Наиболее широко используемая. В этом стандарте помимо синхронного обмена данными, введена поддержка асинхронного обмена данными. Асинхронный обмен данных позволяет продолжать выполнение программы без ожидания ответа устройства. Этот метод снижает нагрузку на сеть и должен быть рекомендован как основной. Получение данных реализуется с помощью callback-функции пользовательской программы, которая вызывается в момент прихода ответа от устройства.

OPC Unified Architecture [ править | править код ]

Спецификация OPC UA совмещает все преимущества предыдущих спецификаций и открывает новые горизонты для применения OPC-технологий. В частности, благодаря тому, что произошел отказ от использования COM-интерфейса, обеспечивается кросс-платформенная совместимость. Новый стандарт уже изначально позволяет обеспечить более высокий уровень безопасности данных, чем OPC DA. Кроме того, новая спецификация дает возможность организации передачи информации через сеть интернет.

Инструментарий [ править | править код ]

Чаще всего для создания приложений с поддержкой OPC используют языки программирования Delphi, C++, C# или Visual Basic. Возможно использования языка Python.

Уровни управления [ править | править код ]

Исходя из области применения OPC-серверов в АСУ предприятия различают несколько уровней управления:

нижний уровень — полевые шины (fieldbus) и отдельные контроллеры;
средний уровень — цеховые сети;
уровень АСУ ТП — уровень работы систем типа SCADA;
уровень АСУП — уровень приложений управления ресурсами предприятия.

Каждый из этих уровней может обслуживаться OPC-сервером, поставляя данные OPC-клиенту на более высоком уровне или даже «соседу».

Возможные области применения OPC-серверов в АСУ предприятия [ править | править код ]

Если имеется оборудование, например плата АЦП, управляемая через драйвер на компьютере с Windows или другой ОС, поддерживающей COM/DCOM, то это самый главный кандидат на реализацию OPC-сервера непосредственно поверх драйвера.

Замена устройства не потребует изменения остальных приложений: OPC-сервер изменяется, но сам OPC-интерфейс поверх него остается прежним.

При наличии устройства, управляемого через какой-нибудь сетевой протокол, вполне возможна реализация OPC-сервера, получающего данные по этому протоколу. Единственная особенность — следует предусмотреть механизмы восстановления связи в случае сбоев.

Несколько более сложной будет схема при работе управляющих приложений на компьютере, не поддерживающем COM/DCOM. В этом случае применим двухкомпонентный OPC-сервер. На стороне ОС, не поддерживающей COM, устанавливается сетевой модуль, который, с одной стороны, связан с приложением(ями), а с другой — через сеть с OPC-сервером. Заметим, что сетевой модуль может быть стандартным, как, например, ISaNet в системе ISaGRAF. В этом случае необходимо разработать только OPC-сервер. Иногда сетевой модуль создаётся специально для OPC-сервера. Возможна даже реализация, при которой этот модуль не ориентирован на конкретное приложение, а предоставляет некоторый API-интерфейс для любых приложений, желающих обслуживаться с помощью OPC. Так действует OPC-сервер для операционной системы OS-9.

Ещё одна разновидность OPC-сервера — шлюз к сети полевой шины, такой, как Profibus или LonWorks. Реализация этой схемы очень похожа на предыдущие случаи. Скорее всего, на компьютере с ОС Windows будет установлен адаптер fieldbus-сети, а OPC-сервер будет взаимодействовать с этой сетью через драйвер адаптера. В Internet можно найти немало таких примеров.

Идея подобной схемы достаточно очевидна. Сеть полевой шины работает в жестком реальном времени, а OPC предоставляет менее требовательный шлюз к этой сети из приложений более высокого уровня.

Можно назвать много других мест применения OPC: для работы с базами данных в качестве вспомогательных или промежуточных OPC-серверов и т. д. Технология DCOM не очень пригодна для глобальных сетей. Поэтому для привлечения к OPC-технологии Internet-технологий возможен такой путь: расширение Web-сервера является OPC-клиентом, собирающим данные от OPC-серверов. А на стороне клиентов запускается динамическая html- или xml-страница, получающая данные от этого Web-сервера. Её можно сделать даже OPC-сервером для других приложений.

Полезность применения OPC с точки зрения интеграции достаточно прозрачна и вытекает из самой сути OPC. Это стандарт на интерфейс обмена данными с оборудованием. Первое преимущество — если вы заменяете какой-нибудь компонент, то нет нужды корректировать другое ПО, так как даже при замене драйвера поверх него работает OPC. Второе — если вы хотите добавить в систему новые программы, нет необходимости предусматривать в них драйверы устройств, кроме OPC-клиента, разумеется. Ну и так далее.

Состояние дел [ править | править код ]

В настоящее время общепризнанным стандартом является только спецификации OPC DA и OPC HDA, а остальные спецификации только начинают завоевывать себе место под солнцем. Не все спецификации завершены, по крайней мере, с точки зрения интерфейса автоматизации (например, для ОРС-Batch уже существует версия 2.0 custom-интерфейса, и только 1.0 — для интерфейса автоматизации. Для некоторых других спецификаций тоже существует отставание интерфейсов автоматизации от custom-интерфейсов).

Соответственно широкое распространение получил лишь стандарт OPC DA. Можно сказать, что сейчас действительно очень многие производители снабжают свои продукты OPC DA серверами. В последние годы активно развивается стандарт OPC HDA. Чего нельзя сказать о других спецификациях.

Среди программ высокого уровня аналогичная картина. Спросом пользуется лишь OPC DA.

Из операционных систем технологию COM/DCOM поддерживают следующие:

ОС Windows, начиная с Windows 95 (с установленным компонентом DCOM) и до Windows 2000. Начиная с Windows XP модель DCOM поддерживается только для целей обеспечения совместимости;
большинство Unix-подобных ОС, включая Linux; поддерживается фирмой GE Software;
ОС реального времени QNX; мост OPC реализуется при помощи решения OPC DataHub компании Cogent;
ОС реального времени VxWorks; обеспечивается фирмой-разработчиком WindRiver; имеется поддержка OPC, встроенная в систему разработки Tornado.

В других распространенных операционных системах поддержки COM/DCOM нет.

Перспективы [ править | править код ]

Довольно много оборудования и ПО не охвачено OPC-технологиями. С другой стороны корпорация Microsoft больше не развивает COM/DCOM, который заменяется более современными технологиями, например .NET.

Организация OPC Foundation своей политикой сдерживает развитие стандарта. Документация с описанием интерфейсов доступна только членам данной организации. Членство стоит от нескольких тысяч долларов, что недоступно не только для разработчиков-одиночек, но даже для многих организаций. Этим и объясняется популярность OPC DA, документация по данному интерфейсу долгое время была доступна свободно. Как результат многие фирмы, не желающие связываться с довольно капризной технологией, имеющие в штате хороших программистов нижнего уровня и работающие с ограниченной номенклатурой контроллеров используют для своих SCADA-пакетов технологию CORBA.

Заключение [ править | править код ]

Технология OPC предлагает стандарты для обмена технологическими данными, в которые заложены самые широкие возможности. Учитывая большой авторитет вовлеченных в данную деятельность фирм, можно ожидать, что технология OPC будет набирать силу. Это перспективная технология для интеграции разнородных систем. Хотя процесс становления еще далеко не завершён и есть много проблем, которые предстоит решить.

Источник