|
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 был разработан с целью сокращения затрат на создание и поддержку приложений промышленной автоматизации. В начале 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-серверов в АСУ предприятия различают несколько уровней управления:
Каждый из этих уровней может обслуживаться 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 поддерживают следующие:
В других распространенных операционных системах поддержки COM/DCOM нет. ПерспективыДовольно много оборудования и ПО не охвачено OPC-технологиями. С другой стороны корпорация Microsoft больше не развивает COM/DCOM, который заменяется более современными технологиями, например .NET. Организация OPC Foundation своей политикой сдерживает развитие стандарта. Документация с описанием интерфейсов доступна только членам данной организации. Членство стоит от нескольких тысяч долларов, что недоступно не только для разработчиков-одиночек, но даже для многих организаций. Этим и объясняется популярность OPC DA, документация по данному интерфейсу долгое время была доступна свободно. Как результат многие фирмы, не желающие связываться с довольно капризной технологией, имеющие в штате хороших программистов нижнего уровня и работающие с ограниченной номенклатурой контроллеров используют для своих SCADA-пакетов технологию CORBA. ЗаключениеТехнология OPC предлагает стандарты для обмена технологическими данными, в которые заложены определенные возможности. Авторитет вовлеченных в данную деятельность фирм серьёзно сказывается на развитии OPC. Однако процесс становления еще далеко не завершён и есть много проблем, которые предстоит решить. Примечания
Ссылки |
