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

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

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

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

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

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

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

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

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

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