OpenSCADA

Модулі/OPC UA

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

English • ‎mRussian • ‎Українська
Модуль Ім'я Версія Ліцензія Джерело Мови Платформи Тип Автор
OPC_UA Клієнт OPC-UA 2.8 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.2 LGPL3 libOPC_UA.{h,cpp} en x86,x86_64,ARM Бібліотека Роман Савоченко
Опис
Надає реалізацію протоколу OPC-UA в частині клієнта та серверу, у вигляді окремої бібліотеки.
- вирішити суперечність у Client::messIO() стосовно змішування режиму чистого запиту із режимом вільного читання/запису та часу очікування тут відповіді без прямої передачі таймауту підключення;
- додати підтримку автентифікації до вхідної-серверної частини протоколу;
- додати автоматичне створення вхідних транспортів та їх пре-конфігурацію із властивостей об'єкту КінцевогоВузла;
+ реалізувати запит-сервіс "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 та вихідні тексти ANSIC-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 вузлів, так і для шлюзування запитів до віддалених станцій. У цій версії модуля підтримується тільки конфігурація локальних кінцевих вузлів.

Загальна конфігурація кінцевого вузла здійснюється на головній вкладці сторінки кінцевого вузла (рис.3) параметрами:

At.png Приховано у ввімкненому стані.
Рис.3. Головна вкладка сторінки кінцевого вузла.

3 Модуль збору даних

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

3.1 Об'єкт контролеру

Для додання джерела даних OPC-UA створюється та конфігурується об'єкт контролеру в OpenSCADA. Приклад вкладки конфігурації об'єкту контролеру даного типу зображено на рисунку 4.

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

За допомогою цієї вкладки можна встановити:

At.png Ручний перезапуск ввімкненого об'єкту контролеру викликає примусове переформування переліку елементів моніторингу.
At.png Часто зустрічається ситуація, коли уточнена адреса є символьною, який у цій мережі не резолвиться, через некоректне налаштування серверу. У таких випадках потрібно залишити початкову IP-адресу або ім'я яке резолвиться у IP правильно.
At.png Приховано у стані виконання.
At.png Цей режим також запобігає втраті записаних даних за втрати підключення та записані дані будуть передані щойно підключення буде відновлено.

З метою полегшення ідентифікації вузлів на віддаленій станції, а також вибору їх для вставки у об'єкті параметру контролеру, в самому об'єкті контролеру передбачено вкладку навігації за вузлами віддаленої станції "Огляд вузлів серверу", де можна пройти за деревом об'єктів та ознайомитися з їх атрибутами (рис.5).

Рис.5. Вкладка "Огляд вузлів серверу" сторінки об'єкту контролеру OPC-UA.

3.2 Параметри

Модуль збору даних надає два типи параметру: "Стандартний (_Prm)" та "Логічний (_PrmL)". Додатковими конфігураційними полями параметрів цього модуля є:

3.2.1 Стандартний (_Prm)

Додатковим конфігураційним полем параметру даного модуля (рис.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 Логічний (_PrmL)

Головну сторінку конфігурації параметру логічного типу представлено на рисунку 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/uk - GFDLMarch 2024OpenSCADA 0.9.7