Автор: Роман Савоченко
Цей документ є посібником по програмі з відкритими вихідними текстами за назвою "OpenSCADA". OpenSCADA представляє собою відкриту SCADA систему, побудовану за принципами модульності, багатоплатформеності та масштабованості.
У якості політики розробки цієї програми обрано "open source" принципи. Вибір цієї політики визначається потребою створення відкритої, надійної та загальнодоступної SCADA системи. Така політика дозволяє залучити до розробки, тестування, розвитку, розповсюдженню та використанню програми значну кількість розробників, ентузіастів та інших зацікавлених осіб з мінімізацією та розподілом зусиль та фінансових витрат.
OpenSCADA призначено для збору, архівування, візуалізації інформації, видачі керуючих дій, а також інших споріднених операцій, характерних для повнофункційних SCADA систем. Завдяки високому рівню абстракції та модульності програма може використовуватися у багатьох суміжних галузях.
OpenSCADA може та застосовується на/у:
У якості основної операційної системи (програмної платформи) для розробки та використання обрано ОС Linux, яка є оптимальним рішенням у питаннях:
Оскільки проект розробляється та реалізується за принципами багатоплатформеності то не складає великої проблеми портувати його на інші операційні системи (програмні платформи) та апаратні платформи. Що заплановано на майбутнє та значним чином вже здійснено для деяких платформ.
Серцем програми є модульне ядро. Та залежно від того які модулі підключено програма може виступати як у ролі різних серверів, так і в ролі різноманітних клієнтів, а також поєднувати ці функції у одній програмі. Це дозволяє реалізовувати клієнт-серверну архітектуру на базі одних й тих же компонентів/модулів, економлячи при цьому машинну пам'ять, дисковий простір, а також цінний час програмістів.
Серверні конфігурації програми призначені для видачі керуючих дій, збору, обробки, архівування, протоколювання інформації від різних джерел, а також надання цієї інформації клієнтам (UI, GUI, TUI ...). Модульна архітектура дозволяє розширювати функціональність серверу без його перевантаження.
Клієнтські конфігурації можуть будуватися на основі різних графічних бібліотек (GUI/TUI ToolKits), як використовуючи ядро програми та його модулі (шляхом додання до нього модуля користувацького інтерфейсу), так і у якості самостійного додатку, підключаючи ядро OpenSCADA як бібліотеку.
Гнучкість конфігурації програми дозволяє будувати рішення під конкретні вимоги надійності, функціональності та розміри-складність програми.
Для надання гнучкості та високого ступеню масштабування OpenSCADA побудовано за модульним принципом. Тісна інтеграція модулів з ядром покращує стабільність програми в цілому, завдяки повторному використанню налагодженого коду. Однак сам процес розробки власного коду модулів OpenSCADA накладає велику відповідальність — можливі помилки вводять елемент нестабільності у програму. Можливість створення розподілених конфігурацій згладжує цю небезпеку.
Модулі OpenSCADA зберігаються у динамічних бібліотеках. Кожна динамічна бібліотека може містити багато модулів різного типу. Наповнення динамічних бібліотек модулями визначається функціональною зв'язністю самих модулів. Динамічні бібліотеки допускають гарячу заміну, що дозволяє здійснювати оновлення окремих частин програми у процесі функціонування. Метод зберігання коду модулів у динамічних бібліотеках є основним для OpenSCADA, оскільки підтримується практично всіма сучасними операційними системами (ОС). Однак це не виключає можливості розробки інших методів зберігання коду модулів.
На основі модулів реалізовано наступні функціональні частини OpenSCADA:
Управління модулями здійснюється підсистемою "Планувальник модулів". Функціями підсистеми є: підключення, відключення, оновлення та інші операції, пов'язані з модулями та бібліотеками модулів.
Архітектурно OpenSCADA поділяється на підсистеми. Підсистеми можуть бути двох типів: звичайні та модульні. Модульні підсистеми мають властивість розширення посередництвом модулів. Кожна модульна підсистема може містити багато модульних об'єктів. Наприклад, модульна підсистема "Бази даних" містить модульні об'єкти типів баз даних. Модульний об'єкт є коренем всередині модуля.
Разом OpenSCADA містить дев'ять підсистем, з них сім є модульними. Ці дев'ять підсистем OpenSCADA є базовими та присутні у будь якій конфігурації. До переліку дев'яти підсистем можуть додаватися нові, за посередництвом самих модулів. Підсистеми OpenSCADA:
Підсистему "Збір даних" (Рис. 1.3) передбачено для надання підтримки джерел динамічних даних, будь то: ПЛК, плати ПУО, віртуальні джерела та інше. До функції цієї підсистеми входить надання отриманих даних у структурованому вигляді та забезпечення управління цими даними, наприклад — модифікація даних.
Підсистема "Збір даних" є модульною та, як наслідок, містить модульні об'єкти типів джерел динамічних даних. Наприклад, OpenSCADA наразі надає більш ніж двадцять модулів та бібліотечних елементів джерел логічних типів. Більш значущі та опрацьовані з яких:
Кожний тип джерела нелогічного типу реалізується у окремому модулі, який може містити багато джерел (об'єктів контролерів) та кожне це джерело зазвичай виконується у окремому потоці-завдані.
Окремо взятий об'єкт контролеру може містити параметри визначених модулем типів. Наприклад, параметри аналогового типу, основною інформацією яких є значення цілого або реального типу. Структурно параметр представляє собою перелік атрибутів, які й містять дані. Атрибути можуть бути п'яти базових типів: логічний, цілий, реальний, символьний рядок(текст) та об'єкт. Структури об'єктів контролерів, параметрів та їх типів містяться у підсистемі "Збір даних", а об'єкти модулів здійснюють їх заповнення згідно зі власною специфікою.
Окремі типи джерел даних самі можуть продукувати дані як повністю їх генеруючи, так і обробляючи фізичні дані та навіть повністю реалізуючи отримання цих даних у оточені OpenSCADA та на її внутрішній мові. Такі джерела даних називаються логічними. Повністю логічні джерела даних представлені модулями: LogicLev та BlockCalc. Існує низка модулів, які поєднують у собі логічні дані як результат безпосередньої обробки фізичних: ModBus та Siemens.
Джерела динамічних даних можуть бути віддаленим, тобто формуватися або отримуватися на віддаленій станції OpenSCADA. Для зв'язку з такими джерелами даних використовується модуль шлюзування DAQGate. Функцією цього типу джерел даних є відображення джерел даних віддаленої OpenSCADA станції на локальну.
Детально ознайомитися із ключовою підсистемою "Збір даних" та її функціями Ви можете у окремому документі "Збір даних у OpenSCADA".
Для зберігання даних програми повсякчасно використовуються бази даних (БД). З метою уніфікації доступу та управління базами даних у OpenSCADA передбачено підсистему "Бази даних" (Рис. 1.4). Для забезпечення підтримки різних БД/СУБД підсистему виконано модульною.
У ролі модульного об'єкту, що міститься у підсистемі, виступає тип БД/СУБД, тобто модуль підсистеми "Бази даних" практично містить реалізацію доступу до визначеного типу БД. OpenSCADA надає наступні більш значущі та опрацьовані модулі: SQLite, MySQL, PostgreSQL, FireBird.
Тип БД/СУБД своєю чергою містить перелік об'єктів окремих БД цього типу, а об'єкт БД містить перелік об'єктів таблиць, які й містять дані у табличній формі.
Практично всі дані OpenSCADA зберігаються у тій або іншій БД. Інструментарій програми дозволяє легко переносити дані з одного типу БД на інший, та, як наслідок, оптимально підбирати тип БД під конкретну сферу застосування OpenSCADA. Перенос інформації з однієї БД до іншої може бути виконано двома способами. Перший — це зміна адреси робочої БД та збереження всієї конфігурації програми на неї, другий — це пряме копіювання інформації між БД. Крім копіювання підтримується й функція прямого редагування вмісту таблиць БД.
Для організації централізованого доступу розподіленої програми до єдиної БД передбачається два способи. Перший це використання мережевих СУБД, наприклад — MySQL. Другий спосіб це використання транспортного типу БД на локальних станціях, для доступу до однієї центральної БД іншої OpenSCADA станції, через пересилку запитів до БД на цій віддаленій станції — не реалізовано ще у OpenSCADA.
Дані можуть зберігатися також у конфігураційному файлі програми. Реалізовано механізм повного відображення структури БД на структуру конфігураційного файлу. Тобто стандартну конфігурацію можна розміщувати у конфігураційному файлі. Сутність такого механізму полягає у тому, що типові (по замовченню) дані програми можна описувати у конфігураційному файлі, наприклад — при старті без БД. Надалі ці дані можуть перевизначатися у БД. Крім того, для випадків неможливості запуску будь якої БД взагалі, можна всі дані зберігати у конфігураційному файлі.
Для доступу до баз даних використовується механізм реєстрації БД. Зареєстровані у програмі БД доступні усім підсистемам OpenSCADA та можуть використовуватися у їх роботі. Завдяки цьому механізму можна забезпечити розподіл зберігання даних. Наприклад, різні бібліотеки можуть зберігатися та розповсюджуватися незалежно, а підключення бібліотеки буде полягати у простій реєстрації потрібної БД.
Будь яка SCADA система має надавати можливість архівування зібраних даних, тобто формувати історію зміни (динаміки) процесу. Архіви умовно можна поділити на два типи: архіви повідомлень та архіви значень.
Особливістю архівів повідомлень є архівація так званих повідомлень програми, а саме — ведення логів та протоколів. Характерною ознакою повідомлення є час його виникнення. Залежно від джерела повідомлення можуть класифікуватися за різними критеріями. Наприклад, це можуть бути протоколи аварійних ситуацій, протоколи дій операторів, протоколи відмов зв'язку та інше.
Особливістю архівів значень є їх періодичність, яка визначається проміжком часу між двома суміжними значеннями. Архіви значень застосовуються для архівування історії неперервних процесів. Оскільки процес неперервний то й архівувати його можна тільки шляхом введення поняття квантування опитування значень, інакше ми отримаємо архіви нескінчених розмірів, відповідно до неперервності самої природи процесу. Крім того, практично ми можемо отримати значення з періодом обмеженим самими джерелами даних. Наприклад, доволі якісні джерела даних у промисловості рідко дозволяють отримувати дані з частотою більш 1 кГц та це без врахування самих давачів, які мають менш якісні частотні характеристики.
Для вирішення задач архівування потоків даних у OpenSCADA передбачено підсистему "Архіви-Історія" (Рис. 1.5), яка є модульною та дозволяє вести архіви повідомлень та значень. Модульним об'єктом, який міститься у підсистемі "Архіви-Історія", виступає тип архіватору. Тип архіватору визначає спосіб зберігання даних тобто сховище — файлова система, СУБД. Кожен модуль підсистеми "Архіви-Історія" відповідно може реалізовувати архівування повідомлень та значень та сама підсистема може містити багато архівів, які обслуговуються різними модулями.
Повідомлення у OpenSCADA характеризуються датою, рівнем важливості, категорією та безпосередньо текстом повідомлення. Дата повідомлення відповідно вказує на дату та час його створення. Рівень важливості вказує на ступінь важливості повідомлення. Категорія визначає адресу або умовний ідентифікатор-ключ джерела повідомлення. Часто категорія містить повний шлях до джерела повідомлення у програмі. Текст повідомлення відповідно й несе головне смислове навантаження повідомлення.
У процесі архівування повідомлення пропускаються через фільтр, який працює за рівнем важливості та категорією повідомлень. Рівень повідомлень у фільтрі вказує на те, що треба пропускати повідомлення з вказаним або вищим рівнем важливості. Для фільтрування за категорією застосовуються шаблони або регулярні вирази, які визначають які повідомлення пропускати. Кожний архіватор містить власні налаштування фільтру, відповідно можна легко створювати різні спеціалізовані архіватори для архіву повідомлень. Наприклад, архіватори повідомлень можна спрямувати на:
Згідно до схожості природи повідомлень та порушень підсистема "Архіви-Історія" містить буфер поточних порушень, який містить активні на цей час порушення за категорією повідомлення у ролі ключа-ідентифікатору порушення. Доступ до переліку-буферу поточних порушень здійснюється шляхом указання негативного значення рівня повідомлення. Так, формування повідомлення з негативним рівнем -2 викликає розташування цього повідомлення у буфері активних порушень з рівнем 2, а також дублювання його безпосередньо у архіві повідомлень (буфері загальних повідомлень). За формуванням повідомлення у такій же категорії, але за позитивним рівнем — скажемо 1, буде здійснено видалення вказаного порушення з буферу порушень, а саме повідомлення також потрапить до архіву повідомлень (буферу загальних повідомлень). Такий механізм дозволяє одночасно вести облік активних порушень та протоколювати їх проходження у архіві повідомлень. При запиті до архіву повідомлень, визначення позитивного рівня здійснює запит до архіву повідомлень (через загальний буфер повідомлень), а негативного до буферу-переліку поточних порушень.
Архіви значень у OpenSCADA виступають як незалежні компоненти, які включають буфери, оброблювані архіваторами. Основним параметром архівів значень є джерело даних, у ролі якого можуть виступати атрибути параметрів підсистеми "Збір Даних", а також інші зовнішні джерела даних (пасивний режим). Іншими джерелами даних можуть бути мережеві архіватори віддалених станцій OpenSCADA, середовище програмування OpenSCADA та інше.
Ключовим компонентом архівування значень неперервних процесів є буфер значень, який призначено для проміжного зберігання масиву значень, отриманого з визначеною періодичністю (квантом часу). Буфер значень використовується для безпосереднього зберігання великих масивів значень у архівах значень як перед безпосереднім "скиданням" на фізичний носій, так і для маніпуляцій з кадрами значень, тобто у функціях покадрового запиту значень та їх розташування у буфері архівів.
Для організації віддалених архіваторів у розподілених конфігураціях використовується транспортний тип архіватору, наразі не реалізовано у OpenSCADA. Функцією транспортного типу архіваторів є відображення віддаленого центрального архіватору OpenSCADA у локальній конфігурації. Як наслідок, архіватори транспортного типу виконують передачу даних між локальною конфігурацією та архіватором віддаленої конфігурації програми, приховуючи від підсистем локальної конфігурації реальну природу архіватору.
Оскільки OpenSCADA є високо-масштабованою то підтримка комунікацій має бути достатньо гнучкою, для чого вона реалізована у підсистемах "Транспорти" та "Транспортні протоколи" (Рис. 1.6), які є модульними.
Підсистема "Транспорти" призначена для забезпечення обміну неструктурованими даними між OpenSCADA та зовнішніми системами, у ролі яких також можуть виступати віддалені станції OpenSCADA. Під неструктурованими даними розуміється потік символів певної довжини. Модульним об'єктом, що міститься у підсистемі "Транспорти", виступає тип транспорту, який і визначає механізм передачі неструктурованих даних. Наприклад, це можуть бути та є:
Підсистема "Транспорти" включає підтримку вхідних та вихідних транспортів. Вхідні транспорти призначено для обслуговування зовнішніх запитів та відправки відповідей. Вихідні транспорти навпаки призначено для надсилання повідомлень та очікування відповідей. Відтак вхідні транспорти містить конфігурацію локальної станції як серверу, а вихідні транспорти містить конфігурацію віддаленого серверу. Така спеціалізація характерна для типового механізму "запит-відповідь", однак наразі вхідні та вихідні транспорти підтримують незалежну передачу та прийом даних. Модулі підсистеми "Транспорти" реалізують підтримку як вхідних, так і вихідних транспортів.
Підсистема "Транспортні протоколи" призначена для структуризації даних, отриманих від підсистеми "Транспорти", є продовженням підсистеми "Транспорты" та здійснює функції перевірки структури та цілісності отриманих даних. Для визначення протоколу разом з яким має працювати транспорт передбачено спеціальне конфігураційне поле. Модульним об'єктом, який міститься у підсистемі "Протоколи", є сам протокол. Наприклад, транспортними протоколами можуть бути та є:
Повну послідовність сеансу вхідного зв'язку для типових протоколів режиму "запит-відповідь" можна записати наступним чином:
Протоколи також підтримуються для вихідних транспортів та беруть на себе функцію спілкування з транспортом та реалізацію особливостей цих протоколів, при підготовці даних до передачі та розборі відповідей. Зовнішній інтерфейс доступу до протоколів, із коду інших модулів та оточення програмування OpenSCADA, реалізується у XML дереві зі власною структурою для кожного протокольного модуля. Такий механізм дозволяє виконувати прозорий доступ до зовнішніх систем, за посередництвом транспортів, просто вказуючи ім'я протоколу за допомогою якого обслуговувати передачу.
Завдяки стандартному доступу (API) до транспортів у OpenSCADA можна легко змінювати спосіб обміну даними не зачіпаючи самих програм, що обмінюються. Наприклад, у випадку локального обміну можна використовувати швидший транспорт на основі UNIX-сокетів або поділюваної пам'яті, а у випадку обміну через інтернет та локальну мережу використовувати TCP або UDP сокети.
SCADA-системи, як клас, передбачають наявність інтерфейсів користувача. У OpenSCADA для надання користувацьких інтерфейсів передбачена підсистема "Користувацькі інтерфейси" під якою розуміється не тільки середовище візуалізації, з яким має працювати кінцевий користувач, але і все, що має стосунок до користувача, наприклад:
Підсистема "Користувацькі інтерфейси" є модульною та її модульним об'єктом виступає власне конкретний інтерфейс користувача. Модульність підсистеми дозволяє створювати різні інтерфейси користувача на різних GUI/TUI бібліотеках та використовувати найбільш оптимальне рішення у конкретно взятому випадку, наприклад, для середовища виконання програмованих логічних контролерів можна використовувати конфігуратори та візуалізатори на основі Web-технологій (WebCfg, WebCfgD, WebVision, WebUser), а у випадку стаціонарних робочих станцій використовувати ті-ж конфігуратори та візуалізатори, але на основі бібліотек на кшталт Qt (QTCfg, Vision).
OpenSCADA є розгалуженою програмою, яка складається з десятка підсистем та може включати багато модулів. Відтак надання всім необмеженого доступу до цих ресурсів є що найменш необережним. Для розмежування доступу, у OpenSCADA передбачено підсистему "Безпека" основними функціями якої є:
OpenSCADA побудовано за модульним принципом, що передбачає наявність багатьох модулів, які треба контролювати та планувати доступність, для чого передбачено підсистему "Планувальник модулів". Всі модулі на цей час надаються до програми за посередництвом поділюваних бібліотек(контейнерів) або вбудовуються прямо у бібліотеку ядра OpenSCADA. Кожний контейнер може містити безліч модулів різного типу згідно до їх логічної зв'язністю.
Підсистема "Планувальник модулів" реалізує контроль за станом контейнерів та дозволяє виконувати "гаряче" додання, видалення та оновлення контейнерів та модулів, що він містить.
Очевидно, що неможливо передбачити всі потрібні функції та функції, що можуть знадобитися у майбутньому, тому у OpenSCADA передбачено підсистему "Спеціальні", яка є модульною та призначена для додання непередбачених функцій шляхом модульного розширення. Наприклад, за допомогою цієї підсистеми можуть бути та реалізовані:
Сучасна SCADA система має містити механізми що надають можливість програмування на користувацькому рівні, тобто — середовище програмування користувача. OpenSCADA містить таке середовище та за його допомогою можна реалізовувати:
Середовище програмування представляє собою комплекс засобів, що організують обчислювальне оточення користувача та до складу якого входять:
Модулі бібліотек функцій надають статичні функції визначеної спрямованості, які розширюють об'єктну модель програми та представляють собою інтерфейс доступу до засобів модуля на рівні користувача. Наприклад, "Середовище Візуалізації та Управління" може надавати функції для видачі різних повідомлень, використовуючи які користувач може реалізовувати інтерактивні алгоритми взаємодії з програмою. Бібліотеки функцій загалом можуть реалізовуватися як набором функцій фіксованого типу — статичні, так і функціями, що допускають вільну модифікацію та доповнення — динамічні.
Бібліотеки функцій вільного типу (динамічні) надають середовище написання користувацьких функцій на одній з мов програмування, наразі це мова подібна до Java, яка реалізується модулем DAQ.JavaLikeCalc. Таким чином можна створювати бібліотеки апаратів технологічних процесів та багато інших, а надалі використовувати їх шляхом зв'язування.
На основі функцій, які надаються об'єктною моделлю, будуються об'єкти обчислювальних контролерів, які здійснюють зв'язування функцій з параметрами програми та механізмом обчислювання. Також пишуться процедури та протоколи збору даних рівня користувача, процедури віджетів "Середовища Візуалізації та Управління" та багато іншого.
SCADA (Supervisory Control And Data Acquisition) загалом мають розподілену архітектуру на кшталт зображеної на рисунку 2. Елементи SCADA систем, у сенсі програмного забезпечення, виконують наступні функції:
Сервер збору: представляє собою задачу або групу задач, що займаються збором даних з джерел даних, або ж самі виступають у ролі джерела даних. До задач серверу входить:
Сервер архівування-історії: представляє собою задачу або групу задач, що займаються архівуванням даних або веденням їх історії. До задач серверу входить:
Сервер протоколювання: представляє собою задачу або групу задач, що займаються архівуванням повідомлень або веденням їх історії. До задач серверу входить:
Сервер сигналізації: представляє собою задачу або групу задач, які виконують функції серверу протоколювання стосовно вузької категорії повідомлень сигналізації.
Робоче місце оператору: представляє собою GUI(Grafical User Interface) додаток, що постійно функціонує та виконаний у одномоніторному, багато-моніторному або панельному режимі та що виконує функції:
Робоче місце інженеру: представляє собою GUI додаток, що використовується для конфігурації SCADA систем. До задач додатку входить:
Робоче місце керівника: представляє собою GUI додаток, як правило виконаний у одномоніторному режимі, що виконує функції:
Робоче місце технологу: суцільно включає у себе функції робочого місця оператору плюс моделі технологічних процесів (без безпосереднього зв'язку з технологічним процесом).
Робоче місце технологу-програміста: суцільно включає у себе функції робочого місця технолога плюс інструментарій для створення моделей технологічних процесів.
У простішому випадку OpenSCADA можна сконфігурувати у серверному режимі (рис. 3.1) для збору та архівування даних. Така конфігурація дозволяє виконувати наступні функції:
Для підвищення надійності та продуктивності OpenSСADA допускає множинне резервування (рис. 3.2), при якому джерела даних (контролери) та архіви-історія одного екземпляру відбиваються у іншому. При використанні подібної конфігурації можливий розподіл навантаження опитування/обчислювання по різними станціями. Така конфігурація дозволяє виконувати функції:
Окремим випадком дубльованого підключення є дублювання у межах одного серверу (рис. 3.3), тобто запуск декількох станцій на одній машині з перехрещенням параметрів. Метою такої конфігурації є підвищення надійності та відмовостійкості конфігурації, шляхом резервування ПЗ.
Для візуалізації даних, які містяться на сервері, гарним рішенням є використання користувацького WEB-інтерфейсу (рис. 3.4). Це рішення дозволяє використовувати стандартний WEB-браузер у клієнта та відповідно є найгнучкішим, оскільки не прив'язано до однієї платформи, тобто є багатоплатформним. Однак це рішення має суттєві недоліки – це невисока продуктивність та надійність. У зв'язку з цим рекомендується використовувати цей метод для візуалізації некритичних даних або даних, що мають резервний високонадійний спосіб візуалізації. Наприклад, гарним рішенням буде використання цього методу у керівництва промислових установок, де завжди існує операторська з надійним способом візуалізації. Така конфігурація дозволяє виконувати наступні функції:
Для візуалізації критичних даних, а також у випадку якщо потрібна висока якість та продуктивність, можна використовувати візуалізацію на основі OpenSCADA, яку сконфігуровано з GUI модулем (рис. 3.5). Така конфігурація дозволяє виконувати натупні функції:
Повнофункційна клієнт-серверна конфігурація на одній машині (рис. 3.6) може використовуватися для підвищення надійності конфігурації в цілому шляхом запуску клієнта та сервера у різних процесах. Така конфігурація дозволяє без наслідків для серверу зупиняти клієнт та виконувати з ним різні профілактичні роботи. Рекомендується для використання на станціях оператору шляхом встановлення двох машин, що поєднують у собі станції оператору та резервований сервер. Така конфігурація дозволяє виконувати наступні функції:
Змішане підключення поєднує функції серверу та клієнту (рис. 3.7). Може використовуватися для тестових, демонстраційних функцій, а також для надання моделей та тренажерів технологічних процесів як єдине ціле. У цьому режимі можуть виконуватися наступні функції:
Така конфігурація є одним з варіантів стійкого-надійного підключення (рис. 3.8). Стійкість досягається шляхом розподілу функцій за:
Сервер опитування конфігурується на основі OpenSCADA та представляє собою задачу або групу задач, що займаються збором даних — опитування контролеру або групи контролерів одного типа. Отримані значення доступні центральному серверу через будь який транспорт підтримка якого додається шляхом підключення відповідного модуля транспорту. Для зниження частоти опитування та величини мережевого трафіку, сервер опитування може бути обладнано невеликим архівом значень. Конфігурація сервера опитування зберігається у одній з доступних БД.
Центральний сервер архівування та обслуговування клієнтських запитів виконує функцію централізованого збору та обробки параметрів серверів опитування та їх значень. Доступ до серверів опитування виконується за посередництвом одного з доступних у OpenSCADA транспортів+протоколів (на прикладі це Sockets). Для надання єдиного інтерфейсу доступу до параметрів та контролерів використовується модуль DAQGate, який відбиває дані серверів опитування на структуру локальних параметрів збору даних.
Для виконання внутрішніх обчислень та додаткового аналізу параметрів використовуються об'єкти обчислювальних контролерів.
Для різнобічного та глибокого архівування використовуються різні модулі архівів-історії.
Для доступу клієнтів до серверу використовуються доступні у OpenSCADA мережеві транспорти, на прикладі — Sockets; та транспортні протоколи, на прикладі — протокол OpenSCADA "SelfSystem".
Конфігурація центрального серверу зберігається в одній з доступних БД (на прикладі це мережева СУБД MySQL).
Для надання користувацького WEB-інтерфейсу використовується модуль WebCfgD за посередництвом транспортного протоколу "HTTP".
Різні клієнти, у їх числі АРМ та WEB-клієнти, виконуються на окремих машинах у потрібній кількості. АРМ реалізується на основі OpenSCADA. До його функції входить опитування значень параметрів з центрального сервера та їх візуалізація на GUI інтерфейсі(ах). Для отримання параметрів збору даних у АРМ також використовується модуль відображення віддалених параметрів DAQGate. Для надання доступу до архівів-історії може використовуватися модуль архіву мережевого типу. Конфігурація АРМ може зберігатися у одній з доступних БД (у прикладі це мережева СУБД MySQL, яка розташована на машині центрального сервера архівування).
Як можна бачити у розділі вище, OpenSCADA надає можливість конфігурації для виконання у різних ролях. Підтримка цієї можливості забезпечується різними механізмами конфігурації та зберігання конфігураційних даних. Цей розділ містить опис цих механізмів, прикликаний дати уявлення про гнучкість та розмаїття, дозволивши тим самим використовувати OpenSCADA на 100%.
In describing the configuration mechanisms and methods of its storage in this section it will be focused the description of program-wide mechanisms. Features of the configuration of modules of subsystems of OpenSCADA are provided in their own module's documentation.
In OpenSCADA it is used the formalized approach to describing the configuration interfaces based on XML. In fact, features of the component's configuration are provided by the component itself, thereby running through the whole program, as the nervous system of the organism. In terms of OpenSCADA it is called the interface of control of OpenSCADA (Control interface). On the basis of the control interface the graphical interfaces of the user configuration are generated by means of modules of OpenSCADA. This approach has the following important advantages:
In OpenSCADA the three configuration modules on the different basis of visualization are provided. Let's observe them and their configuration options:
Configuration values, changed in the configurators, as well as most of the data are stored in databases (DB). Given the modularity of subsystems "DB", there can be different database. Moreover, there is the possibility of storing different OpenSCADA parts in different databases of the same type and in the database of different types as well.
In addition to the database configuration information may be contained in the OpenSCADA configuration file, and passed through the command line parameter's when you call OpenSCADA. Saving the configuration in the configuration file is carried out on an equal footing with the database. Standard name of the OpenSCADA configuration file is /etc/oscada.xml. The format of the configuration file and command line parameters we'll examine in the separate section.
Some node's configuration changing will set the modification flag for the node, and also will set active for buttons "Load from DB", for loading the first configuration, and "Save to DB" for the changes saving. The modification flag also rise to parrent node, which allow for restore-save from root node, but real into operations with DB will participate only modified nodes.
A node removing causes to removing it from storage-DB and modification mechanism do not work for this operation.
Many of the settings and configuration objects OpenSCADA, which are executed or are already enabled, are not applied immediately, as for changes, because the configuration is read/apply usually only when turn on or start. Therefore to apply the changes, in such cases, it is enough to enable/disable enabled object or to restart the running — start/stop. Presently many configurations, which its are not provided applying for now, just are not allowed for editing.
Further examining of the OpenSCADA configuration will be based on the interface of the configurator UI.QTCfg, but the principles of work will be fully consistent with the rest of the configurators owing to the generality in the control interface of OpenSCADA.
We will start examining with the configuration of program parameters of OpenSCADA, which is located in the six tabs at the root page of the station:
To modify the fields of this page it may be required the super user's rights. Get these rights you can by means of including your user into the superuser's group "root", or by entering the station from the superuser "root".
We must mention another one important point: the fields of the identifiers of all OpenSCADA objects are unacceptable for direct editing, because they are keys for storage of objects' data in the database. However, to change the object's identifier you can by the command of cutting and the further pasting of the object (Cut-> Paste) in the configurator.
The service task of the redundancy mechanism is always running and executed at intervals which are prescribed in the appropriate configuration field. The real work on implementing the redundancy is carried out in the presence of at least one redundant station in the list of stations, and implies:
There is recommended the redundancy configure in way for DBs of the redundant stations save equal and that will allow you to copy its painlessly to each the station and then to backup only one the DBs set. And the configurations specified to the different stations will save into the configuration file and you can simply configure and change the needed station by the proper configuration file select.
The redundancy configuration start from the redundant stations appending to list of OpenSCADA stations in tab "Subsystem" of the subsystem "Transports" (Fig.4.3b). And to add here needs not only the redundant stations to the current one but the same current one with its external IP, that is some loop. Further this configurations will have been stored into the generic DB of the redundant station, and from this time the DBs will be used for that all redundant station creation. Then there is important to make on that stage all needed changes into the generic DB and about this project in general!
Next for the concrete station, with copy of the generic DB, we configure its specific parameters into the tab "Redundancy" of the main page (Fig.4c), which will be stored into the configuration file.
After that all next configurations of redundancy perform into the tab "Redundancy" of proper subsystem, "Data acquisition" (Fig.4.5b) or "Archives" (Fig.4.6b). If you will set the parameter "Local primary commands transfer" (Fig.4c) then the configurations, like to any other generic configurations, can be performed at any one from the stations and all the performed changes will be transferred to all other ones, sure if its are available.
For OpenSCADA different working specific debug you may be necessary to enable addition-debugging messages generation, which you can set by select minimal messages level, into tab "Station", to "Debug (0)". As a result of this will emerge tab "Debug" (fig.4e) where available the objects counters for control to leaks, and also the table with incoming debug messages' categories list. Into the table you can select only needed debug messages sources and omit to overload the archiving messages subsystem and overall the system performance decrease. You can also select higher categories, up to root system category, that will disable detailed selection and enable all messages generation by the level or by overall system. For the debug messages observing you need to go subsystem "Archives" (fig. 4.6c), and for this provided button "See to messages". Selected debug mode and debug categories list can be standard stored to configuration file and on next boot the debug mode will be activated, this important primarily for the objects counters.
While examining the configuration pages of modular subsystems there will be described the general for all modules properties. However, it should be noted that each module can provide both: the additional tabs, and separate fields for the configuration of their own functioning for the pages, objects of which are inherited by modules. Information on the features and additions of the modules can be found in separate documentation for each of them.
The subsystem is the modular one and contains a hierarchy of objects shown in Figure 1.4. To configure the subsystem the root page of the subsystem "DB" containing the tab "Modules". Tab "Modules" (Fig. 4.1a) contains the list of modules in subsystem "DB", available at the station.
To modify the page's fields of this subsystem it may be required the super user's rights or the inclusion of your user to the "DB" group.
Each module of the "DB" subsystem provides the configuration page with the following tabs: "DB" and "Module". "DB" tab (Fig. 4.1b) contains the list of databases registered in the module and the flag of the sign of full deleting of the database when making the delete command. In the context menu of the databases' list the user is provided with an opportunity to add, delete and move to the desired database. The "Module" tab contains information about the module of the "DB" subsystem (Fig.4.1c):
Each database contains its own configuration page with the tabs "Data base", "Tables" and "SQL", in case SQL-requests support. Besides the basic operations you can copy the contents of the DB by means of the standard function for the copying the objects in the configurator. The copying operation the DB contents involves the copying of the original database to the destination database, and the contents of the destination database is not cleared before the copy operation. Copying the contents of database is made only when the both databases are enabled, otherwise it will run a simple copy of the object of the database.
Tab "Data base" (Fig.4.1d) contains the main configuration options of the DB as follows:
Tab "Tables" (Fig.4.1e) contains the list of the opened pages. In normal mode of the program operation this tab is empty, because after the completion of working with tables the program closes them. The presence of opened tables tells that the program is now working with tables or tables are opened by the user to examine their contents. In the context menu of list of opened tables you can open the table for study (the command "Add"), close the opened page (the command "Delete") and proceed to examination of the contents of the table.
Tab "SQL" (Fig.4.1f) allow only for data bases which support SQL-requests, and contains field to request enter, button to request send and table to result. To control the request transaction context provided by separate configuration field.
Page of the examination of the contents of the table contains only one tab, "Table". Tab "Table" (Figure 4.1g) contains the field of the name of the table and the table with the contents. Table of contents provides the following functions:
The subsystem is not modular one. To configure the subsystem the root page of the subsystem "Security" is provided, which contains the tab "Users and Groups". Tab "Users and Groups" (Figure 4.2a) contains the list of users and users' groups. Users in the group "Security" and with the rights of the privileged user can add, delete the user or group of users. All other users can go to the page the user or the users' group.
To configure the user it is provided the page containing only the tab "User" (Fig.4.2b). Tab contains the configuration data of the user's profile, which can be changed by the user itself, the user of the "Security" group or the privileged user:
To configure the user's group it is provided the page containing only the tab "Group" (Fig.4.2c). Tab contains the configuration data of the group's profile, which can be changed only by the privileged use:
Підсистема є модульною та містить ієрархію об'єктів, зображену на рисунку 1.6. Для конфігурації підсистеми передбачено кореневу сторінку підсистеми "Транспорти", яка містить вкладки "Підсистема" та "Модулі".
Вкладка "Підсистема" (рис.4.3a) містить таблицю конфігурації зовнішніх, для цієї, OpenSCADA станцій. Зовнішні станції можуть бути системними, користувацькими або одночасно, що обирається у відповідному стовпчику. Системні зовнішні станції доступні тільки привілейованому користувачу та використовуються компонентами системного призначення, наприклад, механізмом горизонтального резервування та модулем DAQ.DAQGate. Користувацькі зовнішні станції прив'язано до користувача, який їх створював, тобто перелік користувацьких зовнішніх станцій індивідуальний для кожного користувача. Користувацькі зовнішні станції використовуються компонентами графічного інтерфейсу, наприклад: UI.QTCfg, UI.WebCfgD та UI.Vision. У таблиці зовнішніх станцій можливе додання та видалення записів про станцію, а також їх модифікація. Кожний запис містить поля:
Вкладка "Модулі" (рис.4.1b) містить перелік модулів підсистеми "Транспорти" та ідентична до всіх модульних підсистем.
Each module of the subsystem "Transports" provides the configuration page with the tabs "Transports" and "Module". The tab "Transports" (Fig.4.3b) contains the list of incoming and outgoing transports registered in the module. The context menu of lists of transports provides the user with the possibility to add, delete and move to the desired transport. On the "Module" tab it is provided the information about the module of subsystem "Transports" (Fig. 4.1d), whose structure is identical for all modules.
Incoming transport (fig.4.3c) includes:
Outgoing transport (Fig. 4.3d) contains:
Outgoing transport, in addition, provides the tab for forming the user request via this transport (Fig.4.3e). The tab is provided for setting communication, as well as for debugging the protocols and includes:
Both incoming and outgoing transports also contain tab "IO log" (Fig.4.3f). The tab is provided for generic control, observing and learning the traffic through the transports and includes the log length field and the same text area of the log. For the log disable you can the log length field set to zero.
The subsystem is modular. To configure the subsystem the root page of the subsystem "Transport Protocols" is provided, it contains tab "Modules". The tab "Modules" (Fig. 4.1b) contains the list of modules in subsystem "Transport Protocols" and is identical for all modular subsystems.
Each module of subsystem "Transport Protocols" provides configuration page with the only one tab — "Module". On the tab "Module" there is the information on the module of subsystem "Transport Protocols" (Fig. 4.1d), which structure is identical for all modules.
The subsystem is modular one and contains the hierarchy of objects shown in Fig.1.3. To configure the subsystem the root page of subsystem "Data acquisition" is provided, which contains the tabs "Redundancy", "Template libraries" and "Modules".
To obtain access to modify the objects of this subsystem the user of the group "DAQ" or the rights of the privileged user are required.
As a redundancy object of the subsystem "Data Acquisition" there used the object of controller for which the redundancy process performs that functions:
Tab "Redundancy" (Fig. 4.5a) presented only if at last one station pointed into the redundancy and contains the configuration of redundancy of data sources of subsystem "Data acquisition" with the following settings:
The tab "Template libraries" (Fig.4.5b) contains the list of libraries of templates for the parameters of this subsystem. In the context menu of the list of template libraries the user can add, delete and move to the desired library. The tab "Modules" (Fig. 4.1b) contains the list of modules in the subsystem "Transports" and is identical for all modular subsystems.
Each template library of subsystem "Data acquisition" provides the configuration page with the tabs "Library" and "Parameter templates". Tab "Library" (fig. 4.5d) contains the basic settings of the library:
Tab "Parameter templates" (Fig.4.5d) contains the list of templates in the library. In the context menu of the list the user can add, delete and move to the desired template.
Each template of the template library provides the configuration page with the tabs "Template" and "IO". The tab "Template" (Figure 4.5e) contains the basic settings of the template:
The tab "IO" (Fig.4.5f) contains the configuration of attributes (IO) of templates and the program of template on the one of languages of the user programming of OpenSCADA, for example, DAQ.JavaLikeCalc.JavaScript. To the table of attributes of template user can, through the context menu, add, insert, delete, move up or down the record of attribute, as well as edit the attribute's fields:
The syntax of the language of the template's program you can see in the documentation of the module, providing an interpreter of the chosen language. For example, a typical user programming language of OpenSCADA — DAQ.JavaLikeCalc.JavaScript.
Each module of the subsystem "Data acquisition" provides the configuration page with the tabs "Controllers" and "Module". The tab "Controllers" (Fig.4.5g) contains the list of controllers, registered in the module. In the context menu user can add, delete and move to the desired controller. The tab "Module" provides information about the module of the subsystem "Data acquisition" (Fig. 4.1d), which structure is identical for all modules.
Each controller contains its own configuration page with the tabs "Controller" and "Parameters".
The tab "Controller" (Fig.4.5h) contains the basic settings. The structure of these settings may differ slightly from one module of this subsystem to another, as you can find in the own documentation of modules. As an example, let's examine the settings of the controller in the module of the controller of logic DAQ.LogicLev:
"Parameters" tab (Fig.4.5i) contains a list of parameters in the controller, select the type of parameters that are created by default, as well as information on the total number and the number of enabled parameters. In the context menu user can add, delete and move to the desired parameter.
"Diagnostic" tab (Fig.4.5j) contains diagnostic messages form by the data source. More data sources is external devices with accessing to the data by a network connection or a system bus then there possible different emergency situation on access to the data. Print all its to field "State" of controller object impossible due it display only current access data state. Due the diagnostic you can trace all emergency situation at messages view, which forming by the controller object for specified period of time and by selected messages level. Besides to certain diagnostic information some modules of data sources can provide here debug exchange dumps, on messages level "Debug (0)".
Parameters of the controllers of subsystem "Data acquisition" provides the configuration page with the tabs "Parameters", "Attributes", "Archiving" and "Template config". The tab "Template config" is not standard, but it is present only in the parameters of modules of subsystem "Data acquisition", which implement the mechanisms of working under the template in the context of the data source, which they are served, for logical type. In this review this tab is included for logical completeness of the review of the configuration of templates of parameters of subsystem "Data acquisition" and as the final stage — using.
The tab "Parameter" (Fig.4.5k) contains the main settings:
The tab "Attributes" (Fig.4.5l) contains the parametr's attributes and their values in accordance with the configuration of the used template and calculation of its program.
The "Archiving" tab (Fig.4.5m) contains the table with the attributes of a parameter in the columns and the archivers in rows. The user can set the archiving for the desired attribute with the required archiver simply by changing the cell at the intersection.
The "Template config" tab (Figure 4.5n) contains the configuration fields in accordance with the template. In this example it is the group link on the external parameter. This link can be set simply by pointing the way to the parameter if the flag "Only attributes are to be shown" is not set, or to set the addresses of the attributes separately in the case if the flag is set. Sign "(+)", at the end of the address signals about successful linking and presence of the target.
The subsystem is modular and contains the hierarchy of objects shown in Fig.1.5. To configure the subsystem the root page of the subsystem "Archives" is provided, it contains tabs: "Redundancy", "Messages archive", "Value archives" and "Modules".
To gain the access to modify the objects of this subsystem the user of the group "Archive" or the privileged user rights are required.
As a redundancy object of the subsystem "Archives" there used the object of messages archivator for which the redundancy process performs that functions:
Redundancy of the value archivators doesn't provided directly but that process does through data sources and the subsystem of "Data acquisition".
Tab "Redundancy" (Fig. 4.6a) presented only if at last one station pointed into the redundancy and contains the configuration of redundancy of messages archvators with the following settings:
The "Messages" tab (Fig.4.6b) contains the configuration of messages archive and the request form of messages from the archive.
Configuration of the messages archive is represented by the fields:
The messages request form contains the configuration fields of the request and the table of results. Configuration fields of the request are:
The result table contains rows of messages with the following columns:
Tab "Value" (Fig.4.6c) contains the general configuration of value's archiving and the list of archives of values. In the context menu of the list of values the user has the opportunity to add, delete and move to the desired archive. The general configuration of archiving is represented by the fields:
The "Modules" tab (Fig. 4.1b) contains a list of modules in subsystem "Archives" and it is identical for all modular subsystems.
Archive of values of subsystem "Archives" provides the configuration page with the tabs "Archive", "Archivators" and "Values".
Tab "Archive" (Fig.4.6d) contains the basic settings of the archive:
Tab Archivators' (Fig.4.6e) contains the table with the configuration of the processing of the archive by the available archivers. Lines are available archivers, and the columns are the following parameters:
Tab "Values" (Fig.4.6f) contains the values request in the archive and the result as a table of values or image of the trend. Values request contains the fields:
Each module of the "Archives" subsystem provides configuration page with the tabs "Archivators" and "Module". The "Archivators" tab (Fig.4.6g) contains a list of messages and values archivers registered in the module. The context menu of the list provides user with possibility to add, delete and move to the desired controller. The "Module" tab contains information about the module of subsystem "Archives" (Fig. 4.1d), whose structure is identical for all modules.
Messages archivators contains their own configuration page with tabs "Archivator" and "Messages".
The "Archivator" tab (Fig.4.6h) contains the basic settings. The structure of these settings may differ slightly from one module of this subsystem to another as you can find in the own documentation of modules. As an example we shall examine the settings of the messages archiver from the module of the archive on the file system Arch.FSArch Settings:
The "Messages" tab (Fig.4.6i) contains the form of the messages request from the archive of the archiver:
The result table contains messages rows with the following columns:
Values archivers contains their own configuration page with tabs "Archivator" and "Archives".
The "Archivator" tab (Fig.4.6j) contains the basic settings. The structure of these settings may differ slightly from one module of this subsystem to another as you can find in the own documentation of modules. As an example we shall examine the settings of the messages archiver from the module of the archive on the file system Arch.FSArch Settings:
The "Archives" tab (Fig.4.6k) contains a table with information about the archives being processed by the archiver. In the rows the table contains archives, and in the columns — the following information:
In the case of the module Arch.FSArch in this tab you can find the form of export the archiver's data.
The subsystem is modular. To configure the subsystem the root page of the subsystem "User Interfaces" is provided, it contains the tab "Modules". The "Modules" tab (Fig. 4.1b) contains a list of modules of subsystem and it is identical for all modular subsystems.
Each module of the subsystem "User Interfaces" provides configuration page with the tabs "User Interface" and "Module". The "User Interface" tab (Fig.4.7a) provides the parameter for monitoring the "Running" status of the module, as well as the configuration sections specialized for the modules of this subsystem. On the "Module" tab there is an information about the module of the subsystem "User Interfaces" (Fig. 4.1d), which structure is identical for all modules.
The subsystem is modular. To configure the subsystem the root page of the subsystem "User Interfaces" is provided, it contains the tab "Modules". The "Modules" tab (Fig. 4.1b) contains a list of modules of subsystem and it is identical for all modular subsystems.
Each module of the subsystem "Specials" provides configuration page with the tabs "Special" and "Module". The "Special" tab (Fig.4.8a) provides the parameter for monitoring the "Running" status of the module, as well as the configuration sections specialized for the modules of this subsystem. On the "Module" tab there is an information about the module of the subsystem "Specials" (Fig. 4.1d), which structure is identical for all modules.
The subsystem is not modular. To configure the subsystem the subsystem's page "Modules scheduler" is provided, it contains tab "Subsystem". The "Subsystem" tab (Fig.4.9a) contains the basic settings of the subsystem. The structure of the tab "Subsystem":
Configuration file of OpenSCADA is provided to store the program and general configuration of OpenSCADA-station. Only in the configuration file and through the command-line options you can specify the part of the key system parameters of the station, so familiarity with the structure of the configuration file is necessary for professionals who make solutions based on OpenSCADA.
The configuration file of OpenSCADA can be called somehow, but the oscada.xml name and derived from it are accepted. The configuration file is usually indicated when you start the station by the command-line option "--config=/home/roman/roman/work/OScadaD/etc/oscada_demo.xml". For the convenience of the calling the startup scripts of the station are created with the correct configuration file or used the project manager at start script openscada_start. For example script (openscada_demo) uses for the demo station execution:
#!/bin/sh openscada --config=/etc/oscada_demo.xml $@
If the configuration file is not specified then the standard configuration file /etc/oscada.xml is used.
Structure of the configuration file based on the extensible markup language XML. Therefore the strict adherence to the rules of XML syntax is required. An example of the configuration file of OpenSCADA, with configuration nodes of most of the OpenASCADA components, is given below:
<?xml version="1.0" encoding="UTF-8" ?>
<OpenSCADA>
<!--
This is the OpenSCADA configuration file.
-->
<station id="AGLKS">
<!--
Describe internal parameters for station.
The station is OpenSCADA program.
-->
<prm id="StName">AGLKS</prm>
<prm id="StName_ru">АГЛКС</prm>
<prm id="StName_uk">АГЛКС</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_ru="Основная БД" NAME_uk="Основна БД" ADDR="St.db" CODEPAGE="UTF-8"/>
</tbl>
</node>
<node id="sub_Security">
<!--
<tbl id="Security_user">
<fld
NAME="root"
DESCR="Super user"
DESCR_ru="Супер пользователь"
DESCR_uk="Супер користувач"
PASS="openscada"/>
<fld
NAME="user"
DESCR="System user"
DESCR_ru="Системный пользователь"
DESCR_uk="Системний користувач"
PASS=""/>
</tbl>
<tbl id="Security_grp">
<fld
NAME="root"
DESCR="Super users groups"
DESCR_ru="Группа суперпользователей"
DESCR_uk="Група суперкористувачів"
USERS="root;user"/>
</tbl>-->
</node>
<node id="sub_ModSched">
<prm id="ModAllow">*</prm>
<prm id="ModDeny"></prm>
<prm id="ChkPer">0</prm>
</node>
<node id="sub_Transport">
<!--
<tbl id="Transport_in">
<fld
ID="WEB_1"
MODULE="Sockets"
NAME="Generic WEB interface"
NAME_ru="Основной WEB интерфейс"
NAME_uk="Основний WEB інтерфейс"
DESCRIPT="Generic transport for WEB interface."
DESCRIPT_ru="Основной транспорт для WEB интерфейса."
DESCRIPT_uk="Основний транспорт для WEB інтерфейсу."
ADDR="TCP::10002:0"
PROT="HTTP"
START="1"/>
<fld
ID="WEB_2"
MODULE="Sockets"
NAME="Reserve WEB interface"
NAME_ru="Резервный WEB интерфейс"
NAME_uk="Резервний WEB інтерфейс"
DESCRIPT="Reserve transport for WEB interface."
DESCRIPT_ru="Резервный транспорт для WEB интерфейса."
DESCRIPT_uk="Резервний транспорт для WEB інтерфейсу."
ADDR="TCP::10004:0"
PROT="HTTP"
START="1"/>
</tbl>
<tbl id="Transport_out">
<fld
ID="testModBus"
MODULE="Sockets"
NAME="Test ModBus"
NAME_ru="Тест ModBus"
NAME_uk="Тест ModBus"
DESCRIPT="Data exchange by protocol ModBus test."
DESCRIPT_ru="Тест обмена по протоколу ModBus."
DESCRIPT_uk="Тест обміну за протоколом ModBus."
ADDR="TCP:localhost:10502"
START="1"/>
</tbl>-->
</node>
<node id="sub_DAQ">
<!--
<tbl id="tmplib">
<fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" DB="tmplib_test2"/>
</tbl>
<tbl id="tmplib_test2">
<fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk=""
PROGRAM="JavaLikeCalc.JavaScript
cnt=5*i;"/>
</tbl>
<tbl id="tmplib_test2_io">
<fld TMPL_ID="test2" ID="i" NAME="I" NAME_ru="I" NAME_uk="I" TYPE="4" FLAGS="160" VALUE="" POS="0"/>
<fld TMPL_ID="test2" ID="cnt" NAME="Cnt" NAME_ru="Cnt" NAME_uk="Cnt" TYPE="4" FLAGS="32" VALUE="" POS="0"/>
</tbl>-->
<node id="mod_LogicLev">
<!--
<tbl id="DAQ">
<fld
ID="test2"
NAME="Test 2"
NAME_ru="Тест 2"
NAME_uk="Тест 2"
DESCR=""
DESCR_ru=""
DESCR_uk=""
ENABLE="1"
START="1"
PRM_BD="test2prm"
PERIOD="1000"
PRIOR="0"/>
</tbl>
<tbl id="test2prm">
<fld SHIFR="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk=""
EN="1" MODE="2" PRM="test2.test2"/>
</tbl>-->
</node>
<node id="mod_System">
<!--
<tbl id="DAQ">
<fld
ID="DataOS"
NAME="Data OS"
NAME_ru="Даные ОС"
NAME_uk="Дані ОС"
DESCR="Data of services and subsystems OS."
DESCR_ru="Данные сервисов и подсистем ОС."
DESCR_uk="Дані сервісів та підсистем ОС."
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_ru="Нагрузка CPU" NAME_uk="Навантаження CPU" DESCR="" DESCR_ru="" DESCR_uk=""
EN="1" TYPE="CPU" SUBT="gen"/>
<fld SHIFR="MEM" NAME="Memory" NAME_ru="Память" NAME_uk="Пам'ять" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" TYPE="MEM"/>
</tbl>
-->
</node>
<node id="mod_DiamondBoards">
<!--
<tbl id="DAQ">
<fld ID="Athena" NAME="Athena board" NAME_ru="Плата Athena" NAME_uk="Плата Athena" DESCR="" DESCR_ru="" DESCR_uk=""
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_ru="AI 0" NAME_uk="AI 0" DESCR="" DESCR_ru="" DESCR_uk="" EN="0" TYPE="0" CNL="0" GAIN="0"/>
</tbl>
<tbl id="AthenaDigPrm">
<fld SHIFR="di0" NAME="DI 0" NAME_ru="DI 0" NAME_uk="DI 0" DESCR="" DESCR_ru="" DESCR_uk="" EN="0" TYPE="0" PORT="0" CNL="0"/>
</tbl>
-->
</node>
<node id="mod_BlockCalc">
<!--
<tbl id="DAQ">
<fld ID="Model" NAME="Model" NAME_ru="Модель" NAME_uk="Модель" DESCR="" DESCR_ru="" DESCR_uk=""
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_ru="Клапан" NAME_uk="Клапан" DESCR="" DESCR_ru="" DESCR_uk=""
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 lev" NAME_ru="Полож. клапана" NAME_uk="Полож. клапана" DESCR="" DESCR_ru="" DESCR_uk=""
EN="1" IO="Klap.l_kl1"/>
</tbl>
-->
</node>
<node id="mod_JavaLikeCalc">
<!--
<tbl id="DAQ">
<fld ID="CalcTest" NAME="Calc Test" NAME_ru="Тест вычисл." NAME_uk="Тест обчисл." DESCR="" DESCR_ru="" DESCR_uk=""
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_ru="Авария" NAME_uk="Аварія" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" FLD="alrm"/>
</tbl>
<tbl id="lib">
<fld ID="TemplFunc" NAME="" NAME_ru="" NAME_uk="" DESCR="" ESCR_ru="" DESCR_uk="" DB="lib_TemplFunc"/>
</tbl>
<tbl id="lib_TemplFunc">
<fld ID="d_alarm" NAME="Digit alarm" NAME_ru="Авария по дискр." NAME_uk="Аварія за дискр" DESCR=""
FORMULA="alrm=(in==alrm_md)?"1:"+alrm_mess:"0";"/>
</tbl>
<tbl id="lib_TemplFunc_io">
<fld F_ID="d_alarm" ID="in" NAME="Input" NAME_ru="Вход" NAME_uk="Вхід" TYPE="3" MODE="0" DEF="" HIDE="0" POS="0"/>
<fld F_ID="d_alarm" ID="alrm" NAME="Alarm" NAME_ru="Авария" NAME_uk="Аварія" TYPE="0" MODE="1" DEF="" HIDE="0" POS="1"/>
<fld F_ID="d_alarm" ID="alrm_md" NAME="Alarm mode" NAME_ru="Режим аварии" NAME_uk="Режим аварії"
TYPE="3" MODE="0" DEF="" HIDE="0" POS="2"/>
<fld F_ID="d_alarm" ID="alrm_mess" NAME="Alarm message" NAME_ru="Сообщ. аварии" NAME_uk="Повід. аварії"
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_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" 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_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" TMPL="S7.ai_man"/>
</tbl>-->
</node>
<node id="mod_SNMP">
<!--
<tbl id="DAQ">
<fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk=""
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_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" OID_LS="system"/>
</tbl>-->
</node>
<node id="mod_ModBus">
<!--
<tbl id="DAQ">
<fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" 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_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1"
ATTR_LS="321:0:tst:Test"/>
</tbl>-->
</node>
<node id="mod_DAQGate">
<!--
<tbl id="DAQ">
<fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" 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_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" 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_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" 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_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" 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_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" 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_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" 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_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" ND_LS=""/>
</tbl>-->
</node>
<node id="mod_SoundCard">
<!--<tbl id="DAQ">
<fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" 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_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" 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_ru="Ошибки"
NAME_uk="Помилки"
DESCR="Local errors' archive"
DESCR_ru="Архив локальных ощибок"
DESCR_uk="Архів локальних помилок"
START="1"
CATEG="/DemoStation*"
LEVEL="4"
ADDR="ARCHIVES/MESS/stError/"/>
<fld
ID="NetRequsts"
MODUL="FSArch"
NAME="Net requests"
NAME_ru="Сетевые запросы"
NAME_uk="Мережеві запити"
DESCR="Requests to server through transport Sockets."
DESCR_ru="Запросы к серверу через транспорт Sockets."
DESCR_uk="Запити до сервера через транспорт 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_ru="1час"
NAME_uk="1год"
DESCR="Averaging for hour"
DESCR_ru="Усреднение за час"
DESCR_uk="Усереднення за годину"
START="1"
ADDR="ARCHIVES/VAL/1h/"
V_PER="360"
A_PER="60"/>
</tbl>
<tbl id="Archive_val">
<fld
ID="test1"
NAME="Test 1"
NAME_ru="Тест 1"
NAME_uk="Тест 1"
DESCR="Test 1"
DESCR_ru="Тест 1"
DESCR_uk="Тест 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>
</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_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk=""
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_ru="" PROC_uk="" 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_ru="Тест 2" IO_VAL_uk="Тест 2" SELF_FLG=""
CFG_TMPL="" CFG_TMPL_ru="" CFG_TMPL_uk="" CFG_VAL=""/>
<fld IDW="test2" ID="dscr" IO_VAL="Test module 2" IO_VAL_ru="Тест модуля 2" IO_VAL_uk="Тест модуля 2" SELF_FLG=""
CFG_TMPL="" CFG_TMPL_ru="" CFG_TMPL_uk="" CFG_VAL=""/>
</tbl>
<tbl id="PRJ">
<fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" 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_ru="" PROC_uk="" 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_ru="" PROC_uk="" 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" categ="" 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>
Let's examine in details the structure of the configuration file. A configuration file can contain a configuration of several stations in the sections <station id="AGLKS"/>. To attribute set the identifier of the station. Using one or another section of the station at startup is specified by the command-line option --station=AGLKS. Section of the station directly contains parameters of the station and subsystems' sections. Configuration options of the section are written in the form <prm id="StName">AGLKS</prm>. Where in the attribute <id> the ID of the attribute is specified, and in the tag's body the value of parameter "AGLKS" is specified. The list of available options and their description for the station and all other sections can be obtained from the console by calling OpenSCADA with parameter --help.
Sections of subsystem (<node id="sub_DAQ" />) contains parameters of subsystem, sections of modules and sections of tables of reflections of the data of databases in the configuration file. Sections of modules (<node id="mod_DiamondBoards" />) contain the individual parameters of modules and sections of tables of reflection of the data of databases in the configuration file.
Sections of the tables of reflection of the data of databases are provided for placement in the configuration file records of DB tables for the OpenSCADA components. Let's examine the table of incoming transports "Transport_in" of subsystem transports (<node id="sub_Transport">) from the example of configuration file above. The table contains two records with fields: ID, MODULE, NAME, DESCRIPT, ADDR, PROT, START. After booting with this section and in general without the DB in the subsystem "Transports" of the "Sockets" module you'll see two input transports. Formats of the table's structures of the main components are included in the demo configuration files. For the details of the database's structure you should read the relevant documentation of modules or simple save the object into the configuration file.
The result of the command: # ./openscada_AGLKS --help
***************************************************************************
********** OpenSCADA v0.9 (Linux-3.2.0-4-amd64). *********
***************************************************************************
===========================================================================
==================== Generic options ======================================
===========================================================================
-h, --help Info message about the program options.
--config=<file> The station configuration file.
--station=<id> The station identifier.
--statName=<name> The station name.
--demon, --daemon Start into the daemon mode.
--pidFile=<file> The file for the programm process ID place here.
--coreDumpAllow Set the limits for a core dump creation allow on the crash.
--messLev=<level> Process messages <level> (0-7).
--log=<direct> Direct messages to, by bitfield:
0x1 - syslogd;
0x2 - stdout;
0x4 - stderr;
0x8 - the messages archive.
----------- The config-file station '/' parameters -----------
StName <nm> Station name.
WorkDB <Type.Name> Work DB (type and name).
WorkDir <path> Work directory.
ModDir <path> Modules directory.
IcoDir <path> Icons directory.
DocDir <path> Documents directory.
MessLev <level> Messages <level> (0-7).
SelDebCats <list> Debug categories list (separated by ';').
LogTarget <direction> Direct messages to, by bitfield:
0x1 - syslogd;
0x2 - stdout;
0x4 - stderr;
0x8 - the messages archive.
Lang <lang> Work-internal language, like "en_US.UTF-8".
Lang2CodeBase <lang> Base language for variable texts translation, two symbols code.
MainCPUs <list> Main used CPUs list (separated by ':').
ClockRT <false> Set for use REALTIME (else MONOTONIC) clock, some problematic with the system clock modification.
SaveAtExit <true> Save the system at exit.
SavePeriod <sec> Save the system period.
RdStLevel <lev> Level of redundancy current station.
RdTaskPer <s> Call period of the redundant task.
RdRestConnTm <s> Restore connection timeout of try to the "dead" reserve stations.
RdStList <list> Redundant stations list, separated symbol ';' (st1;st2).
RdPrimCmdTr <0|1> Enable the primary commands transfering to the redundant stations.
=================== Subsystem "Module scheduler" options =================
--modPath=<path> Modules <path> (/var/os/modules/).
------------ Parameters of section '/sub_ModSched/' in config-file -----------
ModPath <path> Path to shared libraries(modules).
ModAllow <list> List of shared libraries allowed for automatic loading, attaching and starting (bd_DBF.so;daq_JavaLikeCalc.so).
Use '*' value for allow all modules.
ModDeny <list> List of shared libraries deny for automatic loading, attaching and starting (bd_DBF.so;daq_JavaLikeCalc.so).
ChkPer <sec> Period of checking at new shared libraries(modules).
========================= Subsystem "DB" options ========================
----------- The config-file station '/sub_BD/' parameters -----------
SYSStPref <1> Use station id prefix into generic (SYS) table.
======================= Subsystem "Security" options ====================
======================= Subsystem "Transports" options ==================
=============== Subsystem "Transport protocols" options =================
======================= Module <Protocol:HTTP> options =======================
---------- Parameters of the module section '/sub_Protocol/mod_HTTP/' in config-file ----------
AuthTime <min> Life time of the authentication, minutes (default 10).
=================== Subsystem "Data acquisition" options ================
------------ Parameters of section '/sub_DAQ/' in config-file -----------
RdRestDtTm <hour> Restore data archive depth from a reserve station after deadline.
======================== Subsystem "Archives" options ===================
------------ Parameters of section '/sub_Archive/' in config-file -----------
MessBufSize <items> Messages buffer size.
MessPeriod <sec> Message archiving period.
ValPeriod <msec> Values active archiving period.
ValPriority <level> Values task priority level of active archiving.
RdRestDtOverTm <hours> Overtime of the reserve history reload at start in hours.
======================= Module <Archive:FSArch> options =======================
--noArchLimit Disable archives limit to the file number. Use for see archives mode, not work.
======================= Subsystem "Special" options =====================
======================= Module <Special:SystemTests> options =======================
---------- Parameters of the module section '/sub_Special/mod_SystemTests/' in config-file ----------
All tests main options:
id test's id;
on on test's flag;
per repeat period (sek).
*** Test's options ***
1) Param DAQ parameters test. Make read a parameter's attributes and configuration fields.
1:name DAQ parameter address
2) XML XML file parsing test. Parse and show selected file structure.
1:file XML file
3) Mess Messages archive test. Periodic read new messages from archive, for selected archivator.
1:arhtor Archivator
2:categ Messages category pattern
3:depth Messages depth (s)
4) SOAttach Attach/detach module test.
1:name Path to module
2:mode Mode (1-attach;-1-detach;0-change)
3:full Full attach(to start)
5) Val Parameter attribute's value test.
Periodic make gathering for last value of selected attribute, and also gathering from archive for selected depth.
1:name Parameter attribute path
2:arch_len Archive value getting depth (s)
3:arch_per Archive value getting period (us)
6) DB Full database test. Make:
- make/open DB;
- make/open table;
- make multiply records for determined structure;
- modify multiply records;
- get and check values for multiply records;
- modify record and table structure;
- remove multiply records;
- close/remove table;
- close/remove DB.
1:type DB type
2:addr DB address
3:table DB table
4:size Records number
7) TrOut Output and/or input transports test.
Make test for output transport by send the request to selected input transport.
1:addr Address
2:type Transport module
3:req Request text
8) SysContrLang System control language test.
Make request to language elements by full path set.
Full path to language element have view </Archive/%2fbd%2fm_per>.
Full path contained two included path.
First </d_Archive/> is path to the node of the control tree.
Second </bd/m_per> is path to concrete node's element.
1:path Path to language element
9) ValBuf Value buffer tests.
Contain 13 tests for all aspects of value buffer (subsystem "Archives").
10) Archive Value archive allocation tests.
Contain 7(8) tests for value archivator for check to correct working the consecutive pack mechanism.
1:arch Value archive
2:period Values period (us)
3:archtor Archivator
11) Base64Code Mime Base64 encoding algorithm tests.
===================== Subsystem "User interfaces" options ===============
======================= Module <UI:QTStarter> options =======================
----------- Qt debug commandline options ----------
--noX11 Prevent Qt start, mostly for pure console.
--sync Switches to synchronous mode X11 for debugging.
--widgetcount Prints debug message at the end about number of widgets
left undestroyed and maximum number of widgets existed at
the same time.
----------- Qt commandline options ----------------
--qws With Qt for Embedded Linux makes this application the server.
--style=<nm> Sets GUI style to <nm> (windows, platinum, plastique, ...).
--stylesheet=<path> Sets styleSheet by <path> to file that contains.
--session=<nm> Restores from an earlier session <nm>.
--reverse Sets layout direction to Qt::RightToLeft.
--graphicssystem=<nm> Sets the backend to be used for on-screen widgets and QPixmaps (raster, opengl).
--display=<nm> Sets the X display name (default it is $DISPLAY).
--geometry=<geom> Sets the client geometry of the first window that is shown.
---------- Parameters of the module section '/sub_UI/mod_QTStarter/' in config-file ----------
StartMod <moduls> Start modules list (sep - ';').
======================= Module <UI:QTCfg> options =======================
---------- Parameters of the module section '/sub_UI/mod_QTCfg/' in config-file ----------
StartPath <path> Configurator start path.
StartUser <user> No password requested start user.
======================= Module <UI:Vision> options =======================
---------- Parameters of the module section '/sub_UI/mod_Vision/' in config-file ----------
StartUser <user> No password requested start user.
UserPass <pass> User password for no local start.
RunPrjs <list> Run projects list on the module start.
ExitLstRunPrjCls {0;1}Exit on last run project close (default = 1).
CachePgLife <hours> Cached pages lifetime.
VCAstation <id> VCA station id ('.' - local).
RestoreTime <seconds> Restore connection time.
======================= Module <UI:WebVision> options =======================
---------- Parameters of the module section '/sub_UI/mod_WebVision/' in config-file ----------
SessTimeLife <time> Time of the session life, minutes (default 10).