OpenSCADA

Документи/Посібник по програмі

This page is a translated version of the page Documents/Program manual and the translation is 100% complete.

English • ‎mRussian • ‎Українська

Цей документ є посібником по програмі з відкритими вихідними текстами за назвою "OpenSCADA". OpenSCADA представляє собою відкриту SCADA систему, побудовану за принципами модульності, багатоплатформеності та масштабованості.

У якості політики розробки цієї програми обрано "open source" принципи. Вибір цієї політики визначається потребою створення відкритої, надійної та загальнодоступної SCADA системи. Така політика дозволяє залучити до розробки, тестування, розвитку, розповсюдженню та використанню програми значну кількість розробників, ентузіастів та інших зацікавлених осіб з мінімізацією та розподілом зусиль та фінансових витрат.

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

OpenSCADA може та застосовується на/у:

У якості основної операційної системи (програмної платформи) для розробки та використання обрано ОС Linux, яка є оптимальним рішенням у питаннях:

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

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

Серверні конфігурації програми призначені для видачі керуючих дій, збору, обробки, архівування, протоколювання інформації від різних джерел, а також надання цієї інформації клієнтам (UI, GUI, TUI ...). Модульна архітектура дозволяє розширювати функціональність серверу без його перевантаження.

Клієнтські конфігурації можуть будуватися на основі різних графічних бібліотек (GUI/TUI ToolKits), як використовуючи ядро програми та його модулі (шляхом додання до нього модуля користувацького інтерфейсу), так і у якості самостійного додатку, підключаючи ядро OpenSCADA як бібліотеку.

Гнучкість конфігурації програми дозволяє будувати рішення під конкретні вимоги надійності, функціональності та розміри-складність програми.

Contents

1 Архітектура та функції

Про фактичні функції та вимоги OpenSCADA Ви можете прочитати на сторінці "Функції та вимоги", та в цьому документі ми розглянемо загальні функції та властивості програми.

Рис. 1. Блокова схема OpenSCADA.

1.1 Модульність

Для надання гнучкості та високого ступеню масштабування OpenSCADA побудовано за модульним принципом. Тісна інтеграція модулів з ядром покращує стабільність програми в цілому, завдяки повторному використанню налагодженого коду. Однак сам процес розробки власного коду модулів OpenSCADA накладає велику відповідальність — можливі помилки вводять елемент нестабільності у програму. Можливість створення розподілених конфігурацій згладжує цю небезпеку.

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

На основі модулів реалізовано наступні функціональні частини OpenSCADA:

Управління модулями здійснюється підсистемою "Диспетчер модулів". Функціями підсистеми є: підключення, відключення, оновлення та інші операції, пов'язані з модулями та бібліотеками модулів.

1.2 Підсистеми

Архітектурно OpenSCADA поділяється на підсистеми. Підсистеми можуть бути двох типів: звичайні та модульні. Модульні підсистеми мають властивість розширення посередництвом модулів. Кожна модульна підсистема може містити багато модульних об'єктів. Наприклад, модульна підсистема "Бази даних" містить модульні об'єкти типів баз даних. Модульний об'єкт є коренем всередині модуля.

Разом OpenSCADA містить дев'ять підсистем, з них сім є модульними. Ці дев'ять підсистем OpenSCADA є базовими та присутні у будь якій конфігурації. До переліку дев'яти підсистем можуть додаватися нові, за посередництвом самих модулів. Підсистеми OpenSCADA:

1.3 ПЛК та інші джерела динамічних даних, підсистема "Збір даних"

Підсистему "Збір даних" (Рис.1.3) передбачено для надання підтримки джерел динамічних даних, будь то: ПЛК, плати ПУО, віртуальні джерела та інше. До функції цієї підсистеми входить надання отриманих даних у структурованому вигляді — модель даних та забезпечення управління цими даними, наприклад — модифікація даних.

Рис. 1.3. Ієрархічна структура підсистеми "Збір даних".

Підсистема "Збір даних" є модульною та, як наслідок, містить модульні об'єкти типів джерел динамічних даних. Наприклад, OpenSCADA наразі надає більш ніж двадцять модулів та бібліотечних елементів джерел логічних типів. Більш значущі та опрацьовані з яких:

Кожний тип джерела нелогічного типу реалізується у окремому модулі, який може містити багато джерел (об'єктів контролерів) та кожне це джерело зазвичай виконується у окремому потоці-завдані.

Окремо взятий об'єкт контролеру може містити параметри визначених модулем типів. Наприклад, параметри аналогового типу, основною інформацією яких є значення цілого або реального типу. Структурно параметр представляє собою перелік атрибутів, які й містять дані. Атрибути можуть бути п'яти базових типів: логічний, цілий, реальний, символьний рядок(текст) та об'єкт. Структури об'єктів контролерів, параметрів та їх типів містяться у підсистемі "Збір даних", а об'єкти модулів здійснюють їх заповнення згідно зі власною специфікою.

Окремі типи джерел даних самі можуть продукувати дані як повністю їх генеруючи, так і обробляючи фізичні дані та навіть повністю реалізуючи отримання цих даних у оточені OpenSCADA та на її внутрішній мові. Такі джерела даних називаються логічними. Повністю логічні джерела даних представлені модулями: LogicLev та BlockCalc. Існує низка модулів, які поєднують у собі логічні дані як результат безпосередньої обробки фізичних: ModBus, Siemens та OPC-UA.

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

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

1.4 Бази даних, підсистема "Бази даних"

Для зберігання даних програми повсякчасно використовуються бази даних (БД). З метою уніфікації доступу та управління базами даних у OpenSCADA передбачено підсистему "Бази даних" (Рис.1.4). Для забезпечення підтримки різних БД/СУБД підсистему виконано модульною.

Рис. 1.4. Ієрархічна структура підсистеми "БД".

У ролі модульного об'єкту, що міститься у підсистемі, виступає тип БД/СУБД, тобто модуль підсистеми "Бази даних" практично містить реалізацію доступу до визначеного типу БД. OpenSCADA надає наступні більш значущі та опрацьовані модулі: SQLite, MySQL, PostgreSQL, FireBird.

Тип БД/СУБД своєю чергою містить перелік об'єктів окремих БД цього типу, а об'єкт БД містить перелік об'єктів таблиць, які й містять дані у табличній формі.

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

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

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

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

1.5 Архіви та історія, підсистема "Архіви-Історія"

Будь яка SCADA система має надавати можливість архівування зібраних даних, тобто формувати історію зміни (динаміки) процесу. Архіви умовно можна поділити на два типи: архіви повідомлень та архіви значень.

Рис. 1.5. Ієрархічна структура підсистеми "Архіви-Історія".

Особливістю архівів повідомлень є архівація так званих повідомлень програми, а саме — ведення логів та протоколів. Характерною ознакою повідомлення є час його виникнення. Залежно від джерела повідомлення можуть класифікуватися за різними критеріями. Наприклад, це можуть бути протоколи аварійних ситуацій, протоколи дій операторів, протоколи відмов зв'язку та інше.

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

Для вирішення задач архівування потоків даних у OpenSCADA передбачено підсистему "Архіви-Історія" (Рис.1.5), яка є модульною та дозволяє вести архіви повідомлень та значень. Модульним об'єктом, який міститься у підсистемі "Архіви-Історія", виступає тип архіватору. Тип архіватору визначає спосіб зберігання даних тобто сховище — файлова система, СУБД. Кожен модуль підсистеми "Архіви-Історія" відповідно може реалізовувати архівування повідомлень та значень та сама підсистема може містити багато архівів, які обслуговуються різними модулями.

1.5.1 Повідомлення

Повідомлення у OpenSCADA характеризуються датою, рівнем важливості, категорією та безпосередньо текстом повідомлення. Дата повідомлення відповідно вказує на дату та час його створення. Рівень важливості вказує на ступінь важливості повідомлення. Категорія визначає адресу або умовний ідентифікатор-ключ джерела повідомлення. Часто категорія містить повний шлях до джерела повідомлення у програмі. Текст повідомлення відповідно й несе головне смислове навантаження повідомлення.

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

Рівнів повідомлень передбачено 8, але кожен з цих рівнів, від 1(першого), може бути розширено підрівнями, тобто фактично бути групою із 10 підрівнів, що здійснюється простим доданням цифри після основного рівня, наприклад, 5 — це основний рівень, а 50...59 це розширення рівня 5. Що загальну кількість рівнів встановлює у 80. Сім основних рівнів мають назви, та відповідності чому бажано дотримуватися:

Відповідно до схожості природи повідомлень та порушень, підсистема "Архіви-Історія" містить буфер поточних порушень, який містить активні на цей час порушення за категорією повідомлення у ролі ключа-ідентифікатору порушення. Доступ до переліку-буферу поточних порушень здійснюється шляхом указання негативного значення рівня повідомлення. Так, формування повідомлення з негативним рівнем -2 викликає розташування цього повідомлення у буфері активних порушень з рівнем 2, а також дублювання його безпосередньо у архіві повідомлень (буфері загальних повідомлень). За формуванням повідомлення у такій же категорії, але за позитивним рівнем — скажемо 1, буде здійснено видалення вказаного порушення з буферу порушень, а саме повідомлення також потрапить до архіву повідомлень (буферу загальних повідомлень). Такий механізм дозволяє одночасно вести облік активних порушень та протоколювати їх проходження у архіві повідомлень. При запиті до архіву повідомлень, визначення позитивного рівня здійснює запит до архіву повідомлень (через загальний буфер повідомлень), а негативного рівня здійснює запит до буферу-переліку поточних порушень.

Суворої структури категорії та тексту повідомлення не передбачається та користувач, для власних повідомлень, може формувати їх довільно, але варто враховувати структуру системних повідомлень та повідомлень, визначених стандартними бібліотеками OpenSCADA, щоб попередити перетин з ними, або предметно розширити:

КАТЕГОРІЯ: визначає типовий шлях до вузлу повідомлення, наприклад — "/sub_DAQ/mod_LogicLev/cntr_gen/", де:
  • "/*/*" — типовий шаблон-ознака системного повідомлення на основі символу-роздільнику елементів шляху, який може бути безпосередньо використано у фільтрі категорії для визначення суто архіву системних повідомлень.
ТЕКСТ: містить шлях назв вузла повідомлення та саме повідомлення у форматі "{NodeNmPath}: {message}", наприклад — "AGLKS > Збір Даних > LogicLev > gen: Запуск контролера.".
КАТЕГОРІЯ: у початок категорії отриманого повідомлення додається ідентифікатор об'єкту контролеру модуля DAQ.DAQGate, що здійснив отримання, наприклад — "loop:alModBus:testTCP" або "TopStat(DAQCntr):alModBus:testTCP", де:
  • "loop:*" — типовий шаблон-ознака віддаленого нижчого повідомлення на основі ідентифікатору об'єкту контролеру модуля DAQ.DAQGate, який може бути безпосередньо використано у фільтрі категорії для визначення суто архіву віддалених повідомлень цього джерела;
  • "TopStat(DAQCntr):*" — типовий шаблон-ознака віддаленого вищого повідомлення на основі назви проекту (або ідентифікатору) TopStat та ідентифікатору об'єкту контролеру DAQCntr модуля DAQ.DAQGate, який може бути безпосередньо використано у фільтрі категорії для визначення суто архіву віддалених повідомлень цього джерела.
КАТЕГОРІЯ: визначає ID-адресу джерела порушення у форматі "{ID}{ModId}:{CntrId}[.{PrmId}][:{SpecPrms}]", де:
  • ID — двосимвольний ідентифікатор структури;
  • ModId — ідентифікатор модуля;
  • CntrId — ідентифікатор об'єкту контролера;
  • PrmId — ідентифікатор параметру;
  • SpecPrms — специфічні параметри структури ID.
КАТЕГОРІЯ: визначає ID-адресу джерела порушення у форматі "al{ModId}:{CntrId}[.{PrmId}]", наприклад — "alLogicLev:gen.F_PP1", де:
  • "al*" — типовий шаблон-ознака повідомлення порушення на основі двох перших символів слова "alarm", який може бути безпосередньо використано у фільтрі категорії для визначення суто архіву порушень.
ТЕКСТ: "{CntrNm} > {PrmNm}: {MessText}", наприклад — "Загальностанційка > F_PP1: Витрати газу через діафрагму PP1: НОРМА", де:
  • CntrNm — назва об'єкту контролера;
  • PrmNm — назва параметру;
  • MessText — текст повідомлення, яке має підструктуру "{Viol}: {Value}[: {QuietTime}[: {NormTime}[: {Comment}]]]", де:
  • Viol — опис порушення, яке окремі кадри, як то Main.alarmsAct та Main.alarmsSt, можуть розширювати користувацькими полями у формі "[[{CustFld0} => {CustFld1} => ... => {CustFldN}]]";
  • Value — значення порушення;
  • QuietTime — час підтвердження (квітації);
  • NormTime — час повернення до стану НОРМА, встановлюється тут після квітації-підтвердження повідомлення вже у НОРМА;
  • Comment — коментар до цього випадку.
  • Дії користувача-оператора із джерелом даних, генеруються процедурою віджетів при визначені дій користувача-оператору, які мають бути зафіксовано у протоколі користувача-оператору та коли доступний об'єкт параметру джерела даних:
КАТЕГОРІЯ: визначає користувача та характерне джерело (зазвичай параметр підсистеми "Збір даних") для якого здійснено дії, у форматі "OP{ModId}:{CntrId}[.{PrmId}]:{user}", наприклад — "OPLogicLev:gen.PC_PCV1:roman", де:
  • "OP*" — типовий шаблон-ознака повідомлення дії користувача-оператору на основі двох перших символів слова "operator", який може бути безпосередньо використано у фільтрі категорії для визначення суто архіву дій оператору.
TEXT: таке саме як і за структури "Дії користувача-оператора".
КАТЕГОРІЯ: визначає користувача та характерне джерело (зазвичай параметр підсистеми "Збір даних") для якого здійснено дії, у форматі "OP:{user}:{src}", наприклад — "OP:roman:РС_КРТ1", де:
  • "OP:*" — типовий шаблон-ознака повідомлення дії користувача-оператору на основі двох перших символів слова "operator", який може бути безпосередньо використано у фільтрі категорії для визначення суто архіву дій оператору;
  • user — користувач OpenSCADA;
  • src — характерне джерело, зазвичай параметр підсистеми "Збір даних", за потреби доповнений ієрархією DAQ-параметрів до об'єкту контролеру.
ТЕКСТ: опис дії у форматі "{src} : {name} : [{oldVal}] : {newVal}", наприклад — "'РС_КРТ1'. Завдання : Регулятор тиску на вході КС : 6.0 : 5.8", де:
  • src — назва джерела, зазвичай об'єкту параметру з деталізацією, та за потреби доповнений ієрархією DAQ-параметрів до об'єкту контролеру;
  • name — назва джерела, зазвичай об'єкту параметру;
  • oldVal — старе значення, може бути відсутнє;
  • newVal — нове значення або дія.
КАТЕГОРІЯ: визначає ID джерела SrcID у форматі "val{SrcID}", де:
  • "val*" — типовий шаблон-ознака значення, який може бути безпосередньо використано у фільтрі категорії для визначення суто значень у повідомленнях;
  • SrcID — ідентифікатор джерела.
ТЕКСТ: назва Name та значення Value параметру у форматі "{Name}: {Value}".
КАТЕГОРІЯ: визначає ідентифікатор користувацького рецепту-програми ProgNM у форматі "uprg{ProgNM}", де:
  • "uprg*" — типовий шаблон-ознака користувацького рецепту-програми, який може бути безпосередньо використано у фільтрі категорії для визначення у повідомленнях суто користувацьких рецептів-програм;
  • ProgNM — ім'я рецепту-програми.
ТЕКСТ: опис дії у форматі "{ActDescr} "{ProgNM}" : {StartTm} : {ActTm}", де:
  • ActDescr — опис дії:
  • "Поточний вузол відсутній";
  • "Перерваний користувачем сеанс програми";
  • "Перерваний помилкою сеанс програми";
  • "Вдалий сеанс програми".
  • ProgNM — ім'я рецепту-програми;
  • StartTm — час запуску рецепту-програми, у форматі "2020-03-14 16:05:01";
  • ActTm — час дії рецепту-програми, у форматі "2020-03-14 16:05:52".

1.5.2 Значення

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

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

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

1.6 Комунікації, підсистеми "Транспорти" та "Транспортні протоколи"

Оскільки OpenSCADA є високо-масштабованою то підтримка комунікацій має бути достатньо гнучкою, для чого вона реалізована у підсистемах "Транспорти" та "Транспортні протоколи" (Рис.1.6), які є модульними.

Рис. 1.6. Ієрархічна структура підсистеми "Транспорти" та "Протоколи".

Підсистема "Транспорти" призначена для забезпечення обміну неструктурованими даними між OpenSCADA та зовнішніми системами, у ролі яких також можуть виступати віддалені станції OpenSCADA. Під неструктурованими даними вважається потік символів певної довжини. Модульним об'єктом, що міститься у підсистемі "Транспорти", виступає тип транспорту, який і визначає механізм передачі неструктурованих даних. Наприклад, це можуть бути та є:

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

Підсистема "Транспортні протоколи" призначена для структуризації даних, отриманих від підсистеми "Транспорти", є продовженням підсистеми "Транспорты", від чого має таку назву, та здійснює функції перевірки структури та цілісності отриманих даних. У глобальній нотації, ця підсистема містить та реалізує КОМУНІКАЦІЙНІ протоколи! Для визначення протоколу, разом з яким має працювати транспорт, передбачено спеціальне конфігураційне поле. Модульним об'єктом, який міститься у підсистемі "Протоколи", є сам протокол. Наприклад, транспортними протоколами можуть бути та є:

Повну послідовність сеансу вхідного зв'язку для типових протоколів режиму "запит-відповідь" можна записати наступним чином:

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

Транспорти мають можливість утримувати додаткові параметри, якими можуть бути параметри використаних протоколів, тобто протоколи можуть бути індивідуально сконфігуровані для кожного підключення. [ПЛАН] У майбутньому ця функція буде використана для обгорткових протоколів.

Завдяки стандартному доступу до транспортів у OpenSCADA, можна легко змінювати спосіб обміну даними не зачіпаючи самих програм, що обмінюються. Наприклад, у випадку локального обміну, можна використовувати швидший транспорт на основі UNIX-сокетів, а у випадку обміну через інтернет та локальну мережу використовувати TCP- або UDP-сокети.

1.7 Інтерфейси користувача, підсистема "Інтерфейси користувача"

SCADA-системи, як клас, передбачають наявність інтерфейсів користувача. У OpenSCADA для надання користувацьких інтерфейсів передбачена підсистема "Користувацькі інтерфейси" під якою розуміється не тільки середовище візуалізації, з яким має працювати кінцевий користувач, але і все, що має стосунок до користувача, наприклад:

Підсистема "Користувацькі інтерфейси" є модульною та її модульним об'єктом виступає власне конкретний інтерфейс користувача. Модульність підсистеми дозволяє створювати різні інтерфейси користувача на різних GUI/TUI бібліотеках та використовувати найбільш оптимальне рішення у конкретно взятому випадку, наприклад, для середовища виконання програмованих логічних контролерів можна використовувати конфігуратори та візуалізатори на основі Web-технологій (WebCfg, WebCfgD, WebVision, WebUser), а у випадку стаціонарних робочих станцій використовувати ті-ж конфігуратори та візуалізатори, але на основі бібліотек на кшталт Qt (QTCfg, Vision).

1.8 Безпека програми, підсистема "Безпека"

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

1.9 Управління модулями, підсистема "Диспетчер модулів"

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

Підсистема "Диспетчер модулів" реалізує контроль за станом контейнерів та дозволяє виконувати "гаряче" додання, видалення та оновлення контейнерів та модулів, що він містить.

1.10 Непередбачені можливості, підсистема "Спеціальні"

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

1.11 Функції, об'єктна модель та середовище програмування користувача

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

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

Модулі бібліотек функцій надають статичні функції визначеної спрямованості, які розширюють об'єктну модель програми та представляють собою інтерфейс доступу до засобів модуля на рівні користувача. Наприклад, "Середовище Візуалізації та Управління" може надавати функції для видачі різних повідомлень, використовуючи які користувач може реалізовувати інтерактивні алгоритми взаємодії з програмою. Бібліотеки функцій загалом можуть реалізовуватися як набором функцій фіксованого типу — статичні, так і функціями, що допускають вільну модифікацію та доповнення — динамічні.

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

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

2 SCADA системи та їх структура

Рис. 2. Ієрархічна SCADA-система.

SCADA (Supervisory Control And Data Acquisition) загалом мають розподілену архітектуру на кшталт зображеної на рисунку 2. Елементи SCADA систем, у сенсі програмного забезпечення, виконують наступні функції:
Сервер збору: представляє собою задачу або групу задач, що займаються збором даних з джерел даних, або ж самі виступають у ролі джерела даних. До задач серверу входить:

Сервер архівування-історії: представляє собою задачу або групу задач, що займаються архівуванням даних або веденням їх історії. До задач серверу входить:

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

Сервер сигналізації: представляє собою задачу або групу задач, які виконують функції серверу протоколювання стосовно вузької категорії повідомлень сигналізації.
Робоче місце оператору: представляє собою GUI(Grafical User Interface) додаток, що постійно функціонує та виконаний у одномоніторному, багато-моніторному або панельному режимі та що виконує функції:

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

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

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

3 Варіанти конфігурації та використання

3.1 Просте серверне підключення

У простішому випадку OpenSCADA можна сконфігурувати у серверному режимі (Рис.3.1) для збору та архівування даних. Така конфігурація дозволяє виконувати наступні функції:

Рис. 3.1. Просте серверне підключення.

3.2 Дубльоване серверне підключення

Для підвищення надійності та продуктивності OpenSСADA допускає множинне резервування (Рис.3.2), при якому джерела даних (контролери) та архіви-історія одного екземпляру відбиваються у іншому. При використанні подібної конфігурації можливий розподіл навантаження опитування/обчислювання по різними станціями. Така конфігурація дозволяє виконувати функції:

Рис. 3.2. Дубльоване серверне підключення.

3.3 Дубльоване серверне підключення на одному сервері

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

Рис. 3.3. Дубльоване серверне підключення на одному сервері.

3.4 Клієнтський доступ за посередництвом Web-інтерфейсу. Місце керівника

Для візуалізації даних, які містяться на сервері, гарним рішенням є використання користувацького WEB-інтерфейсу (Рис.3.4). Це рішення дозволяє використовувати стандартний WEB-браузер у клієнта та відповідно є найгнучкішим, оскільки не прив'язано до однієї платформи, тобто є багатоплатформним. Однак це рішення має суттєві недоліки – це невисока продуктивність та надійність. У зв'язку з цим рекомендується використовувати цей метод для візуалізації некритичних даних або даних, що мають резервний високонадійний спосіб візуалізації. Наприклад, гарним рішенням буде використання цього методу у керівництва промислових установок, де завжди існує операторська з надійним способом візуалізації. Така конфігурація дозволяє виконувати наступні функції:

Рис. 3.4. Клієнтський доступ за посередництвом Web-інтерфейсу. Місце керівника.

3.5 Автоматизоване робоче місце (місце керівника/оператору)

Для візуалізації критичних даних, а також у випадку якщо потрібна висока якість та продуктивність, можна використовувати візуалізацію на основі OpenSCADA, яку сконфігуровано з GUI модулем (Рис.3.5). Така конфігурація дозволяє виконувати натупні функції:

Рис. 3.5. Автоматизоване робоче місце (місце керівника/оператору).

3.6 АРМ з сервером збору та архівування на одній машині (місце оператору, модель-тренажер ...)

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

Рис. 3.6. АРМ з сервером збору та архівування на одній машині (місце оператору, модель-тренажер ...).

3.7 Найпростіше змішане підключення (модель, демонстрація, тренажер, конфігуратор ...)

Змішане підключення поєднує функції серверу та клієнту (Рис.3.7). Може використовуватися для тестових, демонстраційних функцій, а також для надання моделей та тренажерів технологічних процесів як єдине ціле. У цьому режимі можуть виконуватися наступні функції:

Рис. 3.7. Найпростіше змішане підключення (модель, демонстрація, конфігуратор ...).

3.8 Стійка розподілена конфігурація

Така конфігурація є одним з варіантів стійкого-надійного підключення (Рис.3.8). Стійкість досягається шляхом розподілу функцій за:

Рис. 3.8. Стійка розподілена конфігурація.

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

Центральний сервер архівування та обслуговування клієнтських запитів виконує функцію централізованого збору та обробки параметрів серверів опитування та їх значень. Доступ до серверів опитування виконується за посередництвом одного з доступних у OpenSCADA транспортів+протоколів (на прикладі це Sockets). Для надання єдиного інтерфейсу доступу до параметрів та контролерів використовується модуль DAQGate, який відбиває дані серверів опитування на структуру локальних параметрів збору даних.

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

Для різнобічного та глибокого архівування використовуються різні модулі архівів-історії.

Для доступу клієнтів до серверу використовуються доступні у OpenSCADA мережеві транспорти, на прикладі — Sockets; та транспортні протоколи, на прикладі — протокол OpenSCADA "SelfSystem".

Конфігурація центрального серверу зберігається в одній з доступних БД (на прикладі це мережева СУБД MySQL).

Для надання користувацького WEB-інтерфейсу використовується модуль WebCfgD за посередництвом транспортного протоколу "HTTP".

Різні клієнти, у їх числі АРМ та WEB-клієнти, виконуються на окремих машинах у потрібній кількості. АРМ реалізується на основі OpenSCADA. До його функції входить опитування значень параметрів з центрального сервера та їх візуалізація на GUI інтерфейсі(ах). Для отримання параметрів збору даних у АРМ також використовується модуль відображення віддалених параметрів DAQGate. Для надання доступу до архівів-історії може використовуватися модуль архіву мережевого типу. Конфігурація АРМ може зберігатися у одній з доступних БД (у прикладі це мережева СУБД MySQL, яка розташована на машині центрального сервера архівування).

4 Конфігурація та налаштування

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

При описанні механізмів конфігурації та способів її зберігання у цьому розділі буде робитися наголос на загальних механізмах. Особливості конфігурації та використання модулів підсистем OpenSCADA надаються у власній документації цих модулів.

В OpenSCADA використовується декларативний підхід до описання конфігураційних інтерфейсів, оснований на мові XML. Фактично, особливості конфігурації компоненту програми надаються самим компонентом, пронизуючи тим самим всю програму як нервова система організму. У термінах OpenSCADA це називається інтерфейсом контролю та управління OpenSCADA (Control interface). На основі інтерфейсу контролю формуються графічні інтерфейси конфігурації користувача за посередництвом модулів OpenSCADA. Такий підхід має наступні важливі переваги:

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

OpenSCADA надає три модулі конфігурації на різній основі візуалізації. Відзначимо їх та їх можливості конфігурації:

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

Типовим ім'ям конфігураційного файлу OpenSCADA є {sysconfdir}/oscada.xml (де sysconfdir зазвичай — "/etc"), для конфігурацій поза проєктами OpenSCADA, та {Proj}/oscada.xml для проєкту "Proj". Формат конфігураційного файлу та параметри командного рядку розглянемо у окремому розділі.

Враховуючи модульність підсистеми "БД", БД можуть бути різні. Причому надається можливість зберігання різних частин OpenSCADA як у різних БД одного типу, так і у БД різних типів.

Багато вузлів OpenSCADA надають можливість обрання сховища для зберігання своїх даних та яке може бути вказано як:

Вузли, які не надають можливості обрання сховища, фіксовано працюють із Загальним Сховком (<gen>), а ті що надають таку можливість також відстежують наявність своїх даних у різних сховках та пропонують механізм послідовного видалення дублікатів або просто їх виявлення у різних бібліотеках, які формуються окремими Базами Даних. Більше прочитати про механізми перенесення конфігурації та виокремлення її у бібліотеки ви можете у відповідному "Як Виконати".

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

Низка налаштувань та конфігурацій вузлів OpenSCADA, які виконуються або вже включені, не застосовуються одразу-ж за внесенням змін, оскільки конфігурація читається/застосовується зазвичай тільки при включенні або запуску. Відтак, для застосування змін у таких випадках, достатньо включити/виключити включений об'єкт або перезапустити виконуваний — зупинити/запустити. На цей час більшість налаштувань, що не передбачають безпосереднього застосування, просто недозволені до редагування.

Подальший огляд конфігурації OpenSCADA буде здійснюватися на основі інтерфейсу конфігуратору UI.QTCfg, однак принципи роботи будуть цілком відповідати іншим конфігураторам, завдяки використанню спільного інтерфейсу контролю OpenSCADA.

Розгляд почнемо з конфігурації системних параметрів OpenSCADA, які розміщуються у шести вкладках кореневої сторінки станції:

At.png Більше дізнатися про деталі та специфіку створення багатомовних проєктів ви можете у відповідному "Як Виконати".
  • Статус — поточний статус перекладу повідомлень проєкту, де можливе:
  • "ОДНОМОВНИЙ, лише використовувати вже багатомовні БД із їх модифікацією";
  • "БАГАТОМОВНИЙ, створення або модифікація конфігураційних БД як багатомовні із вказаною базовою мовою '{мова}'";
  • "БАГАТОМОВНИЙ-ДИНАМІЧНИЙ, та динамічний переклад".
  • Базова мова - перелік локалей — вмикає підтримку багатомовності текстових змінних у конфігураційних БД через введення базової мови та переліку всіх локалей (на кшталт "uk_UA.UTF-8") проєкту (опціонально) поділених ';'. Далі, для текстових змінних на небазовій мові у таблицях БД будуть створюватися окремі стовпчики. Під текстовими змінними маються на увазі всі текстові поля конфігуратору, які може бути перекладено на іншу мову. Числа та інші службові символи до їх переліку не належать і не перекладаються. Повний перелік локалей не є обов'язковою частиною та переважно використовується у перетворені коду мови у повну локаль для системних функцій та у переліках обрання локалі.
At.png Ви можете ввести тут іншу мову окрім Англійська(en), але майте на увазі, що всі стандартні бібліотеки OpenSCADA сформовано для базової мови Англійська(en), тож інша базова мова псуватиме ці БД при зміні!
  • , динамічний переклад — запланований стан динамічного перекладу текстових повідомлень. Динамічний переклад текстових повідомлень викликає включення кешу перекладів текстових повідомлень та запити з БД перекладів частин OpenSCADA для робочих мов. Механізм переважно призначено для багатомовних динамічних користувацьких інтерфейсів, коли користувач програми має власну-переважну мову та користувачів у програми багато, як правило це кінцеві користувачі-оператори.
  • Ввімкнення менеджера — включення загального керування перекладами, що призводить до повного перезавантаження для отримання вбудованих повідомлень, що однак не призводить до формування повного індексу повідомлень у зв'язку із забороною перевантаження низки об'єктів під час їх виконання. Для завантаження повного індексу повідомлень потрібно зберегти менеджер у ввімкненому режимі та повністю перезапустити OpenSCADA. У процесі наступного запуску сформується повний індекс повідомлень.
  • Мови контролю — перелік оброблюваних мов, поділені символом ';'. Якщо для вказаної мови у джерелі присутні переклади то стовпчик мови буде їх містити, інакше буде порожнім.
  • Фільтр джерел — фільтр джерел для обмеження роботи менеджеру деякими БД, джерело має просто містити такий підрядок.
  • , перевірка/виправлення — увімкнути перевірку щодо однаковості перекладу базового повідомлення у різних джерелах та виправлення щодо: розповсюдження перекладу на порожні джерела, очищення дублювань базових повідомлень. Та окремий-другий прапорець щодо виправлення поєднанням базових повідомлень як переклади, оскільки ця операція може бути дещо помилковою у складних оточеннях.
  • , пропуск — пропустити визначену кількість елементів таблиці від початку, корисно для дуже великих проєктів які обмежено у часі повного опрацювання таблиці.
  • Повідомлення — безпосередньо таблиця повідомлень зі стовпчиками: базова мова, контрольовані мови перекладу, джерела повідомлення. Для модифікації доступні стовпчики мов, зміни яких будуть вноситися до джерел повідомлення.

Для модифікації полів цієї сторінки можуть бути потрібні права привілейованого користувача. Отримати такі права можна, долучивши вашого користувача до групи суперкористувача "root" або увійти до станції від ім'я суперкористувача "root".

Треба відзначити ще один важливий момент! Поля ідентифікаторів всіх об'єктів OpenSCADA недозволені для прямого редагування оскільки вони є ключем для зберігання даних об'єктів у БД. Однак змінити ідентифікатор об'єкту можливо за допомогою команди перенесення та наступної вставки об'єкту (Cut->Paste) у конфігураторі.

Рис. 4a. Вкладка "Станція" кореневої сторінки конфігурації станції.
Рис. 4b. Вкладка "Підсистеми" кореневої сторінки конфігурації станції.

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

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

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

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

Після цього вся конфігурація резервування здійснюється у вкладці "Резервування" відповідної підсистеми — "Збір даних" (Рис.4.5b) або "Архіви" (Рис.4.6b). Якщо встановити параметр "Передача локальних первинних команд" (Рис.4c) то ця конфігурація, як і будь яка інша загального характеру, може здійснюватися на одній з станцій, а внесенні зміни потраплять на всі резервні, звісно якщо вони будуть доступні.

Рис. 4c. Вкладка "Резервування" кореневої сторінки конфігурації станції.
Рис. 4d. Вкладка "Задачі" кореневої сторінки конфігурації станції.

Для налагодження різних особливостей роботи OpenSCADA може знадобитися включення генерації додаткових-налагоджувальних повідомлень, що здійснюється встановленням мінімального рівня повідомлень, у вкладці "Станція", у "Налагодження (0)". В результаті цього з'явиться вкладка "Налагодження" (Рис.4e) де доступні лічильники об'єктів для контролю за витоками, а також таблиця з переліком категорій налагоджувальних повідомлень, що надходять. У таблиці категорій можна обрати тільки ті джерела налагоджувальних повідомлень, які потрібні, тим самим не перевантажуючи підсистему виводу та архівування повідомлень, а також не знижуючи сильно продуктивності програми в цілому. Можна обирати категорії вищих рівнів, безпосередньо до кореневої категорії підсистеми, що вимкне детальне обрання та увімкне генерацію всіх повідомлень за рівнем або підсистемою. Для вивчення налагоджувальних повідомлень треба перейти до підсистеми "Архіви" (Рис. 4.6c), для чого передбачено кнопку "Перегляд повідомлень". Обраний режим налагодження та перелік категорій налагодження може бути збережений у конфігураційному файлі стандартним чином та при наступному старті режим налагодження активується одразу, що важливо у першу чергу для лічильників об'єктів.

Рис. 4e. Вкладка "Налагодження" кореневої сторінки конфігурації станції.
Рис. 4f. Вкладка "Переклади" кореневої сторінки конфігурації станції.

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

4.1 Підсистема "БД"

Підсистема є модульною та містить ієрархію об'єктів, зображену на рисунку 1.4. Для конфігурації підсистеми передбачено кореневу сторінку підсистеми "БД", що містить вкладку "Підсистема" та "Модулі". Вкладка "Підсистема" (Рис.4.1a) наразі містить лише конфігураційне поле встановлення часу життя відкритих таблиць, у секундах. Вкладка "Модулі" (Рис.4.1b) містить перелік модулів підсистеми "БД", що доступні на станції.

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

Рис. 4.1a. Вкладка "Підсистема" кореневої сторінки підсистеми "БД".
Рис. 4.1b. Вкладка "Модулі" кореневої сторінки підсистеми "БД".

Кожний модуль підсистеми "БД" надає конфігураційну сторінку з вкладками "БД" та "Модуль". Вкладка "БД" (Рис.4.1c) містить перелік об'єктів БД, зареєстрованих у модулі та ознаку повного видалення БД при виконанні команди видалення. У контекстному меню переліку БД користувачу надається можливість додання, видалення та переходу до потрібної БД. У вкладці "Модуль" міститься інформація про модуль підсистеми "БД" у якості інформаційних полей кожного модуля (Рис.4.1d):

Модулі підсистеми "БД" містять також специфічне інформаційне поле "Властивості" з ключовими словами підтримуваних властивостей:

Для зберігання конфігурації OpenSCADA, модуль реалізації сховища має надавати щонайменш наступні властивості: GET, SEEK, SET, DEL. Та щоб бути багатомовним сховищем має також надавати властивість TR.

Рис. 4.1c. Вкладка "БД" модуля підсистеми "БД".
Рис. 4.1d. Вкладка "Модуль" модуля підсистеми "БД".

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

Вкладка "База даних" (Рис.4.1e) містить основні налаштування об'єкту БД, у складі:

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

Вкладка "SQL" (Рис.4.1g) доступна тільки для баз даних, що підтримують SQL-запити, та містить поле вводу запиту, кнопку надсилання запиту та таблицю з результатом запиту. Для управління режимом транзакції запиту передбачено окреме конфігураційне поле.

Рис. 4.1e. Вкладка "База даних" об'єкту БД модуля підсистеми "БД".
Рис. 4.1f. Вкладка "Таблиці" об'єкту БД модуля підсистеми "БД".
Рис. 4.1g. Вкладка "SQL" об'єкту БД модуля підсистеми "БД".

Сторінка вивчення вмісту таблиці містить тільки одну вкладку "Таблиця". Вкладка "Таблиця" (Рис.4.1h) містить поле назви таблиці та таблицю зі змістом. Таблицею вмісту надаються функції:

Рис. 4.1h. Вкладка "Таблиця" таблиці БД модуля підсистеми "БД".

4.2 Підсистема "Безпека"

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

Рис. 4.2a. Вкладка "Користувачі та групи користувачів" кореневої сторінки підсистеми "Безпека".

Для конфігурації користувача надається сторінка, що містить тільки вкладку "Користувач" (Рис.4.2b). Вкладка містить конфігураційні дані профілю користувач, які може змінювати сам користувач, користувач у групі "Security" або привілейований користувач:

Рис. 4.2b. Вкладка "Користувач" сторінки користувача підсистеми "Безпека".

Для конфігурації групи користувачів надається сторінка, що містить тільки вкладку "Група" (Рис.4.2c). Вкладка містить конфігураційні дані профілю групи користувачів, які може змінити тільки привілейований користувач:

Рис. 4.2c. Вкладка "Група" сторінки групи користувачів підсистеми "Безпека".

4.3 Підсистема "Транспорти"

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

Вкладка "Підсистема" (Рис.4.3a) містить таблицю конфігурації зовнішніх, для цієї, OpenSCADA станцій. Зовнішні станції можуть бути системними, користувацькими або одночасно, що обирається у відповідному стовпчику. Системні зовнішні станції доступні тільки привілейованому користувачу та використовуються компонентами системного призначення, наприклад, механізмом горизонтального резервування та модулем DAQ.DAQGate. Користувацькі зовнішні станції прив'язано до користувача, який їх створював, тобто перелік користувацьких зовнішніх станцій індивідуальний для кожного користувача. Користувацькі зовнішні станції використовуються компонентами графічного інтерфейсу, наприклад: UI.QTCfg, UI.WebCfgD та UI.Vision. У таблиці зовнішніх станцій можливе додання та видалення записів про станції, а також їх модифікація. Кожний запис містить поля:

Вкладка "Модулі" (Рис.4.1b) містить перелік модулів підсистеми "Транспорти" та ідентична до всіх модульних підсистем.

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

Кожний модуль підсистеми "Транспорти" надає конфігураційну сторінку з вкладками "Транспорти" та "Модуль".

Вкладка "Транспорти" (Рис.4.3b) містить перелік вхідних та вихідних транспортів, зареєстрованих модулем. У контекстному меню переліків транспортів користувачу надається можливість додання, видалення та переходу до потрібного транспорту. Вихідні транспорти також надають функцію часу життя, яка передбачає закриття транспортів за неактивністю. Встановіть це поле у 0 для вимкнення цієї функції!

У вкладці "Модуль" міститься інформація про модуль підсистеми "Транспорти" (Рис.4.1d), склад якої ідентичний до всіх модулів.

Рис. 4.3b. Вкладка "Транспорти" модуля підсистеми "Транспорти".

Кожний транспорт містить власні конфігураційні діалоги у вкладці "Транспорт" і "Додаткове". Вкладка "Транспорт" містить основні налаштування транспорту. Вхідний транспорт (Рис.4.3c) містить:

Рис. 4.3c. Вкладка "Транспорт" і "Додаткове" сторінки вхідного транспорту модуля підсистеми "Транспорти".

Вихідний транспорт (Рис.4.3d) містить:

Рис. 4.3d. Вкладка "Транспорт" і "Додаткове" сторінки вихідного транспорту модуля підсистеми "Транспорти".

Вкладка "Додаткове" обох вхідного і вихідного транспортів містить специфічні параметри типу транспорту та специфічні до протоколу користувацькі параметри. Також тут може бути скинуто усі додаткові параметри до типових значень та очищено специфічні до протоколу користувацькі параметри.

Вихідний транспорт додатково надає вкладку формування користувацького запиту через даний транспорт (Рис.4.3e). Вкладку призначено для налагодження зв'язку та протоколів обміну, та вона містить:

Рис. 4.3e. Вкладка "Запит" сторінки вихідного транспорту модуля підсистеми "Транспорти".

Вхідний та вихідний транспорти також містять вкладку "Лог ВВ" (Рис.4.3f). Вкладка надається для загального контролю, спостереження та вивчення трафіку через транспорти і включає поле логу щодо довжини, обмеження блоку, тип, час агрегації і сам текстовий простір. Для вимкнення логу можете поле довжини логу встановити у нуль (0) та -1 для запису до файлу.

Рис. 4.3f. Вкладка "Лог ВВ" сторінки вхідного транспорту модуля підсистеми "Транспорти".

4.4 Підсистема "Транспортні протоколи"

Підсистема є модульною. Для конфігурації підсистеми передбачено кореневу сторінку підсистеми "Транспортні протоколи", що містить вкладку "Модулі". Вкладка "Модулі" (Рис.4.1b) містить перелік модулів підсистеми "Транспортні протоколи" та ідентична для всіх модульних підсистем.

Кожний модуль підсистеми "Транспортні протоколи" надає конфігураційну сторінку з вкладкою "Модуль". У вкладці "Модуль" міститься інформація про модулі підсистеми "Транспортні протоколи" (Рис.4.1d), склад якої ідентичний для всіх модулів.

4.5 Підсистема "Збір даних"

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

Для отримання доступу на модифікацію об'єктів цієї підсистеми потрібні права користувача у групі "DAQ" або права привілейованого користувача.

Об'єктом резервування підсистеми "Збір Даних" виступає об'єкт контролеру у межах якого резервування даних виконує функції:

Вкладка "Резервування" (Рис.4.5a) доступна лише якщо у резерві вказано хоча-б одну станція (Рис.4c) та містить конфігурацію резервування джерел даних підсистеми "Збір даних", у складі налаштувань:

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

Вкладка "Бібліотеки шаблонів" (Рис.4.5b) містить перелік бібліотек шаблонів для параметрів цієї підсистеми. У контекстному меню переліку бібліотек шаблонів користувачу надається можливість додання, видалення та переходу до потрібної бібліотеки. Вкладка "Модулі" (Рис.4.1c) містить перелік модулів підсистеми "Транспорти" та ідентична для всіх модульних підсистем.

Рис. 4.5b. Вкладка "Бібліотеки шаблонів" підсистеми "Збір даних".

Кожна бібліотека шаблонів підсистеми "Збір даних" надає конфігураційну сторінку з вкладками "Бібліотека" та "Шаблони параметрів". Вкладка "Бібліотека" (Рис.4.5d) містить основні налаштування бібліотеки у складі:

  • Доступний — стан бібліотеки "Доступний".
  • Сховище — зберігання даних бібліотеки та її шаблонів, з відстеженням наявності даних у різних сховищах та наданням послідовного видалення дублікатів.
At.png Об'єкт все ще підтримує визначення надлишкової адреси сховку із таблицею до того часу як ви перейменуєте її у стандартну форму "tmplib_{ObjID}".
  • Дата модифікації — дата та час останньої модифікації об'єкту.
  • Ідентифікатор — інформація про ідентифікатор бібліотеки.
  • Ім'я — вказує ім'я бібліотеки.
  • Опис — короткий опис бібліотеки та її призначення.

Вкладка "Шаблони параметрів" (Рис.4.5d) містить перелік шаблонів у бібліотеці. У контекстному меню переліку користувачу надається можливість додання, видалення та переходу до потрібного шаблону.

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

Кожний шаблон бібліотеки шаблонів надає конфігураційну сторінку з вкладками "Шаблон" та "ВВ". Вкладка "Шаблон" (Рис.4.5e) містить основні налаштування шаблону у складі:

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

Вкладка "ВВ" (Рис.4.5f) містить конфігурацію атрибутів (Вхід-Вихід) шаблонів та текст програми шаблону на мові користувацького програмування OpenSCADA, наприклад, "JavaLikeCalc.JavaScript". Ознака "Перекладати програму" вказує на збереження та переклад текста програми для кожної мови (людської) окремо, що ускладнює утримання алгоритма однаковим для багатомовних конфігурацій. Цю ознаку загалом впроваджено для сумісності зі старими версіями OpenSCADA, не рекомендовано для встановлення та наразі практикується переклад конкретних текстових повідомлень у тексті програми, через функцію tr().

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

At.png Рядки ім'я після першого опрацьовуються як допомога.

З синтаксисом мови програми шаблону можна ознайомитися у документації модуля, що надає інтерпретатор обраної мови. Наприклад, типовою мовою користувацького програмування OpenSCADA є JavaLikeCalc.JavaScript.

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

Кожний модуль підсистеми "Збір даних" надає конфігураційну сторінку з вкладками "Контролери" та "Модуль". Вкладка "Контролери" (Рис.4.5g) містить перелік об'єктів контролерів, зареєстрованих у модулі. У контекстному меню переліку користувачу надається можливість додання, видалення та переходу до потрібного об'єкту контролеру. У вкладці "Модуль" міститься інформація про модуль підсистеми "Збір даних" (Рис.4.1d), склад якої ідентичний до всіх модулів.

Рис. 4.5g. Вкладка "Контролери" модуля підсистеми "Збір даних".

Кожний об'єкт контролеру містить власну сторінку конфігурації з вкладками "Контролер", "Параметри" та "Діагностика".

Вкладка "Контролер" (Рис.4.5h) містить основні налаштування. Склад цих налаштувань може дещо відрізнятися від одного модуля цієї підсистеми до іншого, про що можна дізнатися у власній документації модулів. У якості прикладу розглянемо налаштування об'єкту контролеру модуля контролера логічного рівня DAQ.LogicLev:

  • Статус — вказує на статус об'єкту контролера та самого контролеру. У нашому випадку контролер виконується, поточний час виконання складає 1.6 мілісекунди та максимальний 2.2 мілісекунди.
  • Ввімкнено — стан об'єкту контролера "Ввімкнено". Ввімкнений об'єкт контролеру надає можливість створення параметрів та їх конфігурації.
  • Виконується — стан об'єкту контролера "Виконується". Об'єкт контролеру що виконується здійснює фізичний збір даних та/або включає механізми доступу до цих даних.
At.png Деякі типи джерел даних надають можливість виконання певної частини функції переходу до стану Ввімкнено — гаряче оновлення конфігураційних даних при ручному запуску та що ви можете бачити у вигулькній підказці до цього поля.
  • Сховище — зберігання даних об'єкту контролера та його параметрів, з відстеженням наявності даних у різних сховищах та наданням послідовного видалення дублікатів. Параметри різних типів зберігаються у різних таблицях із власною структурою і уніфікованою назвою "{ModId}{TypeId}_{CntrId}", яка може бути специфічною для деяких модулів.
  • Дата модифікації — дата та час останньої модифікації об'єкту.
  • Ідентифікатор — інформація про ідентифікатор об'єкту контролера.
  • Ім'я — вказує ім'я контролеру.
  • Опис — короткий опис контролеру та його призначення.
  • Вмикати — вказує на стан "Ввімкнено" у який переводити об'єкт контролеру при запуску програми.
  • Запускати — вказує на стан "Виконується" у який переводити об'єкт контролеру при запуску програми.
  • Планування обчислення — визначає періодичний або за розкладом характер обчислення. У нашому прикладі це періодичне секундне обчислення шаблону.
  • Рівень пріоритету задачі отримання даних — встановлює пріоритет задачі збору даних цього контролеру. Використовується при плануванні задач операційною системою. У випадку наявності доступу це поле включає планування задачі контролеру у режимі реального часу та за визначеним пріоритетом інакше модифікує параметр "nice" задачі.
Рис. 4.5h. Головна вкладка конфігурації об'єкту контролеру підсистеми "Збір даних".

Вкладка "Параметри" (Рис.4.5i) містить перелік параметрів у об'єкті контролеру, надає вибір типу створюваних по замовченню параметрів, а також інформацію про загальну кількість та кількість включених параметрів. У контекстному меню переліку параметрів користувачу надається можливість додання, видалення та переходу до потрібного параметру.

Рис. 4.5i. Вкладка "Параметри" сторінки конфігурації об'єкту контролера підсистеми "Збір даних".

Вкладка "Діагностика" (Рис.4.5j) містить форму діагностичних повідомлень джерела даних. Оскільки багато джерел даних представляють собою зовнішні пристрої з доступом до даних за посередництвом мережевого обміну або системної шини то можливі різні позаштатні ситуації при доступі до даних. Вивід всіх їх у поле "Статус" об'єкту контролера неможливий оскільки він відображає лише поточний стан доступу до даних. За допомогою діагностики можна прослідкувати всі нештатні ситуації у вигляді повідомлень, сформованих даним об'єктом контролеру за визначений проміжок часу та з обраним рівнем повідомлення. Крім безпосередньо робочої діагностичної інформації низка модулів джерел даних можуть надавати тут різні налагоджувальні дампи обміну, на рівні повідомлень "Налагодження (0)".

Рис. 4.5j. Вкладка "Діагностика" сторінки конфігурації об'єкту контролера підсистеми "Збір даних".

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

Вкладка "Параметр" (Рис.4.5k) містить основні налаштування у складі:

Рис. 4.5k. Головна вкладка конфігурації параметру об'єкта контролера підсистеми "Збір даних".

Вкладка "Атрибути" (Рис.4.5l) містить атрибути параметру та їх значення згідно до конфігурації використаного шаблона та обчислення його програми.

Рис. 4.5l. Вкладка "Атрибути" параметру об'єкта контролера підсистеми "Збір даних".

Вкладка "Архівація" (Рис.4.5m) містить таблицю з атрибутами параметру у рядках та архіваторами у стовпчиках. Користувач має можливість встановити архівацію потрібного атрибуту потрібним архіватором просто змінивши клітинку на перетині.

Рис. 4.5m. Вкладка "Архівація" параметру об'єкта контролера підсистеми "Збір даних".

Вкладка "Включення" (Fig.4.5n) містить перелік параметрів ієрархічно включених до іншого параметру, надає інформацію про загальну кількість та кількість включених параметрів. У контекстному меню користувач може додати, видалити та перейти до потрібного параметру. Включення параметрів підтримується більшістю джерел даних та глибину включення типово обмежено 10 рівнями!

Fig. 4.5n. Вкладка "Включення" параметру об'єкту контролеру підсистеми "Збір даних".

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

Рис. 4.5o. Вкладка "Конфігурація шаблону" параметру об'єкта контролера підсистеми "Збір даних".

4.6 Підсистема "Архіви-Історія"

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

Для отримання доступу на модифікацію об'єктів цієї підсистеми потрібні права користувача у групі "Archive" або права привілейованого користувача.

Об'єктом резервування підсистеми "Архіви-Історія" виступає об'єкт архіватору повідомлень у межах якого резервування даних виконує функції:

  1. запит всіх активних порушень;
  2. запит повідомлень конкретного архіву на глибину, вказану параметром "Глибина примусового перевантаження історії резерву при запуску", та по час попереднього запиту, тобто коли нові активні порушення напевне не з'являться;
  3. перехід у нормальний режим відстеження нових повідомлень та порушень через архів.

Резервування архіваторів значень не надається безпосередньо через здійснення цього процесу у джерелах даних та підсистемі збору даних.

Вкладка "Резервування" (Рис.4.6a) доступна тільки якщо у резерві вказано хоча-б одну станцію (Рис.4c) та містить конфігурацію резервування архіваторів повідомлень підсистеми "Архіви-Історія", у складі налаштувань:

Рис. 4.6a. Вкладка "Резервування" підсистеми "Архіви-Історія".

Вкладка "Повідомлення" (Рис.4.6b) містить конфігурацію архіву повідомлень та форму запиту повідомлень з нього.

Конфігурацію архіву повідомлень представлено полями:

Форма запиту повідомлень містить конфігураційні поля запиту та таблицю результату. Конфігураційні поля запиту:

Таблиця результату містить рядки повідомлень у стовпчиках:

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

Рис. 4.6b. Вкладка "Повідомлення" підсистеми "Архіви-Історія".

Вкладка "Значення" (Рис.4.6c) містить загальну конфігурацію архівування значень та перелік архівів значень. У контекстному меню переліку значень користувачу надається можливість додання, видалення та переходу до потрібного архіву. Загальну конфігурацію архівування представлено полями:

Рис. 4.6c. Вкладка "Значення" підсистеми "Архіви-Історія".

Вкладка "Модулі" (Рис.4.1b) містить перелік модулів підсистеми "Архіви-Історія" та ідентична для всіх модульних підсистем.

Архів значень підсистеми "Архіви-Історія" надає конфігураційну сторінку з вкладками "Архів", "Архіватори" та "Значення".

Вкладка "Архів" (Рис.4.6d) містить основні налаштування архіву у складі:

Рис. 4.6d. Основна вкладка конфігурації архіву значень підсистеми "Архіви-Історія".

Вкладка "Архіватори" (Рис.4.6e) містить таблицю з конфігурацією процесу обробки даного архіву доступними архіваторами. У рядках розташовано доступні архіватори, а у стовпчиках параметри:

Рис. 4.6e. Вкладка "Архіватори" архіву значень підсистеми "Архіви-Історія".

Вкладка "Значення" (Рис.4.6f) містить запит значень у архіві та результат у вигляді таблиці значень або зображення тренду. Запит значень місить поля:

Рис. 4.6f. Вкладка "Значення" архіву значень підсистеми "Архіви-Історія".

Кожний модуль підсистеми "Архіви-Історія" надає конфігураційну сторінку з вкладками "Архіватори" та "Модуль". Вкладка "Архіватори" (Рис.4.6g) містить переліки архіваторів повідомлень та значень, зареєстрованих у модулі. У контекстному меню переліків користувачу надається можливість додання, видалення та переходу до потрібного архіватору. На вкладці "Модуль" міститься інформація про модуль підсистеми "Архіви-Історія" (Рис.4.1d), склад якої ідентичний для всіх модулів.

Рис. 4.6g. Вкладка "Архіватори" модуля підсистеми "Архіви-Історія".

Архіватори повідомлень містять власну сторінку конфігурації з вкладками "Архіватор" та "Повідомлення".

Вкладка "Архіватор" (Рис.4.6h) містить основні налаштування. Склад цих налаштувань може дещо відрізнятися від модуля до модуля цієї підсистеми про що можна дізнатися у власній документації модулів. У якості прикладу розглянемо налаштування архіватору повідомлень у модулі архівування на файлову систему Arch.FSArch:

Рис. 4.6h. Головна вкладка конфігурації архіватору повідомлень підсистеми "Архіви-Історія".

Вкладка "Повідомлення" (Рис.4.6i) містить форму запиту повідомлень з архіву даного архіватору:

Таблиця результату містить рядки повідомлень у стовпчиках:

Рис. 4.6i. Вкладка запиту повідомлень "Повідомлення" архіватору повідомлень підсистеми "Архіви-Історія".

Архіватори значень містять власну сторінку конфігурації з вкладками "Архіватор" та "Архіви".

Вкладка "Архіватор" (Рис.4.6j) містить основні налаштування. Склад цих налаштувань може дещо відрізнятися від модуля до модуля цієї підсистеми про що можна дізнатися у власній документації модулів. У якості прикладу розглянемо налаштування архіватору значень у модулі архівування на файлову систему Arch.FSArch:

Рис. 4.6j. Головна вкладка конфігурації архіватору значень підсистеми "Архіви-Історія".

Вкладка "Архіви" (Рис.4.6k) містить таблицю з інформацією про архіви, що обробляються архіватором. Таблиця у рядках містить архіви, а у стовпчиках інформацію:

У випадку з модулем Arch.FSArch у цій вкладці ще міститься форма експорту даних архіватору.

Рис. 4.6k. Вкладка "Архіви" архіватору значень підсистеми "Архіви-Історія".

4.7 Підсистема "Користувацькі інтерфейси"

Підсистема є модульною. Для конфігурації підсистеми передбачено кореневу сторінку підсистеми "Користувацькі інтерфейси", яка містить вкладку "Підсистема" та вкладку "Модулі". Вкладка "Підсистема" (Рис.4.7a) наразі містить лише конфігураційне поле встановлення шрифту підсвітлення синтаксису коду. Вкладка "Модулі" (Рис.4.1b) містить перелік модулів підсистеми "Спеціальні" та ідентична для всіх модульних підсистем.

Fig. 4.7a. Вкладка "Підсистема" кореневої сторінки "Користувацькі інтерфейси".

Кожний модуль підсистеми "Користувацькі інтерфейси" надає конфігураційну сторінку з вкладками "Користувацький інтерфейс" та "Модуль". Вкладка "Користувацький інтерфейс" (Рис.4.7b) надає параметр для контролю за станом "Виконується" модуля, а також розділи конфігурації, спеціалізовані для модулів цієї підсистеми. У вкладці "Модуль" міститься інформація про модуль підсистеми "Користувацькі інтерфейси" (Рис.4.1d), склад якої ідентичний для всіх модулів.

Рис. 4.7b. Вкладка "Користувацький інтерфейс" модуля підсистеми "Користувацькі інтерфейси".

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

4.8 Підсистема "Спеціальні"

Підсистема є модульною. Для конфігурації підсистеми передбачено кореневу сторінку підсистеми "Спеціальні", що містить вкладку "Модулі". Вкладка "Модулі" (Рис.4.1b) містить перелік модулів підсистеми "Спеціальні" та ідентична для всіх модульних підсистем.

Кожний модуль підсистеми "Спеціальні" надає конфігураційну сторінку з вкладками "Спеціальний" та "Модуль". Вкладка "Спеціальний" (Рис.4.8) надає параметр для контролю за станом "Виконується" модуля, а також розділи конфігурації, спеціалізовані для модулів цієї підсистеми. У вкладці "Модуль" міститься інформація про модуль підсистеми "Спеціальні" (Рис.4.1d), склад якої ідентичний для всіх модулів.

Рис. 4.8. Вкладка "Спеціальний" модуля підсистеми "Спеціальні".

4.9 Підсистема "Диспетчер модулів"

Підсистема не є модульною. Для конфігурації підсистеми "Диспетчер модулів" передбачено сторінку підсистеми, що містить вкладку "Підсистема". Вкладка "Підсистема" (Рис.4.9) містить основні налаштування підсистеми у складі:

Рис. 4.9. Головна вкладка конфігурації підсистеми "Диспетчер модулів".

4.10 Конфігураційний Файл та параметри командного рядку

Конфігураційний Файл OpenSCADA призначено для зберігання основної конфігурації станції OpenSCADA. Лише у Конфігураційному Файлі та через параметри командного рядка можна вказати частину ключових параметрів станції, тому знайомство зі структурою Конфігураційного Файлу необхідне фахівцям, що розгортають специфічні рішення на основі OpenSCADA. Більше інформації із запуску та виконання OpenSCADA може бути знайдено у секції "Запуск та виконання".

Структурно Конфігураційний Файл організовано на розширювальній мові розмітки тексту XML. Відповідно вимагається суворе дотримання правил синтаксису XML. Показовий приклад Конфігураційного Файлу OpenSCADA з прикладами конфігурації більшості компонентів OpenSCADA, наведено ...

<?xml version='1.0' encoding='UTF-8' ?>
<OpenSCADA>
    <!--
    This is the OpenSCADA configuration file.
    -->
    <station id="SimulatorStation">
        <!--
        Description of the internal parameters of the station.
        The station is the OpenSCADA program.
        -->
        <prm id="StName">AGLKS</prm>
        <prm id="WorkDB">SQLite.GenDB</prm>
        <prm id="LogTarget">10</prm>
        <prm id="LangBase">en_US.UTF-8;uk_UA.UTF-8;ru_RU.UTF-8</prm>
        <prm id="SaveAtExit">0</prm>
        <prm id="SavePeriod">0</prm>

        <node id="sub_BD">
            <tbl id="DB">
                <fld ID="GenDB" TYPE="SQLite" NAME="Generic DB" NAME_uk="Основна БД" NAME_ru="Основная БД" ADDR="St.db" CODEPAGE="UTF-8" />
            </tbl>
        </node>

        <node id="sub_Security">
            <tbl id="Security_user">
                <fld NAME="roman" DESCR="Roman Savochenko" PASS="$1$roman$wleNCf/uyA84cGpBn5QuG." />
                <fld NAME="root" DESCR="Administrator (superuser)!!!" DESCR_uk="Супер користувач" DESCR_ru="Супер пользователь" PASS="$1$root$lCn57dP9yzkCIAyrwJ24r1" />
                <fld NAME="test" DESCR="Test user" PASS="$1$test$pi/xDtU5WFVRqYS6BMU8X/" />
                <fld NAME="user" DESCR="Simple user" DESCR_uk="Звичайний користувач" DESCR_ru="Простой пользователь" PASS="$1$user$k8sntSoh7jhsc6lwspjsU." />
            </tbl>
            <tbl id="Security_grp">
                <fld NAME="Archive" DESCR="Archives-History" DESCR_uk="Архіви-Історія" DESCR_ru="Архивы-История" />
                <fld NAME="BD" DESCR="Databases" DESCR_uk="Бази даних" DESCR_ru="Базы данных" />
                <fld NAME="DAQ" DESCR="Data acquisition" DESCR_uk="Збір даних" DESCR_ru="Сбор данных" />
                <fld NAME="ModSched" DESCR="Modules scheduler" DESCR_uk="Диспетчер модулів" DESCR_ru="Диспетчер модулей" />
                <fld NAME="Protocol" DESCR="Transport protocols" DESCR_uk="Транспортні протоколи" DESCR_ru="Транспортные протоколы" />
                <fld NAME="Security" DESCR="Security" DESCR_uk="Безпека" DESCR_ru="Безопасность" />
                <fld NAME="Special" DESCR="Specials" DESCR_uk="Спеціальні" DESCR_ru="Специальные" />
                <fld NAME="Transport" DESCR="Transports" DESCR_uk="Транспорти" DESCR_ru="Транспорты" />
                <fld NAME="UI" DESCR="User Interfaces" DESCR_uk="Інтерфейси користувача" DESCR_ru="Интерфейсы пользователя" />
                <fld NAME="root" DESCR="Administartors group" DESCR_uk="Група адміністраторів" DESCR_ru="Группа администраторов" USERS="roman;" />
                <fld NAME="users" DESCR="Users group" DESCR_uk="Група користувачів" DESCR_ru="Группа пользователей" USERS="test;user;" />
                <fld NAME="ITW" DESCR="IT worker" DESCR_uk="Робітник IT" DESCR_ru="Работник IT"
                    LONGDESCR="Information Technology or service worker."
                    LONGDESCR_uk="Робітник Інформаційних Технологій та сервісу."
                    LONGDESCR_ru="Работник Информационных Технологий и сервиса." />
                <fld NAME="op" DESCR="Operator" DESCR_uk="Оператор" DESCR_ru="Оператор" />
            </tbl>
        </node>

        <node id="sub_ModSched">
            <prm id="ModAllow">*</prm>
            <prm id="ModDeny" />
            <prm id="ChkPer">0</prm>
        </node>

        <node id="sub_Transport">
            <tbl id="ExtTansp">
                <fld OP_USER="roman" ID="loop" NAME="Loop" NAME_uk="Петля" NAME_ru="Петля" TRANSP="Sockets" ADDR="TCP:localhost:10005" USER="roman" PASS="roman" />
                <fld OP_USER="*" ID="loop" NAME="Loop" NAME_uk="Петля" NAME_ru="Петля" TRANSP="Sockets" ADDR="TCP:localhost:10005" USER="roman" PASS="roman" />
                <fld OP_USER="roman" ID="loopSSL" NAME="Loop SSL" NAME_uk="Петля SSL" NAME_ru="Петля SSL" TRANSP="SSL" ADDR="localhost:10045" USER="roman" PASS="roman" />
                <fld OP_USER="*" ID="loopSSL" NAME="Loop SSL" NAME_uk="Петля SSL" NAME_ru="Петля SSL" TRANSP="SSL" ADDR="localhost:10045" USER="roman" PASS="roman" />
            </tbl>
            <tbl id="Transport_in">
                <fld ID="Self" MODULE="Sockets" NAME="Self system" DESCRIPT="Main transport of OpenSCADA self protocol."
                        DESCRIPT_uk="Основний транспорт власного протоколу OpenSCADA." DESCRIPT_ru="Основной транспорт собственного протокола OpenSCADA." ADDR="TCP::10005:1" PROT="SelfSystem" START="1">
                    <A_PRMS>&amp;lt;prms MaxQueue="10" MaxClients="20" MaxClientsPerHost="5" BufLen="5" KeepAliveReqs="0" KeepAliveTm="60" /&amp;gt;</A_PRMS>
                </fld>
                <fld ID="WEB_1" MODULE="Sockets" NAME="WEB 1" DESCRIPT="Main transport of the WEB interfaces."
                        DESCRIPT_uk="Основний транспорт WEB інтерфейсів." DESCRIPT_ru="Основной транспорт WEB интерфейсов." ADDR="TCP::10002:0" PROT="HTTP" START="1">
                    <A_PRMS>&amp;lt;prms MaxQueue="10" MaxClients="100" MaxClientsPerHost="25" BufLen="5" KeepAliveReqs="0" KeepAliveTm="5" /&amp;gt;</A_PRMS>
                </fld>
                <fld ID="WEB_2" MODULE="Sockets" NAME="WEB 2" DESCRIPT="Reserve transport of the WEB interfaces."
                        DESCRIPT_uk="Резервний транспорт WEB інтерфейсів." DESCRIPT_ru="Резервный транспорт WEB интерфейсов." ADDR="TCP::10004:0" PROT="HTTP" START="1">
                    <A_PRMS>&amp;lt;prms MaxQueue="10" MaxClients="100" MaxClientsPerHost="25" BufLen="5" KeepAliveReqs="0" KeepAliveTm="5" /&amp;gt;</A_PRMS>
                </fld>
            </tbl>
            <!--
            <tbl id="Transport_out">
                <fld
                    ID="testModBus"
                    MODULE="Sockets"
                    NAME="Test ModBus"
                    NAME_uk="Тест ModBus"
                    NAME_ru="Тест ModBus"
                    DESCRIPT="ModBus protocol exchange test."
                    DESCRIPT_uk="Тест обміну за протоколом ModBus."
                    DESCRIPT_ru="Тест обмена по протоколу ModBus."
                    ADDR="TCP:localhost:10502"
                    START="1"/>
            </tbl>-->
        </node>

        <node id="sub_DAQ">
            <!--
            <tbl id="tmplib">
                <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" DB="tmplib_test2"/>
            </tbl>
            <tbl id="tmplib_test2">
                <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR=""
                    PROGRAM="JavaLikeCalc.JavaScript&amp;#010;cnt=5*i;"/>
            </tbl>
            <tbl id="tmplib_test2_io">
                <fld TMPL_ID="test2" ID="i" NAME="I" NAME_uk="I" NAME_ru="I" TYPE="4" FLAGS="160" VALUE="" POS="0"/>
                <fld TMPL_ID="test2" ID="cnt" NAME="Cnt" NAME_uk="Cnt" NAME_ru="Cnt" TYPE="4" FLAGS="32" VALUE="" POS="0"/>
            </tbl>-->

            <node id="mod_LogicLev">
                <!--
                <tbl id="DAQ">
                    <fld
                        ID="test2"
                        NAME="Test 2"
                        NAME_uk="Тест 2"
                        NAME_ru="Тест 2"
                        DESCR=""
                        ENABLE="1"
                        START="1"
                        PRM_BD="test2prm"
                        PERIOD="1000"
                        PRIOR="0"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR=""
                        EN="1" MODE="2" PRM="test2.test2"/>
                </tbl>-->
            </node>

            <node id="mod_System">
                <!--
                <tbl id="DAQ">
                    <fld
                        ID="dataOS"
                        NAME="OS data"
                        NAME_uk="Дані ОС"
                        NAME_ru="Даные ОС"
                        DESCR="Data of services and subsystems of OS."
                        DESCR_uk="Дані сервісів та підсистем ОС."
                        DESCR_ru="Данные сервисов и подсистем ОС."
                        ENABLE="1"
                        START="1"
                        AUTO_FILL="0"
                        PRM_BD="DataOSprm"
                        PERIOD="1000"
                        PRIOR="0"/>
                </tbl>
                <tbl id="DataOSprm">
                    <fld SHIFR="CPU" NAME="CPU load" NAME_uk="Навантаження CPU" NAME_ru="Нагрузка CPU" DESCR=""
                        EN="1" TYPE="CPU" SUBT="gen"/>
                    <fld SHIFR="MEM" NAME="Memory" NAME_uk="Пам'ять" NAME_ru="Память" DESCR="" EN="1" TYPE="MEM"/>
                </tbl>
                -->
            </node>

            <node id="mod_DiamondBoards">
                <!--
                <tbl id="DAQ">
                    <fld ID="Athena" NAME="Athena board" NAME_uk="Плата Athena" NAME_ru="Плата Athena" DESCR=""
                        ENABLE="1" START="0" BOARD="25" PRM_BD_A="AthenaAnPrm" PRM_BD_D="AthenaDigPrm" ADDR="640" INT="5"
                        DIO_CFG="0" ADMODE="0" ADRANGE="0" ADPOLAR="0" ADGAIN="0" ADCONVRATE="1000"/>
                </tbl>
                <tbl id="AthenaAnPrm">
                    <fld SHIFR="ai0" NAME="AI 0" NAME_uk="AI 0" NAME_ru="AI 0" DESCR="" EN="0" TYPE="0" CNL="0" GAIN="0"/>
                </tbl>
                <tbl id="AthenaDigPrm">
                    <fld SHIFR="di0" NAME="DI 0" NAME_uk="DI 0" NAME_ru="DI 0" DESCR="" EN="0" TYPE="0" PORT="0" CNL="0"/>
                </tbl>
                -->
            </node>

            <node id="mod_BlockCalc">
                <!--
                <tbl id="DAQ">
                    <fld ID="Model" NAME="Model" NAME_uk="Модель" NAME_ru="Модель" DESCR=""
                        ENABLE="1" START="1" PRM_BD="Model_prm" BLOCK_SH="Model_blcks" PERIOD="1000" PRIOR="0" PER_DB="0" ITER="1"/>
                </tbl>
                <tbl id="Model_blcks">
                    <fld ID="Klap" NAME="Klapan" NAME_uk="Клапан" NAME_ru="Клапан" DESCR=""
                        FUNC="DAQ.JavaLikeCalc.lib_techApp.klap" EN="1" PROC="1"/>
                </tbl>
                <tbl id="Model_blcks_io">
                    <fld BLK_ID="Klap" ID="l_kl1" TLNK="0" LNK="" VAL="50"/>
                    <fld BLK_ID="Klap" ID="l_kl2" TLNK="0" LNK="" VAL="20"/>
                </tbl>
                <tbl id="Model_prm">
                    <fld SHIFR="l_kl" NAME="Klap level" NAME_uk="Положення клапану" NAME_ru="Положение клапана" DESCR=""
                        EN="1" IO="Klap.l_kl1"/>
                </tbl>
                -->
            </node>

            <node id="mod_JavaLikeCalc">
                <!--
                <tbl id="DAQ">
                    <fld ID="CalcTest" NAME="Calculation test" NAME_uk="Тест обчислення" NAME_ru="Тест вычисления" DESCR=""
                        ENABLE="1" START="1" PRM_BD="CalcTest_prm" FUNC="TemplFunc.d_alarm" SCHEDULE="1" PRIOR="0" ITER="1"/>
                </tbl>
                <tbl id="CalcTest_val">
                    <fld ID="in" VAL="0"/>
                    <fld ID="alrm" VAL=""/>
                    <fld ID="alrm_md" VAL="1"/>
                    <fld ID="alrm_mess" VAL="Error present."/>
                </tbl>
                <tbl id="CalcTest_prm">
                    <fld SHIFR="alrm" NAME="Alarm" NAME_uk="Аварія" NAME_ru="Авария" DESCR="" EN="1" FLD="alrm"/>
                </tbl>
                <tbl id="lib">
                    <fld ID="TemplFunc" NAME="" DESCR="" DB="lib_TemplFunc"/>
                </tbl>
                <tbl id="lib_TemplFunc">
                    <fld ID="d_alarm" NAME="Digit alarm" NAME_uk="Аварія за дискретним" NAME_ru="Авария по дискретному" DESCR=""
                        FORMULA="alrm=(in==alrm_md)?&amp;quot;1:&amp;quot;+alrm_mess:&amp;quot;0&amp;quot;;"/>
                </tbl>
                <tbl id="lib_TemplFunc_io">
                    <fld F_ID="d_alarm" ID="in" NAME="Input" NAME_uk="Вхід" NAME_ru="Вход" TYPE="3" MODE="0" DEF="" HIDE="0" POS="0"/>
                    <fld F_ID="d_alarm" ID="alrm" NAME="Alarm" NAME_uk="Аварія" NAME_ru="Авария" TYPE="0" MODE="1" DEF="" HIDE="0" POS="1"/>
                    <fld F_ID="d_alarm" ID="alrm_md" NAME="Alarm mode" NAME_uk="Режим аварії" NAME_ru="Режим аварии"
                        TYPE="3" MODE="0" DEF="" HIDE="0" POS="2"/>
                    <fld F_ID="d_alarm" ID="alrm_mess" NAME="Alarm message" NAME_uk="Повідомлення аварії" NAME_ru="Сообщение аварии"
                        TYPE="0" MODE="0" DEF="" HIDE="0" POS="3"/>
                </tbl>-->
            </node>

            <node id="mod_Siemens">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1000" PRIOR="0" CIF_DEV="0" ADDR="5" ASINC_WR="0"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1" TMPL="S7.ai_man"/>
                </tbl>-->
            </node>

            <node id="mod_SNMP">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR=""
                        ENABLE="1" START="1" PRM_BD="test2prm" PERIOD="1000" PRIOR="0" ADDR="localhost" COMM="public" PATTR_LIM="20"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1" OID_LS="system"/>
                </tbl>-->
            </node>

            <node id="mod_ModBus">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1000" PRIOR="0" TRANSP="Sockets" ADDR="exlar.diya.org" NODE="1"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1"
                        ATTR_LS="321:0:tst:Test"/>
                </tbl>-->
            </node>

            <node id="mod_DAQGate">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1000" PRIOR="0" SYNCPER="60" STATIONS="loop" CNTRPRM="System.AutoDA"/>
                </tbl>-->
            </node>

            <node id="mod_DCON">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1" PRIOR="0" ADDR="" REQ_TRY="1"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1" MOD_TP="0"
                        MOD_ADDR="1" CRC_CTRL="1"/>
                </tbl>-->
            </node>

            <node id="mod_ICP_DAS">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1" PRIOR="0" BUS="1" BAUD="115200" LP_PRMS="" REQ_TRY="3"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1"
                        MOD_TP="552985" MOD_ADDR="0" MOD_SLOT="1" MOD_PRMS="0"/>
                </tbl>-->
            </node>

            <node id="mod_OPC_UA">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" ENABLE="1" START="1"
                        PRM_BD="test2prm" SCHEDULE="1" PRIOR="0" SYNCPER="60" ADDR="" EndPoint="opc.tcp://localhost:4841" SecPolicy="None"
                        SecMessMode="1" Cert="" PvKey="" AttrsLimit="100"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1" ND_LS=""/>
                </tbl>-->
            </node>

            <node id="mod_SoundCard">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" ENABLE="1" START="1"
                        PRM_BD="test2prm" CARD="" SMPL_RATE="8000" SMPL_TYPE="1"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1" CHANNEL="0"/>
                </tbl>-->
            </node>
        </node>

        <node id="sub_Archive">
            <prm id="MessBufSize">1000</prm>
            <prm id="MessPeriod">5</prm>
            <prm id="ValPeriod">1000</prm>
            <prm id="ValPriority">10</prm>
            <!--
            <tbl id="Archive_mess_proc">
                <fld
                    ID="StatErrors"
                    MODUL="FSArch"
                    NAME="Errors"
                    NAME_uk="Помилки"
                    NAME_ru="Ошибки"
                    DESCR="Archive of local errors"
                    DESCR_uk="Архів локальних помилок"
                    DESCR_ru="Архив локальных ощибок"
                    START="1"
                    CATEG="/DemoStation*"
                    LEVEL="4"
                    ADDR="ARCHIVES/MESS/stError/"/>
                <fld
                    ID="NetRequsts"
                    MODUL="FSArch"
                    NAME="Network requests"
                    NAME_uk="Мережеві запити"
                    NAME_ru="Сетевые запросы"
                    DESCR="Requests to the server via Sockets transport."
                    DESCR_uk="Запити до сервера через транспорт Sockets."
                    DESCR_ru="Запросы к серверу через транспорт Sockets."
                    START="1"
                    CATEG="/DemoStation/Transport/Sockets*"
                    LEVEL="1"
                    ADDR="ARCHIVES/MESS/Net/"/>
            </tbl>
            <tbl id="Archive_val_proc">
                <fld
                    ID="1h"
                    MODUL="FSArch"
                    NAME="1hour"
                    NAME_uk="1година"
                    NAME_ru="1час"
                    DESCR="Averaging at hour"
                    DESCR_uk="Усереднення за годину"
                    DESCR_ru="Усреднение за час"
                    START="1"
                    ADDR="ARCHIVES/VAL/1h/"
                    V_PER="360"
                    A_PER="60"/>
            </tbl>
            <tbl id="Archive_val">
                <fld
                    ID="test1"
                    NAME="Test 1"
                    NAME_uk="Тест 1"
                    NAME_ru="Тест 1"
                    DESCR="Test 1"
                    DESCR_uk="Тест 1"
                    DESCR_ru="Тест 1"
                    START="1"
                    VTYPE="1"
                    BPER="1"
                    BSIZE="200"
                    BHGRD="1"
                    BHRES="0"
                    SrcMode="0"
                    Source=""
                    ArchS=""/>
            </tbl>-->
        </node>

        <node id="sub_Protocol">
        </node>

        <node id="sub_UI">
            <node id="mod_QTStarter">
                <prm id="StartMod">QTCfg</prm>
                <prm id="CloseToTray">0</prm>
                <prm id="Style"></prm>
                <prm id="Palette"></prm>
                <prm id="StyleSheets"></prm>
                <tbl id="LookFeel">
                    <fld NAME="Typical TDE" STYLE="" STL_SHTS="">
                        <PALETTE>#000000, #dddfe4, #ffffff, #ffffff, #555555, #c7c7c7, #000000, #ffffff, #000000, #ffffff, #efefef, #000000, #678db2, #ffffff, #0000ee, #52188b
#808080, #dddfe4, #ffffff, #ffffff, #555555, #c7c7c7, #c7c7c7, #ffffff, #808080, #ffffff, #efefef, #000000, #567594, #ffffff, #0000ee, #52188b
#000000, #dddfe4, #ffffff, #ffffff, #555555, #c7c7c7, #000000, #ffffff, #000000, #ffffff, #efefef, #000000, #678db2, #ffffff, #0000ee, #52188b</PALETTE>
                    </fld>
                    <fld NAME="Blue Slate" STYLE="" STL_SHTS="">
                        <PALETTE>#000000, #9db9c8, #f6fcff, #c9dae3, #4e5c64, #697b85, #000000, #bfe2f4, #000000, #c3c3c3, #9db9c8, #000000, #558097, #ffffff, #0000ee, #52188b, #b4b4b4, #000000, #ffffdc, #000000
#808080, #9db9c8, #f6fcff, #b5d5e6, #4e5c64, #697b85, #808080, #bfe2f4, #808080, #c3c3c3, #9db9c8, #000000, #558097, #808080, #0000ee, #52188b, #b4b4b4, #000000, #ffffdc, #000000
#000000, #9db9c8, #f6fcff, #b5d5e6, #4e5c64, #697b85, #000000, #bfe2f4, #000000, #c3c3c3, #9db9c8, #000000, #558097, #ffffff, #0000ee, #52188b, #b4b4b4, #000000, #ffffdc, #000000</PALETTE>
                    </fld>
                    <fld NAME="Blue Darkness" STYLE="" STL_SHTS="">
                        <PALETTE>#ffffff, #426794, #5788c3, #4871a2, #162231, #37567b, #dcdcdc, #5788c3, #ffffff, #002a4e, #426794, #000000, #5cb3ff, #000000, #00ffff, #c0c0ff
#555555, #426794, #5788c3, #4871a2, #162231, #37567b, #37567b, #5788c3, #555555, #002a4e, #426794, #000000, #4c95d4, #ffffff, #00ffff, #c0c0ff
#ffffff, #426794, #5788c3, #4871a2, #162231, #37567b, #dcdcdc, #5788c3, #ffffff, #002a4e, #426794, #000000, #5cb3ff, #000000, #00ffff, #c0c0ff</PALETTE>
                    </fld>
                </tbl>
            </node>
            <node id="mod_QTCfg">
                <prm id="StartUser">roman</prm>
            </node>
            <node id="mod_Vision">
                <prm id="StartUser">roman</prm>
            </node>
            <node id="mod_WebCfg">
                <prm id="SessTimeLife">20</prm>
            </node>
            <node id="mod_VCAEngine">
                <!--
                <tbl id="LIB">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR=""
                        DB_TBL="wlib_test2" ICO="" USER="root" GRP="UI" PERMIT="436"/>
                </tbl>
                <tbl id="wlib_test2">
                    <fld ID="test2" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" PROC_PER="-1"
                        USER="root" GRP="UI" PERMIT="436"/>
                </tbl>
                <tbl id="wlib_test2_io">
                    <fld IDW="test2" ID="name" IO_VAL="Test 2" IO_VAL_uk="Тест 2" IO_VAL_ru="Тест 2" SELF_FLG="" CFG_TMPL="" CFG_VAL=""/>
                    <fld IDW="test2" ID="dscr" IO_VAL="Test of the module 2" IO_VAL_uk="Тест модуля 2" IO_VAL_ru="Тест модуля 2" SELF_FLG="" CFG_TMPL="" CFG_VAL=""/>
                </tbl>
                <tbl id="PRJ">
                    <fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" DB_TBL="prj_test2" ICO="" USER="root" GRP="UI" PERMIT="436"/>
                </tbl>
                <tbl id="prj_test2">
                    <fld OWNER="/test2" ID="pg1" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" PROC_PER="-1" USER="root" GRP="UI" PERMIT="436" FLGS="1"/>
                    <fld OWNER="/test2/pg1" ID="pg2" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" PROC_PER="-1" USER="root" GRP="UI" PERMIT="436" FLGS="0"/>
                </tbl>
                <tbl id="prj_test2_incl">
                    <fld IDW="/prj_test2/pg_pg1" ID="wdg1" PARENT="/wlb_originals/wdg_Box"/>
                </tbl>-->
            </node>
        </node>

        <node id="sub_Special">
            <node id="mod_SystemTests">
                <prm id="Param" on="0" per="5" name="LogicLev.experiment.F3" />
                <prm id="XML" on="0" per="10" file="/etc/oscada.xml" />
                <prm id="Mess" on="0" per="10" arhtor="DBArch.test3" depth="10" />
                <prm id="SOAttach" on="0" per="20" name="../../lib/openscada/daq_LogicLev.so" mode="0" full="1" />
                <prm id="Val" on="0" per="1" name="LogicLev.experiment.F3.var" arch_len="5" arch_per="1000000" />
                <prm id="Val" on="0" per="1" name="System.AutoDA.CPULoad.load" arch_len="10" arch_per="1000000" />
                <prm id="DB" on="0" per="10" type="MySQL" addr="server.diya.org;roman;123456;oscadaTest" table="test" size="1000" />
                <prm id="DB" on="0" per="10" type="DBF" addr="./DATA/DBF" table="test.dbf" size="1000" />
                <prm id="DB" on="0" per="10" type="SQLite" addr="./DATA/test.db" table="test" size="1000" />
                <prm id="DB" on="0" per="10" type="FireBird" addr="server.diya.org:/var/tmp/test.fdb;roman;123456" table="test" size="1000" />
                <prm id="TrOut" on="0" per="1" addr="TCP:127.0.0.1:10001" type="Sockets" req="time" />
                <prm id="TrOut" on="0" per="1" addr="UDP:127.0.0.1:10001" type="Sockets" req="time" />
                <prm id="TrOut" on="0" per="1" addr="UNIX:./oscada" type="Sockets" req="time" />
                <prm id="TrOut" on="0" per="1" addr="UDP:127.0.0.1:daytime" type="Sockets" req="time" />
                <prm id="SysContrLang" on="0" per="10" path="/Archive/FSArch/mess_StatErrors/%2fprm%2fst" />
                <prm id="ValBuf" on="0" per="5" />
                <prm id="Archive" on="0" per="30" arch="test1" period="1000000" />
                <prm id="Base64Code" on="0" per="10" />
            </node>
        </node>
  </station>

</OpenSCADA>

Детально розглянемо структуру конфігураційного файлу. Один конфігураційний файл може містити конфігурацію декількох станцій у секціях <station id="SimulatorStation"/>. Атрибутом "id" вказується ідентифікатор станції — клас станції. Використання тієї або іншої секції станції вказується параметром командного рядку --station=SimulatorStation, при виклику. Секція станції безпосередньо містить параметри станції та секції підсистем. Параметри конфігурації секції записуються у вигляді <prm id="StName">AGLKS</prm>, де атрибутом "id" вказується ідентифікатор параметру, а у тілі тегу "prm" вказується значення параметру "AGLKS". Перелік доступних параметрів та їх опис для станції та всіх інших секцій можна отримати у консолі, за посередництвом виклику OpenSCADA з параметром --help.

Секції підсистем <node id="sub_DAQ" /> містять: параметри підсистеми, секції модулів та секції таблиць відображення даних баз даних у конфігураційному файлі. Секції модулів <node id="mod_DiamondBoards" /> містять індивідуальні параметри модулів та секції таблиць відображення даних баз даних у конфігураційному файлі.

Секції таблиць відображення даних баз даних призначено для розташування у конфігураційному файлі записів таблиць БД для компонентів OpenSCADA. Розглянемо таблицю вхідних транспортів "Transport_in" підсистеми "Транспорти" <node id="sub_Transport"> з наведеного вище прикладу конфігураційного. Таблиця містить три записи з полями: ID, MODULE, NAME, DESCRIPT, ADDR, PROT, START. Після завантаження з такою секцією та взагалі без БД у підсистемі "Транспорти" модуля "Sockets" з'являться три вхідних транспорти. Формати структур таблиць основних компонентів включено до демонстраційних конфігураційних файлів — моделі технологічних процесів. За деталями структур таблиць БД звертайтеся до документації відповідних модулів або просто збережіть потрібний об'єкт до конфігураційного файлу.

Результат виконання команди openscada_AGLKS --help ...

***************************************************************************
********** OpenSCADA v0.9+r2535 (Linux-4.9.0-0.bpo.5-amd64). *********
***************************************************************************

===========================================================================
======================== Основні опції ====================================
===========================================================================
-h, --help              Цей текст допомоги за опціями командного рядку та параметрами конфігураційного файлу програми.
    --projName=<ім'я>   Ім'я проєкту OpenSCADA для перемикання.
                        Для такої операції також використовується змінна оточення "OSCADA_ProjName" та ім'я бінарної програми "openscada_{ProjName}".
    --projUserDir={тека} Тека користувацьких проєктів OpenSCADA (доступна для запису), по замовченню "~/.openscada".
    --projLock={per}    Використовувати блокування проєктів створенням файлу "lock" у теці проєкту та його оновлення з періодом <per>,
                        по замовченню включено та період оновлення <per> складає 60 секунд. Для вимкнення встановити період оновлення <per> у нуль.
    --lang=<LANG>       Мова станції, у вигляді "uk_UA.UTF-8".
    --config=<файл>     Конфігураційний файл станції.
    --station=<ід>      Ідентифікатор станції.
    --statName=<ім'я>   Ім'я станції.
    --modDir=<path>     Теки модулів, поділені ';', та можуть містити у кінці шаблон файлів.
    --messLev=<рівень>  Рівень оброблюваних повідомлень (0-7).
    --log=<напрямок>    Спрямування повідомлень до, за бітовим полем:
                          0x1 - системний логер (syslogd);
                          0x2 - стандартний вихід (stdout);
                          0x4 - стандартний вихід помилок (stderr);
                          0x8 - архів повідомлень.
    --consoleCharSet={CharSet} Примусово встановити кодовий набір символів консолі у <CharSet>, по замовченню він системний.
    --demon, --daemon   Запуск у режимі демона.
    --pidFile=<file>    файл для розташування ID процесу програми тут.
    --noCoreDump        Запобігати створенню передсмертних дампів - не знімати це обмеження.
    --permCrtFiles={права} Права створюваних OpenSCADA файлів, по замовченню це 0755 (RWXRW_RW_).
------ Параметри станції 'AGLKS(SimulatorStation)' у конфігураційному файлі --------
StName     <ім'я>       Ім'я станції.
WorkDB     <Тип.Ім'я>   Робоча БД (ім'я та тип).
WorkDir    <шлях>       Робоча тека.
ModDir     <path>       Теки модулів, поділені ';', та можуть містити у кінці шаблон файлів.
IcoDir     <path>       Тека іконок.
DocDir     <path>       Тека документів.
MessLev    <рівень>     Рівень оброблюваних повідомлень (0-7).
SelDebCats <перелік>    Перелік категорій налагодження, поділено ';'.
LogTarget  <напрямок>   Спрямування повідомлень до, за бітовим полем:
                          0x1 - системний логер (syslogd);
                          0x2 - стандартний вихід (stdout);
                          0x4 - стандартний вихід помилок (stderr);
                          0x8 - архів повідомлень.
Lang       <мова>       Мова-локаль станції, у вигляді "uk_UA.UTF-8".
LangBase   <мова>       Базова мова та перелік всіх локалей (на кшталт "uk_UA.UTF-8") проєкту (опціонально) поділених ';', для багатомовного режиму.
Lang2CodeBase <мова>    Базова мова для перекладу текстових змінних, два символи.
MainCPUs   <перелік>    Основний перелік використаних процесорів, поділено ':'.
TaskInvPhs <n>          Кількість фаз виклику задач, 1 для вимкнення фазування.
ClockRT    <0|1>        Встановити використання джерела годиннику у REALTIME (інакше MONOTONIC), дещо проблематичне при модифікації системного годинника.
SaveAtExit <0|1>        Зберігати програму при виході.
SavePeriod <секунд>     Період збереження програми, 0 для вимкнення.
ModifCalc  <0|1>        Встановлювати модифікацію для обчислювальних об'єктів.
RdStLevel  <рів>        Рівень резервування поточної станції.
RdTaskPer  <секунд>     Період виклику задачі обслуговування резервування.
RdRestConnTm <секунд>   Час відновлення з'єднання з "мертвою" резервною станцією.
RdStList   <перелік>    Перелік резервних станції, поділено символом ';' (st1;st2).
RdPrimCmdTr <0|1>       Включення трансляції первинних команд до резервних станцій.
    Глобальні конфігуровані ліміти:
limObjID_SZ     [*20..50] Розмір ІД об'єктів OpenSCADA.
                УВАГА! Великий розмір може викликати помилку розміру ключа на БД схожих на MySQL!
                        Змініть це лише одноразово перед використанням на БД із фіксованим типом "char({N})"!
limObjNm_SZ     [*100...200] Розмір НАЗВИ об'єктів OpenSCADA.
                УВАГА! Змініть це лише одноразово перед використанням на БД із фіксованим типом "char({N})"!
limArchID_SZ    [*50...90] Розмір ІД об'єктів архіву значень.
                УВАГА! Лише збільшуйте його, інакше можете отримати проблеми у Archive.FSArch!
                        Змініть це лише одноразово перед використанням на БД із фіксованим типом "char({N})"!
limUserFile_SZ  [1MB...*10MB...1000MB] Обмеження розміру файлів на завантаження та опрацювання у просторі користувача
                та розміру частин передачі великих файлів.
limUserIts_N    [1000...*1000000...1000000000] Обмеження на кількість створюваних користувацьких елементів, на кшталт елементів масивів.
limCacheIts_N   [*100...100000] Обмеження на кількість елементів у кешу.
limCacheIts_TM  [10...*60...1000] Обмеження на час елементів у кешу, секунд.
    Глобальні конфігуровані параметри:
prmStrBuf_SZ    [1000...*10000...1000000] Довжина строкових буферів, не строковий клас.
prmWait_DL      [0.001...*0.1...1] Час кванту циклів очікування, секунд.
prmWait_TM      [*5...10] Розмір стандартного таймаута очікування, секунд.
prmInterf_TM    [*7...15] Час очікування реакції інтерфейсу, секунд.
prmServTask_PER [1...*10...120] Період сервісного завдання, секунд.

========================= Опції підсистеми "БД" =========================
---------- Параметри секції '/sub_BD/' конфігураційного файлу ----------
TblLifeTime  <секунд>   Час життя відкритих таблиць (по замовченню 600 секунд).

======================== Опції підсистеми "Безпеки" =====================

======================= Опції підсистеми "Транспорти" ===================

========================== Опції модуля <Transport:Sockets> ==========================
------ Параметри модульної секції '/sub_Transport/mod_Sockets/' конфігураційного файлу ------
OutLifeTime  <секунд>   Час життя вихідного транспорту (по замовченню 0 секунд), 0 - для вимкнення функції.

========================== Опції модуля <Transport:Serial> ==========================
------ Параметри модульної секції '/sub_Transport/mod_Serial/' конфігураційного файлу ------
OutLifeTime  <секунд>   Час життя вихідного транспорту (по замовченню 0 секунд), 0 - для вимкнення функції.

========================== Опції модуля <Transport:SSL> ==========================
------ Параметри модульної секції '/sub_Transport/mod_SSL/' конфігураційного файлу ------
OutLifeTime  <секунд>   Час життя вихідного транспорту (по замовченню 0 секунд), 0 - для вимкнення функції.

=============== Опції підсистеми "Транспортні Протоколи" ================

======================= Опції модуля <Protocol:HTTP> =============================
------ Параметри модульної секції '/sub_Protocol/mod_HTTP/' конфігураційного файлу ------
AuthTime   <хвил>       Час життя сеансу аутентифікації, хвилин (по замовченню 10).

==================== Опції підсистеми "Збір даних" ======================
---------- Параметри секції '/sub_DAQ/' конфігураційного файлу ----------
RdRestDtTm <год>        Глибина часу відновлення даних архіву з резервної станції, під час включення, у годинах.

====================== Опції підсистеми "Архіви-Історія" ========================
---------- Параметри секції '/sub_Archive/' конфігураційного файлу ----------
MessBufSize   <од.>     Розмір буферу повідомлень.
MessPeriod    <секунд>  Період архівування повідомлень.
ClrAlrmDays   <діб>     Діб автоматичного очищення порушень.
ValPeriod     <мсекунд> Період активного архівування значень.
ValPriority   <рівень>  Рівень пріоритету задачі активного архівування значень.
RdRestDtOverTm <днів>   Глибина примусового перевантаження історії резерву при запуску, у днях.

======================= Опції модуля <Archive:FSArch> =============================
    --noArchLimit       Вимкнути обмеження на кількість файлів.
                        Використовуйте для режиму перегляду архівів, не для роботи.

====================== Опції підсистеми "Спеціальні" ====================

========================== Опції модуля <Special:SystemTests> ==========================
------ Параметри модульної секції '/sub_Special/mod_SystemTests/' конфігураційного файлу ------
       *** Загальні опції всіх тестів ***
  id                    ідентифікатор тесту;
  on                    прапор ввімкнення тесту;
  per                   період повтору, секунд.
       *** Опції тестів ***
  1) Param      Тест DAQ параметрів. Вичитує атрибути та конфігураційні поля параметру.
    1:name      Адреса DAQ параметру
  2) XML        Тест розбору XML файлу. Розбирає та відображає структуру вказаного файлу.
    1:file      XML файл
  3) Mess       Тест архіву повідомлень. Періодично вичитує нові повідомлення з архіву, для вказаного архіватору.
    1:arhtor    Архіватор
    2:categ     Шаблон категорії повідомлення
    3:depth     Глибина повідомлень, секунд
  4) SOAttach   Тест підключення/виключення модулів.
    1:name      Шлях до модуля
    2:mode      Режим (1-підключити;-1-виключити;0-змінити)
    3:full      Повне підключення (на старті)
  5) Val        Тест значень атрибуту параметра.
Виконує періодичне опитування останнього значення вказаного атрибуту, а також опитування архіву на потрібну глибину.
    1:name      Шлях до атрибуту параметру
    2:arch_len  Глибина отримання архівних значень, секунд
    3:arch_per  Глибина отримання архівних значень, микросекунды
  6) DB Повний тест БД. Виконує:
  - створення/відкриття БД;
  - створення/відкриття таблиці;
  - створення множини записів (рядків) визначеною структурою;
  - модифікація множини записів;
  - отримання та перевірка значень множини записів;
  - модифікація структури запису та таблиці;
  - видалення записів;
  - закриття/видалення таблиці;
  - закриття/видалення БД.
    1:type      Тип БД
    2:addr      Адреса БД
    3:table     Таблиця БД
    4:size      Кількість записів
  7) TrOut      Тест вихідних та/або вхідних транспортів.
Виконує тестування вихідного транспорту шляхом надсилання запиту до вказаного вхідного транспорту.
    1:addr      Адреса
    2:type      Модуль транспорту
    3:req       Текст запиту
  8) SysContrLang       Тест мови контролю програми.
Виконує запит елементів мови за посередництвом повного шляху.
Повний шлях до елемента мови має вигляд </Archive/%2fbd%2fm_per>.
Повний шлях складається з двох вкладених шляхів.
Перший </Archive/> це шлях до вузла дерева контролю.
Другий </bd/m_per> це шлях до конкретного елемента вузла.
    1:path      Шлях до елементу мови
  9) ValBuf     Тести буферу значень.
Містить 13 тестів всіх аспектів буферу значень (підсистема "Архіви").
  10) Archive   Тест розташування у архіві значень. Містить 7(8) тестів архіватора значень на перевірку коректності функціонування послідовного механізму упакування.
    1:arch      Архів значень
    2:period    Період значень, микросекунды
    3:archtor   Архіватор
  11) Base64Code        Тести кодування алгоритмом Mime Base64.

================= Опції підсистеми "Інтерфейси користувачів" ============
---------- Параметри секції '/sub_UI/' конфігураційного файлу ----------
FontSnthHglCode <шрифт>  Шрифт використаний у підсвітлені синтаксису коду, по замовченню "monospace".

======================== Опції модуля <UI:Vision> ============================
------ Параметри модульної секції '/sub_UI/mod_Vision/' конфігураційного файлу ------
StartUser  <корист>     Стартовий, безпарольний, користувач.
UserPass   <пароль>     Пароль користувача для нелокального запуску.
RunPrjs    <перелік>    Перелік проєктів які мають запускатися при старті модуля.
ExitLstRunPrjCls <0|1>  Вихід при закритті останнього проєкту що виконується (по замовченню = 1).
CachePgLife <години>    Час життя сторінок у кешу (по замовченню 1).
CachePgSz  <кільк.>     Максимальна кількість сторінок у кешу (по замовченю 10).
VCAstation <id>         Станція з рушієм СВК ('.' - локальна).
RestoreTime <секунди>   Час відновлення підключення.

========================= Опції модуля <UI:QTStarter> ===========================
    --QtInNotMainThread Запускати Qt у окремому потоці від основного.
    --showWin=<0,1,2>   Режим відображення вікон, початковий та від якого дозволений до зміни: 0-типове вікно, 1-максимізоване вікно, 2-повний екран.
    --simulRightMKeyTm=<tm> Час, у секундах, симуляції правої клавіші миші та контекстного меню через утримання лівої клавіші протягом цього часу - більше за нуль.
------ Налагоджувані параметри Qt, командного рядка --
    --noX11             Запобігати запуску Qt, переважно для чистої консолі.
    --sync              Переключення у синхронний режим X11 для налагодження.
    --widgetcount       Друк налагоджувальних повідомлень при виході, у кількості
                        віджетів залишених невидаленими та максимальну їх кількість.
------ Параметри Qt, командного рядку -------------
    --qws               Робити цю програму сервером із Qt для вбудованого Linux.
    --style=<ім'я>      Встановити GUI стиль у ім'я (windows, platinum, plastique, ...).
    --stylesheet=<шлях> Встановити таблицю стилів із файлу за шляхом.
    --session=<ім'я>    Відновити із попереднього сеансу з вказаним ім'ям.
    --reverse           Встановити напрямок розташування у Qt::RightToLeft.
    --graphicssystem=<ім'я> Встановити механізм рендерінгу для екранних віджетів та QPixmaps (raster, opengl).
    --display=<ім'я>    Встановити X екран (типово у $DISPLAY).
    --geometry=<геом>   Встановити клієнтську геометрію першого відображуваного вікна.
------ Параметри модульної секції '/sub_UI/mod_QTStarter/' конфігураційного файлу ------
StartMod   <модулі>     Перелік модулів що запускаються, розділених ';'.
CloseToTray <0|1>       Закривати всі вікна або запускати без Qt модулів до системного лотку.
SessCntr   [0...*3]     Контроль-перезапуск сеансів: 0-якщо виконується, 1-завжди, 2-негайно, 3-ніколи.
Style      <ім'я>       GUI стиль Qt.
Font       <шрифт>      Загальний шрифт Qt.
Palette    <кольори>    Двадцять кольорів палітри поділених символом ',' у трьох рядках для активної, вимкненої та неактивної груп.
StyleSheets <CSS>       Правила таблиці каскадних стилів (CSS).

======================= Опції модуля <UI:QTCfg> =============================
------ Параметри модульної секції '/sub_UI/mod_QTCfg/' конфігураційного файлу ------
StartPath  <шлях>       Шлях первинної сторінки конфігуратору.
StartUser  <корист>     Стартовий користувач, без паролю.

======================== Опції модуля <UI:WebVision> ============================
------ Параметри модульної секції '/sub_UI/mod_WebVision/' конфігураційного файлу ------
SessTimeLife <хвил>     Час життя сеансів у хвилинах (по замовченню 10).
SessLimit    <кільк.>   Максимальна кількість сеансів (по замовченю 5).
CachePgLife  <години>   Час життя сторінок у кешу (по замовченю 1).
CachePgSz    <кільк.>   Максимальна кількість сторінок у кешу (по замовченю 10).
PNGCompLev   <рів.>     Рівень стиснення [-1..9] створюваних PNG-файлів.
ImgResize    <0|1>      Зміна розміру растрових зображень на боці серверу.

================ Опції підсистеми "Планувальник модулів" ==================
    --modPath=<шлях>    Теки модулів, поділені ';', та можуть містити у кінці шаблон файлів.
---------- Параметри секції '/sub_ModSched/' конфігураційного файлу ----------
ModPath    <шлях>       Теки модулів, поділені ';', та можуть містити у кінці шаблон файлів.
                        Це синонім параметру рівня станції "ModDir".
ModAllow   <перелік>    Перелік поділюваних бібліотек дозволених для автоматичного завантаження, підключення та виконання (bd_DBF.so;daq_JavaLikeCalc.so).
                        Використовувати значення '*' для дозволу всіх модулів.
ModDeny    <перелік>    Перелік поділюваних бібліотек заборонених для автоматичного завантаження, підключення та виконання (bd_DBF.so;daq_JavaLikeCalc.so).
ChkPer     <секунд>     Період пошуку нових поділюваних бібліотек(модулів), 0 - для вимкнення.

5 Запуск та виконання

OpenSCADA від початку є програмою яка може бути запущена з консолі або терміналі, набравши openscada. У такий спосіб програма запуститься з повідомленнями її дій у цю консоль та блокуванням консолі на очікуванні дій користувача, що є типовим режимом запуску у консолі-терміналі та може використовуватися для оперативного налагодження і контролю результату дій і помилок. Окрім типового режиму передбачено також ще три режими, які визначаються передачею параметрів до команди запуску:

  1. Режим отримання допомоги за параметрами командного рядку — openscada --help.
  2. Режим демону — openscada --demon, фонового або сервісного виконання. Передбачає від'єднання від консолі запуску та фонове виконання, тобто візуально програма наче одразу завершується, консоль звільняється та блокуються всі модулі локального графічного інтерфейсу на кшталт Qt. Використовується для запуску та виконання програми у режимі обслуговування сервісів на кшталт: серверу SCADA, середовища виконання ПЛК, серверу візуалізації, серверу WEB-інтерфейсів. Зазвичай ця команда поміщається до файлів опису-формування сервісу операційної системи та декілька готових наразі постачаються разом з OpenSCADA.
  3. Режим налагодження сервісу-демону — openscada --noX11, по суті є звичайним режимом з повідомленнями про дії у консолі, але із запобіганням запуску модулів локального графічного інтерфейсу, що неможливо у чистій консолі та недоступним X-сервером.

OpenSCADA є модульною та має модулі локальних графічних інтерфейсів, а відтак може запускатися у графічному інтерфейсі, що відбувається одночасно при типовому запуску з консолі та за наявності доступного X-серверу. Для запуску виключно у та з графічного інтерфейсу команда типового запуску може та використовується: у конфігурації іконок-ярликів, запуску програм (також автоматичного) з оточення графічного середовища — робочого столу (DE). Сам модуль запуску локального графічного оточення може передбачати декілька режимів про що можна дізнатися з документації на цей модуль, яким наразі є UI.QTStarter та який передбачає режими:

Рис.5a. Діалогове вікно пускачу модуля QTStarter.
Рис.5b. Проєкт "АГЛКС", запущений або згорнутий до системного лотка.
Рис.5c. Діалогове вікно пускачу модуля QTStarter у режимі ініціюючого запуску — обрання проєкту.

Простий запуск є малокорисним, незручним та передбачає використання і роботу лише з однією конфігурацією, це — конфігураційний файл {sysconfdir}/oscada.xml, як первинне сховище конфігурації. Для надання можливості вибору конфігурації при запуску програми передбачено параметр командного рядка --config та зміна робочої теки програми перед запуском або параметром "WorkDir" цього конфігураційного файлу, що може бути використано та виключно використовувалося OpenSCADA до версії 0.9 через створення окремого сценарію командного рядку (Shell) для окремої конфігурації. У версії OpenSCADA 0.9 додано поняття "Проєкту OpenSCADA", яке спочатку реалізовувалося окремим сценарієм командного рядку openscada_start, а потім було інтегровано до ядра OpenSCADA та модуля запуску локального графічного інтерфейсу.

5.1 Проєкти OpenSCADA

У OpenSCADA 0.9 було визначено, впроваджено та остаточно сформовано сутність проєкту OpenSCADA, як окреме місце (тека) з конфігурацією та всіма даними окремого проєкту-рішення SCADA-системи — об'єкт технологічного процесу, ПЛК, сервер візуалізації, сервер Web та інше.

Дані окремого проєкту-теки зазвичай передбачають:

Назва теки проєкту дорівнює назві проєкту та розташовується у робочій теці OpenSCADA. Робоча тека OpenSCADA поділяється на системну ("{datadir}/openscada", де "datadir" зазвичай — "/usr/share"), яка звичайному-непривілейованому користувачеві доступна лише для читання, та користувацька ("{HOME}/.openscada"), яка, за потреби, створюється у домашній теці користувача. До системної робочої теки зазвичай поміщаються попередньо-встановлені проєкти та бібліотеки OpenSCADA, які встановлюються відповідними пакетами дистрибутиву Linux. Відтак, для забезпечення повноцінної роботи, проєкти та бібліотеки з системної робочої теки копіюються до користувацької, що менеджер проєктів здійснює автоматично.

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

1. Визначення конфігураційного файлу, теки з даними та ім'я за вказаною назвою проєкту, де назву проєкту можна вказати:
  • параметром командного рядку "--ProjName={Ім'яПроєкту}";
  • змінною оточення "OSCADA_ProjName={Ім'яПроєкту}";
  • ім'ям символьного посилання openscada_{Ім'яПроєкту} на openscada_start.
2. Запуск OpenSCADA через виклик первинного бінарного файлу openscada та з параметрами командного рядка визначеного проєкту.
3. Перевірку коректності завершення програми та генерацію звіту про некоректне завершення у випадку наявності файлу передсмертного дампу пам'яті у теці проєкту та налагоджувача "gdb".
4. Перевірку та запобігання багаторазовому запуску одного й того-ж проєкту, що є небезпечним для даних, архівів та загальної стабільності роботи програми.
5. Формування діалогів обрання та створення нового проєкту, якщо не вказано потрібного для запуску, у одній з програм діалогового типу: dialog, kdialog, zenity або Xdialog.
6. Cтворення нових проєктів за шаблоном конфігурації робочої станції, що передбачає:
  • створення теки проєкту;
  • копіювання шаблону конфігураційного файлу "oscada_start.xml" у "oscada.xml" теки проєкту;
  • створення посилання на локальну копію теки бібліотек (яка, за потреби, копіюється із зони "Тільки для читання");
  • створення тек архівів на файлову систему "ARCHIVES/MESS" для повідомлень та "ARCHIVES/VAL" для значень;
  • створення на робочій стільниці файлу запуску проєкту OpenSCADA з графічного середовища (іконки-ярлику), шляхом створення файлу "openscada_{НазваПроєкту}.desktop" за шаблоном файлу "openscada.desktop".

З метою уніфікації та розширення функціональності, та за досвідом експлуатації openscada_start, сутність проєкту пізніше було інтегровано до ядра OpenSCADA і модуля запуску локального графічного інтерфейсу UI.QTStarter. Відтак, ядро OpenSCADA, а саме первинний бінарний файл openscada, передбачає визначення конфігураційного файлу, теки з даними та ім'я за вказаною назвою проєкту і перемикання на цю конфігурацію згідно до пунктів 1, 2 та 4 вище-перелічених функцій менеджеру проєкту. Формування елементів інтерфейсу для обрання та створення нових проєктів, пункт 5, здійснює модуль запуску локального графічного інтерфейсу UI.QTStarter (Рис.5a,5c). Пункти 3 та 6 винесено у окремий сценарії командного рядку openscada-proj через специфічність цих операцій до програмної платформи, а відтак і необхідність у простій адаптації до цієї специфіки.

Відтак, наразі OpenSCADA можна запустити як у режимі демону-сервісу, так і графічного інтерфейсу просто вказавши ім'я чинного проєкту чотирма способами:

  1. параметром командного рядку — openscada --projName={Ім'яПроєкту};
  2. змінною оточення — OSCADA_ProjName={Ім'яПроєкту} openscada;
  3. ім'ям символьного посилання — openscada_{Ім'яПроєкту} на openscada.
  4. вибором наявного проєкту з переліку локального графічного інтерфейсу UI.QTStarter, який надається за простим викликом первинного бінарного файлу openscada — ініціюючий режим (Рис.5c), та якщо не вказано графічних модулів Qt автоматичного запуску — режим виконання проєкту OpenSCADA (Рис.5a).

Створити новий проєкт можна з локального графічного інтерфейсу UI.QTStarter (Рис.5c) та через сценарій командного рядку менеджеру проєктів openscada-proj, який власне і викликається з локального графічного інтерфейсу.

Результат виконання команди openscada-proj --help ...

Projects management script of OpenSCADA mostly designed to call from OpenSCADA but also can be used independently.
The script is mostly software platform specific and relates now for Linux.
openscada-proj list
openscada-proj proc|create|remove|update {ProjName}
 Commands:
  list   - allowed projects list;
  proc   - proceed for copy RO projects to WR, create desktop links, process core dumps;
  create - create new projects or copy RO projects to WR, create desktop links;
  remove - remove project;
  update - update from 0.8.0 LTS;
 Arguments:
  ProjName - project name;
 Environment variables:
  dPrj     - directory of projects OpenSCADA, can be RO;
  dPrjUser - directory of projects OpenSCADA of the user, WR;
  dSysCfg  - directory of system configuration;
  dData    - directory of system data;

openscada-proj backup|backupRestore {ProjName} [{BackupName}]
openscada-proj backupList {ProjName}
 Commands:
  backup - backup the selected project <ProjName> to the name <BackupName>, or to the current date at missing;
  backupRestore - restore the selected project <ProjName> from the pointed backup name <BackupName>, or from the last one at missing;
  backupList    - list the project <ProjName> backups.
 Arguments:
  ProjName   - project name;
  BackupName - the backup archive name.
 Environment variables:
  OSCD_TAR_ComprPrg - TAR compression program, by default gzip;
  OSCD_TAR_Args     - TAR extra arguments, by default \"--exclude=lock --exclude=ARCHIVES\";
  OSCD_BackLim      - Backups limit, by default 10.

Загалом сценарій командного рядку менеджеру проєктів openscada-proj передбачає функції та команди довкола проєктів:

Додатково сценарій командного рядку містить команди менеджеру резервного копіювання проєктів:

Резервне копіювання загалом здійснюється у робочій теці OpenSCADA поряд із теками самих проєктів, для яких створюються файли запакованих тек із назвою {ProjName}_{BackupName}.backup, наприклад — "Boiler_2020-06-24_20.09.backup". По замовченню теки проєктів стискаються програмою "gzip", яку можна змінити встановленням змінної оточення "OSCD_TAR_ComprPrg". Обмеження на резервні файли встановлено у 10 та ви можете його змінити змінною оточення "OSCD_BackLim". Також ви можете додати специфічних аргументів до архіватору TAR змінною оточення "OSCD_TAR_Args", яка по замовченню встановлена у "--exclude=lock --exclude=ARCHIVES" задля виключення файлу "lock" та теки "ARCHIVES" із резервного копіювання. Резервування можна здійснювати із зовні, наприклад, за встановленим розкладом із CRON, окрім того, що здійснювати це вручну із графічного інтерфейсу менеджеру проєктів (Рис.5a).

5.2 Виконання готового проєкту OpenSCADA у просторі сервісу-фоні

Організація проєкту OpenSCADA у окремій теці робить простим запуск готових проєктів у просторі сервісу — виконання у фоні, а також подальше оновлення та супровід цього проєкту без прямого віддаленого контролю. Фактично, ви можете розробляти проєкт локально, тримаючи його теку у користувацькій робочій теці (типово "{HOME}/.openscada"), а для запуску у просторі сервісу лише копіювати або пакувати, передавати на віддалений робочий пристрій та розпаковувати у системну робочу теку (типово "/usr/share/openscada").

Сервісне-фонове виконання програм в Linux обслуговується відповідним чином сформованим сценарієм-скриптом, який розташовується в теці "/etc/ini.d" та має бути окремим на кожен проєкт OpenSCADA що запускається у сервісному просторі. Для спрощення та виключення необхідності займатися створенням власних сценаріїв OpenSCADA надає відповідні для стандартних випадків-профілів та які зазвичай постачаються пакетами openscada-server і openscada-plc (openscada-lts-server і openscada-lts-plc для LTS).

Відтак, для запуску у просторі сервісу скажімо бібліотечного проєкту "АГЛКС" ми:

# Підключитися від суперкористувача
su -
# ... для живого диску та деяких інших оточень Linux
sudo bash
# Зупинити виконання попередньої конфігурації серверу та видалити його теку
service openscada-server stop; rm -R /usr/share/openscada/server
# ... для LTS
service openscada-lts-server stop; rm -R /usr/share/openscada/server
# Скопіювати проєкт "АГЛКС" із домашньої теки користувача "{HOME}" з перейменуванням у "server"
cp -R {HOME}/.openscada/AGLKS /usr/share/openscada/server 
# Запустити сервер вже з проєктом "АГЛКС"
service openscada-server start
# ... для LTS
service openscada-lts-server start

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

Відмінність виконання проєкту у середовищі сервісу-фону від користувацького середовища робочої стільниці власне одна, звісно крім відсутності локального графічного інтерфейсу, це — відсутність у фоні визначення локалі, тобто мова інтерфейсу там буде Англійська. Та що можна просто виправити зміною або доданням конфігураційного параметру <prm id="Lang">uk_UA.UTF-8</prm> до секції-тегу "station" файлу oscada.xml фонового проєкту.


6 Посилання

Documents/Program_manual/uk - GFDLMay 2024OpenSCADA 0.9.7