База даних реального часу

База даних реального часу та підсистема вводу/виводу

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

У SCADA-програмах призначених для середніх та великих систем за роботою БДРЧ слідкує виділений програмний модуль, який ми будемо називати Сервером вводу/виводу. Сервер вводу/виводу (або аналогічна програмна частина) забезпечує з одного боку своєчасне оновлення плинних значень змінних з джерела даних (наприклад контролера), а з іншого – обслуговує запити на цю змінну для читання/запису з інших підсистем, які в такому зв’язку є клієнтами. При цьому Сервер вводу/виводу та клієнти можуть знаходитися як на одному комп’ютері, так на різних.

Сервери вводу/виводу обмінюються з джерелами даних (наприклад контролерами) через підсистеми вводу/виводу, які часто називають драйверами. У даному випадку драйвери – це програмні бібліотеки, в яких реалізовані комунікаційні протоколи. Враховуючи велику різноманітність протоколів промислових мереж, які на сьогоднішній день використовуються для з'єднання з контролерами та іншими засобами вводу/виводу, наявність того чи іншого драйверу у SCADA-програмі може стати визначальним при її виборі. Так, наприклад, більшість SCADA-програм мають у своєму складі драйвер протоколу Modbus RTU, але мало які підтримують пропрієтарний протокол UNITE та XWAY (Telemechanique). Звісно, що драйвер однієї SCADA-програми не підходить до іншої. За цих причин нерідко розробнику приходиться вирішувати проблему сумісності засобів SCADA/HMI з обладнанням рівня контролерів. На сьогоднішній день цю проблемо вдалося подолати використовуючи уніфікацію інтерфейсу підсистеми вводу/виводу через технологію OPC, яка розглядається в окремому розділі даного курсу.

Змінні (Теги)

Вище сказано, що база даних реального часу вміщує змінні, які часто називають тегами (tag). Слід зазначити, що в багатьох SCADA-програмах поняття "тег" та "змінна" відсутні взагалі, а побудова і функціонування серверної частини значно відрізняється від описаної в даному посібнику. Так, наприклад, в SCADA Trace Mode, центральним місцем є "канали", які вміщують всю функціональність обробки даних від джерела до місць призначення та в зворотному напрямку. Тим не менше, нижче приводиться певне, найбільш поширене та усереднене представлення реалізації БДРЧ.

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

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

- ідентифікатор або ім'я тегу;

- короткий опис (коментар);

- тип;

- параметри налаштування вказівки на джерело даних (наприклад, контролер);

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

- параметри налаштування масштабування;

- інші параметри   

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

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

Ідентифікація тегів

Кожному тегу, незалежно від його призначення, розробник проекту повинен дати унікальний в межах серверу ідентифікатор, за яким інші підсистеми зможуть звертатись до його значень. Як правило, це є ім'я тегу. У більшості випадків вимоги до формування імен схожі до вимог до змінних мов програмування:

- використовується тільки літери латинського алфавіту, цифри та деякі спец.символи;

- не можуть вміщувати пробілів;

- мають суттєві обмеження на кількість літер   

Звісно не обходиться без виключень з цих правил. Деякі SCADA-програми дозволяються використовувати кирилицю, а в деяких, як наприклад у SCADA zenon, змінні можуть називатися як завгодно (хоч є несуттєві обмеження на кількість літер). На перший погляд, це може дати суттєві переваги. Одне це також може зіграти злий жарт над розробником проекту. Так, наприклад, ім'я "ТІ12" на кирилиці і латинськими літерами виглядить однаково, хоч з точки зору програми є означеннями різних тегів, що може привести до довгого пошуку причини непрацездатності SCADA/HMI-проекту.

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

Ім'я тега, як правило використовується тільки для означення зв’язків в самому проекті і не видиме для оператора (користувача) системи режиму виконання. Для оператора ім'я тегу є малоінформативним і не зрозумілим, особливо якщо воно не може містити великих слів на кирилиці (для місцевих операторів) та пробілів. Так, скажімо, якщо розробник проекту вирішив використовувати ідентифікацію відповідно до схеми автоматизації, то тег може мати позначення, скажімо "TT1а" для плинного значення температури, або "TV1b" для значення положення клапану. Для розробника у цьому є певний продуманий сенс, але для оператора буде важко звикнути до таких найменувань. Тому, якщо на якомусь спливаючому вікні необхідно показати ідентифікатор тегу з яким робиться певна дія, або в легенді тренду вказати назву пера, замість імені тега краще використовувати короткий опис (Description) або коментар. Ця властивість, як правило, не має таких суттєвих обмежень як ім'я тега, і не є ідентифікуючим з точки зору SCADA, однак для оператора його можна використати саме для ідентифікації технологічного параметру з яким він працює. У наведеному вище прикладі для тегу "TT1а" можна вказати коментар "Температура на виході теплообмінника".             

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