Збір даних SCADA(Supervisory Control and Data Acquisition)-системи є її невід'ємною частиною, яка займається отриманням даних із джерел різноманітного походження. Природа даних, з якими працює SCADA, характеризується сигналами базових типів значень (цілі, реальні, логічні та рядок). Сигнали змінюються у часі та мають історією — життя. У теорії управління технологічними процесами (ТП), під сигналом мається на увазі значення давача установки ТП у коді АЦП — "сирий" сигнал, або у реальному значені — інженерний. Сигнали можуть поєднуватися у групи за смисловим навантаженням, які часто називаються параметрами або комплексним тегом. Наприклад, розвинуті джерела даних можуть надавати структури параметрів із визначеним набором пов'язаних сигналів. Крім безпосередньо збору даних, до функції цього механізму також входить і передача дій на виконавчі пристрої управління ТП, зазвичай це: засувки, насоси та регулюючі клапани. Сукупно, це обладнання отримало назву — Пристрій Узгодження із Об'єктом (ПУО).
Джерела даних характеризуються великим розмаїттям, яке можна умовно поділити на три групи:
Розмаїття джерел даних породило великий спектр механізмів доступу до них. Локальні джерела даних різняться інтерфейсами програмування додатку (API), а мережеві джерела, своєю чергою, транспортним та протокольним рівнями взаємодії. В цілому, це призвело до того, що додання підтримки нового джерела даних потребує створення модуля сполучення або драйверу. Враховуючи ж велике розмаїття джерел, це доволі затратно та фактично нереально охопити весь спектр ринку таких пристроїв. Ситуація дещо спрощується із мережевими джерелами, завдяки наявності низки стандартних та вільних протоколів взаємодії, однак багато джерел все-ж використовують власні протоколи: закриті комерційні або протоколи, зав'язані на закриті механізми комерційних операційних систем (ОС).
У термінах OpenSCADA, надаються наступні об'єкти моделі даних обслуговування механізму збору даних:
Для врахування особливостей різних пристроїв збору даних, а також різних механізмів взаємодії, у OpenSCADA передбачено підсистему "Збір Даних", яка є модульною. У якості модуля підсистеми виступає драйвер сполучення із джерелом даних окремого типу. Кожний модуль може містити конфігурацію декількох пристроїв цього типу у вигляді об'єктів контролеру. Загальну схему об'єктів підсистеми "Збір даних" зображено на рисунку 1.
Враховуючи різні властивості джерел даних, а також можливі варіанти взаємодії, методи збору даних можна поділити на: простий синхронний, простий асинхронний, пакетний та пасивний.
У огляді механізмів нижче будуть приймати участь наступні об'єкти:
Механізм характеризується запитами до джерела даних синхронно із запитом до атрибуту параметра (рис.2). Цей механізм, зазвичай, застосовується при роботі з локальними джерелами даних, які характеризуються низькою латентністю, тобто затримкою у відповіді на запит. За допомогою цього методу можна отримати актуальні дані безпосередньо із запитом, однак час запиту об'єкту буде включати час транспортування та обробки запиту джерелом даних.
Відповідно до діаграми вище, ми отримуємо наступну послідовність запитів отримання даних та їх передачі:
У OpenSCADA такий механізм реалізують наступні модулі підсистеми "Збір Даних":
Механізм характеризується запитами до джерела даних незалежно від запиту до атрибуту параметра (рис.3). Зазвичай, запити до джерела даних здійснюються періодично, у власному завдані опитування окремо взятого контролеру та блоками по декілька сигналів. При цьому, запитом до атрибуту параметра повертається значення, отримане останнім сеансом зв'язку із джерелом даних. Цей механізм зазвичай застосовується при роботі з віддаленими (мережевими) джерелами даних, які характеризуються високою латентністю, тобто затримкою у відповіді на запит.
За допомогою цього методу можна забезпечити оптимізацію часового ресурсу, витраченого на один сигнал, і тим самим збільшити максимальну кількість опитаних сигналів за інтервал часу опитування.
У якості показового прикладу розглянемо промисловий ПЛК "Siemens S7-315", при опитувані його по шині ProfiBus (1,5 Мбіт/с). Середній час обробки MPI-запиту цим контролером становить 30 мс. Якщо використовувати синхронний механізм для кожного сигналу, тобто один запит на кожний сигнал, то протягом однієї секунди ми зможемо отримати біля 33 сигналів. А якщо застосувати асинхронний механізм, тобто у одному MPI-пакеті отримувати до 220 байт або 110 сигналів цілочисельного типу на 16-розрядів, то ми зможемо за одну секунду отримати до 3630 сигналів. Як можна бачити, ефективність асинхронного механізму, у цьому випадку, складає 110 разів, а саме значення максимальної ємності MPI-пакету.
Недоліком асинхронного механізму є те, що запит значень атрибуту параметра повертає неактуальне на час запиту значення, а значення останнього сеансу опитування контролеру. Утім, якщо врахувати, що джерело даних може оновлюватися з періодичністю апаратних обмежень АЦП, та й самі давачі можуть мати певні обмеження у швидкості реакції, то й застосування асинхронного механізму збору може мати серйозні підстави.
Застосування асинхронного механізму для запису значень у ПЛК є доволі рідкісним явищем, оскільки запис значень зазвичай передбачає вплив оператора на ТП. Оператор, по факту, достатньо рідко вносить коригування у процес, відтак запис можна здійснювати синхронно. Однак, існують ситуації, наприклад, управління ТП регуляторами на SCADA-системі, яка виконує функції середовища виконання ПЛК.
Згідно до діаграми вище, ми отримуємо наступну картину:
В OpenSCADA такий механізм реалізують наступні модулі підсистеми "Збір Даних":
Пакетний механізм збору характерний збором даних кожного сигналу пакетом, який включає історію його зміни. Тобто, за один сеанс опитування отримується декілька значень історії сигналу. Пакетний механізм працює спільно із синхронним та асинхронними механізмами.
У випадку роботи з синхронним механізмом, виконується фактичне перекидання архіву джерела даних для оперативної роботи у системі (рис. 2). Як і простий синхронний механізм, його бажано застосовувати тільки на низько-латентних джерелах даних або із джерелами, робота яких є сеансовою, наприклад, у сфері комерційного обліку для читання значень лічильників.
При роботі спільно із асинхронним механізмом, історія отриманих сигналів зазвичай прямо розташовується у архіви (рис. 4), а поточні значення атрибута параметру встановлюються у останнє значення пакету. Така комбінація ефективна при зборі швидких даних або при синхронізації архівів після втрати зв'язку з віддаленим джерелом даних.
Згідно діаграми вище, ми отримаємо наступну поведінку пакетного механізму при асинхронних запитах:
У OpenSCADA такий механізм реалізують наступні модулі підсистеми "Збір Даних":
Пасивний механізм збору характерний ініціативою надання даних до SCADA-системи із боку джерела даних. Цей механізм є достатньо рідкісним явищем, однак може мати місце за певних умов або обмежень у можливості використання прямих механізмів збору даних, рисунок 1.4a. Прикладом такої ситуації можуть слугувати географічно розосереджені системи збору даних за посередництвом мобільних мереж GPRS/EDGE/3G/4G/... . Наділення всіх вузлів окремими реальними та статичними IP-адресами, або формування корпоративної мобільної мережі, у таких мережах може виявитися дорогим задоволенням, тому доступніше виявляється ініціатива сеансу передачі даних із-за динамічних IP-адрес на одну реальну IP-адресу серверу SCADA-системи. Дії на модифікацію передаються джерелу даних в момент сеансу передачі даних джерелом — читання. Хоча тут можливі й типові запити через VPN підключення від джерела даних та функціювання через мережеву СУБД-посередника.
Згідно до діаграми вище, ми отримуємо наступну поведінку пасивного механізму:
У випадку коли хост, що ініціює підключення, має динамічну адресу яка не є "сірою", тобто за нею можна підключитися прямо, тоді ініціативне підключення можна використовувати лише для отримання зворотної адреси, за якою прямо і підключатися, а у контролері таких підключень здійснювати лише оновляння динамічної адреси.
Окремим випадком є ініціатива встановлення TCP-підключення від джерела даних та подальше здійснення стандартних запитів за цим підключенням від сервера, що вхідні транспорти модуля "Сокети" і модуля "SSL" наразі підтримують. Цей режим наразі навіть найрозповсюдженіший!
OpenSCADA також сама підтримує ініціацію таких підключень, тобто може виступати у ролі джерела даних за "сірим" та динамічним IP. Так, вхідний транспорт модуля "Сокети" і модуля "SSL" у режимі 2 виступає ініціатором підключення, після чого надсилає ідентифікуючу послідовність та переходить у звичайний режим отримання запитів від хосту, до якого під'єднався. Щодо чого наразі особливо корисним є віддалений контроль OpenSCADA станцій у сірих мережах за такого підключення.
Крім збору фізичних даних, актуальною є функція віртуального збору даних. Віртуальні дані представляють собою дані, отримані всередині системи як незалежно, так і на основі фізичних даних. Практично, механізми формування віртуальних даних реалізуються разом з механізмом користувацьких обчислень. В середині промислових контролерів та SCADA-систем використовуються різні мови програмування. У випадку з контролерами, у якості таких мов часто використовуються мови низького рівня (асемблери), однак, останнім часом, все частіш використовуються мови високого рівня (C, Pascal та інші), а також формальні мови IEC 61131-3 (схеми потоків станів SFC, блокові схеми FBD, релейні схеми LD та текстові ST, IL). У випадку із SCADA-системами, обчислювання частіше забезпечуються мовами програмування високого рівня та формальними мовами.
У OpenSCADA можуть бути реалізовані інтерфейси програмування та віртуальних джерел даних на основі різних мов, у окремих модулях підсистеми "Збір Даних". На поточний час доступні модулі віртуальних обчислювачів:
До ядра OpenSCADA інтегровано механізм користувацьких функцій або API користувацького програмування. Користувацькі функції можуть надаватися будь яким об'єктом програми, в тому числі й модулями, відповідно до власної функціональності, тим самим надаючи користувачу деякий набір функцій контролю за тим або іншим об'єктом. Функції користувацького API можуть бути як статичними, тобто ті що реалізують фіксовану функціональність окремого об'єкту, так і динамічними, тобто ті що формуються користувачем під потрібне йому завдання на внутрішній мові користувацького програмування високого рівня.
Модуль JavaLikeCalc надає до OpenSCADA механізм створення динамічних користувацьких функцій та їх бібліотек на Java-подібній мові. Опис функції на Java-подібній мові полягає у обв'язки параметрів функції алгоритмом. Крім цього, модуль наділено функціями безпосередніх обчислень, шляхом створення обчислювальних контролерів із асоційованою обчислювальною функцією. Модулем надається механізм прекомпіляції контекстно-залежних функцій, що використовується для вбудовування користувацьких алгоритмів безпосередньо до контексту різних компонентів OpenSCADA, це, наприклад, шаблони параметрів підсистеми "Збір Даних" та рушій Середовища Візуалізації та Управління (СВУ).
Модуль BlockCalc надає до OpenSCADA механізм створення користувацьких обчислень, що ґрунтується на формальній мові блокових схем. Мови блокового програмування ґрунтуються на понятті блокових схем та функціональних блоків. Причому, залежно від сутності блоку, блокові схеми можуть бути: логічними схемами, схемами релейної логіки, моделлю технологічного процесу та інше. Сутність блокової схеми полягає в тому, що вона містить перелік блоків та зв'язки між ними. З формальної точки зору блок — це елемент (функція), яка має входи, виходи та алгоритм обчислення. Виходячи із концепції середовища програмування, блок — це кадр значень, асоційований з об'єктом функції. Входи та виходи блоків треба поєднувати для отримання цільної блокової схеми.
З метою наповнення API користувацького програмування функціями, створені наступні спеціалізовані модулі статичних функцій API користувацького програмування:
Вище ми відзначали, що тип джерела даних може коливатися від "сирого" до комплексного. Під "сирим" мається на увазі джерело, яке надає тільки елементарні сигнали (цілі, реальні, логічні, рядок, ...), до того ж окремо. Під комплексним мається на увазі джерело, яке групує сигнали та, в параметрі підсистеми "Збір Даних", надає атрибути додаткового призначення, які покривають практично всі діагностичні завдання, тобто параметр є закінченим об'єктом, який не потребує доповнення.
Враховуючи таку розбіжність, може виникнути ситуація, коли інформації у параметру контролера від джерела даних недостатньо для опису реального об'єкту ТП загалом та потрібен довільний об'єкт більш високого рівня абстракції. Вирішенням цієї ситуації може бути формування додаткових параметрів, що є ненаглядним та вносить плутанину. Більш правильним рішенням є використання прошарку "Логічного рівня", який виконує функцію гнучкого формування параметрів-контейнерів сигналів потрібної структури та що включає пост-обробку.
Функціонально, "Логічний рівень" призначено для надання у OpenSCADA механізму вільного формування параметрів-контейнерів сигналів потрібної структури.
Експлуатаційним призначенням "Логічного рівня" є:
Концепцію "Логічного рівня" засновано на шаблонах параметрів, для яких, у підсистемі "Збір Даних", передбачено контейнер бібліотек шаблонів (рис.1). Кожна бібліотека містить шаблони параметрів, які можуть використовуватися модулями підсистеми "Збір Даних" для реалізації параметрів на основі шаблонів. Модулями OpenSCADA, які використовують шаблони у своїй роботі, є:
Загальний механізм роботи "Логічного рівня", на прикладі модуля LogicLev, зображено на рисунку 7.
Виходячи із цього зображення видно, що параметри контролеру логічного рівня виконують функцію віддзеркалення інших параметрів підсистеми "Збір Даних" (на прикладі параметрів 1 та 4) та довільне формування параметрів на основі шаблонів 1, 2 та інших параметрів підсистеми "Збір Даних" (на прикладі параметрів 2, 3 та 5).
Структура параметрів з шаблоном в основі має структуру, зображену на рисунку 8.
Як можна бачити із структури, параметр логічного рівня складається із об'єкту функції, атрибутів та конфігурації шаблону. Об'єкт функції це екземпляр виконання функції шаблону з набором входів/виходів та програмою обчислення шаблону на одній із мов користувацького програмування, зазвичай це Java-подібна мова користувацького програмування модуля JavaLikeCalc. Утім, шаблон може бути взагалі без програми, надаючи тільки структуру перекидання входів/виходів. Атрибути у структурі зображують перелік атрибутів результуючого параметру відповідно до шаблону. Конфігурація у структурі надає конфігурацію властивостей шаблону та його зовнішніх зв'язків.
Логіку роботи логічного рівня параметрів можна записати наступним чином:
Шаблон параметрів, загалом, надає наступне:
На рисунку 9 наведено зображення вкладки конфігурації шаблону параметрів підсистеми "Збір Даних" у вигляді таблиці з конфігурацією входів/виходів та тексту програми користувацького програмування.
Вкладкою входи/виходи "ВВ" шаблону параметрів передбачено наступні властивості спеціалізованого призначення: "Атрибут", "Конфігурація" та "Значення".
Властивість "Атрибут" виступає ознакою віддзеркалення входу/виходу шаблону на результуючий атрибут параметра. Передбачено наступні варіанти цієї властивості:
Властивість "Конфігурація" виступає ознакою, яка вказує на використання входу/виходу функції шаблону в результуючій конфігурації шаблону на логічному рівні. Передбачено наступні варіанти цієї властивості:
Поле "Значення" описує передвстановлене значення постійних та шаблонів зовнішніх зв'язків. Шаблон зовнішніх зв'язків використовується з метою описання механізму групування та автоматичного розподілу зовнішніх зв'язків. Структура шаблону зовнішніх зв'язків однакова у частині підключення до атрибутів параметрів підсистеми "Збір даних" та розширюється специфічним форматом адреси окремого модуля підсистеми "Збору даних", який використовує механізм шаблонів. Підключення до параметрів підсистеми "Збір даних" — шаблон конфігурації зовнішнього зв'язку має вигляд {Параметр}|{атрибут}, де:
Саме подальше зв'язування загалом може здійснюватися:
У якості прикладу використання шаблону, на рисунку 10 наведено зображення параметру "F3" модуля логічного рівня, де представлено вкладку "Конфігурація шаблона" для конфігурації шаблону параметру, включаючи зв'язування. На рисунку 11 представлено вкладку "Атрибути" з переліком атрибутів та їх значень, створених за посередництвом шаблону.
Наступним рівнем, заснованим на Логічному Рівні, є концепція доступу до даних через користувацький протокол, що реалізується або прямо у коді шаблону або як окремий об'єкт Користувацького Протоколу у модулі Protocol.UserProtocol, де наразі також можна використовувати DAQ-шаблони.
Концепцію доступу до даних через користувацький протокол можна зобразити як на рисунку 1.
Як можна бачити з рисунку 1, взаємодія з пристроєм відбувається через деякий транспорт на якому вони фізично базуються. Запит до транспорту Ви можете надіслати:
Цей останній метод наразі розвинено до можливості формування протокольної частини коду безпосередньо у тому-ж коді шаблону, як окрема вбудована функція через виклик функції запиту першого методу, якщо немає потреби повторного використання, або навіть якщо така потреба є та тут має сенс створення комплексного шаблону, який зможе поєднувати роль й вихідного протоколу, через його підключення також до модуля користувацького протоколу. Та воно буде повністю зберігатися у одній бібліотеці шаблонів. Пряма робота із вихідним транспортом функції string messIO( string mess, real timeOut = 0 ); не передбачає блокування транспорту поза викликом цієї функції, а відтак, для складних протоколів із посилками відповіді більш ніж у одному пакеті, що передбачає процес "доочікування", не можна використовувати спільний транспорт, за яким можливе надсилання пакетів різних протоколів або навіть один, але з різних завдань (об'єктів контролерів). Відтак, якщо є потреба використання спільного транспорту, то розташовуйте параметри опитування за протоколом у одному об'єкті контролеру (завдані) або використовуйте модуль користувацького протоколу, до якого це зауваження не має стосунку, оскільки він здійснює таке блокування на час виклику процедури обробки, як і решта модульних протоколів OpenSCADA.
Створено наступні бібліотеки з використанням концепції доступу до даних через користувацький протокол:
Резервування загалом, та джерел даних зокрема, слугує для підвищення загального рівня відмовостійкості рішення шляхом включення дублювальних вузлів до спільної роботи з основним вузлом. У випадку відмови основного вузла відбувається підхоплення функцій основного вузла резервним. Часто, схема резервування може працювати і у режимі розподілу навантаження між вузлами, що спільно працюють.
У випадку з підсистемою "Збір Даних", резервування даних (рис.12) виконує функції:
Резервування рекомендується налаштовувати таким чином щоб БД резервних станцій зберігалися однаковими, що надалі дозволить безболісно копіювати їх, при відновленні, на будь яку станцію та, відповідно, у резервній копії можна зберігати тільки один набір БД. При цьому, налаштування, специфічні до окремої станції, будуть зберігатися у конфігураційному файлі та можна буде легко конфігурувати та міняти потрібну станцію через вибір відповідного конфігураційного файлу.
Налаштування резервування починається з додання резервних станцій до переліку станцій OpenSCADA на вкладці "Підсистема" підсистеми "Транспорти" (Рис.13). Причому додавати тут потрібно не лише резервні станції до поточної, але й саму цю поточну станцію з її зовнішньою адресою, тобто своєрідна петля. Надалі ці налаштування будуть збережені до загальної БД резервованої системи та сама БД з цього моменту буде використовуватися при створені всіх резервних станцій. Відповідно, важливо на цьому етапі внести всі потрібні зміни до загальної БД довкола проекту в цілому!
Далі, на конкретній станції з копією загальної БД, налаштовуємо її специфічні параметри у вкладці "Резервування" головної сторінки (рис.14), які будуть збережені у конфігураційному файлі.
Після цього вся конфігурація резервування здійснюється у вкладці "Резервування" підсистеми "Збір даних" (Рис.15). Якщо встановити параметр "Передача локальних первинних команд" (Рис.14) то ця конфігурація, як і будь яка інша загального характеру, може здійснюватися на одній з станцій, а внесенні зміни потраплять на всі резервні, звісно якщо вони будуть доступні.
Завдання обслуговування механізму резервування запускається завжди та виконується з періодичністю, встановленою у відповідному конфігураційному полі. Реальна робота щодо здійснення резервування відбувається при наявності хоча б однієї резервної станції у переліку станцій та передбачає:
Для контролю за часом, витраченим на виконання циклу обслуговування резервування, передбачено поле статусу. При наближені реального часу виконання до циклу завдання обслуговування резервування, рекомендується збільшити періодичність виконання цього завдання!
Для об'єкту контролера підсистеми "Збір Даних" передбачено режими резервування "Асиметричне" та "Тільки порушення". Асиметричне резервування працює з тією конфігурацією контролеру віддаленої станції, яка є і не намагається її узагальнювати. Для цього режиму працюють всі раніш описані функції та властивості резервування. Резервування "Тільки порушення" передбачає фактичну роботу без резервування, але з придушенням порушень від резервного об'єкту контролера з метою виключення дублювальних повідомлень про порушення.
Фактично всі джерела даних, які підтримуються OpenSCADA, у якості мітки часу оперативних-потокових даних використовують час комп'ютера де працює OpenSCADA та здійснюється опитування цих джерела даних, навіть у випадку можливості отримання часу серверу або джерела у джерела даних, і часто навіть у випадку коли таким джерелом виступає інша станція-ПЛК з OpenSCADA.
Такий підхід визначено з декількох причин, а саме:
Наразі відомо один метод, коли від мітки часу джерела даних є практична цінність, це робота з історією-архівом на боці джерела даних, коли за виявленням прогалин у даних, наприклад, на час відсутності зв'язку, замість поточних-оперативних даних запитується ділянка історії-архіву, що відповідає цій прогалині. Та цей метод реалізовано у модулі DAQ.DAQGate, при роботі OpenSCADA на боці джерела даних або ПЛК.
| Documents/DAQ/uk - GFDL | November 2024 | OpenSCADA 1+r2996 |