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

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

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

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

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

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

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

Примечания[править | править код]

  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.

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

Источник — https://ru.wikipedia.org/w/index.php?title=OPC&oldid=137302849