Загальні принципи розроблення SCADA/HMI

1. Загальний опис процесів життєвого циклу програмного проекту SCADA/HMI

Процеси розроблення SCADA/HMI – це тільки частина робіт у життєвому циклі автоматизованих систем керування. Будь-яка фізична сутність, у тому числі програмна, яка колись планується, з’являється на світ і зникає. Кажуть, що вона проходить свій життєвий цикл. Весь комплекс процесів програмної (і системної) інженерії пов’язаний з упорядкування робіт навколо життєвого циклу. Тобто планування робіт, використання інструментів та інших засобів для створення, зміни, чи обслуговування, перевірку виконання робіт та інші дії розглядають у контексті знаходження програмного продукту на певній стадії життєвого циклу.

Відповідно до ISO/IEC/IEEE 15288:2015, життєвий цикл (ЖЦ, life cycle) – це розвиток системи, продукції, послуги, проекту або іншої, створюваної людиною сутності від задумки до списання.

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

Життєвий цикл традиційно поділяють на стадії, кожна з яких розглядається як певна закінчена частина роботи, за результатами якої з’являються якісь артефакти (документи, програми, системні компоненти тощо) і приймають якісь важливі рішення щодо інших стадій. Стадії відрізняються за характером робіт. Наприклад, проектування зосереджене на розробленні певного типу документації, за яким проводять реалізацію. Поділ життєвого циклу системи на стадії залежить від її типу та прийнятих правилах у тих організаціях, що її розроблюють. Найпростіше життєвий цикл будь-якої системи можна розглядати як наступні стадії: задум, розроблення, введення в дію, експлуатація, утилізація. Часто розробники систем останню стадію не враховують, вважаючи що після введення в дію та гарантійного терміну експлуатації інше лежить на плечах покупця.

Засоби SCADA/HMI є частиною системи АСКТП, тому часто їхній життєвий цикл є частиною ЖЦ всіє системи. Тим не менше, є певні правила й стандарти, означені саме для SCADA/HMI, а розробниками можуть бути окремі організації. Тому в цьому посібнику ЖЦ для SCADA/HMI розглядається окремо.

Життєвий цикл та стадії проектування SCADA/HMI показані в 10-му розділі. Їх варто розглядати після ознайомлення зі способами та засобами, які надаються або можуть надаватися розробникові для реалізації того чи іншого функціоналу. Наразі достатньо розуміти, що для різних стадій та етапів використовуються різні інструментальні засоби, а їх наявність та зручність сильно впливає на їхній вибір та організацію життєвого циклу взагалі. Слід сказати, що на відміну від сектора ІТ, інструментальні засоби проектування, розроблення та супроводження SCADA/HMI далеко не завжди використовують сучасні методи та підходи.

У цьому розділі розглядаються такі стадії та етапи з життєвого циклу:

1) стадія розроблення, що включає етапи:

розроблення програмного проекту SCADA/HMI (у розділі розглядаються засоби, організація бази даних проектів, створення, редагування, імпорт/експорт, резервне копіювання та відновлення, керування версіями тощо);
налагодження (у розділі розглядаються засоби, компілювання та перевірка на помилки, тестовий запуск тощо);

2) введення в дію, що включає етапи:

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

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

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

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

2. Розроблення проекту

2.1. Узагальнена функціональна структура SCADA системи

Як уже зазначалося, загальна концепція розроблення на базі програм SCADA/HMI – це “конфігурування замість програмування”. Тобто вся або більша частина проекту розроблюються шляхом заповнення полів, таблиць, розміщення готових елементів. Тільки в деяких випадках, коли немає готового рішення, використовують вбудовані в SCADA/HMI мови та середовища програмування.

Розробник проекту повинен розуміти внутрішню функціональну структуру SCADA/HMI. Але довідникова система програмних засобів не завжди включає схему та опис такої структури. Набір сутностей та їх взаємозв’язки можуть відрізнятися в різних SCADA/HMI і розробникові без загального “системного” представлення інколи важко зрозуміти, як функціонує середовище виконання і як побудоване середовище розроблення. Тим не менше, враховуючи ринкові вимоги та історичне підґрунтя розвитку SCADA/HMI, перелік функцій середовища виконання для них спільні (вони наведені в попередньому розділі). Це дає можливість зробити певне узагальнення функціональної структури і саме через нього розглядати спільні риси більшості середовищ розроблення та виконання. На рис. 1 наведено спрощену модель функціонування SCADA-системи. Вона може відрізнятися для конкретного програмного пакета в той чи інший бік, тим не менше в цьому посібнику вона є базисною: саме в контексті цієї моделі будуть розглядатися всі діяльності по розробленню.

Центральне місце в системі збирання та диспетчерського керування займає база даних реального часу (БДРЧ) – сукупність змінних процесу, на базі значень яких функціонують інші підсистеми. Ці змінні часто називають тегами (Tag), і завдання SCADA – слідкувати за їхнім оновленням. З одного боку, теги зв’язуються з джерелом даних, а з іншого – з іншими підсистемами SCADA/HMI. Джерелом даних для тегів можуть слугувати зовнішні пристрої (наприклад контролери), системна інформація (наприклад плинна дата та час, або ім’я оператора, що ввійшов у систему), внутрішня або дискова пам’ять. При створенні та конфігуруванні тегу вказується його унікальне ім’я, тип, джерело даних, періодичність оновлення (зчитування), межі зміни та інші настройки. Наприклад, на рис. 1 показано, що зовнішній тег з ім’ям “TT1a” через підсистему введення/виведення зв’язується з однойменною змінною на ПЛК, яка має за джерело даних датчик температури, що підключений до вхідного аналогового каналу (%IW3.3). Детальніше конфігурування бази даних реального часу розглядається в третьому розділі посібника.

Як правило, теги в базах даних реального часу оновлюються періодично. Це робиться для того, щоб отримувати свіжу інформацію від пристроїв введення/виведення, наприклад контролера. Ці значення потрібні іншим підсистемам, наприклад, людино-машинному інтерфейсу. З іншого боку, деякі підсистеми SCADA теж можуть змінювати значення тегів, і при цьому це значення повинно записуватися в контролер. Таким чином реалізується двосторонній обмін. Наприклад, на рис. 2.1 за допомогою повзуна в підсистемі HMI змінюється значення тегу “H1”, що прив’язаний до нього. При зміні “H1” підсистема введення/виведення змінює значення однойменної змінної в контролері, яка формує завдання для регулятора “TC1”.

Рис. 1. Спрощена модель функціонування SCADA-системи

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

Для розроблення, редагування та тестування програмного проекту використовують програмні засоби, які прийнято відносити до середовища розроблення. Середовище розроблення SCADA/HMI – це комплекс інструментального програмного забезпечення, куди входять різноманітні редактори, компілятори, імітаційні засоби, засоби налагодження та утиліти. Хоч не в усіх SCADA/HMI середовище розроблення явно виділяється від середовища виконання, як мінімум режим розроблення повинен бути. Тим не менше, надалі будемо розглядати SCADA/HMI саме в контексті їх розділення на 2 складові: розроблення та виконання, як це було зазначено в 1-му розділі. Також будемо вважати, що проект у середовищі розроблення (вихідний) шляхом компілювання перетворюється на проект середовища виконання, хоч не в усіх SCADA/HMI необхідно проводити компілювання.

Процес створення проекту SCADA/HMI, як правило, проходить у трьох площинах:

конфігурування проектних даних;
створення графічної частини проекту(HMI);
написання невеликих програм (скриптів), якщо в таких є необхідність.

Таке розділення пов’язано з різним характером процесів розроблення. Конфігурування проектних даних, як правило, пов’язане із заповненням різноманітних полів таблиць або/та властивостей об’єктів. Графічна частина передбачає створення безпосередньо людино-машинного інтерфейсу, тому включає роботи по рисуванню та налаштуванню анімації. Написання скриптів передбачає програмування на одній або кількох мовах. Хоч ці діяльності пов’язані між собою і переплітаються, для них існують різні редактори. Інтегроване середовище розроблення може включати в себе ці редактори або посилатися на них.

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

2.2. Структура та принципи побудови середовища розроблення

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

Проект середовища розроблення містить дані, необхідні для редагування та зв’язування даних у середині проекту. Так, для відображення числового значення тегу в полі необхідно в конкретній властивості цього поля вказати його ім’я, яке є атрибутом цього тегу. Для того щоб при компіляції проекту відбулося таке поєднання, записування про цей тег повинен десь існувати. Той же тег повинен в якості джерела даних отримати змінну з ПЛК, і ці налаштування також десь мають бути записані. Цей ланцюжок зав’язків можна продовжувати, однак очевидно, що проект – це своєрідна база даних. У різних середовищах розроблення SCADA/HMI ця база даних має своє представлення. Наприклад, проект SCADA Citect являє собою папку переважно з файлами Dbase (DBF) та іншими файлами (як правило для опису графічних сторінок). У SCADA zenon проектні дані зберігаються в базі даних MS SQL Server Express. Таким чином, окрім створення, редагування та видалення проектів, для різних середовищ можуть бути доступні різні можливості, зокрема:

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

Як вже зазначалося, середовища розроблення SCADA/HMI включають кілька редакторів. Як правило, серед них є редактор проектних даних, редактор графіки та редактор коду. Редактор даних призначений для редагування усієї неграфічної частини, а графічна частина проекту виконується в редакторі графіки. У багатьох SCADA/HMI є єдине інтегроване середовище розроблення IDE (Integrated development environment), де редактори графічних сторінок відкриваються в тому самому вікні.

Сучасні SCADA/HMI як правило мають навігатор проекту або проектів, через який можна швидко доступитися до всіх розділів проекту. На рис. 2 показано приклади таких навігаторів, різних за підходами SCADA/HMI. Тим не менше, при детальному розгляді цих структур можна знайти відповідності. Так, в наведених на прикладі середовищах можна знайти розділи:

теги/змінні;
налаштування драйверів введення/виведення;
екрани/сторінки;
бібліотечні статичні та динамічні символи;
налаштування архівування трендів (Historian);
налаштування підсистеми тривог та подій (Alarms);
планувальники (Scheduler);
рецепти;
налаштування користувачів;
налаштування мов.

Рис. 2. Приклади навігаторів проекту

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

У різних SCADA/HMI можуть використовуватися принципово різні підходи до використання зв’язків між елементами. Так, у SCADA Citect зв’язки властивостей проводяться під час компіляції. Тобто якщо на якомусь етапі розроблення необхідно буде змінити ім’я тегу, то в усіх полях графічної підсистеми залишиться стара назва, що приведе до прив’язки до неіснуючого тегу. Це у багатьох випадках незручно і призводить до помилок, тим не менше компілятор показує місця цих помилок. Слід відмітити, що у нових версіях SCADA Citect підтримується так звана “каскадна” заміна, коли пов’язані поля за зміни змінюється по всьому проекту. У SCADA zenon принципово інший підхід. Там практично усі зв’язки між елементами формуються не за ім’ям, а за внутрішньо-проектним посиланням. Тобто, якщо зміниться ім’я тегу (змінної), то в усіх місцях, де він до цього використовувався також зміниться назва прив’язки. Хоч це здається завжди зручнішим, інколи бувають випадки, де 1-й спосіб має свої переваги.

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

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

Важливим моментом при розробленні великих проектів є можливість імпортувати дані з інших редакторів. Як правило, підтримуються текстові формати даних типу CSV (Comma Separated Value) та XML (eXtensible Markup Language). Файли CSV являють собою текстові записи, в яких поля розділені якимось знаком (“;”, “,”, “TAB” тощо). Такий формат досить зручно використовувати при імпортуванні таблиць з інших редакторів. Враховуючи, що до редакторів, які вміють експортувати CSV, входить Excel, то можливості автоматизації створення SCADA/HMI значно зростають. Навіть якщо формат файлів, що приймає редактор SCADA/HMI, відрізняється від CSV в Excel, то звичайний блокнот з функціями пошуку та заміни легко виправить цей недолік.

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

Для автоматизації розроблення проекту середовище розроблення може мати відкритий програмний інтерфейс API (Application Program Interface). У цьому випадку проектними даними можна оперувати ззовні з використанням різних середовищ програмування. У ряді випадків в IDE SCADA/HMI можуть бути наявні також і засоби такого програмування. Наявність API дає можливість використовувати сучасні підходи автоматизації розроблення та DEVOPS.

2.3. Створення графічної частини проекту

Графічна частина проекту створюється у вбудованих в SCADA/HMI редакторах. Цей процес полягає у виборі елемента з палітри доступних (рис. 3) та конфігурування його властивостей. Властивості елементів, які повинні анімуватися, вказують на той тег, який використовується в анімації. Так, на рис. 3 властивість “Числовое выражение” елемента “Текст” вказує на тег “ТТ1а”, що в режимі виконання приведе до показу значення цього тегу в цьому елементі.

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

Використання готових програмних інструментів SCADA/HMI значно прискорює процес розроблення, зменшує кількість проектних помилок, та дає можливість внести зміни в проект у будь-який момент, навіть без зупинки технологічного процесу. Графічна частина стосується практично всіх основних функцій SCADA/HMI. (Основні підходи розроблення людино-машинного інтерфейсу розглядаються в 5-му розділі посібника.)

Рис.3. Приклади інструментів для створення людино-машинного інтерфейсу в різних SCADA

3. Виконання та налагодження

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

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

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

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

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

переведення драйверу, або частини підсистеми вводу/виводу в режим, який дозволяє відключитися від джерела даних для можливості їх зміни з HMI;
набір засобів для контролю стану та зміни значення тегів;

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

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

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

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

4. Введення в дію

Після налагодження проект необхідно завантажити (розгорнути) і перезапустити на цільовому пристрої. Залежно від SCADA/HMI це може відбуватися в різні способи. Класичним є передача файлів середовища виконання через знімний носій. Цей спосіб не дуже зручний і потребує розуміння файлової структури середовища виконання. Також він може бути небезпечним, бо може створити додаткову загрозу щодо зараження цільової системи вірусом або проникнення туди зловмисного ПЗ (див. підрозділ 9.5). Крім того, перезапуск середовища виконання після цього повинен проводитися вручну. Це значить, що на місці знаходження цільового пристрою повинен бути компетентний спеціаліст, наприклад співробітник КВПіА. Крім того, ця процедура може потребувати від кількох хвилин до кількох десятків хвилин, що може також негативно проявитися на процесі керування.

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

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

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

Введення в дію SCADA/HMI відбувається на стадії пуско-налагодження. Однак за необхідності зміни проекту на стадії експлуатації також необхідно проводити процедуру розгортання та перезапуску. Це спонукає до віддаленого підключення інженерної станції до об’єкта через зовнішні канали зв’язку. Це досить поширена практика як при пуско-налагоджуванні, так і на стадії експлуатації. Класичним підходом до організації віддаленого доступу інженерної станції до мережі з цільовою системою є VPN-тунелі в Інтернет (див. параграф 9.5.7). Не дивлячись на зручність і швидкість реакції на необхідні зміни в проекті, слід розуміти, що при неправильній організації зв’язку і невиконанні правил це може привести до небезпечних ситуацій (див. підрозділ 9.5).

Альтернативним рішенням доступу через VPN є організація використання інженерної станції за місцем з віддаленим підключенням користувача. Тобто на об’єкті передбачено наявність сервісної інженерної станції, яка підключається за необхідністю. Підключення до цільового пристрою SCADA/HMI може відбуватися як по мережі Ethernet, так і через інші канали зв’язку. Інженер-розробник заходить на інженерну станцію через сервіси віддаленого робочого столу, типу RDP, VNC, TeamViewer або аналогічні, використовуючи Інтернет. Ряд з цих сервісів потребують явно виділеної IP-адреси, деякі можуть бути платними.

Слід зауважити, що деякі SCADA/HMI передбачають можливість завантаження проекту виконання без використання середовища розроблення.

Контрольні запитання

Поясніть що таке життєвий цикл?
За яким принципом виділяють стадії життєвого циклу?
Роботи яких стадій ЖЦ розглядаються в цьому розділі? Поясніть призначення етапів на цих стадіях.
Що таке інженерна робоча станція, чим вона відрізняється від цільового пристрою?
Поясніть спрощену модель функціонування SCADA-системи, що показана на рис. 2.1.
Поясніть принцип розроблення “проектування замість програмування”, що закладені у більшість SCADA.
Які основні роботи проводяться при розробленні проекту в середовищі розроблення?
Що таке проект середовища розроблення, як він може бути побудований?
Як можуть організовуватися зв’язки між елементами?
Які можливості редакторів Ви можете назвати?
Які спільні характеристики можна навести для всіх середовищ розроблення?
Розкажіть про можливі функції редакторів.
Покажіть на прикладі однієї з програм SCADA/HMI, як відбувається перенесення проекту режиму розроблення.
Поясніть необхідність імпорту та експорту даних у проектах.
Як можна використати наявний відкритий програмний інтерфейс (API) у середовищі розроблення?
Розкажіть про загальні підходи до створення графічної частини проекту.
Поясніть, у чому полягає налагодження проекту SCADA/HMI.
Яка відмінність у налагодженні проекту для різних типів цільових пристроїв: ПК та ОП?
Покажіть на прикладі однієї з SCADA/HMI, які засоби використовуються для відображення/зміни значення тегів (змінних) при налагодженні.
Покажіть на прикладі однієї з SCADA/HMI як можна використовувати журнали подій та помилок.
Назвіть кілька способів перенесення файлів виконання із середовища розроблення на цільовий пристрій.
Покажіть на прикладі однієї з SCADA/HMI, як відбувається перенесення файлів виконання на цільовий пристрій через знімний носій. Які переваги та недоліки такого способу?
Які переваги та недоліки в перенесенні файлів виконання через мережні папки?
Покажіть на прикладі однієї з SCADA/HMI, як відбувається пересилання файлів виконання на цільовий пристрій через вбудовані засоби розгортання (завантаження).
Назвіть кілька способів віддаленого розгортання (завантаження) та перезапуску проекту їх переваги та недоліки.

Список використаних джерел

PAC Framework V1.02. Функціональний каркас для розробки прикладного програмного забезпечення для промислових контролерів [Електронний ресурс]. Доступно: https://github.com/pupenasan/PACFramework

Теоретичне заняття розробив Олександр Пупена.