Людино-машинні інтерфейси Автор і лектор: Олександр Пупена доц. кафедри АКСТУ НУХТ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проект середовища розроблення містить дані, необхідні для редагування та зв’язування даних у середині проекту. Так, для відображення числового значення тегу в полі необхідно в конкретній властивості цього поля вказати його ім’я, яке є атрибутом цього тегу. Для того щоб при компіляції проекту відбулося таке поєднання, записування про цей тег повинен десь існувати. Той же тег повинен в якості джерела даних отримати змінну з ПЛК, і ці налаштування також десь мають бути записані. Цей ланцюжок зав’язків можна продовжувати, однак очевидно, що проект – це своєрідна база даних. У різних середовищах розроблення 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 як правило мають навігатор проекту або проектів, через який можна швидко доступитися до всіх розділів проекту. На рис. 4.2 показано приклади таких навігаторів, різних за підходами SCADA/HMI. Тим не менше, при детальному розгляді цих структур можна знайти відповідності. Так, в наведених на прикладі середовищах можна знайти розділи:

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

Рис. 4.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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.5. Приклад організації проектів у Citect

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

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

Проект середовища розроблення Citect – це набір різноманітних файлів, які розміщуються в папці проекту. Для їх редагування передбачено кілька окремих редакторів, для версії Citect SCADA 2018 це:

Citect Studio – для створення і налаштовування логічної частини проекту;
Graphics Builder – для створення і редагування графічних сторінок, а також бібліотечних елементів;
Cicode Editor – редактор файлів мов Cicode та VBA;
Computer Setup Editor – редактор файлу з параметрами citect.ini;
Equipment Editor – редактор устатковання.

Таким чином, щоб створювати або редагувати проект в SCADA 2018, необхідно запустити Citect Studio, а він автоматично відкриє реактор Graphics Builder. Додатково також у наявності є помічники (Wizard), які в інтерактивному режимі допомагають створювати чи налаштовувати проектні дані. Основним редактором є Citect Studio, який є навігатором по проектах і дає змогу не тільки редагувати логічну частину проекту, а й переходити на інші розділи проекту та відкривати відповідні редактори.

Середовище виконання представлене одним основним файлом Citect.exe, який виконує стартовий проект, але може виконуватися в кількох екземплярах (процесах) для кожного сервера і клієнтів. Для керування середовищем виконання є Runtime Manger, за допомогою якого запускають, зупиняють і перезапускають проекти.

Практично усі редактори та середовище виконання орієнтуються на параметри проекту та системи Citect. Параметр – це поіменована змінна середовища, за допомогою якої можна змінювати налаштування середовища розроблення та середовища виконання. Параметри можуть бути частиною проекту (Project Database Parameters) або стосуватися конкретного комп’ютера, де запускається Citect (Citect.ini File Parameters). Перші стосуються тільки поведінки конкретного проекту в середовищі виконання і їх конфігурують у відповідному розділі проекту. Параметри, які записані в Citect.ini, стосуються як середовища розроблення, так і виконання, і мають найвищий пріоритет.

Параметр має ім’я та значення і є частиною якоїсь секції. Параметрами можуть користуватися система Citect (умовно називатимемо системні параметри), драйвери введення/виведення Citect (параметри драйверу) або розробник для власних цілей (користувацькі параметри). Системні та драйверні параметри мають наперед визначені імена та набір значень у певних секціях. Якщо їх не задавати, вони матимуть значення за замовчуванням.

Файл Citect.ini є типовим текстовим ini-файлом, який містить розділи, назви та значення параметрів. За замовчуванням він інсталюється в папку “C:\ProgramData...\Citect…\Config”. Для його зміни можна користуватися будь-яким текстовим редактором або спеціалізованою утилітою Computer Setup Editor (рос. лок.”Редактор конфигурирования компьютера”), що поставляється разом з Citect. На рис. 4.4 показаний зовнішній вигляд цього редактору. Він дає можливість знайти наперед визначені параметри і за необхідності їх змінити. Якщо параметра у файлі немає, то вважається що він має значення за замовченням.

Рис.4.4. Редактор Citect.ini

При запуску Citect Studio він повинен дізнатися про розміщення папок з файлами середовища розроблення. Шлях до папки з проектними даними вказано в параметрі “User” (див. рис. 4.4), за замовченням це “C:\ProgramData...\Citect …\User”. Там знаходиться файл MASTER.DBF, який вказує на проекти, що будуть видимі в редакторі. Слід сказати, що проект може знаходитися в папці User, але якщо його немає в MASTER.DBF, він не буде видимий в Citect Studio. Проект може бути підключений або відключений через добавлення/видалення посилання на проект в Citect Studio.

Середовище виконання – це, по суті, виконавчий файл (або файли) Citect.exe, який може виконувати проект, створений та скомпільований у середовищі розроблення Citect. При запуску середовище виконання повинно знати про те, який саме проект необхідно запустити, а також з якими налаштуваннями (наприклад, де зберігати файли для трендів та тривог, якою буде стартова сторінка і т. д.). Назва та розміщення проекту зберігаються в параметрі “RUN” Citect.ini. Параметр “RUN” може змінювати розробник виділивши в Citect Studio потрібний проект для виконання.

Як видно, для налаштування параметрів середовища розроблення і виконання розробник повинен володіти достатньо великою кількістю знань. Для спрощення налаштування основних параметрів виконавчої системи краще користуватися помічником налаштування комп’ютера, Computer Setup Wizard (рос. лок. “Мастер конфигурирования компьютера”). Цей помічник в інтерактивному режимі налаштовує найнеобхідніші параметри для середовища виконання. Редактор параметрів та помічник налаштування комп’ютера доступні як з меню Windows, так і з Citect Studio.

Роботи в Citect SCADA передбачають такі основні проектні діяльності.

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

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

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

Інтегроване середовище розроблення Citect Studio дає можливість відкривати та редагувати кілька проектів. Citect передбачає механізм включення одних проектів, відкритих у Citect Studio, в інші. Це механізм, при якому кілька проектів (Included Projects) включаються в один загальний проект. Тобто розроблення кожного проекту ведеться індивідуально, а основний проект може включати ці проекти шляхом посилання на них. При компілюванні основного проекту будуть компілюватися і файли виконання включених проектів, і вони будуть перенесені в папку основного проекту.

Рис. 4.5. Включення проектів

Механізм включення проектів дає змогу:

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

Окремим типом включених проектів є системні проекти (System Projects). Це проекти, що постачаються разом з Citect, які передбачені для включення в інші проекти для перенесення туди шаблонів та бібліотек відповідно до обраного стилю. Системні проекти за замовченням не відображаються в переліку Citect Studio, щоб розробник випадкового не міг змінити їх. Для активації їх відображення є відповідна опція “Системні проекти”.

При створенні нового проекту вибирається стиль проекту (рис. 4.6). Вибір стилю вказує редактору, які саме системні проекти треба включити в новий проект. Розробник також може вибрати два варіанти створення нового проекту в Citect Studio (див. рис. 4.6):

пустий проект: проект не буде містити жодного компоненту і навіть не зможе компілюватися;
на базі початкового проекту: передбачає створення базового набору компонентів (серверів, пристроїв введення/виведення, сторінок, користувачів тощо) на основі стилю початкового проекту.

Рис. 4.6. Включення системних проектів при створенні стартового проекту

Наприклад, у результаті вибору стилю SxW_Style_1 в стартовий проект Project1 буде включено два системні проекти (див. рис. 4.6). Ці проекти, у свою чергу, включатимуть у себе інші системні проекти.

Для редагування проекту Citect Studio його необхідно зробити активним. Після створення проекту типово проводиться конфігурування серверів, введення/виведення, добавлення тегів, розроблення графічної частини і т. п. (див. наступні розділи посібника). Усі зміни в проекті приводять до зміни проектних файлів. Для Citect Studio більшість даних зберігається у файлах *.dbf, які можна редагувати в Excel з використанням Excel AddOn, який поставляється разом з дистрибутивом Citect. Видалення записів у редакторі не приводить до їх вилучення з бази даних, а тільки до відповідної помітки в ній. Тому інколи необхідно робити пакування через відповідний пункт меню проекту, яке видалить усі помічені для цього записи.

Для перенесення проекту на інший ПК або збереження плинної версії Citect Studio надає можливість створити резервну архівну копію проекту. Резервна копія – це архів .zip, який включає усі необхідні файли проекту. Створювати та відновлювати резервну копію можна як в Citect Studio, так і через меню Windows, що дає можливість робити ці операції на робочій станції оператора, на якій не встановлено середовище розроблення. У налаштуваннях майстра можна вибрати проект, який необхідно архівувати, місце розміщення архіву, та різноманітні опції (рис. 4.7). Відновлювати проект можна в папку активного проекту або в нову.

Рис. 4.7. Створення резервної копії проекту та відновлення

Виконання та налагодження проекту

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

помилки (Error): компіляція завершена, але проект не може бути запущений на виконання до їх виправлення;
критичні помилки (Fatal): компіляція не завершилася через критичну помилку;
попередження (Warning): компіляція завершена з помилками, але проект може бути виконаний.

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

Компілювання приводить до створення файлів виконання, серед яких є база даних режиму виконання (RDB, runtime databases), на які перетворюються конфігураційні таблиці.

Після компілювання проекту його необхідно запустити на виконання для перевірки та налагодження. Запуск виконання можна проводити як із середовища розроблення Citect Studio, так і з меню програм Windows. У першому випадку попередньо буде зроблено компілювання проекту, якщо в цьому є необхідність, і проект буде вибраний як стартовий. В обох випадках буде запущений стартовий проект (шлях вказаний у параметрі [Ctedit]RUN файлу Citect.ini).

Для керування середовищем виконання в Citect є спеціальний менеджер (Runtime Manager), який дозволяє запускати, зупиняти, контролювати стан та зупиняти процеси середовища виконання (рис. 4.8). Менеджер запускається автоматично при запуску середовища виконання, його вікно можна відкрити через контекстне меню піктограми в панелі статусу. Враховуючи, що Citect може виконуватися в кількох процесах, кожен з них може керуватися окремо.

Рис. 4.8. Вікно менеджера середовища виконання

Для перевірки та зміни тегів в Citect є шаблон DataBrowse, який виводить значення усіх тегів у вигляді таблиці. Крім того, є функції TagDebug та TagDebugForm, які виводять вікна читання/записування значень тегів.

Теги введення/виведення беруть значення з I/O Device, для яких, виставивши властивість Memory (рос.лок “Память”) в значення TRUE, можна вказати на необхідність “відключення” від зовнішнього джерела. Цей механізм можна використовувати при налагодженні для тимчасового відключення від джерела.

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

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

Цю інформацію можна аналізувати безпосередньо (журнали зберігаються в папці Logs, наприклад, “C:\ProgramData\Schneider Electric\Citect SCADA 2018\Logs”) або з використанням спеціального інструмента Citect SCADA Kernel. Kernel (надалі “Ядро”) може виконувати низько-рівневу діагностику та налагодження, аналіз середовища виконання. Він може відображати структури даних нижнього рівня, бази даних реального часу, статистику, мережний трафік, трафік введення/виведення тощо.

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

Файли проекту виконання для Citect задаються в Citect.ini параметром [RUN] (повний шлях [CtEdit]Run). Після компіляції проекту на інженерній робочій станції шлях розміщення автоматично вказує на папку з файлами проекту режиму розроблення. Для встановлення параметру [RUN] на цільовому комп’ютері рекомендується використовувати Computer Setup Wizard (рос. лок. “Мастер конфигурирования компьютера”). Папку проекту виконання [RUN] бажано розміщувати за тим самим шляхом, де розміщуються включені проекти, тобто в [USER]. Перед цим необхідно туди якимось способом переписати файли з інженерної станції. Після компіляції та налагодження проекту на інженерній робочій станції файли середовища виконання можна передати на цільову систему кількома способами:

ручне копіювання файлів в директорію запуску;
через створення резервної копії (Backup) та її відновлення (Restore Projects) ;
використовуючи автоматичну передачу файлів з інженерної станції на сервер проектів, налаштувавши параметри [CtEdit]Run та [CtEdit]Copy;
використовуючи функціональність системи розгортання Deployment (рекомендований варіант);
зробивши директорію середовища виконання доступною з мережі та скопіювавши туди файли (не рекомендується для серверних компонентів середовища виконання Citect).

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

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

Для мережних архітектур можна використовувати функціональність автоматичного копіювання файлів з папки, вказаної параметром [Copy] ([CtEdit]Copy). Якщо цей параметр містить посилання на директорію, середовище виконання Citect періодично перевірятиме її на наявність файлів, відмітка часу для яких не збігається з однойменними файлами в папці [Run] (навіть якщо вони будуть старіші). Якщо такі файли мають місце бути, вони будуть скопійовані в директорію [Run] із заміною попередніх файлів. Таким чином, на одному з ПК в мережі може бути відкрита для мережного доступу папка з найсвіжішим проектом, куди розробник копіюватиме файли виконання. Усі робочі станції із середовищем виконання будуть посилатися на неї через параметр [Copy]. Слід зауважити, що для коректної роботи слід робити мережний доступ до всієї папки [USER] на файловому сервері і завантажувати туди всі необхідні включені проекти. Таким чином, при необхідності додаткових проектів вони також будуть завантажені на цільову станцію автоматично.

Наразі в Citect для пересилання фалів виконання та їх запуску рекомендується використовувати механізм розгортання – поширення проектів з одного місця на всі необхідні робочі станції та перезапуск середовища виконання. У комплекті дистрибутиву Citect постачається Сервер Розгортання (Deployment Server) – спеціальне ПЗ в мережі, яке зберігає версії проектів виконання і видає їх Клієнтам Розгортання (Deployment Client) за необхідності. Інженерна станція завантажує проект на Сервер (Add version), і за необхідності відбувається розгортання (Deploy) потрібної версії на робочі станції, які також є Клієнтами Розгортання. Деталі читайте в посібнику.

4.6. Приклад організації проектів в SCADA zenon

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

SCADA zenon (офіційна назва zenon Supervisor) включає в себе ПЗ середовища розроблення (Editor) та середовища виконання (Runtime). Обидва доступні як в 32-бітній так і в 64-бітній версії. Окрім самих середовищ, у комплекті постачається велика кількість утиліт різного призначення. Одна з них – утиліта запуску (Startup Tool), яка дає можливість виконати такі дії (рис. 4.9):

Рис. 4.9. Вікно запуску та вікно вибору запуску утиліт zenon

запустити середовище розроблення або виконання з вказаними параметрами (Application Options);
запустити різні версії zenon, які можуть бути встановлені на одному ПК;
адміністрування різних екземплярів SQL для тієї самої версії zenon;
адміністрування налаштувань для різних версій;
означення мов для середовищ розроблення та виконання перед їх запуском;
означення мови для ВЕБ-клієнта;
запуск утиліт з Startup Tool.

Startup Tool дає зручний інтерфейс для налаштування і запуску середовищ та потрібних утиліт. Частина з цих налаштувань змінюють параметри в файлі “zenon6.ini”, який означує режим та особливості роботи середовища розроблення та виконання. На станцію оператора та/або сервер SCADA ставиться тільки середовище виконання, а Startup Tool дає можливість вказати, який проект слід запускати.

Проект zenon Editor зберігається в базі даних яка керується СКБД SQL Server Express, яка інсталюється разом із середовищем розроблення. Для середовища виконання СКБД SQL Server з базою даних проекту середовища розроблення не потрібні.

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

Розроблення проектів проводиться у Робочому середовищі (Workspace), файл якого має розширення .wsp6 і завантажується при старті zenon Editor. В одному Робочому середовищі може бути підключено кілька проектів, в один момент часу активним для редагування є тільки один. Яке Робоче середовище необхідно завантажувати і який проект повинен бути активний при старті zenon Editor – означується в zenon6.ini, і може бути налаштований в Startup Tool (див. рис. 4.9). Після старту zenon Editor можна відкривати інші Робочі середовища та проекти.

Уся конфігурація бази даних середовища виконання проекту міститься в MS SQL Server Express, який інсталюється на інженерну станцію. Інші файли, що стосуються проекту, зберігаються в папці проекту розроблення, яка знаходиться поряд з файлами бази даних SQL. В одному Робочому просторі може бути створено кілька стандартних проектів та один глобальний. Глобальний проект може слугувати бібліотекою фреймів, символів, стилів та інших для всіх інших проектів, відкритих у Робочому просторі. Кілька проектів в одному Робочому просторі є сенс відкривати за кількох причин, наприклад необхідність копіювання частин проекту або включення кількох проектів в один інтегрований для цілей мультисерверної системи.

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

SCADA zenon пропонує багато помічників (wizards), які автоматизують процеси розроблення, їх можна викликати через меню Tools середовища розроблення. Також можна створювати свої макроси для автоматизації робіт по проекту в інтегрованих середовищах програмування VBA (Visual Basic for Application) або VSTA (Visual Studio Tools for Applications).

Ряд операцій з проектами в робочому просторі доступні через контекстне меню проекту (див.рис. 4.10):

активація (Activate project): проект відкритий для редагування (тільки один проект);
тримати проект в пам’яті (Keep project in memory): проект відкритий тільки для читання; якщо проект не відкритий для редагування і не в пам’яті, то його вміст не буде відображатися;
установити проект як стартовий (Set project as start project): один з проектів вибирається як стартовий, тобто буде запускатися при старті середовища виконання;
запустити проект на виконання.

Рис.4.10. Керування проектами.

В один момент часу один проект (з активною опцією Multi-user project) можуть редагувати кілька користувачів на різних інженерних станціях.

Через розділ проекту “Project Backup” створюються резервні копії, які зберігаються в папці проектів (див. рис. 4.10). Через контекстне меню ці копії можна експортувати (по суті копіювати) в потрібне місце, наприклад, на знімний носій, для перенесення на іншу інженерну станцію. Також у цей розділ можна імпортувати іншу версію резервної копії проекту. У будь-який момент часу можна відновити потрібну копію (Restore backup). Відновити резервну копію можна також через контекстне меню Робочого простору. Якщо необхідно перенести усі проекти Робочого простору, робиться його резервна копія, яку можна також за необхідності відновити. Файли резервних копій – це, по суті, архіви формату *.ZIP.

Діяльність по розробленню проекту передбачає:

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

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

Рис.4.11. Функції zenon

Проект має велику кількість властивостей, в яких означуються загальні функції, які стосуються розділів проекту. Деякі з цих властивостей будуть розглядатися в інших розділах посібника, тут зупинимося лише на основних, більшість з яких налаштовуються на вкладці General (рис. 4.12). У групі General та Name/Folder налаштовуються властивості щодо середовища виконання, які розглянуті далі. Через опцію “Versioning active” можна активувати керування версіями, у цьому випадку основний номер версії проекту (Main version) може бути змінений розробником, а додатковий (номер після крапки) – при кожному створенні резервної копії. Номер версії проекту перевіряється при передачі файлів виконання з використанням віддаленого транспорту або через мережну топологію і може бути прочитаний через змінну системного драйвера. Якщо в редакторі і в середовищі виконання при цьому завантажена інша версія, то буде відображатися попередження. Якщо виникає конфлікт під час передачі файлів Runtime через мережу, ви підтверджуєте або відхиляєте передачу для всіх проектів, які передаються на комп’ютер і в яких існують конфлікти. Виставивши опцію “XML export active”, можна при створенні резервної копії формувати файл з XML-версіями розділів проекту.

Рис.4.12. Основні властивості проекту.

Середовище розроблення zenon дає також можливість вести журнал змін у проекті, активація та деталізація якого налаштовується в розділі “History of changes”.

За допомогою помічника “Documentation Wizard” zenon можна сформувати документацію по проекту у форматі HTML.

Виконання та налагодження проекту

SCADA zenon дає можливість компілювати проекти повністю або частково (тільки внесені зміни). Скомпільовані файли на інженерній станції розміщуються в папці, яка задається у властивості проекту “Runtime folders” (див. рис. 4.12). SCADA zenon дає можливість вибрати версію середовища виконання, якщо вона відрізняється від версії редактора, підтримуються версії від 6.20 до актуальної (див. рис. 4.12). Опція “Windows CE project” вказує, що проект розробляється для операторської панелі.

При компіляції у вікні “Output window” виводяться повідомлення про результати. За замовченням налаштування проекту, чотири файли не будуть компілюватися, тому будуть виводитися відповідні повідомлення про відмову в переписуванні. Опція налаштування компіляції і перенесення цих файлів налаштовується в “Runtime Changeable” (див. інші розділи посібника). У процесі налагоджування компіляція без цих файлів не є критичною, тому на початку на ці повідомлення можна не звертати уваги. У SCADA zenon усі діяльності по створенню створені таким чином, що ймовірність того, що проект не скомпілюється дуже низька.

Для налагодження в SCADA zenon можна використовувати такі засоби:

файли журналів, в які записуються повідомлення та помилки, за замовчуванням розміщується в “%ProgramData%\COPA-DATA\LOG”;
діагностична утиліта “Diagnosis Viewer”, яка дає можливість журналювати повідомлення та помилки підключеної робочої станції та зручного перегляду журналів;
системні змінні, які доступні через драйвер введення/виведення SYSDRV (рис. 4.13) і можуть бути використані як для отримання діагностичної інформації, так і для керування системою;
функції zenon, зокрема Application (див. рис. 4.13);
спеціальні типи екранів, наприклад Variable Diagnostic.

Рис. 4.13. Вікно створення системних змінних та вікно вибору функцій Application

Серед функцій групи Application окремо варто виділити “Reload project online”, яка дає можливість перезавантажити проект після його зміни без зупинки середовища виконання .

Для перевірки та зміни тегів є спеціальний тип екрана “Variable Diagnostic”, за допомогою якого можна передивитися стан змінних та змінити їх. Драйвери zenon підтримують режим відключення від джерела даних та імітації. Крім того, змінні підтримують режим використання альтернативного значення.

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

Файли проекту виконання для zenon задаються в zenon6.ini (параметр “VBF30”). Після активації проекту в середовищі розроблення він автоматично відмічається як стартовий, і в zenon6.ini прописується шлях, який вказаний у властивості проекту “Runtime folders” (див.рис. 4.12). Для встановлення параметра “VBF30” на цільовому комп’ютері рекомендується використовувати “Startup Tool”.

Після компіляції та налагодження проекту на інженерній робочій станції файли середовища виконання можна передати на цільову систему кількома способами:

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

Віддалена передача (Remote Transport) дає можливість установити з’єднання з цільовою системою через доступну комунікацію (TCP/IP або послідовний інтерфейс) з метою передачі файлів виконання та керування системою. Параметри віддаленої передачі налаштовуються в однойменних властивостях проекту (див. “Remote Transport” на рис. 4.12). Зокрема, там вказується середовище передачі та адреса або ім’я цільового комп’ютера. У налаштуваннях “Target” вказується папка, куди будуть переміщуватися файли виконання. Налаштування з’єднання можна буде також задати в “Connection settings” перед самим віддаленим підключенням.

За необхідності передачі файлів на цільову систему спочатку встановлюється з’єднання через пункт контекстного меню проекту “Remote transport”->”Establish connection” (рис. 4.14). Для захисту від несанкціонованого підключення необхідно вказати пароль. При першому з’єднанні цей пароль порожній, його можна задати в меню “Change connection password”. Після встановлення з’єднання у вікні “Output window” виводиться інформація про цільову систему та про сумісність проекту з середовищем виконання (див. рис. 4.14)

Рис. 4.14. Віддалена передача

Після встановлення з’єднання файли можна передавати на цільову систему або в зворотний бік. Слід відмітити, що при передачі файлів через віддалений транспорт першого разу треба зробити компіляцію всіх файлів, тобто зняти всі опції в “Runtime changeable data”->”Do not generate and transfer”, інакше буде видана помилка передачі. Для запуску саме цього проекту в меню віддаленої передачі вказується опція “Set project as start project”. Через меню віддаленого транспорту проект можна запускати, зупиняти, перезапускати, а за необхідності перезавантажувати ПК.

Для успішної передачі файлів на цільовій системі повинна бути запущена служба ZenSysSrv.exe (за замовчуванням додається в автозапуск при встановленні IDE zenon).

Команда “Start Remote Desktop connection” викликає доступ до віддаленого керування або контролю робочого столу цільової системи. Перед цим на цільовому ПК необхідно активувати цю опцію і налаштувати через утиліту zenon “Remote Desktop Server configuration”.

<– Лекція 3. Інші функції SCADA/HMI

–> Лекція 5. Підсистема керування збором та обробкою даних в реальному часі

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

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

Загальні принципи розроблення АРМ оператора на базі SCADA/HMI from Пупена Александр