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

Other languages:
English • ‎российский • ‎українська
Constr.png Common revision and translation

Автор: Роман Савоченко, Максим Лисенко (2010-2012)
Відео-доповнення: ftp://ftp.oscada.org/OpenSCADA/0.8.0/doc/ru/QuickStart.mkv (RU)

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

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

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

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

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

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

  • QT — інструментарій розробки ПЗ, за допомогою якого, зокрема, створено модулі QTStarter (пускач модулів OpenSCADA на бібліотеці Qt), QTCfg (графічний конфігуратор OpenSCADA) та Vision (редактор та виконавець робочих користувацьких інтерфейсів СВУ). QT це ранній запис, використаний авторами для бібліотеки Qt.
  • Блокування — умовна границя технологічного параметру по подоланню якої

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

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

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 — "протокол передачі гіпертексту") — протокол прикладного рівня передачі даних, частіш за все у вигляді гіпертекстових документів.
  • 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)".

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

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 з вихідних текстів.

Constr.png The common revision and translation goes here. Move some sentences from part 2 to 3.

3 Initial configuration and start

After successful installation of the OpenSCADA with the database of "AGLKS" model no pre-configuration is required. If you want to perform a particular configuration, which differs from the base, then use the document of description the OpenSCADA program.

At.png The demonstration of OpenSCADA based on the "AGLKS" model database is not the same as that is usually provided by the commercial software vendors to demonstrate the possibilities, but to exclude or to complicate the normal operations by limiting the functions. Demonstration of OpenSCADA is fully-functional system that provides examples of implementation and configuration of various components. Based on the "AGLKS" model database and other OpenSCADA models one can easily create own projects, using the given resources.

You can execute the OpenSCADA with "AGLKS" model database from the menu of the desktop environment in the "Graphics" section, "Model 'AGLKS' on open SCADA system" with the characteristic icon (Fig. 3.1).

Fig. 3.1. Menu item of the desktop environment to start the demonstration of OpenSCADA.

Start also can be done from the console by the command:

$ openscada_AGLKS

At.png When you start OpenSCADA from the console with the command "$ openscada" , the system is launched without any configuration and the result is the request of the user name and password to login. By default, the system provides OpenSCADA super user "root" (password "openscada") and unprivileged "user" (password "user"), which have no relation to the users of the operating system. Starting the OpenSCADA in this way makes sense only if it is done from the OS administrator ("root") or in daemon mode.

After start we'll get the window of the OpenSCADA graphical configurator — QTCfg (Fig.3.2) with the opened root page. Demo database specifically configured so that the first window you'll see after start it is the configurator's window. You can then open the window for creating graphical user interfaces, as well as run the user interface project's execution.

Fig. 3.2. OpenSCADA configurator — QTCfg, the root page.

Configurator of OpenSCADA is the main and sufficient instrument for the configuration of any system's component. Like many other components of OpenSCADA, configurator is implemented as a module. Besides the QTCfg configurator there may be available other configurators that performs the same function, but implemented on the basis of other technologies. For example, these are the Web-configurators: WebCfgD and WebCfg.

All actions in the future, we will make only in the configuration tool QTCfg, although all of them can be done in other configurators.

The structure of the configurator's window interface can be considered in detail by the reference. It is more important now for us to examine all the available interfaces OpenSCADA, so click next to last icon in the top on the toolbar. After clicking on this icon the window of user interface development will be opened (Fig.3.3).

Fig. 3.3. Window of the UI development.

Then we can start the "AGLKS" project's execution. To do this, select it in the list of projects and run by clicking on the first left icon on the toolbar or in the the popup menu. The result will be the window of user interface (Fig.3.4).

Fig. 3.4. Window of the user interface of the "AGLKS" project.

Building and executing of the user interfaces is implemented by the Vision module of the "User interfaces" subsystem. In addition to this module it can be accessed the other modules of visualization. For example, OpenSCADA provides the WebVision module, which allows to execute projects, previously developed in the "Vision" interface module, through the Web-based technologies and standard Web-browser. All actions in the future we will make only in the interface of the "Vision" module.

So we ran the demonstration of OpenSCADA and familiarized with the main set of tools. In the future we will use them for configuration of OpenSCADA, creating the tasks of data acquisition, binding the collected data with the purpose of their processing and making the impacts, as well as to create the visualization user interface of the received data and to make the control actions.

Lets close the window of the "AGLKS" project's execution and the window of the user interface development to prepare for the study of the following chapters.

The whole process of SCADA-system's configuration to perform the "top level" functions can be divided into two stages:

  • The configuration of data sources and creation the database (DB) of the parameters from these sources.
  • Formation of a visual presentation of technological process (TP) data by creating the operator's interface in the form of: mnemonic schemes, groups of graphs (trends), groups of contours, documents, etc.

3.1 Creation the user's project from scratch

All the actions in the following sections are described in the "AGLKS" (demonstration) model database environment with the purpose of the widest and the most descriptive presentation of the configuration process, with the ability to connect to a real-live data source, realized on the basis of the gas compressor station TP model. However, it is necessary to describe the process of creation a user project from scratch, which is obviously your final goal. On the basis of a new user's project you can perform all the following steps with the "AGLKS" model database, but with an eye to your own data sources of a new project.

To start a clean user's project there is the item "OpenSCADA System" with the characteristic icon in the desktop environment menu, the "Graphics" section (Fig.3.1.1).

Fig. 3.1.1. Menu item of the desktop environment to start the clean user's project.

The start can also be done with the following command:

$ openscada_start

Starting from version 0.9 of OpenSCADA the command call cause creation the dialog for new project creation or using pre-installed and user's projects. For selection and new project name dialogs building supported the dialog programs, into the priority checking: dialog (for active terminal present), kdialog (Fig.3.1.2), "zenity" and "Xdialog". Let select the menu item "<New project>" and enter the project name "start" into next dialog.

Fig. 3.1.2. Dialog of selection of new project creation or using pre-installed and user's projects.

A clean user's project does not contain any project-specific configuration and is configured to work in the user's directory "/.openscada", with the main SQLite database in the file "DATA/MainSt.db". It is easier to create a complex SCADA-system's project using the libraries of API functions of the OpenSCADA object model and libraries of graphic elements, as well as with the help of other OpenSCADA libraries. To use the OpenSCADA libraries, stored in a database file, they need to be connected, added in the "SQLite" database module's object (Fig.3.1.3), as well as it is necessary to set the address and the database charset to "UTF-8" (Fig.3.1.4).

Fig. 3.1.3. Add the "SQLite" DB object.
Fig. 3.1.4. "SQLite" DB object of OpenSCADA library.

OpenSCADA distributions supplied with a number of libraries in the form of "SQLite" database files (Table 3.1), which, when you run the clean user's project are placed to the "LibsDB/" directory. According to this list, lets add them in the "SQLite" database module's object, set the "Enabled" flag and save. Next, to load the library contents it is necessary to enable the database and click "Download this system from the database", but during the loading some of new objects are disabled so it's easier to complete a exit user's project and start over again.

Table 3.1. OpenSCADA libraries included in the distribution.

ID Name Address Languages/charset
OscadaLibs Functions libraries ./LibsDB/OscadaLibs.db EN,RU,UK/UTF-8
vcaBase VCA: Main libraries ./LibsDB/vcaBase.db EN,RU,UK/UTF-8
vcaTest VCA: Tests ./LibsDB/vcaTest.db EN,RU,UK/UTF-8
vcaElectroEls VCA: Electrical elements library of the user interface ./LibsDB/vcaElectroEls.db EN,RU,UK/UTF-8

After the addition of OpenSCADA libraries you'll get an environment ready for addition of data sources and the formation of the new SCADA-system project's interface.

4 Working with Data Sources

The main function of any SCADA-system is to work with data sources of realtime, namely the inquiry of programmable logic controllers (PLC) and simple modules of CPI. For more details see the document "Data acquisition in OpenSCADA".

Support of the one or another data source depends on the protocol or API, through which the source provides its data, and the availability for the protocol/API the module in the subsystem "Data acquisition" in OpenSCADA. The total list of modules of the subsystem "Data acquisition" and documentation on them can be found here in the appropriate table part.

Obtained from sources data subsequently are archived, processed and used for visual representation for the operator of TP.

4.1 Data acquisition from the TP device

As an example lets examine and create the inquiry for the air cooler device. Demo database contains the real-time model of the compressor station with six compressors. Data for two devices of air coolers "AT101_1" and "AT101_2" of the compressor station "KM101" are available via the ModBus/TCP protocol on the 10502 port.

We will create the inquiry controller's object via the ModBUS/TCP protocol and get these data, thereby practically made the task of inquiry of real data, because from the external device our configuration will be different only in address of the device, addresses of the ModBUS registers and maybe the interaction interface.

There is "ModBUS" module in the "Data acquisition" subsystem for the data acquisition via "ModBUS" protocol in OpenSCADA. To add a new controller we will open the page of the "ModBUS" module in the configurator ("Demo Station"->"Data acquisition"->"Module"->"ModBUS") and in the pop-up menu of the "ModBUS" item lets click "Add" (Fig. 4.1.1).

Fig. 4.1.1. Adding the controller in the "ModBUS" module of the "Data acquisition" subsystem.

At the result of our actions the dialog window will appear (Fig.4.1.2) to enter the ID and name of the new controller. IDs of any objects in OpenSCADA are limited by 20 characters and they should be entered using English alphabet characters and numerals. In addition, it is desirable to start the ID with the letter. This is due to the fact that the identifier can later be used in scripts. The OpenSCADA objects' names are limited by 50 characters and can contain any characters. The names are usually displayed. If the name field is blank, instead it the identifier will be displayed. Enter the ID "KM101" and the name "KM 101".

Fig. 4.1.2. Dialog to specify the ID and name of the new object.

After confirmation we have a new controller's object. Lets choose it in the configurator and get acquainted with its settings (Fig.4.1.3).

Fig. 4.1.3. Main tab of the controller's object settings of the ModBUS module.

Settings of the controller's object, as a rule, are specific for the different types of data sources and protocols. You can familiarize in details with the settings of the controller's object of the ModBUS module using the link. We'll examine the general configuration of the controller's object and the key settings for the ModBUS module.

Before the connection configuration with your controller you need from the controller's documentation to find the settings of network interfaces and protocols, and also, in the case of "ModBus" using, to get the association table for external and internal controller's signals with the numbers of "ModBus" registers.

With the help of the page of the controller's object in the section "Status" may be primarily assessed the current state of the controller's object and the real state of connection with the physical controller, as well as it can be quickly changed. For example, field "Status" contains the code of error and the textual description of the current state of connection with the controller, in this case the controller's object is disabled. We are able to enable it and start by setting the flags beside the appropriate fields. Enabled controller's object initializes the parameters objects, the running one runs the acquisition task and provides an opportunity to transmit data to the controller through the attributes of the parameters. The DB field indicates which database to store in the configuration of the object. We will store the data to main database, ie leave it by defaults.

In the "Config" section the configuration of the controller's object is directly contained:

  • "ID" and "Name" are the fields, we've just entered at the object's creation. The Name can be changed right here, but the ID can not be changed so simply. If you want to change the ID you must Cut (Ctrl+X) and Paste (Ctrl+V) the object and enter the desired ID.
  • "Description" may contain the detailed description and purpose of the controller's object. In our case, the value of this field is not principal.
  • "Enable" and "Run" indicated the state, in which to transfer the controller's object at start of OpenSCADA. Lets set both fields.
  • "Parameters table" — contains the name of the database's table in which to store the configuration of parameters of the controller. Leave it default.
  • "Acquisition schedule" — contains the configuration of the scheduler to run the inquiry task. To get the description of the format of the configuration of the field you can from the tooltip. The single number indicates the periodicity of run in seconds. Let it be one second.
  • "Gather task priority" — indicate the priority of the task (from -1 to 99). Priorities above zero are meaningful only when you start OpenSCADA from the privileged user. Leave this field unchanged.
  • "ModBUS protocol" — indicates to variant of the ModBUS protocol. The protocol variants possible "TCP/IP", "RTU" and "ASCII". At the moment we are interested in the option "TCP/IP", so leave it as is. The protocol variants "RTU" and "ASCII" need for set at case communication with the controller by serial interfaces, typically "RS-485".
  • "Transport address" — indicates the outgoing transport of the subsystem "Transports", which is used to connect to the controller. In the case of "TCP/IP" option we need the transport module Sockets, and in case variants "RTU", "ASCII" and serial interfaces we need the transport module Serial. We'll examine the creating of the outgoing transport in "Sockets" and "Serial" in details below.
  • "Destination node" — indicates the node of data source or conroller in ModBUS network. In our case, it should be "1".
  • "Data fragments merge" — includes the merging not related fragments of registers in the single block of the request, up to 100 registers, instead generating individual requests. Allows you to reduce the total time of the inquiry. Lets set this option.
  • "Using write functions for more items (0x0F,0x10)" — instead one-item write will used multi-items functions. Leave this field unchanged.
  • "Connection timeout" — indicates how long to wait for the response from the controller and after which to report an error of connection. Zero indicates the use of time of transport. Unchanged.
  • "Restore timeout" — specifies the time in seconds after which if there is no connection to retry to reconnect.
  • "Maximum request block size (bytes)" — maximum size (bytes) of registers and coils blocks set. Usefull for some controllers with like limits. Unchanged.

Lets save our changes to the database by clicking the second left icon on the toolbar.

Now, in the same manner as the controller's object, let's create the outgoing transport in the module "Sockets" ("Demo Station" ->"Transports"->"Sockets") through the context menu (Fig.4.1.4). And let's call the transport as well as the controller: "KM101" and the name "KM 101". Note that in the "Item type" of the dialog (fig.4.1.2) you should choose the "Output transport.

Fig. 4.1.4. Adding the outgoing transport in the module "Sockets" of the subsystem "Transports".

The configuration page of outgoing transport is shown in Fig.4.1.5. This page also contains the section of the status and operational control. In the "Status" field the textual description of the current state of transport is contained. We can run it for execution by checking the box in front of the appropriate field. Running object of the transport initiates the connection to the external node. Field DB indicates the database to store the configuration of the object. We will store it in the main database.

Fig. 4.1.5. Configuration page of the outgoing transport of the "Sockets" module of the subsystem "Transports".

In the "Config" section the configuration of the transport object is contained:

  • "ID" and "Name" contain the titles, which we entered when creating the object.
  • "Description" — may contain the detailed description and purpose of the object.
  • "Address" — specifies the type, address and mode of connection with the remote station. You can view the record format in the tooltip. Let's set this field to the value "TCP:localhost:10502".
  • "To start" — indicates in what state to transfer an object at start of OpenSCADA. Let's set the field.
  • "Timings" — indicate the duration of waiting for the response from the remote station. You can view the record format in the tooltip. Let us leave the value unchanged.

Other types transports created by like to "Sockets" method, but configuration typical different only at record format for address and timings. In case of transport module "Serial" into address field write the path to serial device, speed, and format. For converters USB->Serial that address you need learn into operation system, for example by console command "$ dmesg", just after the converter connection.

Let's save the transport and return to the configuration field "Transport address" of the controller's object and select the address "Sockets.KM101". Setting the controller's object is finished, enable it by set flag "Enabled". The next step is configuration and choose the data you need to query from the controller. This setting is done by creating an object "Parameter" of the controller. The "Parameter" object allows you to describe the list of data obtained from the comptroller and to transmit them to the environment of OpenSCADA.

To add a new object of the parameter we will open in the configurator the page of our controller's object and on the popup menu of item "KM101" we'll click "Add". The parameter's object we'll call "AT101_1" and the name "AT 101_1".

The configuration page of the obtained parameter is shown in the Fig.4.1.6. This page contains the section of status and operational control. In the "Type" field it is contained the ID of the type of the parameter, in this case it is only possible the "Standard" type (std). We can enable the parameter by checking the box of the appropriate field. The enabled parameter is involved in the process of exchange with the controller.

Fig. 4.1.6. Configuration page of the controller's parameter "ModBUS".

In the "Config" section the configuration of tge parameter's object is contained:

  • "ID" and "Name" contain the titles, which we entered when creating the object.
  • "Description" — may contain the detailed description and purpose of the object.
  • "To enable" — indicates in what state to transfer an object at start of OpenSCADA. Let's set the field.
  • "Attributes list" — contains the configuration of attributes of parameters in relation of them to the registers and bits of ModBUS. You can view the record format in the tooltip. Let's set the contents of the text field as follows:
R:100:r:Ti:T input
R:101:r:To:T output
R:102:rw:Cw:Productivity.

Similarly, create the second option: "AT101_2" with the name "AT 101_2". The list of attributes fro it let's set in:

R:103:r:Ti:T input
R:104:r:To:T output
R:105:rw:Cw:Productivity.

Let's save the both objects of the parameter. Now we can enable and run our controller to initiate the exchange. To do this, go back to the page of our controller's object and in the "Status" section let's set the flag "Run". If we do not miss something, the exchange is successfully started and in the "Status" field we'll get something like this, as it is shown in the Fig.4.1.7.

Fig. 4.1.7. Page of the controller's object if the exchange with the physical controller is successful.

In the case of a successful exchange with the physical controller, we'll obtain the described data of the controller in the infrastructure of OpenSCADA. You can see these data on the tab "Attributes" of our parameters AT101_1 (Fig.4.1.8) and AT101_2. Because the inquiry is regularly and at intervals of a second, then we can observe their changes by clicking the button "Refresh current page" on the toolbar.

Fig. 4.1.8. Page of described attributes of the AT101_1 parameter.

The configuration of data acquisition is complete.

4.2 TP data processing

Frequently the initial data obtained from the data source are the "raw", ie unprepared or uncomfortable for the visual presentation, so you need to perform this preparation. In our example, we received the data that comes in the code from the scale inside the controller. Our task is to perform the calculation of real values from the received data. Data processing in OpenSCADA can be done, either during the visualization, and in the subsystem "Data acquisition". However, the mixing of the visualization process and processing of initial data makes the configuration confusing and makes the obtained images of the visualization unsuitable for reuse. For this reason, let's make the preparation of data in the subsystem "Data acquisition".

Calculations in the subsystem "Data acquisition" are done via the module of logic level LogicLev and the templates of parameters of the subsystem "Data acquisition". To familiarize with the concept of "logical level" you can here.

To make calculations in the module of the logic level you must first create the template of the parameter of subsystem "Data acquisition". To do this, let's open the page of templates' library "Main templates" ("Demo Station"->"Data acquisition"->"Template library"->"Main templates") and through the context menu we will create the template object "airCooler" with the name "Air cooler". The configuration page of the resulting object is shows in the figure 4.2.1. This page contains the "State" section and the section of the operational control. We can make the template accessing by checking the box next to the corresponding field. Accessing templates can be connected to the data acquisition parameters, and the parameters will make calculations on this template. In the "Used" field the number of objects that use this template to calculate the image of the parameter is indicated. In the "Config" section only the familiar for us configuration fields are present.

Fig. 4.2.1. Configuration page of the template's object.

The basic configuration and the formation of the template of parameter of data acquisition is made in the tab "IO" (Fig.4.2.2) of the template. The detailed description of the process of the template's formation can be found here.

Let's create in the template two properties fro the inputs ("TiCod", "ToCod"), two for outputs ("Ti","To") and one clear property ("Cw"). For the "TiCod", "ToCod" and "Cw" let's set the "Configure" flag to the "Link", this will let to link to them the "raw" source. For the "Ti" and "To" let's set the "Attribute" flag to the "Read only", and for the "Cw" — "Full access", we make it to form the three attributes of the resulting parameter of the data acquisition: two — read only and one with the full access.

The program language let's set to "JavaLikeCalc.JavaScript", and the program:

Ti = 150*TiCod/65536;
To = 100*ToCod/65536;
Fig. 4.2.2. Tab "IO" of the configuration page of the template's object.

Let's save the resulting template and set the accessibility flag.

Now we'll create the controller's parameters' objects in the "LogicLev" module of subsystem "Data acquisition". The controller and its parameters in the module "LogicLev" are identical to the previously created in the module "ModBUS" and they are created on the page: "Demo station"->"Data acquisition->"Module"->"Logic level". The object of the controller and the parameters will be called identical to the objects in the module "ModBUS".

The object of the controller of the module "LogicLev" (Fig.4.2.3) has no specific settings and the default ones may not be touched except the "Calculation planning" field, which will be set to one second. Before adding parameters, you must turn on the controller by checking the "Enabled" flag.

Fig. 4.2.3. Main tab of the configuration of the object of controller of the LogicLev module.

The object of the parameter of controller of the "LogicLev" module (Fig.4.2.4) has the specific setting "Type", where you need to set "Logical" (std) and into setting "Parameter template" select the address of the template, we have just created.

Fig. 4.2.4. Configuration page of the "LogicLev" controller's parameter.

In addition to the basic configuration of the parameter it is necessary to configure the attached template (Fig. 4.2.5). Configuration tab of the template appears in the parameter's mode "Enable". To enable the parameter it is possible by the previously enabling the controller. The flag "Only attributes are to be shown" allows you to set apart each link (Fig.4.2.6). Since we are made the following format of linkage in the template "Parameter|Ti", then all three links we can set simply by typing an address to the parameter in the "ModBus" controller. We shall specify the following addresses "ModBus.KM101.AT101_1" and "ModBus.KM101.AT101_2" in the appropriate parameters.

It should be noted that all the input fields addresses of objects in OpenSCADA provide a mechanism to set the address. This mechanism involves elemental choice, during which there is a movement in the interior. For example, typing the address "ModBus.KM101.AT101_1" first we will be able to choose the type of data source, including the "ModBus". By selecting "ModBus" in the list of available items for selection will be added to the module controllers "ModBus", among which will be "ModBus.KM101". Select the item "ModBus.KM101" add to the list of parameters of the controller, etc. to the final element in accordance with the hierarchy of objects. To be able to return to levels above the selection list of all the elements are inserted into the higher levels of the current value of the address.

Fig. 4.2.5. Tab "Template config" of the "LogicLev" controller's parameter page.
Fig. 4.2.6. Tab "Template config" of the "LogicLev" controller's parameter page with the links details.

Let's save the created objects of the controller and parameters. After this, run the controller for execution by setting the controller's flag "Run" in the "State". If we do not miss something, the calculation is successfully started and in the "State" we'll get something like the one on Fig.4.2.7.

Fig. 4.2.7. Page of the controller's object if the calculation of the controller in the "LogicLev" module is successful.

In the case of successful processing of the template's code in the parameters we'll obtain the processed data in the infrastructure of OpenSCADA. You can see these data on the tab "Attributes" of our parameters AT101_1 (Fig.4.2.8) and AT101_2.

Fig. 4.2.8. Page of attributes of the parameter AT101_1 of the "LogicLev" module.

The configuration of data processing is complete.

4.3 Typified Data Sources Parameters

In the previous sections the data source connection mechanism has been described for the apparatus object ("Air Cooler"), which provides the unification of all signals in a single parameter's object of the data source. However, a more common approach is to create a parameter's object around a signal, such as "Temperature at the cooler's outlet AT101_1 (TE1314_1)".

Creating the parameter's object around the signal allows to formalize its description to the templates of analog and digital signals by including to them all necessary processing, alarming and other characteristic information. For a simple configuration of the typified analog and digital signals there are the parameters templates in the OpenSCADA libraries, and many of the visual presentation images are adapted to work and binding with these parameters directly, without going into details on the attributes.

Typically, for the formation of a parameter's object based on a template the logic level module LogicLev is used, as described in the previous section. However, a number of modules, including ModBus provide the ability to immediately create logical parameters, based on the template. We'll add new parameter's objects by opening the early created page of our "ModBus" controller's object in the configurator, and in the context menu of the "KM101" item lets press "Add".

Lets name the analog parameter object "TE1314_1" — id and the name is "TE1314_1" (Fig.4.3.1). Parameter's type lets set to "Logical", the parameter's template — "base.anUnif", description — "The temperature at the outlet of AT101_1", lets set the "To enable" and "Enable" flags. Next, we need to configure the parameter's template in the tab "Template Configuration" tab (Fig.4.3.2): the "Input" field is set to ModBus-register's address of this parameter "R:101", the "Maximum module scale" is set to 65535, which corresponds to 100 °C. Next, lets go to the "Attributes" tab (Fig.4.3.3) and set some fields, "Dimension" is set to "deg. C", "Scale minimum" to "0", "Scale maximum" to "100"; "Border up alarm" to "40", "Border up warning" to "30". Lets save the parameter's object.

Fig. 4.3.1. Page of the logical parameter "TE1314_1" of the "ModBus" module.
Fig. 4.3.2. Page of the "TE1314_1" parameter's template configuration of the "ModBus" module.
Fig. 4.3.3. Page of the "TE1314_1" parameter's attributes of the "ModBus" module.

The discrete parameter's object lats name: "KSH102" — id and the name is "KSH102". Parameter's type lets set to "Logical", the parameter's template — "base.digitBlockUnif", lets set the "To enable" and "Enable" flags. Next, we need to configure the parameter's template in the tab "Template Configuration" tab (Fig.4.3.4): the "Command 'Open '" field is set to the value of the ModBus-bit address of the parameter "C:100:rw"; the "State 'Opened'" field is set to the value of the ModBus-bit address "C:101", the "State 'Closed'" field is set to the value of the ModBus-bit address "C:102", the "Hold command time (s)" field is set to 0, because the command if not the pulse one. Next, lets go to the "Attributes" tab (Fig.4.3.5) and make sure the availability of command and states. Save the parameter's object.

Fig. 4.3.4. Page of the "KSH102" parameter's template configuration of the "ModBus" module.
Fig. 4.3.5. Page of the "KSH102" parameter's attributes of the "ModBus" module.

4.4 Enabling the TP data archiving

Many tasks require to keep the history of parameters of the TP. To activate the archiving of the attributes "Ti" and "To" of the AT101_1 and AT101_2 parameters in the previously created controller of the "LogicLev" module it is enough on the "Archiving" tab of the configuration page to choose which attributes are to be archived and by what archivers (Fig.4.4.1). We'll choose the archiving of "Ti" and "To" attributes in the "FSArch.1s" archiver. The same thing you can do for attribute "var" of analog parameter "ModBus.KM101.TE1314_1" and for "com" of digital parameter "ModBus.KM101.KSH102".

Fig. 4.4.1. Tab "Archiving" of the AT101_1 parameter of the "LogicLev" module.

As the result of this operation it will be automatically created the objects of archives for the selected attributes. For example, the archive's object for the attribute "Ti" of the AT101_1 parameter is presented at Fig.4.4.2.

Fig. 4.4.2. Page of the archive's object of the "Ti" attribute of the AT101_1 parameter.

Usually the settings of the archive do not need to be change, but if you need the special configuration, it can be done on the aforesaid page. Often you may need to obtain the information about the archive. For example, find the archive's size, both in time and in the bytes, as well as to look at the graph(diagram) of the parameter (Fig.4.4.3).

Fig. 4.4.3. Tab "Values" of the page of the archive's object of the "To" attribute of the AT101_1 parameter.

5 Formation of visual presentation

The formation of visual presentation may be performed at three levels of complexity and the user can select any of them, depending on the level of his knowledge and availability of libraries with ready-made images and templates.

The first level requires a minimum qualification of the user, but implies the presence of template frames' libraries, which are needed to solve his task. Within the limits of the first level the user only has to know how to connect the dynamics to the template frames' pages and how to add new pages of the template frames.

The second level provides the additional ability to create new frames based on the finished complex elements, simply by their placement in the frame. To achieve this qualification level users will need libraries of complex elements needed to solve his tasks.

The third level requires that user is able to use of all the tools of the development environment of visual interfaces of OpenSCADA, including the creation of new complex elements and developing of the new user interfaces in the project.

All works on the visualization interface we will make in an environment of the "Vision" module of subsystem "User interfaces". To open the "Vision" interface window you should click the second icon on the right on the configurator toolbar. The result is the window previously shown in Figure 3.3.

The interfaces of user-operator realizing into OpenSCADA by the projects of visualization. Into library main elements library of the user interface the typical project template has presented, which based on signal objects model and display views concept. The user can start for self concept of visualization interface creation, by new project, or can use pointed template. For new visualization project creation you will need third level knowledge and hard work which placed over this document. By that will see to creation the visualization interface based on allowed template project.

Fig. 5.1. Template project by the signal objects concept.

The template contain two branches: "Control panels" and "Root page". The branch "Control panels" contain typical control panels and special frames set. Branch "Root page", with the root page basis, contain subbranches for signal objects "Group 1", "Group 2" and different branch of "Result graphics". The signal object's subbranches "Group {n}" have number identifier and can expanded by appending up to 16. The subbranch "Group {n}" presenting will display by activation corresponding to it signal object's button on root page, which will allow switch to it. Every subbranch "Group {n}" has containers or templates for display views, typical: "Mnemo", "Graphics groups", "Contours groups", "Groups of overview frames" and "Documents". Any pages present into containers will enable selection the display view, for corresponding signal object of root page. About root page structure you can detailed see by link http://wiki.oscada.org/HomePageEn/Using/GraphicElementsLibraries/MainElements#h1039-45.

For creation self visualization project user can copy the template project and call it for self. We will continue work direct with template project and place our pages into mnemo-containers and graphics groups.

5.1 Adding the template page in the project and linkage of the dynamics

Let's examine the first level of complexity task, when in the already designed interface it is necessary to link the dynamics to the template page. The concept of "Page's template" means the page on the basis of which with the help of inheritance it can be created a lot of final visualization pages with an individual list of the dynamics. The examples of these pages are: "Graphics group", "Contours group", "Overview frames panel" and "Result graphics". In the Fig.5.1.1 the template page "Graphics group" in the project tree "Signal groups (template)" is presented.

Fig. 5.1.1. Template page "Graphics group".

The "Graphics group" template page provides an opportunity to link up to eight signals for simultaneous display them on the diagram. Elements at the top will automatically hide for unspecified links.

Let's create the new group of graphs "Graphics 2" in the template container "Graphics group" of the first group of the root page of "Signal groups (template)". To do this, let's in the context menu of the "Graphics group" item select "Add visual item" (Fig.5.1.2). To enter the ID and name of the new visual item the dialog will appear (Fig.5.1.3). Enter the ID "2" and the name "Graphics 2".

Fig. 5.1.2. Adding of the "Graphics 2" group of graphs.
Fig. 5.1.3. Input dialog of the ID and name.

After confirming the name input it will be created the new page. However, for its activation, we need to enable it. You can enable this page in the dialog of the properties editing page (Fig.5.1.4). To open this page it is possible by selecting the menu item 'Visual item properties" in the context menu of the newly created page. New page, based at the template, you can create into the logical container by simple copy template to internal self.

Fig. 5.1.4. Dialogue of properties editing of the visual element.

After enabling the page you are ready to set links to the created in the previous chapter parameters of controllers. To do this, without leaving the dialog to edit the properties of the newly created page (Fig.5.1.4), click on the "Links" tab (Fig.5.1.5). On this tab, we can see the tree with the elements "el1" ... "el8". Unwinding any of the elements we'll see the "Parameter" branch, in this branch we need to specify or select the address of our attributes "Ti" and "To". Total we will fill the four elements. When filling out the elements the part of properties must be specified as constants. For example, it is necessarily needed to be specified:

  • name — "val:AT101_1 Ti".
  • ed — "val:deg.C".
  • max — "val:150" (for Ti) and "val:100" (for To).
  • min — "val:0".

If you foresee the existence of the attributes specified in the controller parameter's template as constant, it will be possible to specify only parameter, and the attributes will be set automatically, that you can see to link created early typical analog parameter "ModBus.KM101.TE1314_1".

Fig. 5.1.5. Tab "Links" of the dialog of edition of the properties of the visual item.

Having finished the links entering, we can see the result of our efforts. To do this we'll close the editing properties dialog and run the "Signal groups (template)" for execution, about the run button we remember from the previous chapters. Then let's choose the graphics and switch to the second page. With error-free configuration, we should see something similar to that shown in Fig.5.1.6. Note that for typical parameter, with violations borders set, variable gone to the borders will cause marking by violations color. For see that we can set performance cooler value to 100 (Fig.4.2.8).

Fig. 5.1.6. Created group of graphs with four signals and one typical parameter linked.

5.2 The creation of the new frame, the mnemonic scheme

Let's raise the bar and create the new frame, on which we'll put the basic elements of our controllers' values displaying. Such frames are usually called the mnemonic schemes and in addition to the dynamics displaying, and even in the first place, contain the static image of the technological process in the mnemonic representation. We are not going to focus on the creation of statics and we'll add the dynamic elements and link them to the parameters of our controllers. We'll put the created frame to the tree of already known to us project.

New frames, destined later to be placed in the project, are to be created in the library of widgets. Let's create the new library of widgets "KM101" by the selecting of the vertical tab "Widgets" and in the context menu of the window of widgets' libraries click "New Library" (Fig.5.2.1). In the dialog of entering the name we'll indicate the identifier "KM101" and the name "KM 101" and then confirm.

Fig. 5.2.1. Adding of a new library of widgets.

Next we'll add the new frame "AT101" by selecting "Library: originals" -> "Elements box" in the context menu of the created library "KM101" (Fig.5.2.2). In the dialog of entering the name we'll indicate the identifier "AT101" and the name "AT 101" and then confirm. At the heart of any frame and the page must be based on an element of "Elements box (Box)", and therefore we have chosen it.

Fig. 5.2.2. Adding of a new frame.

Immediately after the creation of the new frame element it is necessary to set its basic properties, characteristic to the mnemonic scheme frame. Properties or attributes of any visual element can be specified in the toolbar "Attributes", having pre-selected the visual element. Let's select the created frame "AT 101" and set the following properties:

  • Geometry:width — "900".
  • Geometry:height — "600".
  • Page:group — "so", for the frame including to mnemo container allow, at run.
  • Background:color — "#5A5A5A".
  • Border:width — "1".
  • Border:color — "black".

The result will be an empty frame (Fig.5.2.3), ready to add items to it. To edit or view the the frame you should in the frame's context menu select the "Visual item edit".

Fig. 5.2.3. View of the new frame and set attributes for the mnemonic scheme.

Now let's add on frame the elements for the value of the analog parameters displaying for our four signals and typical parameter "ModBus.KM101.TE1314_1". To place an element for displaying an analog signal to the mnemonic scheme it is necessary to select our mnemonic scheme, and then in the window's menu to select the "Widget" -> "Library: Main" -> "Analog show" after which the cursor with an image of this element will appear, which should be moving to the desired location on the mnemonic scheme and then the left mouse button should be pressed. At the time of adding the dialog asking the name of the new element will appear. We'll add this way the five elements which we'll call: "A1_Ti", "A1_To", "A2_Ti", "A2_To" and "TE1314_1".

let's add on the frame the element of typical digital parameter, for that will use library's widget "Widget"->"Library: mnEls"->"Ball crane" and next call it "KSH102".

For list of current violations display let's place on the frame the protocol element from the primitives library "Widget"->"Library: originals"->"Protocol" and next call it "Protocol". For the protocol element will set properties into the attributes inspector:

  • Geometry:width — "500".
  • Geometry:height — "250".
  • View columns — "tm;lev;mess".
  • Level — "-1", for any level violations display.
  • Size, sek — "0", for any depth violatons display.
  • Tracing period (s) — "1".

The added elements can be subsequently positioned as needed by simply selecting and dragging them by the mouse. Also you can change its size. Simple size changing will only resize the container widget geometry, what often needlessly. For all widget's content geometry change it need to scale, what making by key "Ctrl" holding at the widget geometry change or by toggle state "Resize" into statusline to "Scale.

After such manipulations, we should get the mnemonic scheme with the view, similar to Figure 5.2.4.

Fig. 5.2.4. View of the new frame and set attributes for the mnemonic scheme.

This procedure of the creating the mnemonic scheme we'll consider to be finished. Save the new library of widgets "KM101" and proceed to the stage of the placing our mnemonic scheme in the project's tree of "Signal groups (template)".

Let's put our mnemonic scheme to the branch of the "Signal groups (template"->"Root page (SO)"->"Group 1"->"Mnemos" by selecting in the context menu for the "Mnemos" item the item "Library: KM101"->"AT 101". The identifier for the new mnemonic scheme let's set to "2" and the name field let's leave blank.

Next you need to make an already familiar to us the operation from the previous chapter, namely the setting of links to the created in the previous chapter the parameters of controllers. To do this let's open the dialogue of the properties editing of the mnemonic scheme on the "Links" tab (Fig.5.2.5). On this tab, we'll see the tree with the elements of "A1_Ti", "A1_To", "A2_Ti" and "A2_To". Unwinding any of the elements, we'll see the "Parameter" branch, in this branch we are to specify or select the address of our attributes "Ti" and "To", respectively. When filling out the elements the part of the properties must be specified as constants. For example, necessarily must be specified:

  • pName — "val:AT101_1 Ti".

As in case with graphics group in previous chapter for typical parameters "ModBus.KM101.TE1314_1" and "ModBus.KM101.KSH102" you can set only the parameter and attributes will assign automatic.

Fig. 5.2.5. Tab "Links" of dialog of editing of properties of the mnemonic scheme.

Now we can save our mnemonic scheme and verify what we have. To do this, we'll close the properties dialog and run the "Signal groups (template)" for execution. Then switch to the second mnemonic scheme by the paging buttons. With error-free configuration, we should see something similar to that shown in Figure 5.2.6.

Fig. 5.2.6. Created mnemonic scheme with four linked signals, typical parameters and the protocol.

Note for you, the typical parameter variable going beyond violation borders set will mark by flashing through alarm color: the parameter, the signal object and the yellow circle bottom. On the violation also will cause boozer cheep and speech synthesis (if set and configured program "ru_tts" or other) from the parameter position text into link field "spName" (рис. 5.2.5). On the violation will set active the indication buttons on the right and right-bottom, and to press the button will accorded type notification make cvitation. On flashing yellow circle on the right-bottom press will cvitation for all. Any violation allowing fact will noted into the protocol, which we have appended. To see going beyond one violation border we can set the cooler productivity to 100 (Fig.4.2.8). About working with violations concept you can detailed read into the "How to Violations, alarms and notifications".

Violations history you can see into document "Protocol of violations", which allowed on the display view "Document" select (Fig.5.2.7).

Fig. 5.2.7. Alarms document.

The digital typical parameter "ModBus.KM101.KSH102", displayed by ball crane, is active then you can select it and get control panel on the right (Fig.5.2.6), and also send commands (open or close). The commands you can doing to the control panel or context menu. All operator's control interruptions will noted into protocols and the document for its you can see on the display view "Document" select (Fig.5.2.8).

Fig. 5.2.7. Operator interruptions protocol.

5.3 Creation of the new complex element

Let's proceed to the objectives of the third level of complexity, namely the creation of an complex element. Creating of the new complex element, which includes a combination of basic primitives, can be made in several stages. As an example, let's examine the task, consisting of two stages:

  • Creation the widget "Air cooler" on the basis of the primitive "Elementary figures".
  • Creation the final grouped widget "Cooler" based on the primitive "Elements box".

5.3.1 Creation the widget "Air cooler" on the basis of the primitive "Elementary figures"

The widget will be created in our previously made library "KM101". To do this we'll make right mouse button click on this library and select the item "Library: originals"->"Elementary figures", as it is shown in Figure 5.3.1.1. For a new element let's write the "air_cooler" identifier and the name "Air cooler".

Fig. 5.3.1.1. Adding of a widget based on the primitive "Elementary figures" to the "KM101" library.

After confirmation, we will have a new widget's object with the name "Air cooler". Select it in the widget library "KM101" and open for editing via the context menu of the new element (Fig. 5.3.1.2). Let is set properties into attributes inspector:

  • Geometry:width — "200".
  • Geometry:height — "200".
  • Fill:color — "lightgrey". Color may set, as with help colors names, and also in format #RRGGBB (#RRGGBB-AAA).
Fig. 5.3.1.2. First widget configuration.

Now let's draw the visual presentation of the widget. This procedure can be done in two ways described below:

  • To draw the desired image by the mouse, using the "Line", "Arc", "Bezier curve" and "Fill." The corresponding panel ("Elementary figure tools") appears after entering the edit mode (drawing). To enter this mode it is possible as shown it is shown in Fig. 5.3.1.3, or by double clicking the left mouse button on the body of the widget.
  • Manually fill in the "Elements' list", by entering the list of required elements and coordinates of points.

More information about the editor you can get here.

Fig. 5.3.1.3. Entrance to the mode of drawing the widget, based on the primitive "Elementary figures".

In our example, we'll use the second method. To do this in the "Elements' list" of the attributes inspector let's enter the list below and press "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)

All the points in our case are specified in the static form, since it is not provided the dynamics and change of coordinates in the mode of execution, and all the other parameters are left by default.

As a consequence, our widget will take the form shown in Figure 5.3.1.4.

Fig. 5.3.1.4. Image corresponding to the "Elements' list" of the widget.

Let's create an icon for our widget, which will be visible in the widgets' tree of the library "KM101" (Figure 5.3.1.5).

Fig. 5.3.1.5. Creating an icon for the widget.

The process of creating the first widget is completed. We'll now turn to the stage of layout and the creation of the resulting widget.

5.3.2 Creation the final complex widget "Cooler" on the basis of the primitive "Elements box"

The resulting widget we'll create in the "KM 101" library. To do this we must click the right mouse button on the library and select the primitive "Elements box", as it is shown in Figure 5.3.2.1. For a new element let's specify the identifier "elCooler" and the name of "Cooler".

Fig. 5.3.2.1. Adding of a widget based on the primitive "Elements box" to the "KM 101" library.

After confirmation, we'll have the new widget object with the name "Cooler". Select it in the widget library "KM 101" and open for editing. Let is set properties into attributes inspector:

  • Geometry:width — "250".
  • Geometry:height — "200".

Let's take the previously created element "Air cooler" (air_cooler) and drag him (clicking on it by the left mouse button and moving the cursor of the mouse to the body of the widget, then let the button) to the newly created widget (see Figure 5.3.2.2).

Fig. 5.3.2.2. Drag and Drop of the widget "air_cooler" to the widget-container "elCooler".

The dialogue window will appear to enter the ID and name of the new widget. ID and the name can be set arbitrarily. We will input the "air_cooler" ID and the name we'll leave blank (it will be inherited from parent - the element "air_cooler"). Thus, the newly-created widget inside the container "elCooler" inherits the element - "Air cooler" ("air_cooler"). After confirming the entry of ID and name the widget "Air cooler" ("air_cooler") will be added to our widget container "elCooler" (Figure 5.3.2.3). Let is set properties into attributes inspector:

  • Geometry:x — "25".
  • Geometry:y — "0".
Fig. 5.3.2.3. Adding of the inherited widget "air_cooler".

Next, unwind the library "Mnemo elements", find there the "Cooler" element (cooler2) and drag it to the widget-container. This element will dynamically display the productivity of the air cooler. As the result it will appear the dialog window for entering the ID and name of the new widget. Enter the ID "cooler2" and the name again let's leave blank. Thus, the newly-created widget inside the container "elCooler" will inherit the element of the library "Mnemo elements" - "Cooler" ("cooler2"). After confirming the entry of the ID and name the widget "Cooler" ("cooler2") will be added to our widget-container "elCooler". Let is set properties into attributes inspector:

  • Geometry:x — "75".
  • Geometry:y — "30".
  • Geometry:z — "10". Raise the widget over all you can from panel "Widgets view functions".
  • Color1 — "#FFFF00-200", we have added the value of transparency 200 ("0" - fully transparent, while "255" - the fully opaque), as it is shown in Fig. 5.3.2.4.
  • Color2 — "#FF0000-200", we have added the value of transparency 200.
Fig. 5.3.2.4. Change the fill colors transparency in the inherited widget "cooler2".

Now let's add to the widget-container "elCooler" two text fields based on the primitive "Text", in order to display the input and output temperatures of the flow. To do this in the library "KM 101" we'll select the widget "Cooler" and then click on the visual items toolbar on the icon of the primitive "Text", as it is shown in Figure 5.3.2.5. The dialog of the ID and name of the newly created element entering will appear. Enter the ID "Ti" for the first text field, and the name field we'll leave blank. Let is set properties into attributes inspector:

  • Geometry:x — "5".
  • Geometry:y — "20".
  • Geometry:ширина — "70".
  • Geometry:высота — "35".
  • Alignment — "Center".
  • Font — "Arial 14 1". Font selection you can do into the dialog which opened at press on the key into edit field (Fig. 5.3.2.7).
  • Text — "%1{Enter}deg.C" (Fig. 5.3.2.8). {Enter} — move to next line.
  • Arguments number — "1" (Fig. 5.3.2.9):
    • Argument 0:type — "Real".
    • Argument 0:value — "300.25", the number "300.25" is entered only the with the purpose of clarity, in the execution mode it will be changed by the real value of the input temperature.
    • Аргумент 0:config — "3;f;2".
Fig. 5.3.2.5. Adding of a new element to the container, based on the primitive "Text".
Fig. 5.3.2.6. Specifying of the geometry of the widget "Ti".
Fig. 5.3.2.7. Changing of the font size for the widget "Ti".
Fig. 5.3.2.8. Changing of the field "Text" and an indication of the argument's presence in it for the widget "Ti".
Fig. 5.3.2.9. Configuration of the argument for the "Ti" widget.

Now we'll copy the "Ti" widget in order to create an equivalent widget "To" (output temperature). Let's paste the widget, in the dialog of the ID and the name entering for the newly created widget in the field "ID" we'll write "To", and the name field we'll leave blank (Fig. 5.3.2.10). Let is set properties into attributes inspector:

  • Geometry:x — "175".
  • Geometry:y — "20".
Fig. 5.3.2.10. Widget "To".

Now let's add the widget based on the primitive "Form's elements" (Fig. 5.3.2.11), which will be used as the ComboBox to select the productivity values of the cooler. The identifier will be "cw", and the "Name" field we'll leave blank (Fig. 5.3.2.12). Let is set properties into attributes inspector:

  • Active — "true".
  • Geometry:x — "60".
  • Geometry:y — "158".
  • Geometry:z — "10". Raise the widget over all you can from panel "Widgets view functions".
  • Geometry:width — "60".
  • Geometry:height — "40".
  • Element type — "Combo Box".
  • Font — "Arial 14 1".
  • Value — "200".
  • Configuration — "0{Enter}50{Enter}100{Enter}150{Enter}200". {Enter} — move to next line.
Fig. 5.3.2.11. Adding of a widget based on the primitive "Form's elements".
Fig. 5.3.2.12. Filling of the parameters of the "cw" ComboBox.

To display the cooler productivity dimensions we'll add the widget on the basis of the "Text" primitive. Let's make the same procedure as for the "Ti" widget. The identifier of the newly created widget will be "dimension" (Fig. 5.3.2.13). Let is set properties into attributes inspector:

  • Geometry:x — "125".
  • Geometry:y — "168".
  • Geometry:width — "60".
  • Geometry:height — "20".
  • Alignment — "Center".
  • Font — "Arial 14 1".
  • Text — "rpm".
Fig. 5.3.2.13. Adding of the "dimension" widget, based on the primitive "Text" and changing of its settings.

To add the processing logics for the widget "Cooler" (elCooler) we'll open the dialog of the properties editing of the visual element and select the "Process" tab. On this tab we can see the tree of widget's attributes and the field for the program code for the attributes' processing. To solve our task, we must add three attributes: Ti, To, Cw (Fig. 5.3.2.14). To add an attribute you should unwind the root element ".", select any element inside the root one and click "Add attribute" button below.

Further we'll enable the processing of "value" attribute of combo box "cw", as it is shown in Figure 5.3.2.15. Similarly, enable the processing of the "arg0val" attribute for Ti and To, as well as the "speed" attribute of the "cooler2" element.

Fig. 5.3.2.14. Adding of three attributes for the element "elCooler" of the library "KM 101".
Fig. 5.3.2.15. Enabling of processing of the attribute "value" of the combo box "cw".

At the end let's set the user programming language for the program to the "JavaLikeCalc.JavaScript" and write the program to process this widget:

Ti_arg0val = Ti;
To_arg0val = To;

ev_wrk = ev_rez = "";
for(off = 0; true; )
{
  ev_wrk = event.parse(0,"\n",off);
  if(!ev_wrk.length) break;
  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 Place or edit the widget program does not make its compilation, and therefore no error messages in the program if they have a place to be. This is due to the fact that the immediate execution of the program and, hence, its compilation is carried out in the surroundings and the moment of launch to project execution visualization. In this case any errors during compilation are displayed in a message OpenSCADA, widgets with errors and not executed. View to messages archive OpenSCADA you can in the main tab of the subsystem "Archives" or in a terminal run OpenSCADA, if the launch was from the terminal or emulator.

The resulting view of the Process tab of the "elCooler" widget of the "KM 101" library will have the form shown in Figure 5.3.2.16.

Fig. 5.3.2.16. Resulting view of the "Process" tab of the "elCooler" widget of the "KM 101" library.

Let's close the dialogue of the properties of visual element editing, create an icon on the basis of our element, close the inner editing window and save it all.

The development of the complex element is finished.

5.3.3 Adding the complex element to the mnemonic scheme

To test the operability and evaluate the results of our efforts let's add the created widget to the mnemonic scheme, developed in chapter 5.2. We'll repeat this operation for two coolers "AT101_1" and "AT101_2".

To do this we'll open the frame of mnemonic scheme "AT 101" for editing. Then grab by the "mouse" our complex element and drag to mnemonic scheme, where we drop it in the desired position. In the dialog we'll enter the identifiers "AT101_1" and "AT101_2" respectively. The field "Name" is blank. Added element we'll place the way we desire. After such manipulations, we should get the mnemonic scheme with the view, similar to Fig.5.3.3.1.

Figure 5.3.3.1. View of the mnemonic scheme with the complex elements.

Let's save the new mnemonic scheme and close its window. Then move on to the project and open this mnemonic scheme in the project's tree "Signal groups (template)"->"Root page (SO)"->"Group 1"->"Mnemos"->"AT 101". As you can see, our new elements are appeared here automatically. And we only need to connect the links to the new elements. To do this we'll open the dialog of editing the properties of the mnemonic scheme on the "Links" tab (Fig.5.3.3.2). On this tab, we can see the tree with the elements of "AT101_1" and "AT101_2". Unwinding any of the elements, we'll see the "Parameter" branch just with the "Ti", "To" and "Cw" attributes, thus we can simply specify the address of the parameter "prm:/LogicLev/KM101/AT101_1" in the "Parameter" field and attributes will be placed automatically.

Fig. 5.3.3.2. Tab "Links" of the dialog of editing properties of the mnemonic scheme.

Let's save our mnemonic scheme and verify what we have. To do this, close the dialog of the properties and run the "Signal groups (template)" for execution. Then switch to the second mnemonic scheme with the help of paging buttons. With error-free configuration, we should see something similar to that shown in Figure 5.3.3.3.

Fig. 5.3.3.3. Resulting mnemonic scheme.

On this mnemonic scheme through our complex elements we can not only observe but also to control the productivity of coolers, simply by changing the value in the combo box. Changing the productivity, we can see the changes in temperature and alarms for analog typed parameter. History of changes we can see on the created in the chapter 5.1 the group of graphs.

6 Conclusion

This document describes in detail the basic process of creating the user interface elements, with preparation and configuration of the data source. In general, you can quickly get an idea of the work with the OpenSCADA system, and purposefully look for solutions of associated problems.