Материал: Побудова SCADA-системи на базі ПК

·        відстежує результати автоматизованої роботи системи;

·        втручається в процес у разі критичних подій, коли автоматика не може впоратися, або при необхідності підстроювання (регулювання) параметрів процесу;

·        навчається в процесі роботи (отримує досвід).

Дане подання SCADA стало основою для розробки сучасних методологій побудови ефективних диспетчерських систем.

Вимоги до диспетчерських систем

Особливості процесу управління на сучасних диспетчерських системах:

-  процес SCADA застосовується в системах, в яких обов'язковою є наявність людини;

-       процес SCADA був розроблений для систем, в яких будь-яка неправильна дія може привести до відмови (втрати) об'єкта управління або навіть до катастрофічних наслідків;

-       оператор несе, як правило, загальну відповідальність за управління системою, яка при нормальних умовах лише зрідка вимагає підлаштовування параметрів для досягнення оптимальної продуктивності;

-       активну участь оператора в процесі управління відбувається не часто і в непередбачувані моменти часу, зазвичай у разі настання критичних подій (відмови, нештатні ситуації і ін.);

-       дії оператора в критичних ситуаціях можуть бути жорстко обмежені за часом (декількома хвилинами або навіть секундами).

Тому до SCADA-систем ставлять наступні основні вимоги:

-    надійність системи (технологічна і функціональна);

-       безпека управління;

-       точність обробки і представлення даних;

-       простота розширення системи.

Вимоги безпеки і надійності управління в SCADA включають наступні:

-    ніяка одинична відмова обладнання не повинна викликати видачу неправдивої вихідної дії (команди) на об'єкт управління;

-       ніяка одинична помилка оператора не повинна викликати видачу неправдивої вихідної дії (команди) на об'єкт управління;

-       всі операції по управлінню повинні бути інтуїтивно зрозумілими і зручними для оператора (диспетчера).

Технологія проектування систем автоматизації на основі SCADA-систем

·  Розробка архітектури системи автоматизації в цілому. На цьому етапі визначається функціональне призначення кожного вузла системи автоматизації.

·        Вирішення питань, пов'язаних з можливою підтримкою розподілення архітектури, необхідністю введення вузлів з ​​ «гарячим резервуванням» і т. п.

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

·        Приведення у відповідність параметрів прикладної системи з інформацією, якою обмінюються пристрої нижнього рівня (наприклад, програмовані логічні контролери - PLC) із зовнішнім світом (датчики температури, тиску та ін.)

·        Налагодження створеної прикладної програми в режимі емуляції і в реальному режимі.

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

Технічні характеристики SCADA-систем

Апаратна реалізація зв'язку з пристроями вводу / виводу

Для організації взаємодії з контролерами можуть бути використані наступні апаратні засоби:

·  COM - порти. У цьому випадку контролер чи об'єднані мережею контролери підключаються за протоколами RS-232, RS-422, RS-485.

·        Мережеві плати. Використання такої апаратної підтримки можливе, якщо відповідні контролери забезпечені інтерфейсним виходом на Ethernet.

·        Вставні плати. У цьому випадку протокол взаємодії визначається платою і може бути унікальним. В даний час пропонуються реалізації в стандартах ISA, PCI, Compact PCI.

Наявні засоби мережевої підтримки

Однією з основних рис сучасного світу систем автоматизації є високий ступінь інтеграції. У будь-яку з них можуть задіюватись об'єкти управління, виконавчі механізми, апаратура, яка реєструє і обробна інформацію, робочі місця операторів, сервери БД і т.д. Очевидно, що для ефективного функціонування в цьому різнорідному середовищі SCADA-система повинна забезпечувати високий рівень мережевого сервісу. Бажано, щоб вона підтримувала роботу в стандартних мережевих середовищах (Arcnet, Ethernet і т.д.) з використанням стандартних протоколів (Netbios, TCP / IP та ін.), а також забезпечувала підтримку найбільш популярних мережевих стандартів з класу промислових інтерфейсів (Profibus, Canbus, LON, Modbus і т.д.).

Більшість SCADA-систем мають вбудовані мови високого рівня, Basic-подібні мови, що дозволяють генерувати адекватну реакцію на події, пов'язані зі зміною значення змінної, виконанням деякої логічної умови, використанням комбінацій клавіш, а також реалізацією деякого фрагмента з заданою частотою щодо всієї програми чи окремого вікна.

Графічні можливості

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

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

Можливості агрегування складних об'єктів у різних SCADA - системах різні. Всі SCADA - системи включають бібліотеки стандартних графічних символів, бібліотеки складних графічних об'єктів, мають цілу низку інших стандартних можливостей.

Вкрай важливим є питання про підтримку в розглянутих системах стандартних функцій GUI (Graphic Users Interface). Оскільки більшість SCADA-систем працює під управлінням Windows, це і визначає тип використовуваного GUI.

автоматизований управління технологічний мережевий

4. Побудова SCADA на базі ПК та контролера Twido

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Розглянемо приклад.

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

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

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

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

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

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

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

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

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

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

%MW100 PRESSURE

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

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

Рис. 3 Схема обміну даним SCADA Citect з використанням ОРС

Рис. 4 Конфігурування ОFS

Рис. 5 Конфігурування VIPA-OPC

Рис. 6 Створення в Citect IODevices, прив’язаних до OPC-серверів

Рис. 7 Створення в Citect Variable Tags

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

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

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

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

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

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

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

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

Рис. 8 Принципи функціонування OPC DA

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

Компоненти Citect

Провідник Citect (Citect Explorer) - це утиліта створення і керування проектами Citect. Окрім цього, це засіб зручного запуску таких компонентів системи Citect, як Редактор проектів, Графічний редактор і Редактор програм на мові Cicode. На рис. 9 показано головне вікно Провідника Citect: