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

10.1.1. Життєвий цикл SCADA/HMI в системі АСКТП

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

1) розроблюється новий об’єкт керування (установка, машина, відділення заводу тощо);

2) розроблюється нова система керування для існуючого об’єкта;

3) модернізується існуюча система керування, заміною рівня керування: модернізується рівень контролерів, SCADA/HMI або ставиться нова система DCS; рівень збирання даних та керування (датчики, виконавчі механізми, перетворювачі) залишаються практично без змін або доповнюються чи частково замінюються;

4) модернізується існуюча система керування заміною підрівня SCADA/HMI.

У кожній з цих ситуацій можливі різні варіанти життєвих циклів об’єкта керування та підсистем керування, але у будь-якому випадку вони пов’язані між собою. У більшості випадків життєві цикли системи керування та SCADA/HMI не розділяються. Часто розроблення, впровадження та експлуатація розглядаються в контексті життєвого циклу всього автоматизованого комплексу. З іншого боку, в підрозділах 10.2 та 10.3 розглядаються окремі життєві цикли для HMI та системи тривожної сигналізації відповідно до стандартів ISA-101 та ISA-18.2. Зрештою, кількість життєвих циклів може визначатися кількістю організацій та людей, які задіяні в процесах керування ними, та тим, як вони відносяться до цільових систем. Для кращого розуміння керування життєвими циклами варто ознайомитися зі стандартами та іншими роботами по системній інженерії, для початку, наприклад з посібниками Анатолія Левенчука [1, 2], деякі моделі будуть розглянуті в підрозділі 10.4.

Надалі в посібнику розглядається ситуація, при якій розроблення SCADA/HMI проводиться окремою організацією або особою, яка розглядає цей підрівень керування як окрему систему (проект) зі своїм життєвим циклом. Однак слід розуміти, що про таке розділення можна говорити тільки відносно прикладного програмного забезпечення системи, оскільки інші види забезпечень (технічне, інформаційне, організаційне) стосується усієї системи керування. Тому цей підрозділ зосереджується саме на процесах життєвого циклу ПЗ SCADA/HMI, а інші процеси розглядаються в дисципліні “Проектування АСКТП”, наприклад у посібниках [3, 4]. Зокрема, вибір та реалізація структури комплексу технічних засобів проводиться з урахуванням системи керування як єдиного цілого (враховуються усі засоби), тому вибір структури системи SCADA/HMI у цьому підрозділі не розглядається. Проектування пунктів керування передбачає врахування значної кількості дисциплін та відповідних стандартів, що виходить за рамки цього посібника, хоч деякі процеси розглядаються в підрозділі 10.2.

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

Вибір моделі, процесів та методів керування життєвим циклом ПЗ визначається рядом факторів, які розглядаються в підрозділі 10.4. Є спеціалізовані стандарти, які означують життєві цикли стосовно HMI (ISA-101; див. підрозділ 10.2) та систем тривожної сигналізації (ISA-18.2; див. підрозділ 10.3). У загальному, будемо вважати, що життєвий цикл прикладного ПЗ SCADA/HMI поділяється на стадії:

Розроблення технічних вимог (технічного завдання). На цій стадії формулюють призначення підсистеми SCADA/HMI і означують основні вимоги до неї. Процеси цієї стадії розглядаються в параграфах 10.1.2–10.1.11. Стадія може завершуватися формуванням документа “Технічні вимоги” або розділом чи окремим документом “Технічне завдання” (ТЗ), яке фіксує принципові вимоги та основні проектні рішення.
Проектування. На цій стадії проводяться проектні роботи щодо розроблювальної (модернізованої) SCADA/HMI або її частини. Ця стадія не передбачає створення ПЗ SCADA/HMI, а лише документів щодо проектних рішень. Основні процеси, методи та результати діяльності цієї стадії для SCADA/HMI описано в підрозділі 10.2 та 10.3. Однак, якщо розглядати саме розроблення прикладного програмного забезпечення, виходом цієї стадії для SCADA/HMI можуть бути вимоги до її ПЗ.
Реалізація. Ця стадія передбачає створення програмних проектів для SCADA/HMI та попередні тестування. Деякі етапи та процеси цієї стадії розглянуті в параграфі 10.1.10.
Введення в дію. Ця стадія передбачає пусконалагоджувальні роботи на об’єкті та навчання персоналу (див. параграф 10.2.8).
Експлуатація. На стадії експлуатації проводиться обслуговування SCADA/HMI, що передбачає внесення певних змін у систему за необхідності. Етапи цієї стадії розглядаються в підрозділі 10.2, експлуатаційна документація – в параграфі 10.1.11.

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

10.1.2. Розроблення технічних вимог або технічного завдання

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

Технічні вимоги можуть бути оформлені у вигляді окремого документа або як частина технічного завдання (ТЗ). Технічне завдання – це формалізований документ, який може виконуватися згідно з вимогами до оформлення. Старий радянський стандарт щодо вимог до його оформлення ГОСТ 34.602-89 скасовано в Україні, але його аналогу поки що немає. Тому розглянемо структуру ТЗ відповідно до ГОСТ 34.602-89. Технічне завдання повинно складатися з таких розділів:

1. Загальні відомості.
    1.1. Повне найменування системи та її умовне позначення.
    1.2. Шифр теми або шифр (номер) договору.
    1.3. Найменування підприємств (об’єднань) розробника та замовника (користувача) системи та їх реквізити.
    1.4. Перелік документів, на основі яких створюється система, ким і коли затвердженні ці документи.
    1.5. Планові терміни початку та закінчення роботи по створенню системи.
    1.6. Відомості про джерела та порядок фінансування робіт.
    1.7. Порядок оформлення та пред’явлення замовнику результатів робіт по створенню системи (її частин), по виготовленню та наладці окремих засобів (технічних, програмних, інформаційних) та програмно-технічних комплексів системи.
2. Призначення та цілі створення (розвитку) системи.
    2.1. Призначення системи.
    2.2. Цілі створення системи.
3. Характеристика об’єкта автоматизації.
4. Вимоги до системи.
    4.1. Вимоги до системи в цілому.
        4.1.1.Вимоги до структури та функціонування системи. 
        4.1.2.Вимоги до чисельності та кваліфікації персоналу системи та режиму його роботи.
        4.1.3.Показники призначення.
        4.1.4.Вимоги до надійності.
        4.1.5.Вимоги безпеки.
        4.1.6.Вимоги до ергономіки та технічної естетики.
        4.1.7.Вимоги до транспортабельності для пересувних АС.
        4.1.8.Вимоги до експлуатації, технічного обслуговування, ремонту та збереженню компонентів системи.
        4.1.9.Вимоги до захисту інформації від несанкціонованого доступу.
        4.1.10.Вимоги до по збереженню інформації при аваріях.
        4.1.11.Вимоги до захисту від впливу зовнішніх дій.
        4.1.12.Вимоги до патентної чистоти.
        4.1.13.Вимоги по стандартизації та уніфікації.
        4.1.14.Додаткові вимоги.
    4.2. Вимоги до функцій(задач), що виконуються системою.
        4.2.1.Перелік функцій, задач або їх комплексів (в тому числі що забезпечують взаємодію частин системи). функціональних підсистем.
        4.2.2.Часовий регламент реалізації кожної функції, задачі (або комплексу задач).
        4.2.3.Вимоги до якості реалізації кожної функції (задачі або комплексу задач), до форми представлення вихідної інформації, характеристики необхідної точності та часу виконання, вимоги одночасності виконання групи функцій, достовірності видачі результатів.
        4.2.4.Перелік та критерії відмов для кожної функції, по якій задаються вимоги надійності.
    4.3. Вимоги до видів забезпечення.
        4.3.1.Вимоги до математичного забезпечення.
        4.3.2.Вимоги до інформаційного забезпечення.
        4.3.3.Вимоги до лінгвістичного забезпечення.
        4.3.4.Вимоги до програмного забезпечення.
        4.3.5.Вимоги до технічного забезпечення.
        4.3.6.Вимоги до метрологічного забезпечення.
        4.3.7.Вимоги до організаційного забезпечення.
        4.3.8.Вимоги до методичного забезпечення.
        4.3.9.Вимоги до інших видів забезпечення.
5. Склад і зміст робіт по створенню(розвитку) системи.
6. Порядок контролю та приймання системи.
7. Вимоги до складу та змісту робіт по підготовці об’єкта автоматизації до введення системи в дію.
8. Вимоги до документування.
9. Джерела розроблення.
10. Додатки (за необхідності).

У наступних параграфах розглянемо деякі з розділів детальніше. Розгляд усіх інших розділів виходить за рамки даного посібника.

10.1.3. Характеристика об’єкта автоматизації та вимоги до системи в цілому

У характеристиці об’єкта автоматизації варто навести загальний опис об’єкта автоматизації та тих функцій, які будуть або вже реалізовані в підсистемі керування (контролері). Для ПЗ SCADA/HMI тут слід наводити не тільки опис самого об’єкта, й підсистем керування, з якими відбувається спряження. Тут варто навести:

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

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

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

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

Більш детально про ці вимоги до користувачів – у підрозділі 8.7.

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

У вимогах до надійності вказується необхідність резервування частин SCADA/HMI: серверів, шляхів доступу до джерел даних (наприклад ПЛК), мережних компонентів тощо. Детальніше про способи підвищення надійності SCADA/HMI описано в розділі 9.1.

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

Таблиця 10.1.

Приклад вимог до користувачів

Назва ролі	Призначення	Привілеї
Administrators	Адміністратори	Доступ до всіх сторінок та елементів введення, крім налаштувань КВПіА та зміни технологічних параметрів
ProdUsers	Оператори установки приготування продукту	Доступ до перегляду та керування сторінок керування процесом приготування продукту та основної мнемосхеми
HeaUsers	Оператори установки підігріву	Доступ до перегляду та керування сторінок керування процесом підігріву
Tech	Технологи	Доступ ProdUsers та HeaUsers, з можливістю змін технологічних параметрів
KVPiA	Служба КВПіА, обслуговуючий персонал	Доступ до всіх сторінок та елементів введення, доступ до блокування та розблокування тривог
Dispatch	Оператори-диспетчери виробництва	Тільки для перегляду

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

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

Детальніше про кібербезпеку подано в підрозділі 9.5.

10.1.4. Вимоги до функцій і задач

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

збирання та оброблення даних;
відображення та супервізорне керування (людино-машинний інтерфейс);
тривожна сигналізація;
ведення журналу подій;
архівування та виведення трендів;
керування рецептами;
керування рецептами відповідно стандартів ISA-88/IEC-61512;
формування виробничих звітів;
календарне планування (керування за розкладом);
мультимовна підтримка;
виконання спеціальних завдань (розрахунків, алгоритмів тощо);
обмін зі сторонніми базами даних для записування/читання;
обмін з іншими системами SCADA/HMI;
інтегрування з верхнім рівнем;
інші групи функцій.

Далі, відповідно до ГОСТ 34.602-89 для кожної з груп функцій, необхідно деталізувати:

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

Нижче розглянемо вимоги до кожної з груп функцій окремо.

10.1.5. Вимоги до збирання та оброблення даних

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

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

Вимоги, означені тут, можуть диктуватися не тільки необхідними функціями а і корпоративними правилами. Наприклад, може бути вимогою використання при обміні SCADA/HMI з засобами введення/виведення мережі Modbus TCP/IP, тоді як засіб підтримує кілька протоколів.

Інші вимоги стосуються збирання/змінювання окремих змінних (тегів) з/на пристроях. До кожного тегу у вимогах варто вказати:

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

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

типи та адреси змінних;
правила масштабування (для аналогових змінних);
опис структурних типів;
інші особливості обміну.

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

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

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

Приклад вимог до збирання та оброблення даних

Для обміну між ПЛК та SCADA/HMI необхідно використовувати протокол Modbus TCP/IP, де ПЛК виступає як Modbus Server (вміщує дані), а SCADA/HMI – Modbus Client (запитує дані для читання та записування). Резервування каналу не передбачається.

Передбачені дискретні, аналогові змінні та структурні змінні, що прив’язані (локалізовані) до адрес %MW та %M. Змінні займають різну кількість адрес у пам’яті ПЛК, що треба передбачати в SCADA/HMI:

типу INT, UINT займають одну комірку в області пам’яті %MW;
типу DINT,UDINT, REAL займають дві комірки в області пам’яті %MW;
типу EBOOL займають одну комірку в області пам’яті %M;
типу EBOOL, BOOL займають один байт в області пам’яті %MW (треба враховувати при використанні дискретних полів у структурних змінних).

У табл.10.2 наведено аналогові змінні та вимоги до них:

адреса у форматі %MW, що відповідає Modbus області “Holding Registers”;
тип змінної в ПЛК;
параметри масштабування (межі PLC та межі реальні), одиниці вимірювання;
періодичність оновлення та задіяння у функціях SCADA/HMI: “-“ – не задіяна в групі функцій;
доступ: R – тільки читання.

Таблиця 10.2. Перелік аналогових (числових) змінних, що доступні в ПЛК зі SCADA/HMI

Назва тегу	Адреса	Тип в ПЛК	Опис	Межі PLC	Межі реальні	HMI	ALM	TRND	LOG
T1_LT1	%MW100	INT	Рівень T1	0-10000	0-100 %	1c, R	1c	10c	-
…
HEA_TC1_OUT	%MW200	REAL	Вихід ведучого регулятора	0-100 %	0-100 %	1c	-	-	-
HEA_TC1_SP	%MW202	REAL	Уставка для ведучого регулятора	20-80°С	20-80°С	1c	-	10c	-
…
HEA_TT1_SP	%MW220	ARRAY[0..5] OF REAL	Завдання для програмного задавача	20-80°С	20-80°С	1c	-	10c	-

У табл. 10.3 наведено дискретні змінні, та вимоги до них.

Таблиця 10.3. Перелік дискретних (типу так/ні) змінних, що доступні в ПЛК зі SCADA/HMI

Назва тегу	Адреса	Тип в ПЛК	Опис	HMI	ALM	TRND	LOG	Примітка
D1_LSH	%M0	EBOOL	Сигналізатор верхнього рівня D1	1с	1с	-	1с	1=спрацював
…
D1_LVS1_CLS	%M4	EBOOL	клапан зливу D1 закритий	1с	1с	-	1с	1=закритий
T_SB1	%M15	EBOOL	запуск процесу приготування	1с	1с	1с	1с	1=команда на запуск
…
D1_LVS1_ALCLS	%m19	EBOOL	клапан зливу D1 не закрився	1с	1с	-	1с	1=тривога активна
…
D1_LVS2_ALCLS	%M21	EBOOL	клапан набору D1 не закрився	1с	1с	-	1с	1=тривога активна

10.1.6. Вимоги до відображення та супервізорного керування (людино-машинного інтерфейсу)

Процеси на стадіях та етапах життєвого циклу для підсистеми HMI досить детально розглянуто в підрозділі 10.2. Зокрема, згідно зі стандартом ISA-101, розроблення вимог належить до стадії “Системні стандарти” та етапу “Вимоги” стадії “Проектування”. Тут зупинимося на переліку найбільш типових вимог:

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

Далі наведено приклад спрощених вимог до підсистеми HMI. Для кращого розуміння матеріалу варто переглянути розділ 5.

Приклад вимог до підсистеми HMI

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

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

Таблиця 10.4. Перелік обов’язкових дисплеїв

Дисплей	Рівень	Стиль	Користувачі	Примітка
виробнича лінія	1	функціональний огляд	усі	стартова
відділення 1	2	схематичний огляд	усі
відділення 2	2	схематичний огляд	усі
…
керування установкою 1	3	процес	усі
керування установкою 2	3	процес	усі
…
список повідомлень тривог і подій	2	список тривог	усі
архів (журнал) повідомлень тривог і подій	2	список тривог	усі
настроювання контурів регулювання	4	логічне + графіки	КВПіА
настроювання та діагностування тегів	4	список	КВПіА
тренди процесів	4	графіки	усі
налаштування масштабування та перетворення усіх змінних	4	список	КВПіА
налаштування масштабування та перетворення вибраної змінної	спливна	список	КВПіА

На кожному дисплеї повинні бути:

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

Таблиця 10.5. Призначення кольорів

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

Вимоги до відображення елементів та компонентів дисплеїв:

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

10.1.7. Вимоги до тривог та подій

Процеси на стадіях та етапах життєвого циклу для підсистеми тривожної сигналізації розглянуто у підрозділі 10.3. Зокрема, згідно зі стандартом ISA-18.2, розроблення загальних вимог належить до стадії “Методологія тривог”, а детальних – до етапу “Специфікації технічних вимог системи тривожної сигналізації”. Однак при формуванні завдання для розробника SCADA/HMI необхідно також визначитися з переліком тривог, який, згідно зі стандартом ISA-18.2, називається “Головною проектною базою даних тривог” (див. параграф 10.3.3.).

Найтиповіші загальні вимоги (див. параграф 10.3.2):

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

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

Нижче наведено приклад спрощених вимог до тривог та подій. Для кращого розуміння матеріалу варто переглянути розділ 6 та підрозділ 10.3.

Приклад вимог до підсистеми тривожної сигналізації

Тривоги усіх класів та пріоритетів повинні включати автомат станів, означений стандартом ISA-18.2, а саме:

нормальний стан (NORM) – в якому процес або устатковання працює в межах нормальних характеристик;
стан непідтвердженої тривоги (UNACK) – стає активним унаслідок ненормальних умов і ще не підтверджений оператором;
стан підтвердженої тривоги (ACKED) – в якому тривога є активною, але оператор її підтвердив;
повернена до нормального стану, непідтверджена тривога (RTNUN) – в якому процес уже перебуває в межах норми, але попередній активний стан тривоги не був підтверджений оператором.

У системі слід передбачити принаймні ті пріоритети тривог, що вказані в табл. 10.6.

Таблиця 10.6. Перелік обов’язкових пріоритетів

Рівень	Назва	Призначення	Примітка
1	Критична	для інформування про критичні відхилення, які необхідно терміново усунути	найвищий пріоритет, кілька хвилин на виправлення ситуації
2	Попередження	для інформування про відхилення, які можуть згодом призвести до перед-аварійного стану	середній пріоритет, десятки хвилин на виправлення ситуації
3	Потреба в обслуговуванні	для інформування про несправність устатковання або засобів автоматизації, які потребують втручання обслуговуючого персоналу (КВПіА, механіки, електрики)	найнижчий пріоритет, кілька годин на виправлення ситуації

Тривоги з найвищим пріоритетом слід відображати найвище в списку тривог на дисплеях зведення та банерах.

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

Усі тривоги оповіщаються операторові процесу, інші адресати вказані в примітці в табл. 10.7.

Тривоги слід групувати за ознакою устатковання, або групи устатковання (зони процесу), за якими їх можна фільтрувати в дисплеях тривог. У табл. 10.8 наведено обов’язкові групи тривог.

Таблиця 10.7. Перелік обов’язкових класів тривог

Назва класу (символ позначення)	Призначення	Примітка
технологічні критичні: загальні (A), занадто високе значення (HIHI), занадто низьке (LOLO)	пов’язані з критичними відхиленнями від процесу	які не належать до HIHI та LOLO, є загальними критичними (A); пріоритет за замовченням 1, якщо не вказано інше
технологічні попередження: загальні (W), високе (HI), низьке (LO), відхилення (DEV)	пов’язані з відхиленнями від процесу	які не належать до HI, LO та DEV, є загальними попередженнями (W); пріоритет за замовченням 2, якщо не вказано інше
устатковання: загальна несправність (M)	пов’язані з несправністю технологічного устатковання	оповіщення чергових механіків; пріоритет за замовченням 3, якщо не вказано інше
засобів КВПіА: загальна несправність (KIP); не відкрився або не включився (KNO); не закрився або не відключився (KNC)	пов’язані з несправністю датчиків або ВМ	оповіщення чергових КВПіА; пріоритет за замовченням 3, якщо не вказано інше
електричні: загальна несправність (ELE); не відкрився або не включився (EON); не закрився або не відключився (EOF)	пов’язані з несправністю електрообладнання	оповіщення чергових електриків; пріоритет за замовченням 3, якщо не вказано інше
системні ПЛК або SCADA/HMI: загальна помилка (E), помилка каналу ПЛК (E0), помилка в SCADA/HMI (EH)	пов’язані з несправністю складової верхнього рівня АСКТП (ПЛК, SCADA/HMI)	оповіщення спеціаліста АСКТП; пріоритет за замовченням 3, якщо не вказано інше
СПАЗ (SIS)	пов’язані зі спрацюванням системи протиаварійного захисту	пріоритет за замовченням 1, якщо не вказано інше

Таблиця 10.8. Перелік обов’язкових груп тривог

Назва	Призначення	Примітка
відділення 1	усі тривоги відділення 1, які не належать до жодної установки
відділення 2	усі тривоги відділення 2, які не належать до жодної установки
…
установка 1	усі тривоги, які належать до роботи установки 1
установка 2	усі тривоги, які належать до роботи установки 2
…

Тривоги слід відображати на тривогових банерах, дисплеях зведення тривог, журналах тривог.

Для кожної тривоги у списку активних тривог (дисплей зведення) повинні відображатися такі атрибути та значення:

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

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

дату і час підтвердження тривоги;
дату і час повернення до нормального стану.

У списках активних тривог (активних, банерах, журналах) фони написів повинні змінюватися за кольором відповідно до пріоритету. У табл. 10.9 показано способи відображення та з оповіщення відповідно до пріоритету для кожного з станів, окрім нормального (в журналах завжди білий фон). Заблоковані тривоги не показуються у списках активних тривог.

Таблиця 10.9. Вимоги до візуальної індикації кольором у списках тривог та звукового оповіщення тривог за пріоритетами

У журналах тривог кольори фону використовувати не рекомендується.

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

прямокутник червоного забарвлення для 1-го пріоритету;
трикутник жовтого забарвлення для 2-го пріоритету;
ромб фіолетового забарвлення для 3-го пріоритету.

Кольори та миготіння повинні відповідати кольорам з табл. 10.9. За можливості рекомендується в написах символів вказувати символьні позначення класу тривоги.

Тривоги, які належать до класів, що призначені для обслуговуючого персоналу (КВПіА, механіки), повинні повідомлятися через засоби дистанційного оповіщення (SMS, альтернативно – через сервіси інтернет-повідомлень) із зазначенням усіх атрибутів.

Дисплеї зведення тривог повинні надавати можливості:

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

Дисплеї журналу тривог повинні надавати можливості забезпечувати фільтрацію за:

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

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

Технологічні тривоги повинні зберігатися в журналі не менш ніж три роки. Усі інші тривоги повинні зберігатися не менш ніж один рік. Має бути можливість експортувати усі тривоги в формат “*.CSV”.

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

Користувачі з правами технологів мають мати можливість змінити уставки тривог: граничні значення, затримку часу на спрацювання.

У табл. 10.10 подано початкові налаштування технологічних тривог для аналогових (числових) змінних. Межі LOLO, LO, HO, HIHI вказують на межі відповідно аварійно низького, низького, високого та аварійно високого значення змінної. Усі зазначені тривоги мають спрацьовувати за замовченням через 2 с після переходу через межу. Значення “Deviation” (відхилення) вказує на максимальну величину відхилення змінної від заданого значення. Затримка на спрацювання тривоги – 5 с.

Усі тривоги повинні зберігатися в журнал і відображатися в списку та зведенні тривог.

Таблиця 10.10. Налаштування аналогових (числових) тривог за змінними

Назва тегу	Опис	межа LOLO	межа LO	межа HI	межа HIHI	Deviation	Пріоритети	Класи
HEA_TT1	Т продукту на виході підігрівача попередження	-	20 °С	75 °С	-	1°С	2	LO/ HI/ DEV
HEA_TT1	Т продукту на виході підігрівача аварія	10 °С	-	-	80 °С	-	1	LOLO, HIHI
HEA_TT2	Т гарячої води на виході підігрівача попередження	-	0-100 °С	0-100 °С	0-100 °С	-	2/2/1	LO/ HI/ HI
HEA_TT2	Т гарячої води на виході підігрівача аварія	10 °С	-	-	65 °С	-	1	LOLO/HIHI

У табл. 10.6 вказано перелік тривог за дискретними змінними.

Таблиця 10.11.Фрагмент переліку дискретних (типу так/ні) тривог

Опис	Умова спрацювання	Пріоритет	Класи	Примітка
3-ходовий клапан не перейшов у позицію T1	T_LVS3 AND NOT T_LVS3_T1OPN	3	KNO	таймаут 5 с
3-ходовий клапан не перейшов у позицію T2	NOT T_LVS3 AND NOT T_LVS3_T2OPN	3	KNС	таймаут 5 с
клапан зливу D1 не закрився	D1_LVS1_ALCLS	1	KNС
клапан зливу D1 не відкрився	D1_LVS1_ALOPN	1	KNO

10.1.8. Вимоги до ведення журналу подій

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

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

Таблиця 10.12. Перелік подій та відповідних повідомлень у журналі

Повідомлення	Умова спрацювання	Категорія
запуск процесу приготування	T_SB1	повідомлення
набір у танк Т1	T1_LVS2	повідомлення
набір у танк Т2	T2_LVS2	повідомлення
злив з танку Т1	T1_LVS1	повідомлення
злив з танку Т2	T2_LVS1	повідомлення

10.1.9. Вимоги до архівування та виведення трендів

Роботи по розробленню підсистеми трендів, так само як і інших підсистем, як правило, проводяться в контексті розроблення всього проекту SCADA/HMI і явно не виділяються. Тим не менше, тут виділимо ті діяльності, які націлені саме на розроблення підсистеми трендів.

У технічних вимогах до SCADA/HMI повинні бути вказані:

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

Вимоги до відображення трендів можуть бути частиною вимог до HMI.

Приклад вимог до підсистеми трендів

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

Таблиця 10.13. Перелік аналогових (числових) змінних для архівування

Назва тегу	Опис	Періодичність опитування	Умови записування	Примітка
T1_LT1	рівень T1	10 с	зміна на 1%	для звітів та аналізу
…	…	…
HEA_TT1_SP	завдання для програмного задатчика	10 с	зміна на 1%	для звітів, аналізу, налагодження регулятора

Перелік дискретних змінних для записування в тренд наведений у табл. 10.14. Запис дискретних змінних у тренд повинен відбуватися за зміни значення або стану (якості), або з дискретністю, визначеною в періодичності опитування.

Таблиця 10.14. Перелік дискретних (типу так/ні) змінних для архівування

Назва тегу	Опис	Періодичність опитування
D1_LSH	сигналізатор верхнього рівня D1	1 с
…	…	…
Dozator2.START	запуск дозування дозатора 2	1 с

Система повинна передбачати відмітку недостовірності даних у трендах.

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

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

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

10.1.10. Вимоги до інших груп функцій

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

Вимоги до керування рецептами. У вимогах треба вказати, чи потребується в рецептах зміна процедури, яка, можливо, затребує додаткового модуля керування рецептами відповідно до стандартів ISA-88/IEC-61512. Якщо ж керування рецептами передбачає використання класичного функціоналу, у вимогах можуть бути вказані (див. підрозділ 8.4):

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

Вимоги до формування виробничих звітів. Як зазначено у підрозділі 8.5, підсистема звітів в SCADA/HMI, як правило, має обмежені можливості. Для створення потужних звітів, можливо, знадобиться окремий модуль або/та ПЗ. У цьому випадку вимоги до звітів можуть формуватися у вигляді окремого розділу. Тут розглянемо тільки можливі вимоги до простих звітів:

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

Вимоги до календарного планування (керування за розкладом). Загальна функціональність календарного планування розглянута в підрозділі 8.6. У переліку вимог можуть бути вказані:

вимоги до необхідності врахування робочих змін;
вимоги до відносного часу виконання дій;
вимоги до врахування особливих календарних днів (свят, вихідних);
перелік дій, які необхідно виконувати за розкладом.

Вимоги до мультимовної підтримки. Функції мультимовної підтримки розглянуті у підрозділі 8.8. Вони можуть бути частиною вимог до лінгвістичного забезпечення. У вимогах можуть бути наведені:

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

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

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

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

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

Можливі технології доступу до баз даних зі SCADA/HMI розглянуті в розділі 8.3.

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

10.1.11. Реалізація ПЗ SCADA/HMI

Розроблення програмного проекту для SCADA/HMI може йти за різними сценаріями. Це насамперед залежить від таких факторів:

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

Один із можливих сценаріїв розроблення, за умови наявності у вимогах переліку тегів введення/виведення, тривог та трендів, ґрунтується на механізмі експорту-імпорту. Спочатку переліки тегів переводяться у формат електронної таблиці, доповнюються, адаптуються під імпорт у середовище розроблення SCADA/HMI. Робиться експорт тегів у формат, підтримуваний ним, наприклад CSV або XML. Проводиться імпорт тегів у середовище розроблення.

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

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

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

10.1.12. Експлуатаційна документація

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

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

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

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

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

Настанова програмісту повинна включати опис проекту для спеціаліста, що буде в подальшому супроводжувати розроблений проект. Вона може складатися з окремих розділів, що відповідають структурі вибраного програмного пакета. Інструментальні засоби можуть мати можливість генерувати такого виду документацію. Інший спосіб – розроблювати структуру проекту відповідно до реалізованих функціональних груп, наприклад аналогічно структурі цього посібника. Зміст розділів, присвячених HMI та підсистемі тривожної сигналізації, описаний відповідно в стандартах ISA-101 (див. підрозділ 10.2) та ISA-18.2 (див. підрозділ 10.3).

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

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

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

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

У розділі “Людино-машинний інтерфейс” можна навести переліки дисплейних мнемосхем, діалогових вікон, спеціальних дисплеїв. Для кожного дисплея навести знімок екрана, де вказати список змінних, використовуваних на ньому. Описати призначення реалізованих елементів індикації та органів керування та взаємозв’язок між ними й змінними. У якості підрозділу варто навести перелік та опис усіх бібліотечних елементів та компонентів (вбудованих або власних), які були використані в проекті. Тут слід навести усю інформацію, що відповідає системним стандартам, означеним в ISA-101 (див. параграф 10.2.3). Зокрема, описати використання кольорів, повідомлень, звукових оповіщень і т. п. Рекомендується привести декілька зображень мнемосхеми, що відповідають різним станам об’єкта керування.

Прикладом щодо оформлення розділу підсистеми подій та тривожної сигналізації може бути Методологія зі стандарту ISA-18.2 (див. підрозділ 10.3). В описі можна подати загальну архітектуру створеної підсистеми тривожної сигналізації. Тут вказуються використані автомати станів, пріоритети, типи, класи тривог, принципи їх групування тощо, як це давалось у технічному завданні. Навести перелік усіх тривог (тегів тривог), умови їх виникнення і зникнення. Варто вказати сенс виникнення кожної тривоги, її важливість і критичність реагування оператора на неї. Тут слід описати способи відображення тривог, можливі фільтри, навести зображення відповідних дисплеїв на АРМ, повідомлень і т. п. Слід розкрити питання, пов’язані з архівацією даних про тривоги й реакції оператора. Все це дати з наведенням конкретних полів в SCADA/HMI. У якості ілюстрації роботи АРМ можна навести кілька зображень вікон повідомлень про події та тривоги.

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

Опис підсистеми перегляду трендів можна винести в окремий розділ, в якому розглянути реалізовану підсистема відображення графіків трендів на дисплеях. Варто описати тренди реального часу та історичні тренди, вказати призначення кожного з них, зроблені настройки в середовищі розроблення. У якості ілюстрації роботи АРМ навести 1–2 зображення дисплеїв трендів.

Також у настанові варто описати інші функції, реалізовані в системі, такі як керування доступом, формування звітів, статистичного оброблення, ОРС та WEB-сервісів, компоненти ActiveX, зазначивши необхідні параметри. Навести вихідні тексти всіх розроблених скриптів, з коментарями.

У кінці опису доцільно навести короткий перелік основних елементів проекту із зазначенням їх кількості (наприклад, “аналогових змінних – 45, …, дисплеїв – 5, …, трендових тегів – 20, …, подій – 33, …, форм звітів – 2, …”).

Настанова операторові (інструкція користувача) потрібна для підготовки та інструктування оператора, який є первинним користувачем системи. Настанова повинна містити повний опис інтерфейсу та функціональних можливостей SCADA/HMI разом з ПЛК, які знаходяться в області його професійних обов’язків. На сьогоднішній день автору цього посібника не відомі стандарти, які використовуються в Україні для вимог до опису цього документа. Діючий до недавнього моменту “РД 50-34.698-90” відмінено, проте його можна брати за основу в якості загальної структури. Згідно з РД, структура цього документа повинна мати такий вигляд:

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

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

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

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

<– Розділ 10. Життєвий цикл SCADA/HMI

–> 10.2. Керування життєвим циклом HMI відповідно до стандарту ISA-101