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

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

Автор: Роман Савоченко, Максим Лисенко (2010-2012)

Contents

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

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

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

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

Документ будується синхронно до реалізації прикладів на підключені до демонстраційної бази даних (БД) моделі "АГЛКС" у ролі джерела даних — ПЛК. Відповідно, користувач має отримати дистрибутив OpenSCADA з цією БД, про що детальніше у розділі "Встановлення"!

1 Терміни, визначення та абревіатури

1.1 Терміни та визначення

  • Qt — інструментарій розробки ПЗ, за допомогою якого, зокрема, створено модулі QTStarter (пускач модулів OpenSCADA на бібліотеці Qt), QTCfg (графічний конфігуратор OpenSCADA) та Vision (редактор та виконавець робочих користувацьких інтерфейсів СВУ). Може зустрічатися у вигляді QT, що є раннім записом, використаною розробниками OpenSCADA для бібліотеки Qt.
  • Блокування — умовна границя технологічного параметру по подоланню якої здійснюються передбачені алгоритмом дії із запобігання аварії. У деяких режимах ТП (пуск), у відповідності з регламентом, може знадобитися відключення блокування — деблокування.
  • Віджет СВУ — елемент візуалізації СВУ.
  • Деблокування — процес вимкнення блокування на час роботи ТП у режимах для яких у регламенті передбачена дана операція. Деблокування технологічних параметрів є суворо звітною операцією та має відбуватися оперативним персоналом у відповідному порядку!
  • Кадр СВУ — похідний елемент візуалізації, який складається із базових елементів та спроможний виконувати функції сторінки проекту СВУ.
  • Квітація — процес підтвердження факту того, що оперативний персонал звернув увагу на порушення у роботі ТП. Зазвичай цей процес передбачає вживання заходів оператором для усунення порушення та натискання відповідної кнопки припинення сигналізації.
  • Комплексний параметр-тег або об'єкт-тег сигналу — деталізований сигнал джерела даних як вичерпний параметр-тег, що для аналогового зазвичай містить:
    • значення сигналу у інженерній-реальній одиниці виміру;
    • назва одиниці виміру;
    • шкала-діапазон фізичної зміни значення сигналу — мінімальна та максимальна границі;
    • шкали границь сигналізації — зазвичай це верхня та нижня границі для попереджувальної та аварійної сигналізації;
    • параметри фільтру;
    • параметри особливостей шкали, визначення достовірності, формату представлення та інше.
  • Модель даних — організація та структурування даних технологічного процесу (ТП) або іншого об'єкту автоматизації у шарі джерела даних SCADA, протоколу обміну або ПЛК. По замовченню мається на увазі шар джерела даних OpenSCADA зі структурою "Об'єкт контролеру" -> "Параметр, рівень 1" -> ... "Параметр, рівень N" -> "Атрибут значення - сигнал".
  • Проект — даний термін має багато значень та, залежно від контексту, може матися на увазі:
    • Проект (програма) OpenSCADA — вільне програмне забезпечення, документацію якого Ви наразі читаєте.
    • Визначений набір-тека з конфігурацією та даними, які створюються користувачем OpenSCADA, де конфігурація зберігається у конфігураційному файлі (обов'язково) та одному або декількох файлах БД (необов'язково та може бути у мережі). Наприклад — демонстраційний проект, модель ТП "АГЛКС". Тобто, автором проекту виступає користувач програми — інженер-розробник або програміст SCADA системи.
    • Проект СВУ — складова середовища візуалізації та управління (СВУ), створювана у модулі UI.VCAEngine через UI.Vision та що містить набір кадрів СВУ.
  • Сигнал (стосовно джерела даних) — елемент джерела даних у вигляді виміряного, або вирахуваного, значення технологічного параметра або сенсору. Представляє із себе скаляр дискретного, цілого або реального типів, який часто кодується, масштабуванням шкали параметру у розмірність цілого. Сигнал, для ідентифікації, часто просто індексується або кодується за адресою його значення у карті протоколу обміну, а осмислену назву він набуває у моделі даних SCADA.
  • Сигналізація — процес повідомлення оперативного персоналу про порушення технологічного процесу або роботи обладнання автоматизації. Способи сигналізації можуть бути різних типів впливу на органи відчуттів людини, з метою привернення уваги. Часто передбачаються наступні типи сигналізації:
    • Світлова сигналізація — зазвичай здійснюється за посередництвом зміни кольору графічного об'єкта (блимання) для подій що виникли та встановленням статичних аварійних кольорів (червоний та жовтий) для сквітованих-підтверджених повідомлень.
    • Звукова — здійснюється видачею звукового сигналу на момент виникнення події. Тип звукового сигналу може бути як монотонним, так і синтезованим мовним повідомленням із інформацією про порушення.
  • Уставка сигналізації — умовна границя значення технологічного параметру, подолання якої вважається нештатною ситуацією. Зазвичай передбачаються наступні границі:
    • Верхня та нижня аварійні границі — границі аварійних значень технологічного параметру.
    • Верхня та нижня попереджувальні границі — границі попередження, регламентні границі, про вихід технологічного параметру за робочий діапазон.
    • Відмова — ознака виходу значення параметру за апаратні границі технологічного обладнання. Зазвичай характеризує відмову давача, обрив каналу зв'язку з давачем або ПЛК.

1.2 Вживані скорочення

  • API (англ. Application Programming Interface) — інтерфейс програмування додатків (модулів OpenSCADA) або розширень на внутрішній мові OpenSCADA — API користувача.
  • AWP (англ. Automated Work Place) — див. АРМ.
  • MOD (англ. Matching to Object Device) — див. ПУО.
  • DAQ (англ. Data Acquisition) — збір даних.
  • DB (англ. Data Base) — див. БД.
  • DCON — найменування одного з комунікаційних протоколів, який використовується у промисловості.
  • GPL (англ. General Public License) — відкрита ліцензійна угода (ліцензія), за умовами якого розповсюджується та може використовуватися OpenSCADA.
  • GUI (англ. Graphical User Interface) — графічний інтерфейс користувача.
  • HMI (англ. Human-machine Interface) — людино-машинний інтерфейс.
  • HTTP (англ. HyperText Transfer Protocol — "протокол передачі гіпертексту") — протокол прикладного рівня передачі даних, частіш за все у вигляді гіпертекстових документів.
  • ModBus — Modicon BUS це послідовний комунікаційний протокол, в варіантах RTU та ASCII, початково опублікований Modicon у 1979 для використання з власними ПЛК. Пізніше розширений для роботи поверх TCP-IP та цей варіант отримав назву ModBus/TCP.
  • PLC (англ. Programmable Logic Controller) — див. ПЛК.
  • QT — див. QT у переліку термінів, не є скороченням.
  • SCADA (англ. Supervisory Control And Data Acquisition) — диспетчерський контроль та збір даних.
  • TP (англ. Technological Process) — див. ТП.
  • TUI (англ. Terminal(Text) User Interface) — термінальний (текстовий) інтерфейс користувача.
  • UI (англ. User Interface) — інтерфейс користувача.
  • VCA (англ. Visual Control Area) — див. СВУ.


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

2 Встановлення OpenSCADA

Встановлення OpenSCADA, загалом, можна здійснити двома способами. Перший та простий спосіб — це отримати готові пакети для використаного дистрибутиву ОС Linux. Другий — зібрати OpenSCADA з вихідних текстів.

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

Якщо у користувача викликає труднощі встановлення не тільки OpenSCADA, але й дистрибутиву Linux, то, на перший час, він може скористатися "живим" дистрибутивом Linux з встановленою та готовою до роботи та вивчення демонстрацією та повноцінною OpenSCADA. Якщо його влаштує таке оточення швидкої доступності то він може зупинити свій вибір на ньому та встановити. На цей час доступні "живі" збірки на основі дистрибутиву Debian та ALTLinux (застаріле) у вигляді гібридних CD/DVD/USB-штампів, на сторінці: http://oscada.org/ua/golovna/zavantazhiti/. Детальніше дивіться у документі рецепту (How to ...) "Живий диск (Live CD/DVD/USB)".

2.1 Встановлення OpenSCADA з готових пакетів

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

Перевірити наявність пакетів OpenSCADA у репозиторіях дистрибутивів Linux або OpenSCADA, а також завантажити пакети OpenSCADA для ручного встановлення, можна на сторінці завантаження офіційного сайту OpenSCADA (http://oscada.org/ua/golovna/zavantazhiti/). Тут Ви також можете отримати конфігурацію для підключення репозиторіїв пакетів OpenSCADA до пакетного менеджеру вашого дистрибутиву Linux.

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

2.1.1 Додавання репозиторію пакетів та встановлення OpenSCADA з нього

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

Адреси репозиторіїв та конфігурацію менеджеру репозиторіїв Ви можете отримати на тій самій сторінці завантаження OpenSCADA (http://oscada.org/ua/golovna/zavantazhiti/) або в прикладах нижче.

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

  • openscada-model-aglks, openscada-model-boiler — проекти динамічних моделей технологічних процесів, які за сумісництвом виконують функцію демонстрації OpenSCADA;
  • openscada-vis-station — шаблонний проект SCADA станції, зазвичай — запуск у графічному інтерфейсі та без Web;
  • openscada-server — шаблонний проект серверу SCADA, що запускається у фоновому режимі — режим демону;
  • openscada-plc — шаблонний проект ПЛК, що запускається у фоновому режимі — режим демону;
  • openscada — типове-повне встановлення OpenSCADA.

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

Репозиторії пакетів, основані на менеджері APT (Debian, Ubuntu, ALTLinux) — додаються розташуванням завантаженого файлу "openscada.list" до теки "/etc/apt/sources.list.d" або редагуванням файлу /etc/apt/sources.list, вставкою одного рядка:
Debian: "deb http://ftp.oscada.org/OpenSCADA/0.9.0/Debian/9 ./"
Debian (робоча версія): "deb http://ftp.oscada.org/OpenSCADA/Work/Debian/9 ./"
Debian (робоча версія, модулі окремо): "deb http://ftp.oscada.org/Debian/9/openscada ./"
Ubuntu: "deb http://ftp.oscada.org/OpenSCADA/0.9.0/Ubuntu/16.04 ./"
Ubuntu (робоча версія): "deb http://ftp.oscada.org/OpenSCADA/Work/Ubuntu/16.04 ./"
Встановлення:

$ apt-get update
$ apt-get install openscada-model-aglks

ALTLinux: "rpm http://ftp.oscada.org/OpenSCADA/0.9.0/ALTLinux/7 openscada main"
ALTLinux (робоча версія): "rpm http://ftp.oscada.org/OpenSCADA/Work/ALTLinux/6 openscada main"
ALTLinux (робоча версія, модулі окремо): "rpm http://ftp.oscada.org/ALTLinux/7 openscada main"
Встановлення:

$ apt-get update
$ apt-get install openscada-Model.AGLKS

Додання ключа перевірки підпису (дійсності) репозиторію та пакетів у ньому (необов'язково та використовується не у всіх репозиторіях):

 $ wget -O - http://ftp.oscada.org/Misc/pkgSignKey | sudo apt-key add - 

Репозиторії пакетів, що засновано на менеджері пакетів YUM (RedHat, Fedora, CentOs) — додаються завантаженням або створенням файлу /etc/yum.repos.d/openscada.repo з вмістом:

[openscada]
name=OpenSCADA
#CentoOs
baseurl=http://ftp.oscada.org/OpenSCADA/0.9.0/CentOs/7
#CentoOs (рабочая версия)
#baseurl=http://ftp.oscada.org/OpenSCADA/Work/CentOs/6
#Fedora (рабочая версия)
#baseurl=http://ftp.oscada.org/OpenSCADA/Work/Fedora/12
enabled=1
gpgcheck=0

Встановлення:

$ yum install openscada-Model.AGLKS 

Репозиторії пакетів SuSE YaST — додаються командою:

$ zypper ar -f http://ftp.oscada.org/OpenSCADA/0.9.0/SuSE/13 OpenSCADA

Встановлення:

$ zypper in openscada-Model.AGLKS 

2.1.2 Ручне встановлення пакетів OpenSCADA

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

Перший набір представлено одиннадцатью пакетами:

  • openscada — пакет зі всіма файлами, потрібними для запуску OpenSCADA у повному об'ємі, включаючи всі модулі;
  • openscada-server — містить залежності, файл сценарію та конфігурацію проекту сервера для запуску OpenSCADA у режимі сервісу-демону;
  • openscada-libdb-main — основні бібліотеки OpenSCADA для збору даних та іншого, у БД SQLite;
  • openscada-libdb-vca — бібліотеки візуальних компонентів, у БД SQLite;
  • openscada-model-aglks — БД та конфігурація динамічної моделі реального часу "АГЛКС" (Демо: EN,UK,RU);
  • openscada-model-boiler — БД та конфігурація динамічної моделі реального часу "Котел" (EN,UK,RU);
  • openscada-doc-en — offline документація OpenSCADA, англійська мова;
  • openscada-doc-uk — offline документація OpenSCADA, українська мова;
  • openscada-doc-ru — offline документація OpenSCADA, російська мова;
  • openscada-dev — пакет розробки, для окремого створення модулів OpenSCADA;
  • openscada-dbg — пакет налагодження, містить налагоджувальну інформацію бінарних файлів для звіту та пошуку помилок у програмі.

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

  • openscada-core — містить ядро OpenSCADA, базову конфігурацію та запускальні файли;
  • openscada-db-* — модулі підсистеми "БД";
  • openscada-daq-* — модулі підсистеми "Збір даних";
  • openscada-arh-* — модулі підсистеми "Архіви-Історія";
  • openscada-tr-* — модулі підсистеми "Транспорти";
  • openscada-prot-* — модулі підсистеми "Транспортні протоколи";
  • openscada-ui-* — модулі підсистеми "Користувацькі інтерфейси";
  • openscada-spec-* — модулі підсистеми "Спеціальні";
  • openscada — віртуальний пакет, що містить залежності для встановлення типової конфігурації OpenSCADA;
  • openscada-plc — містить залежності, файл сценарію, конфігурацію проекту ПЛК для запуску OpenSCADA у режимі сервісу-демона;
  • openscada-server — містить залежності, файл сценарію та конфігурацію проекту сервера для запуску OpenSCADA у режимі сервісу-демону;
  • openscada-vis-station — віртуальний пакет, що містить залежності для встановлення типової конфігурації OpenSCADA, як візуальна SCADA-станція.
  • openscada-libdb-main — основні бібліотеки OpenSCADA для збору даних та іншого, у БД SQLite;
  • openscada-libdb-vca — бібліотеки візуальних компонентів, у БД SQLite;
  • openscada-model-aglks — БД та конфігурація динамічної моделі реального часу "АГЛКС" (Демо: EN,UK,RU);
  • openscada-model-boiler — БД та конфігурація динамічної моделі реального часу "Котел" (EN,UK,RU);
  • openscada-doc-en — offline документація OpenSCADA, англійська мова;
  • openscada-doc-uk — offline документація OpenSCADA, українська мова;
  • openscada-doc-ru — offline документація OpenSCADA, російська мова;
  • openscada-dev — пакет розробки, для окремого створення модулів OpenSCADA;
  • openscada-dbg — пакет налагодження, містить налагоджувальну інформацію бінарних файлів для звіту та пошуку помилок у програмі.

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

Ручне встановлення DEB-пакетів першого набору можна здійснити командою, попередньо змінивши робочу директорію на директорію з пакетами:

$ dpkg -i openscada-libdb.main_0.9.0-1_all.deb openscada-libdb.vca_0.9.0-1_all.deb openscada-model.aglks_0.9.0-1_all openscada_0.9.0-1_i386.deb 

Ручне встановлення RPM-пакетів першого набору можна здійснити командою, попередньо змінивши робочу директорію на директорію з пакетами:

$ rpm -i openscada-LibDB.Main-0.9.0-alt1.noarch.rpm openscada-LibDB.VCA-0.9.0-alt1.noarch.rpm openscada-Model.AGLKS-0.9.0-alt1.i586.rpm openscada-0.9.0-alt1.i586.rpm 

At.png У процесі виконання встановлення можуть виникнути помилки, пов'язані з незадоволеними залежностями. При ручному встановлені із пакетів задовольняти їх треба буде вручну, подібно до встановлення пакетів OpenSCADA, або через менеджер пакетів дистрибутиву Linux. Випадки наявності проблем залежності можуть бути навіть при встановлені через пакетний менеджер, якщо використовується репозиторій OpenSCADA, який не відповідає дистрибутиву Linux або його версії, або-ж не підключено основні репозиторії пакетів самого дистрибутиву. У пакетному менеджері APT, для автоматичного розв'язання проблем зовнішніх залежностей, які виникли при ручному встановлені OpenSCADA, можна використовувати команду:

$ apt-get install -f

2.2 Встановлення-збірка з вихідних текстів

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

3 Первина конфігурація та запуск

Для наших основних задач з OpenSCADA, у межах цього документу, треба встановити пакет з БД моделі "АГЛКС" — openscada-model-aglks, про що можна детально дізнатися з попереднього розділу. Звісно, якщо Ви використовуєте живий диск то у Вас все потрібне вже є.

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

Встановлена БД моделі "АГЛКС" не потребує попереднього налаштування. Якщо-ж треба здійснити особливе налаштування, яке відрізняється від базового, то скористайтеся посібником по програмі. У процесі чого Вам може знадобитися інформація про типові облікові записи та паролі OpenSCADA (не мають стосунку до облікових записів ОС), хоча моделі та новостворені конфігурації запускаються від привілейованого користувача та Ви можете легко змінити будь який з них:

  • Суперкористувач (root), пароль "openscada".
  • Звичайний користувач (user), пароль "user".
  • Приклад окремого користувача (roman), пароль "roman".

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

At.png Динамічна модель компресорної станції на 6 газових компресорів, яка лежить у основі демонстраційної БД, потребує помітних ресурсів, а саме — процесору з частотою більш 1 ГГц (x86) та пам'яті до 200МБ. Дані обчислювальні ресурси потрібні безпосередньо для динамічної моделі та не є загальним показником ресурсоємності програми у кінцевих задачах! Вимоги до пам'яті, навпаки, є типовим показником для графічної станції АРМ схожої складності.

Загальний процес конфігурації SCADA-системи, для виконання функцій верхнього рівня — АРМ оператора, можна умовно поділити на два етапи:

  • Конфігурація джерела даних, створення бази даних (БД) параметрів цих джерел та налаштування історії.
  • Формування візуального представлення даних ТП, шляхом створення інтерфейсу оператору у вигляді: мнемосхем, груп графіків, груп контурів, документів та інше.

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

Рис. 3. Просте поєднане підключення станції та серверу SCADA з джерелом даних у демонстраційній БД.

За разом, ми ознайомимося з такими важливими ролями OpenSCADA як: сервер збору, архівації, візуалізації; середовище виконання ПЛК та віддалена розробка. Та перед цим ми оглянемо OpenSCADA та її можливості загалом.

3.1 Загальний огляд

Запустити локальне виконання OpenSCADA, з БД моделі "АГЛКС", можна з меню оточення робочої стільниці у розділі "Графіка", пункт "Модель "АГЛКС" на відкритій SCADA системі" з характерною іконкою (Рис.3.1.1).

Рис. 3.1.1. Пункт меню оточення робочої стільниці для локального запуску демонстрації OpenSCADA.

Локальний запуск також можна здійснити з консолі, командою:

$ openscada_AGLKS 

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

Рис. 3.1.2. Програмний конфігуратор OpenSCADA — QTCfg, коренева сторінка.

Програмний конфігуратор OpenSCADA є основним та достатнім засобом для конфігурації будь якого компоненту OpenSCADA. Як і багато компонентів OpenSCADA, конфігуратор реалізовано у вигляді модуля. Крім конфігуратору QTCfg доступні й інші конфігуратори, що виконують ті ж функції, але реалізовані на основі інших технологій. Наприклад, такими є Web-конфігуратори: WebCfgD та WebCfg.

Всі дії надалі ми будемо розглядати лише у конфігураторі QTCfg, хоча їх можна буде виконати і в інших конфігураторах.

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

Рис. 3.1.3. Вікно розробки користувацького інтерфейсу.

Далі можемо запустити проект "АГЛКС" на виконання. Для цього обираємо його у переліку проектів та запускаємо шляхом натискання на першу ліворуч іконку, на панелі інструментів, або у контекстному меню. У результаті чого отримаємо вікно кінцевого інтерфейсу користувача — оператору (Рис.3.1.4).

Рис. 3.1.4. Вікно кінцевого інтерфейсу користувача проекту "AGLKS".

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

Всі дії надалі ми будемо розглядати тільки у інтерфейсі модуля Vision.

Таким чином ми запустили демонстрацію OpenSCADA та познайомилися із основним набором інструментів. Надалі будемо їх використовувати у конфігурації OpenSCADA для виконання функцій верхнього рівня — АРМ оператора, та інших задач.

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

3.2 Фонове та віддалене виконання — сервер, середовище виконання ПЛК та віддалена розробка

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

Для запуску OpenSCADA в фоновому режимі виконання нам треба встановити пакет openscada-server, як це описано у розділі встановлення та який вже буде встановлений у випадку живого диску. Після встановлення цього пакету ми маємо, у консолі-терміналі (наприклад, програма "konsole" у оточені живого диску за діалогом запуску Alt+F2) та від суперкористувача, здійснити наступні дії:

# Підключитися від суперкористувача
$ su -
# ... для живого диску та деяких інших оточень Linux
$ sudo bash
# Зупинити виконання порожньої конфігурації серверу
$ service openscada-server stop
# Створити посилання серверного проекту на "АГЛКС"
$ rm -R /usr/share/openscada/server
$ ln -s AGLKS /usr/share/openscada/server
$ ln -s /etc/oscada_AGLKS.xml /usr/share/openscada/server/oscada.xml
# Запустити сервер вже з демонстраційною БД
$ service openscada-server start

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

Якщо-ж у Вас все-ж виникли проблеми при роботі з консолью-терміналом або Ви свідомо хочете фонового виконання у графічному оточені — так званого "запуску або закриття у системний лоток", тоді Ви, на цій стадії, можете знову запустити демонстраційну конфігурацію, як описано на початку цього розділу (Рис.3.1.1), встановити параметр Згортати або запускати у системний лоток, модуля UI.QTStarter, та закрити вікно конфігуратору, щоб проект моделі АГЛКС згорнувся до системного лотку.

3.3 Створення власного проекту

У вікні менеджеру проектів OpenSCADA (Рис.3.3) створимо наш власний проект, який можна викликати з меню оточення робочої стільниці у розділі "Графіка", загальним пунктом "Відкрита SCADA-система" з характерною іконкою (Рис.3.1.1), або командою з консолі-терміналу:

$ openscada
Рис. 3.3. Вікно менеджеру проектів OpenSCADA.

У цьому вікні ми також можемо перевірити фонове виконання серверної та демонстраційної конфігурацій.

А саме, натиснемо відповідну кнопку Створити-оновити проект та введемо назву нового проекту, наприклад — Start.

3.3.1 Підключення та використання віддалених та фонових конфігурацій

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

На сторінці транспортів (Рис.3.3.1.1), у режимі Користувацький та Системний, створимо підключення до нашої фонової демонстрації "AGLKS", як станції OpenSCADA. Вкажемо там транспорт Сокети, адресу TCP:localhost:10005, користувача root та пароль openscada. Після оновлення дерева навігації конфігуратора, командою у контекстному меню, ми маємо отримати новий кореневий пункт цього підключення та зможемо контролювати віддалену-фонову станцію з цього конфігуратору.

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

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

Рис. 3.3.1.1. Сторінка транспортів зовнішніх станцій OpenSCADA та огляд дерева OpenSCADA віддаленої-фонової станції.

На сторінці конфігурації візуалізатору UI.Vision (Рис.3.3.1.2) оберемо:

  • станцію рушія СВУ — AGLKS;
  • користувача запуску — залишимо порожнім;
  • пароль користувача цієї віддаленої станції — залишимо порожнім;
  • проект(и) для їх автоматичного виконання — також залишимо порожнім, бо ми хочемо побачити можливість віддаленої розробки.
Рис. 3.3.1.2. Сторінка конфігурації візуалізатору UI.Vision.

Наступний запуск модуля UI.Vision, другою іконкою з кінця на панелі інструментів нагорі, має призвести середовище візуальної розробки до встановлення підключення з сервером візуалізації фонового демонстраційного проекту. Де Ви можете здійснювати віддалену розробку (Рис.3.3.1.3) та запускати проекти з цього серверу візуалізації на виконання (Рис.3.3.1.4).

Рис. 3.3.1.3. Екран віддаленої розробки UI.Vision для серверу візуалізації "АГЛКС".
Рис. 3.3.1.4. Екран віддаленого виконання UI.Vision для серверу візуалізації "АГЛКС".

At.png Цю конфігурацію віддаленого підключення до серверу візуалізації зберігати не треба та поле конфігурації "Станція рушія СВУ" (Рис.3.3.1.3) треба повернути у Local, а користувача станції встановити у root; тільки після чого зберегти.

Можливість віддаленого підключення та розробки інколи є єдиним способом здійснити розробку або коригування не тільки для серверних конфігурацій виключно з WEB-інтерфейсом, але і для конфігурацій з локальною візуалізацією, коли саме оточення локальної візуалізації непридатне або обмежене для виконання середовища розробки модуля UI.Vision, наприклад, таких як смартфони, планшети, та інші мобільні пристрої з малим екраном, виключно сенсорним вводом (Android) або обмеженнями, на кшталт неможливості відкриття системної віртуальної клавіатури (Nokia N9). Та цю віддалену розробку можна переважно здійснювати у процесі виконання проекту — гаряча розробка, що особливо актуально для Web-інтерфейсів і локальних інтерфейсів, які запускаються лише у вікні виконання. Щодо віддаленої конфігурації то на один локальний конфігуратор, як центр адміністрування, можна зібрати всі віддалені станції у мережі, включно зі станціями у прихованих мережах станцій першого рівня, підняти які можно аргументом "Рівень підняття" (Рис.3.3.1.1).

3.3.2 Підключення стандартних бібліотек OpenSCADA

Ново-створений проект OpenSCADA не містить жодної специфічної конфігурації, по факту є порожнім та передбачає створення користувачем нової конфігурації у локальному файлі БД SQLite "St.db", що розташовується у власній теці проекту з такою-ж назвою. Створювати складний проект SCADA-системи простіше з використанням бібліотек функцій API об'єктної моделі OpenSCADA та бібліотек графічних елементів, а також інших бібліотек OpenSCADA. Для використання бібліотек OpenSCADA треба файли БД, де зберігаються бібліотеки: підключити — додати у об'єкті модуля БД "SQLite" (Рис.3.3.2.1), встановити-обрати адресу та вказати кодування БД у UTF-8 (Рис.3.3.2.2).

Рис. 3.3.2.1. Додання об'єкту БД "SQLite".
Рис. 3.3.2.2. Об'єкт БД "SQLite" бібліотеки OpenSCADA.

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

Таблиця 3.3.2. Бібліотеки OpenSCADA у складі дистрибутиву.

ID Ім'я Адреса Мова/кодування
OscadaLibs Бібліотеки функцій LibsDB/OscadaLibs.db EN,UK,RU/UTF-8
vcaBase СВУ: Головні бібліотеки LibsDB/vcaBase.db EN,UK,RU/UTF-8
vcaTest СВУ: Тести LibsDB/vcaTest.db EN,UK,RU/UTF-8
vcaElectroEls СВУ: Бібліотека електро-елементів мнемосхем користувацького інтерфейсу LibsDB/vcaElectroEls.db EN,UK,RU/UTF-8

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

4 Робота з джерелами даних

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

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

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

4.1 Збір даних аппарату ТП

У якості прикладу розглянемо та створимо збір даних для апарату повітряного охолоджувача. Фонова демонстраційна БД, як ПЛК та джерело даних, містить модель реального часу ТП компресорної станції з шести компресорів. Дані для двох апаратів повітряних холодильників "AT101_1" та "AT101_2" компресорної станції "KM101" доступні за протоколом ModBus/TCP на порту 10502 (стандартно цей порт 502, при наявності доступу його відкриття).

Створимо об'єкт контролеру для збору за протоколом ModBUS/TCP та отримаємо ці дані. Тим самим фактично реалізуємо завдання збору реальних даних, оскільки наша конфігурація буде відрізнятися від роботи зі справжнім зовнішнім пристроєм тільки його адресою та адресами регістрів ModBUS, а також це може бути інший фізичний інтерфейс взаємодії — варіант протоколу ModBus. Це підключення також є яскравим прикладом можливості реалізації середовища виконання джерела даних (ПЛК) на основі OpenSCADA.

Для збору даних за протоколом "ModBUS" у OpenSCADA присутній модуль "Modus" підсистеми "Збір даних". Для додання нового об'єкту контролера у конфігураторі відкриємо сторінку модуля "ModBUS" ("Start"->"Збір даних"->"Модуль"->"ModBus") та у контекстному меню пункта "ModBus" натиснемо "Додати" (риc.4.1.1).

Рис. 4.1.1. Додання об'єкту контролера у модулі "ModBus" підсистеми "Збір даних".

У результаті з'явиться вікно діалогу (Рис.4.1.2) з пропозицією ввести ідентифікатор та ім'я нового об'єкту контролера. Ідентифікатори будь яких об'єктів у OpenSCADA обмежено розміром у 20 символів та їх рекомендується вводити символами англійського алфавіту та цифрами. Крім того, починати ідентифікатор бажано з літери, що спростить його використання у внутрішніх процедурах. Імена об'єктів OpenSCADA обмежено розміром у 50 символів, які можуть бути будь якими. Ім'я зазвичай використовуються для відображення та якщо воно порожнє то буде використано ідентифікатор. Надалі, ім'я ми можемо змінити у конфігурації об'єкта, але ідентифікатор неможливо змінити прямо; однак об'єкт можна вирізати (Ctrl+X) та потім вставити (Ctrl+V), тем самим перейменувавши його. Введемо, згідно до зауважень раніш, ідентифікатор "CM101", ім'я "KM 101" — CM101 (KM 101).

Рис. 4.1.2. Діалог визначення ідентифікатору та ім'я нового об'єкту.

Після підтвердження у нас з'явиться об'єкт нового контролера. Оберемо його у конфігураторі та ознайомимося з налаштуваннями (Рис.4.1.3).

Рис. 4.1.3. Головна вкладка налаштування об'єкту контролера модуля ModBus.

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

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

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

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

  • "Вмикати" та "Запускати" вказують на те, у який стан переводити об'єкт контролеру при запуску програми. Встановимо обидва поля.
  • "Планування збору" містить конфігурацію планувальника для запуску задачі збору даних. Отримати опис формату конфігурації даного поля можна з спливаючої підказки. Одиночне число вказує на періодичність запуску, у секундах. Вкажемо одну секунду.
  • "ModBus протокол" вказує на варіант протоколу ModBus. Можливі варіанти протоколу "TCP/IP", "RTU" та "ASCII". Наразі нас цікавить варіант TCP/IP, тому залишимо як є. Варіанти протоколів "RTU" та "ASCII" треба встановлювати у випадку зв'язку з контролером за посередництвом послідовних інтерфейсів, часто це "RS-485".
  • "Адреса транспорту" вказує на вихідний транспорт підсистеми "Транспорти", який використовується для з'єднання з контролером. У випадку з варіантом "TCP/IP" нам потрібен транспорт у модулі Sockets, а у випадку варіантів "RTU", "ASCII" та послідовного інтерфейсу нам потрібен транспорт у модулі Serial. На створені вихідного транспорту у "Sockets" та "Serial" детальніше зупинимося нижче.
  • "Вузол призначення" вказує на вузол джерела даних або контролера у мережі ModBus. У нашому випадку це має бути 1.
  • "Об'єднувати фрагменти даних" включає об'єднання несуміжних фрагментів регістрів у один блок запиту, до визначеної нижче кількості байтів, замість генерації окремих запитів. Дозволяє зменшити загальний час збору. Встановимо цю опцію.

Збережемо наші зміни у БД, натиснувши другу ліворуч іконку на панелі інструментів.

Тепер, таким чином як і об'єкт контролеру, створимо вихідний транспорт у модулі "Sockets" ("Start"->"Транспорти"->"Сокети"), за посередництвом контекстного меню (Рис.4.1.4) та назвемо транспорт так як і об'єкт контролеру CM101 (KM 101). Зверніть увагу, що у полі "Тип елементу", діалогу вводу ідентифікатору та ім'я (Рис.4.1.2), треба обрати Вихідний транспорт!

Рис. 4.1.4. Додавання вихідного транспорту у модулі "Sockets" підсистеми "Транспорти".

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

Рис. 4.1.5. Сторінка конфігурації вихідного транспорту модуля "Sockets" підсистеми "Транспорти".

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

  • "Адреса" вказує на: тип, адресу та режим підключення з віддаленою станцією. Ознайомитися з форматом запису можна з підказки що спливає. Встановимо це поле у значення TCP:localhost:10502.

Транспорти інших типів створюються подібно до методу, розглянутому для "Sockets", а конфігурація їх відрізняється зазвичай тільки форматом запису адреси та таймаутів. У випадку з транспортом модуля "Serial" у адресі вказується: шлях до послідовного пристрою, швидкість та формат. Для конвертерів USB->Serial,Modem цю адресу можна дізнатися з операційної системи, наприклад, консольною командою $ dmesg, одразу після його підключення.

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

Для додання нового параметру відкриємо сторінку нашого об'єкту контролера та, у контекстному меню пункту "KM 101 (CM101)", натиснемо "Додати". Параметр назвемо: AT101_1 (AT 101_1).

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

Рис. 4.1.6. Сторінка конфігурації параметру контролера "ModBUS".

У розділі "Конфігурація" безпосередньо міститься конфігурація параметру. Встановимо наступні з них, залишивши всі інші без змін:

  • "Вмикати" вказує на необхідність переводу об'єкта у режим "Ввімкнений", при запуску програми. Встановимо це поле.
  • "Перелік атрибутів" містить конфігурацію атрибутів параметру відносно до регістрів та бітів "ModBus". Ознайомитися з форматом запису можна з підказки що спливає. Встановимо вміст цього текстового поля у:
R:100:r:Ti:T вхід
R:101:r:To:T вихід
R:102:rw:Cw:Продуктивність

Таким же чином створимо, або скопіюємо з AT101_1, другий параметр "AT101_2 (AT 101_2)". Перелік атрибутів для нього встановимо у:

R:103:r:Ti:T вхід
R:104:r:To:T вихід
R:105:rw:Cw:Продуктивність

Збережемо обидва параметри. Тепер ми можемо запустити наш об'єкт контролера для здійснення збору, для чого повернемося на його сторінку та, у розділі "Стан", встановимо ознаку "Виконується". Якщо ми нічого не пропустили то обмін успішно запуститься та у полі "Статус" ми отримаємо подібне представленому на рисунку 4.1.7.

Рис. 4.1.7. Сторінка об'єкту контроллера при успішному обміні з фізичним контролером.

У випадку вдалого обміну з фізичним контролером ми також отримаємо описані дані контролеру у інфраструктурі (моделі даних) OpenSCADA. Побачити ці дані можна у вкладці "Атрибути" наших параметрів AT101_1 (Рис.4.1.8) та AT101_2. Оскільки збір здійснюється регулярно та з періодичністю у секунду, то ми можемо спостерігати їх зміну, натискаючи кнопку "Поновити поточну сторінку" на панелі інструментів.

Рис. 4.1.8. Сторінка опису атрибутів параметру AT101_1.

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

4.2 Обробка отриманих даних ТП

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

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

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

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

Для створення шаблону відкриємо сторінку ново-створеної бібліотеки шаблонів ("Start"->"Збір даних"->"Бібліотека шаблонів"->"Запуск") та, за посередництвом контекстного меню, створимо об'єкт шаблону airCooler (Повітряний холодильник). Сторінка конфігурації отриманого об'єкту шаблона (Рис.4.2.2) містить розділ стану та оперативного управління "Стан" та розділ налаштувань "Конфігурація" у якому містяться тільки типові поля конфігурації та які залишимо незмінними. Загалом ми маємо:

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

Основна конфігурація та формування шаблону параметра збору даних здійснюється у вкладці "ВВ" (Рис.4.2.3) шаблону. Детальний опис процесу формування шаблону можна отримати за посиланням.

У шаблоні створимо дві властивості для входів ("TiCod", "ToCod"), дві для виходів результату ("Ti","To") та один прозорий ("Cw"). Властивостям "TiCod", "ToCod" та "Cw" встановимо ознаку "Конфігурація" у Зв'язок, що дозволить підв'язувати до них "сире" джерело. Параметрам "Ti" та "To", ознаку "Атрибут" встановимо у Тільки читання, "Cw" у Повний доступ; для формування трьох атрибутів результатного параметру збору даних: два тільки на читання та один на повний доступ.

Встановимо мову програми у JavaLikeCalc.JavaScript, а програму у:

Ti = 150*TiCod/65536;
To = 100*ToCod/65536;
Рис. 4.2.3. Вкладка "ВВ" сторінки конфігурації объекта шаблону.

Збережемо отриманий шаблон та встановимо ознаку доступності (Рис.4.2.2).

Тепер створимо об'єкт контролера та параметри у модулі "LogicLev" підсистеми "Збір даних". Об'єкт контролера "LogicLev" та його параметри створюються ідентично раніш створеним у модулі "ModBus", на сторінці: "Start"->"Збір даних"->"Модуль"->"Логічний рівень". Назвемо їх ідентично до об'єктів модуля "ModBus".

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

Рис. 4.2.4. Головна вкладка налаштування об'єкту контролера модуля "LogicLev".

Параметр об'єкту контролера модуля "LogicLev" (Рис.4.2.5) із специфічних налаштувань має "Тип", де треба встановити Логічний (std), а у полі "Шаблон параметру" обрати адресу створеного нами шаблону.

Рис. 4.2.5. Сторінка конфігурації параметру об'єкта контролера модуля "LogicLev".

Крім базової конфігурації параметру треба сконфігурувати й підключений шаблон (Рис.4.2.6). Вкладка конфігурації шаблону з'являється у режимі параметру "Ввімкнено". Ввімкнути параметр можна, ввімкнувши попередньо об'єкт контролеру. Ознака "Показувати тільки атрибути" дозволяє встановлювати окремо кожний зв'язок (Рис.4.2.7). Оскільки ми, у шаблоні, передбачливо описали формат зв'язків у вигляді "Параметр|Ti", то всі три зв'язки ми можемо встановити просто вказавши адресу до параметру у об'єкті контролеру "ModBus". Вкажемо-оберемо адресу ModBus.CM101.AT101_1 та ModBus.CM101.AT101_2, у відповідних параметрах.

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

Рис. 4.2.6. Вкладка "Конфігурація шаблона" сторінки параметра контролера "LogicLev".
Рис. 4.2.7. Вкладка "Конфігурація шаблона" сторінки параметра контролера "LogicLev" із розворотом зв'язків.

Збережемо створені об'єкти контролеру та параметрів, після чого запустимо об'єкт контролера на виконання, установивши ознаку "Виконується" у розділі "Стан". Якщо ми нічого не пропустили, то обчислення успішно запуститься та у полі "Статус" ми отримуємо схоже на рисунку 4.2.8.

Рис. 4.2.8. Сторінка об'єкту контролера при успішному його обчислені у модулі "LogicLev".

У випадку вдалої обробки коду шаблона, у параметрах, ми отримаємо оброблені дані у інфраструктурі (моделі даних) OpenSCADA. Побачити ці дані можна у вкладці "Атрибути" наших параметрів AT101_1 (Рис.4.2.9) та AT101_2.

Рис. 4.2.9. Сторінка атрибутів параметру AT101_1 модуля "LogicLev".

На цьому конфігурацію обробки даних вважаємо закінченою.

4.3 Комплексний об'єкт-тег сигналу

У попередніх розділах було описано механізм підключення джерела даних за об'єктом апарату — "Повітряний охолоджувач", який передбачає об'єднання всіх сигналів у одному об'єкті параметру джерела даних. Однак більш розповсюдженим підходом крупної автоматизації є формування об'єкту параметру довкола окремого сигналу, наприклад — "Температура на виході холодильника AT101_1 (TE1314_1)", які часто називаються тегами.

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

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

Назвемо аналоговий параметр TE1314_1 (TE1314_1), (Рис.4.3.1). Тип параметру встановимо у Логічний (logic), шаблон параметру оберемо base.anUnif, опис встановимо у Температура на виході AT101_1, встановимо ознаки "Вмикати" та "Ввімкнено". Далі, нам треба налаштувати:

  • Шаблон параметру, у вкладці "Конфігурація шаблона" що з'явилася (Рис.4.3.2):
    • поле "Вхід" встановлюємо у значення адреси ModBus-регістру цього параметру R:101;
    • поле "Максимум шкали модуля" встановлюємо у значення 65535, що відповідає 100 °C.
  • Встановлення вкладки "Атрибути" (Рис.4.3.3):
    • "Од. виміру" встановлюємо у град. С;
    • "Шкала:мінімум" у 0;
    • "Шкала:максимум" у 100;
    • "Границя верхня аварійна" у 40;
    • "Границя верхня попереджув." у 30.
  • Збережемо об'єкт.
Рис. 4.3.1. Сторінка логічного параметру "TE1314_1" модуля "ModBus".
Рис. 4.3.2. Вкладка "Конфігурація шаблону" сторінки параметру "TE1314_1" модуля "ModBus".
Рис. 4.3.3. Вкладка "Атрибути" сторінки параметру "TE1314_1" модуля "ModBus".

Дискретний параметр назвемо CB102 (КК102). Тип параметру встановимо у Логічний (logic), шаблон параметру оберемо base.digitBlockUnif, встановимо ознаки "Вмикати" та "Ввімкнено". Далі нам треба налаштувати:

  • Шаблон параметру, у вкладці "Конфігурація шаблону" що з'явилася (Рис.4.3.4):
    • поле "Команда 'Відкрити'" встановлюємо у значення адреси ModBus-біту цього параметру C:100:rw;
    • поле "Стан 'Відкрито'" встановлюємо у значення адреси ModBus-біту C:101;
    • поле "Стан 'Закрито'" встановлюємо у значення адреси ModBus-біту C:102;
    • поле "Час утримання команди" встановлюємо у 0 оскільки команда не імпульсна.
  • Встановлення вкладки "Атрибути" (рис.4.3.5): упевнюємося у доступності команди та станів.
  • Збережемо об'єкт.
Рис. 4.3.4. Вкладка "Конфігурація шаблону" сторінки параметру "CB102" модуля "ModBus".
Рис. 4.3.5. Вкладка "Атрибути" сторінки параметру "CB102" модуля "ModBus".

4.4 Отримання готових даних OpenSCADA — шлюзування

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

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

OpenSCADA передбачає можливість такої уніфікації через додання спорідненості з ПЛК. Та таку спорідненість можна забезпечити тільки для ПЛК, які є повністю відкритими, на них встановлено відкрите-вільне ПЗ, а відтак можна встановити і OpenSCADA у ролі середовища виконання ПЛК. Як середовище виконання, OpenSCADA може надавати дані ПЛК і стандартними протоколами, як то ModBus, та, для отримання цих даних прямо і без здійснення будь-яких дій над ними, на боці SCADA-системи передбачено модуль "DAQGate", що, по факту, об'єднує моделі. Тобто, фактично, програміст ПЛК, який по сумісництву є програмістом SCADA, формує модель даних ПЛК, а на рівні SCADA-системи вона використовується вже як готова, чим повністю прибирається стадія та роботи з отримання, обробки та формування моделі даних SCADA-системи. Більш того:

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

З метою демонстрації та ознайомлення, створимо тут об'єкт контролеру модуля "DAQGate", для шлюзування даних нашого віртуального ПЛК. Створюється він ідентично до раніш створених об'єктів контролеру у модулі "ModBus" та "LogicLev", на сторінці: "Start"->"Збір даних"->"Модуль"->"Шлюз джерел даних" та назвемо його AGLKS.

Об'єкт контролера модуля "DAQGate" (Рис.4.4.1) має наступні специфічні налаштування, які ми маємо здійснити:

  • "Перелік віддалених станцій" — у полі "Додання станції" оберемо раніш створене підключення віддаленої станції "AGLKS".
  • Ввімкнемо об'єкт контролера.
  • "Перелік віддалених контролерів та параметрів" — у полі "Дерево параметрів" оберемо LogicLev.experiment, а потім пункт <<Додати поточний>> нагорі цього переліку.
  • Запустимо виконання об'єкту контролера.
Рис. 4.4.1. Головна вкладка налаштування об'єкту контролера модуля "DAQGate".

Якщо все зроблено правильно то автоматично створяться параметри обраного контролера та ми зможемо поглянути на дані по них у вкладці "Атрибути" (Рис.4.4.2).

Рис. 4.4.2. Вкладка "Атрибути" сторінки параметру модуля "DAQGate".

4.5 Архівування-історія даних ТП

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

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

Почнемо з архівації значень, для якої треба створити хоча-б один архіватор для потрібного типу сховища та періодичністю значень. Загалом, OpenSCADA містить два модулі архівації: на файлову систему "FSArch" та на базу даних "DBArch". Тут ми розглянемо тільки модуль архівації на файлову систему, як найбільш універсальний та ефективний. Стосовно періодичності значень, для "якісного" архіватору, то її, переважно, треба обирати за періодичністю значень самого повільного джерела даних у нашій системі, який у нас один та періодичність ми йому вказали 1 секунда. Для створення архіватору значень відкриємо сторінку модуля архівування ("Start"->"Архіви-Історія"->"Модуль"->"Архіватор на файлову систему") та, за посередництвом контекстного меню, створимо об'єкт архіватору значень 1s. Зверніть увагу на значення поля "Тип елементу" діалогу створення, яке має бути Архіватор значень! Сторінка конфігурації отриманого об'єкта архіватору значень (Рис.4.5.1) містить розділ стану та оперативного управління "Стан", розділ налаштувань "Конфігурація" та розділ специфічних налаштувань архіватору цього модуля "Додаткові опції". Загалом ми маємо:

  • Розділ "Стан":
    • запустити архіватор на виконання, встановивши ознаку навпроти відповідного поля — тільки архіватор що виконується здійснює архівування; At.png встановити у останню чергу та після виконання всього цього переліку;
    • можемо проконтролювати поточний та максимальний час сеансу архівування;
    • вказати сховище конфігурації у полі "БД архіватора", залишимо основну БД проекту, по замовченню;
    • можемо проконтролювати загальний розмір файлів архіву цього архіватору.
  • Розділ "Конфігурація":
    • встановити запуск архіватору при запуску програми, встановивши ознаку навпроти відповідного поля;
    • встановити адресу теки з файлами архіву у ARCHIVES/VAL/1s, що ставиться по замовченню;
    • встановити період значень у 1 секунду;
    • встановити період архівування у 60 секунд, по замовченню; зазвичай однаковий для архіваторів з будь-якою періодичністю значень.
  • Зберегти об'єкт.
Рис. 4.5.1. Конфігурація архіватору значень "1s" на файлову систему.

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

  • Хвилинний: ідентифікатор 1m, адреса ARCHIVES/VAL/1m та період значень 60 секунд.
  • Годинний: ідентифікатор 1h, адреса ARCHIVES/VAL/1h та період значень 3600 секунд.

Для включення архівування атрибутів "Ti" та "To" параметрів AT101_1 та AT101_2, у раніш створеному об'єкті контролеру модуля "LogicLev", достатньо у вкладці "Архівація" сторінки параметрів обрати, які атрибути архівувати та якими архіваторами (Рис.4.5.2). Оберемо архівацію атрибутів "Ti" та "To" раніш створеними архіваторами FSArch.1s, FSArch.1m, FSArch.1h. Теж саме зробимо для атрибуту "var" аналогового параметру "ModBus.CM101.TE1314_1" та "com" дискретного параметра "ModBus.CM101.CB102".

Рис. 4.5.2. Вкладка "Архівація" параметру AT101_1 модуля "LogicLev".

У результаті цієї операції будуть автоматично створені об'єкти архівів для обраних атрибутів. Приклад об'єкту архіву, для атрибуту "Ti" параметру AT101_1, представлено на рисунку 4.5.3.

Рис. 4.5.3. Сторінка об'єкта архіву атрибуту "Ti" параметру AT101_1.

За звичай, налаштування архіву міняти не треба, однак, якщо буде потрібна особлива конфігурація, то її можна зробити на вказаній вище сторінці. Частіше може знадобитися отримання інформації про архів. Наприклад, дізнатися розмір архіву як за часом, так і на носії, а також поглянути на графік параметру (Рис.4.5.4).

Рис. 4.5.4. Вкладка "Значення" сторінки об'єкта архіву атрибута "Ti" параметра AT101_1.

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

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

Відповідно, створимо архіватор повідомлень для архівації порушень, для чого відкриємо сторінку модуля архівування ("Start"->"Архіви-Історія"->"Модуль"->"Архіватор на файлову систему") та, за посередництвом контекстного меню, створимо об'єкт архіватору повідомлень alarms (Порушення). Зверніть увагу на значення поля "Тип елементу" діалогу створення, яке має бути Архіватор повідомлень! Сторінка конфігурації отриманого об'єкта архіватору значень (Рис.4.5.5) містить розділ стану та оперативного управління "Стан", розділ налаштувань "Конфігурація" та розділ специфічних налаштувань архіватору цього модуля "Додаткові опції". Загалом ми маємо:

  • Розділ "Стан":
    • запустити архіватор на виконання, встановивши ознаку навпроти відповідного поля — тільки архіватор що виконується здійснює архівування; At.png встановити у останню чергу та після виконання всього цього переліку;
    • вказати сховище конфігурації у полі "БД архіватора", залишимо основну БД проекту, по замовченню;
    • можемо проконтролювати час першого та останнього повідомлення у архіві цього архіватору;
    • можемо проконтролювати загальний розмір файлів архіву цього архіватору;
    • можемо проконтролювати поточний та максимальний час сеансу архівування.
  • Розділ "Конфігурація":
    • встановити запуск архіватору при запуску програми, встановивши ознаку навпроти відповідного поля;
    • встановити категорію повідомлень, яка характеризує порушення, у al*;
    • встановити рівень архівованих порушень у Інформація (1);
    • встановити адресу теки з файлами архіву у ARCHIVES/MESS/alarms, що ставиться по замовченню;
  • Зберегти об'єкт.
Рис. 4.5.5. Конфігурація архіватору повідомлень "alarms" на файлову систему.

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

5 Формування візуального представлення

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

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

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

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

Всі роботи над інтерфейсом візуалізації будемо виконувати у оточені модуля "Vision" підсистеми "Користувацькі інтерфейси". Для відкриття вікна інтерфейсу "Vision" натиснемо другу іконку праворуч панелі інструментів конфігуратору. У результаті отримаємо вікно, раніш представлене на рисунку 3.3.1.3.

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

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

Скопіюємо проект "Групи сигналізації (шаблон)", натиснувши спочатку кнопку "Копіювати візуальний елемент" на ньому, а потім кнопку "Вставити візуальний елемент" (Рис.5.1). У діалозі назвемо наш новий проект start (Старт) та у переліку проектів отримаємо пункт нашого нового проекту (Рис.5.1).

Рис. 5.1. Копіювання шаблонного проекту у новий.

Перед використанням та збереженням нового проекту (Рис.5.3) треба змінити адресу його сховища на головну БД *.*.prj_start, що ми можемо зробити на головній сторінці діалогу властивостей візуального елементу, який викликається за кнопкою "Властивості візуального елементу" (Рис.5.2). Після чого збережемо наш новий проект, натиснувши третю кнопку ліворуч панелі інструментів.

Рис. 5.2. Свойства нового проекта на основе шаблонного.

Шаблонний проект (Рис.5.3) містить дві гілки: "Панелі управління" та "Коренева сторінка". Гілка "Панелі управління" містить набір кадрів типових панелей управління та спеціалізованих кадрів. Гілка "Коренева сторінка", з кореневою сторінкою у основі, містить підгілки об'єктів сигналізації "Група 1", "Група 2" та окрему гілку зведених графіків "Зведені графіки". Підгілки об'єктів сигналізації "Група {n}" мають цифровий ідентифікатор та можуть розширятися доданням упритул до 20. Присутність підгілки "Група {n}" відбивається на активації відповідної кнопки об'єкта сигналізації кореневої сторінки, що дозволяє на них перемикатися. Кожна підгілка "Група {n}" містить контейнери або шаблони видів відображення, зазвичай: "Мнемосхеми", "Групи графіків", "Групи контурів", "Групи оглядових кадрів" та "Документи". Наявність сторінок у контейнерах відображень вмикає можливість обрання цього відображення, для відповідного об'єкта сигналізації кореневої сторінки. Детальніше ознайомитися зі структурою кореневої сторінки можна за посиланням.

Рис. 5.3. Шаблонний проект на основі концепції об'єктів сигналізації.

5.1 Додання шаблонної сторінки та підключення динаміки

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

Рис. 5.1.1. Шаблонна сторінка "Група графіків".

Шаблонна сторінка "Група графіків" надає можливість підключити до восьми сигналів одночасного їх відображення на графіку. Елементи відображення значення нагорі автоматично приховуються для невстановлених зв'язків.

Створимо нову групу графіків у шаблонному контейнері "Група графіків" першої групи кореневої сторінки. Для цього, у контекстному меню пункту "Група графіків", оберемо пункт меню "Додати візуальний елемент" (Рис.5.1.2). Для вводу ідентифікатору та назви нового візуального елемента з'явиться діалог їх вводу (Рис.5.1.3). Введемо ідентифікатор "2" та ім'я "Графіки 2" — 2 (Графіки 2).

Рис. 5.1.2. Додання групи графіків "Графіки 2".
Рис. 5.1.3. Діалог вводу ідентифікатора та ім'я.

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

Рис. 5.1.4. Діалог редагування властивостей візуального елементу.

Після включення сторінки можна приступати до встановлення зв'язків на створені раніш параметри контролерів. Для цього, не покидаючи діалогу редагування властивостей щойно створеної сторінки (Рис.5.1.4), перейдемо до вкладки "Зв'язки" (Рис.5.1.5). На цій вкладці ми побачимо дерево з елементами "el1" ... "el8". Розгорнувши будь-який з елементів ми побачимо гілку "Parameter", та саме у ній ми маємо вказати або обрати адресу наших атрибутів "Ti" та "To". Загалом заповнимо чотири елементи, та під час цього частину властивостей треба вказувати як постійні:

  • "name" — val:AT101_1 Ti.
  • "ed" — val:град.С.
  • "max" — val:150 (для Ti) та val:100 (для To).
  • "min" — val:0.

Якщо у шаблоні параметру контролера заздалегідь передбачити наявність атрибутів, вказаних нами постійними, то можна буде вказувати тільки параметр, а атрибути розставляться автоматично. Це можемо побачити, прив'язавши створений нами раніш комплексний об'єкт-тег аналогового сигналу "ModBus.CM101.TE1314_1".

Рис. 5.1.5. Вкладка "Зв'язки" діалогу редагування властивостей візуального елементу.

Закінчивши введення зв'язків можемо перевірити, що вийшло у результаті наших зусиль. Для цього закриємо вікно діалогу властивостей та запустимо наш проект "Старт" на виконання, про кнопку запуску ми пам'ятаємо з перших глав. Далі, оберемо графіки та перемкнемося на другу сторінку. За безпомилкової конфігурації ми маємо побачити щось подібне до зображеного на рисунку 5.1.6. Зауважте, що для параметру комплексного об'єкту-тегу, зі встановленими границями порушень, вихід значення за границі відзначається аварійним кольором. Для того щоб побачити вихід за границю порушення Ви можете встановити значення продуктивності вентилятора у 100 (Рис.4.2.9).

Рис. 5.1.6. Група графіків з підключенням чотирьох сигналів та одним параметром объекта-тега.

5.2 Створення нового кадру — мнемосхеми

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

Нові кадри, призначені надалі до розташування у проекті, прийнято створювати та змінювати у бібліотеці віджетів. Створимо нову бібліотеку віджетів, обравши вертикальну вкладку "Віджет" та у контекстному меню вікна бібліотек віджетів оберемо пункт меню "Нова бібліотека" (Рис.5.2.1). У діалозі вводу назви вкажемо CM101 (KM 101).

Рис. 5.2.1. Додання нової бібліотеки віджетів.

Далі додаємо новий кадр, обравши пункт меню "Бібліотека: originals"->"Група елементів" (Рис.5.2.2) у контекстному меню створеної бібліотеки "KM 101". У діалозі вводу назви вкажемо AT101 (AT 101). У основі будь-якого кадру та сторінки має лежати елемент "Група елементів (Box)" тому ми його й обрали.

Рис. 5.2.2. Додання нового кадру.

Одразу після створення нового кадру треба встановити його базові властивості, характерні для кадру мнемосхеми. Властивості або атрибути будь-якого візуального елементу можна вказати у панелі інструментів "Атрибути", попередньо обравши потрібний візуальний елемент. Оберемо створений кадр "AT 101" та встановимо наступні властивості:

  • "Геометрія: ширина" — 900.
  • "Геометрія: висота" — 600.
  • "Сторінка: група" — so, для включення кадру до контейнеру мнемосхем, при виконанні.
  • "Фон: колір" — #5A5A5A.
  • "Границя: ширина" — 1.
  • "Границя: колір" — black.

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

Рис. 5.2.3. Вигляд нового кадру та встановлених атрибутів мнемосхеми.

Тепер, на кадр додамо елементи відображення значень аналогового параметру для наших чотирьох сигналів та параметру комплексного об'єкта-тегу "ModBus.CM101.TE1314_1". Для розташування елементу відображення аналогового сигналу на мнемосхему треба її обрати, а потім, у меню вікна, обрати пункт меню "Віджет"->"Бібліотека: Main"->"Відображення аналогового"; після чого з'явиться курсор з образом цього елементу, який треба підвести у бажану область мнемосхеми та натиснути ліву кнопку миші. У момент додання з'явиться діалог із запитом ім'я нового елементу. Подібним чином додавати будемо п'ять елементів, які назвемо: A1_Ti, A1_To, A2_Ti, A2_To и TE1314_1.

Таким-же чином додамо елемент крану комплексного об'єкту-тегу дискретного параметра "ModBus.CM101.CB102", для представлення якого використаємо бібліотечний елемент "Віджет"->"Бібліотека: mnEls"->"Кран кульовий" та назвемо його CB102.

Для відображення переліку поточних порушень, на мнемосхемі розташуємо елемент протоколу з бібліотеки примітивів "Віджет"->"Бібліотека: originals"->"Протокол" та назвемо його Protocol. У інспекторі атрибутів встановимо властивості протоколу:

  • "Геометрія: ширина" — 500.
  • "Геометрія: висота" — 250.
  • "Показати колонки" — tm;lev;mess.
  • "Рівень" — -1, відображення потокових порушень будь-якого рівня.
  • "Розмір, секунд" — 0, відображати порушення на будь-яку глибину.
  • "Період стеження, секунд" — 1.

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

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

Рис. 5.2.4. Вигляд мнемосхеми з низкою елементів.

На цьому процедуру створення мнемосхеми будемо вважати закінченою. Збережемо нову бібліотеку віджетів "KM 101" та приступимо до етапу розташування нашої мнемосхеми у дереві проекту "Старт".

Розташуємо нашу мнемосхему у гілці "Старт"->"Коренева сторінка"->"Група 1"->"Мнемосхеми", шляхом обрання пункту меню "Бібліотека: CM101"->"AT 101", у контекстному меню пункту сторінки проекту "Мнемосхеми". Ідентифікатор нової мнемосхеми встановимо у "2", при цьому поле ім'я залишимо порожнім — 2.

Далі треба здійснити вже знайому нам, з попередньої глави, операцію, а саме — встановлення зв'язків на раніш створені параметри контролерів. Для цього, відкриємо вкладку "Зв'язки" (Рис.5.2.5) діалогу редагування властивостей мнемосхеми, де ми побачимо дерево з елементами "A1_Ti", "A1_To", "A2_Ti" та "A2_To". Розгорнувши будь-який з елементів ми побачимо гілку "Parameter", у якій ми маємо вказати, або обрати, адресу значень наших атрибутів "Ti" та "To", відповідно. У процесі заповнення елементів, частина властивостей треба вказувати постійними:

  • "pName" — val:AT101_1 Ti.

Як і у випадку з групою графіків у попередньому розділі, для комплексних параметрів об'єкту-тегу "ModBus.CM101.TE1314_1" та "ModBus.CM101.CB102" можна вказати тільки параметр, а атрибути розставляться автоматично.

Рис. 5.2.5. Вкладка "Зв'язки" діалогу редагування властивостей мнемосхемы.

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

Рис. 5.2.6. Мнемосхема з чотирма підключеними сигналами, комплексними параметрами об'єкту-тегу та протоколом.

Зауважте, що вихід значення комплексного параметру об'єкта-тегу за границі порушень відзначається миготінням через аварійний колір для: параметру, об'єкту сигналізації та жовтого кола внизу. Крім миготіння, при порушенні здійснюється монотонна сигналізація (часто на бузер) та синтез мови з промовою позиції параметру, вказаної у полі зв'язку "spName" (Рис.5.2.5), якщо доступний відповідний синтезатор мови. При активації порушення, праворуч та праворуч-внизу активуються кнопки з індикацією типу повідомлення, а по натисканню на них здійснюється квітація відповідного типу повідомлення. По натиску на миготливе жовте коло праворуч-знизу квитуються всі повідомлення. Факт присутності порушення також відображається записом у протоколі, який ми додали. Щоб побачити вихід за границю порушення Ви можете встановити значення продуктивності вентилятору у 100 (Рис.4.2.9). Детальніше про концепцію роботи з порушеннями можна почитати у "Як зробити Порушення, сигналізація та повідомлення".

Історію порушень можемо переглянути у документі "Протокол порушень", який доступний при обрані виду "Документ" (Рис.5.2.7).

Рис. 5.2.7. Документ "Протокол порушень".

Дискретний комплексний параметр об'єкту-тегу "ModBus.CM101.CB102", представлений нами у вигляді шарового крану, є активним. Тобто його можна обрати, отримавши панель управління праворуч (Рис.5.2.6), а також передати команди (відкрити або закрити). Команди можна передавати з панелі управління або через контекстне меню. Всі дії оператора, з керуючого впливу, протоколюються та документ протоколу можна переглянути при обрані виду "Документ" (Рис.5.2.8).

Рис. 5.2.8. Документ "Протокол втручань".

5.3 Створення нового комплексного елемента

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

  • Створення віджету "Повітряний холодильник" на основі примітиву "Елементарна фігура".
  • Створення фінального-скомпонованого віджета "Холодильник" на основі примітиву "Група елементів".

5.3.1 Створення віджета "Повітряний холодильник" на основі примітива "Елементарна фігура"

Віджет будемо створювати у раніш нами створеній бібліотеці "КМ 101". Для цього клікаємо правою кнопкою маніпулятору "миші" по пункту цієї бібліотеки та обираємо пункт меню "Бібліотека: originals"->"Елементарна фігура", як це показано на рисунку 5.3.1.1, та називаємо новий елемент air_cooler (Повітряний холодильник).

Рис. 5.3.1.1. Додання віджету до бібліотеки "KM 101" на основі примітиву "Елементарна фігура".

Після підтвердження з'явиться новый віджет з ім'ям "Повітряний холодильник". Оберемо його у переліку віджетів бібліотеки "KM 101" та відкриємо для редагування, за посередництвом контекстного меню нового елемента (Рис.5.3.1.2). У інспекторі атрибутів встановимо властивості:

  • "Геометрія: ширина" — 200.
  • "Геометрія: висота" — 200.
  • "Заповнення: колір" — lightgrey. Колір можна задавати, як за допомогою назв кольорів, так і у форматі #RRGGBB (#RRGGBB-AAA).
Рис. 5.3.1.2. Первинна конфігурація віджету.

Тепер зобразимо візуальне представлення віджета, що можна здійснити двома способами:

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

Додаткову інформацію про редактор можна отримати тут.

Рис. 5.3.1.3. Вхід у режим рисування віджета, заснованого на примітиві "Елементарна фігура".

У нашому прикладі ми скористаємося другим способом. Для чого, у полі "Перелік елементів" інспектору атрибутів, введемо нижченаведений перелік та натиснемо "Ctrl"+"Enter":

line:(20|80):(100|20)
line:(100|20):(180|80)
line:(180|80):(100|140)
line:(100|140):(20|80)
line:(100|20):(100|140)
line:(20|80):(180|80)
line:(50|165):(100|140)
line:(100|140):(150|165)
line:(150|165):(50|165)
fill:(20|80):(100|20):(180|80):(100|140)
fill:(50|165):(100|140):(150|165)

У нашому випадку, всі точки вказано статично, так як не передбачено динамізації та зміни координат у режимі виконання, та всі інші параметри залишено по замовченню. Відтак, наш віджет прийме вид на рисунку 5.3.1.4.

Рис. 5.3.1.4. Зображення, що відповідає "Переліку елементів" віджету.

Створимо іконку нашого віджета, яку буде видно у дереві віджетів бібліотеки "KM 101" (Рис.5.3.1.5).

Рис. 5.3.1.5. Створення іконки віджета.

На цьому процес створення першого віджета можна вважати завершеним. Перейдемо до етапу компонування та створення результуючого віджету.

5.3.2 Створення фінального-скомпонованого віджету "Холодильник" на основі примітиву "Група елементів"

Фінальний віджет будемо створювати у бібліотеці "KM 101", для чого клікаємо правою кнопкою маніпулятору "миша" по цій бібліотеці та обираємо примітив "Група елементів", як це показано на рисунку 5.3.2.1. Назвемо новий елемент — elCooler (Холодильник).

Рис. 5.3.2.1. Додання віджету до бібліотеки "KM 101", на основі примітиву "Група елементів".

Після підтвердження з'явиться новый віджет з ім'ям "Холодильник". Оберемо його у переліку віджетів бібліотеки "KM 101" та відкриємо для редагування. У інспекторі атрибутів встановимо властивості:

  • "Геометрія: ширина" — 250.
  • "Геометрія: висота" — 200.

Візьмемо раніш створений елемент "Повітряний холодильник (air_cooler)" та перетягнемо його — натиснемо на ньому ліву кнопку маніпулятору "миша" та пересунемо курсор до області щойно створеного виджета, де відпустимо кнопку (Рис.5.3.2.2).

Рис. 5.3.2.2. Перетягнення (Drag&Drop) віджету "air_cooler" у віджет-контейнер "elCooler".

У результаті з'явиться вікно діалогу з пропозицією ввести ідентифікатор та ім'я нового виджета. Ідентифікатор та ім'я можуть бути задані довільно. Ми введемо ідентифікатор air_cooler, та ім'я залишимо порожнім та воно успадкується від батька — елемента "air_cooler". Таким чином, щойно створений віджет всередині контейнеру "elCooler" успадкує елемент "Повітряний холодильник (air_cooler)". Після підтвердження вводу ідентифікатору та ім'я, віджет "Повітряний холодильник (air_cooler)" додасться до нашого віджету-контейнеру "elCooler" (Рис.5.3.2.3). У інспекторі атрибутів встановимо для нього властивості:

  • "Геометрія: x" — 25.
  • "Геометрія: y" — 0.
Рис. 5.3.2.3. Додання успадкованого віджету "air_cooler".

Далі, розгорнемо пункт меню бібліотеки "Елементи мнемосхеми", знайдемо там елемент "Вентилятор 2 (cooler2)" та перетягнемо його на віджет-контейнер. Цей елемент буде динамічно відображати інтенсивність роботи повітряного холодильника. Для нового віджета введемо ідентифікатор cooler2 та ім'я знову залишимо порожнім, після чого віджет "Вентилятор 2 (cooler2)" додасться до нашого віджета-контейнеру "elCooler". Таким чином, щойно створений віджет, всередині контейнеру "elCooler", успадкує елемент бібліотеки "Елементи мнемосхеми" — "Вентилятор 2 (cooler2)". У інспекторі атрибутів встановимо властивості:

  • "Геометрія: x" — 75.
  • "Геометрія: y" — 30.
  • "Геометрія: z" — 10. Підняти елемент над всіма можна з панелі "Функції видимості віджетів".
  • "Колір1" — #FFFF00-200, добавили альфа канал — прозорість 200 ("0" - повністю прозорий, "255" - повністю непрозорий), рисунок 5.3.2.4.
  • "Колір2" — #FF0000-200, добавили альфа канал — прозорість 200.
Рис. 5.3.2.4. Зміна прозорості кольору заповнення успадкованого віджету "cooler2".

Тепер, у віджеті-контейнері "elCooler" додамо два текстових поля, заснованих на примітиві "Текст", з метою відображення вхідної та вихідної температури потоку. Для цього, виділимо віджет "Холодильник" та, на панелі візуальних елементів бібліотеки "KM 101", оберемо пункт меню примітиву "Текст", як це показано на рисунку 5.3.2.5. Для першого текстового поля введемо ідентифікатор Ti та, у інспекторі атрибутів, встановимо властивості:

  • "Геометрія: x" — 5.
  • "Геометрія: y" — 20.
  • "Геометрія: ширина" — 70.
  • "Геометрія: висота" — 35.
  • "Вирівнювання" — У центрі.
  • "Шрифт" — Arial 14 1. Зміну шрифту можна здійснити у діалозі, який відкривається по натиску на ключик у полі редагування, (Рис.5.3.2.7).
  • "Текст" (Рис.5.3.2.8):
%1
град.C
  • "Кількість аргументів" — 1 (Рис.5.3.2.9):
    • "Аргумент 0: тип" — Реальний.
    • "Аргумент 0: значення" — 300.25, задано лише для наочності та у режимі виконання воно буде замінено реальним значенням вхідної температури.
    • "Аргумент 0: конфігурація" — 3;f;2.
Рис. 5.3.2.5. Додання нового елемента, заснованого на примітиві "Текст".
Рис. 5.3.2.6. Указання геометрії віджета "Ti".
Рис. 5.3.2.7. Зміна розміру шрифта для виджета "Ti".
Рис. 5.3.2.8. Зміна поля "Текст" та вказання наявності аргументу, для віджета "Ti".
Рис. 5.3.2.9. Конфігурація аргументу віджета "Ti".

Тепер, з метою створення аналогічного віджета для вихідної температури, скопіюємо віджет "Ti". Вставимо скопійований віджет та вкажемо йому ідентифікатор To (Рис.5.3.2.10). У інспекторі атрибутів встановимо властивості:

  • "Геометрія: x" — 175.
  • "Геометрія: y" — 20.
Рис. 5.3.2.10. Віджет "To".

Тепер додамо віджет, заснований на примітиві "Елемент форми" (Рис.5.3.2.11), який будемо використовувати для обрання завдань продуктивності холодильника. Вкажемо ідентифікатор cw (Рис.5.3.2.12) та, у інспекторі атрибутів, встановимо властивості:

  • "Активний" — true.
  • "Геометрія: x" — 60.
  • "Геометрія: y" — 158.
  • "Геометрія: ширина" — 60.
  • "Геометрія: висота" — 40.
  • "Геометрія: z" — 10. Підняти елемент над всіма можна з панелі "Функції видимості віджетів".
  • "Тип елементу" — Combo Box.
  • "Шрифт" — Arial 14 1.
  • "Значення" — 200.
  • "Конфігурація":
0
50
100
150
200
Рис. 5.3.2.11. Додання віджета, заснованого на примітиві "Елемент форми".
Рис. 5.3.2.12. Заповнення параметрів ComboBox "cw".

Для відображення одиниці виміру продуктивності холодильника додамо ще один віджет, заснований на примітиві "Текст". Робимо ту-ж процедуру, що й для віджета "Ti". Вкажемо ідентифікатор dimension (Рис.5.3.2.13) та, у інспекторі атрибутів, встановимо властивості:

  • "Геометрія: x" — 125.
  • "Геометрія: y" — 168.
  • "Геометрія: ширина" — 80.
  • "Геометрія: висота" — 20.
  • "Вирівнювання" — У центрі.
  • "Шрифт" — Arial 14 1.
  • "Текст" — об./хвил..
Рис. 5.3.2.13. Додання віджету "dimension", заснованого на примітиві "Текст", та зміна його параметрів.

Для додання логіки обробки віджету "Холодильник (elCooler)", відкриємо діалог редагування властивостей цього візуального елемента та перейдемо до вкладки "Обробка". На цій вкладці ми побачимо дерево атрибутів віджету та поле тексту програми обробки атрибутів. Для вирішення нашого завдання треба додати три атрибуту: Ti, To, Cw (Рис.5.3.2.14); для чого треба розгорнути кореневий елемент ".", обрати будь-який елемент всередині нього та натиснути кнопку "Додати атрибут" знизу.

Далі, ввімкнемо на обробку атрибут value комбобоксу "cw", як це показано на рисунку 5.3.2.15. Аналогічно ввімкнемо на обробку атрибут arg0val для Ti и To, а також атрибут speed елементу "cooler2".

Рис. 5.3.2.14. Додання трьох атрибутів елементу "elCooler" бібліотеки "KM 101".
Рис. 5.3.2.15. Включення на обробку атрибуту "value" комбобоксу "cw".

На завершення, встановимо мову користувацького програмування "JavaLikeCalc.JavaScript" та напишемо саму цю програму обробки віджета:

Ti_arg0val = Ti;
To_arg0val = To;

for(ev_rez = "", off = 0; (ev_wrk=event.parse(0,"\n",off)).length; )
    if(ev_wrk == "ws_CombChange:/cw") Cw = cw_value;
    else ev_rez += ev_wrk+"\n";
event = ev_rez;

cw_value = Cw;
cooler2_speed = Cw/5;

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

Отримана вкладка "Обробка" віджету "elCooler" бібліотеки "KM 101" буде мати вигляд, показаний на рисунку 5.3.2.16.

Рис. 5.3.2.16. Результуюча вкладка "Обробка" віджету "elCooler" бібліотеки "KM 101".

Закриємо діалог редагування властивостей візуального елемента, створимо іконку нашого елемента, закриємо внутрішнє вікно редагування та збережемо це все.

На цьому розробку комплексного елемента можна вважати закінченою.

5.3.3 Додання комплексного елементу на мнемосхему

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

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

Рис. 5.3.3.1. Мнемосхема з нашими комплексними елементами.

Збережемо нову мнемосхему та закриємо її вікно. Далі, перейдемо до проекту та відкриємо цю мнемосхему у дереві проекту "Старт"->"Коренева сторінка"->"Група 1"->"Мнемосхеми"->"AT 101". Як можна зауважити, наші нові елементи з'явилися тут автоматично та нам залишилося лише підключити зв'язки до них. Для цього відкриємо діалог редагування властивостей мнемосхеми на вкладці "Зв'язки" (рис.5.3.3.2). На цій вкладці ми побачимо дерево з елементами "AT101_1" та "AT101_2", розгорнувши будь-який ми побачимо гілку "Параметр" з атрибутами "Ti", "To" та "Cw". Таким чином, у полі "Параметр" ми можемо просто вказати адресу параметра prm:/LogicLev/CM101/AT101_1 та prm:/LogicLev/CM101/AT101_2, відповідно, а атрибути буде розставлено автоматично.

Рис. 5.3.3.2. Вкладка "Зв'язки" діалогу редагування властивостей мнемосхеми.

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

Рис. 5.3.3.3. Результуюча мнемосхема.

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

6 Висновок

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

При побудові інтерфейсу ТП ми розглянули всі три рівні складності, а відтак і отримано уявлення про потрібний кваліфікаційний рівень програміста SCADA.

Збір та обробку даних ми розглянули та здійснили у різні способи, від простого-типового та до відображення моделі даних ПЛК, побудованого на основі OpenSCADA. Тобто, отримано уявлення про джерела даних SCADA-систем та доступу до них за допомогою мережевих інтерфейсів та протоколів обміну, підтримку яких реалізують відповідні модулі OpenSCADA.

І звісно, ми розглянули методи розповсюдження (дистрибуції) OpenSCADA, способи її встановлення та отримання потрібного оточення, як то: серверу SCADA, ПЛК OpenSCADA та робочого місця оператору.

Інформація про OpenSCADA цим документом не обмежується та, у вирішені специфічних питань, Ви маєте використовувати всю доступну документацію та приклади демонстраційних конфігурацій-моделей OpenSCADA, користуючись тим самим перевагами "відкритих вихідних текстів (OpenSource)". Окремо тут треба ще раз відзначити "Посібник по програмі", "Як зробити ..." та "Динамічну модель реального часу АГЛКС", як більш повні джерела інформації про OpenSCADA.

7 Посилання