Модулі/Рушій Середовища Візуалізації та Управління (СВУ)

Модуль надає до OpenSCADA рушій середовища візуалізації та управління (СВУ). Сам модуль не реалізує візуалізації СВУ, а містить дані відповідно до концепції "Модель/дані – Інтерфейс". Візуалізація даних цього модуля виконується модулями візуалізації СВУ, наприклад, модулем Vision та WebVision.

Середовище візуалізації та управління (СВУ) є невід'ємною складовою SCADA системи. Воно застосовується на клієнтських станціях з метою доступного представлення інформації про об'єкт управління та видачі керуючого впливу на об'єкт. У різних практичних ситуаціях та умовах можуть застосовуватися СВУ, побудовані на різних принципах візуалізації. Наприклад, це можуть бути бібліотеки віджетів Qt, GTK+, wxWidgets або гіпертекстові механізми на основі технологій HTML, XHTML, XML, CSS та JavaScript або сторонні додатки візуалізації, реалізовані на різних мовах програмування Java, Python та інше. Будь-який з цих принципів має свої переваги та недоліки, комбінація яких може стати непереборною перепоною у можливості використання СВУ у тому або іншому практичному випадку. Наприклад, технології на кшталт бібліотеки Qt дозволяють створювати високопродуктивні СВУ, що безсумнівно важливо для станцій оператору управління технологічним процесом (ТП). Однак необхідність інсталяції даного клієнтського ПЗ може унеможливити його використання у окремих випадках. З іншого боку, Web-технології не потребують інсталяції на клієнтські системи та є гранично багатоплатформними (достатньо вказати посилання на Web-сервер у будь-якому Web-браузері), що найбільш важливо для різних інженерних та адміністративних станцій. З іншого боку, продуктивність та надійність таких інтерфейсів нижче, що практично виключає їх використання на станціях оператору ТП.

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

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

З метою запобігання цих проблем, а також створення у найкоротший термін повного спектру різних типів СВУ, засновано проєкт створення концепції СВУ. Результатом цього проєкту став даний модуль рушія(моделі даних) СВУ, а також модулі безпосередньої візуалізації Vision та WebVision.

1 Призначення

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

Фінальна версія цього модуля СВУ забезпечить:

Перелічимо можливості, які зможе та забезпечує СВУ, побудована на основі даного проєкту:

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

1. формування з шаблонних кадрів, шляхом призначення динаміки та без графічної конфігурації;
2. графічне формування нових кадрів, шляхом використання готових елементів візуалізації з бібліотеки — мнемосхеми;
3. формування, у бібліотеці, нових: кадрів, шаблонних кадрів та елементів відображення.

• побудова інтерфейсів візуалізації практично будь-якої складності (обмежену "дискретністю" функцій примітивів), починаючи від простих інтерфейсів моніторингу та, закінчуючи повноцінними ієрархічними інтерфейсами, що використовуються у SCADA системах;
• надання різних способів формування та конфігурації користувацького інтерфейсу, заснованих на різних інтерфейсах графічного представлення (Qt, Web, ...), або-ж за посередництвом стандартного інтерфейсу управління OpenSCADA;
• побудова та корекція інтерфейсу, призначення та зміна динаміки у процесі виконання;
• побудова, на рівні користувача, нових шаблонних кадрів та формування спеціалізованих, під область застосування, бібліотек кадрів (наприклад, включення кадрів параметрів, графіків та інших елементів з ув'язкою їх один з другим), згідно до ідеї вторинного використання, накопичення та вдосконалення;
• побудова нових користувацьких елементів візуалізації та формування спеціалізованих, під область застосування, бібліотек кадрів, згідно до ідеї вторинного використання, накопичення та вдосконалення;
• опис логіки нових шаблонних кадрів та користувацьких елементів візуалізації як простими зв'язками, так і лаконічною, повноцінною мовою користувацького програмування;
• можливість включення, до користувацьких елементів візуалізації, функцій (або кадрів обчислення функцій) об'єктної моделі OpenSCADA, практично зв'язуючи представлення з алгоритмом обчислення; наприклад, візуалізуючи бібліотеку моделей апаратів ТП, для подальшої візуальної побудови моделей ТП;
• розподіл даних користувацьких інтерфейсів та інтерфейсів представлення цих даних, що дозволяє будувати інтерфейс користувача у одному середовищі, а виконувати у багатьох інших (Qt, Web, ...);
• можливість підключення до виконуваного інтерфейсу для спостереження та корекції дій; наприклад, при навчанні операторів та контролю за його діями у реальному часі;
• візуальна побудова різних схем з накладанням логічних зв'язків та подальшим централізованим виконанням у фоні — візуальна побудова та виконання математичних моделей, логічних схем, релейних схем та іншого;
• надання, до OpenSCADA, функцій об'єктного API; може використовуватися для управління властивостями інтерфейсу візуалізації із користувацьких процедур;
• побудова серверів для: кадрів, елементів візуалізації та проєктів інтерфейсів візуалізації; з можливістю обслуговування множинних клієнтських підключень;
• проста організація клієнтських станцій на різній основі (Qt, Web, ...), з підключенням до центрального серверу;
• повноцінний механізм розподілу повноважень між користувачами, що дозволяє створювати та виконувати проєкти з різними правами доступу до його компонентів;
• гнучке формування правил сигналізацій та повідомлень, з урахуванням та підтримкою різних способів повідомлення;
• підтримка користувацького формування палітри та шрифтових переваг інтерфейсу візуалізації, в стилях;
• підтримка користувацького формування карт повідомлень під різне обладнання управління та переваги користувача;
• підтримка профілів користувача, що дозволяють визначати різні властивості інтерфейсу візуалізації (гама кольорів, шрифтові особливості, переважні карти повідомлень);
• гнучке зберігання та розповсюдження бібліотек віджетів, кадрів та проєктів інтерфейсів візуалізації у БД, підтримуваних OpenSCADA; практично, користувачу треба тільки зареєструвати отриману БД з даними.

2 Конфігурація та формування інтерфейсів СВУ

Сам модуль не містить механізмів візуального формування інтерфейсів СВУ, такі інструменти можуть надаватися модулями кінцевої візуалізації СВУ, наприклад, він надається модулем Vision.

Хоча візуальних механізмів формування СВУ модулем не надається, для управління логічної структури надається механізм, реалізований на основі інтерфейсу управління OpenSCADA, а значить, доступний для використання у будь-якому конфігураторі OpenSCADA. Діалоги цього інтерфейсу розглянуто далі, у контексті розгляду архітектури модуля та його даних.

3 Архітектура

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

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

Кадри та користувацькі елементи розташовуються у бібліотеках віджетів. З елементів цих бібліотек формуються проєкти інтерфейсів кінцевої візуалізації СВУ. На основі-ж цих проєктів формуються сеанси візуалізації.

Описану структуру СВУ приведено на рисунку.

Дана архітектура СВУ дозволяє реалізовувати підтримку трьох рівнів складності у процесі розробки інтерфейсів управління:

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

3.1 Кадри та елементи відображення (віджети)

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

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

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

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

Похідні кадри/віджети можуть містити вкладені віджети, які можуть бути склеєні-зв'язані один з одним логікою, за допомогою мови користувацького програмування OpenSCADA.

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

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

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

3.2 Проєкт

Безпосередня конфігурація, та властивості кінцевого інтерфейсу візуалізації, містяться у проєкті інтерфейсу візуалізації СВУ, яких може бути створено багато.

Кожний проєкт включає сторінки з бібліотек кадрів-віджетів. Для низки режимів, сама сторінка може включати у себе вкладені сторінки як незалежні від батьківської, так і з використанням батьківського у ролі шаблону. Шаблонні сторінки-віджети дозволяють гранично спростити процес створення однотипних кадрів простого моніторингу, інженером АСУ ТП або користувачем OpenSCADA. Прикладом таких однотипних кадрів можуть бути: групи контурів, групи графіків, протоколи та різні зведені таблиці. Мнемосхеми технологічних процесів рідко підпадають під таку схему та формуються у окремій сторінці-віджеті.

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

Приклад ієрархічного представлення компонентів проєкту класичного інтерфейсу ВУ технологічного процесу, з описом виразів стандартних викликів, приведено на рисунку.

Передбачено наступні спеціальні властивості сторінок:

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

На комбінаціях вищевказаних спеціальних властивостей сторінок реалізовано наступні їх типи:

• Стандарт — стандартна сторінка (не встановлено жодної з властивостей), є повноцінною кінцевою сторінкою.
• Контейнер — повноцінна сторінка з властивістю контейнера (Контейнер).
• Логічний контейнер — логічний контейнер, фактично сам не є сторінкою (Контейнер|Порожньо), виконує роль проміжного та групуючого елементу у дереві сторінок.
• Шаблон — сторінка-шаблон (Шаблон). Чиста шаблонна сторінка, використовується для опису загальних властивостей та довизначення їх у вкладених сторінках, у приватному порядку.
• Контейнер та шаблон — сторінка шаблону та контейнер (Шаблон|Контейнер), поєднує функції шаблону та контейнеру.
• Зв'язок — зв'язок на іншу сторінку. Зв'язки можуть бути використані на повністю динамічних та високо тиражованих сторінках, для оптимізації використання пам'яті. Для розрізнення відкриття зв'язуваних сторінок Ви маєте використовувати атрибут "path". Функція uiCmd() користувацького API має використовуватися для керування сторінками цього типу замість прямого запису до атрибутів сторінок "pgOpen" та "pgOpenSrc".

На боці візуалізації (RunTime) побудовано логіку, що регулює яким чином відкривати сторінки, на основі наступних атрибутів базового елементу "Box":

• pgOpen — ознака "Сторінка відкрита";
• pgNoOpenProc — ознака "Виконувати сторінку навіть якщо вона не відкрита";
• pgOpenSrc — містить адресу виджета, або сторінки, що відкрила поточну сторінку; у випадку вкладеного контейнерного віджета тут міститься адреса включеної сторінки; для відкриття сторінки із скрипта достатньо тут вказати адресу віджета-джерела відкриття, але для сторінок типу "Зв'язок" Ви маєте віддавати перевагу використанню функції uiCmd() користувацького API, для керування сторінкам;
• pgGrp — група сторінок, використовується для зв'язки контейнерів сторінок зі сторінками, згідно загальної групи; ПОРОЖНЯ та "main" група передбачають використання цієї сторінки як Кореневу-основну сторінку, тож така буде замінювати інші Кореневі-головні сторінки; група "fl" призначена для використання у зовнішніх вікнах, які передбачено для багаторазового одночасного відкриття та які не мають відстежуватися на дублікати; решта передбачено для включення у контейнери-бокси або одноразового одночасного відкриття, тож вони примусово перевіряються на дублікати, коли останнє відкривається, а попередні закриваються.

Логіка визначення способу відкриття сторінок працює наступним чином:

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

3.3 Сеанс виконання проєкту

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

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

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

Обчислення та обробка віджету виконується у наступній послідовності:

• обираються події, доступні на момент обчислення, з атрибуту "event" віджету;
• події завантажуються до параметру "event" об'єкта обчислення;
• до об'єкту обчислення завантажуються значення за вхідними зв'язками;
• до об'єкту обчислення завантажуються значення спеціальних змінних (f_frq, f_start та f_stop);
• до об'єкту обчислення завантажуються значення обраних параметрів віджету;
• обчислення;
• вивантаження значень об'єкту обчислення у обрані параметри віджету;
• вивантаження подій з параметру "event" об'єкта обчислення;
• обробка подій та передача необроблених на рівень вище.

Об'єкти сеансу успадковуються від абстрактного об'єкту "Widget" та використовують відповідні об'єкти проєкту. Так, сеанс "Session" використовує проєкт "Project" та формує на його основі розгорнуте дерево. Сторінка проєкту "Page" прямо використовується сторінкою сеансу "SessPage". Решта об'єктів "SessWdg" розгортаються відповідно до ієрархії елементів сторінки.

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

• "Сторінка верхнього рівня" -> "Сторінка нижнього рівня"
• "Віджет нижнього рівня" -> "Віджет верхнього рівня"

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

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

3.4 Стилі

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

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

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

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

Рисунок. Вкладка "Стилі" сторінки конфігурації проєкту.

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

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

3.5 Події, їх обробка та карти подій

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

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

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

Загалом, передбачено чотири типи подій:

• події образів-примітивів СВУ (префікс: ws_), наприклад, подія натискання екранної кнопки — "ws_BtPress";
• клавішні події (префікс: key_) — всі події від клавіатури та миші у вигляді "key_presAlt1";
• користувацькі події (префікс: usr_), генеруються користувачем у процедурах обрахунку віджетів;
• маповані події (префікс: map_) — події, отримані з карти події, у планах.

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

ws_BtPress — подія;

/curtime — шлях до дочірнього елементу, який згенерував подію.

У таблиці 3.5 наведено перелік стандартних подій, підтримку яких має бути забезпечено у візуалізаторах СВУ.

Таблиця 3.5. Стандартні події

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

• Первинний — сценарій управління відкриттям сторінок.
• Вторинний — обчислювальна процедура віджета.

Механізм "Сценарій управління відкриттям сторінок" засновано на базовому атрибуті віджету "evProc", у якому може описуватися відкриття сторінок. Сценарій цього атрибуту записується у вигляді переліку команд з синтаксисом: "{event}:{evSrc}:{com}:{prm}". Де:

• event — очікувана подія;
• evSrc — шлях вкладеного віджета-джерела події;
• com — команда сеансу;
• prm — параметр команди.

Реалізовано наступні команди:

• open — відкриття сторінки; сторінка, що відкривається, вказується у параметрі prm як прямо, так і у вигляді шаблону, наприклад — /pg_so/1/*/*;
• next — відкриття наступної сторінки; сторінка, що відкривається, вказується у параметрі prm, у вигляді шаблону, наприклад: /pg_so/*/*/$;
• prev — відкриття попередньої сторінки; сторінка, що відкривається, вказується у параметрі prm, у вигляді шаблону, наприклад: /pg_so/*/*/$.

Спеціальні символи шаблону розшифровуються наступним чином:

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

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

• Перемикання об'єкту сигналізації:

Початково: /pg_so/pg_1/pg_mn/pg_1

Команда: open:/pg_so/2/*/*

Результат: /pg_so/pg_2/pg_mn/pg_1

• Перемикання виду відображення:

Початково: /pg_so/pg_1/pg_mn/pg_1

Команда: open:/pg_so/*/gkadr/*

Результат: /pg_so/pg_1/pg_gkadr/pg_1

• Наступна/попередня сторінка виду відображення:

Початково: /pg_so/pg_1/pg_mn/pg_1

Команда: next:/pg_so/*/*/$

Результат: /pg_so/pg_1/pg_mn/pg_2

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

ws_BtPress:/prev:prev:/pg_so/*/*/$
ws_BtPress:/next:next:/pg_so/*/*/$
ws_BtPress:/go_mn:open:/pg_so/*/mn/*
ws_BtPress:/go_graph:open:/pg_so/*/ggraph/*
ws_BtPress:/go_cadr:open:/pg_so/*/gcadr/*
ws_BtPress:/go_view:open:/pg_so/*/gview/*
ws_BtPress:/go_doc:open:/pg_so/*/doc/*
ws_BtPress:/go_resg:open:/pg_so/rg/rg/*
ws_BtPress:/so1:open:/pg_so/1/*/*
ws_BtPress:/so2:open:/pg_so/2/*/*
ws_BtPress:/so3:open:/pg_so/3/*/*
ws_BtPress:/so4:open:/pg_so/4/*/*
ws_BtPress:/so5:open:/pg_so/5/*/*
ws_BtPress:/so6:open:/pg_so/6/*/*
ws_BtPress:/so7:open:/pg_so/7/*/*
ws_BtPress:/so8:open:/pg_so/8/*/*
ws_BtPress:/so9:open:/pg_so/9/*/*
ws_BtPress:*:open:/pg_control/pg_terminator

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

Вмістом атрибуту "event" є перелік подій формату "{event}:{evSrc}", з подією у окремому рядку. Наведемо приклад процедури обробки події на Java-подібній мові користувацького програмування OpenSCADA:

for(ev_rez = "", off = 0; (sval=event.parse(0,"\n",off)).length; ) {
  if(sval == "ws_BtPress:/cvt_light") alarmSt = 0x1000001;
  else if(sval == "ws_BtPress:/cvt_alarm") alarmSt = 0x1000002;
  else if(sval == "ws_BtPress:/cvt_sound") alarmSt = 0x1000004;
  else ev_rez += sval+"\n";
}
event = ev_rez;

3.6 Сигналізація

Важливим елементом будь-якого інтерфейсу візуалізації є сповіщення користувача про порушення — сигналізація. Для спрощення сприйняття, а також через тісний зв'язок візуалізації та сповіщення (як правило, сповіщення доповнюють візуалізацію) вирішено інтегрувати інтерфейс сповіщень у інтерфейс візуалізації. Для цього, у всіх віджетах, передбачається два додаткових атрибути рівня сеансу: "alarm" та "alarmSt". Атрибут "alarm" використовується для формування сигналу віджетом згідно до його логіки, а атрибут "alarmSt" використовується для контролю за фактом сигналізації гілки дерева сеансу.

Атрибут "alarm" є рядком, який має наступний формат: "{lev}|{categ}|{message}|{type}|{tp_arg}"
Де:

• lev — рівень сигналізації: число від 0 до 255;
• categ — категорія сигналу: параметр підсистеми збору, об'єкт, шлях або комбінація;
• message — повідомлення сигналізації;
• type — типи сповіщень, вказуються у вигляді цілого числа (0...7), що містять ознаки способів сповіщень; типові способи сповіщень:
  • 1 — візуальне;
  • 2 — гудок, часто відбувається через PC-speaker;
  • 4 — звуковий сигнал з файлу звуку або синтез мови; якщо у tp_arg вказано ім'я ресурсу звукового файлу, то відтворюється саме він, інакше виконується синтез мови з тексту, вказаного у message.
• tp_arg — аргумент типу; часто використовується для прямого вказання ресурсу звукового сигналу — файл звукового формату, при здійснені звукової сигналізації.

Атрибут "alarmSt" є цілим числом, яке відображає максимальний рівень сигналу та факт квітування гілки дерева сеансу. Формат числа має наступний вигляд:

• перший байт (0...255) характеризує рівень сигналу гілки;
• другий байт вказує тип сповіщення, так як і у атрибуті "alarm";
• третій байт вказує тип несквітованого сповіщення, так як і у атрибуті "alarm";
• четвертий байт має спеціальне значення, яке визначається окремими бітами:
  • біт 0 — вказує, встановленням, на факт квітування сповіщень у першому байті;
  • біт 1 — вказує, при встановленні його та бита 0, на повернення квітування — включення сповіщення.

Формування сигналу та отримання його візуалізатором.
Формування сигналу здійснюється самим віджетом, шляхом встановлення власного атрибуту "alarm" потрібним чином та, згідно до нього, автоматично встановлюється атрибут "alarmSt" поточного та вищестоящих віджетів. Візуалізатори отримують сповіщення про сигнал за допомогою стандартного механізму сповіщення про зміну атрибутів віджетів.

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

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

Квітація
Квітація (від quietance) — процес підтвердження факту того, що оперативний персонал звернув увагу на порушення у роботі ТП. Зазвичай цей процес передбачає вживання заходів оператором для усунення порушення та натискання відповідної кнопки припинення сигналізації.

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

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

//Виокремлення факту наявності сигналізацій різних способів-типів сповіщення
cvt_light_en = alarmSt&0x100; cvt_alarm_en = alarmSt&0x200; cvt_sound_en = alarmSt&0x400;
//Виокремлення факту наявності несквітованих сигналізацій різних способів сповіщення
cvt_light_active = alarmSt&0x10000; cvt_alarm_active = alarmSt&0x20000; cvt_sound_active = alarmSt&0x40000;
//Обробка подій кнопок квітації та квітація різних способів сповіщення
for(ev_rez = "", off = 0; (sval=event.parse(0,"\n",off)).length; ) {
  if(sval == "ws_BtPress:/cvt_light") alarmSt = 0x1000001;
  else if(sval == "ws_BtPress:/cvt_alarm") alarmSt = 0x1000002;
  else if(sval == "ws_BtPress:/cvt_sound") alarmSt = 0x1000004;
  else ev_rez += sval + "\n";
}
event = ev_rez;

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

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

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

• Для серверу/рушія візуалізації, атрибутом "notify{N}" у форматі:

//flags=notifyServ[{DL}][|resource[|queue[|qMergeMess]]];
//resStatic={ResourceFile}
if(doRes) { Текст команди формування ресурсу. }
if(doNtf) { Текст команди сповіщення. }

• Для візуалізатору, атрибутом "notifyVis[Vision|WebVision]{N}" у форматі:

//flags=notify[{DL}][|resource[|queue[|quietanceRet]]];
//name={Ім'я сповіщувача}
//ico={Ім'я іконки}
{ Текст команди сповіщення для будь-якого або конкретного візуалізатору. }

Прапорці:

• notify[{DL}], notifyServ[{DL}] — включає сповіщення з повтором через час DL, якщо вказано; для DL = 0 повтор здійснюється одразу; notifyServ[{DL}] використовується для примусового сповіщення на боці серверу замість візуалізатору із notify[{DL}].
• resource — запитувати-формувати (примусово) ресурс сповіщення у сервера візуалізації, може бути звуковим файлом, текстом або іншими даними формування сповіщення; але наразі сповіщувачі переважно очікують аудіо.
• queue — ресурси сповіщення визначаються не лише за глобальною ознакою порушення та квітації, а й згідно до пріоритетної черги джерел сповіщення-ресурсів. Черга формується на боці серверу візуалізації, а для візуалізаторів вказується необхідність роботи з нею при запиті ресурсів.
• qMergeMess — поєднувати сповіщення у черзі за рівністю сповіщення.
• quietanceRet — можливість відкликання-повернення стишення візуалізатору, тобто, по факту — зворотного включення сповіщення.

Наявність поля "resStatic" вмикає отримання ресурсу безпосередньо із таблиці ресурсів або файлу, вказується у спосіб подібний до примітиву "Медіа".

Змінні обміну:

• en[0,1] — сповіщення ввімкнути (1) або вимкнути (0);
• doNtf[0,1] — виклик сценарію сповіщення;
• doRes[0,1] — виклик сценарію формування ресурсу;
• res — вміст або ім'я файлу з вмістом ресурсу, для зовнішніх сценаріїв;
• resTp — тип ресурсу, на кшталт "audio/ogg"; є поверненням та поміщається до стандартного виходу (для Shell) для doRes;
• mess — повідомлення-параметри формування ресурсу або сповіщення;
• lang — мова поточного користувача або системи;
• prcID — унікальний ідентифікатор процедури (на кшталт "ses_AGLKS_ntf2"), переважно для безпечного створення тимчасових файлів.

Приклади та коментарі до функціювання типових способів сповіщення:

• Бузер (buzzer) на боці візуалізатору (flags=notify0) або серверу візуалізації (flags=notifyServ0) із повторенням та контролем програвання:

• alarm = "10|Prm||0x02"
• notifyVisVision1 | notify1 =

//flags=notify0|notifyServ0
if(en && (ntfPrg=SYS.system("which beep")).length &&
    (SYS.system("test -s "+prcID+".pid",true) ||		//No PID file
     SYS.system("ps -A -o \"pid cmd\" | grep \"^ *$(cat "+prcID+".pid).*"+ntfPrg.parseLine(0)+"\" > /dev/null",true)) )	//No notify already
{
    ntfPrg = ntfPrg.parseLine(0);
    SYS.system(ntfPrg+" -f 1000 -l 100000 &\necho $! > "+prcID+".pid", true);
}
else if(!en && !SYS.system("test -s "+prcID+".pid",true))
    SYS.system("kill $(cat "+prcID+".pid); rm "+prcID+".pid "+prcID+".res;", true);

• notifyVisVision1 | notify1 =

#!/bin/sh
#flags=notify0|notifyServ0
if test $en = 1; then
    ntfPrg=$(which beep)
    #No PID file || No notify already
    if test ! -s $prcID.pid || ! ps -A -o "pid cmd" | grep "^ *$(cat $prcID.pid).*$ntfPrg" > /dev/null; then
      $ntfPrg -f 1000 -l 100000 &
      echo $! > $prcID.pid
    fi
elif test -s $prcID.pid; then
    kill $(cat $prcID.pid)
    rm $prcID.pid $prcID.res
fi

• Повторюване програвання готового звукового файлу, одного загального, на боці візуалізатору (flags=notify2) або серверу візуалізації (flags=notifyServ2), тривалість аудіо файлу для внутрішньої мови має бути не більше 10 секунд:

• alarm = "10|Prm||0x04"
• notify2 | notifyVisVision2 =

//flags=notify2|notifyServ2
if(en) SYS.system("play -q alarm.ogg");

• notify2 | notifyVisVision2 =

#!/bin/sh
#flags=notify2|notifyServ2
if test $en = 1; then play -q alarm.ogg; fi

• Програвання індивідуального для джерела звукового файлу, на боці візуалізатору, тривалість аудіо файлу для внутрішньої мови має бути не більше 10 секунд:

• alarm = "10|Prm||0x04|res:al_prm1"
• notify2 =

//flags=queue

• notifyVisVision2 =

//flags=notify2|queue
if(doNtf && en && res.length) {
  SYS.fileWrite("tmpPlay", res);
  SYS.system("play -q tmpPlay");
  SYS.fileRemove("tmpPlay");
}

• notifyVisVision2 =

#!/bin/sh
#flags=notify2|queue
if test $doNtf = 1 -a $en = 1 -a -s $res; then play -q $res; fi

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

• alarm = "10|Prm|Текстове повідомлення синтезу мови|0x04"
• notify2 =

//flags=queue

• notifyVisVision2 =

//flags=notify2|queue
if(doNtf && en && mess.length) {
  SYS.fileWrite("tmpForSpeech", mess);
  SYS.system("festival --tts tmpForSpeech");
  SYS.fileRemove("tmpForSpeech");
}

• notifyVisVision2 =

#!/bin/sh
#flags=notify2|queue
if test $doNtf = 1 -a $en = 1 -a "x" != "x$mess"; then
  echo $mess > tmpForSpeech
  festival --tts tmpForSpeech
  rm tmpForSpeech
fi

• Приготування звукового файлу, одного загального, та його програвання на боці візуалізатору (flags=notifyServ2) або серверу візуалізації (flags=notifyServ2), тривалість аудіо файлу для внутрішньої мови має бути не більше 10 секунд:

• alarm = "10|Prm||0x04"
• notify2 =

//flags=notify2|notifyServ2|resource
if(doRes) res = SYS.fileRead("alarm.ogg");  //Insert here a different method of the generation
if(doNtf && en && res.length) {
  SYS.fileWrite("tmpPlay", res);
  SYS.system("play -q tmpPlay");
  SYS.fileRemove("tmpPlay");
}

• notify2 =

#!/bin/sh
#flags=notify2|notifyServ2|resource
if test $doRes = 1; then cp -f alarm.ogg $res; fi  #Insert here a different method of the generation
if test $doNtf = 1 -a $en = 1 -a -s $res; then play -q $res; fi

• notifyVisVision2 =

//flags=notify2|resource
if(en && res.length) {
  SYS.fileWrite("tmpPlay", res);
  SYS.system("play -q tmpPlay");
  SYS.fileRemove("tmpPlay");
}

• notifyVisVision2 =

#!/bin/sh
#flags=notify2|resource
if test $en = 1 -a -s $res; then play -q $res; fi

• Приготування індивідуального для джерела сповіщення звукового файлу через синтез мови, на боці візуалізатору (flags=notify2) або серверу візуалізації (flags=notifyServ2), тривалість повідомлення для внутрішньої мови має бути не більше 10 секунд:

• alarm = "10|Prm|Текстове повідомлення синтезу мови|0x04"
• notify2 =

//flags=notify2|notifyServ2|queue
if(doRes && mess.length) {
 SYS.fileWrite("tmpText", mess);
 SYS.system("text2wave tmpText -o tmpWAV");
 res = SYS.fileRead("tmpWAV");
 SYS.fileRemove("tmpText"); SYS.fileRemove("tmpWAV");
}
if(doNtf && en && res.length) {
 SYS.fileWrite("tmpPlay", res);
 SYS.system("play -q tmpPlay");
 SYS.fileRemove("tmpPlay");
}

• notify2 =

#!/bin/sh
#flags=notify2|notifyServ2|queue
if test $doRes = 1 -a "x" != "x$mess"; then
 echo $mess > tmpText
 text2wave tmpText -o $res
 rm tmpText
fi
if test $doNtf = 1 -a $en = 1 -a -s $res; then play -q $res; fi

• notifyVisVision2 =

//flags=notify2|queue
if(en && res.length) {
 SYS.fileWrite("tmpPlay", res);
 SYS.system("play -q tmpPlay");
 SYS.fileRemove("tmpPlay");
}

• notifyVisVision2 =

#!/bin/sh
#flags=notify2|queue
if test $en = 1 -a -s $res; then play -q $res; fi

3.7 Управління правами

Для поділу доступу до інтерфейсу ВУ та його складовим, кожний віджет містить інформацію про власника, його групи та права доступу. Права доступу записуються у вигляді тріади: "{користувач}{група[,група1,групаN]}{інші}", де кожний елемент складається з двох ознак доступу, для який прийнята наступна інтерпретація:

• r — право на перегляд віджету;
• w — право на контроль над віджетом.

У режимі розробки використовується проста схема доступу "root:UI|RWRWR_", що означає — всі користувачі можуть відкривати та переглядати бібліотеки, їх компоненти та проєкти; а редагувати можуть всі користувачі групи "UI" (користувацькі інтерфейси).

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

3.8 Зв'язування з динамікою

Для надання до інтерфейсу візуалізації актуальних даних, повинні використовуватися дані підсистеми "Збір даних (DAQ)". Природа цих даних наступна:

1. параметри, що містять деяку кількість атрибутів;
2. атрибути параметру можуть надавати дані п'яти базових типів: Логічний, Цілий, Реальний, Рядок та Об'єкт;
    які доповнено СВУ модифікаторами: "Обирається"; варіантами Рядка: "Текст", "Переклад", "Колір", "Зображення", "Шрифт", "Адреса"; варіантами Цілого: "ДатаЧас".
3. атрибути параметру можуть мати архів (історію);
4. атрибути параметру можуть бути на читання, запис та з повним доступом.

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

Згідно до пункту 2, зв'язки забезпечують прозоре перетворення типів та не потребують спеціальної конфігурації.

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

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

Рисунок. Вкладка "Обробка" сторінки конфігурації віджета.

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

Якщо у стовпчику "Обробка" стоїть true, то у обчислювальній процедурі стає доступною змінна {ідентифікатор віджета}_{ідентифікатор атрибуту}, наприклад cw_value.

Стовпчик "Конфігурація" дозволяє вказати тип зв'язку атрибуту віджета:

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

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

• Для постійної: пряме значення атрибуту.
• Для зв'язку: "{параметр}|{ідентифікатор}", де:
  • параметр — група атрибутів;
  • ідентифікатор — ідентифікатор атрибуту; саме значення у цьому полі співставляється з атрибутами параметрів DAQ після указання групового зв'язку, при автоматичному зв'язувані;
• Для стиля: ідентифікатор-ім'я поля стиля.

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

• val: — Пряме завантаження значення через механізм зв'язків. Наприклад, зв'язок "val:100" завантажує значення 100 до атрибуту віджета. Часто використовується у випадку відсутності кінцевої точки зв'язку, з метою прямого встановлення значення.
• prm: — Зв'язок на атрибут параметру або параметр, загалом, для групи атрибутів підсистеми "Збір даних". Наприклад, зв'язок "prm:/LogicLev/experiment/Pi/var" здійснює доступ атрибуту віджета до атрибуту параметра підсистеми "Збір даних". Знак "(+)", у кінці адреси, вказує на вдале зв'язування-лінкування та присутність цільового об'єкту. Для атрибутів об'єктного типу допустимий ієрархічний доступ до конкретної властивості об'єкту, шляхом вказання її шляху через символ '#', наприклад: "prm:/LogicLev/experiment/Pi/var#pr1/pr2".
• wdg: — Зв'язок на атрибут іншого віджета або віджет, загалом, для групи атрибутів. Наприклад, зв'язок "wdg:/ses_AGLKS/pg_so/pg_1/pg_ggraph/pg_1/a_bordColor" здійснює доступ атрибуту одного віджету до атрибуту іншого. Підтримуються як абсолютні, так і відносні шляхи зв'язків. Точкою відліку адреси абсолютного зв'язку виступає об'єкт кореня модуля "VCAEngine", що означає — першим елементом абсолютної адреси є ідентифікатор сеансу або проєкту. Перший елемент на боці сеансу опускається, тому зв'язки, встановлені у проєкті, там працюють. Відносні зв'язки беруть відлік від віджету, де зв'язок вказано. Спеціальним елементом відносного зв'язку є елемент вищестоячого вузла "..".
• arh: — Особливий тип зв'язку, доступний тільки для окремого атрибуту типу "Адреса", який дозволяє підключитися прямо до архіву значень ("arh:CPU_load"). Може бути корисний для вказання архіву у якості джерела даних примітиву "Діаграма".

Обробка зв'язків відбувається з періодичністю обчислення віджету, у порядку:

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

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

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

Рисунок. Вкладка "Зв'язки" сторінки конфігурації віджету з індивідуальним призначенням атрибутів.

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

Рисунок. Вкладка "Зв'язки" сторінки конфігурації контейнеру віджетів, що включає віджети зі зв'язками.

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

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

Розглянемо приклад, коли є кадр загального призначення "Панель контролю графіком" та багато "Графіків" на різних кадрах. "Панель контролю графіком" має зв'язки з шаблонами:

• tSek -> "<page>|tSek"
• tSize -> "<page>|tSize"
• trcPer -> "<page>|trcPer"
• valArch -> "<page>|valArch"

При цьому, кожний віджет "Графік" має атрибути "tSek", "tSize", "trcPer" та "valArch". За викликом сигналу відкриття "Панелі контролю графіком" з будь-якого віджету "Графік", відбувається зв'язування атрибутів "Панелі контролю графіком" з атрибутами віджету "Графік", згідно шаблону. як результат, всі зміни на "Панелі контролю графіком" будуть відображатися на графіку, за посередництвом цих зв'язків.

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

Для наочного зображення цього механізмі наведено таблицю.

Таблиця. Механізм динамічної лінковки.

3.9 Примітиви віджетів

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

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

Таблиця. Бібліотека примітивів віджетів — базові елементи відображення

Таблиця. Загальний набір властивостей/атрибутів віджету

* — Спеціальна функція атрибуту віджета, виконувана у сеансі проєкту при користувацькій модифікації.

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

3.9.1 Елементарна графічна фігура (ElFigure)

Примітив є основою відмальовки елементарних графічних фігур з різноманітною їх комбінацією у одному об'єкті. Враховуючи широкий спектр можливих фігур, які повинен підтримувати примітив, та, у цей-же час, бути достатньо простим у використанні та, по можливості, у реалізації, було вирішено обмежити перелік базових фігур, використаних для побудови результуючих графічних об'єктів, до таких: лінія, дуга, крива Без'є та заливка замкнених контурів. Ґрунтуючись вже на цих базових фігурах, можна будувати довільні фігури, комбінуючи базові. У рамках примітиву існує можливість завдання прозорості кольору у діапазоні [0...255], де '0' — повна прозорість.

Таблиця. Набір додаткових властивостей/атрибутів примітиву "Елементарна фігура (ElFigure)"

3.9.2 Елемент форми (FormEl)

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

Таблиця. Набір додаткових властивостей/атрибутів примітиву "Елемент форми (FormEl)"

<tbl>
<h><s>{Заголовок1}</s><s>{Заголовок2}</s></h>
<r><s>{Рядок1Стовпчик1Рядок}</s><i>{Рядок1Стовпчик2Ціле}</i></r>
<r><b>{Рядок2Стовпчик1Логічне}</b><r>{Рядок2Стовпчик2Реальне}</r></r>
</tbl>

3.9.3 Елемент тексту (Text)

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

Таблиця. Набір додаткових властивостей/атрибутів примітиву "Елемент тексту (Text)"

3.9.4 Елемент відображення медіа-матеріалів (Media)

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

Таблиця. Набір додаткових властивостей/атрибутів примітиву "Елемент відображення медіа-матеріалів (Media)"

3.9.5 Елемент побудови діаграм (Diagram)

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

• "Графік-тренд" — будує графік значень параметру у часі.
• "Спектр" — будує частотний спектр із значень параметрів. Вікно даних частотного спектру формується виходячи із розміру віджету по горизонталі, у пікселях, та доступних даних параметрів, накладених на ґратку горизонтального розміру. У зв'язку з цим, мінімальна виділювана частота визначається значенням атрибуту "tSize" — "1/tSize", а максимальна, половинною шириною графіка у пікселях помноженою на мінімальну частоту "width/(2*tSize)".
• "XY" — будує двомірний графік значень параметрів, парами на графік, де парні по осі Y (0,2,4...) та непарні по осі X (1,3,5...). Вказаний діапазон часу даних використовується у отримані значень параметрів осі X та Y, з подальшим зображенням.

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

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

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

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

Таблиця. Набір додаткових властивостей/атрибутів примітиву "Елемент побудови діаграм (Diagram)"

3.9.6 Елемент побудови протоколів на основі архівів повідомлень (Protocol)

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

Таблиця. Набір додаткових властивостей/атрибутів примітиву "Елемент побудови протоколів на основі архівів повідомлень (Protocol)"

3.9.7 Елемент формування звітної документації (Document)

Примітив призначено для формування звітної, оперативної та іншої документації на основі шаблонів документів.

Таблиця. Набір додаткових властивостей/атрибутів примітиву "Елемент формування звітної документації (Document)"

<body docProcLang="JavaLikeCalc.JavaScript">
  <h1>Значення<?dp return wCod+1.314;?></h1>
</body>

Можливості примітиву "Документ":

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

У основі будь-якого документу лежить XHTML-шаблон. XHTML-шаблон це тег "body" WEB-сторінки, що містить статику документу у стандарті XHTML 1.0 та елементи виконувальних інструкцій на мові користувацького програмування OpenSCADA, у вигляді <?dp {procedure} ?>. Результуючий документ формується шляхом виконання процедур та вставки їх результату у документ.

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

На рисунку зображено структурну схему віджету примітива "Документ". Згідно цієї структури, "Документ" містить: XHTML-шаблон, результатні документи та процедуру обробки даних. Джерелом даних процедури та результатних документів є атрибути віджету.

Рисунок. Структурна схема примітиву "Документ".

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

Генерація документу завжди здійснюється у момент встановлення атрибуту часу time відносно встановленого раніш початкового часу документу у атрибуті bTime. При вимкненому архіві, результатний документ поміщається безпосередньо у атрибут doc. При увімкненому архіві, результатний документ поміщається до клітинки під курсором, атрибут aCur, а також у doc, якщо значення курсору архіву aCur та курсору візуалізованого документу vCur збігаються. Атрибути архівних курсорів передбачають декілька командних значень:

• "aCur < 0" — переміщує курсор архіватору на наступну позицію, тим самим залишаючи попередній документ у архіві та очищаючи документ під курсором, якщо кільцевий архів замкнувся.
• "vCur == -1" — вибір наступного документу для відображення, обраний документ копіюється до атрибуту doc.
• "vCur == -2" — вибір попереднього документу для відображення, обраний документ копіюється до атрибуту doc.

Як було вказано вище, динаміка шаблону документа визначається вставками виконуваних інструкцій виду "<?dp {procedure} ?>". У процедурах можуть використовуватися однойменні атрибути віджету та функції користувацького інтерфейсу програмування OpenSCADA. Крім атрибутів віджету, зарезервовано спеціальні атрибути, дивись таблицю.

Таблиця. Спеціальні та зарезервовані елементи шаблону.

3.9.8 Контейнер (Box)

Примітив контейнеру, використовується для формування складених віджетів та/або сторінок користувацького інтерфейсу.

Таблиця. Набір додаткових властивостей/атрибутів примітиву "Контейнер (Box)"

3.10 Використання БД для зберігання бібліотек віджетів та проєктів

Зберігання даних віджетів, бібліотек віджетів та проєктів реалізовано у БД, доступних OpenSCADA. БД організовано за приналежністю даних до бібліотеки-проєкту. Тобто, окрема бібліотека-проєкт зберігається у окремій групі таблиць БД. Перелік бібліотек віджетів зберігається у індексній таблиці бібліотек з іменем "VCALibs" та структурою "Libs", а перелік проєктів у індексній таблиці "VCAPrjs" та структурою "Projs". Екземпляр цих таблиць створюється у кожній БД, де зберігаються дані цього модуля. До складу таблиць, що належать бібліотеці віджетів та проєкту, входять наступні:

• "{DB_TBL}" — таблиця віджетів, що належать бібліотеці (структура "LibWigets"), або сторінок, що належать проєкту (структура "ProjPages");
• "{DB_TBL}_io" — таблиця робочих властивостей віджетів та вкладених віджетів бібліотеки (структура "LibWidgetIO") або властивостей сторінок проєкту (структура "ProjPageIO");
• "{DB_TBL}_uio" — таблиця користувацьких властивостей віджетів та вкладених віджетів бібліотеки (структура "LibWidgetUserIO") або користувацьких властивостей сторінок проєкту (структура "ProjPageUserIO");
• "{DB_TBL}_incl" — таблиця віджетів, вкладених у віджети-контейнери, бібліотеки (структура "LibWidgetIncl") або проєкту (структура "ProjPageWIncl");
• "{DB_TBL}_mime" — таблиця ресурсів бібліотеки та її віджетів (структура "LibWidgetMime"), або проєкту та його сторінок (структура "ProjMime");
• "{DB_TBL}_stls" — таблиця значень стильових параметрів проєкту (структура "PrjStlsIO");
• "{DB_TBL}_stl" — застаріла таблиця значень стильових параметрів проєкту (структура "PrjStlIO");
• "{DB_TBL}_ses" — таблиця даних режиму виконання проєкту, тобто сеансів (структура "PrjSesIO").

{DB_TBL} наразі формується у вигляді "wlb_{ID}" для бібліотек та "prj_{ID}" для проєктів, а окреме поле DB_TBL таблиць "Libs", "Projs" застаріле і буде видалене у випуску OpenSCADA 1.0!

Проекції (структури) основних таблиць такі:

• Libs(ID, NAME, DSCR, DB_TBL, ICO) — бібліотеки віджетів ID.

ID — ідентифікатор;

NAME — ім'я;

DSCR — опис;

DB_TBL (ЗАСТАРІЛЕ) — корінь таблиць БД з віджетами;

ICO — закодоване (Base64) зображення іконки бібліотеки.

• LibWigets(ID, ICO, PARENT, PROC, PROC_PER, ATTRS, TIMESTAMP) — віджети ID бібліотеки.

ID — ідентифікатор;

ICO — закодоване (Base64) зображення іконки віджету;

PARENT — адреса віджету основи, у вигляді /wlb_originals/wdg_Box;

PROC — внутрішня процедура та мова процедури віджету;

PROC_PER — період обчислення процедури віджету;

ATTRS — перелік атрибутів віджету, модифікованих користувачем;

TIMESTAMP — мітка часу останньої модифікації.

• LibWidgetIO(IDW, ID, IDC, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL) — робочі атрибути ID віджету IDW дочірнього віджету IDC.

IDW — ідентифікатор віджету;

ID — ідентифікатор атрибуту;

IDC — ідентифікатор дочірнього віджету;

IO_VAL — значення атрибуту;

SELF_FLG — внутрішні прапорці атрибутів;

CFG_TMPL — шаблон елементу конфігурації, заснованого на даному атрибуті;

CFG_VAL — значення елементу конфігурації (посилання, константа ...).

• LibWidgetUserIO(IDW, ID, IDC, NAME, IO_TP, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL) — користувацькі атрибути ID віджету IDW дочірнього віджету IDC.

IDW — ідентифікатор віджету;

ID — ідентифікатор атрибуту;

IDC — ідентифікатор дочірнього віджету;

NAME — ім'я атрибуту;

IO_TP — тип та головні прапорці атрибуту;

IO_VAL — значення атрибуту;

SELF_FLG — внутрішні прапорці атрибуту;

CFG_TMPL — шаблон елементу конфігурації, заснованого на даному атрибуті;

CFG_VAL — значення елементу конфігурації (посилання, константа ...).

• LibWidgetIncl(IDW, ID, PARENT, ATTRS) — включені у контейнер IDW віджети ID.

IDW — ідентифікатор віджету;

ID — ідентифікатор екземпляру вкладеного віджету;

PARENT — адреса віджету основи, у вигляді /wlb_originals/wdg_Box;

ATTRS — перелік атрибутів віджету, модифікованих користувачем.

• LibWidgetMime(ID, MIME, DATA) — audio, video, media та інші ресурси віджетів ID бібліотеки.

ID — ідентифікатор ресурсу;

MIME — MIME ресурсу, у форматі — "{MIME};{Size}";

DATA — дані ресурсу, кодовані Base64.

• Projs(ID, NAME, DSCR, DB_TBL, ICO, USER, GRP, PERMIT, PER, FLGS, STYLE) — проєкти ID інтерфейсу візуалізації.

ID — ідентифікатор проєкту;

NAME — ім'я проєкту;

DSCR — опис проєкту;

DB_TBL (ЗАСТАРІЛЕ) — корінь таблиць БД зі сторінками;

ICO — закодоване (Base64) зображення іконки проєкту;

USER — ім'я власника проєкту;

GRP — ім'я групи користувачів проєкту;

PERMIT — права доступу до проєкту;

PER — період обчислення проєкту, у мілісекундах;

FLGS — прапорці проєкту;

STYLE — типовий стиль проєкту.

• ProjPages(OWNER, ID, ICO, PARENT, PROC, PROC_PER, FLGS, ATTRS, TIMESTAMP) — сторінки ID, що містяться у проєкті-сторінці OWNER.

OWNER — проєкт-сторінка — власник даної сторінки, у вигляді — "/AGLKS/so/1/gcadr";

ID — ідентифікатор сторінки;

ICO — закодоване (Base64) зображення іконки сторінки;

PARENT — адреса віджету основи, у вигляді /wlb_originals/wdg_Box;

PROC — внутрішня процедура та мова процедури сторінки;

PROC_PER — період обчислення процедури сторінки;

FLGS — прапорці типів сторінки;

ATTRS — перелік атрибутів сторінки, модифікованих користувачем;

TIMESTAMP — мітка часу останньої модифікації.

• ProjPageIO(IDW, ID, IDC, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL) — робочі атрибути сторінок, структура фактично збігається з таблицею "LibWidgetIO".
• ProjPageUserIO(IDW, ID, IDC, NAME, IO_TP, IO_VAL, SELF_FLG, CFG_TMPL, CFG_VAL) — користувацькі атрибути сторінок, структура фактично збігається з таблицею "LibWidgetUserIO".
• ProjPageWIncl(IDW, ID, PARENT, ATTRS) — віджети, включені на сторінки, структура фактично збігається з таблицею "LibWidgetIncl".
• ProjMime(ID, MIME, DATA) — audio, video, media та інші ресурси сторінок проєктів, структура фактично збігається з таблицею "LibWidgetMime".
• PrjStls(SID, ID, VAL) — значення VAL поля ID стилю SID проєкту.

IDS — ідентифікатор стилю;

ID — ідентифікатор поля стилю;

VAL — значення поля стилю.

• PrjStl(ID, V_0, V_1, V_2, V_3, V_4, V_5, V_6, V_7, V_8, V_9) — значення поля стилю ID проєкту.

ID — ідентифікатор поля стилю;

V_{N} — значення поля стилю для стилю N.

• ProjSess(IDW, ID, IO_VAL) — таблиця проєкту IDW для збереження даних сеансів, що виконують проєкт.

IDW — повний шлях елементу проєкту;

ID — атрибут елементу;

IO_VAL — значення атрибуту.

3.11 API користувацького програмування

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

Об'єкт "Сеанс" ( this.ownerSess() )

• string user( ) — поточний користувач сеансу.
• int alrmQuietance( int quit_tmpl, string wpath = "", bool ret = false ) — стишує порушення wpath з шаблоном quit_tmpl. Якщо wpath це порожній рядок то здійснюється глобальне стишення. У рядку wpath, через символ ';', може бути перелічено адреси декількох віджетів. При встановлені ret здійснюється повернення стишення.
• int reqTm( ) — час останнього запиту у секундах від епохи 1.1.1970.
• string reqUser( ) — користувач останнього запиту.
• string reqLang( ) — мова останнього запиту.
• int userActTm( ) — час останньої дії користувача у секундах від епохи 1.1.1970.
• bool uiCmd( string cmd, string prm, string src ) — надсилає UI команду керування сторінками, як то: "open", "next", "prev"; детальніше дивиться у секції подій. Ця функція має бути пріоритетною для використання у керуванні сторінками перед прямим записом до атрибутів сторінок "pgOpen" та "pgOpenSrc", оскільки це єдиний метод коректної поводження з лінкованими сторінками.
• int period( bool isReal = false ) — отримання періоду опрацювання сеансу, isReal для реального періоду.

Об'єкт "Віджет" (this)

• TCntrNodeObj ownerSess( ) — об'єкт сеансу даного віджету.
• TCntrNodeObj ownerPage( ) — об'єкт батьківської сторінки даного віджету.
• TCntrNodeObj ownerWdg( bool base = false ) — об'єкт батьківського віджету даного віджету. При указанні base буде повернено й об'єкти сторінок.
• TCntrNodeObj wdgAdd( string wid, string wname, string parent ) — додає віджет wid з ім'ям wname на основі бібліотечного віджету parent.

//Додає новий віджет на основі віджету текстового примітиву
nw = this.wdgAdd("nw", "Новий віджет", "/wlb_originals/wdg_Text");
nw.attrSet("geomX", 50).attrSet("geomY", 50);

• bool wdgDel( string wid ) — видаляє віджет wid.
• TCntrNodeObj wdgAt( string wid, bool byPath = false ) — підключається до дочірнього або глобального віджету, за посередництвом шляху byPath. У випадку глобального підключення можна використати абсолютний або відносний шлях до віджету. Точкою відліку абсолютної адреси виступає об'єкт кореня модуля "VCAEngine", а значить, першим елементом абсолютної адреси є ідентифікатор сеансу, який опускається. Відносна адреса бере відлік від поточного віджету. Спеціальним елементом відносної адреси є елемент вищестоящого вузла "..".
• Array attrList() — перелік атрибутів віджету.
• bool attrPresent( string attr ) — перевіряє атрибут віджета attr на факт присутності.
• ElTp attr( string attr, bool fromSess = false ) — значення атрибуту віджету attr або з сеансу fromSess. Для відсутніх атрибутів повертає порожній рядок.
• TCntrNodeObj attrSet( string attr, ElTp vl, bool toSess = false ) — встановлює значення vl у атрибут віджету attr або сеанс, для toSess. Повертає поточний об'єкт, для конкатенації функцій встановлення.
• string link( string attr, bool prm = false ) — посилання атрибуту віджету attr. При встановленні prm запитує посилання групи атрибутів (параметр), представлене вказаним атрибутом.
• string linkSet( string attr, string vl, bool prm = false ) — встановлює посилання атрибуту віджету attr. При встановленні prm здійснює встановлення посилання групи атрибутів (параметр), представленого вказаним атрибутом.

//Встановлює посилання восьмого тренду параметром
this.linkSet("el8.name", "prm:/LogicLev/experiment/Pi", true);

• string {resource,mime}( string addr, string MIME = "" ) — ресурс об'єкту за адресою addr (пряме посилання на ресурс або атрибут віджету з цим посиланням) з типом MIME, з таблиці сеансу або джерела. Призначено для редагування ресурсу об'єкта та підставлення його у контексті сеансу, наприклад, зображень SVG.
• int {resourceSet,mimeSet}( string addr, string data, string MIME = "" ) — встановлює ресурс об'єкту у data з типом MIME за адресою addr.
• int messDebug( string mess ); int messInfo( string mess ); int messNote( string mess ); int messWarning( string mess ); int messErr( string mess ); int messCrit( string mess ); int messAlert( string mess ); int messEmerg( string mess ); — формує повідомлення програми mess з категорією — шлях до даного віджету.
• int calcPer( int set = EVAL ) — отримання, та встановлення за set не EVAL, щодо актуального періоду обчислення-опрацювання. Зарезервовано наступні спеціальні значення:
  • 0 — якщо бажаєте періодичного опрацювання сеансу;
  • -1 — якщо бажаєте використати період опрацювання батьківського віджету/сторінки/проєкту каскадно;
  • -2 — для цілковитого вимкнення періодичного опрацювання.
  • -3 — відсутній період часу сеансу, отримання проєктного.

Об'єкт "Віджет", примітиву "Документ" (this)

• string getArhDoc( int nDoc) — текст документу архіву на глибині nDoc (0-{aSize-1}).

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

Перелік віджетів (WdgList)
Опис: Повертає перелік віджетів, у контейнері віджетів, або дочірніх віджетів. Якщо встановлено pg, то повертається перелік сторінок проєктів та сеансу.
Параметри:

Присутність вузла (NodePresent)
Опис: Перевірка вузла на присутність, включаючи віджети, атрибути та інше.
Параметри:

Перелік атрибутів (AttrList)
Опис: Повертає перелік атрибутів віджету. Якщо встановлено noUser тоді повертаються тільки атрибути не користувача.
Параметри:

Отримати атрибут (AttrGet)
Опис: Отримання значення атрибуту віджета. Запит може здійснюватися як указанням повної адреси атрибуту у addr, так і окремо: адресу віджету у addr та ідентифікатор атрибута у attr.
Параметри:

Встановити атрибут (AttrSet)
Опис: Встановлення значення атрибуту віджета. Встановлення може здійснюватися як указанням повної адреси атрибуту у addr, так і окремо: адресу віджету у addr та ідентифікатор атрибута у attr.
Параметри:

Користувач сеансу (SesUser)
Опис: Повертає користувача сеансу за шляхом віджета сеансу.
Параметри:

3.12 Сервісні команди-функції Інтерфейсу Управління

Сервісні функції — це інтерфейс доступу до OpenSCADA із зовнішніх систем посередництвом Інтерфейсу Управління. Цей механізм покладено в основу усього обміну всередині OpenSCADA, реалізованого шляхом слабких зв'язків та власного протоколу обміну OpenSCADA.

Загальні віджети

Отримання значень визначених або всіх візуальних атрибутів віджету

ЗАП: <get path="/UI/VCAEngine/{wAddr}/%2fserv%2fattr">{attributes}</get>

• wAddr — локальна адреса віджету, на кшталт "/wlb_AGLKS/wdg_CM101/wdg_ElFigure1";
• attributes — лише запитані атрибути у тегах "el" із тільки одним атрибутом ідентифікатору "id"; можлива цілковита відсутність тегів атрибутів для запиту усіх наявних.

ВІДП: <get path="/UI/VCAEngine/{wAddr}/%2fserv%2fattr" rez="0">{attributes}</get>

• attributes — опрацьовувані атрибути у тегах "el": <el id="{ID}" p="{pos}" act="{active}">{value}</el>
  • ID — ідентифікатор атрибуту;
  • pos — позиція-індекс атрибуту для стандартних;
  • active — стан активності атрибуту, лише для прямого запиту;
  • value — значення атрибуту.

<get path="/UI/VCAEngine/wlb_AGLKS/wdg_CM101/wdg_ElFigure1/%2fserv%2fattr" rez="0" user="roman">
  <el id="id">ElFigure1</el>
  <el id="path">/wlb_AGLKS/wdg_CM101/wdg_ElFigure1</el>
  <el id="parent">/wlb_originals/wdg_ElFigure</el>
  <el id="owner">root:UI</el>
  <el id="perm">948</el>
  <el id="root" p="1">ElFigure</el>
  <el id="name" />
  <el id="dscr" />
</get>

Встановлення групи значень визначених атрибутів віджетів

ЗАП[root-UI]: <set path="/UI/VCAEngine/{wAddr}/%2fserv%2fattr">{attributes}</set>

• wAddr — локальна адреса віджету у модулі, на кшталт "/wlb_AGLKS/wdg_CM101/wdg_ElFigure1";
• attributes — атрибути зі значеннями у тегах "el": <el id="{ID}">{value}</el>
  • ID — ідентифікатор атрибуту;
  • value — встановлюване значення атрибуту.

<set path="/UI/VCAEngine/wlb_AGLKS/wdg_CM101/wdg_ElFigure1/%2fserv%2fattr">
  <el id="name">Нова назва</el>
  <el id="dscr">Новий опис</el>
</set>

Отримання значень візуальних атрибутів гілки віджетів, оптимізовано для мереж

ЗАП: <get path="/UI/VCAEngine/{wAddr}/%2fserv%2fattrBr" />

• wAddr — локальна адреса віджету у модулі, на кшталт "/wlb_AGLKS/wdg_CM101/wdg_ElFigure1".

ВІДП: <get path="/UI/VCAEngine/{wAddr}/%2fserv%2fattrBr" rez="0">{attributes} {widgets}</get>

• attributes — опрацьовані атрибути у тегах "el": <el id="{ID}" p="{pos}">{value}</el>
  • ID — ідентифікатор атрибуту;
  • pos — позиція-індекс атрибуту для стандартних;
  • value — значення атрибуту.
• widgets — дочірні віджети у тегах "w": <w id="{ID}" lnkPath="{lnkPath}">{attributes} {widgets}</w>
  • ID — ідентифікатор віджету;
  • lnkPath — шлях до пов'язаного віджету для дочірніх віджетів бібліотек віджетів.

<get path="/UI/VCAEngine/wlb_AGLKS/wdg_CM101/%2fserv%2fattrBr" rez="0" user="roman">
  <el id="id">CM101</el>
  <el id="path">/wlb_AGLKS/wdg_CM101</el>
  <el id="parent">/wlb_originals/wdg_Box</el>
  <el id="owner">root:UI</el>
  <el id="perm">948</el>
  <el id="root" p="1">Box</el>
  <el id="name">КМ101</el>
  <w id="AT101_1" lnkPath="/wlb_mnEls/wdg_cooler">
    <el id="id">AT101_1</el>
    <el id="path">/wlb_AGLKS/wdg_CM101/wdg_AT101_1</el>
    <el id="parent">/wlb_mnEls/wdg_cooler</el>
    <el id="owner">root:UI</el>
    <el id="perm">948</el>
    <el id="root" p="1">ElFigure</el>
    <el id="name">АТ101 1</el>
  </w>
</get>

Бібліотеки віджетів

Отримання дерева віджетів бібліотек, оптимізовано для мереж

ЗАП: <get path="/UI/VCAEngine/%2fserv%2fwlbBr" item="{item}" disIconsW="{disIconsW}" disIconsCW="{disIconsCW}" />

• item — елемент бібліотеки отримання, як шлях "wlb_{WLib}[/wdg_{Wdg}[/wdg_{ChildWdg}]]", для порожнього отримуватиметься все дерево;
• disIconsW — вимкнути отримання даних іконки для віджетів [0|1];
• disIconsCW — вимкнути отримання даних іконки для дочірніх віджетів [0|1].

ВІДП: <get path="/UI/VCAEngine/%2fserv%2fwlbBr" item="{item}" disIconsW="{disIconsW}" disIconsCW="{disIconsCW}" rez="0">{wlibs}</get>

• wlibs — бібліотеки віджетів у тегах "wlb": <wlb id="{ID}" doc="{doc}">{name} {icon} {widgets}</wlb>
  • icon — тег "icon" із даними цієї іконки кодоване Base64;
  • widgets — теги "w" із описом бібліотек віджетів: <w id="{ID}" doc="{doc}" parent="{parent}">{name} {icon} {widgets}</w>
    • parent — адреса батька віджету;
    • widgets — теги "сw" із описом дочірніх віджетів: <cw id="{ID}" doc="{doc}">{name} {icon}</cw>

<get disIconsCW="1" disIconsW="1" item="/wlb_AGLKS" path="/UI/VCAEngine/%2fserv%2fwlbBr" rez="0" user="roman">
  <wlb id="AGLKS">АГЛКС
    <ico>iVBORw0KGgoAA...AAAElFTkSuQmCC</ico>
    <w id="CM101" parent="/wlb_originals/wdg_Box">КМ101
      <cw id="AT101_1">АТ101 1</cw>
      <cw id="AT101_2">АТ101 1</cw>
      <cw id="C101_1">C101/1</cw>
      <cw id="C101_2">C101/1</cw>
      <cw id="C101_3">C101/1</cw>
      <cw id="CM101">CM101</cw>
      <cw id="CM101_1">CM101_1</cw>
      <cw id="CM101_2">CM101_2</cw>
      <cw id="ElFigure1">ElFigure1</cw>
      <cw id="ElFigure2">ElFigure2</cw>
      <cw id="ElFigure3">ElFigure3</cw>
      <cw id="ElFigure4">ElFigure4</cw>
      <cw id="ElFigure5">ElFigure5</cw>
      <cw id="ElFigure6">ElFigure6</cw>
      <cw id="ElFigure7">ElFigure7</cw>
    </w>
    <w id="KCH_MN1" parent="/wlb_originals/wdg_Box">KCH_MN1
      <cw id="BC1">Кульовий кран</cw>
      <cw id="BC2">Кульовий кран</cw>
      <cw id="BC21">Кульовий кран</cw>
      <cw id="BC22">Кульовий кран</cw>
    </w>
    <w id="comprEn" parent="/wlb_originals/wdg_ElFigure">Робота компресора</w>
  </wlb>
</get>

Проєкти СВУ

Отримання переліку проєктів розширене деякими опціями

ЗАП: <get path="/UI/VCAEngine/[%2fbr%2fprj_|%2fprm%2fcfg%2fprj]" chkUserPerm="{chkUserPerm}" getChPgN="{getChPgN}" noName="{noName}" />

• chkUserPerm — перевірка прав користувача перед включенням до переліку [0|1];
• getChPgN — запит кількості дочірніх сторінок у проєктах [0|1];
• noName — не повертати назви сторінок [0|1].

ВІДП: <get path="/UI/VCAEngine/[%2fbr%2fprj_|%2fprm%2fcfg%2fprj]" chkUserPerm="{chkUserPerm}" getChPgN="{getChPgN}" noName="{noName}" rez="0">{projects}</get>

• projects — перелік проєктів у тегах "el", де назва у тексті тегу та ідентифікатор у атрибуті "id". Розширено додатковими атрибутами:
  • "chPgN" — кількість дочірніх сторінок у проєкті за встановлення "getChPgN".

<get getChPgN="1" path="/UI/VCAEngine/%2fbr%2fprj_" rez="0" user="roman">
  <el chPgN="2" id="AGLKS">АГЛКС</el>
  <el chPgN="2" id="archBrowser">Огляд архівів</el>
  <el chPgN="2" id="tmplSO">Групи сигналізації (шаблон)</el>
</get>

Перевірка доступу на читання проєкту від користувача запиту

ЗАП: <read path="/UI/VCAEngine/prj_{proj}/%2fserv%2faccess" />

• proj — ідентифікатор проєкту.

ВІДП: <read path="/UI/VCAEngine/prj_{proj}/%2fserv%2faccess" rez="0">{access}</get>

• access — статус наявності доступу [0|1].

<read path="/UI/VCAEngine/prj_AGLKS/%2fserv%2faccess" rez="0" user="roman">1</read>

Сеанси проєктів

Отримання переліку сеансів розширене деякими параметрами

REQ: <get path="/UI/VCAEngine/[%2fbr%2fses_|%2fses%2fses]" chkUserPerm="{chkUserPerm}" onlyMy="{onlyMy}" />

• chkUserPerm — перевірка прав користувача перед доданням до переліку [0|1];
• onlyMy — додавати до переліку лише мої власні сеанси [0|1].

RESP: <get path="/UI/VCAEngine/[%2fbr%2fses_|%2fses%2fses]" chkUserPerm="{chkUserPerm}" onlyMy="{onlyMy}" rez="0">{sessions}</get>

• sessions — перелік сеансів у тегах "el", де ідентифікатор у тексті тегу. Розширено додатковими атрибутами:
  • "user" — користувач сеансу;
  • "proj" — проєкт сеансу.

<get path="/UI/VCAEngine/%2fses%2fses" rez="0" onlyMy="1" user="roman">
  <el user="roman" proj="AGLKS">AGLKS</el>
  <el user="roman" proj="AGLKS">AGLKS0</el>
</get>

Отримання переліку сеансів визначеного проєкту СВУ

ЗАП: <list path="/UI/VCAEngine/%2fserv%2fsess" prj="{project}" />

• project — ідентифікатор запитаного проєкту.

ВІДП: <list path="/UI/VCAEngine/%2fserv%2fsess" prj="{project}" rez="0">{sessions}</list>

• sessions — сеанси у тегах "el".

<list path="/UI/VCAEngine/%2fserv%2fsess" prj="AGLKS" rez="0" user="roman">
  <el>AGLKS</el>
</list>

Підключення до визначеного проєкту СВУ або сеансу проєкту

ЗАП: <connect path="/UI/VCAEngine/%2fserv%2fsess" prj="{project}" sess="{session}" userChange="{userChange}" onlyMy="{onlyMy}" />

• project — ідентифікатор запитаного проєкту, порожнє при підключені до наявного сеансу;
• session — ідентифікатор вже наявного сеансу, порожнє для створення нового сеансу;
• onlyMy — ознака підключення-перепідключення до сеансу лише якщо він мій;
• userChange — ознака зміни користувача [0|1], тобто для оновлення інформації користувача.

ВІДП: <connect path="/UI/VCAEngine/%2fserv%2fsess" prj="{project}" sess="{session}" userChange="{userChange}" onlyMy="{onlyMy}" rez="0" conId="{conId}" userIsRoot="{userIsRoot}" />

• conId — ідентифікатор підключення сеансу, використовується у подальших запитах;
• project — ідентифікатор проєкту успішно підключеного сеансу;
• session — ідентифікатор новоствореного сеансу успішно підключеного проєкту;
• userIsRoot — користувач має права суперкористувача [0|1].

<connect conId="50860885" path="/UI/VCAEngine/%2fserv%2fsess" prj="AGLKS" rez="0" sess="AGLKS" user="roman" userIsRoot="1" />

Відключення від визначеного сеансу проєкту СВУ

Сеанси із нульовою кількістю підключень тут також закриваються.

ЗАП: <disconnect path="/UI/VCAEngine/%2fserv%2fsess" sess="{session}" conId="{conId}" />

• session — ідентифікатор наявного сеансу;
• conId — ідентифікатор підключення сеансу.

<disconnect path="/UI/VCAEngine/%2fserv%2fsess" sess="AGLKS" conId="50860885" />

Отримання переліку відкритих сторінок сеансу проєкту

ЗАП[{owner}-{grp}]: <openlist path="/UI/VCAEngine/ses_{session}/%2fserv%2fpg" conId="{conId}" tm="{clock}" />

• owner, grp — доступ на читання для власника проєкту або користувача у групі та відповідно до прав проєкту;
• session — ідентифікатор сеансу;
• conId — ідентифікатор підключення сеансу;
• clock — значення внутрішнього лічильника (цикл життя) від попереднього опрацьованого запиту, для перевірки змінених.

ВІДП: <openlist path="/UI/VCAEngine/ses_{session}/%2fserv%2fpg" conId="{conId}" tm="{clock}" rez="0">{pages}</openlist>

• clock — значення внутрішнього лічильника (цикл життя) - 1 на час запиту;
• pages — сторінки у тегах "pg": <pg pgGrp="{pgGrp}" updWdg="{nUpdWdgs}">{ID}</pg>
  • ID — ідентифікатор сторінки;
  • pgGrp — група сторінок для раннього обчислення включення сторінок;
  • nUpdWdgs — кількість оновлених віджетів після останнього запиту та для непорожнього "clock".

<openlist conId="52760577" path="/UI/VCAEngine/ses_AGLKS/%2fserv%2fpg" rez="0" tm="1403" user="roman">
  <pg>/ses_AGLKS/pg_so</pg>
  <pg pgGrp="so">/ses_AGLKS/pg_so/pg_1/pg_mn/pg_1</pg>
  <pg pgGrp="cntr">/ses_AGLKS/pg_control/pg_ElCadr</pg>
</openlist>

Відкриття або закриття визначеної сторінки сеансу проєкту

ЗАП[{owner}-{grp}]: <[open|close] path="/UI/VCAEngine/ses_{session}/%2fserv%2fpg" pg="{page}" />

• owner, grp — доступ на запис для власника проєкту або користувача у групі та відповідно до прав проєкту;
• session — ідентифікатор сеансу;
• page — адреса сторінки у контексті сеансу, на кшталт "/ses_AGLKS/pg_so/pg_1/pg_mn/pg_1".

Отримання статусу сигналізації та ресурсу сповіщення для сеансу проєкту

ЗАП[{owner}-{grp}]: <get path="/UI/VCAEngine/ses_{session}/%2fserv%2falarm" mode="{mode}" tp="{typeNtf}" wdg="{widget}" />

• owner, grp — доступ на читання для власника проєкту або користувача у групі та відповідно до прав проєкту;
• session — ідентифікатор сеансу;
• mode — режим запиту, лише "resource" для отримання ресурсів сповіщення та пусто тільки статус;
• typeNtf — тип сповіщення для отримання ресурсу, дивіться секцію сигналізації;
• widget — адреса віджету для формування ресурсу сповіщення, порожньо для глобального.

ВІДП: <get path="/UI/VCAEngine/ses_{session}/%2fserv%2falarm" mode="{mode}" tp="{typeNtf}" rez="0" alarmSt="{alarmSt}" tm="{clock}" wdg="{widget}" resTp="{resTp}" mess="{message}" lang="{language}">{resource}</get>

• alarmSt — статус сигналізації як описано у секції сигналізації;
• clock — значення внутрішнього лічильника (цикл життя) при формуванні ресурсу сповіщення;
• widget — адреса віджету джерела при формуванні ресурсу сповіщення;
• message — повідомлення сповіщення із тексту;
• language — мова сповіщення, переважно для "message";
• resTp — тип ресурсу сповіщення;
• resource — ресурс сповіщення кодований Base64 для бінарних даних.

<get path="/UI/VCAEngine/ses_AGLKS/%2fserv%2falarm" mode="resource" tp="1" rez="0" user="roman"
     alarmSt="460554" tm="0" resTp="audio/ogg;73.3428" lang="en_US.UTF-8">
T2dnUwACA...Dg6gwAjo+PAQ==
</get>

Стишення-квітація сповіщення сигналізації сеансу проєкту

ЗАП[{owner}-{grp}]: <quietance path="/UI/VCAEngine/ses_{session}/%2fserv%2falarm" wdg="{widget}" tmpl="{template}" ret="{return}" />

• owner, grp — доступ на читання для власника проєкту або користувача у групі та відповідно до прав проєкту;
• session — ідентифікатор сеансу;
• widget — адреса віджету для стишення сповіщення, пусто для глобального;
• template — шаблон сповіщення, тобто бітова збірка відповідно до типів стишуваних сповіщень;
• return — ознака повернення сповіщення, тобто стишення вимикається.

<quietance path="/UI/VCAEngine/ses_AGLKS/%2fserv%2falarm" tmpl="7" />

Отримання значень модифікованих візуальних атрибутів віджету сеансу

Перевизначає загальний сервісний запит віджетів "<get path='/UI/VCAEngine/{wAddr}/%2fserv%2fattr' />" щодо специфіки сеансу.

ЗАП: <get path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattr" tm="{clock}" />

• wAddr — локальна адреса віджету сеансу, на кшталт "/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1";
• clock — значення внутрішнього лічильника (цикл життя) від попереднього опрацьованого запиту, для перевірки змінених; за нульового значення примусово додаються сервісні-віртуальні атрибути: "perm", "name".

ВІДП: <get path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattr" tm="{clock}" rez="0">{attributes}</get>

• attributes — модифіковані від "clock" атрибути у тегах "el": <el id="{ID}" p="{pos}">{value}</el>
  • ID — ідентифікатор атрибуту;
  • pos — позиція-індекс атрибуту для стандартних;
  • value — значення атрибуту.

<get path="/UI/VCAEngine/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1/%2fserv%2fattr" rez="0" tm="0" user="roman">
  <el id="perm" p="-3">6</el>
  <el id="root" p="1">ElFigure</el>
  <el id="en" p="5">1</el>
  <el id="active" p="6">0</el>
  <el id="geomX" p="7">488</el>
  <el id="geomY" p="8">250</el>
  <el id="geomW" p="9">16</el>
  <el id="geomH" p="10">100</el>
  <el id="geomXsc" p="13">1</el>
  <el id="geomYsc" p="14">0.75</el>
  <el id="geomZ" p="11">-9</el>
</get>

Встановлення групи значень визначених атрибутів віджету сеансу

Перевизначає загальний сервісний запит віджетів "<set path='/UI/VCAEngine/{wAddr}/%2fserv%2fattr' />" щодо специфіки сеансу на кшталт опрацювання атрибуту "event" та виявлення активності-неактивності користувача.

ЗАП[{owner}-{grp}]: <set path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattr" noUser="{noUser}">{attributes}</set>

• owner, grp — доступ на запис для власника проєкту або користувача у групі та відповідно до прав проєкту;
• wAddr — локальна адреса віджету сеансу, на кшталт "/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1";
• noUser — не маркувати це як активність користувача;
• attributes — атрибути зі значеннями у тегах "el": <el id="{ID}">{value}</el>
  • ID — ідентифікатор атрибуту;
  • value — встановлюване значення атрибуту.

<set path="/UI/VCAEngine/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1/%2fserv%2fattr">
  <el id="name">Нова назва</el>
  <el id="dscr">Новий опис</el>
</set>

Активація атрибуту для використання у якості візуального та його створення за відсутності

ЗАП: <activate path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattr%2f{aID}" aNm="{aName}" aTp="{aType}" aFlg="{aFlags}" aVls="{aValues}" aNms="{aNames}">{aDef}</activate>

• wAddr — локальна адреса віджету сеансу, на кшталт "/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1";
• aID — ідентифікатор атрибуту сеансу;
• aName — ім'я атрибуту при його створені;
• aType — тип атрибуту при його створені, дивіться об'єкт TFld;
• aFlags — прапорці атрибуту при його створені, дивіться об'єкт TFld;
• aDef — типове значення атрибуту при його створені;
• aValues — значення атрибуту для вибіркових типів при його створені;
• aNames — назви значень атрибуту для вибіркових типів при його створені.

<activate path="/UI/VCAEngine/ses_AGLKS/pg_so/%2fserv%2fattr%2frunWin" aNm="Вікно виконання" aTp="1" aFlg="1" aVls="0;1;2" aNms="Original size;Maximize;Full screen">0</activate>

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

Перевизначає загальний сервісний запит віджетів "<get path='/UI/VCAEngine/{wAddr}/%2fserv%2fattrBr' />" щодо специфіки сеансу.

ЗАП: <get path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattrBr" tm="{clock}" FullTree="{FullTree}" />

• wAddr — локальна адреса віджету сеансу, на кшталт "/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1";
• clock — значення внутрішнього лічильника (цикл життя) від попереднього опрацьованого запиту, для перевірки змінених; за нульового значення примусово додаються сервісні-віртуальні атрибути: "perm", "name".
• fullTree — отримання повного дерева віджетів незалежно від наявності змін, без атрибутів.

ВІДП: <get path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattrBr" tm="{clock}" FullTree="{FullTree}" rez="0">{attributes} {widgets}</get>

• attributes — опрацьовані атрибути у тегах "el": <el id="{ID}" p="{pos}">{value}</el>
  • ID — ідентифікатор атрибуту;
  • pos — позиція-індекс атрибуту для стандартних;
  • value — значення атрибуту.
• widgets — дочірні віджети у тегах "w": <w id="{ID}">{attributes} {widgets}</w>
  • ID — ідентифікатор віджету.

<get path="/UI/VCAEngine/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/%2fserv%2fattrBr" rez="0" tm="0" user="roman">
  <el id="name" p="-4">CM101</el>
  <el id="perm" p="-3">6</el>
  <el id="root" p="1">Box</el>
  <el id="en" p="5">1</el>
  <el id="active" p="6">0</el>
  <el id="geomX" p="7">0</el>
  <el id="geomY" p="8">0</el>
  <el id="geomW" p="9">900</el>
  <el id="geomH" p="10">580</el>
  <w id="AT101_1">
    <el id="perm" p="-3">6</el>
    <el id="root" p="1">ElFigure</el>
    <el id="en" p="5">1</el>
    <el id="active" p="6">0</el>
    <el id="geomX" p="7">338</el>
    <el id="geomY" p="8">320</el>
    <el id="geomW" p="9">80</el>
    <el id="geomH" p="10">100</el>
  </w>
</get>

Отримання значення специфічного до сеансу атрибуту віджету сеансу

ЗАП: <get path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattrSess%2f{aID}" />

• wAddr — локальна адреса віджету сеансу, на кшталт "/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1";
• aID — ідентифікатор специфічного до сеансу атрибуту.

ВІДП: <get path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattrSess%2f{aID}" rez="0">{value}</get>

• value — значення атрибуту.

<get path="/UI/VCAEngine/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/%2fserv%2fattrSess%2ftestA" rez="0" user="roman">тестове значення</get>

Встановлення значення специфічного до сеансу атрибуту віджету сеансу

ЗАП[{owner}-{grp}]: <set path="/UI/VCAEngine/ses_{wAddr}/%2fserv%2fattrSess%2f{aID}">{value}</get>

• owner, grp — доступ на запис для власника проєкту або користувача у групі та відповідно до прав проєкту;
• wAddr — локальна адреса віджету сеансу, на кшталт "/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/wdg_ElFigure1";
• aID — ідентифікатор специфічного до сеансу атрибуту;
• value — значення атрибуту.

<set path="/UI/VCAEngine/ses_AGLKS/pg_so/pg_2/pg_mn/pg_CM101/%2fserv%2fattrSess%2ftestA">тестове значення</set>

4 Конфігурація модуля за посередництвом інтерфейсу управління OpenSCADA

За посередництвом інтерфейсу управління OpenSCADA компоненти, які його використовують, можна конфігурувати з будь-якого конфігуратору OpenSCADA. Даним модулем надається інтерфейс доступу до всіх об'єктів даних СВУ. Головна вкладка конфігураційної сторінки модуля надає доступ до бібліотек віджетів та проєктів (рис.4.1). Вкладка "Сеанси" надає доступ до відкритих сеансів проєктів (рис.4.2).

Рис.4.1. Головна конфігураційна сторінка модуля.

Рис.4.2. Вкладка "Сеанси" конфігураційної сторінки модуля.

Крім переліку відкритих сеансів, вкладка на рисунку 4.2 містить таблицю з переліком сеансів, які мають створюватися та запускатися у момент завантаження OpenSCADA. Створення сеансів за посередництвом цього механізму може бути корисним для Web-інтерфейсу. У такому випадку, при підключені Web-користувача, всі дані вже готові та забезпечується неперервність формування архівних документів.

Конфігурація контейнерів віджетів у особі бібліотек віджетів та проєктів виконується за посередництвом сторінок на рисунку 4.3 (для проєкту) та рисунку 4.5 (для бібліотеки віджетів). Бібліотека віджетів містить віджети, а проєкт — сторінки. Обидва типи контейнеру містять вкладку конфігурації ресурсів, що використовуються віджетами (рис.4.6). Сторінка проєкту також містить вкладку "Діагностика" (рис.4.4) для налагодження та контролю за виконанням сторінки у сеансах.

Рис.4.3. Сторінка конфігурації проєктів.

За допомогою цієї сторінки можна встановити:

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

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

• Ідентифікатор, ім'я, опис та іконка контейнеру.
• Власник, група користувачів та права доступу до елементу.
• Період обчислення сеансів, заснованих на даному проєкті.
• Ознака увімкнення за потреби.

Рис.4.4. Вкладка "Діагностика" проєкту.

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

Рис.4.5. Сторінка конфігурації бібліотек віджетів.

За допомогою цієї сторінки можна встановити:

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

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

• Ідентифікатор, ім'я, опис та іконка контейнеру.

Рис.4.6. Вкладка конфігурації ресурсів контейнеру.

Конфігурація сеансу проєкту значно відрізняється від конфігурації проєкту (рис.4.7), однак, також, містить сторінки проєкту.

Рис.4.7. Сторінка конфігурації сеансів проєктів.

За допомогою цієї сторінки можна встановити:

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

Сторінки конфігурації візуальних елементів, розташованих у різних контейнерах, можуть сильно відрізнятися, однак, ця різниця полягає у наявності або відсутності окремих вкладок. Головна вкладка візуальних елементів фактично всюди однакова, відрізняючись на одне конфігураційне поле та три у сеансі (рис.4.8). У сторінок присутні вкладки дочірніх сторінок та вкладених віджетів. У контейнерних віджетів міститься вкладка вкладених віджетів. Всі візуальні елементи містять вкладку атрибутів (рис.4.9), крім логічних контейнерів проєктів. Елементи, на рівні яких можна формувати користувацьку процедуру та визначати зв'язки, містять вкладки "Обробка" (рис.4.10) та "Зв'язки" (рис.4.11). Рядки ім'я атрибуту у вкладці "Обробка" після першого опрацьовуються як допомога.

Рис.4.8. Головна вкладка конфігурації візуальних елементів.

За допомогою цієї сторінки можна отримати:

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

Рис.4.9. Вкладка атрибутів візуальних елементів.

Рис.4.10. Вкладка обробки візуальних елементів.

Рис.4.11. Вкладка зв'язків візуальних елементів.