Олександр Пупена, ТК-185
Місце SCADA/HMI в інтегрованій системі керування
На сучасних підприємствах засоби SCADA/HMI не функціонують самі по собі і повинні взаємодіяти з іншими рівнями керування. Класична структура інтегрованої системи керування підприємством має вигляд піраміди (рис.1), де засоби SCADA/HMI та ПЛК займають 2-й рівень (керування АСКТП). Вони взаємодіють з процесом через контролери (PLC), які в свою чергу можуть бути поєднані між собою промисловими мережами. Обмін SCADA/HMI з контролерами проходить у м’якому реальному часі, тобто коли запізнення оновлення даних не критичне, а між контролерами – в жорсткому реальному часі, коли дані повинні надходити в чітко визначені проміжки часу. У свою чергу, промислові контролери взаємодіють з технологічним процесом через датчики та виконавчі механізми, які можуть підключатися з використанням уніфікованих сигналів або промислових мереж рівня датчиків.
Як видно з рис.1, у сучасних системах керування підприємством рівень SCADA/HMI не є найвищим. Для ефективного керування всією виробничою діяльністю використовують системи керування виробництвом (АСК В) які прийнято називати MOM (Manufacturing Operations Management). До задач MOM входять функції керування різними виробничими операціями, зокрема (не повний перелік):

- керування операціями основного виробництва (MES – Manufacturing Execution Systems): планування, диспетчерування, запуск виконання, контроль та звітність виконання і т.п; системи призначені для різного типу керівників виробництва (начальник виробництва, начальник дільниці і т.п)
- керування операціями по обслуговуванню устатковання (ТОіР – технологічне обслуговування та ремонт; EAM – Enterprise Asset Management, який включає також функції вищого рівня): планування, контроль стану, контроль виконання, звітність, замовлення деталей і т.п.; системи призначені для інженерно-технічних підрозділів підприємства (механіки, електрики, КВПіА);
- керування операціями по керуванню якістю (LIMS – Laboratory Information Management System): планування та виконання контролю якості, формування звітної інформації по якості і т.п.; системи призначені для керівників з якості, працівників лабораторій і т.п;
- керування операціями по керуванню запасами (WMS – Warehouse Management System): планування та контроль наявності, переміщення сировини, напівпродуктів та продуктів; системи призначенні для начальників складів, виробничників та іншого персоналу, відповідального за запаси.
У свою чергу, системи MOM взаємодіють з системами рівня керування підприємством (АСК П), а саме його фінансово-економічною діяльністю. До таких системи відносяться системи ERP (Enterprise Resource Planning), призначення яких – автоматизація планування, бізнес-процесів, організаційно-економічної діяльності, документообігу і т.п. Також там можуть виконуватися інші спеціалізовані застосунки, як SCM (Supply Chain Management) для керування ланцюжком постачань. З рівня MOM в системи рівня АСК П передаються узагальнені виробничі показники, а на рівень MOM об’ємні виробничі плани.
Системи рівня керування рівня MOM та АСТКП забезпечують виконання виробничих операцій, або іншими словами автоматизують операційні технології OT (Operation Technologies). Системи керування бізнес-процесами автоматизують інформаційні процеси і відносяться до класу IT (Information Technologies). На виробничому підприємстві ці два сектори взаємодіють для забезпечення функціонування єдиної інтегрованої системи керування усім підприємством.
Для реалізації єдиної інтеграційної платформи даних OT часто використовуються засоби Historian.
Фізична структура інтегрованої системи може відрізнятися в залежності від підходів. Наприклад інтегрування рівнів може проводитися з використанням технологій промислового Інтернету речей (IIoT), а явно виділені системи деяких рівнів можуть бути відсутні.
Питання інтегрування зі SCADA та ієрархія устатковання
Треба розуміти, що забезпечення інтеграції на рівні даних – це лише частина задачі, інша частина – це інтерпретація цих даних.
На сьогоднішній день ці питання інтегрування систем керування описуються рядом стандартів, зокрема ДСТУ EN 62264 та ДСТУ EN 61512. Згідно цих стандартів керування підприємством може бути представлено у вигляді функціональної ієрархії (рис.2). На кожному рівні вирішуються окремі функції та потребують різних часових рамок. Відповідно до рис.2 обмін між другим та третім рівнем може функціонувати як обмін зі SCADA. Стандарт ДСТУ EN 62264 стандартизує представлення об’єктів та функцій, які стосуються операційної діяльності на рівні 3. Іншими словами стандарт описує які повинні бути сутності (об’єкти) і як вони повинні бути представлені в інформаційних структурах (наприклад таблицях), для того щоб представити операційну діяльність виробництва. До таких об’єктів входять різні види ресурсів: устатковання (забезпечує виробництво), персонал, матеріали (з чого виготовляється і що виготовляється), активи (наявні підконтрольні необоротні ресурси) та їх об’єднання. Для представлення об’єктів рівня 2 (АСКТП) існують стандарти групи ДСТУ EN 61512, але вони стосуються тільки порційного типу виробництва, хоч можуть бути так саме прийняті і до інших типів виробництв.

Для обох стандартів спільним є представлення моделі рольової ієрархії устатковання (рис.3). Відповідно до цієї ієрархії кожне устатковання (equipment, обладнання) виконує певну роль у процесі виготовлення продукції. При інтегруванні верхніх рівнів з системами АСКТП, керування та контроль відбувається саме в поняттях устатковання. Тобто підконтрольне устатковання знаходиться в якомусь стані, і на нього йде певна команда. Розглянемо яке саме устатковання стосується АСКТП.

Модуль керування (Control Module) забезпечує виконання функцій керування обладнанням. По суті це ті засоби та їх функції, які прийнято показувати на схемах автоматизації як засоби КВПіА: датчики, виконавчі механізми, регулятори та їх об’єднання. Цей рівень устатковання може бути цікавим для систем класу ТОіР та EAM. Наприклад, системи ТОіР (технічного обслуговування та ремонт) може цікавити інформація про кількість спрацювань, мотогодини роботи, статистика тривог і т.п. Зверніть увагу, що у даному прикладі систему верхнього рівня цікавить інформація не про стан датчиків положення а про узагальнений стан виконавчого механізму.
Модуль технологічного устатковання (Equipment Module) – виконує певну дію в технологічному процесі, наприклад перекачку продукту (насосні агрегати), чи нагрівання (теплообмінники) і т.п. Вони включають в себе різне технологічне устатковання та модулі керування. При інтегруванні з верхнім рівнем так само може передаватися інформація про стан.
Робочий вузол (Work Unit) – робить певну одну або кілька виробничий операцій. Для порційного виробництва (Технологічний вузол, Unit) це може бути реактор, або ємність в якій виробляється певна порція продукту. Для неперервного це може бути певний апарат неперервного типу, для дискретного – якась машина (наприклад пакувальна). На верхній рівень може передаватися стан устатковання, кількість виготовленої продукції та інші узагальнені показники та статистичні дані. З верхнього рівня можуть передаватися команди на запуск (зупинку, паузу і т.п), задана кількість, потрібна операція, рецепт і т.п.
Робочий центр (Work Center) – це набір устатковання, що робить певний напівпродукт. Як і в попередньому випадку, може відбуватися обмін станами, командами і параметрами.
Як правило, рівень АСКТП не виходить за межі робочого центру, а часто і за рамки робочого вузлу. Тому устатковання на вищих рівнях не стосується SCADA.
Отже, з кожним устаткованням зв’язані як правило як мінімум два параметри: стан і команда. Для модулів керування та модулю технологічного устатковання стан може бути представлений набором статусів типу відкрито/закрито/відкривається/закривається, або включено/відключено а також нормальна робота/тривога і т.п. Для робочих вузлів і робочих центрів стан може описуватися складним автоматом станів. Крім станів та команд, устатковання також може мати режим (наприклад ручний/автоматичний), статистичну інформацію про кількість спрацювань, мотогодин роботи, кількість поломок і т.п.
Наявність моделей устатковання на кожному з рівнів робить можливим побудувати єдину базу SCADA. Це значно спростить інтегрування з функціональної точки зору. Якщо в рівень MOM необхідно передати якусь інформацію, зручно буде якщо вона буде вже підготовленою в термінах устатковання. Це може бути також певна звітна інформація, наприклад про кількість тривог, статистика по трендам, тощо за певний період часу. У засобах SCADA/HMI деяких виробників з’являється підтримка устатковання. У більшості випадків це зроблено не з метою інтегрування, а для спрощення контролю та керування. Нижче наведені приклади використання моделей устатковання в SCADA Citect та zenon, які надають можливість в середовищі виконання фільтрувати тривоги та записи в журналах по вибраному устаткованню а також виконувати функції для нього. Для середовища розробки устатковання можна використовувати як допоміжне поле для фільтрації. Це тільки частина з переліку доступних функцій, детальніше описано нижче.
Використання ієрархії устатковання в Citect
У SCADA Citect наявність устатковання не є обов’язковим. Однак, його використання значно покращує для оператора ситуаційну обізнаність, керованість процесом та може значно скоротити час розробки та модернізації. Починаючи з версії 7.4 в Citect з’явилися додаткові таблиці з означенням моделі устатковання (equipment, в рос.лок. «оборудование»). Кожен запис устатковання включає ім’я, яке має ієрархічну структуру, де ієрархічні рівні розділені крапкою. Так “Loops.Level” передбачає устатковання з іменем “Level”, що входить в устатковання верхнього рівня з іменем «Loops» (див рис.4). Ієрархію можна створювати шляхом добавлення подібних імен в редакторі моделі устатковання Citect Studio, але зручніше це робити через спеціальний редактор устатковання, який входить в середовище розробки Citect. Цей редактор відображає модель у наглядному деревовидному вигляді (рис.4).

Після створення екземпляра устатковання, його можна вказати в налаштуваннях тегів, трендових тегів та тегів тривог. Наприклад тег з назвою LOOP_1_PV слугує елементом ProcessVariable в устаткуванні Loops.Level (див.рис.4). Тепер до тегу у будь якому місці проекту можна звертатися двома способами:
- через ім’я тегу “LOOP_1_PV”
- або через елемент устатковання “Loops.Level.ProcessVariable”
Слід відмітити, що після встановлення середовище розробки Citect, за замовчуванням редактор графіки відображає вікно вибору тегу саме за іменем устатковання а не імені тегу. Це можна змінити в налаштуваннях параметрів Citect Studio.
Окрім іншого формату посилань на теги, їх прив’язка в якості елементів устатковання дає наступні можливості в середовищі виконання (див.рис.5):
- на сторінці переглядача тегів фільтрувати список тегів, відповідно до обраного обладнання
- на сторінках активних тривог, журналів подій (SOE) відображати записи тільки для елементів обраного устатковання
- відображати тренди для обраного устатковання
- використовувати навігатор устатковання

Використання устатковання в якості фільтру значно спрощує вибір необхідних тривог, тегів в списку або трендів. У першому випадку, оператор робить аналіз тільки тих тривог та подій з журналу, що стосується конкретної частини процесу. При цьому він робить це звичайним вибором в навігаторі. Те саме стосується відображення трендів. Зрештою, можна зробити окремі вікна, що динамічно прив’язуються до конкретного устатковання і надають усю необхідну інформацію саме по ньому. Для цього в Citect є багато Cicode функцій, що надають можливість отримувати дані з тегів про устатковання та навпаки, робити навігацію по устаткуванню, отримувати та змінювати його властивості. Властивість устатковання Page (рос.лок.«Страница») дає можливість задати сторінку, яка буде асоціюватися з ним. Через цю властивість навігацію по сторінкам можна зробити з використанням навігатору устатковання, що доступний поруч з меню в шаблонах стилю SxWStyle.
Устатковання також може мати стани, за допомогою яких можна налаштувати керування ним через планувальник. Крім тегів до устатковання можуть бути прив’язані акумулятори (Accumulator). Акумулятори можуть рахувати кількість запусків, інтегрувати певну величину, та рахувати загальний час роботи. При конфігуруванні в Citect інтерфейсу OPC ієрархія устатковання може бути використана для формування простору імен ItemID.
Окрім додаткових можливостей, які надає ієрархія устатковання SCADA Citect у середовищі виконання, розробник проекту може використовувати його як вихідну точку проектування. Враховуючи, що устатковання (Equipment) є додатковою властивістю тегів, їх можна використовувати в якості фільтрації та упорядкування записів в табличних редакторах тегів. Але це не єдина можливість, механізм устатковання дає можливість зовсім по іншому побудувати процес розробки. Класичний для Citect до версії 7.3 механізм розробки передбачав створення тегів (за необхідності акумуляторів), через заповнення таблиць або полів в редакторі. Це має ряд недоліків, зокрема передбачає велику кількість рутинної роботи по заповненню. При необхідності зміни тегу, розробнику приходиться шукати його в таблиці тегів де змінювати поля, потім в таблиці тегів тривог а потім можливо ще в таблиці трендових тегів. Більшість об’єктів предбачають однотипні структури, які згуртовані навколо устатковання. Так, наприклад з насосом зв’язано кілька параметрів (частота обертів, операційний стан, температура підшипників і т.п.), тривог та трендів. Citect дозволяє процес створення почати з устатковання, яке автоматично створить пов’язані з ним теги. Спочатку визначається тип устатковання, в якому задаються правила створення устатковання та необхідних тегів, що з ним пов’язані. Тип устатковання описується файлом XML, але розробнику не обов’язково розуміти його внутрішню структуру. Типи можна створювати та редагувати через редактор типів устатковання, який представлений окремою вкладкою в редакторі устатковання (рис.6).

Основним змістом типу є елементи (Item), кожен з яких може асоціюватися з змінним тегом, тривоговим тегом або трендовим тегом. При створенні тегів, він міг прив’язуватися до елемента існуючого устатковання. Тут же конфігурується зворотній напрямок – від створення устатковання та його елементу до тегів. На рис.6 до елементу Setpoint будуть прив’язані змінний тег, аналоговий аларм та трендовий тег. Екземпляри устатковання одного типу матимуть однаковий набір елементів, що створюватимуться за однаковими правилами. На рис.7 показані правила створення змінного тегу для елементу з іменем «Setpoint». В лівій частині вказуються імена властивостей тегу, а справа – правила створення їх значення. Текст, що взятий у фігурні дужки «{}» передбачає вставку замінника, що означений в цьому тексті. Так, наприклад «{equipment.tagprefix}_SP» вказує на те, що значенням даної властивості буде конкатенація (поєднання) значення властивості “Tag prefix” (рос. лок. «Префикс дескриптора») устатковання та «_SP».

У якості полів обладнання можуть бути усі, що перелічені на рис.7 (показані через контекстне меню) та додаткові користувацькі. Таким чином, при створенні нового устатковання в редакторі вказується його тип, ім’я, заповняються його властивості, після чого необхідно виконати команду оновлення устатковання. У результаті оновлення створиться не тільки устатковання, а і усі необхідні теги. При зміні типу устатковання (видалення, зміна, добавлення елементів) процедура повторюється. При цьому усі створені теги не доступні для редагування з редактору тегів, вони оновлюються тільки через зміну устатковання та його типу.
Аналогічним чином можна означувати акумулятори. Через вкладку типу States (рос.лок.«Состояния») означуються стани (див.рис.6).
Практика використання такого підходу до розробки проектів доказала свою ефективність та значне скорочення часу в життєвому циклі проекту.
Використання ієрархії устатковання в SCADA zenon
У SCADA zenon ієрархія устатковання створюється у відповідному розділі проекту «Equipment Modeling» (див.рис.8). Ім’я групи устатковання (Equipment group) може бути вказано в якості додаткового параметру для більшості елементів проекту, у тому числі:
- змінних (Variables) та типів змінних
- екранів (Screens) та шаблонів (frames)
- функцій та скриптів
- стандартних рецептів та груп рецептів
- часових функцій
- моделей планувальника
- пунктів меню
- користувачів
- матриць реакцій
- переприсвоєнь (Allocation)
- класів, груп та дільниць тривог
Один елемент може одночасно назначений кільком групам устатковання. Назначивши елемент устаткованню, воно може бути використано в якості фільтра в середовищі виконання. Фільтр налаштовується шляхом вибору груп устатковання, до якого має входити елемент щоб відображатися в таблиці. Крім того в ієрархії устатковання можна отримати інформацію про прив’язані до нього елементи через пункт «Linked elements» контекстного меню.

У середовищі виконання устатковання може бути використано в якості фільтрів та додаткових параметрів в функціях. Наприклад, в аргументах функцій виклику екранів AML, CEL, Recipegroup Manager, або керування змінами (Shift management) в якості фільтру можна вказати групу устатковання. При цьому можна вказати чи необхідно відображати елементи тільки вибраного рівня, чи також усіх підлеглих (опція «Hierarchic filter»). Ієрархію устатковання також можна використовувати в означенні тривог.
Вибирати устатковання для фільтрів можна і після відкриття екранів. Це можна зробити через спеціальні екрани налаштування фільтрів, де поряд з вибором часу, формату відображення і т.ін можна вказати групу устатковання. Однак це не дуже зручно, так як потребує великої кількості операцій. Альтернативою є використання спеціального типу екрану «Equipment model». Після створення екрану, для його виклику створюється функція «Screen switch», в аргументах якої можна налаштовати екрани, фільтри яких будуть оновлюватися при виборі групи устатковання («Screens to be update»). Тут можна також вказати текстову змінну, яка буде отримувати назву групи вибраної групи устатковання (рис.9). Використовуючи екран моделі устатковання у середовищі виконання оператор зможе вибирати необхідну групу, та підтвердити свій вибір. Після цього фільтри усіх налаштованих екранів будуть оновлені. Використовуючи кнопку запуску функції можна також запустити усі функції, що прив’язані до вибраної групи устатковання.

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