From OpenSCADAWiki
Jump to: navigation, search
This page is a translated version of the page Documents/Program manual and the translation is 100% complete.

Other languages:
English • ‎российский • ‎українська

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

Contents

Цей документ є посібником по програмі з відкритими вихідними текстами за назвою "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 наразі надає більш ніж двадцять модулів та бібліотечних елементів джерел логічних типів. Більш значущі та опрацьовані з яких:

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

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

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

Джерела динамічних даних можуть бути віддаленим, тобто формуватися або отримуватися на віддаленій станції 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), яка є модульною та дозволяє вести архіви повідомлень та значень. Модульним об'єктом, який міститься у підсистемі "Архіви-Історія", виступає тип архіватору. Тип архіватору визначає спосіб зберігання даних тобто сховище — файлова система, СУБД. Кожен модуль підсистеми "Архіви-Історія" відповідно може реалізовувати архівування повідомлень та значень та сама підсистема може містити багато архівів, які обслуговуються різними модулями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • архівування або ведення історії даних 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_start", які здійснюють встановлення робочої теки та адреси конфігураційного файлу згідно до вказаного проекту. Детальніше про це описано у розділі "Проекти OpenSCADA".

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

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

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

Окрім баз даних конфігурації можуть міститися у конфігураційному файлі OpenSCADA, а також передаватися за посередництвом параметрів командного рядку при виклику OpenSCADA. Збереження конфігурації у конфігураційному файлі здійснюється нарівні з БД. Типовим ім'ям конфігураційного файлу OpenSCADA є {sysconfdir}/oscada.xml (де sysconfdir зазвичай — "/etc"), для конфігурацій поза проектами OpenSCADA, та {Proj}/oscada.xml для проекту "Proj". Формат конфігураційного файлу та параметри командного рядку розглянемо у окремому розділі.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • редагування вмісту клітинок таблиці;
  • додання запису (рядка);
  • видалення запису (рядка).
Рис. 4.1g. Вкладка "Таблиця" таблиці БД модуля підсистеми "БД".

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.1a) містить перелік модулів підсистеми "Транспорти" та ідентична до всіх модульних підсистем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Розділ "Стан" — містить властивості, що характеризують стан об'єкту контролера та самого контролеру:
    • Статус — вказує на статус об'єкту контролера та самого контролеру. У нашому випадку контролер виконується, поточний час виконання складає 499 мікросекунд та максимальний 4.2 мілісекунди.
    • Ввімкнено — стан об'єкту контролера "Ввімкнено". Ввімкнений об'єкт контролеру надає можливість створення параметрів та їх конфігурації.
    • Виконується — стан об'єкту контролера "Виконується". Об'єкт контролеру що виконується здійснює фізичний збір даних та/або включає механізми доступу до цих даних.
    • БД контролеру — адреса БД для зберігання даних об'єкту контролера та його параметрів.
  • Розділ "Конфігурація" — безпосередньо містить поля конфігурації:
    • Ідентифікатор — інформація про ідентифікатор об'єкту контролера.
    • Ім'я — вказує ім'я контролеру.
    • Опис — короткий опис контролеру та його призначення.
    • Вмикати — вказує на стан "Ввімкнено" у який переводити об'єкт контролеру при запуску програми.
    • Запускати — вказує на стан "Виконується" у який переводити об'єкт контролеру при запуску програми.
    • Таблиці параметрів — імена таблиць, у яких зберігати параметри різних типів (мається на увазі об'єкти параметрів збору даних).
    • Планування обчислення — визначає періодичний або за розкладом характер обчислення. У нашому прикладі це періодичне секундне обчислення шаблону.
    • Рівень пріоритету задачі отримання даних — встановлює пріоритет задачі збору даних цього контролеру. Використовується при плануванні задач операційною системою. У випадку наявності доступу це поле включає планування задачі контролеру у режимі реального часу та за визначеним пріоритетом інакше модифікує параметр "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" або права привілейованого користувача.

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

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

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

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

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

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

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

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

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

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

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

  • Час, мкс — повна дата та час повідомлення, а також мікросекундна частина, окремо.
  • Категорія — категорія повідомлення.
  • Рівень — рівень повідомлення.
  • Повідомлення — безпосередньо текст повідомлення.
Рис. 4.6b. Вкладка "Повідомлення" підсистеми "Архіви-Історія".

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

  • Період отримання даних — вказує на періодичність задачі активного архівування, у мілісекундах. Максимальна деталізація або мінімальний період активних архівів фактично визначається цим значенням.
  • Рівень пріоритету задачі отримання даних — встановлює пріоритет задачі активного архівування. Використовується при плануванні задач операційною системою. У випадку наявності доступу це поле включає планування задачі архівації у режимі реального часу та з визначеним пріоритетом інакше модифікує параметр "nice" задачі.
  • Примусово встановлювати мітку часу у поточний час — мітка часу отриманих при активній архівації значень примусово встановлюється у поточний час, замінюючи час джерела даних.
Рис. 4.6c. Вкладка "Значення" підсистеми "Архіви-Історія".

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

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

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

  • Розділ "Стан" — містить властивості що характеризують стан архіву:
    • Виконується — стан архіву "Виконується". Архів що виконується збирає дані у буфер та обслуговується архіваторами.
    • Початок та кінець буферу — дата та час початку та кінця значень у буфері.
    • БД архіву — адреса БД для зберігання конфігурації архіву.
  • Розділ "Конфігурація" — безпосередньо містить поля конфігурації:
    • Ідентифікатор — інформація про ідентифікатор архіву.
    • Ім'я — вказує ім'я архіву.
    • Опис — короткий опис архіву та його призначення.
    • Запускати — вказує на стан "Виконується" у який переводити архів при запуску програми.
    • Джерело — вказує на тип та адресу джерела. Тип джерела визначається з переліку: "Пасивний", "Пасивний атрибут параметру" або "Активний атрибут параметру". Пасивний архів не має асоційованого джерела значень, а дані до такого архіву передаються джерелом самостійно, наприклад, з користувацьких обчислювальних процедур за посередництвом внутрішньої мови програмування. Типи з атрибутом параметру у полі адреси вказують на атрибут параметра підсистеми "Збір даних" як джерело. Пасивний атрибут параметру спрямовує дані до архіву самостійно з власним періодом збору даних. Активний атрибут параметру опитується завданням архівування цієї підсистеми. Фактично всі джерела реальних даних працюють у пасивному режимі архівування оскільки отримані дані одразу поміщаються до атрибуту параметра, інколи за міткою часу джерела. А ось обчислювачі (DAQ.JavaLikeCalc, DAQ.LogicLev, DAQ.BlockCalc, DAQ.Siemens) можуть працювати тільки у активному режимі архівування оскільки дані у атрибуті параметру оновлюються тільки при їх безпосередньому запиті та беруться з контексту обчислення. У випадку з джерелами реальних даних, різниця між активним та пасивним режимом архівування визначається тим, що у пасивному режимі джерело може поміщати дані у архів за міткою часу, а у активному режимі мітка часу завжди встановлюється у поточний системний час.
    • Режим об'єднання даних — встановлює режим об'єднання даних при запису з буферу високої роздільної здатності (наприклад, 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.1c), склад якої ідентичний для всіх модулів.

Рис. 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.1a) містить перелік модулів підсистеми "Спеціальні" та ідентична для всіх модульних підсистем.

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

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

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

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

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

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

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

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

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

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

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

Конфігураційний файл 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="Lang2CodeBase">en</prm>
        <prm id="SaveAtExit">0</prm>
        <prm id="SavePeriod">0</prm>

        <node id="sub_BD">
            <prm id="SYSStPref">0</prm>
            <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>&lt;prms MaxQueue="10" MaxClients="20" MaxClientsPerHost="5" BufLen="5" KeepAliveReqs="0" KeepAliveTm="60" /&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>&lt;prms MaxQueue="10" MaxClients="100" MaxClientsPerHost="25" BufLen="5" KeepAliveReqs="0" KeepAliveTm="5" /&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>&lt;prms MaxQueue="10" MaxClients="100" MaxClientsPerHost="25" BufLen="5" KeepAliveReqs="0" KeepAliveTm="5" /&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&#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)?&quot;1:&quot;+alrm_mess:&quot;0&quot;;"/>
                </tbl>
                <tbl id="lib_TemplFunc_io">
                    <fld F_ID="d_alarm" ID="in" NAME="Input" NAME_uk="Вхід" NAME_ru="Вход" TYPE="3" MODE="0" DEF="" HIDE="0" POS="0"/>
                    <fld F_ID="d_alarm" ID="alrm" NAME="Alarm" NAME_uk="Аварія" NAME_ru="Авария" TYPE="0" MODE="1" DEF="" HIDE="0" POS="1"/>
                    <fld F_ID="d_alarm" ID="alrm_md" NAME="Alarm mode" NAME_uk="Режим аварії" NAME_ru="Режим аварии"
                        TYPE="3" MODE="0" DEF="" HIDE="0" POS="2"/>
                    <fld F_ID="d_alarm" ID="alrm_mess" NAME="Alarm message" NAME_uk="Повідомлення аварії" NAME_ru="Сообщение аварии"
                        TYPE="0" MODE="0" DEF="" HIDE="0" POS="3"/>
                </tbl>-->
            </node>

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

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

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

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

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

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

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

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

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

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

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

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

</OpenSCADA>

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

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

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

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

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

===========================================================================
======================== Основні опції ====================================
===========================================================================
-h, --help              Цей текст допомоги за опціями командного рядку та параметрами конфігураційного файлу програми.
    --projName=<ім'я>   Ім'я проекту OpenSCADA для перемикання.
                        Для такої операції також використовується змінна оточення "OSCADA_ProjName" та ім'я бінарної програми "openscada_{ProjName}".
    --projUserDir={тека} Тека користувацьких проектів OpenSCADA (доступна для запису), по замовченю "~/.openscada".
    --projLock={per}    Використовувати блокування проектів створенням файлу "lock" у теці проекту та його оновлення з періодом <per>,
                        по замовченю включено та період оновлення <per> складає 60 секунд. Для вимкнення встановити період оновлення <per> у нуль.
    --lang=<LANG>       Мова станції, у вигляді "uk_UA.UTF-8".
    --config=<файл>     Конфігураційний файл станції.
    --station=<ід>      Ідентифікатор станції.
    --statName=<ім'я>   Ім'я станції.
    --demon, --daemon   Запуск у режимі демона.
    --pidFile=<file>    файл для розташування ID процесу програми тут.
    --noCoreDump        Запобігати створеню передсмертних дампів - не знімати це обмеження.
    --messLev=<рівень>  Рівень оброблюваних повідомлень (0-7).
    --log=<напрямок>    Спрямування повідомлень до, за бітовим полем:
                          0x1 - системний логер (syslogd);
                          0x2 - стандартний вихід (stdout);
                          0x4 - стандартний вихід помилок (stderr);
                          0x8 - архів повідомлень.
------ Параметри станції '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".
Lang2CodeBase <мова>    Базова мова для перекладу текстових змінних, два символи.
MainCPUs   <перелік>    Основний перелік використаних процесорів, поділено ':'.
ClockRT    <0|1>        Встановити використання джерела годиннику у REALTIME (інакше MONOTONIC), дещо проблематичне при модифікації системного годинника.
SaveAtExit <0|1>        Зберігати програму при виході.
SavePeriod <сек>        Період збереження програми, у секундах. Встановити у нуль для вимкнення.
RdStLevel  <рів>        Рівень резервування поточної станції.
RdTaskPer  <сек>        Період виклику задачі обслуговування резервування, у секундах.
RdRestConnTm <сек>      Час відновлення з'єднання з "мертвою" резервною станцією, у секундах.
RdStList   <перел>      Перелік резервних станції, поділено символом ';' (st1;st2).
RdPrimCmdTr <0|1>       Включення трансляції первинних команд до резервних станцій.

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

========================= Опції підсистеми "БД" =========================
---------- Параметри секції '/sub_BD/' конфігураційного файлу ----------
SYSStPref  <0|1>        Використовувати ідентифікатор станції у загальній таблиці (SYS).

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

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

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

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

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

====================== Опції підсистеми "Архіви-Історія" ========================
---------- Параметри секції '/sub_Archive/' конфігураційного файлу ----------
MessBufSize <од.>       Розмір буферу повідомлень.
MessPeriod <сек>        Період архівування повідомлень.
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.

================= Опції підсистеми "Інтерфейси користувачів" ============

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

========================= Опції модуля <UI:QTStarter> ===========================
------ Налагоджувані параметри 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 модулів до системного трею.
Style      <ім'я>       GUI стиль Qt.
Palette    <кольори>    Двадцять кольорів палітри поділених символом ',' у трьох рядках для активної, вимкненої та неактивної груп.
StyleSheets <CSS>       Правила таблиці каскадних стилів (CSS).

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

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

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

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

  • Режим отримання допомоги по параметрам командного рядку — openscada --help.
  • Режим демону — openscada --demon, фонового або сервісного виконання. Передбачає від'єднання від консолі запуску та фонове виконання, тобто візуально програма наче одразу завершується, консоль звільняється та блокуються всі модулі локального графічного інтерфейсу на кшталт Qt. Використовується для запуску та виконання програми у режимі обслуговування сервісів на кшталт: серверу SCADA, середовища виконання ПЛК, серверу візуалізації, серверу WEB-інтерфейсів. Зазвичай ця команда поміщається до файлів опису-формування сервісу операційної системи та декілька готових наразі постачаються разом з OpenSCADA.
  • Режим налагодження сервісу-демону — 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 можна запустити як у режимі демону-сервісу, так і графічного інтерфейсу просто вказавши ім'я чинного проекту у чотири способи:

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

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

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

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

6 Посилання