Стандарти ОРС

Походження та специфікації

 Перша версія стандарту OPC (OPC DA 1.0) розроблена групою компаній, які в 1996 році організували некомерційну організацію  OPC Foundation (www.opcfoundation.org), що займається розвитком та просуненням даної технології на ринку.

На сьогоднішній день стандарт існує в наборі специфікацій, основні з яких:

1. OPC DA (Data Access) – специфікація доступу до даних реального часу;
2. OPC AE (Alarms & Events) – для реалізації задач попереджувально-аварійних сигналізацій;
3. OPC HDA (Historical Data Access) – для реалізації задач ведення архіву та доступу до архівних даних;
4. OPC DX (Data eXchange) – для безпосереднього обміну між ОРС-серверами;
5. OPC XML – для обміну даними через інтермережі за допомогою структур XML на базі WEB-сервісів та SOAP;
6. OPC Batсh – для реалізації управління рецептурними задачами.
7. OPC UA (United Architecture) – самий новий платформо-незалежний стандарт, який об’єднує функції всіх наведених вище специфікацій, але функціонує не на базі СОМ а SOA-WEB-сервісах .

Серед наведених вище стандартів найбільшу популярність на сьогоднішній день має OPC DA 2.0, всі інші зустрічаються набагато рідше. Перші три стандарти зі списку формують так званий OPC Classic.  Стандарт OPC UA є найновішим стандартом (2008 рік), однак поки що не знайшов такого широкого вжитку як OPC DA. Планується, що OPC UA в найближчому майбутньому витіснить OPC DA 2.0 та всі супутні йому стандарти.

  Першопочатково технологія OPC розшифровувалась як OLE for Process Control і являлась промисловим стандартом взаємодії між програмними засобами в області промислової автоматизації,  який базується на об’єктній моделі COM/DCOM (OLE). Однак  при появі нових специфікацій, зокрема XML та UA, які не базуються на СОМ, слово "OLE" в абревіатурі перестало відповідати дійсному функціональному змісту технології. На сьогоднішній день немає офіційної розшифровки  терміну ОРС. Тому будемо користуватися таким поняттям ОРС - це відкрита технологія зв’язку (open connectivity) в області промислової автоматизації та управління виробництвом.

Загальна модель

У загальному випадку, технологія ОРС забезпечує одній програмі (ОРС Клієнту) доступ до даних процесу іншої програми (ОРС Серверу) через стандартний набір інтерфейсів. Розглянемо набір інтерфейсів, які базуються на СОМ-технології, через призму їх використання в системах АСУТП (рис.8.1). Це інтерфейси, які описуються специфікаціями  OPC DA, OPC A&E та OPC HDA. 

OPC DA (Data Access). СОМ-інтерфейси ОРСDА стандартизують доступ ОРС DA Клієнту до даних процесу ОРС DA Серверу. В свою чергу програма ОРС-Сервер, як правило здійснює обмін даними з контролерами або розподіленою периферією через специфічний, відмінний від ОРС, інтерфейс. В цьому випадку, ОРС DA Сервер надає доступ ОРС DA Клієнту до даних процесу пристроїв, з якими він обмінюється тому служить в якості програми-шлюза. У випадку використання ОРС DA Серверу для доступу до даних контролеру,  його можна назвати універсальним драйвером зв’язку. Слід зазначити, що ряд  SCADA-програм повністю базуються на ОРС (Genesis, Master SCADA).

OPC AE (Alarms & Events). ОРС АЕ Клієнт використовує ОРС АЕ Сервер для контролю за процесом, тобто за виникненням певних подій. Ці події налаштовуються в межах Серверу. ОРС АЕ Клієнт з’єднується з ОРС АЕ Сервером і підписується під отримання повідомлень про виникнення цих подій. При підписці, ОРС АЕ Клієнт вказує додаткові критерії фільтрації повідомлень. Специфікацією підтримується можливість квітування повідомлень ОРС АЕ Клієнтом. 

OPC HDA (Historical Data Access). ОРС HDA Сервер надає доступ ОРС HDA Клієнту для отримання збережених даних. Даний Сервер підтримує два СОМ Об’єкти: OPC HDA Server – який надає доступ до архівних даних, та OPC HDA Browser, який надає доступ до переліку змінних, які зберігаються в архіві. Читання архівних даних проводитись з використанням 3-х різних механізмів. Перший механізм передбачає зчитування архівних даних в певному часовому діапазоні для однієї або декількох змінних, які визначені іменами. Кількість зчитаних значень обмежується Клієнтом. Другий механізм передбачає зчитування архівних даних по часу їх відновлення (Time Stamp). Третій механізм дозволяє отримувати статистичну інформацію по збереженим даним. У ОРС HDA інтерфейсі також передбачена можливість вставки, заміни або знищення архівних даних.  У наступних підрозділах буде розглядатися тільки ОРС DA технологія. 

Функціонування ОРС з точки зори інтегратора

Найбільш часто ОРС-технологія використовується в якості універсального інтерфейсу до драйверів контролерів та периферійних пристроїв. Тобто разом з контролером може поставлятися спеціальна програма – ОРС Сервер, який надає доступ до змінних цього типу контролеру. Тобто ОРС Сервер з одного боку має драйвери для зв’язку з контролерами по конкретним протоколам промислових мереж, а з іншого - надає універсальний ОРС інтерфейс для зв’язку з сервером SCADA-програми. У такій системі SCADA буде ОРС Клієнтом

На рис.8.2 показана спрощена схема функціонування роботи ОРС технології в контексті описаної системи. База даних реального часу SCADA-програми (з умовною назвою "SamplSCADA"), збирає дані з чотирьох джерел:  ПЛК1, ПЛК2, ПЛК3 та ПЛК4. Для перших двох контролерів для збору даних використовуються драйвери зв’язку для цих ПЛК, вірніше для протоколів промислових мереж, по яким вони з’єднуються. Дані зчитуються (або записуються) з ПЛК в БДРЧ (базу даних реального часу). Зв’язок з ПЛК3 та ПЛК4 виконується через ОРС сервери з умовними назвами відповідно "Sampl.OPC" та "Exmpl.OPC" з використанням драйвера ОРС Клієнта. Тобто  ОРС Сервери через вбудовані драйвери зчитують дані з ПЛК та зберігають їх в своїй базі даних реального часу. SCADA-програма в свою чергу зчитує дані з ОРС Серверів. Запис даних відбувається аналогічно.

Для реалізації такого зв’язку користувач повинен:

1. Налаштувати OPC-Сервер за допомогою спеціалізованої програми-конфігуратора, що поставляється разом з ним: створити всі необхідні змінні сервера, тобто дати їм ім’я (Item ID) та вказати джерела даних в ПЛК, на які вони посилаються.
2. У SCADA-програмі вказати:

• • назву ОРС Сервера, з яким необхідно зв’язатися (ProgID). У нашому прикладі це будуть два сервери "Sampl.OPC" та "Exmpl.OPC". Інколи SCADA надає можливість вибору ProgID зі списку зареєстрованих ОРС Серверів.
  • для вибраної змінної в якості джерела даних вказати ім’я на ОР Сервері, тобто ItemID, що був створений на 1-му кроці. Як правило ItemID вибирається зі списку, який надає  Browser на стороні ОРС-Клієнта.

ОРС модель взаємодії

ОРС DA технологія базується на Клієнт-Серверній архітектурі. ОРС Клієнт користується послугами ОРС Сервера, використовуючи СОМ-інтерфейси його об’єктів. У наведеному на рис.8.3 прикладі, ОРС Клієнтом є SCADA-програма, задачею якої є відображення чотирьох змінних (%MW100-%MW103) які знаходяться на ПЛК. OPC Сервер отримує необхідні дані через драйвери зв’язку і зберігає їх у своїй базі даних реального часу. Для того щоб доступитися до даних ОРС Сервера, ОРС Клієнт створює для себе ОРС Group (Group1, Group2), в яких створює ОРС Item (Item1, Item2), що посилаються на ці дані.

• ОРС Клієнт (OPC Client) – прикладна програма, яка вміє користуватися об’єктами OPC-Сервера за допомогою ОРС-інтерфейсів (підмножина СОМ-інтерфейсів).
• ОРС-Сервер (OPC Server) – прикладна програма, яка надає доступ до визначених в специфікації ОРС СОМ-об’єктів за допомогою ОРС-інтерфейсів.

 З одним ОРС-Сервером можуть з’єднатися декілька ОРС Клієнтів. З іншого боку, одна і та сама програма ОРС-Клієнт, може одночасно користуватися послугами декількох ОРС-Серверів. Тобто ОРС технологія є мультиклієнтною і мультисерверною.

Так як ОРС-Сервер – це СОМ-Сервер, він реєструється на комп’ютері унікальним числовим ідентифікатором (GUID) та має строковий програмний ідентифікатор (ProgID). Тобто, для того щоб для ОРС-Клієнта визначити з яким ОРС-Сервером на тому самому ПК йому необхідно з’єднатися, достатньо вказати його ProgID.

Об’єкт ОРС-Item надає доступ до джерела даних (надалі тег) в межах ОРС-Сервера, яке ідентифікується  унікальним в межах сервера ідентифікатором ItemID. Тому при створенні ОРС-Item’а, вказується ItemID необхідного тега. Правила ідентифікації даних залежать від реалізації ОРС-Сервера, а механізм визначення їх джерел (наприклад адреса пристрою та змінної в ПЛК) як правило реалізується в конфігураторі цього сервера.

Список ItemID може мати плоску або деревовидну ієрархічну структуру, що дозволяє зручніше використовувати цей механізм в проектах з великою кількістю даних. Для навігації по списку/дереву ідентифікаторів ОРС-Сервер, як правило, має об’єкт OPC Browser.

ОРС-Item належить Клієнту, який його створив і тому його не можуть використовувати декілька Клієнтів. Тим не менше є можливість посилатися на одні і ті ж дані. На рис.8.3 два Клієнта одночасно використовують дані з %MW100 та %MW102, однак створюють для цього різні OPC-Item. Джерелом даних не обов’язково є змінна на зовнішньому пристрої, це можуть бути внутрішні дані самого Серверу.

З кожним ОРС-Item'ом асоціюється:

• плинне значення (Value), тобто останнє значення яке отримав ОРС-Item від джерела даних;
• відмітка часу (Time Stamp), тобто значення часу, коли було оновлений стан ОРС-Item;
• якість (Quality), тобто величина, що характеризує стан ОРС-Item (як мінімум погана/добра/невизначена якість), зокрема з причин:
  • погана якість: помилка конфігурації, немає з'єднання з джерелом даних, помилка пристрою, помилка датчику (наприклад вихід за діапазон), помилка комунікації;
  • невизначена якість: вихід значення за заданий діапазон, неточність вимірювання, дані застарілі;     

Окрім наведених обов’язкових властивостей, кожен ОРС-Item може також додатково мати межі вимірювання, опис (коментар), одиниці вимірювання і т.д, що залежить від розробника OPC Серверу.  

OPC-Group – об’єкт ОРС Сервера, який призначений для виконання групових операцій над ОРС-Item’ами. Так як ОРС-Item не може існувати без цього об’єкту, спочатку ОРС Клієнт створює ОРС-Group, а потім в його межах створює ОРС-Item’и.

В інтерфейсі OPC DA 2.0 кожний ОРС-Group, як і все його наповнення, належить окремому ОРС-Клієнту. Механізм групування дозволяє розділяти дані за принципом читання/запису, періодичністю операцій та активувати/деактивувати відновлення змінних.

Механізми читання та запису даних процесу

Технологія ОРС надає двохсторонній доступ до даних, тобто як для читання так і для запису. Механізми реалізації цих сервісів практично однакові за принципом, однак мають свої особливості у різних версіях специфікації ОРС DA. Ми розглянемо їх в контексті 2-ї версії цієї специфікації, оскільки на сьогодні вона є найбільш популярною.

Читання зводиться до вирішення наступних питань:

• коли на ОРС-Сервері повинні відновлюватися дані з пристроїв для кожного з ОРС-Item'ів;
• яким чином про відновлення даних дізнається ОРС-Клієнт і як він їх отримає.

Операції читання та запису проводиться одночасно для всіх  Item'ів в межах ОРС-Group.

Синхронне читання (Sync Read). Ініціація процесу відновлення змінних на ОРС-Сервері може проводитись самим ОРС-Клієнтом. Тобто при необхідності ОРС-Клієнт робить запит на відновлення певної ОРС-Group. В такому випадку Клієнт може заморозити виконання своєї програми (потоку), поки не дочекається результату читання від ОРС-Сервера. Такий спосіб називається Синхронним Читанням (Sync Read). На рис.8.4 графічно зображений процес обміну між ОРС-Клієнтом та ОРС-Сервером. При необхідності Клієнт робить запит за допомогою виклику метода SyncRead для OPC-Group "myGroup" та чекає поки той не поверне відповідь.

Асинхронне читання (Async Read).  Механізм синхронного читання гальмує роботу програми (потоку) Клієнта, тому доречний для читання невеликих об’ємів даних. Альтернативою йому може бути використання Асинхронного Читання (Async Read), при якому ОРС-Клієнт теж ініціює обмін, однак не чекає результату обробки. Замість цього, при закінченні процесу читання ОРС-Сервер викликає функцію зворотного виклику  ОРС-Клієнта (обробник події AsyncReadComplete), в яку передає результат читання. Для реалізації цього механізму необхідно, щоб в об’єкті OPC-Group був активований механізм Підписки (Subscript). 

Періодичне Читання з Оповіщенням (Periodical Read with Notify). При необхідності відновлення даних, обидва наведених вище способи потребують від ОРС-Клієнта кожний раз проводити запит до ОРС-Сервера. Однак як правило дані необхідно читати періодично через певні інтервали часу. Для цього в специфікаціях OPC DA є механізм Періодичного Читання з Оповіщенням (Periodical Read with Notify). При створенні ОРС-Group, Клієнт замовляє частоту відновлення Item'ів в межах цієї групи. Через вказані проміжки часу ОРС-Сервер буде відновлювати ці дані, а результат буде зберігати в Кеші (Cache). Якщо дані (Value або Quality) хоча б для одного ОРС-Item'а в OPC-Group змінилися, буде викликана зворотна функція Оповіщення (Notify), тобто обробник події DataChange, в параметрах виклику якого будуть передані нові значення. Для ефективного використання цього механізму можна скористатися зоною нечутливості (Deadband). Необхідно зазначити, що в об’єкті OPC-Group повинен бути активований механізм Підписки та прапорець Активності (ACTIVE FLAG). Крім того, періодично відновлюватись будуть тільки Активні OPC-Item.          

Синхронний та асинхронний запис. Операції запису можуть проводитись двома способами: Синхронний Запис (Sync Write) та Асинхронний Запис (Async Write). Функціонування повністю аналогічне як і в операціях читання (рис.8.5).

Ідентифікатори ItemID

Способи ідентифікації даних.  ItemID – це унікальний, в межах OPC-Сервера, символьний ідентифікатор, який однозначно ідентифікує дані (теги) на цьому Сервері. Тобто він не повинен вказувати, з якого пристрою беруться дані, а тільки де вони розміщуються на Сервері. Частіше всього ItemID створюються за допомогою конфігуратора ОРС Сервера. Саме там і конфігурується розміщення джерела даних.

В деяких реалізаціях ItemID може створюватись автоматично. В цьому випадку розміщення джерела даних, зона нечутливості, мінімум та максимум і інше вказується в самому символьному рядку ідентифікатора. Наприклад, символьний рядок ItemID "MODBUS01:5!%MW100" в OFS Server (OPC Server від Schneider Electric) означає, що джерело даних розміщується на шині Modbus у Веденого з адресою 5, в змінній %MW100.

Доступ до списку ItemID (Об’єкт OPCBrowser).  Для зручності ідентифікації джерела даних, ОРС-Сервер опціонально може підтримувати об’єкт-навігатор OPCBrowser. В версіях ОРС DA 1.0/2.0 та ОРС DA 3.0 реалізація механізмів навігації відрізняється, однак і в першому і в другому випадку весь перелік ItemID може формувати плаский список (flat) або ієрархічне дерево (hierarchical). Ієрархічна структура формується у вигляді дерева, приклад якого наведений на рис.8.6.

OPCBrowser, як правило, потрі-бен тільки для Клієнтів, які необхідно конфігурувати, наприклад SCADA. У випадку його відсутності, користувачу треба добре знати правило формування символьного рядку ItemID для конкретного ОРС-Сервера, адже це не обумовлено в стандарті. Так наприклад, в рядку ItemID з рис.8.6 замість відокремлюючих крапок можуть використовуватися інші символи, наприклад "!".

Робота ОРС-Клієнта з віддаленими ОРС Серверами

ОРС-Клієнт та ОРС-Сервер на одному і тому самому ПК запускаються як окремі Процеси. Обмін даними між цими Процесами відбувається по правилам СОМ-технології. Інколи виникає необхідність у з’єднані ОРС-Клієнта з віддаленим ОРС-Сервером, який знаходиться у мережі на іншому ПК. Для такого з’єднання використовуються сервіси DCOM

На рис.8.7 наведений приклад, у якому ОРС-Клієнт (SCADA) на ПК1 з’єднується з локальним ОРС-Сервером (OPCServer1) та двома віддаленими (OPCServer2 на ПК2 та OPCServer3 на ПК3). Для реалізації такого з’єднання для ОРС-Клієнта окрім ProgID необхідно вказати розміщення ПК з ОРС-Сервером, а також вірно налаштувати DCOM-конфігуратор. Таким чином необхідно виконати наступну послідовність:

1. Налаштувати DCOM Конфігуратор на вузлі Серверу та Клієнта.
2. Вказати Server Node (Ім’я вузла ОРС Серверу) або його IP.
3. Вказати ProgID Сервера.

Зв’язатися з віддаленим ОРС за допомогою ОРС DA можливо тільки у випадку коли вузли знаходяться в межах одного домену або робочої групи Windows та не розмежовуються брандмауерами. Останні можуть не пропустити пакети СОМ (порти RPC як правило закриті для доступу), тому для з’єднання через Інтернет необхідно вдаватися до неабияких хитрощів. Щоб вирішити цю проблему OPC Foundation пропонує технології  OPC XML та OPC UA

Область застосування технології ОРС

Найчастіше технологія ОРС-DA використовується для вирішення проблеми доступу до даних ПЛК зі SCADA, тобто у якості стандартного інтерфейсу до драйвера зв’язку. Однак область застосування ОРС цим не обмежується.

На рис.8.8 показаний приклад використання інтерфейсів ОРС в якості „мосту” між двома прикладними програмами на різних ПК. При горизонтальній інтеграції може знадобитися об’єднання в єдиний інформаційний простір SCADA програм. Популярність ОРС-технології призвела до появи в останніх не тільки клієнтської сторони ОРС, а і серверної. Тобто SCADA може виступати як ОРС-Клієнтом так і ОРС-Сервером.

Існування в SCADA Серверного інтерфейсу дає можливість доступитись до її даних зі сторони прикладних програм рівня MES чи ERP. Офісні програми завдяки наявності VBA та ActiveX теж надають таку можливість.