OpenSCADA

Модули/OPC UA

This page is a translated version of the page Modules/OPC UA and the translation is 100% complete.

English • ‎российский • ‎українська
Модуль Имя Версия Лицензия Источник Языки Платформы Тип Автор
OPC_UA Клиент OPC-UA 2.6 GPL2 daq_OPC_UA.so en,uk,ru,de x86,x86_64,ARM Сбор Данных Роман Савоченко
Описание
Предоставляет реализацию OPC-UA клиентского сервиса.
OPC_UA Сервер OPC-UA 2.2 GPL2 daq_OPC_UA.so en,uk,ru,de x86,x86_64,ARM Протокол Роман Савоченко
Описание
Предоставляет реализацию OPC-UA сервиса сервера.
OPC_UA Библиотека реализации OPC-UA в OpenSCADA 2.1 LGPL3 libOPC_UA.{h,cpp} en x86,x86_64,ARM Библиотека Роман Савоченко
Описание
Предоставляет реализацию протокола OPC-UA в части клиента и сервера, в виде отдельной библиотеки.
+ отревизировать представительскую страницу документации;
- разрешить противоречие в Client::messIO() на предмет смешивания режима чистого запроса с режимом свободного чтения/записи и времени ожидания тут ответа без прямой передачи таймаута подключения;
+ дополнить встроенным Логическим Режимом DAQ-Параметров;
- добавить поддержку аутентификации к входной-серверной части протокола;
- добавить автоматическое создание входных транспортов и их пре-конфигурацию из свойств объекта КонечногоУзла;
+ реализовать запрос-сервис "Publish" и "куски" в клиентской части;
- глубоко пересмотреть сервис Publish на предмет потери пакетов и отправки запроса Republish;
- добавить поддержку сервиса истории серверной части, смотря и тестируя совместно с обменом UAExpert;
- добавить поддержку сервиса истории клиентской части.

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

В виду того, что значительное влияние в организации OPC Foundation имеет корпорация Microsoft, протоколы OPC до последнего времени были одноплатформенными и закрытыми, по причине привязки к закрытым технологиям MS Windows. Однако, с недавних пор, организацией OPC Foundation были созданы такие многоплатформенные решения, как OPC XML-DA и OPC-UA. Наибольший интерес из них представляет OPC-UA, как унифицирующий все протоколы ранних версий в рамках открытых и многоплатформенных технологий.

Данный модуль реализует поддержку интерфейса и протокола OPC-UA как в виде клиентского сервиса, так и в виде сервера OPC-UA. Клиентский сервис OPC-UA реализуется одноимённым модулем подсистемы "Сбор данных", а сервер реализуется модулем подсистемы "Протоколы". Весь код реализации этим модулем специфики протокола OPC-UA был вынесен, по просьбе пользователей, в отдельную библиотеку, которая распространяется под лицензией LGPL3.

Текущей версией данных модулей и библиотеки реализуются бинарная часть протокола и базовые сервисы в небезопасном режиме и безопасных режимах политик "Base128Rsa15" и "Base256". В последствии планируется реализация остальных сервисов OPC-UA, по потребности.

Хотя протокол OPC-UA и является многоплатформенным, его спецификация и SDK не являются свободнодоступными, а предоставляются только членам организации OPC Foundation. По этой причине реализация данных модулей столкнулась со значительными препятствиями и проблемами.

Во первых, протокол OPC-UA сложен и реализация его вообще без спецификации крайне трудоёмка. По этой причине работы над данными модулями долгое время не начиналась, и только благодаря спонсорской помощи одной из организаций-члена OPC Foundation, проект OpenSCADA получил документацию спецификации. При этом SDK и исходные тексты ANSIС-API протокола OPC-UA получены не были по причине несовместимости их лицензии с GPL и, как следствие, потенциальной угрозы нарушения лицензии при работе с исходными текстами, что могло привести к последующим юридическим проблемам при свободном распространении данных модулей.

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

Для отладки функционирования модулей использовалось демонстрационное ПО фирмы Unified Automation, в составе OPC-UA клиента — UAExpert и сервера — "OPC-UA Demo Server", из пакета SDK. В виду постоянного развития самого клиента "UAExpert", в плане интерпретации спецификации OPC-UA, новые его версии часто имеют проблемы при работе с сервером OPC-UA от OpenSCADA. В целом, результаты совместимости работы с клиентами и серверами различных производителей можно получить в таблице совместимости.

Contents

1 Протокол OPC-UA

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

OPC-UA предоставляет совмещение интегрированного адресного пространства и сервисной модели. Это позволяет серверу интегрировать данные, нарушения (Alarms), события (Events) и историю в этом адресном пространстве, а также предоставлять доступ к ним посредством интегрированных сервисов. Сервисы также предоставляют интегрированную модель безопасности.

OPC-UA позволяет серверам предоставлять для клиентов определения типов, для доступа к объектам из адресного пространства. OPC-UA допускает предоставление данных в различных форматах, включая бинарные структуры и XML-документы. Через адресное пространство клиенты могут запросить у сервера метаданные, которые описывают формат данных.

OPC-UA добавляет поддержку множественной связности между узлами вместо простого ограничения иерархичностью. Такая гибкость, в комбинации с определением типов, позволяет применять OPC-UA для решения задач в широкой проблемной области.

OPC-UA спроектирован для обеспечения надёжной выдачи данных. Основная особенность всех OPC серверов — способность выдавать данные и события.

OPC-UA спроектирован для поддержки широкого диапазона серверов, от простых ПЛК до промышленных серверов. Эти сервера характеризуются широким спектром размеров, производительности, платформ исполнения и функциональной ёмкости. Следовательно, OPC-UA определяет исчерпывающее множество возможностей и сервер может имплементировать подмножества этих возможностей. Для обеспечения совместимости, OPC-UA определяет подмножества, именуемые Профилями, которые сервера могут указывать для согласования. Клиенты могут в последствии выполнять обзор профилей сервера и пробрасывать взаимодействие с сервером, основанном на профилях.

OPC-UA спецификация спроектирована как ядро в слое, изолированном от подлежащих компьютерных технологий и сетевых транспортов. Это позволяет OPC-UA, при необходимости, расширяться на будущие технологии без отторжения основы дизайна. На данный момент, спецификацией определены два способа кодирования данных: UA Binary и XML/text. Дополнительно определено два типа транспортного слоя: TCP и HTTP/SOAP.

OPC-UA спроектирован как решение для миграции с OPC клиентов и серверов, которые основаны на Microsoft COM технологиях. OPC COM сервера (DA, HDA и A&E) могут быть легко отражены в OPС-UA. Производители могут самостоятельно осуществлять такую миграцию или же рекомендовать пользователям использовать обёртки и конвертеры между этими протоколами. OPC-UA унифицирует предыдущие модели в едином адресном пространстве с единым множеством сервисов.

2 Модуль реализации протокола

Модуль сервера содержит код реализации серверной части OPC-UA — серверных сервисов (Рис.1), в части специфичной для OpenSCADA, и используя библиотеку для OPC-UA специфичной части. Для построения OPC-UA сервера достаточно создать входящий транспорт, обычно это TCP-транспорт модуля Sockets, и выбрать в нём модуль данного протокола, а также сконфигурировать хотя бы один конечный узел модуля протокола, о чём ниже.

Рис.1. Общее состояние "Сервера".

Общее состояние Сервера содержит только перечень активных каналов безопасности.

2.1 Обслуживание запросов по протоколу OPC-UA

Входящие запросы к модулю-протоколу обрабатываются модулем в соответствии со сконфигурированными конечными узлами OPC-UA (EndPoints) (рис.2).

Рис.2. Конечные узлы протокола.

Конечный узел протокола OPC-UA это фактически объект сервера OPC-UA. Конечные узлы в OPC-UA могут быть как локальными, так и удалёнными. Локальные конечные узлы предназначены для предоставления ресурсов станции OpenSCADA по протоколу OPC-UA, в тоже время удалённые конечные узлы служат для выполнения как сервиса обзора доступных OPC-UA узлов, так и для шлюзования запросов к удалённым станциям. В данной версии модуля поддерживается только конфигурация локальных конечных узлов.

Общая конфигурация конечного узла осуществляется на главной вкладке страницы конечного узла (рис.2) параметрами:

At.png Спрятано во включенном состоянии.
Рис.3. Главная вкладка страницы конечного узла.

3 Модуль сбора данных

Модуль сбора данных предоставляет возможность опроса и записи атрибутов значения(13) узлов типа "Переменная" в режиме прямого опроса запросом "Read" и асинхронным сервисом запроса "Publish".

3.1 Объект контроллера

Для добавления источника данных OPC-UA создаётся и конфигурируется объект контроллера в OpenSCADA. Пример вкладки конфигурации объекта контроллера данного типа изображен на рисунке 4.

Рис.4. Вкладка конфигурации объекта контроллера OPC-UA.

С помощью этой вкладки можно установить:

At.png Ручной перезапуск включенного объекта контроллера вызывает принудительное переформирование перечня элементов мониторинга.
At.png Часто встречается ситуация, когда уточнённый адрес является символьным, который в этой сети не резолвится, из-за некорректной настройки сервера. В таких случаях нужно оставить исходный IP-адрес или имя которое резолвится в IP правильно.
At.png Спрятано в состоянии исполнения.

С целью облегчения идентификации узлов на удалённой станции, а также выбора их для вставки в объекте параметра контроллера, в самом объекте контроллера предусмотрена вкладка навигации по узлам удалённой станции "Обзор узлов сервера", где можно пройти по дереву объектов и ознакомится с их атрибутами (рис.5).

Рис.5. Вкладка "Обзор узлов сервера" страницы объекта контроллера OPC-UA.

3.2 Параметры

Модуль сбора данных предоставляет два типа параметра: "Стандартный (std)" и "Логический (logic)". Дополнительными конфигурационными полями параметров данного модуля являются:

3.2.1 Стандартный (std)

Дополнительным конфигурационным полем параметра данного модуля (рис.6) является перечень узлов OPC-UA и поле однострочной навигации по узлам OPC-UA для вставки выбранных узлов типа "Переменная" в указанный перечень. Атрибут в этом перечне записывается как "{ns}:{id}[|[{flg}][|{id}[|{name}]]]".
Где:

Примеры:

84 — корневой узел;
3:"BasicDevices2"||var — узел базовых устройств в области имён 3 и в виде строки с прямым ИД атрибута;
4:"61626364"||var|Variable — узел в области имён 4 и в виде строки байт с прямым ИД и названием атрибута;
4:{40d95ab0-50d6-46d3-bffd-f55639b853d4}|irw|var|Variable — узел в области имён 4 и в виде GUID с неосуществлением запроса целевых данных на предмет Целого Чтения-Записи и прямым ИД и названием атрибута.
Рис.6. Вкладка конфигурации объекта параметра OPC-UA.

At.png Узлы типа "Переменная" со значением в виде структуры прочитать целиком обычно нельзя поэтому необходимо её элементы вставлять в перечень узлов чтения отдельно.

Согласно указанного списка узлов выполняется опрос и создание атрибутов параметра (рис.7).

Рис.7. Вкладка атрибутов параметра.

3.2.2 Логический (logic)

Главная страница конфигурации параметра логического типа представлена на рисунке 8.

Рис.8. Вкладка конфигурации параметра логического типа.

Значение ссылки при конфигурации шаблона (рис.9) записывается в форме "{ns}:{id}".
Где:

Примеры:

84 — корневой узел;
3:"BasicDevices2" — узел базовых устройств в области имён 3 и в виде строки;
4:"61626364" — узел в области имён 4 и в виде строки байт;
4:{40d95ab0-50d6-46d3-bffd-f55639b853d4} — узел в области имён 4 и в виде GUID.
Рис.9. Вкладка "Конфигурация шаблона" параметра логического типа.

Модулем предусмотрена особая обработка ряда атрибутов шаблона:

В соответствии с шаблоном, лежащим в основе параметра, мы получаем набор атрибутов параметра (рис.10).

Рис.10. Вкладка атрибутов параметра логического типа.

3.3 API пользовательского программирования

В виду поддержки параметров логического типа, имеет смысл предоставление ряда функций пользовательского API для их вызова из шаблона логического параметра.

Объект "Параметр" [this]


4 Библиотека libOPC_UA

Основываясь на наработках данного модуля, протокольный код OPC-UA был вынесен в отдельную библиотеку и опубликован под лицензией LGPLv3. Данные действия выполнены с целью предоставить возможность простого добавления поддержки протокола OPC-UA сторонними проектами. Библиотека представлена двумя файлами libOPC_UA.h, libOPC_UA.cpp; поддерживается и содержится в составе данного модуля, т.е. актуальную версию Вы можете загрузить здесь: http://oscada.org/svn/trunk/OpenSCADA/src/moduls/daq/OPC_UA/libOPC_UA.

Библиотека, как и данный модуль, написан на языке программирования C++. Статическая диаграмма классов, отражающая архитектуру библиотеки, приведена на рисунке 11. Согласно диаграмме классов, библиотека выполнена в области имён "OPC", а архитектурно её можно разделить на клиентскую "Client" и серверную "Server" части, которые унаследованы от общего класса протокола "UA". Кроме непосредственно классов протокола "OPC-UA" библиотека включает в себя набор функций и классов для обработки или хранения данных протокола, отдельно из которых нужно отметить класс узла языка XML "XML_N", используемый для унификации обращений к API библиотеки.

Рис.11. Статическая диаграмма классов библиотеки libOPC_UA.

Использование библиотеки в целом заключается в наследовании от класса "Client" и/или "Server" согласно с функциями конечной программы и последующей реализации виртуальных функций свойств клиента/сервера в контексте протокола OPC-UA, а также транспортной части коммуникации, т.е. — подключение/открытие TCP-сокета и передачу/чтение неструктурированного потока данных. Последующие запросы, и обработка запросов данных (для сервера), осуществляются через вызов функции запроса сервису reqService() и/или обработки виртуальной функции запроса данных reqData(), т.е., по сути, интеграция в модель данных приложения.

После добавления к клиенту поддержки асинхронного сервиса опроса данных сервисом "Publish", процесс интеграции дополнился периодическим вызовом функции Client::poll() с целью обработки асинхронного сервиса. Функция Client::poll() также обеспечена поддержкой синхронного режима работы, отдельным аргументом, через унифицированную инфраструктуру подписки-регистрации элементов мониторинга, но функцией "Read". Т.е., на данный момент достаточно зарегистрировать все элементы мониторинга функцией Client::Subscr::monitoredItemAdd() а потом вызывать функцию Client::poll() для получения их данных в нужном режиме.

После последнего пересмотра кода в версии 2, интеграция серверной части дополнительно нуждается в обязательном запуске отдельного потока обработки всех подписок, с вызовом из него функции Server::EP::subScrCycle() и аргументом счётчика циклов обработки подписок — периодичность вызова Server::EP::subscrProcPer().

4.1 Служебные объекты, функции и класс UA

4.1.1 Данные

Типы реализаций (enum — SerializerType):

Типы запроса открытия канала безопасности (enum — SC_ReqTP):

Режимы безопасности сообщения (enum — MessageSecurityMode):

Типы аутентификации (enum — AuthTp):

Классы узлов (enum — NodeClasses):

Направления обзора (enum — BrowseDirection):

Возвратная метка времени (enum — TimestampsToReturn):

Доступ (enum — Access):

Элементы маски описания обзорного запроса (enum — RefDscrResMask):

Идентификаторы атрибутов узла (enum — AttrIds):

Состояния подписки (enum — SubScrSt):

Режимы мониторинга (enum — MonitoringMode):

4.1.2 Внешние функции

В библиотеку включен ряд внешних функций объекта TSYS ядра OpenSCADA для упрощения и унификации ряда внутренних операций:

4.1.3 Объект автоматического разблокирования POSIX мютекса для OPC (OPCAlloc)

Этот объект управления мютексом является копией объекта "MtxAlloc" для ядра OpenSCADA.

Публичные методы:

4.1.4 Ошибка OPC (OPCError)

Объект ошибки "OPCError" является урезанной копией объекта TError ядра OpenSCADA.

Публичные методы:

Публичные атрибуты:

4.1.5 XML-тег (XML_N)

Объект "XML_N" является урезанной копией объекта XMLNode ядра OpenSCADA.

Публичные методы:

4.1.6 Объект узла OPC-UA (NodeId)

Данные:
Типы данных (enum — NodeId::Type):

Публичные методы:

4.1.7 Корневой объект протокола OPC-UA (UA)

Публичные методы:

4.1.7.1 Включенный объект параметров безопасности (SecuritySetting)

Публичные данные:

Публичные методы:

4.2 Основной объект Клиента (Client->UA)

Применение: Непосредственно наследуется пользовательским объектом — Клиент OPC-UA.

Публичные методы:

At.png Смешанный режим запроса и свободного чтения/записи всё ещё решается.

Защищённые атрибуты:

4.2.1 Комплексный сеанс Клиента (Client::SClntSess)

Публичные данные:

Публичные методы:

4.2.1.1 Подписка Клиента (Client::Subscr)

Публичные данные:

Публичные методы:

4.2.1.1.1 Элемент Мониторинга Подписки Клиента (Client::Subscr::MonitItem)

Публичные данные:

Публичные методы:

4.3 Основной объект Сервера (Server->UA)

Применение: Прямо наследуется пользовательским объектом — Сервер OPC-UA.

Публичные методы:

Защищённые методы:

Защищённые атрибуты:

4.3.1 Канал Безопасности Сервера (Server::SecCnl)

Публичные методы:

Публичные атрибуты:

4.3.2 Сеанс Сервера (Server::Sess)

Публичные методы:

Публичные атрибуты:

4.3.2.1 Точка продолжения обзора Сеанса Сервера (Server::Sess::ContPoint)

Публичные методы:

Публичные атрибуты:

4.3.3 Подписка Сервера (Server::Subscr)

Публичные методы:

Публичные атрибуты:

4.3.3.1 Элемент Мониторинга Подписки Сервера (Server::Subscr::MonitItem)

Публичные атрибуты:

4.3.3.1.1 Элемент значения Элемента Мониторинга Подписки Сервера (Server::Subscr::MonitItem::Val)

Публичные методы:

Публичные атрибуты:

4.3.4 Конечная Точка Сервера (Server::EP)

Публичные методы:

Защищённые методы:

Защищённые атрибуты:

5 Приватные ключи и сертификаты

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

# Создание приватного ключа:
$ openssl genrsa -out key_c.pem -des3 -rand /var/log/messages 2048
# Создание приватного ключа без пароля:
$ openssl rsa -in key_c.pem -out key_c1.pem
# Создание самоподписанного сертификата:
$ openssl req -x509 -new -key key_c.pem -out cert_c.pem -config ./OPC-UA_openssl.cnf -days 3650
# Поместить содержимое файла key_c1.pem в поле приватного ключа и cert_c.pem в поле сертификата!

6 Замечания

В процессе реализации модулей поддержки OPC-UA был обнаружен ряд несоответствий официального SDK со спецификацией OPC-UA:

7 Таблица совместимости с реализациями OPC-UA других производителей

ПО Ядро Обзор Чтение Запись Публикация Замечания
OpenSCADA parts
OpenSCADA OPC-UA Client (libOPC_UA client part) + + + + + IO requests by XML implemented: HEL (HELLO), OPN (OpenSecureChannel), CLO (CloseSecureChannel), FindServers, GetEndpoints, CreateSession, ActivateSession, CloseSession, Read, Write, Browse, CreateSubscription, DeleteSubscriptions, CreateMonitoredItems, DeleteMonitoredItems, Publish, Poll (the special empty request of checking the input channel). Chunks implemented.
OpenSCADA OPC-UA Server (libOPC_UA server part) + + + + + The requests implemented: HELF, OPNF, CLOF, MSGF: FindServers, GetEndpoints, CreateSession, ActivateSession, CloseSession, CreateSubscription, ModifySubscription, DeleteSubscriptions, MonitoredItems, ModifyMonitoredItems, SetMonitoringMode, DeleteMonitoredItems, SetPublishingMode, TranslateBrowsePathsToNodeIds, RegisterNodes, UnregisterNodes, Browse, BrowseNext, Read, Write, Publish, Republish. Chunks implemented.
Clients
UAExpert 1.2, 1.3 Pass Pass Pass Pass Pass
Indusoft web studio 7.1 Pass Pass Pass Pass Pass
Iconics genesis64 10.8 Pass Pass Pass Pass Pass
Insat masterscada 3.7 Pass Pass Pass Pass Pass
Sample Applications of Unified Architecture Pass Pass Pass Not tested Pass
Wonderware System Platform Pass Pass Pass Not tested Pass Result mask processing fix into the service "Browse" for nodes of OpenSCADA data model. ...
Kepware Pass Pass Pass Pass Pass Specific value types OpcUa_IntAuto and OpcUa_UIntAuto was added for adaptive integer type selection, mostly for provide integer not fixed as int64. Time stamp was removed from "Write" package but the client tell 0x80730000(OpcUa_BadWriteNotSupported)
UAExpert 1.4 Pass Pass Pass Pass Pass Packages sequence number split from it request and set self managing.
UAExpert 1.5 Pass Pass Pass Pass Pass The Server code cleaned from inconsistency of the data types and the types appended for declaration own OpenSCADA types OpcUa_IntAuto and OpcUa_UIntAuto.
Servers
IgnitionOPC_UA Pass Pass Pass Not tested Not tested
B&R Embedded OPC-UA Server Pass Pass Pass Pass Pass
  • the authenticate process fixed by the server provides self specific identifiers to its. The string of bytes wrong interpretation fixed;
  • 2021.05: has limits on direct reading by the service request "Read", so that was an initiator of implementing the service request "Publish" and Chunks for the Client part, UAExpert 1.5 adaption, significant refactoring and the document complete revision.


8 Ссылки

Modules/OPC_UA/ru - GFDLFebruary 2022OpenSCADA 1+r2802