- Автор: Роман Савоченко
Збір даних SCADA(Supervisory Control and Data Acquisition)-системи є її невід'ємною частиною, яка займається отриманням даних із джерел різноманітного походження. Природа даних, з якими працює SCADA, характеризується сигналами базових типів значень (цілі, реальні, логічні та рядок). Сигнали змінюються у часі та мають історією — життя. У теорії управління технологічними процесами (ТП), під сигналом мається на увазі значення давача установки ТП у коді АЦП — "сирий" сигнал, або у реальному значені — інженерний. Сигнали можуть поєднуватися у групи за смисловим навантаженням, які часто називаються параметрами або комплексним тегом. Наприклад, розвинуті джерела даних можуть надавати структури параметрів із визначеним набором пов'язаних сигналів. Крім безпосередньо збору даних, до функції цього механізму також входить і передача дій на виконавчі пристрої управління ТП, зазвичай це: засувки, насоси та регулюючі клапани. Сукупно, це обладнання отримало назву — Пристрій Узгодження із Об'єктом (ПУО).
Джерела даних характеризуються великим розмаїттям, яке можна умовно поділити на три групи:
- Джерела "сирих" даних, які надають код АЦП або рівні дискретних сигналів, а також які включають простішу обробку. Зазвичай, це модулі розосередженого ПУО або простіші промислові програмовані логічні контролери (ПЛК).
- Потужні промислові ПЛК, що мають значні обчислювальні потужністю та можливості формування складних параметрів з різною структурою.
- Локальні або супутні джерела даних. Наприклад, ПУО у вигляді плат розширення, а також дані апаратного та програмного оточення в якому функціонує система.
Розмаїття джерел даних породило великий спектр механізмів доступу до них. Локальні джерела даних різняться інтерфейсами програмування додатку (API), а мережеві джерела, своєю чергою, транспортним та протокольним рівнями взаємодії. В цілому, це призвело до того, що додання підтримки нового джерела даних потребує створення модуля сполучення або драйверу. Враховуючи ж велике розмаїття джерел, це доволі затратно та фактично нереально охопити весь спектр ринку таких пристроїв. Ситуація дещо спрощується із мережевими джерелами, завдяки наявності низки стандартних та вільних протоколів взаємодії, однак багато джерел все-ж використовують власні протоколи: закриті комерційні або протоколи, зав'язані на закриті механізми комерційних операційних систем (ОС).
У термінах OpenSCADA, надаються наступні об'єкти моделі даних обслуговування механізму збору даних:
- "Атрибут" — об'єкт віддзеркалення даних сигналу, включає поточне значення визначеного типу сигналу та доступ до історії зміни цих значень;
- "Параметр" — об'єкт групи атрибутів зі структурою, відповідною до особливостей окремо взятого джерела даних;
- "Об'єкт контролеру" — об'єкт окремого джерела даних. Як правило це окремий модуль ПУО або пристрій промислового ПЛК.
Для врахування особливостей різних пристроїв збору даних, а також різних механізмів взаємодії, у OpenSCADA передбачено підсистему "Збір Даних", яка є модульною. У якості модуля підсистеми виступає драйвер сполучення із джерелом даних окремого типу. Кожний модуль може містити конфігурацію декількох пристроїв цього типу у вигляді об'єктів контролеру. Загальну схему об'єктів підсистеми "Збір даних" зображено на рисунку 1.
Contents
1 Методи збору даних
Враховуючи різні властивості джерел даних, а також можливі варіанти взаємодії, методи збору даних можна поділити на: простий синхронний, простий асинхронний, пакетний та пасивний.
У огляді механізмів нижче будуть приймати участь наступні об'єкти:
- "ObjectSCADA" — будь-який об'єкт SCADA-системи, який звертається за значенням сигналу, наприклад, архіви та візуалізатори;
- "DAQParamAttribute" — атрибут параметра підсистеми "Збір Даних", який виступає посередником у доступі до значень сигналу джерела даних;
- "DAQParamAttributeArch" — об'єкт архіву атрибута;
- "HardwarePLC" — об'єкт джерела даних, наприклад, модулі розосередженого ПУО або промислові ПЛК.
1.1 Простий синхронний механізм збору
Механізм характеризується запитами до джерела даних синхронно із запитом до атрибуту параметра (рис.2). Цей механізм, зазвичай, застосовується при роботі з локальними джерелами даних, які характеризуються низькою латентністю, тобто затримкою у відповіді на запит. За допомогою цього методу можна отримати актуальні дані безпосередньо із запитом, однак час запиту об'єкту буде включати час транспортування та обробки запиту джерелом даних.
Відповідно до діаграми вище, ми отримуємо наступну послідовність запитів отримання даних та їх передачі:
- об'єкт SCADA-системи надсилає запит значення до об'єкту атрибута параметра DAQParamAttribute::getVal();
- об'єкт атрибута параметру, отримавши запит, надсилає його джерелу даних HardwarePLC::valueRequest();
- джерело даних, обробивши запит, повертає результат;
- об'єкт атрибуту параметра, отримавши результат, повертає його об'єкту SCADA-системи.
У OpenSCADA такий механізм реалізують наступні модулі підсистеми "Збір Даних":
- JavaLikeCalc — обчислювач на Java-подібній мові високого рівня. У якості джерела даних виступає користувацька програма на Java-подібній мові. Атрибути параметрів модуля синхронно звертаються до входів/виходів обчислювального контексту користувацької функції.
- LogicLev — модуль логічного рівня параметрів збору даних, детальніше про нього у розділі 3. У якості джерела даних цього модуля виступають інші параметри підсистеми "Збір Даних" та контекст виконання шаблону параметрів. Атрибути параметрів модуля синхронно звертаються до атрибутів інших параметрів, у режимі віддзеркалення параметрів підсистеми "Збір Даних", або до входів/виходів контексту виконання шаблону, у режимі роботи за шаблоном.
- BlockCalc — обчислювач на мові блокових схем. У якості джерела даних виступає користувацька блокова схема. Атрибути параметрів модуля синхронно звертаються до входів/виходів блоків блокової схеми.
- DAQGate — модуль віддзеркалення об'єктів контролерів віддалених OpenSCADA-станцій на локальну. У модулі реалізовано синхронний режим запису даних.
- ModBus — модуль доступу до даних джерел за посередництвом сімейства протоколів "ModBus". У модулі реалізовано синхронний режим запису даних.
- DiamondBoards — модуль доступу до даних PC/104 плат фірми Diamond Systems. Плати PC/104 розташовуються на ISA-шині, відповідно є локальними та доступні порівняно швидко. У режимі збору даних не за перериванням, доступ до значень АЦП здійснюється синхронно. Режим запису значення ЦАП завжди працює синхронно.
1.2 Простий асинхронний механізм збору
Механізм характеризується запитами до джерела даних незалежно від запиту до атрибуту параметра (рис.3). Зазвичай, запити до джерела даних здійснюються періодично, у власному завдані опитування окремо взятого контролеру та блоками по декілька сигналів. При цьому, запитом до атрибуту параметра повертається значення, отримане останнім сеансом зв'язку із джерелом даних. Цей механізм зазвичай застосовується при роботі з віддаленими (мережевими) джерелами даних, які характеризуються високою латентністю, тобто затримкою у відповіді на запит.
За допомогою цього методу можна забезпечити оптимізацію часового ресурсу, витраченого на один сигнал, і тим самим збільшити максимальну кількість опитаних сигналів за інтервал часу опитування.
У якості показового прикладу розглянемо промисловий ПЛК "Siemens S7-315", при опитувані його по шині ProfiBus (1,5 Мбіт/с). Середній час обробки MPI-запиту цим контролером становить 30 мс. Якщо використовувати синхронний механізм для кожного сигналу, тобто один запит на кожний сигнал, то протягом однієї секунди ми зможемо отримати біля 33 сигналів. А якщо застосувати асинхронний механізм, тобто у одному MPI-пакеті отримувати до 220 байт або 110 сигналів цілочисельного типу на 16-розрядів, то ми зможемо за одну секунду отримати до 3630 сигналів. Як можна бачити, ефективність асинхронного механізму, у цьому випадку, складає 110 разів, а саме значення максимальної ємності MPI-пакету.
Недоліком асинхронного механізму є те, що запит значень атрибуту параметра повертає неактуальне на час запиту значення, а значення останнього сеансу опитування контролеру. Утім, якщо врахувати, що джерело даних може оновлюватися з періодичністю апаратних обмежень АЦП, та й самі давачі можуть мати певні обмеження у швидкості реакції, то й застосування асинхронного механізму збору може мати серйозні підстави.
Застосування асинхронного механізму для запису значень у ПЛК є доволі рідкісним явищем, оскільки запис значень зазвичай передбачає вплив оператора на ТП. Оператор, по факту, достатньо рідко вносить коригування у процес, відтак запис можна здійснювати синхронно. Однак, існують ситуації, наприклад, управління ТП регуляторами на SCADA-системі, яка виконує функції середовища виконання ПЛК.
Згідно до діаграми вище, ми отримуємо наступну картину:
- атрибут параметру, або вищестоящий об'єкт контролеру, виконує періодичні запити HardwarePLC::valueRequest() отримання значення сигналу або групи сигналів;
- отриманні значення сигналів розташовуються локально у атрибутах параметрів;
- об'єкт SCADA-системи надсилає запит значення до атрибута параметра DAQParamAttribute::getVal() та отримує збережене локально значення попереднього сеансу опитування джерела даних.
В OpenSCADA такий механізм реалізують наступні модулі підсистеми "Збір Даних":
- DAQGate — модуль віддзеркалення об'єктів контролерів віддалених OpenSCADA-станцій на локальну. В модулі реалізовано асинхронний режим читання даних.
- System — модуль доступу до даних оточення виконання OpenSCADA. У модулі реалізовано асинхронний режим читання даних.
- ModBus — модуль доступу до даних джерел за посередництвом сімейства протоколів "ModBus". У цьому модулі асинхронний режим реалізовано як для читання даних, так і для їх запису (опціонально) на ПЛК.
- SNMP — модуль доступу до даних пристроїв мережі за посередництвом "Simple Network Management Protocol". В модулі реалізовано асинхронний режим читання даних.
- Siemens — модуль доступу до даних контролерів фірми Siemens серії S7. У цьому модулі асинхронний режим реалізовано як для читання даних, так і для їх запису (опціонально) на ПЛК.
1.3 Пакетний механізм збору
Пакетний механізм збору характерний збором даних кожного сигналу пакетом, який включає історію його зміни. Тобто, за один сеанс опитування отримується декілька значень історії сигналу. Пакетний механізм працює спільно із синхронним та асинхронними механізмами.
У випадку роботи з синхронним механізмом, виконується фактичне перекидання архіву джерела даних для оперативної роботи у системі (рис. 2). Як і простий синхронний механізм, його бажано застосовувати тільки на низько-латентних джерелах даних або із джерелами, робота яких є сеансовою, наприклад, у сфері комерційного обліку для читання значень лічильників.
При роботі спільно із асинхронним механізмом, історія отриманих сигналів зазвичай прямо розташовується у архіви (рис. 4), а поточні значення атрибута параметру встановлюються у останнє значення пакету. Така комбінація ефективна при зборі швидких даних або при синхронізації архівів після втрати зв'язку з віддаленим джерелом даних.
Згідно діаграми вище, ми отримаємо наступну поведінку пакетного механізму при асинхронних запитах:
- атрибут параметру, або вищестоящий об'єкт контролера, здійснює періодичні запити HardwarePLC::valuesRequest() отримання пакетів значень сигналу або групи сигналів;
- отримані пакети значень сигналів розташовуються до архіву, запитом DAQParamAttributeArch::setValues(), а останнє значення пакетів розташовується у атрибут параметру;
- об'єкт SCADA-системи надсилає запит фрагменту архіву до атрибуту параметра DAQParamAttribute::getValues(), а той переспрямовує запит до архіву DAQParamAttributeArch::getValues(). У результаті, повертається фрагмент архіву, доступний після попереднього сеансу опитування джерела даних;
- об'єкт SCADA-системи надсилає запит останнього значення до об'єкту атрибута параметра DAQParamAttribute::getVal() та отримує збережене локальне значення попереднього сеансу опитування джерела даних.
У OpenSCADA такий механізм реалізують наступні модулі підсистеми "Збір Даних":
- DAQGate — модуль віддзеркалення об'єктів контролерів віддалених OpenSCADA-станцій на локальну. Реалізує синхронний та асинхронний пакетний режими віддзеркалення архівів віддалених OpenSCADA-станцій.
- DiamondBoards — модуль доступу до даних PC/104 плат фірми Diamond Systems. Плати PC/104 розташовуються на ISA-шині, відтак є локальними та доступні порівняно швидко. У режимі збору даних за перериванням здійснюється очікування пакетів швидких значень (до 200 кГц) за одну секунду (до 200000 значень у пакеті) та наступного розташування даних пакетів у архівах атрибутів параметрів DAQ.
1.4 Пасивний механізм збору та ініціативні підключення
Пасивний механізм збору характерний ініціативою надання даних до SCADA-системи із боку джерела даних. Цей механізм є достатньо рідкісним явищем, однак може мати місце за певних умов або обмежень у можливості використання прямих механізмів збору даних, рисунок 1.4a. Прикладом такої ситуації можуть слугувати географічно розосереджені системи збору даних за посередництвом мобільних мереж GPRS/EDGE/3G/4G/... . Наділення всіх вузлів окремими реальними та статичними IP-адресами, або формування корпоративної мобільної мережі, у таких мережах може виявитися дорогим задоволенням, тому доступніше виявляється ініціатива сеансу передачі даних із-за динамічних IP-адрес на одну реальну IP-адресу серверу SCADA-системи. Дії на модифікацію передаються джерелу даних в момент сеансу передачі даних джерелом — читання. Хоча тут можливі й типові запити через VPN підключення від джерела даних та функціювання через мережеву СУБД-посередника.
Згідно до діаграми вище, ми отримуємо наступну поведінку пасивного механізму:
- об'єкт джерела даних здійснює періодичні сеанси зв'язку із атрибутом параметру DAQParamAttributeArch::setVal() для передачі своїх даних та отримання команд дій;
- об'єкт SCADA-системи надсилає запит останнього значення атрибуту параметра DAQParamAttribute::getVal() та отримує збережене локально значення попереднього сеансу зв'язку джерела даних.
У випадку коли хост, що ініціює підключення, має динамічну адресу яка не є "сірою", тобто за нею можна підключитися прямо, тоді ініціативне підключення можна використовувати лише для отримання зворотної адреси, за якою прямо і підключатися, а у контролері таких підключень здійснювати лише оновляння динамічної адреси.
Окремим випадком є ініціатива встановлення TCP-підключення від джерела даних та подальше здійснення стандартних запитів за цим підключенням від сервера, що вхідні транспорти модуля "Сокети" і модуля "SSL" наразі підтримують. Цей режим наразі навіть найрозповсюдженіший!
OpenSCADA також сама підтримує ініціацію таких підключень, тобто може виступати у ролі джерела даних за "сірим" та динамічним IP. Так, вхідний транспорт модуля "Сокети" і модуля "SSL" у режимі 2 виступає ініціатором підключення, після чого надсилає ідентифікуючу послідовність та переходить у звичайний режим отримання запитів від хосту, до якого під'єднався. Щодо чого наразі особливо корисним є віддалений контроль OpenSCADA станцій у сірих мережах за такого підключення.
2 Віртуальні джерела даних
Крім збору фізичних даних, актуальною є функція віртуального збору даних. Віртуальні дані представляють собою дані, отримані всередині системи як незалежно, так і на основі фізичних даних. Практично, механізми формування віртуальних даних реалізуються разом з механізмом користувацьких обчислень. В середині промислових контролерів та SCADA-систем використовуються різні мови програмування. У випадку з контролерами, у якості таких мов часто використовуються мови низького рівня (асемблери), однак, останнім часом, все частіш використовуються мови високого рівня (C, Pascal та інші), а також формальні мови IEC 61131-3 (схеми потоків станів SFC, блокові схеми FBD, релейні схеми LD та текстові ST, IL). У випадку із SCADA-системами, обчислювання частіше забезпечуються мовами програмування високого рівня та формальними мовами.
У OpenSCADA можуть бути реалізовані інтерфейси програмування та віртуальних джерел даних на основі різних мов, у окремих модулях підсистеми "Збір Даних". На поточний час доступні модулі віртуальних обчислювачів:
- Обчислювач на Java-подібній мові: JavaLikeCalc;
- Блоковий обчислювач: BlockCalc.
До ядра OpenSCADA інтегровано механізм користувацьких функцій або API користувацького програмування. Користувацькі функції можуть надаватися будь яким об'єктом програми, в тому числі й модулями, відповідно до власної функціональності, тим самим надаючи користувачу деякий набір функцій контролю за тим або іншим об'єктом. Функції користувацького API можуть бути як статичними, тобто ті що реалізують фіксовану функціональність окремого об'єкту, так і динамічними, тобто ті що формуються користувачем під потрібне йому завдання на внутрішній мові користувацького програмування високого рівня.
Модуль JavaLikeCalc надає до OpenSCADA механізм створення динамічних користувацьких функцій та їх бібліотек на Java-подібній мові. Опис функції на Java-подібній мові полягає у обв'язки параметрів функції алгоритмом. Крім цього, модуль наділено функціями безпосередніх обчислень, шляхом створення обчислювальних контролерів із асоційованою обчислювальною функцією. Модулем надається механізм прекомпіляції контекстно-залежних функцій, що використовується для вбудовування користувацьких алгоритмів безпосередньо до контексту різних компонентів OpenSCADA, це, наприклад, шаблони параметрів підсистеми "Збір Даних" та рушій Середовища Візуалізації та Управління (СВУ).
Модуль BlockCalc надає до OpenSCADA механізм створення користувацьких обчислень, що ґрунтується на формальній мові блокових схем. Мови блокового програмування ґрунтуються на понятті блокових схем та функціональних блоків. Причому, залежно від сутності блоку, блокові схеми можуть бути: логічними схемами, схемами релейної логіки, моделлю технологічного процесу та інше. Сутність блокової схеми полягає в тому, що вона містить перелік блоків та зв'язки між ними. З формальної точки зору блок — це елемент (функція), яка має входи, виходи та алгоритм обчислення. Виходячи із концепції середовища програмування, блок — це кадр значень, асоційований з об'єктом функції. Входи та виходи блоків треба поєднувати для отримання цільної блокової схеми.
З метою наповнення API користувацького програмування функціями, створені наступні спеціалізовані модулі статичних функцій API користувацького програмування:
- Бібліотека функцій системного API: FLibSYS;
- Бібліотека стандартних математичних функцій: FLibMath;
- Бібліотека функцій сумісності зі SCADA Complex1: FLibComplex1.
3 Логічний рівень обробки даних
Вище ми відзначали, що тип джерела даних може коливатися від "сирого" до комплексного. Під "сирим" мається на увазі джерело, яке надає тільки елементарні сигнали (цілі, реальні, логічні, рядок, ...), до того ж окремо. Під комплексним мається на увазі джерело, яке групує сигнали та, в параметрі підсистеми "Збір Даних", надає атрибути додаткового призначення, які покривають практично всі діагностичні завдання, тобто параметр є закінченим об'єктом, який не потребує доповнення.
Враховуючи таку розбіжність, може виникнути ситуація, коли інформації у параметру контролера від джерела даних недостатньо для опису реального об'єкту ТП загалом та потрібен довільний об'єкт більш високого рівня абстракції. Вирішенням цієї ситуації може бути формування додаткових параметрів, що є ненаглядним та вносить плутанину. Більш правильним рішенням є використання прошарку "Логічного рівня", який виконує функцію гнучкого формування параметрів-контейнерів сигналів потрібної структури та що включає пост-обробку.
Функціонально, "Логічний рівень" призначено для надання у OpenSCADA механізму вільного формування параметрів-контейнерів сигналів потрібної структури.
Експлуатаційним призначенням "Логічного рівня" є:
- розширення сфери застосування OpenSCADA за рахунок збільшення гнучкості опису параметрів підсистеми "Збір Даних";
- скорочення трудовитрат на створення складних автоматизованих систем.
Концепцію "Логічного рівня" засновано на шаблонах параметрів, для яких, у підсистемі "Збір Даних", передбачено контейнер бібліотек шаблонів (рис.1). Кожна бібліотека містить шаблони параметрів, які можуть використовуватися модулями підсистеми "Збір Даних" для реалізації параметрів на основі шаблонів. Модулями OpenSCADA, які використовують шаблони у своїй роботі, є:
- LogicLev — модуль реалізації класичної концепції "Логічного рівня".
- ModBus — модуль доступу до даних джерел за посередництвом сімейства протоколів "ModBus". Крім типу параметру прямого опису переліку регістрів, модуль підтримує і логічний тип, де регістри "ModBus" описуються у зв'язках шаблону.
- Siemens — модуль збору даних контролерів фірми Siemens серії S7. Завдяки високій гнучкості та функціональності контролерів цієї серії, що дозволяє формувати комплексні типи даних різноманітної структури, всі параметри цього модуля працюють за шаблонами.
- OPC-UA — модуль доступу до даних джерел за посередництвом протоколу "OPC-UA". Крім типу параметру прямого опису переліку вузлів, модуль підтримує і логічний тип, де вузли "OPC-UA" описуються у зв'язках шаблону.
Загальний механізм роботи "Логічного рівня", на прикладі модуля LogicLev, зображено на рисунку 7.
Виходячи із цього зображення видно, що параметри контролеру логічного рівня виконують функцію віддзеркалення інших параметрів підсистеми "Збір Даних" (на прикладі параметрів 1 та 4) та довільне формування параметрів на основі шаблонів 1, 2 та інших параметрів підсистеми "Збір Даних" (на прикладі параметрів 2, 3 та 5).
Структура параметрів з шаблоном в основі має структуру, зображену на рисунку 8.
Як можна бачити із структури, параметр логічного рівня складається із об'єкту функції, атрибутів та конфігурації шаблону. Об'єкт функції це екземпляр виконання функції шаблону з набором входів/виходів та програмою обчислення шаблону на одній із мов користувацького програмування, зазвичай це Java-подібна мова користувацького програмування модуля JavaLikeCalc. Утім, шаблон може бути взагалі без програми, надаючи тільки структуру перекидання входів/виходів. Атрибути у структурі зображують перелік атрибутів результуючого параметру відповідно до шаблону. Конфігурація у структурі надає конфігурацію властивостей шаблону та його зовнішніх зв'язків.
Логіку роботи логічного рівня параметрів можна записати наступним чином:
- Параметр зв'язується з шаблоном, із якого отримується структура атрибутів, відповідно до функції шаблону.
- Виконується зв'язування об'єкту функції параметру з функцією із шаблону.
- Формується структура зв'язків відповідно до шаблону функції. Виходячи із структури зв'язків формується форма зв'язування параметру та користувачем встановлюються зв'язки.
- При доступі до атрибутів отриманого параметра здійснюється перевірка на наявність прямого зв'язку. У випадку наявності прямого зв'язку, запит переспрямовується за цим зв'язком, інакше, значення береться із об'єкту функції параметру.
- Паралельно працює обчислювання функції шаблону за об'єктом функції параметрів. При цьому, перед обчисленням здійснюється читання значень за зв'язками, а після обчислення запис змін за цими зв'язками.
Шаблон параметрів, загалом, надає наступне:
- структуру входів/виходів функції шаблону;
- ознаки конфігурації та зв'язування шаблона (константа, зв'язок);
- попередні значення конфігурації постійних та шаблону зв'язків;
- ознаки атрибутів результуючого параметру логічного рівня, типів: не атрибут, атрибут з повним доступом, атрибут з доступом тільки на читання;
- механізм обчислення входів/виходів функції шаблонів мовою користувацького програмування OpenSCADA.
На рисунку 9 наведено зображення вкладки конфігурації шаблону параметрів підсистеми "Збір Даних" у вигляді таблиці з конфігурацією входів/виходів та тексту програми користувацького програмування.
Вкладкою входи/виходи "ВВ" шаблону параметрів передбачено наступні властивості спеціалізованого призначення: "Атрибут", "Конфігурація" та "Значення".
Властивість "Атрибут" виступає ознакою віддзеркалення входу/виходу шаблону на результуючий атрибут параметра. Передбачено наступні варіанти цієї властивості:
- Не атрибут — вхід/вихід функції шаблону не віддзеркалюється на атрибут;
- Тільки читання — вхід/вихід функції шаблону віддзеркалюється на атрибут з доступом тільки на читання;
- Повний доступ — вхід/вихід функції шаблону віддзеркалюється на атрибут з повним доступом.
Властивість "Конфігурація" виступає ознакою, яка вказує на використання входу/виходу функції шаблону в результуючій конфігурації шаблону на логічному рівні. Передбачено наступні варіанти цієї властивості:
- Змінна — доступний для доступу та контролю тільки з процедури шаблона, як змінна, яка зберігається із контекстом параметру логічного рівня;
- Константа — доступний для встановлення на рівні параметра логічного рівня, у вигляді постійної розділу конфігурації шаблону;
- Зв'язок — доступний для встановлення на рівні параметру логічного рівня, у вигляді зв'язку розділу конфігурації шаблону.
Поле "Значення" описує передвстановлене значення постійних та шаблонів зовнішніх зв'язків. Шаблон зовнішніх зв'язків використовується з метою описання механізму групування та автоматичного розподілу зовнішніх зв'язків. Структура шаблону зовнішніх зв'язків однакова у частині підключення до атрибутів параметрів підсистеми "Збір даних" та розширюється специфічним форматом адреси окремого модуля підсистеми "Збору даних", який використовує механізм шаблонів. Підключення до параметрів підсистеми "Збір даних" — шаблон конфігурації зовнішнього зв'язку має вигляд {Параметр}|{атрибут}, де:
- Параметр — використовується для об'єднання атрибутів та розташування на формі конфігурації;
- атрибут — для асоціативного зв'язування атрибутів при призначені параметру.
Саме подальше зв'язування загалом може здійснюватися:
- загальним визначенням-обранням адреси-атрибуту параметру підсистеми "Збір даних"; наприклад, зв'язок "LogicLev.experiment.Pi.var" або "prm:/LogicLev/experiment/Pi/var" здійснює доступ атрибуту параметру до іншого атрибуту параметра; знак "(+)" у кінці адреси вказує на вдале зв'язування та присутність цільового об'єкту; для атрибутів об'єктного типу допустимий ієрархічний доступ до конкретної властивості об'єкту шляхом вказання її шляху через символ '#', наприклад: "LogicLev.experiment.Pi.var#pr1.pr2" або "prm:/LogicLev/experiment/Pi/var#pr1.pr2"; у шляху із префіксом "prm:" ви можете використовувати елементи відносності "." та "..";
- визначенням специфічної адреси окремого модуля підсистеми "Збір даних";
- прямим встановленням постійного значення у форматі "val:Стале значення";
- порожньою або помилковою адресою, коли значення за зв'язком встановлюється у EVAL.
У якості прикладу використання шаблону, на рисунку 10 наведено зображення параметру "F3" модуля логічного рівня, де представлено вкладку "Конфігурація шаблона" для конфігурації шаблону параметру, включаючи зв'язування. На рисунку 11 представлено вкладку "Атрибути" з переліком атрибутів та їх значень, створених за посередництвом шаблону.
3.1 Концепція доступу до даних через користувацький протокол
Наступним рівнем, заснованим на Логічному Рівні, є концепція доступу до даних через користувацький протокол, що реалізується або прямо у коді шаблону або як окремий об'єкт Користувацького Протоколу у модулі Protocol.UserProtocol, де наразі також можна використовувати DAQ-шаблони.
Концепцію доступу до даних через користувацький протокол можна зобразити як на рисунку 1.
Як можна бачити з рисунку 1, взаємодія з пристроєм відбувається через деякий транспорт на якому вони фізично базуються. Запит до транспорту Ви можете надіслати:
- Безпосередньо за допомогою функції системного API OpenSCADA об'єкту транспорту string messIO( string mess, real timeOut = 0 );, якщо протоколоспецифічна частина дуже проста та дані вам потрібно лише вилучити.
- Загорнутий запит даних req, функцією int messIO( XMLNodeObj req, string prt ); та для протоколу prt, якщо протокольна частина достатньо складна та вже представлена у OpenSCADA.
- Загорнутий запит даних специфічний до користувача за допомогою функції int messIO( XMLNodeObj req, "UserProtocol" ); та реалізації користувацького протоколу, якщо протокольна частина достатньо складна та ще відсутня у OpenSCADA. Користувач реалізує тут саму протоколоспецифічну частину у модулі UserProtocol та частину специфічну до даних у шаблоні для модуля Логічного Рівня або безпосередньо у процедурі контролеру на внутрішній мові програмування модуля JavaLikeCalc.
-
Цей останній метод наразі розвинено до можливості формування протокольної частини коду безпосередньо у тому-ж коді шаблону, як окрема вбудована функція через виклик функції запиту першого методу, якщо немає потреби повторного використання, або навіть якщо така потреба є та тут має сенс створення комплексного шаблону, який зможе поєднувати роль й вихідного протоколу, через його підключення також до модуля користувацького протоколу. Та воно буде повністю зберігатися у одній бібліотеці шаблонів.
-
Пряма робота із вихідним транспортом функції string messIO( string mess, real timeOut = 0 ); не передбачає блокування транспорту поза викликом цієї функції, а відтак, для складних протоколів із посилками відповіді більш ніж у одному пакеті, що передбачає процес "доочікування", не можна використовувати спільний транспорт, за яким можливе надсилання пакетів різних протоколів або навіть один, але з різних завдань (об'єктів контролерів). Відтак, якщо є потреба використання спільного транспорту, то розташовуйте параметри опитування за протоколом у одному об'єкті контролеру (завдані) або використовуйте модуль користувацького протоколу, до якого це зауваження не має стосунку, оскільки він здійснює таке блокування на час виклику процедури обробки, як і решта модульних протоколів OpenSCADA.
Створено наступні бібліотеки з використанням концепції доступу до даних через користувацький протокол:
4 Резервування джерел даних
Резервування загалом, та джерел даних зокрема, слугує для підвищення загального рівня відмовостійкості рішення шляхом включення дублювальних вузлів до спільної роботи з основним вузлом. У випадку відмови основного вузла відбувається підхоплення функцій основного вузла резервним. Часто, схема резервування може працювати і у режимі розподілу навантаження між вузлами, що спільно працюють.
У випадку з підсистемою "Збір Даних", резервування даних (рис.12) виконує функції:
- Резервування механізму збору даних. Зазвичай ця функція реалізується без особливих механізмів, шляхом простого запуску паралельних резервних станцій з однаковою конфігурацією та працюючих незалежно. Однак, у випадку виконання станцією функції ПЛК, така поведінка недозволена з причини одночасної видачі керуючих дій та відсутності синхронізації даних обчислювачів.
- Компенсація втрати даних на час недоступності вузла за рахунок архіву резервного. Передбачено два механізми компенсації. Перший та основний механізм здійснює завантаження ділянок архіву з резервної станції під час запуску станції загалом або окремих об'єктів контролерів. Ділянка архіву запитується з моменту останнього запису у локальному архіві та по поточний час. Глибина запиту, при цьому, обмежується визначенням граничного часу в конфігурації резервування. Другий, доповнюючий механізм, здійснює заповнення "дірок" у архіві значень, під час фактичного запиту користувача до цих даних. Такий підхід, з одного боку, дозволяє здійснити прогнозовану за часом синхронізацію при старті, а з іншого боку, фактично виключає втрату даних при умові роботи хоча б однієї станції на протязі всього робочого часу.
- Розподіл навантаження по збору даних між вузлами. При створені складних розподілених систем може виявитися важливим питання прогнозування та оптимізації загальної продуктивності системи. Враховуючи такі завдання, механізм резервування передбачає виконання завдань збору даних окремих джерел (об'єктів контролерів OpenSCADA) тільки на одній станції. При цьому, завдання решти станцій переходять в режим синхронізації даних зі станцією, що виконується. У випадку втрати зв'язку зі станцією, що виконується, запускається завдання локального збору даних. Передбачено, також, можливість оптимального розподілу навантаження виконання задач збору даних групи об'єктів контролерів, між станціями.
- Оптимізація навантаження на зовнішні джерела даних за рахунок запиту (обміну) даних у зовнішнього джерела тільки одним вузлом. На практиці часто зустрічаються високо-навантажені джерела даних, або інтерфейси доступу до джерел даних, для яких навіть збір даних однією станцією може бути проблемою і вимагатиме зниження періодичності збору, тобто якості даних. Механізм резервування, крім розподілу навантаження між станціями за описаною вище схемою, дозволяє зняти додаткове навантаження на джерело даних та його інтерфейси, тим самим підвищивши якість даних. Запис до атрибуту резервного об'єкту контролеру призводить до відправки запиту модифікації на основний, тобто — через основний.
- Запобігання деякої різниці даних на різних вузлах, пов'язане з незбігом моментів часу при незалежному зборі даних окремими вузлами, здійснюється шляхом отримання даних зі станції з активним об'єктом контролера. У системах високої звітності з резервуванням має бути виключено, або зведено до мінімуму, розходження у даних на різних станціях, що передбачає реальний збір даних однією станцією та синхронізацію з цими даними інших станцій.
Резервування рекомендується налаштовувати таким чином щоб БД резервних станцій зберігалися однаковими, що надалі дозволить безболісно копіювати їх, при відновленні, на будь яку станцію та, відповідно, у резервній копії можна зберігати тільки один набір БД. При цьому, налаштування, специфічні до окремої станції, будуть зберігатися у конфігураційному файлі та можна буде легко конфігурувати та міняти потрібну станцію через вибір відповідного конфігураційного файлу.
Налаштування резервування починається з додання резервних станцій до переліку станцій OpenSCADA на вкладці "Підсистема" підсистеми "Транспорти" (Рис.13). Причому додавати тут потрібно не лише резервні станції до поточної, але й саму цю поточну станцію з її зовнішньою адресою, тобто своєрідна петля. Надалі ці налаштування будуть збережені до загальної БД резервованої системи та сама БД з цього моменту буде використовуватися при створені всіх резервних станцій. Відповідно, важливо на цьому етапі внести всі потрібні зміни до загальної БД довкола проекту в цілому!
Далі, на конкретній станції з копією загальної БД, налаштовуємо її специфічні параметри у вкладці "Резервування" головної сторінки (рис.14), які будуть збережені у конфігураційному файлі.
Після цього вся конфігурація резервування здійснюється у вкладці "Резервування" підсистеми "Збір даних" (Рис.15). Якщо встановити параметр "Передача локальних первинних команд" (Рис.14) то ця конфігурація, як і будь яка інша загального характеру, може здійснюватися на одній з станцій, а внесенні зміни потраплять на всі резервні, звісно якщо вони будуть доступні.
Завдання обслуговування механізму резервування запускається завжди та виконується з періодичністю, встановленою у відповідному конфігураційному полі. Реальна робота щодо здійснення резервування відбувається при наявності хоча б однієї резервної станції у переліку станцій та передбачає:
- Контроль за з'єднанням із зовнішніми станціями. В процесі контролю здійснюються запити до віддалених станцій, за оновленням інформації про них та перевірки зв'язку. У випадку втрати зв'язку із станцією, повтор підключення до неї здійснюється через проміжок часу, вказаний у конфігураційному полі інтервалу часу відновлення підключення. У полі "Живий", станції, відображається поточний стан зв'язку. У полі "Лічильник" представлено кількість запитів, здійснених до віддаленої станції, або ж час, який залишився до здійснення наступної спроби підключення із втраченою станцією.
- Локальне планування виконання об'єктів контролерів у резерві. Планування здійснюється відповідно до рівня станцій та вподобанням виконання об'єктів контролерів.
- Виклик функції синхронізації даних локальних об'єктів контролерів, працюючих у режимі синхронізації даних із зовнішніх станцій.
Для контролю за часом, витраченим на виконання циклу обслуговування резервування, передбачено поле статусу. При наближені реального часу виконання до циклу завдання обслуговування резервування, рекомендується збільшити періодичність виконання цього завдання!
Для об'єкту контролера підсистеми "Збір Даних" передбачено режими резервування "Асиметричне" та "Тільки порушення". Асиметричне резервування працює з тією конфігурацією контролеру віддаленої станції, яка є і не намагається її узагальнювати. Для цього режиму працюють всі раніш описані функції та властивості резервування. Резервування "Тільки порушення" передбачає фактичну роботу без резервування, але з придушенням порушень від резервного об'єкту контролера з метою виключення дублювальних повідомлень про порушення.
5 Мітка часу джерела даних
Фактично всі джерела даних, які підтримуються OpenSCADA, у якості мітки часу оперативних-потокових даних використовують час комп'ютера де працює OpenSCADA та здійснюється опитування цих джерела даних, навіть у випадку можливості отримання часу серверу або джерела у джерела даних, і часто навіть у випадку коли таким джерелом виступає інша станція-ПЛК з OpenSCADA.
Такий підхід визначено з декількох причин, а саме:
- розрізнення та виокремлення відмінності часу оперативних значень джерела даних та ПК збору даних не має жодної практичної мети окрім діагностичної з виявлення самого розходження часу, оскільки поточні дані архівуються у архів періодичних значень, де мітка часу так чи інакше притягується та округляється до цієї періодичності, тобто частина часу точніша за період даних архіву втрачається;
- рідко яке джерело даних взагалі має годинник реального часу, а коли і має то до нього одразу ставиться вимога синхронізації часу із зовнішнім джерелом зразкового часу, що у свою чергу вимагає вирішення складнощів із прямим підключенням GPS приймача або доступом до NTP-серверу у інтернет або локальній мережі; за визначеним-же підходом зразковим часом стає час ПК збору даних, навіть коли він сам не синхронізований, оскільки він один;
- мітка часу джерела даних може змінюватися з власною періодичністю або це оновлення взагалі може бути аперіодичним, що у випадку використання цієї мітки при опитувані призведе до прогалин у архіві, та навіть коли періодичності опитування-архівування та оновлення мітки часу джерела однакові такі прогалини будуть мати місце через відсутність синхронності, що доведеться компенсувати зменшенням періодичності опитування та, відповідно, збільшенням навантаження на мережу та джерело; відтак це зробить архів мало корисним, хоча наразі і надається можливість вважати такі прогалини (прохідні) не фактом відсутності або помилковістю даних.
Наразі відомо один метод, коли від мітки часу джерела даних є практична цінність, це робота з історією-архівом на боці джерела даних, коли за виявленням прогалин у даних, наприклад, на час відсутності зв'язку, замість поточних-оперативних даних запитується ділянка історії-архіву, що відповідає цій прогалині. Та цей метод реалізовано у модулі DAQ.DAQGate, при роботі OpenSCADA на боці джерела даних або ПЛК.
6 Посилання
- Діаграма: Ієрархічна структура підсистеми "Збір даних".
- UML: Діаграми послідовності підсистеми "Збір Даних".
- Діаграма: Ініціативне підключення Джерел Даних.
- Діаграма: Механізм роботи "Логічного рівня" на прикладі модуля LogicLev.
- Діаграма: Структура параметру логічного рівня.
- Діаграма: Загальна структура компонентів середовища програмування.
- Діаграма: Концепція доступу до даних через користувацький протокол.
- Діаграма: Горизонтальне та вертикальне резервування.