OLE for process control

OPC (від англ. Open Platform Communications, раніше OLE for Process Control) — сімейство програмних технологій, що надають єдиний інтерфейс для управління об'єктами автоматизації і технологічними процесами. Багато з OPC протоколів базуються на Windows-технологіях: OLE, ActiveX, COM / DCOM. Такі OPC протоколи, як OPC XML DA і OPC UA, є платформно незалежними.

Створення і підтримку специфікацій OPC координує міжнародна некомерційна організація OPC Foundation, створена в 1994 році провідними виробниками засобів промислової автоматизації.

Девіз OPC Foundation — «Відкриті комунікації по відкритих протоколах».

Стандарти

OPC — набір специфікацій стандартів. Кожен стандарт описує набір функцій певного призначення. Поточні стандарти:

• • OPC DA (Data Access) — основний і найбільш затребуваний стандарт. Описує набір функцій обміну даними в реальному часі з ПЛК, РСУ, ЧМІ, ЧПУ і іншими пристроями.
  • OPC AE (Alarms & Events) — надає функції повідомлення на вимогу про різні події: аварійні ситуації, дії оператора, інформаційні повідомлення та інші.
  • OPC Batch — надає функції крокової і рецептурного управління технологічним процесом (відповідно до стандартом S88.01)
  • OPC DX (Data eXchange) — надає функції організації обміну даними між OPC-серверами через мережу Ethernet. Основне призначення — створення шлюзів для обміну даними між пристроями і програмами різних виробників.
  • OPC HDA (Historical Data Access) — в той час як OPC Data Access надає доступ до даних, що змінюються в реальному часі, OPC Historical Data Access надає доступ до вже збережених даних.
  • OPC Security — визначає функції організації прав доступу клієнтів до даних системи управління через OPC-сервер.
  • OPC XML-DA (XML-Data Access) — надає гнучкий, керований правилами формат обміну даними через SOAP і HTTP.
  • OPC UA (Unified Architecture) — остання за часом випуску специфікація, яка заснована не на технології Microsoft COM, що надає крос-платформну сумісність.

Призначення

Стандарт OPC розроблявся з метою скоротити витрати на створення і супровід додатків промислової автоматизації. На початку 1990 року у розробників промислового ПО виникла потреба в універсальному інструменті обміну даними з пристроями різних виробників або по різних протоколах обміну даними.

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

Версія

На даний момент останньою версією специфікації OPC DA є версія 3.0, однак найбільш поширеною поки є версія 2.05a. Нещодавно розроблений стандарт OPC UA (Unified Architecture) уніфікує набір функцій для обміну даними, реєстрації подій, зберігання даних, забезпечення безпеки даних.

OPC DA Version 2.05a

Найбільш широко використовувана. У цьому стандарті крім синхронного обміну даними, введена підтримка асинхронного обміну даними. Асинхронний обмін даних дозволяє продовжувати виконання програми без очікування відповіді пристрою. Цей метод знижує навантаження на мережу і повинен бути рекомендований як основний. Отримання даних реалізується за допомогою callback-функції користувальницької програми, яка викликається в момент приходу відповіді від пристрою.

OPC Unified Architecture

Специфікація OPC UA поєднує всі переваги попередніх специфікацій і відкриває нові горизонти для застосування OPC-технологій. Зокрема, завдяки тому, що відбулася відмова від використання COM-інтерфейсу, забезпечується крос-платформна сумісність. Новий стандарт вже спочатку дозволяє забезпечити більш високий рівень безпеки даних, ніж OPC DA. Крім того, нова специфікація дає можливість організації передачі інформації через мережу інтернет.

Інструментарій

Найчастіше для створення додатків з підтримкою OPC використовують мови програмування Delphi, C ++, C # або Visual Basic. Можливо використання мови Python.

Рівні управління

Віходячі з області застосування OPC-серверів в АСУ підприємства розрізняють кілька рівнів управління:

• нижній рівень — польові шини (fieldbus) і окремі контролери;
• середній рівень — цехові мережі;
• рівень АСУ ТП — рівень роботи систем типу SCADA;
• рівень АСУП — рівень додатків управління ресурсами підприємства.

Кожен з цих рівнів може обслуговуватися OPC-сервером, поставляючи дані OPC-клієнту на більш високому рівні або навіть «сусідові».

Можливі області застосування OPC-серверів в АСУ підприємства

Якщо є обладнання, наприклад плата АЦП, керована за допомогою драйвера на комп'ютері з Windows або іншої ОС, що підтримує COM / DCOM, то це найголовніший кандидат на реалізацію OPC-сервера безпосередньо поверх драйвера.

Заміна пристрою не зажадає зміни інших додатків: OPC-сервер змінюється, але сам OPC-інтерфейс поверх нього залишається колишнім.

При наявності пристрою під керуванням через який-небудь мережевий протокол, цілком можлива реалізація OPC-сервера, який отримує дані з цього протоколу. Єдина особливість — слід передбачити механізми відновлення зв'язку в разі збоїв.

Дещо складнішою буде схема при роботі керуючих додатків на комп'ютері, що не підтримує COM / DCOM. В цьому випадку можна застосувати двокомпонентний OPC-сервер. На стороні ОС, що не підтримує COM, встановлюється мережевий модуль, який, з одного боку, пов'язаний з додатком (ами), а з іншого — через мережу з OPC-сервером. Зауважимо, що мережевий модуль може бути стандартним, як, наприклад, ISaNet в системі ISaGRAF. В цьому випадку необхідно розробити тільки OPC-сервер. Іноді мережевий модуль створюється спеціально для OPC-сервера. Можлива навіть реалізація, при якій цей модуль не орієнтований на конкретний додаток, а надає певний API-інтерфейс для будь-яких додатків, які бажають обслуговуватися за допомогою OPC. Так діє OPC-сервер для операційної системи OS-9.

Ще один різновид OPC-сервера — шлюз до мережі польовий шини, такий, як Profibus або LonWorks. Реалізація цієї схеми дуже схожа на попередні випадки. Швидше за все, на комп'ютері з ОС Windows буде встановлено адаптер fieldbus-мережі, а OPC-сервер буде взаємодіяти з цією мережею через драйвер адаптера. В Internet можна знайти чимало таких прикладів.

Ідея подібної схеми досить очевидна. Мережа польовий шини працює в жорсткому режимі реального часу, а OPC надає менш вимогливий шлюз до цієї мережі з додатків більш високого рівня.

Можна назвати багато інших місць застосування OPC: для роботи з базами даних в якості допоміжних або проміжних OPC-серверів і так далі. Технологія DCOM не надто придатна для глобальних мереж. Тому для залучення до OPC-технології Internet-технологій можливий такий шлях: розширення Web-сервера є OPC-клієнтом, що збирає дані від OPC-серверів. А на стороні клієнтів запускається динамічна html- або xml-сторінка, яка отримує дані від цього Web-сервера. Її можна зробити навіть OPC-сервером для інших додатків.

Корисність застосування OPC з точки зору інтеграції досить прозора і випливає з самої суті OPC. Це стандарт на інтерфейс обміну даними з обладнанням. Перша перевага — якщо ви замінюєте який-небудь компонент, то немає потреби коригувати інше програмне забезпечення, так як навіть при заміні драйвера поверх нього працює OPC. Друге — якщо ви хочете додати в систему нові програми, немає необхідності передбачати в них драйвери пристроїв, крім OPC-клієнта, зрозуміло. Ну і так далі.

Стан справ

В даний час загальновизнаним стандартом є тільки специфікації OPC DA і OPC HDA, а решта специфікації тільки починають завойовувати собі місце під сонцем. Не всі специфікації завершені, принаймні, з точки зору інтерфейсу автоматизації (наприклад, для ОРС-Batch вже існує версія 2.0 custom-інтерфейсу, і тільки 1.0 — для інтерфейсу автоматизації. Для деяких інших специфікацій теж існує відставання інтерфейсів автоматизації від custom-інтерфейсів).

Відповідно широке поширення отримав лише стандарт OPC DA. Можна сказати, що зараз дійсно дуже багато виробників постачають свої продукти OPC DA серверами. В останні роки активно розвивається стандарт OPC HDA. Чого не можна сказати про інших специфікаціях.

Серед програм високого рівня аналогічна картина. Попитом користується лише OPC DA.

З операційних систем технологію COM / DCOM підтримують наступні:

• ОС Windows, починаючи з Windows 95 (з встановленим компонентом DCOM) і до Windows 2000. Починаючи з Windows XP модель DCOM підтримується тільки для цілей забезпечення сумісності;
• більшість Unix-подібних ОС, включаючи Linux; підтримується фірмою GE Software;
• ОС реального часу QNX; міст OPC реалізується за допомогою вирішення OPC DataHub компанії Cogent;
• ОС реального часу VxWorks; забезпечується фірмою-розробником WindRiver; є підтримка OPC, вбудована в систему розробки Tornado.

В інших поширених операційних системах підтримки COM / DCOM немає.

Перспективи

Досить багато обладнання і ПЗ не охоплено OPC-технологіями. З іншого боку корпорація Microsoft більше не розвиває COM / DCOM, який замінюється більш сучасними технологіями, наприклад .NET.

Організація OPC Foundation своєю політикою стримує розвиток стандарту. Документація з описом інтерфейсів доступна тільки членам цієї організації. Членство коштує від кількох тисяч доларів, що недоступно не тільки для розробників-одинаків, але навіть для багатьох організацій. Цим і пояснюється популярність OPC DA, документація по даному інтерфейсу довгий час була доступна вільно. Як результат багато фірм, які не бажають зв'язуватися з досить примхливої ​​технологією, мають в штаті хороших програмістів нижнього рівня і працюють з обмеженою номенклатурою контролерів використовують для своїх SCADA-пакетів технологію CORBA.

Висновок

Технологія OPC пропонує стандарти для обміну технологічними даними, в які закладені найширші можливості. З огляду на великий авторитет залучених в дану діяльність фірм, можна очікувати, що технологія OPC буде набирати силу. Це перспективна технологія для інтеграції різнорідних систем. Хоча процес становлення ще далеко не завершений і є багато проблем, які треба буде розв'язати.

Примітки

• OPC Foundation [ 8 квітня 2011 у Wayback Machine.]