OPC (OPC)

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 — набор спецификаций стандартов. Каждый стандарт описывает набор функций определенного назначения. Текущие стандарты^[2]:

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 проста — предоставить разработчикам промышленных программ универсальный фиксированный интерфейс (то есть набор функций) обмена данными с любыми устройствами. В то же время разработчики устройств предоставляют программу, реализующую этот интерфейс (набор функций).

Версии

Последней версией спецификации OPC DA является версия 3.0. Стандарт 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 будет установлен адаптер полевой шины, а OPC-сервер будет взаимодействовать с этой сетью через драйвер адаптера. В интернете можно найти множество примеров подобных решений.

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

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

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

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

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

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

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

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

Можно назвать много других мест применения OPC: для работы с базами данных в качестве вспомогательных или промежуточных OPC-серверов и т. д. Технология DCOM не очень пригодна для глобальных сетей. Поэтому для привлечения к OPC-технологии интернет-технологий возможен такой путь: расширение 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 Data-Hub компании Cogent;
ОС реального времени VxWorks; обеспечивается фирмой-разработчиком WindRiver; имеется поддержка OPC, встроенная в систему разработки Tornado.

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

Перспективы

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

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

Заключение

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

Примечания

↑ What is OPC? (Eng) (неопр.). Дата обращения: 11 июля 2017. Архивировано 4 июля 2017 года.
↑ Memorandum, Wisner to Stevens, Consideration of OPC Responsibility in the Field of Escape and Evasion, October 24, 1950, Top Secret. (неопр.) Cold War Intelligence. Дата обращения: 5 апреля 2022.

Ссылки

[1] What is OPC? (Eng) (неопр.). Дата обращения: 11 июля 2017. Архивировано 4 июля 2017 года.

[2] Memorandum, Wisner to Stevens, Consideration of OPC Responsibility in the Field of Escape and Evasion, October 24, 1950, Top Secret. (неопр.) Cold War Intelligence. Дата обращения: 5 апреля 2022.

[1]

[2]