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

---

• Автор: Роман Савоченко
• Початково створено: у старій Wiki

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• бази даних;
• комунікаційні інтерфейси, транспорти;
• протоколи комунікаційних інтерфейсів;
• джерела даних та збір даних;
• архіви-історія (повідомлень та значень);
• інтерфейси користувача (GUI, TUI, WebGUI, speach, signal ...);
• додаткові модулі, спеціальні.

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

1.2 Підсистеми

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

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

• Безпека.
• Диспетчер модулів.
• Бази даних (модульна).
• Транспорти (модульна).
• Транспортні протоколи (модульна).
• Збір даних (модульна).
• Архіви-Історія (модульна).
• Інтерфейси користувача (модульна).
• Спеціальні (модульна).

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

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

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

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

• Обчислювач на мові подібній до Java;
• Логічний рівень;
• Блоковий обчислювач;
• Шлюз джерел даних;
• Збір даних ОС;
• ModBus;
• DCON клієнт;
• Клієнт OPC-UA;
• Збір даних Siemens;
• MMS(IEC-9506);
• SNMP клієнт;
• Обладнання ICP DAS;
• Diamond плати збору даних.

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

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

Окремі типи джерел даних самі можуть продукувати дані як повністю їх генеруючи, так і обробляючи фізичні дані та навіть повністю реалізуючи отримання цих даних у оточені 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. Сім основних рівнів мають назви, та відповідності чому бажано дотримуватися:

• 0 — Налагодження;
• 1[X] — Інформація;
• 2[X] — Зауваження;
• 3[X] — Попередження;
• 4[X] — Помилка;
• 5[X] — Критично;
• 6[X] — Тривога;
• 7[X] — Аварія.

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

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

• Системні, генеруються об'єктами-вузлами OpenSCADA:

КАТЕГОРІЯ: визначає типовий шлях до вузлу повідомлення, наприклад — "/sub_DAQ/mod_LogicLev/cntr_gen/", де:

• "/*/*" — типовий шаблон-ознака системного повідомлення на основі символу-роздільнику елементів шляху, який може бути безпосередньо використано у фільтрі категорії для визначення суто архіву системних повідомлень.

ТЕКСТ: містить шлях назв вузла повідомлення та саме повідомлення у форматі "{NodeNmPath}: {message}", наприклад — "AGLKS > Збір Даних > LogicLev > gen: Запуск контролера.".

• Шлюзовані, повідомлення, що було отримано з ієрархічно нижчої станції OpenSCADA (як то ПЛК) або передане вищою станцією:

КАТЕГОРІЯ: у початок категорії отриманого повідомлення додається ідентифікатор об'єкту контролеру модуля DAQ.DAQGate, що здійснив отримання, наприклад — "loop:alModBus:testTCP" або "TopStat(DAQCntr):alModBus:testTCP", де:

• "loop:*" — типовий шаблон-ознака віддаленого нижчого повідомлення на основі ідентифікатору об'єкту контролеру модуля DAQ.DAQGate, який може бути безпосередньо використано у фільтрі категорії для визначення суто архіву віддалених повідомлень цього джерела;
• "TopStat(DAQCntr):*" — типовий шаблон-ознака віддаленого вищого повідомлення на основі назви проекту (або ідентифікатору) TopStat та ідентифікатору об'єкту контролеру DAQCntr модуля DAQ.DAQGate, який може бути безпосередньо використано у фільтрі категорії для визначення суто архіву віддалених повідомлень цього джерела.

• Уніфіковані структури із джерелом даних у категорії, генеруються джерелом даних або його процедурами за допомогою функції messSet() API OpenSCADA та користувацького API:

КАТЕГОРІЯ: визначає ID-адресу джерела порушення у форматі "{ID}{ModId}:{CntrId}[.{PrmId}][:{SpecPrms}]", де:

• ID — двосимвольний ідентифікатор структури;
• ModId — ідентифікатор модуля;
• CntrId — ідентифікатор об'єкту контролера;
• PrmId — ідентифікатор параметру;
• SpecPrms — специфічні параметри структури ID.

• Порушення, генеруються джерелом даних або його процедурами за допомогою функції alarmSet() API OpenSCADA та користувацького API:

КАТЕГОРІЯ: визначає 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 — нове значення або дія.

• Значення у повідомлені — виміряні значення, які введено вручну, що первинно запроваджено у кадрі документу "Річний звіт місячних значень (docRepYear)":

КАТЕГОРІЯ: визначає 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. Під неструктурованими даними вважається потік символів певної довжини. Модульним об'єктом, що міститься у підсистемі "Транспорти", виступає тип транспорту, який і визначає механізм передачі неструктурованих даних. Наприклад, це можуть бути та є:

• сокети (TCP/UDP/UNIX);
• послідовні інтерфейси;
• шифровані канали.

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

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

• власний протокол OpenSCADA;
• ModBus;
• OPC-UA;
• DCON;
• протокол передачі гіпертексту (HTTP);
• користувацькі протоколи, що реалізуються у самій OpenSCADA на логічному рівні, та який, із розвитком внутрішньої мови, став пріоритетним.

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

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

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

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

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

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

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

• Середовище візуалізації: Рушій Середовища Візуалізації, візуалізатори Qt та Web;
• Конфігуратори: Qt та Web;
• Сигналізатори.

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

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

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

• зберігання облікових записів користувачів та груп користувачів;
• аутентифікація користувачів;
• перевірка прав доступу користувача до того або іншого ресурсу.

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

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

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

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

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

• тести OpenSCADA та її модулів;
• бібліотеки функцій користувацького програмування: функції системного API, математичні функції.

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

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

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

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

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

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

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

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

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

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

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

• отримання та/або формування даних;
• обробка даних;
• обслуговування запитів на доступ до даних;
• обслуговування запитів на модифікацію даних.

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

• архівування або ведення історії даних SCADA-систем;
• обслуговування запитів на доступ до архівних даних або історії;
• імпорт/експорт архівів-історії.

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

• архівування або ведення історії повідомлень SCADA-систем;
• обслуговування запитів на доступ до архівних повідомлень або історії;
• імпорт/експорт архівів-історії.

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

• надання користувацького інтерфейсу для контролю за станом технологічного процесу;
• надання можливості формування керуючих дій;
• надання можливості вивчення та аналізу історії технологічного процесу;
• надання інструментарію для формування звітної документації.

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 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). Стійкість досягається шляхом розподілу функцій за:

• серверами опитування;
• центральним сервером архівування та обслуговування клієнтських запитів;
• клієнтами: АРМи та WEB-клієнти.

Рис. 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 надає три модулі конфігурації на різній основі візуалізації. Відзначимо їх та їх можливості конфігурації:

• Модуль конфігурації на основі бібліотеки графічного інтерфейсу Qt — UI.QTCfg. Надає розвинутий інтерфейс конфігурації, що дозволяє керувати як локальними, так і віддаленими станціями у локальній та глобальній мережах, включаючи безпечне з'єднання.
• Модуль конфігурації на основі динамічних WEB-технологій (DHTML) — UI.WebCfgD. Надає розвинутий інтерфейс конфігурації, що дозволяє керувати як локальними станціями серверу, так і віддаленими станціями у локальній та глобальній мережах, включаючи роботу по безпечному з'єднанню. Клієнтське підключення здійснюється за посередництвом звичайного Web-браузеру.
• Модуль конфігурації на основі статичних WEB-технологій (XHTML) — UI.WebCfg. Надає достатній інтерфейс конфігурації, який дозволяє керувати локальними станціями серверу за посередництвом звичайного Web-браузеру.

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

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

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

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

• Конфігураційний Файл (<cfg>);
• {Модуль БД}.{Назва БД} — База Даних;
• Загальний Сховок (<gen>) — Загальний Сховок (комбіноване), яке складається із Конфігураційного Файлу та робочої Бази Даних, вказаної у конфігураційному полі Робоча БД; де Конфігураційний Файл первинний для вже наявних там даних, тобто їх зміни, але все нове створюється у Базі Даних.

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

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

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

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

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

• Вкладка "Станція" містить основні інформаційні та конфігураційні поля програми, рисунок 4a. Перелічимо поля що надаються та прокоментуємо їх:
  • Станція — містить інформацію про ідентифікатор станції та вказує на локалізоване ім'я станції. Ідентифікатор вказується параметром командного рядку "--station"; при завантажені шукається відповідний до ідентифікатору станції розділ у конфігураційному файлі та використовується перший доступний, якщо не виявляється. Назва вказується параметром командного рядку "--statName".
  • Конфігураційний файл — містить інформацію про конфігураційний файл, що використовується програмою. Встановлюється параметром командного рядку "--config" або проєктом.
  • Робоча тека — містить інформацію про робочу теку станції. Використовується у відносній адресації об'єктів на файловій системі, наприклад — файлів БД. Переважно встановлюється менеджером проєктів при старті або безпосередньо у конфігурації запуску програми.
  • Тека модулів — містить інформацію про теки модулів OpenSCADA, поділені символом ';' та які можуть включати шаблони файлів у кінці (/my/modules/path/lib*.so). Якщо значення цього поля некоректне то при запуску програма завершиться з повідомленням у консолі про некоректність конфігурації.
  • Тека іконок — містить інформацію про теки іконок програми, поділені символом ';'. Якщо у дереві навігації конфігуратору відсутні іконки то значення цього поля некоректне.
  • Тека документів — містить інформацію про теки документів програми, поділені символом ';'. Якщо ви не можете викликати локальну документацію то значення цього поля встановлено некоректно або не встановлено документації.
  • Робоча БД — вказує на робочу Базу Даних, а саме на частину Бази Даних комбінованого сховища (Загальний Сховок), що використовується для зберігання основних даних програми; яким може бути і Конфігураційний Файл (<cfg>) також для повного виключення Бази Даних зі зберігання даних.
  • Зберігати програму при виході, за періодом — вказує на необхідність збереження змінених даних при завершені роботи програми та вказує на періодичність у секундах з якою зберігати змінені дані програми.
  • Встановлювати модифікацію для обчислювальних об'єктів — особливо корисне для робочих систем разом із попередніми конфігураційними властивостями для збереження контексту обчислення. Але незручне у режимі розробки, постійно нагадуючи про необхідність збереження.
  • Повідомлення — вказує рівень повідомлень починаючи з якого програма буде їх обробляти та спрямування повідомлень. Повідомлення нижче цього рівня будуть ігноруватися. Рівень "Налагодження (0)" має особливий сенс, а саме — при встановлені буде увімкнено генерацію налагоджувальних повідомлень різними частинами програми. Контролювати генерацію налагоджувальних повідомлень частинами програми можна у вкладці "Налагодження" (Рис.4d), яка з'явиться у цьому випадку. Спрямування вказують необхідність відправлення повідомлень до системного журналу, до стандартного виводу, помилок та до архіву:
    • системний журнал це механізм операційної системи для роботи з повідомленнями системи та ПЗ; при включенні цього параметру з'являється можливість керувати та контролювати повідомлення OpenSCADA механізмами ОС;
    • стандартний вивід та помилки спрямовує повідомлення до консолі відповідно до рівня; або до стандартного журналу для деяких специфічних вбудованих систем;
    • архів повідомлень OpenSCADA представлено буфером повідомлень; цей параметр зазвичай увімкнено та його вимкнення призводить до фактичного відключення архівування повідомлень на станції; збереження повідомлень буферу до сховища здійснюється відповідним архіватором повідомлень, про створення та конфігурацію якого можна детально ознайомитися у розділі конфігурації підсистеми "Архіви-Історія".
  • Оточення — секція інформації та конфігурації оточення:
    • Програма — містить інформацію про назву та версію програми. Зазвичай це OpenSCADA або назва заснованого на OpenSCADA рішення.
    • Система — містить інформацію про назву та версію Операційної Системи (OS), ядро ОС на якому виконується програма.
    • Системний час — містить інформацію про актуальний час системи із часовою зоною.
    • Системний годинник планування — містить інформацію про використаний годинник планування завдань та його роздільну здатність на даній операційній системі. Дозволяє зорієнтуватися з мінімальним інтервалом часу періодичних завдань, наприклад, для завдань збору даних.
    • Системний користувач — містить інформацію про користувача від ім'я якого виконується програма у ОС.
    • Мова — містить інформацію про кодування у якому зберігаються текстові повідомлення всередині програми та вказує на повну інформація щодо локалі із мовою, країною та кодуванням у вигляді "uk_UA.UTF-8". Зміна повної локалі допустима, однак переважно призводить до зміни мови повідомлень для інтерфейсу та динамічних повідомлень.
    • Ім'я хосту — містить інформацію про ім'я машини, на якій запущено станцію.
    • CPU — містить оперативну інформацію про центральний процесор та вказує на основний набір процесорів для використання завданнями OpenSCADA. Інформацію процесору представлено кількістю доступних процесорів/ядер та частотою, який виконує програму. Значення частоти перевіряється раз на 10 секунд (для X86) та дозволяє відстежувати її зміну механізмами управління живленням, наприклад. Основний набір процесорів у круглих дужках містить перелік процесорів, що використовуються на цей час.
    • Кількість фаз виклику задач — для встановлення фазування виклику задач у визначену кількість фаз, <= 0 для встановлення оптимально, 1 для вимкнення фазування задач.
• Вкладка "Підсистеми" містить перелік підсистем (Рис.4b) та дозволяє виконувати прямі переходи до них за допомогою контекстного меню.
• Вкладка "Резервування" (Рис.4с) містить конфігурацію резервування станції у складі налаштувань:
  • Статус — містить інформацію про роботу механізму резервування — поточний та максимальний час, витрачений на виконання циклу задачі обслуговування резерву.
  • Рівень станції — вказує на рівень даної станції у схемі резервування (0-255).
  • Період задачі резервування — вказує на періодичність виконання задачі резервування, у секундах (1-255).
  • Час відновлення підключення — вказує через який інтервал часу здійснювати спробу відновлення підключення зі втраченою резервною станцією, у секундах (0-255).
  • Передача локальних первинний команд — включає передачу локальних первинних команд резервним станціям для автоматичної синхронізації локальних змін.
  • Станції — містить таблицю з інформацією про резервні станції. Станції можна додавати та видаляти за посередництвом контекстного меню. Ідентифікатор доданих станцій треба обрати з переліку доступних системних станцій OpenSCADA. Наявність у таблиці хоча-б однієї станції включає резервування у цілому та відкриває доступ до сторінок конфігурації резервування на рівні підсистем, якщо підсистема підтримує резервування. Таблиця надає наступну інформацію про станції:
    • Ідентифікатор — ідентифікатор системної станції OpenSCADA, має бути змінений після додання шляхом обрання з переліку доступних;
    • Ім'я — ім'я системної станції OpenSCADA;
    • Живий — ознака наявності зв'язку з резервною станцією;
    • Рівень — рівень віддаленої станції у схемі резервування;
    • Лічильник — лічильник запитів до резервної станції або час очікування відновлення, у випадку відсутності зв'язку.
  • Перехід до конфігурації переліку віддалених станцій — команда для переходу на сторінку конфігурації віддалених OpenSCADA станцій у підсистемі "Транспорти".
• Вкладка "Переклади" містить елементи менеджеру централізованого перекладу текстових повідомлень станції (Рис.4f) та активується при включені багатомовного режиму встановленням базової мови текстових змінний:

Більше дізнатися про деталі та специфіку створення багатомовних проєктів ви можете у відповідному "Як Виконати".

• Статус — поточний статус перекладу повідомлень проєкту, де можливе:

• "ОДНОМОВНИЙ, лише використовувати вже багатомовні БД із їх модифікацією";
• "БАГАТОМОВНИЙ, створення або модифікація конфігураційних БД як багатомовні із вказаною базовою мовою '{мова}'";
• "БАГАТОМОВНИЙ-ДИНАМІЧНИЙ, та динамічний переклад".

• Базова мова - перелік локалей — вмикає підтримку багатомовності текстових змінних у конфігураційних БД через введення базової мови та переліку всіх локалей (на кшталт "uk_UA.UTF-8") проєкту (опціонально) поділених ';'. Далі, для текстових змінних на небазовій мові у таблицях БД будуть створюватися окремі стовпчики. Під текстовими змінними маються на увазі всі текстові поля конфігуратору, які може бути перекладено на іншу мову. Числа та інші службові символи до їх переліку не належать і не перекладаються. Повний перелік локалей не є обов'язковою частиною та переважно використовується у перетворені коду мови у повну локаль для системних функцій та у переліках обрання локалі.

Ви можете ввести тут іншу мову окрім Англійська(en), але майте на увазі, що всі стандартні бібліотеки OpenSCADA сформовано для базової мови Англійська(en), тож інша базова мова псуватиме ці БД при зміні!

• , динамічний переклад — запланований стан динамічного перекладу текстових повідомлень. Динамічний переклад текстових повідомлень викликає включення кешу перекладів текстових повідомлень та запити з БД перекладів частин OpenSCADA для робочих мов. Механізм переважно призначено для багатомовних динамічних користувацьких інтерфейсів, коли користувач програми має власну-переважну мову та користувачів у програми багато, як правило це кінцеві користувачі-оператори.
• Ввімкнення менеджера — включення загального керування перекладами, що призводить до повного перезавантаження для отримання вбудованих повідомлень, що однак не призводить до формування повного індексу повідомлень у зв'язку із забороною перевантаження низки об'єктів під час їх виконання. Для завантаження повного індексу повідомлень потрібно зберегти менеджер у ввімкненому режимі та повністю перезапустити OpenSCADA. У процесі наступного запуску сформується повний індекс повідомлень.
• Мови контролю — перелік оброблюваних мов, поділені символом ';'. Якщо для вказаної мови у джерелі присутні переклади то стовпчик мови буде їх містити, інакше буде порожнім.
• Фільтр джерел — фільтр джерел для обмеження роботи менеджеру деякими БД, джерело має просто містити такий підрядок.
• , перевірка/виправлення — увімкнути перевірку щодо однаковості перекладу базового повідомлення у різних джерелах та виправлення щодо: розповсюдження перекладу на порожні джерела, очищення дублювань базових повідомлень. Та окремий-другий прапорець щодо виправлення поєднанням базових повідомлень як переклади, оскільки ця операція може бути дещо помилковою у складних оточеннях.
• , пропуск — пропустити визначену кількість елементів таблиці від початку, корисно для дуже великих проєктів які обмежено у часі повного опрацювання таблиці.
• Повідомлення — безпосередньо таблиця повідомлень зі стовпчиками: базова мова, контрольовані мови перекладу, джерела повідомлення. Для модифікації доступні стовпчики мов, зміни яких будуть вноситися до джерел повідомлення.

• Вкладка "Задачі" містить таблицю з переліком задач, відкритих різними компонентами OpenSCADA (Рис.4d). З таблиці можна отримати різну інформацію по задачах, а також призначити використані задачами процесори, на багатопроцесорних системах, та встановити фазу виклику задачі.
• Вкладка "Налагодження" містить елементи контролю за налагодженням (Рис.4e) та активується при виборі рівня повідомлень "Налагодження (0)" або при використані лічильників об'єктів.

Для модифікації полів цієї сторінки можуть бути потрібні права привілейованого користувача. Отримати такі права можна, долучивши вашого користувача до групи суперкористувача "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):

• Модуль — ідентифікатор модуля.
• Ім'я — ім'я модуля.
• Тип — тип модуля, ідентифікатор підсистеми до якої модуль відноситься.
• Джерело — поділювана бібліотека або *bd_{ModId}, для вбудовування, що характеризує джерело цього модуля.
• Версія — версія модуля.
• Автор — автор модуля.
• Опис — короткий опис модуля.
• Ліцензія — ліцензійна угода розповсюдження модуля.

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

• LIST — перелік таблиць-контейнерів у БД-сховищі;
• GET, SEEK, SET, DEL — відповідні запити записів даних OpenSCADA;
• STRUCT — отримання структури полів БД у відображенні на типи даних OpenSCADA;
• PRELOAD — попереднє завантаження записів даних OpenSCADA за SEEK-запиту, груповим SQL SELECT запитом;
• SQL — SQL-запити;
• FIX — виправлення-зміна структури сховища відповідно до структури записів даних OpenSCADA;
• TR — опрацювання даних перекладу структури запису OpenSCADA;
• ERR — перевірена обробка та реєстрація помилок оточення на кшталт RO-режиму, підключення та подібне.

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

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

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

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

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

• Розділ "Стан" — містить властивості, що характеризують стан об'єкту БД:
  • Ввімкнено — стан "Ввімкнено", об'єкту БД. Для мережевих БД цей стан передбачає підключення до СУБД, відповідно й відображає факт наявності підключення та яке, за встановлення "Вмикати", періодично відновлюється.
  • Наявні таблиці — перелік таблиць, які містить БД. Контекстним меню цієї властивості надається можливість фізичного видалення таблиць з БД.
  • Завантажити програму з цієї БД — команда для виконання завантаження з даної БД. Може використовуватися при перенесенні даних у БД між станціями. Наприклад, можна зберегти ділянку однієї станції до експортної БД, фізично перенести БД на іншу станцію, підключити її у цій підсистемі та викликати дану команду.
• Розділ "Конфігурація" — безпосередньо містить поля конфігурації:
  • Ідентифікатор — містить інформацію про ідентифікатор об'єкту БД.
  • Ім'я — вказує ім'я об'єкту БД.
  • Опис — короткий опис та призначення об'єкту БД та самої БД у програмі.
  • Адреса — адреса БД у специфічному для типу БД (модуля) форматі. Опис формату запису адреси БД як правило доступний у підказці цього поля, що спливає.
  • Кодова сторінка — вказує на кодову сторінку, у якій зберігаються та надаються текстові значення БД. Значення кодової сторінки БД у зв'язці із внутрішнім кодуванням станції використовується для прозорого перекодування текстових повідомлень при обміні між станцією та БД.
  • Вмикати — вказує на стан "Ввімкнено", у який переводити БД при завантажені.
  • Пріоритет у переліку — пріоритет БД [0...99] у загальному переліку баз даних використовуваних у завантаженні, корисно для бібліотек розташованих у декількох базах даних для визначення пріоритетних — використовуваних.
  • Закриття транзакції: після відкриття, секунд — час закриття транзакції після її відкриття.
  • Закриття транзакції: після запиту, секунд — час закриття транзакції після останнього запиту. Якщо час менше за SERV_TASK_PER (10), тоді для опрацювання транзакцій БД буде відкрито незалежний потік-задачу з визначеним наступним параметром пріоритетом, інакше процес буде здійснюватися сервісною задачею.
  • Закриття транзакції: пріоритет окремої задачі — пріоритет незалежного потоку-задачі, відкритої за попереднього часу менше за SERV_TASK_PER (10).

Вкладка "Таблиці" (Рис.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). Вкладку призначено для налагодження зв'язку та протоколів обміну, та вона містить:

• Час — інформація про час, витрачений на запит та отримання відповіді.
• Режим — вказує режим даних, з переліку: "Бінарний", "Текст(LF)", "Текст(CR)", "Текст(CR/LF)"; у якому буде формуватися запит та надаватися відповідь. У бінарному режимі дані записуються парами чисел у шістнадцятковому численні, тобто байтами, поділеними пробілами.
• Очікувати таймаут — ознака очікування таймауту при отриманні відповіді. Багато систем при відповіді на різних протоколах (наприклад, HTTP) можуть надсилати дані відповіді декількома шматками. Без цієї ознаки буде отримано та відображено тільки перший шматок. При встановлені ознаки буде здійснено очікування всіх шматків відповіді, безпосередньо до відсутності даних протягом таймауту доочікування транспорту.
• Розмір вхідного буферу, байт — контролює розмір вхідного буфера або вимикає читання (0) взагалі — тільки запис.
• Надіслати — команда надсилання запиту.
• Запит — містить дані запиту у обраному режимі представлення.
• Відповідь — надає дані відповіді у обраному режимі представлення.

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

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

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

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

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

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

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

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

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

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

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

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

• Глибина відновлення даних при запуску — вказує на максимальну глибину архівних даних для відновлення з архіву віддаленої станції при запуску, у годинах (0-12).
• Контролери — містить таблицю з переліком об'єктів контролерів, доступних для резервування, та поточний їх стан:
  • Контролер — повний ідентифікатор об'єкту контролеру;
  • Ім'я — ім'я об'єкту контролера;
  • Запущено — ознака виконання об'єкту контролеру локальною станцією;
  • Резервування — режим резервування об'єкту контролера, може бути обрано з переліку:
    • "Виключено" — повністю незалежна робота об'єкту контролера.
    • "Асиметричне" — повне резервування з доступною конфігурацією об'єкта контролера віддаленої станції та без спроб її узагальнювати.
    • "Тільки порушення" — фактична робота без резервування, але з пригніченням порушень від резервного об'єкту контролера з метою виключення дублювальних повідомлень про порушення.
  • Уподобання виконання — конфігурація уподобання виконання на вказаній станції; зарезервовані значення вказують на:
    • <Високий рівень> — виконання на станції з найвищим рівнем.
    • <Низький рівень> — виконання на станції з найнижчим рівнем.
    • <Оптимально> — обрання для виконання найменш навантаженої станції — станції яка виконує найменшу кількість об'єктів контролерів.
  • Віддалений — ознака, що вказує на виконання об'єкта контролера віддаленою станцією та роботу локальної станції у режимі синхронізації даних з віддаленою.

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

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

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

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

• Розділ "Стан" — містить властивості, що характеризують стан бібліотеки:

• Доступний — стан бібліотеки "Доступний".
• Сховище — зберігання даних бібліотеки та її шаблонів, з відстеженням наявності даних у різних сховищах та наданням послідовного видалення дублікатів.

Об'єкт все ще підтримує визначення надлишкової адреси сховку із таблицею до того часу як ви перейменуєте її у стандартну форму "tmplib_{ObjID}".

• Дата модифікації — дата та час останньої модифікації об'єкту.

• Розділ "Конфігурація" — безпосередньо містить поля конфігурації:

• Ідентифікатор — інформація про ідентифікатор бібліотеки.
• Ім'я — вказує ім'я бібліотеки.
• Опис — короткий опис бібліотеки та її призначення.

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

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

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

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

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

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

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

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

• Ідентифікатор — ідентифікатор атрибуту.
• Ім'я — ім'я атрибуту.

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

• Тип — обрання типу значення атрибуту з переліку: "Реальний", "Цілий", "Логічний", "Рядок", "Рядок (переклад)", "Текст", "Текст (переклад)", "Об'єкт", "Вибір цілих чисел", "Вибір реальних чисел", "Вибір рядків".
• Режим — обрання режиму з переліку: "Вхід", "Вихід". Зазвичай використовується для визначення напрямку передачі даних за посередництвом зв'язку. Тобто для значення "Вхід" дані за зв'язком будуть тільки отримуватися, а для "Вихід" також будуть передаватися, у випадку модифікації.
• Атрибут — режим атрибуту параметра реалізованого на основі шаблону, з переліку: "Не атрибут", "Тільки для читання", "Повний доступ". Для атрибутів шаблону у яких це поле встановлено буде створюватися відповідний атрибут у параметрі контролеру цієї підсистеми.
• Конфігурація — режим конфігурації атрибуту у вкладці конфігурації шаблону параметра контролеру цієї підсистеми, з переліку: "Змінна", "Константа", "Зв'язок". У режимах "Константа" та "Зв'язок" у вкладці конфігурації шаблону будуть додані ці атрибути для встановлення константи або визначення зовнішнього зв'язку параметру.
• Значення — значення атрибуту по замовченню або шаблон посилання для доступу за посиланням:
  • Формат шаблону посилання залежить від компоненту, який його використовує. Загальний формат зв'язків записується у вигляді "{Parameter}|{attribute}". Поле Parameter — вказує ім'я параметру, як контейнеру атрибутів. Атрибути з однаковим значенням Parameter будуть групуватися та дозволять призначатися визначенням тільки контейнеру атрибутів, а окремі атрибути будуть пов'язані з атрибутами контейнеру відповідно до поля {attribute}.
  • Для вибірних типів це поле також може містити перелік значень, у другому рядку, та перелік назв, у третьому рядку, з поділом елементів символом ";".

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

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

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

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

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

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

• Розділ "Стан" — містить властивості, що характеризують стан об'єкту контролера та самого контролеру:

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

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

• Сховище — зберігання даних об'єкту контролера та його параметрів, з відстеженням наявності даних у різних сховищах та наданням послідовного видалення дублікатів. Параметри різних типів зберігаються у різних таблицях із власною структурою і уніфікованою назвою "{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) містить конфігурацію архіву повідомлень та форму запиту повідомлень з нього.

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

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

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

• Час, розмір (секунд) та рівень — вказує час, розмір або глибину (у секундах) та мінімальний рівень повідомлень (більш або рівний вказаному) запиту.
• Шаблон категорії — вказує категорію запитуваних повідомлень. У категорії можна вказувати елементи вибірки за шаблоном, а саме символи "*" — для будь якого підрядка та "?" — для будь якого символу, а також регулярний вираз заключений між символами '/' (/mod_(System|LogicLev)/).
• Архіватори — Вказує архіватори повідомлень, поділені символом ';', для яких обробляти запит. Якщо значення відсутнє то запит буде оброблено для буферу та всіх архіваторів. Якщо вказано "<buffer>" то запит буде оброблено для буферу повідомлень.

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

• Час, мкс — повна дата та час повідомлення, а також мікросекундна частина, окремо.
• Категорія — категорія повідомлення.
• Рівень — рівень повідомлення.
• Повідомлення — безпосередньо текст повідомлення.

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

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

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

• Період отримання даних — вказує на періодичність задачі активного архівування, у мілісекундах. Максимальна деталізація або мінімальний період активних архівів фактично визначається цим значенням.
• Рівень пріоритету задачі отримання даних — встановлює пріоритет задачі активного архівування. Використовується при плануванні задач операційною системою. У випадку наявності доступу це поле включає планування задачі архівації у режимі реального часу та з визначеним пріоритетом інакше модифікує параметр "nice" задачі.
• Примусово встановлювати мітку часу у поточний час — мітка часу отриманих при активній архівації значень примусово встановлюється у поточний час, замінюючи час джерела даних.
• Режим формування ID атрибуту автоматично створюваних архівів — режим формування ідентифікатору при обранні архівування у вкладці "Архівування" DAQ-параметрів.
• Кількість — деталізована кількість архівів значень із загальною статистикою щодо них: увімкнено, без джерела (пасивне), помилка (відсутнє джерело), втрачене (порожня БД).
• Архіви значень — сам перелік архівів значень.
• Видалити усе ... — групові операції видалення усього без джерела - пасивні, із помилкою джерела - джерело відсутнє, втрачені архіви - порожня БД.

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

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

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

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

• Розділ "Стан" — містить властивості що характеризують стан архіву:
  • Виконується — стан архіву "Виконується". Архів що виконується збирає дані у буфер та обслуговується архіваторами.
  • Початок та кінець буферу — дата та час початку та кінця значень у буфері.
  • Сховище — зберігання даних архіву, з відстеженням наявності даних у різних сховищах та наданням послідовного видалення дублікатів.
• Розділ "Конфігурація" — безпосередньо містить поля конфігурації:
  • Ідентифікатор — інформація про ідентифікатор архіву.
  • Ім'я — вказує ім'я архіву.
  • Опис — короткий опис архіву та його призначення.
  • Запускати — вказує на стан "Виконується" у який переводити архів при запуску програми.
  • Джерело — вказує на тип та адресу джерела. Тип джерела визначається з переліку: "Пасивний", "DAQ Атрибут" або "Активний DAQ Атрибут (ЗАСТАРІЛЕ)". Пасивний архів не має асоційованого джерела значень, а дані до такого архіву передаються джерелом самостійно, наприклад, з користувацьких обчислювальних процедур за посередництвом внутрішньої мови програмування. Типи з атрибутом параметру у полі адреси вказують на атрибут параметра підсистеми "Збір даних" як джерело. Основний атрибут параметру спрямовує дані до архіву самостійно з власним періодом збору даних. Активний атрибут параметру опитується завданням архівування цієї підсистеми. Всі джерела реальних даних працюють у основному режимі архівування оскільки отримані дані одразу поміщаються до атрибуту параметра, інколи за міткою часу джерела. Обчислювачі (DAQ.JavaLikeCalc, DAQ.LogicLev, DAQ.BlockCalc, DAQ.Siemens, DAQ.OPC_UA) також працюють зараз у основному режимі архівування та раніше використовували активний режим архівації оскільки дані у атрибуті параметру оновлювалися лише при їх безпосередньому запиті та бралися із контексту обчислення. У випадку з джерелами реальних даних, різниця між активним та основним режимом архівування визначається тим, що у основному режимі джерело може поміщати дані до архіву за міткою часу, а у активному режимі мітка часу завжди встановлюється у поточний системний час.
  • Режим об'єднання даних — встановлює режим об'єднання даних при запису з буферу високої роздільної здатності (наприклад, 1 секунда) у архіватор низької роздільної здатності (наприклад, 1 хвилина), коли у одну точку архіватора потрапляє декілька значень з буферу (наприклад, 60). Реалізовано режими: "Ковзне середнє", "Один", "Мінімум" та "Максимум".
  • Тип значень — вказує на тип значень, що зберігаються у архіві, з переліку: "Логічний", "Цілий", "Реальний", "Рядок", "Ціле16", "Ціле32", "Ціле64", "Реальне(Float)" та "Реальне(Double).
  • Період буферу — вказує на періодичність значень у буфері архіву, у секундах.
  • Розмір буферу — вказує розмірність або глибину буферу архіву, у одиницях. Розмірність автоматично встановлюється з розрахунку на 60 сек періодичності задачі архівування, із залишком.
  • Жорстка сітка часу буферу — вказує на режим буферу. Режим жорсткої сітки передбачає резервування пам'яті під кожне значення, але без мітки часу. Такий режим виключає можливість пакування суміжно-однакових значень, але заощаджує на зберіганні мітки часу. Інакше буфер працює у режимі зберігання значень у мітці часу та підтримує паковання суміжно-однакових значень.
  • Висока роздільна здатність часу буферу — вказує на можливість зберігання значень з періодичністю та роздільною здатністю до 1 мікросекунди, інакше значення можуть зберігатися з періодичністю та роздільною здатністю до 1 секунди.
  • Заповнення прохідних точок останнім значенням — прохідні значення переважно заповнюються EVAL однак інколи періодичність значень джерела більше за періодичність цього архіву та це нормально.

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

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

• Архіватор — інформація про адресу архіватора.
• Виконується — інформація про стан "Виконується" архіватору.
• Обробка — ознака обробки даного архіву архіватором. Поле доступно для модифікації користувачем.
• Період — інформація про періодичність архіватору, у секундах.
• Початок — дата та час початку даних архіву у архіваторі.
• Кінець — дата та час кінця даних архіву у архіваторі.

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

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

• Час — вказує дату та час запиту. Містить два поля: поле дата+час та мікросекунди.
• Розмір — вказує розмір або глибину запиту у секундах.
• Архіватор — вказує архіватор значень для якого обробляти запит. Якщо значення відсутнє то запит буде оброблено для буферу та всіх архіваторів. Якщо вказано "<buffer>", то запит буде оброблено тільки для буферу архіву.
• Показати графік — вказує на необхідність представлення даних архіву у вигляді графіку (тренду) інакше результат надається у таблиці, що містить тільки час та значення. У випадку встановлення цього поля формується та відображається графік, крім того з'являються додаткові конфігураційні поля налаштування зображень:
  • Розмір зображення — вказує ширину та висоту зображення що формується, у пікселях.
  • Шкала значення — вказує нижню та верхню границю шкали значень. Якщо обидва значення встановлено у 0 або дорівнюють то шкала буде визначатися автоматично у залежності від значень.

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

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

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

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

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

• Розділ "Стан" — містить властивості що характеризують стан архіватору:
  • Виконується — стан архіватору "Виконується". Архіватор що виконується обробляє буфер архіву повідомлень та поміщає його дані до свого сховища, а також обслуговує запити на доступ до даних у цьому сховищі.
  • Сховище — зберігання даних архіватору, з відстеженням наявності даних у різних сховищах та наданням послідовного видалення дублікатів.
  • Кінець та початок архіватору — дата та час кінця та початку значень даних у сховищі архіватору.
  • Загальний розмір файлів архіватору — інформація про загальний розмір файлів архіватору з даними.
  • Час архівування — поточний та максимальний час, витрачений на архівування даних архіву повідомлень.
• Розділ "Конфігурація" — безпосередньо містить поля конфігурації:
  • Ідентифікатор — інформація про ідентифікатор архіватору.
  • Ім'я — вказує ім'я архіватору.
  • Опис — короткий опис архіватору та його призначення.
  • Запускати — вказує на стан "Виконується" у який переводити архіватор при запуску програми.
  • Категорії повідомлень — перелік категорій повідомлень, поділених символом ';'. Повідомлення, що потрапили під шаблони або регулярні вирази категорій, будуть оброблятися архіватором. У категорії можна вказати елементи вибірки за шаблоном, а саме символи '*' — для будь якого підрядка та '?' — для будь якого символу, а також регулярний вираз, включений між символами '/' (/mod_(System|LogicLev)/).
  • Рівень повідомлень — вказує на рівень повідомлень архіватору. Повідомлення з рівнем більш або рівним вказаному обробляються архіватором — беруться з буферу.
  • Адреса — адреса сховища у специфічному для типу архіватору (модуля) форматі. Опис формату запису адреси архіватору як правило доступний у спливаючій підказці цього поля. У прикладі це відносний шлях до теки сховища.
• Розділ "Додаткові опції" — спеціалізований для модуля розділ з вмістом якого можна ознайомитися у документації на модуль.

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

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

• Час, розмір (секунд) та рівень — вказує дату та час, розмір або глибину та мінімальний рівень повідомлень (більш або рівний вказаному) запиту.
• Шаблон категорії — вказує категорію запитаних повідомлень. У категорії можна вказувати елементи вибірки за шаблоном, а саме символи '*' — для будь якого підрядка та '?' — для будь якого символу, а також регулярний вираз, заключений між символами '/' (/mod_(System|LogicLev)/).

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

• Час, мкс — повна дата та час повідомлення, а також мікросекундна частина, окремо.
• Категорія — категорія повідомлення.
• Рівень — рівень повідомлення.
• Повідомлення — безпосередньо текст повідомлення.

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

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

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

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

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

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

• Архів — ім'я архіву.
• Період, секунд — періодичність архіву.
• Розмір буферу — розмір буферу, у одиницях.
• Останнє читання буферу — дата та час останнього читання даних з буферу.
• Розмір файлів — специфічне до модуля Arch.FSArch поле з інформацією про сумарний розмір файлів сховища архіватору для архіву.

У випадку з модулем 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) містить основні налаштування підсистеми у складі:

• Шлях до поділюваних бібліотек(модулів) — інформація про розташування теки з модулями OpenSCADA. Встановлюється параметром ModDir конфігураційного файлу станції.
• Заборонені модулі — перелік модулів, поділений символом ';', заборонених до автоматичного підключення та оновлення. Встановлюється параметром ModDeny розділу підсистеми "sub_ModSched" конфігураційного файлу станції. Перелік заборонених модулів має більший пріоритет ніж дозволених.
• Дозволені модулі — перелік модулів, поділених символом ';', дозволених до автоматичного підключення та оновлення. Значення '*' використовується для дозволу всіх модулів. Встановлюється параметром ModAllow розділу підсистеми "sub_ModSched" конфігураційного файлу станції.
• Період перевірки модулів — вказує на період перевірки модулів на факт їх оновлення, у секундах. Модулі, дозволені до автоматичного підключення та оновлення, будуть автоматично оновлені.
• Перевірити модулі зараз — команда виконати перевірку модулів на факт їх оновлення. Модулі, допустимі для автоматичного підключення та оновлення, будуть автоматично оновлені.
• Поділювані бібліотеки (модулі) — таблиця з переліком поділюваних бібліотек з модулями, що виявлені OpenSCADA. У рядках розташовано модулі, а у стовпчиках інформацію про них:
  • Джерело — джерело модуля(ів), яке або поділювана бібліотека або вбудований код.
  • Час — інформація про дату та час останньої модифікації файлу поділюваної бібліотеки.
  • Модулі — інформація про перелік модулів у поділюваній бібліотеці.
  • Ввімкнено — стан "Ввімкнено" поділюваної бібліотеки. Привілейованим користувачам надається можливість ручного включення/виключення поділюваних бібліотек шляхом зміни цього поля.

Рис. 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" /> містять індивідуальні параметри модулів та секції таблиць відображення даних баз даних у конфігураційному файлі.

Типові значення опцій командного рядка і загальні параметри ви можете передати через змінні оточення у формі "OSCADA_{OPT}={VAL}" після увімкнення змінною оточенняOSCADA_CMD_EN, на кшталт — OSCADA_CMD_EN=1 OSCADA_log=0 OSCADA_limObjDscr_SZ=1000 OSCADA_sub_UI_mod_QTStarter_Style=Fusion ./openscada_AGLKS. Тобто ви можете приготувати індивідуальне типове середовище виконання OpenSCADA для вашої системи загалом у файлі теки /etc/profile.d/ або для конкретного користувача у файлі {USER-HOME}/.profile.

Секції таблиць відображення даних баз даних призначено для розташування у конфігураційному файлі записів таблиць БД для компонентів 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})"!
limObjDscr_SZ   [300...*1000...1000000] Розмір ОПИСУ об'єктів OpenSCADA.
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> =============================
    --getaddrinfo[=<lev>] Використати getaddrinfo() для вирішення усіх адрес.
                        <lev> - рівень використання:
                                1(типово) - із глобальним блокуванням ресурсу;
                                2 - без блокування.

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

======================= Опції модуля <Transport:SSL> =============================
    --getaddrinfo[=<lev>] Використати getaddrinfo() для вирішення усіх адрес.
                        <lev> - рівень використання:
                                1(типово) - із глобальним блокуванням ресурсу;
                                2 - без блокування.

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

======================= Опції модуля <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 та який передбачає режими:

• основний режим виконання проєкту OpenSCADA із:
  • відкриттям визначених модулів Qt;
  • відкриттям власного діалогового вікна пускачу (Рис.5a);
  • запуском-згортанням до системного лотка (Рис.5b) — фактично є режимом фонового виконання, але з доступом із графічного середовища.
• режим ініціюючого запуску (Рис.5c) — обрання проєкту для перемикання у основний режим виконання проєкту OpenSCADA.

Рис.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 та інше.

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

• сам конфігураційний файл ("oscada.xml");
• файли БД проєкту та бібліотек (тека "LibsDB") у режимі повного доступу та/або посилання на лише для читання;
• архіви повідомлень та значень на файлову систему (тека "ARCHIVES");
• зображення та медіа-дані (тека "icons");
• документація (тека "docs");
• специфічні файли конфігурації, ресурси модулів OpenSCADA та внутрішніх процедур проєкту.

Назва теки проєкту дорівнює назві проєкту та розташовується у робочій теці 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 передбачає функції та команди довкола проєктів:

• list — перелік наявних проєктів;
• proc — опрацювати на предмет: копіювання RO проєкту у RW, створення іконки-ярлика на робочій стільниці, генерації звіту про падіння та інше;
• create — створення нового проєкту, додатково до всіх функцій proc;
• remove — видалення існуючого проєкту.

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

• backup — резервне копіювання обраного проєкту ProjName до BackupName, або на поточну дату за відсутності;
• backupRestore — відновлення обраного проєкту ProjName із резервної копії з вказаною назвою BackupName, або із останньої за відсутності;
• backupList — перелік резервних копій проєкту ProjName.

Резервне копіювання загалом здійснюється у робочій теці 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).

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

• встановлюємо пакет openscada-model-aglks (openscada-lts-model-aglks для LTS)та openscada-server (openscada-lts-server для LTS), якщо їх ще не встановлено та це не оточення Живого Диску або Linux Автоматизації від встановлення цього Диску;
• запускаємо проєкт "АГЛКС" для отримання його теки у користувацькій робочій теці;
• копіюємо теку проєкту "АГЛКС" до системної робочої теки із перейменуванням у "server", попередньо зупинивши фонове виконання проєкту "server" та видаливши його теку проєкту; наприклад, наступним чином із консолі:

# Підключитися від суперкористувача
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

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

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

6 Посилання

• Діаграма: Блокова схема OpenSCADA.
• Діаграма: Ієрархічна структура підсистеми "Збір даних".
• Діаграма: Ієрархічна структура підсистеми "БД".
• Діаграма: Ієрархічна структура підсистеми "Архіви".
• Діаграма: Ієрархічна структура підсистеми "Транспорти" та "Протоколи".
• Діаграма: Ієрархічна SCADA-система.
• Діаграма: Набір використання OpenSCADA.