English
Российский

---

Сторінку заморожено, актуальна тут.

---

1793

Збір даних у OpenSCADA

Автор: Роман Савоченко

Вступ

Збір даних SCADA(Supervisory Control and Data Acquisition)-системи є її невід'ємною частиною, яка займається отриманням даних із джерел різноманітного походження. Природа даних, з якими працює SCADA, характеризується сигналами базових типів значень (цілі, реальні, логічні та рядок). Сигнали змінюються у часі та мають історією, життя. У теорії управління технологічними процесами (ТП) під сигналом мається на увазі значення давача установки ТП у коді АЦП, "сирий" сигнал або у реальному значені. Сигнали можуть поєднуватися у групи за смисловим навантаженням, які часто називаються параметрами. Наприклад, розвинуті джерела даних можуть надавати структури параметрів із визначеним набором пов'язаних сигналів. Крім безпосередньо збору даних до функції цього механізму також входить і передача дій на виконавчі пристрої управління ТП; зазвичай це засувки, насоси та регулюючі клапани. Сукупно це обладнання отримало назву Пристрій Сполучення із Об'єктом (ПСО).

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

• Джерела "сирих" даних, які надають код АЦП або рівні дискретних сигналів, а також які включають простішу обробку. Зазвичай це модулі розосередженого ПСО або простіші промислові програмовані логічні контролери (ПЛК).
• Потужні промислові ПЛК, що мають значні обчислювальні потужністю та можливості формування складних параметрів з різною структурою.
• Локальні або супутні джерела даних. Наприклад, ПСО у вигляді плат розширення, а також дані апаратного та програмного оточення, в якому функціонує система.

Розмаїття джерел даних породило великий спектр механізмів доступу до них. Локальні джерела даних різняться інтерфейсами програмування додатку (API), а мережеві джерела, своєю чергою, транспортним та протокольним рівнями взаємодії. В цілому це призвело до того, що додання підтримки нового джерела даних потребує створення модуля сполучення або драйверу. Враховуючи ж велике розмаїття джерел, це доволі затратно та фактично нереально охопити весь спектр ринку таких пристроїв. Ситуація дещо спрощується із мережевими джерелами завдяки наявності низки стандартних та вільних протоколів взаємодії, однак багато джерел все-ж використовують власні протоколи: закриті комерційні або протоколи, зав'язані на закриті механізми обмеженого кола комерційних операційних систем (ОС).

У термінах системи OpenSCADA надаються наступні об'єкти для обслуговування механізму збору даних:

• "Атрибут" — об'єкт відображення даних сигналу, включає поточне значення з типом сигналу та історію зміни значень;
• "Параметр" — об'єкт групи атрибутів (сигналів) зі структурою, відповідною до особливостей окремо взятого джерела даних;
• "Контролер" — об'єкт окремого джерела даних. Як правило, це окремий модуль ПСО або пристрій промислового ПЛК.

Для врахування особливостей різних пристроїв збору даних, а також різних механізмів взаємодії у OpenSCADA передбачено підсистему "Збір Даних", яка є модульною. У якості модуля підсистеми виступає драйвер для сполучення із джерелом даних окремого типу. Кожний модуль може містити конфігурацію декількох пристроїв цього типу у вигляді об'єктів "Контролер" системи OpenSCADA. Загальну схему об'єктів підсистеми "Збір даних" зображено на рисунку 1.

Рис. 1. Схема підсистеми "Збір Даних".

1. Методи збору даних

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

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

• "ObjectSCADA" — будь-який об'єкт SCADA-системи, який звертається за значенням сигналу; наприклад, архіви та візуалізатори;
• "DAQParamAttribute" — атрибут параметра підсистеми "Збір Даних", який виступає посередником у доступі до значень сигналу джерела даних;
• "DAQParamAttributeArch" — об'єкт архіву атрибута;
• "HardwarePLC" — об'єкт джерела даних, наприклад, модулі розосередженого ПСО або промислові ПЛК.

1.1. Простий синхронний механізм збору

Механізм характеризується запитами до джерела даних синхронно із запитом до атрибуту параметра (рис.2). Цей механізм зазвичай застосовується при роботі з локальними джерелами даних, які характеризуються низькою латентністю, тобто затримкою у відповіді на запит. За допомогою цього методу можна отримати актуальні дані безпосередньо із запитом, однак час запиту об'єкту буде включати час транспортування та обробки запиту джерелом даних.

Рис. 2. Діаграма послідовності взаємодії при синхронних запитах.

У відповідності із діаграмою вище ми отримуємо наступну послідовність запитів отримання даних та їх передачі:

• об'єкт SCADA-системи надсилає запит значення до об'єкту атрибута параметра DAQParamAttribute::getVal();
• об'єкт атрибута параметру, отримавши запит, надсилає його джерелу даних HardwarePLC::valueRequest();
• джерело даних, обробивши запит, повертає результат;
• об'єкт атрибуту параметра, отримавши результат, повертає його об'єкту SCADA-системи.

У OpenSCADA такий механізм реалізують наступні модулі підсистеми "Збір Даних".

• ModBus — модуль доступу до даних джерел за посередництвом сімейства протоколів "ModBus". У модулі реалізовано синхронний режим для запису даних.
• DiamondBoards — модуль доступу до даних PC/104 плат фірми Diamond Systems. Плати PC/104 розташовуються на ISA-шині, відповідно є локальними та доступні порівняно швидко. У режимі збору даних не за перериванням доступ до значень АЦП здійснюється синхронно. Режим запису значення ЦАП завжди працює синхронно.
• DAQGate — модуль відображення об'єктів контролерів віддалених на локальну. У модулі реалізовано синхронний режим для запису даних.
• BlockCalc — обчислювач на мові блокових схем. У Якості джерела даних у ньому виступає користувацька блокова схема. Атрибути параметрів модуля синхронно звертаються до входів/виходів блоків блокової схеми.
• JavaLikeCalc — обчислювач на Java-подібній мові високого рівня. У якості джерела даних в ньому виступає користувацька програма на Java-подібній мові. Атрибути параметрів модуля синхронно звертаються до входів/виходів користувацької обчислювальної функції.
• LogicLev EN RU — модуль логічного рівня параметрів збору даних, детальніше про нього у розділі 3. У якості джерела даних цього модуля виступають інші параметри підсистеми "Збір Даних" та контекст виконання шаблону параметрів. Атрибути параметрів модуля синхронно звертаються до атрибутів інших параметрів у режимі відображення параметрів підсистеми "Збір Даних" або до входів/виходів контексту виконання шаблону у режимі роботи за шаблоном.

1.2. Простий асинхронний механізм збору

Механізм характеризується запитами до джерела даних незалежно від запиту до атрибуту параметра (рис.3). Зазвичай запити до джерела даних здійснюються періодично у власному завдані опитування окремо взятого контролеру та блоками по декілька сигналів. При цьому запитом до атрибуту параметра повертається значення, отримане останнім сеансом зв'язку із джерелом даних. Цей механізм зазвичай застосовується при роботі з віддаленими (мережевими) джерелами даних, які характеризуються високою латентністю, тобто затримкою у відповіді на запит.

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

У якості прикладу розглянемо промисловий ПЛК Siemens S7-315 при опитувані його по шині ProfiBus (1,5 Мбіт/с). Середній час обробки MPI-запиту цим контролером становить 30 мс. Якщо використовувати синхронний механізм для кожного сигналу, тобто один запит на кожний сигнал, то протягом однієї секунди ми зможемо отримати біля 33 сигналів. А якщо застосувати асинхронний механізм, тобто у одному MPI-пакеті отримувати до 220 байт або 110 сигналів цілочисельного типу на 16-розрядів, то ми зможемо за одну секунду отримати до 3630 сигналів. Як можна бачити, ефективність асинхронного механізму у цьому випадку складає 110 разів, а саме значення максимальної ємності MPI-пакету.

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

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

Рис. 3. Діаграма послідовності взаємодії при асинхронних запитах.

У відповідності з діаграмою вище ми отримуємо наступну картину:

• об'єкт атрибута параметра (або вищестоящий об'єкт контролеру) виконує періодичні запити HardwarePLC::valueRequest() для отримання значення сигналу або групи сигналів;
• отриманні значення сигналів розташовуються у об'єктах атрибутів параметрів локально;
• об'єкт SCADA-системи надсилає запит значення до об'єкту атрибута параметра DAQParamAttribute::getVal() та отримує збережене локально значення попереднього сеансу опитування джерела даних.

В OpenSCADA такий механізм реалізують наступні модулі підсистеми "Збір Даних".

• Siemens — модуль доступу до даних контролерів фірми Siemens серії S7. У цьому модулі асинхронний режим реалізовано як для читання даних, так і для їх запису (опціонально) на ПЛК.
• ModBus — модуль доступу до даних джерел за посередництвом сімейства протоколів "ModBus". У цьому модулі асинхронний режим реалізовано як для читання даних, так і для їх запису (опціонально) на ПЛК.
• SNMP EN RU — модуль доступу до даних пристроїв мережі за посередництвом "Simple Network Management Protocol". В модулі реалізовано асинхронний режим читання даних.
• System — модуль доступу до даних оточення виконання OpenSCADA. У модулі реалізовано асинхронний режим читання даних.
• DAQGate — модуль відображення об'єктів контролерів віддалених на локальну. В модулі реалізовано асинхронний режим читання даних.

1.3. Пакетний механізм збору

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

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

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

Рис. 4. Діаграма послідовності взаємодії при асинхронних запитах пакетного механізму.

У відповідності з діаграмою вище ми отримаємо наступну поведінку пакетного механізму при асинхронних запитах:

• об'єкт атрибуту параметра або вищестоящий об'єкт контролера виконує періодичні запити HardwarePLC::valuesRequest() для отримання пакетів значень сигналу або групи сигналів;
• отримані пакети значень сигналів розташовуються до архів запитом DAQParamAttributeArch::setValues(), а останнє значення пакетів розташовується у об'єктах атрибутів параметрів;
• об'єкт SCADA-системи надсилає запит фрагменту архіву до об'єкту атрибута параметра DAQParamAttribute::getValues(), а той переспрямовує запит до архіву DAQParamAttributeArch::getValues(). В результаті повертається фрагмент архіву, доступний після попереднього сеансу опитування джерела даних;
• об'єкт SCADA-системи надсилає запит останнього значення до об'єкту атрибута параметра DAQParamAttribute::getVal() та отримує збережене локальне значення попереднього сеансу опитування джерела даних.

В OpenSCADA такий механізм реалізують наступні модулі підсистеми "Збір Даних".

• DiamondBoards — модуль доступу до даних PC/104 плат фірми Diamond Systems. Плати PC/104 розташовуються на ISA-шині, відтак є локальними та доступні порівняно швидко. В режимі збору даних за перериванням здійснюється очікування пакетів швидких значень (до 200 кГц) за одну секунду (до 200000 значень у пакеті) та наступного розташування даних пакетів у архівах атрибутів параметрів DAQ.
• DAQGate — модуль відображення об'єктів контролерів віддалених на локальну. Реалізує синхронний та асинхронний пакетний режими відображення архівів віддалених

1.4. Пасивний механізм збору

Пасивний механізм збору даних характерний ініціативою надання даних в SCADA-систему із боку джерела даних. Цей механізм є достатньо рідкісним явищем, однак може мати місце у випадку певних умов або обмежень у можливості використання прямих механізмів збору даних, рис. 5. Прикладом такої ситуації можуть слугувати географічно розосереджені системи збору даних за посередництвом мобільних мереж GPRS/EDGE. У таких мережах наділення клієнтських вузлів окремими/реальними IP-адресами або формування корпоративної мобільної мережі може виявитися коштовним задоволенням, тому доступніше виявляється ініціатива сеансу передачі даних з клієнтських динамічних IP-адрес на одну реальну IP-адресу серверу SCADA-системи. Хоча можлива робота і через мережеву СУБД-посередника. Дії на модифікацію передаються джерелу даних в момент сеансу передачі даних джерелом.

Проміжним варіантом є ініціатива встановлення TCP-підключення від джерела даних та типові запити надалі від сервера по цьому підключенню, що вхідний транспорт OpenSCADA Transport.Sockets наразі підтримує.

Рис. 5. Діаграма послідовності взаємодії у пасивному механізмі роботи.

У відповідності з діаграмою вище ми отримуємо наступну поведінку пасивного механізму:

• об'єкт джерела даних здійснює періодичні сеанси зв'язку із об'єктом атрибуту параметра DAQParamAttributeArch::setVal() для передачі своїх даних та отримання команд дій;
• об'єкт SCADA-системи надсилає запит останнього значення до об'єкту атрибуту параметра DAQParamAttribute::getVal() та отримує збережене локально значення попереднього сеансу зв'язку джерела даних.

У OpenSCADA такий механізм ще не використано, однак принципова можливість його реалізації у системі є, наприклад, через запис за посередництвом стандартних протоколів "ModBus", "OPC-UA".

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 користувацького програмування:

• Бібліотека функцій сумісності зі SCADA Complex1: FLibComplex1;
• Бібліотека стандартних математичних функцій: FLibMath;
• Бібліотека функцій системного API: FLibSYS.

Рис. 6. Загальна структура компонентів середовища програмування.

3. Логічний рівень обробки даних

Вище ми казали про те, що тип джерела даних може коливатися від "сирого" до комплексного. Під "сирим" мається на увазі джерело, яке надає тільки елементарні сигнали (цілі, реальні, логічні, рядок, ...), причому окремо. Під комплексним мається на увазі джерело, яке групує сигнали та в параметрі підсистеми "Збір Даних" надає атрибути додаткового призначення, які покривають практично всі діагностичні завдання, тобто параметр є закінченим об'єктом, який не потребує доповнення.

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

Функціонально "Логічний рівень" призначено для надання у системі OpenSCADA механізму вільного формування об'єктів параметрів, контейнерів сигналів, потрібної структури.

Експлуатаційним призначенням "Логічного рівня" є:

• розширення сфери застосування системи OpenSCADA за рахунок збільшення гнучкості опису об'єктів параметрів підсистеми "Збір Даних";
• скорочення витрат труда на створення складних автоматизованих систем.

Концепція "Логічного рівня" заснована на шаблонах параметрів, для яких у підсистемі "Збір Даних" передбачено контейнер бібліотек шаблонів (рис. 1). Кожна бібліотека містить шаблони параметрів, які можуть використовуватися модулями підсистеми "Збір Даних" для реалізації параметрів на основі шаблонів. Модулями системи OpenSCADA, які використовують шаблони у своїй роботі, є:

• LogicLev EN RU — модуль реалізації класичної концепції "Логічного рівня".
• Siemens EN RU — модуль збору даних контролерів фірми Siemens серії S7. У зв'язку із високою гнучкістю та функціональністю контролерів фірми цієї серії, яка дозволяє формувати комплексні типи даних різноманітної структури, всі параметри цього модуля працюють за шаблонами.
• ModBus — модуль доступу до даних джерел за посередництвом сімейства протоколів "ModBus". Крім типу параметру прямого опису переліку регістрів підтримує і логічний тип, де регістри "ModBus" описуються у зв'язках шаблону.

Загальний механізм роботи "Логічного рівня" на прикладі модуля LogicLev EN RU зображено на рисунку 7.

Рис. 7. Механізм роботи "Логічного рівня" на прикладі модуля LogicLev EN RU.

Виходячи із зображення видно, що параметри контролеру логічного рівня виконують функцію відображення інших параметрів підсистеми "Збір Даних" (на прикладі параметрів 1 та 4) та довільне формування параметрів на основі шаблонів 1, 2 та інших параметрів підсистеми "Збір Даних" (на прикладі параметрів 2, 3 та 5).

Структура параметрів з шаблоном в основі має структуру, зображену на рисунку 8.

Рис. 8. Структура параметрів, з шаблоном в основі.

Як можна бачити із структури, параметр логічного рівня складається із об'єкту функції, атрибутів та конфігурації шаблону. Об'єкт функції це екземпляр виконання функції шаблону з набором входів/виходів та програмою обчислення шаблону на одній із мов користувацького програмування, зазвичай це Java-подібна мова користувацького програмування модуля JavaLikeCalc. Утім шаблон може бути взагалі без програми, надаючи тільки структуру прокидання входів/виходів. Атрибути у структурі зображують перелік атрибутів результуючого параметру у відповідності із шаблоном. Конфігурація у структурі надає конфігурацію властивостей шаблону та його зовнішніх зв'язків.

Логіку роботи логічного рівня параметрів можна записати наступним чином:

• Параметр зв'язується з шаблоном із якого отримується структура атрибутів, у відповідності із функцією шаблону.
• Під час зв'язування параметру з функцією виконується зв'язування об'єкту екземпляру функції параметру з функцією із шаблону.
• Далі, у відповідності із шаблоном функції, формується структура зв'язків. Виходячи із структури зв'язків формується форма зв'язування параметру та користувачем встановлюються зв'язки.
• При доступі до атрибутів отриманого параметра здійснюється перевірка на наявність прямого зв'язку. У випадку наявності прямого зв'язку запит переспрямовується за цим зв'язком, інакше значення береться із об'єкту екземпляру функції параметру.
• В цей момент працює обчислювання функції шаблону, за об'єктом функції параметрів. При цьому, перед обчисленням, здійснюється читання значень за зв'язками, а після обчислення запис результатів за цими зв'язками.

Шаблон параметрів в цілому надає наступне:

• структуру входів/виходів функції шаблону;
• ознаки конфігурації та зв'язування шаблона (константа, зв'язок);
• попередні значення конфігурації постійних та шаблонів конфігурації зв'язків;
• ознаки атрибутів результуючого параметру логічного рівня типів: не атрибут, атрибут з повним доступом, атрибут з доступом тільки на читання;
• механізм обчислення входів/виходів функції шаблонів з використанням мови користувацького програмування OpenSCADA.

На рисунку 9 наведено зображення вкладки конфігурації шаблону параметрів підсистеми "Збір Даних" у вигляді таблиці з конфігурацією входів/виходів та тексту програми користувацького програмування.

Рис. 9. Вкладка конфігурації шаблону параметрів підсистеми "Збір Даних".

Вкладкою входу/виходу шаблону параметра передбачені наступні властивості спеціалізованого призначення: "Атрибут", "Доступ" та "Значення".

Властивість "Атрибут" виступає ознакою відображення входу/виходу шаблону на результуючий атрибут параметра. Передбачено наступні варіанти цієї властивості:

• Не атрибут — вхід/вихід функції шаблону не відображається на атрибут;
• Тільки читання — вхід/вихід функції шаблону відображається на атрибут з доступом тільки на читання;
• Повний доступ — вхід/вихід функції шаблону відображається на атрибут з повним доступом.

Властивість "Доступ" виступає ознакою, яка вказує на використання входу/виходу функції шаблону в результуючій конфігурації шаблону на логічному рівні. Передбачено наступні варіанти цієї властивості:

• Змінна — доступний для доступу та контролю тільки з процедури шаблона як змінна, яка зберігається із контекстом параметру логічного рівня;
• Константа — доступний для встановлення на рівні параметра логічного рівня в розділі конфігурації шаблону у вигляді постійної;
• Зв'язок — доступний для встановлення на рівні параметру логічного рівня в розділі конфігурації шаблону у вигляді зв'язку.

Поле "Значення" описує передвстановлене значення для постійних та шаблон конфігурації зовнішніх зв'язків. Шаблон конфігурації зовнішніх зв'язків використовується в цілях опису механізму групування та автоматичного розподілу зовнішніх зв'язків. Структура шаблону конфігурації зовнішніх зв'язків специфічна для кожного модуля підсистеми "Збору Даних", який використовує механізм шаблонів. У випадку з модулем логічного рівня розподіл відбувається над зовнішніми атрибутами параметрів з шаблоном конфігурації зовнішнього зв'язку виду: {Параметр}|{атрибут}. Де "Параметр" використовується для об'єднання параметрів та розташування на форму конфігурації, а атрибут для асоціативного зв'язування атрибутів при призначені параметру.

У якості прикладу використання шаблону на рис.10 приведемо зображення параметру модуля логічного рівня "F3". На рис.10 представлено вкладку "Конфігурація шаблона" для конфігурації, включаючи зв'язування, шаблону параметру. На рис.11 представлено вкладку "Атрибути" з переліком атрибутів та їх значень, створених за посередництвом шаблону.

Рис. 10. Вкладка "Конфігурація шаблону" параметру "F3" модуля логічного рівня.

Рис. 11. Вкладка "Атрибути" параметру "F3" модуля логічного рівня.

4. Резервування джерел даних

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

Рис. 12. Горизонтальне та вертикальне резервування.

У випадку з підсистемою "Збір Даних" системи OpenSCADA резервування даних (рис.12) виконує функції:

• Резервування механізму збору даних. Зазвичай ця функція реалізується без особливих механізмів шляхом простого запуску паралельних резервних станцій з однаковою конфігурацією та працюючих незалежно. Однак у випадку виконання станцією функції ПЛК така поведінка недозволена з причини одночасної видачі керуючих дій та відсутності синхронізації даних обчислювачів.
• Компенсація втрати даних на час простою вузла за рахунок архіву резервного. Передбачено два механізми компенсації. Перший та основний механізм здійснює завантаження ділянок архіву з резервної станції під час запуску станції в цілому або окремих об'єктів контролерів. Ділянка архіву запитується з моменту останнього запису у локальному архіві та по поточний час. Глибина запиту при цьому обмежується визначенням граничного часу в конфігурації резервування. Другий, доповнюючий механізм, здійснює заповнення "дірок" у архіві значень, під час фактичного запиту користувача до цих даних. Такий підхід з одного боку дозволяє здійснити прогнозовану за часом синхронізацію при старті, а з іншого боку фактично виключає втрату даних при умові роботи хоча б однієї станції на протязі всього робочого часу.
• Розподіл навантаження по збору даних між вузлами. При створені складних розподілених систем може виявитися важливим питання прогнозування та оптимізації загальної продуктивності системи. Враховуючи такі завдання механізм резервування передбачає виконання завдань збору даних окремих джерел (контролерів OpenSCADA) тільки на одній станції. При цьому завдання решти станцій переходять в режим синхронізації даних зі станцією що виконується. У випадку втрати зв'язку зі станцією що виконується запускається завдання локального збору даних. Передбачено також можливість оптимального розподілу навантаження виконання задач збору даних групи контролерів між станціями.
• Оптимізація навантаження на зовнішні джерела даних за рахунок запиту (обміну) даних у зовнішнього джерела тільки одним вузлом. В практиці часто зустрічаються високо-навантажені джерела даних або інтерфейси доступу до джерел даних, для яких навіть збір даних однією станцією може бути проблемою і вимагатиме зниження періодичності збору, тобто якості даних. Механізм резервування, крім розподілу навантаження між станціями за описаною вище схемою, дозволяє зняти додаткове навантаження на джерело даних та його інтерфейси тим самим підвищивши якість даних. Запис до атрибуту резервного об'єкту контролеру призводить до відправки запиту модифікації на основний, тобто через основний.
• Запобігання деякої різниці даних на різних вузлах, пов'язане з незбігом моментів часу при незалежному зборі даних окремими вузлами, шляхом отримання даних зі станції з активним контролером. В системах високої звітності з резервуванням має бути виключено або зведено до мінімуму розходження у даних на різних станціях, що передбачає реальний збір даних однією станцією та синхронізацію з цими даними інших станцій.

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

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

Рис. 13. Вкладка "Підсистема" підсистеми "Транспорти".

Далі на конкретній станції, з копією загальної БД, налаштовуємо її специфічні параметри у вкладці "Резервування" головної сторінки (рис.14), які будуть збережені у конфігураційному файлі.

Рис. 14. Вкладка "Резервування" головної сторінки.

Після цього вся конфігурація резервування збору даних здійснюється зі вкладки "Резервування" підсистеми "Збір Даних" (рис.15), а якщо встановити параметр "Передача локальних первинних команд" (рис.14) то ця конфігурація, як і будь яка інша конфігурація загального характеру, може здійснюватися на одній з станцій, а внесенні зміни потраплять й на всі резервні, звісно якщо вони будуть доступні.

Рис. 15. Вкладка "Резервування" підсистеми "Збір Даних".

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

• Контроль за з'єднанням із зовнішніми станціями. В процесі контролю здійснюються запити до віддалених станції за оновленням інформації про них та перевірки зв'язку. У випадку втрати зв'язку із станцією повтор підключення до неї здійснюється через проміжок часу, вказаний у конфігураційному полі інтервалу часу відновлення підключення. У полі "Живий" станції відображається поточний стан зв'язку. У полі "Лічильник" представлено кількість запитів, здійснених до віддаленої станції, або ж час, який залишився для здійснення наступної спроби підключення із втраченою станцією. У полі "Запущено" наводиться перелік активних контролерів на віддаленій станції з ознакою локального виконання.
• Локальне планування виконання об'єктів контролерів у резерві. Планування здійснюється у відповідності з рівнями станцій та вподобаннями виконання об'єктів контролерів.
• Виклик функції синхронізації даних для локальних об'єктів контролерів, працюючих у режимі синхронізації даних із зовнішніх станцій.

Для контролю за часом, витраченим на виконання циклу завдання обслуговування резервування, передбачено поле статусу. При наближені реального часу виконання до циклу завдання обслуговування резервування рекомендується збільшити періодичність виконання цього завдання!

Для об'єкту контролера підсистеми "Збір Даних" передбачено режими резервування "Асиметричне" та "Тільки порушення". Асиметричне резервування працює з тією конфігурацією контролеру віддаленої станції, яка є і не намагається її узагальнювати, для якого працюють всі раніш описані функції та властивості резервування. Резервування "Тільки порушення" передбачає фактичну роботу без резервування, але з придушенням порушень від резервного об'єкту контролера з метою виключення дублювальних повідомлень про порушення.

Посилання