OPC

Матеріал з Вікіпедії — вільної енциклопедії.
(Перенаправлено з 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 буде набирати силу. Це перспективна технологія для інтеграції різнорідних систем. Хоча процес становлення ще далеко не завершений і є багато проблем, які треба буде розв'язати.

Примітки

[ред. | ред. код]