OpenSCADAWiki: Doc/OPCUA ...

Home | Index | Changes | Comments | Users | Registration | Login  Password:  
 
English (1 Кб) English
Ukrainian (1 Кб) Українська
 (2 Кб) Страница заморожена, актуальная тут.

Модули "OPC-UA", подсистем "Сбор данных" и "Транспортные протоколы"

Параметр Модуль 1 Модуль 2 Библиотека
ID: OPC_UA OPC_UA libOPC_UA
Имя: Клиент OPC-UA Сервер OPC-UA Библиотека реализации OPC-UA в OpenSCADA
Тип: Сбор Данных Протокол Библиотека
Источник: daq_OPC_UA.so daq_OPC_UA.so libOPC_UA.{h,cpp}
Версия: 1.6 1.8 1.2
Автор: Роман Савоченко
Описание: Предоставляет реализацию OPC-UA клиентского сервиса. Предоставляет реализацию OPC-UA сервиса сервера. Предоставляет реализацию протокола OPC-UA в части клиента и сервера, в виде отдельной библиотеки.
Лицензия: GPL2 GPL2 LGPL3

Contents

Введение

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". В последствии планируется расширение модуля для работы через HTTP/SOAP и реализации остальных сервисов 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. В целом результаты совместимости работы с клиентами и серверами различных производителей можно получить в приложении.

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 при необходимости расширяться на будущие технологии без отторжения основы дизайна. На данный момент спецификацией определены два способа кодирования данных: XML/text и UA Binary. В дополнение, определено два типа транспортного слоя: TCP и HTTP/SOAP.


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

2. Модуль реализации сервера

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

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

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


Конечные узлы протокола. (60 Кб)
Рис.1. Конечные узлы протокола.

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


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


Главная вкладка страницы конечного узла. (125 Кб)
Рис.2. Главная вкладка страницы конечного узла.

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

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

3.1. Объект контроллера данных

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


Вкладка конфигурации контроллера. (137 Кб)
Рис.3. Вкладка конфигурации объекта контроллера.

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

 (2 Kb) Часто встречается ситуация, когда уточнённый адрес является символьным, который в этой сети не резолвится, из-за некорректной настройки сервера. В таких случаях нужно оставить исходный IP-адрес или имя которое резолвится в IP правильно.

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


Вкладка "Обзор узлов сервера" страницы контроллера. (125 Кб)
Рис.4. Вкладка "Обзор узлов сервера" страницы объекта контроллера.

3.2. Параметры

Модуль сбора данных предоставляет только один тип параметров — "Стандарт". Дополнительным конфигурационным полем параметра данного модуля (рис.5) является перечень узлов OPC-UA и поле однострочной навигации по узлам OPC-UA для вставки выбранных узлов типа "Переменная" в указанный перечень. Атрибут в этом перечне записывается следующим образом: {ns}:{id}.
Где:

ns — область имён, числом; нулевое значение может быть опущено;
id — идентификатор узла, числом, строкой, строкой байт или GUID.

Примеры:

84 — корневой узел;
3:"BasicDevices2" — узел базовых устройств в области имён 3 и в виде строки;
4:"61626364" — узел в области имён 4 и в виде строки байт;
4:{40d95ab0-50d6-46d3-bffd-f55639b853d4} — узел в области имён 4 и в виде GUID.

Вкладка конфигурации параметра. (102 Кб)
Рис.5. Вкладка конфигурации объекта параметра.

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


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


Вкладка атрибутов параметра. (80 Кб)
Рис.6. Вкладка атрибутов параметра.

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


Статическая диаграмма классов библиотеки libOPC_UA. (42 Кб)
Рис.7. Статическая диаграмма классов библиотеки libOPC_UA.

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

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

Данные

Типы реализаций (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):

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

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

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

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


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

Ошибка OPC (OPCError)

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


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


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

XML-тег (XML_N)

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


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

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

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


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

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

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

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

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


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

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

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


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


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

Включенный объект сеанса клиента (SClntSess)

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


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

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

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


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


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

Включенный объект канала безопасности (SecCnl)

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


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

Включенный объект сеанса (Sess)

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


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

Включенный объект точки продолжения обзора (ContPoint)

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


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

Включенный объект подписки (Subscr)

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


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

Включенный объект элемента мониторинга (MonitItem)

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

Включенный объект элемента значения (Val)

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


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

Включенный объект конечной точки (EP)

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


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


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

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

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

6. Замечания

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

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

Software Core Browse Read Write Publish Notes
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
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's request and set self managing.
Servers
IgnitionOPC_UA Pass Pass Pass Not tested NA
B&R Embedded OPC-UA Server Pass Pass Pass Not tested NA The authenticate process fixed by the server provides self specific identifiers to its. The string of bytes wrong interpretation fixed.

Ссылки

Referring pages: Doc
Function
Works/RoadMap


 
There are 10 files on this page.[Display files/form]
Comments [Hide comments/form]