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.