OpenSCADAWiki: Home Page Uk/Doc/OPCUA
 
English (1 Kb) English
Russian (1 Kb) Российский

 (2 Kb) Сторінку заморожено, актуальна тут.

Модулі "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 Kb)
Рис.1. Кінцеві вузли протоколу.


Кінцевий вузол протоколу OPC-UA це фактично об'єкт серверу OPC-UA. Кінцеві вузли у OPC-UA можуть бути як локальними, так і віддаленими. Локальний кінцевий вузол призначено для надання ресурсів станції OpenSCADA за протоколом OPC-UA, в той-же час віддалені кінцеві вузли слугують для виконання як сервісу огляду доступних OPC-UA вузлів, так і для шлюзування запитів до віддалених станцій. У цій версії модуля підтримується тільки конфігурація локальних кінцевих вузлів.

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

Головна вкладка сторінки кінцевого вузла. (127 Kb)
Рис.2. Головна вкладка сторінки кінцевого вузла.

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

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

3.1. Об'єкт контролеру даних

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

Вкладка конфігурації об'єкту контролера. (130 Kb)
Рис.3. Вкладка конфігурації об'єкту контролера.


За допомогою цієї вкладки можна встановити:
 (2 Kb) Часто зустрічається ситуація, коли уточнена адреса є символьною, який у цій мережі не резолвиться, через некоректне налаштування серверу. У таких випадках потрібно залишити початкову IP-адресу або ім'я яке резолвиться у IP правильно.

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

Вкладка "Огляд вузлів серверу" сторінки об'єкту контролеру. (121 Kb)
Рис.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.

Вкладка конфігурації об'єкту параметра. (99 Kb)
Рис.5. Вкладка конфігурації об'єкту параметра.


 (2 Kb) Вузли типу "Змінна" зі значенням у вигляді структури прочитати цілком зазвичай не можна тому потрібно її елементи вставляти до переліку вузлів читання окремо.

У відповідності із вказаним переліком вузлів виконується опитування та створення атрибутів параметру (рис.6).

Вкладка атрибутів параметру. (81 Kb)
Рис.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 Kb)
Рис.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 (RU) ядра 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: HomePageUk/Doc
HomePageUk/Function
HomePageUk/Works/RoadMap