13.OPC(укр)

 
13. Технологія ОРС

13.1. Загальні концепції.

13.1.1. Передумови виникнення

13.1.1.1. Вибір SCADA/HMI по набору підтримуваних комунікацій. Один з критеріїв вибору SCADA програми – перелік підтримуваних комунікацій. Тобто SCADA з одного боку і технічний засіб (надалі контролер) з іншого, повинні підтримувати однаковий протокол (або протоколи) промислової мережі. Найчастіше вибирають ту мережу, яка вже інтегрована в контролер. В цьому випадку при виборі SCADA враховують наявність даних протоколів в переліку комунікаційних драйверів.

13.1.1.2. Проблеми сумісності SCADA/HMI з контролерами. При інтеграції продуктів одного виробника, наявність в SCADA-програмі драйверів зв’язку з необхідними контролерами є очевидною. Найскладнішим є випадок, коли необхідно інтегрувати засоби від декількох виробників, ряд з яких підтримують закриті протоколи. В цій ситуації дуже важко підібрати таку SCADA-програму, яка б підтримувала всі необхідні протоколи промислових мереж. Розглянемо, які можливі варіанти реалізації подібної системи.  

1.     Вибір іншої промислової мережі, яка б підтримувалась з боку  SCADA та контролеру. Цей варіант не завжди можливо реалізувати.

2.     Написання спеціального драйверу, якого не існує в SCADA, для забезпечення зв’язку з контролером. Цей варіант потребує залучення програміста досить високого рівня підготовки, наявності відкритого програмного інтерфейсу з боку  SCADA-програми та відкритого протоколу обміну з контролером.

3.     Заміна частини одних контролерів іншими, для яких є драйвери зв’язку. Цей варіант потребує значних капітальних затрат і може бути використаний як виключна міра.

4.     Використання шлюзів для промислових мереж. Варіант також потребує значних капітальних затрат і не завжди реалізується.

Як бачимо, одні способи сильно обмежують реалізацію системи, а інші потребують значних капітальних затрат. Розглянемо приклад.

Приклад 13.1. ОРС.  Вибір SCADA програми.

Завдання. Система управління технологічним процесом включає три підсистеми, в кожній із яких використовуються різні за типом і виробником контролеру: TSX Premium (Schneider Electric), S7-300 (Siemens), Ломіконт Л-110 (Чебоксари) (рис.13.1.). Необхідно вибрати SCADA-програму серед трьох варіантів (Citect 7, Zenon 6, Trace Mode 6), яка б забезпечувала зв’язок з усіма підсистемами, враховуючи використання вбудованих комунікацій в ПЛК, та без придбання додаткових конвертуючих програмних засобів.

Рішення. При виборі SCADA-програми необхідно перевірити перелік комунікаційних драйверів зв’язку для підтримки вказаних контролерів. Необхідні три типи драйверів: UNI-Telway (для TSX Premium), S7-MPI (для S7-300) та драйвер Сеть Ломиконт (для Л-110).   

Протоколи для підключення засобів до SCADA-програми реалізовані у вигляді драйверів зв’язку. Зрозуміло, що інтерфейс драйверів з боку SCADA для кожної реалізації різний, тому драйвери для однієї SCADA-програми не підійдуть для іншої. Тому необхідно вибрати ту, яка має всі три драйвери. Citect 7 та Zenon 6 підтримують всі комунікації, крім Ломіконту. ТМ6 – всі комунікації, однак S7-MPI потребує наявність драйверів SIMATIC NET і має певні обмеження у використанні. Таким чином жодна з перерахованих SCADA-програм не задовольняє вказаним в умові задачі критеріям вибору. Необхідне використання додаткових програм-конверторів, розглянути можливість вибору іншої SCADA, мережі або написання драйверу зв’язку.
 
Наведений вище приклад – це один із багатьох, який обумовлює вирішення проблеми вибору SCADA. Для конкурентноздатності найбільш відомі компанії, які займаються розробкою програмного забезпечення верхнього рівня для систем автоматизованого управління, забезпечили їх великою кількістю драйверів зв’язку для пристроїв найбільш відомих брендів. Однак поставлена задача не завжди може бути вирішена шляхом вибору певної SCADA. Адже пристрій управління може бути розроблений невеликою компанією, яка не є всесвітньо відомим брендом і для якої не розроблявся відповідний драйвер.

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

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

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

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

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) – самий новий платформо-незалежний стандарт, який об’єднує функції всіх наведених вище специфікацій, але функціонує не на базі СОМ а WEB-сервісах .

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

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

Тому будемо користуватися таким поняттям ОРС - це відкрита технологія зв’язку (open connectivity) в області промислової автоматизації та управління виробництвом.

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

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

Всі перераховані в задачі 13.1 SCADA-програми можуть бути ОРСDA-Клієнтами, оскільки мають в наявності відповідний драйвер. Тому, придбавши ОРСDA-Сервер для Ломіконт, можна зв’язати Zenon та Citect з Л-110, а придбавши ОРСDA-Сервер з підтримкою S7-MPI, можна повноцінно поєднати Trace Mode з S7-300. Таким чином в даному випадку ОРСDA-Сервер можна назвати універсальним (з боку SCADA) драйвером зв’язку. Слід зазначити, що ряд  SCADA-програм повністю базуються на ОРС (Genesis, Master SCADA).

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

13.1.2.7. OPC HDA (Historical Data Access). ОРСHDA-Сервер надає доступ ОРСHDA-Клієнту для отримання збережених даних. Даний сервер підтримує два СОМ-Об’єкти: OPCHDAServer – який надає доступ до архівних даних, та OPCHDABrowser, який надає доступ до переліку змінних, які зберігаються в архіві.

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

  В наступних підрозділах буде розглядатися тільки ОРС DA технологія. 

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

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

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

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

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

2.     В SCADA-програмі вказати:

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

-         для вибраної змінної в якості джерела даних вказати ім’я на ОРС-Сервері, тобто ItemID, що був створений на 1-му кроці. Як правило ItemID вибирається зі списку, який надає  Browser на стороні ОРС-Клієнта.

Приклад 13.2. ОРС. Конфігурація ОРС-Серверів та ОРС-Клієнта (SCADA).

Завдання. Налаштувати ОРС-сервери (Schneider-Aut.OFS, VIPA.OPC-Server) та SCADA (Citect) для зчитування наступних змінних (рис.13.4) :

-        MW100, що відповідає за температуру з PLC1(VIPA200) по протоколу MPI;

-        %MW100, що відповідає за тиск з PLC2 (TSX Micro) по протоколу Modbus RTU;

Для зв’язку з контролерами використовуються ОРС-сервери:

-         OFS-Servrer від Шнейдер Електрик (ProgID=Schneider-Aut.OFS), що підтримує ряд протоколів, зокрема Modbus RTU;

-         VIPA OPC-Server від фірми VIPA (ProgID=VIPA.OPCServer), що підтримує протокол MPI.

Рішення..

1. Конфігурування OFS. Відповідно до рис.13.4 на даному OPC сервері необхідно створити змінну з назвою "Pressure", джерелом даних для якої буде змінна %MW100 на PLC2.  Для конфігурування OFS-сервера використовується утиліта OFS Configuration Tool.

Дані визначаються наступним чином (рис.13.5):

-         створюється псевдонім, який буде вказувати на адресу конкретного пристрою, з яким може обмінюватись ОРС-сервер.  У нашому випадку псевдонім пристрою має ім’я PLC2);

-         для створеного псевдоніму вказується драйвер зв’язку, адреса пристрою та додаткові параметри, що уточнюють місцезнаходження його в мережі; в нашому випадку в результаті конфігурування створиться адреса: MODBUS01:1/T;

-         для створеного псевдоніму пристрою вказати файл, в якому будуть знаходитись символьні імена та відповідні їм змінні контролера. У нашому випадку вибраний файл PLC2.CSV, в якому сформований запис:

%MW100      PRESSURE

Відповідно до правил іменування змінних в OFS, ідентифікатор потрібної змінної буде формуватися наступним чином:

ItemID = Ім’я_псевдоніму_пристрою!Ім’я_змінної

В нашому випадку ідентифікатор змінної буде −PLC2!PRESSURE. 

2. Конфігурування VIPA-OPC. Конфігурування для VIPA OPC-Server виконується з використанням утиліти OPC Editor. Аналогічно OFS, на сервері створюються пристрої, в межах яких визначаються змінні, однак їх порядок і форма дещо відрізняються (рис.13.6).

Спочатку вибирається драйвер мережі (в нашому випадку MPI). В межах мережі створюється PLC (в нашому випадку PLC1), а в межах пристрою вказується назва змінної (Tag) та її адреса в ПЛК (TEMPERATURE - MW100) Відповідно до правил іменування змінних в VIPA OPC ідентифікатор змінної буде формуватися наступним чином:

ItemID = Ім’я_PLC/Ім’я_змінної

В нашому випадку ідентифікатор змінної буде: PLC1/TEMPERATURE 

3. Створення проекту для Citect. Всі змінні в Citect (VariableTag) створюються в межах віртуальних пристроїв (IODevices). Тому необхідно створити два IODEvices, які будуть відповідати за ОРС Сервери.  Для створення IODevices скористаємось Express Communication Wizard (рис.13.7). В обох випадках вибирається драйвер ОРС  DA Client. В полях Address вказується ім’я ОРС-Серверів, тобто їх ProgID.

Далі необхідно створити змінні (рис.13.8) з прив’язкою до створених IODevices, та в полі адреси вказати відповідні ItemID.

13.2. Принципи функціонування ОРС DA

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

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

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

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

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

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

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

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

З кожним ОРС-Item'ом асоціюється плинне значення (Value), відмітка часу (Time Stamp) та якість (Quality).

 

 

 

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

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

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

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

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

-         коли на ОРС-Сервері повинні відновлюватися дані з пристроїв для кожного з ОРС-Item'ів;

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

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

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

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

13.2.2.4. Періодичне Читання з Оповіщенням (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.  

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

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

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

Частіше всього ItemID створюються за допомогою конфігуратора ОРС Сервера. Саме там і конфігурується розміщення джерела даних. У прикладі 13.2. таким способом ідентифікуються теги на VIPA.OPCServer - "Temperature". 

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

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

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

Приклад 13.3. OPC. Створення OPCGroup, OPCItem та налаштування відновлення, з використанням тестової програми OPC-Client. 

Завдання. Необхідно за допомогою тестової програми OFS-Client створити 2 групи в межах ОFS-Сервера, сконфігурованого по прикладу 13.2 з наступними параметрами:

-         перша група з періодичним читанням та оповіщенням (період=1с);

-         друга група тільки для синхронних операцій.

Продемонструвати роботу об’єкта OPC Browser для OFS Server та VIPA-OPC.

Рішення. OFS-Client – це тестова програма ОРС-Клієнта, яка поставляється разом з Сервером OFS від Шнейдер Електрик. За її допомогою можна перевірити роботу будь якого ОРС-Сервера. При запуску ОРС-Клієнта він пропонує вибрати один з ОРС-Серверів, зареєстрованих на ПК (рис.13.13). В нашому прикладі ми вибираємо Schneider-Aut.OFS.

При підключенні до Сервера, створюємо ОРС-Group (рис.13.14). Для першої визначаємо швидкість відновлення UpdateRate=1000 мс, виставляємо опцію Active – періодичне зчитування, виставляємо опцію Notifycation – активація оповіщення. На рис.13.14 видно, що можна також налаштувати зону нечутливості та способи її читання (Cash чи Device). Для другої групи опції Notifycation та Active повинні бути відключені. В обох випадках можна проводити операції синхронного читання або запису (Read Group/Write Group). Асинхронні операції можна проводити тільки для першої групи, оскільки тільки для неї активована функція оповіщення (Notifycation). Крім того для першої групи всі Item будуть автоматично відновлятися на сервері 1рас/с.
 
 
Вікна браузера ОРС-ItemID при підключенні до OFS Server та VIPA-OPC зображені відповідно на рис.13.15 та 13.16. З них видно, що перелік ItemID для обох серверів має ієрархічний вигляд. Виставивши опцію Browse Flat можна перейти до пласкої форми. Крім того браузер автоматично формує ItemID при його виборі.
 

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

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

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

1. Налаштувати DCOM Конфігуратор на вузлі Серверу та Клієнта (див. розділ 12).

2. Вказати Server Node (Ім’я вузла ОРС Серверу) або його IP.

3. Вказати ProgID Сервера.

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

13.3. Типи ОРС DA інтерфейсів

13.3.1. Загальний огляд типів інтерфейсів

OPC-Клієнти можуть зв'язуватись з OPC-Серверами через два набори COM-інтерфейсів: OPC Custom Interfaces і OPC Automation Interfaces (рис.13.17). Набір Custom інтерфейсів є обов'язковим набором COM-інтерфейсів, який використовують SCADA-програми та прикладні програми написані, наприклад, на C++ чи Delphi.

Набір Automation інтерфейсів був розроблений для використання їх в програмах, побудованих на MS Visual Basic (³V5.0) та VB for Application з використанням технології OLE Automation. Цей набір інтерфейсів є необов'язковим, але як правило присутній на OPC-Серверах основних виробників контролерів. Доступ до Сервера через такі види інтерфейсів проходить через так звану "Wrapper" DLL-бібліотеку, яка в свою чергу використовує той самий OPC Custom Interface.
 

OPC Custom інтерфейси більш гнучкі і використовуються для написання OPC-Клієнтів професійними спеціалістами, наприклад для SCADA-програм.  Однак для спеціалістів, які займаються розробленням та впровадженням систем автоматизації, може знадобитися знання Automation інтерфейсу, наприклад для написання невеликих програм на VBA, який вбудований в офісний пакет MS Office. Цей інтерфейс виділяється простотою у використанні, оскільки програміст не знаючи про механізми роботи COM/DCOM, може користуватися методами та властивостями об'єктів Сервера, як звичайного елемента управління. Для цього необхідно підключити бібліотеку типів - Wrapper (як правило, "OPC Automation 2.0" (OPCDAuto.dll), яку перед цим необхідно зареєструвати в операційній системі, виконавши операції:

1. Переписати OPCDAuto.dll в папку system32 системної папки;

2.     Запустити команду реєстрації бібліотеки: regsvr32 opcdaauto.dll.

13.3.2. Об’єктна модель інтерфейсу OPC Automation

13.3.2.1. Основні об’єкти OPC Automation. Нижче перераховані основні об’єкти бібліотеки  OPC Automation 2.0, а також приклад їх застосування (табл.13.1). На рис.13.19 показана об’єктна архітектура Automation-інтерфейсу.

Спочатку створюється об’єкт OPCServer, за допомогою якого можна продивитись список зареєстрованих Серверів та з’єднатися з необхідним. Об’єкт  OPCBrowser призначений для доступу до списку ItemID. Створення та використання об’єктів OPCGroup та  OPCItem можливе через об’єкти-колекції, в які вони об’єднані.

Таблиця 13.1

Основні об’єкти OPC Automation 2.0 та їх призначення

Об’єкт

Призначення

OPCServer

Створюється для доступу до інших об’єктів OPC-сервера: OPCGroups і OPCBrowser.

OPCGroups

Колекція об’єктів OPCGroup для даного ОРС-клієнта 

OPCGroup

Даний об’єкт реалізує механізм створення та знищення  об’єктів OPCItem та збору даних для цих об’єктів

OPCItems

Колекція об’єктів OPCItem, створених в межах OPCGroup

OPCItem

Об’єкт, який зберігає поточне значення даних на які поси-лається, інформацію про їх стан та час останньої модифікації

OPCBrowser

Об’єкт, призначений для перегляду списку ідентифікаторів даних ОРС-сервера

 

13.3.2.2. Послідовність створення об’єктів OPC Automation у програмі VBA. Застосування ОРС Automation інтерфейсу не потребує високої  кваліфікації програміста. Тому найбільш ймовірні випадки його використання – це невеликі за обсягом програми, написані на VB-подібній мові. Це може бути макрос в MS Excel чи програма для візуалізації написана в VisualBasic. Багато сучасних SCADA-програм також мають вбудовані VBA чи VB-скрипти, в яких можна користуватися об’єктами OLE Automation та ActiveX. За допомогою цього інтерфейсу відкриваються додаткові можливості при вертикальній інтеграції в комп’ютерно-інтегрованих системах.

Пропонується наступний порядок створення об’єктів для доступу до даних на ОРС-Сервері.

1.     Створюється об’єкт OPCServer:

-         оголошується об’єкт типу OPCServer з ключовим словом NEW;

-         викликається його метод Connect;

2.     Створюється об’єкт OPCGroup:

-         оголошується об’єкт типу OPCGroup (для роботи з подіями об’єкта необхідно об’явити його з ключовим словом WithEvents на рівні модуля);

-         в колекції OPCGroups викликається метод Add

3.     Створюються об’єкти OPCItem шляхом виклику метода AddItems або AddItem.

4.     Для закінчення роботи з ОРС-Сервером необхідно викликати метод Disconnect  відповідного об’єкту OPCServer.

13.3.2.3. Користування сервісами читання та запису об’єктів OPC Automation у програмі VBA.

1.     Періодичне читання групи (OPCGroup) з повідомленням:

-       відповідний об’єкт OPCGroup необхідно об’явити з ключовим словом WithEvents на рівні модуля;

-       властивісті IsActive та IsSubscribe відповідного об’єкту OPCGroup необхідно присвоїти  − TRUE;

-       властивісті IsActive кожного OPCItem, який треба відновлювати,  необхідно присвоїти  − TRUE;

-       якщо хоча б одне значення OPCItem змінилося, буде викликаний обробник подій DataChange відповідного об’єкту OPCGroup.

2.     Синхронне читання:

-       для читання декількох OPCItem в групі необхідно викликати метод SyncRead відповідного об’єкту OPCGroup;

-       для читання OPCItem необхідно викликати його метод Read.

3.     Синхронний запис:

-       для запису декількох OPCItem в групі необхідно викликати метод SyncWrite відповідного об’єкту OPCGroup;

-       для запису OPCItem необхідно викликати його метод Write.

4.     Асинхронне читання:

-       відповідний об’єкт OPCGroup необхідно об’явити з ключовим словом WithEvents на рівні модуля;

-       викликати метод AsyncRead відповідного об’єкту OPCGroup;

-       після обробки транзакції буде викликаний обробник подій AsyncReadComplete відповідного об’єкту OPCGroup.

5.     Асинхронний запис:

-       відповідний об’єкт OPCGroup необхідно об’явити з ключовим словом WithEvents на рівні модуля;

-       викликати метод AsyncWrite відповідного об’єкту OPCGroup;

-       після обробки транзакції буде викликаний обробник подій AsyncWriteComplete відповідного об’єкту OPCGroup.

13.3.3. Синтаксис основних методів, властивостей та подій об’єктів бібліотеки OPCAutomation

13.3.3.1. Загальні формальні параметри. Перед тим як розглянути основні методи та властивості об’єктів бібліотеки OPCAutomation, розглянемо формальні параметри, які найбільш часто використовуються.

Для об’єктів типу OPCGroup та OPCItem:

-         ClientHandle – це клієнтський дескриптор, за допомогою якого сервер зможе вказати клієнту на об’єкт (для ідентифікації);

-          ServerHandle – це серверний дескриптор, за допомогою якого клієнт зможе вказати на сервері об’єкт.

У деяких методах та подіях повертаються наступні параметри:

-         Valuesце масив прочитаних (записаних) значень OPCItem;

-         Errors – це масив, у якому розміщені коди помилок, якщо операція пройшла невдало;

-         NumItems – кількість OPCItem, які приймають участь у методі або повертаються з подією;

-         Qualities – це масив, в якому розміщені значення параметрів якості даних

-         TimeStamps – список значень UTC TimeStamps (час відновлення) для кожного із даних.

Параметр Source вказує на Джерело даних OPC_DS_CACHE (кеш) або OPC_DS_DEVICE (пристрій) .   

13.3.3.2. OPCServer. Повертає вказівку на колекцію об’єктів OPCGroup. Властивість по замовченню.

Таблиця 13.2

Властивість/метод

Опис

OPCGroups

Повертає вказівку на колекцію об’єктів OPCGroup. Властивість по замовченню.

GetOPCServers

(Optional Node As Variant) As Variant

 

Повертає масив імен (ProgIDs) зареєстрованих OPC Серверів на локальному або віддаленому комп’ютері. Повернений ProgIDs можна використати в методі Connect.

Node – ім’я  віддаленого вузла (комп’ютера), на якому потрібно переглянути список зареєстрованих OPC-серверів через DCOM. Наприклад: UNC ім’я (“Comp1”), або DNS ім’я (“server.com”, “www.vendor.com”, або “180.151.19.75”).

Connect

(ProgID As String, Optional Node As Variant)

 

Використовується для з’єднання з OPC Data Access Server (через custom interface). При повторному використанні методу об’єкту без явного його від’єднання від сервера automation wrapper буде автоматично відключати існуюче з’єднання. 

ProgID - Унікальне ім’я (ProgID) зареєстрованого OPC Data Access Server

Node - Може використовуватись для підключення до іншого комп’ютера через DCOM.

Disconnect()

 

Від’єднання від OPC-сервера. Після від’єднання всі посилання об’єктів OPCServer, OPCGroup(s) і OPCItem(s)  будуть знищені.

CreateBrowser() As OPCBrowser

 

Створює об’єкт OPCBrowser та повертає ссилку на нього. Метод буде виконаний тільки в тому випадку, якщо OPC Custom інтерфейс його підтримує (він є опціональний).

 

13.3.3.3. OPCGroups.   Об’єкт OPCGroups є колекцією об’єктів OPCGroup, за допомогою якого можна створювати, знищувати та управляти ними. Через нього можна також настроїти властивості по замовченню для груп, які будуть створюватись. Але для вже існуючих груп ці властивості залишаться такими як були

Таблиця 13.3

 

Властивість/метод

Опис

Item (ItemSpecifier

As Variant) As OPCGroup

Повертає ссилку на об’єкт OPCGroup по його ItemSpecifier (індекс починаючи з 1 або ім’я). Метод по замовченню

Add

(Optional Name As Variant) As OPCGroup

 

Створю новий об’єкт OPCGroup і добавляє його в колекцію. Група створюється з властивостями по замовченню. Після створення властивості групи також можуть змінюватись.

Name - Ім’я групи. Повинно бути унікальним серед всіх груп даного клієнта, інакше буде згенерована помилка. Якщо ім’я групи не вказується, сервер автоматично присвоює їй унікальну назву.

GetOPCGroup

 (ItemSpecifier As Variant) As OPCGroup

 Повертає ссилку на об’єкт OPCGroup по його ItemSpecifier (OPCGroups ServerHandle або ім’я). 

Remove

(ItemSpecifier As Variant)

 Знищує вказану групу з колекції.

ItemSpecifier - OPCGroups ServerHandle або ім’я OPCGroup, яка буде знищена.

 

13.3.3.4. OPCGroup. OPC Group призначені для організації даних для клієнтів. Дані можуть як зчитуватись так і записуватись. OPC Клієнт може сконфігурувати час відновлення, через який OPC Сервер буде повідомляти про зміни значень OPCItem в групі.

Таблиця 13.4

 

Властивість/метод

Опис

Name

Унікальне серед всіх груп даного клієнта символьне ім’я групи. Якщо клієнт не дає ім’я групі при створенні, то сервер генерує його автоматично.

IsActive

Стан групи (активна/неактивна). Якщо група неактивна, то група не буде періодично зчитувати дані.

IsSubscribed

Ця властивість вказує на можливість повідомлення клієнта в результаті роботи асинхронних операцій.  

ClientHandle

 Значення клієнтського дескриптору, який пов’язаний з групою. Його можна використовувати для ідентифікації групи при повідомленнях.

ServerHandle

Значення унікального серед всіх груп в сервері серверного дескриптору, який пов’язаний з групою. Цей дескриптор використовується в деякий методах, наприклад OPCGroups.Remove.

UpdateRate

Найменше значення часу  в мілісекундах відновлення всіх змінних в групі. Сервер може не підтримувати таку швидкість відновлення, тоді він буде зчитувати дані з найбільшою швидкістю, на яку здатен.

OPCItems

Колекція об’єктів OPCItem. Властивість по замовченню

SyncRead

(Source As Integer, NumItems As Long, ServerHandles() As Long, ByRef Values() As Variant,  ByRef Errors() As Long, Optional ByRef Qualities As Variant, Optional ByRef TimeStamps As Variant)

Операція синхронного читання, повертає  значення(value), якість(quality) та час відновлення(timestamp) items в групі.  Функція буде чекати повернення результата. Дані можуть бути прочитані із кеша у випадку, якщо вони будуть задовільняти  UpdateRate’ і deadband для групи, в іншому випадку вони будуть прочитані з пристрою. Якщо стан групи або елемента буде неактивний, то при читанні з кеша Quality буде повернений OPC_QUALITY_OUT_OF_SERVICE. 

SyncWrite

(NumItems As Long, ServerHandles() As Long, Values() As Variant, ByRef Errors() As Long)

Операція синхронного запису значення одного або декілька елементів в групі. Функція повертає управління тільки у випадку, коли значення буде записано на пристрій(DEVICE).

AsyncRead
(NumItems As Long, ServerHandles() As Long, ByRef Errors() As Long, TransactionID As Long, ByRef CancelID As Long)

 

Операція синхронного читання, повертає значення(value), якість(quality) та час відновлення(timestamp) items в групі, результат повертається при повідомленні AsyncReadComplete для даного об’єкта OPCGroup. Асинхронне читання проводиться тільки з пристрою (‘DEVICE’) при будь яких значеннях стану ACTIVE групи або елемента.

TransactionIDID транзакції, по якій клієнт при отриманні повідомлення про обробку зможе ідентифікувати номер запиту на читання.

CancelID -  ID, згенерований сервером, для можливості відмови поточної транзакції.

AsyncWrite

(NumItems As Long, ServerHandles() As Long, Values() As Variant, ByRef Errors() As Long, TransactionID As Long, ByRef CancelID As Long)

Операція асинхронного запису значення одного, або декілька елементів в групі. Результат операції повертається з повідомленням AsyncWriteComplete поточного об’єкта OPCGroup.

TransactionID - ID транзакції, по якій клієнт при отриманні повідомлення про обробку зможе ідентифікувати номер запиту на запис.

CancelID - ID, згенерований сервером, для можливості відмови поточної транзакції.

DataChange

(TransactionID As Long, NumItems As Long, ClientHandles() As Long, ItemValues() As Variant, Qualities() As Long, TimeStamps() As Date)

Подія виникає в тому випадку, коли значення або якість елемента в групі змінилося і якщо даний елемент і група являються активними.

TransactionID - ID(ідентифікатор) клієнтського запиту. Повертає ненульове значення ID запиту функції AsyncRefresh, 0 – якщо подія виникла в результаті відновлення по звичайній подписці на відновлення.

AsyncReadComplete

(TransactionID As Long, NumItems As Long, ClientHandles() As Long, ItemValues() As Variant, Qualities() As Long, TimeStamps() As Date, Errors() As Long)

Подія виникає після закінчення обробки методу AsyncRead

AsyncWriteComplete

(TransactionID As Long, NumItems As Long, ClientHandles() As Long, Errors() As Long)

Подія виникає після закінчення обробки методу AsyncWrite

 

13.3.3.5. OPCItems. Це колекція елементів OPCItem, яка також визначає настройку об’єктів OPCItem по замовченню. При добавлені об’єкта OPCItem в колекцію властивості DefaultXXXX будуть ініціалізуватися по замовченню.

Таблиця 13.5

Властивість/метод

Опис

DefaultIsActive

Статус активності для новостворюваних елементів. По замовченню True.

Count

Кількість елементів в колекції.

Item

(ItemSpecifier As Variant) As OPCItem

Повертає ссилку на елемент в колекції.

ItemSpecifier - Номер (починаючи з 1) елемента в колекції

GetOPCItem

(ServerHandle As Long) As OPCItem

Повертає ссилку на OPCItem по його ServerHandle.

ServerHandle - Це серверний дескриптор OPCItem.

AddItem

(ItemID As String, ClientHandle As Long)

 

Створює новий об’єкт OPCItem і добавляє його в колекцію.

ItemID - Повний ідентифікатор елемента

ClientHandle - Клієнтський дескриптор, який буде присвоєний об’єкту

AddItems

(Count As Long, ItemIDs() As String, ClientHandles() As Long, ByRef  ServerHandles() As Long, ByRef Errors() As Long, Optional RequestedDataTypes As Variant, Optional AccessPaths As Variant)

 

Створює декілька об’єктів OPCItem і добавляє їх в колекцію.

Count – Кількість елементів для добавлення

ItemIDs  Масив із повних ідентифікаторів ItemID

ClientHandles – Масив клієнтських дескрипторів елемнтів, які добавляються

ServerHandles – Масив серверних дескрипторів елемнтів, які добавляються

Errors – Масив помилок, який індикує результат створення елементів.

RequestedDataTypes – Опціональний Список типів даних по кожному з елементів.

AccessPaths – Опціональний Список типів даних по кожному з елементів, в якому вказаний шлях доступу Access Path’s.

Remove

(Count As Long, ServerHandles() As Long, ByRef Errors() As Long)

 Знищує об’єкти OPCItem і видаляє з колекції

SetActive

(Count As Long, ServerHandles() As Long, ActiveState As Boolean, ByRef Errors() As Long)

Позволяє активувати або деактивувати OPCItem в колекції

ActiveState - TRUE для активації. FALSE для деактивації.

 

13.3.3.6. OPCItem. Представляє собою об’єкт, який підключається до джерела даних в межах сервера. Він зв’язаний з Value, Quality and Time Stamp кожного з елементів

Таблиця 13.6

Властивість/метод

Опис

ClientHandle

Клієнтський дескриптор, асоційований з OPCItem. По цьому дескриптору клієнт може визначити джерело даних при виклику події в групі.  

ServerHandle  

Унікальний серверний дескриптор для елемента. Його необхідно вказувати при визові деяких методів (наприклад  OPCItems.Remove).

IsActive

Стан елемента (Активний = TRUE  / неактивний = FALSE).

Value  

Повертає останнє значення елемента. Властивість по замовченню.

Quality

Повертає останню величину якості елемента.

TimeStamp

Повертає останню величину часової мітки елемента.

Read

(Source As Integer, Optional ByRef Value As Variant, Optional ByRef Quality As Variant, Optional ByRef TimeStamp As Variant)

Зчитує дані для елемента з сервера. Дані можуть бути зчитані як з кеша так і з пристрою (OPCCache або OPCDevice) для відновлення інформації про значення, якості та часової мітки елемента.

Write (Value As Variant)

Записує значення елемента в сервері.

 

Приклад 13.4. ОРС. Робота з ОРС за допомогою VBA.

Завдання. Написати програму на VB/VBA для періодичного зчитування 2-х змінних з ПЛК та 1 внутрішньої змінної OFS Сервера.

Рішення. В VB створюємо форму, у якій розміщуємо 3 елементи: Labels(1), Labels(2), Labels(3). У цих елементах будуть відображатися значення змінних. Також створимо 3 кнопки, які будуть викликити відповідні процедури: SerConnect, CreateGroups та CreateItems.

В розділі об’явлення змінних (рис.13.20) вказуємо змінні для об’єктів класів OPCServer та OPCGroup. Для зберігання клієнтських та серверних індексів Item об’являємо два масиви.

При створенні групи в процедурі CreateGroups вказується ім’я групи, періодичність відновлення та активність. При створенні Item, в методі AddItems передається масив клієнтських дескрипторів (ClHandleItems). При відновленні даних буде викликаний обробник події DataChange об’єкта MyOPCGroup, в який у вигляді масивів будуть передані значення ItemValues(), TimeStamps(),Qualities() а також масив клієнтських дескрипторів тих змінних, які змінилися. По клієнтським дескрипторам змінні будуть відображені у конкретному текстовому полі Label.              

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

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

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

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

 

Оставить комментарии Вы можете здесь http://pupena-san.blogspot.com 

 

 
 
Ĉ
Александр Пупена,
12 апр. 2011 г., 8:49
Ċ
Александр Пупена,
12 апр. 2011 г., 8:46
Comments