3. Підходи до реалізації функцій рецептурного керування

Олександр Пупена,
Роман Міркевич,
Олег Клименко

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

3.1. Майстер рецепти та керівні рецепти

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

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

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

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

3.2. Принципи реалізації рецептів з однією процедурою

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

Рис. 20. Приклад процедури керівного рецепту з посиланням на реалізовану процедуру в устаткованні

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

BATCHID – унікальний ідентифікатор партії продукту, використовується для простежування виготовлення партії. Застосовні лише для керівного рецепту. Зазвичай генерується при створенні та запуску керівного рецепту на виконання з часу та дати.
MSRECIPE_ID – унікальний ідентифікатор майстер рецепту, використовується для посилання на шаблон як при виготовленні партії так і при простежуванні.
Змінна стану та змінна часу стану – використовується для керування виконанням процедури технологічної комірки керівного рецепту (запуск, зупин, утримування), і зазвичай відповідає. Застосовні лише для керівного рецепту.
Параметри формули – вміщує необхідний набір полів, які відповідають за параметри виготовлення продуктів. Міститься як в майстер рецепті так і в керівному. При запуску керівного рецепту копіюються з відповідного майстер рецепту. Одним із параметрів може бути номер необхідної процедури технологічної комірки.
Статистична інформація (опційно) – вміщує набір інформації на основі якої будуть генеруваться звіти, наприклад, кількість виготовленої продукції, інформацію про перебіг технологічного процесу і т.д. Генерується керівним рецептом в процесі його виконання.
Вимоги до необхідного устатковання – технологічне устатковання на якому можна виконати конкретний майстер рецепт.

Таким чином, процедура технологічної комірки буде реалізована в програмі контролера, а рецепт матиме ідентифікатор, який посилається на дану процедуру. При необхідності приготування конкретного продукту потрібно вибрати майстер рецепт, який посилатиметься на необхідну процедуру. У складнішому випадку, майстер рецепт означує «технологічну програму» через послідовність процедур. Формат опису такої процедури може бути різним, в тому числі і з використанням мови PFC. Зрештою, він може вміщувати усі типи процедурних елементів (див.рис.21). Повні вимоги до структури керівного та майстер рецепта і мова PFC описані в стандарті IEC 61512-2 і виходить за рамки даного посібника. Приклад такої реалізації з використанням спеціалізованого модуля показаний в лабораторному практикумі [13] та продемонстровано на відео [14]

Рис. 21. Приклад процедури керівного рецепту з повною ієрархією рецептурних процедур

3.3. Приклад реалізації простих рецептів

Якщо рецептурна процедура технологічної комірки посилається на аналогічну апаратурну, рецепти можна реалізувати в ПЛК через структурні змінні. На Рис. 22. для прикладу представлена структура для спрощеного майстер рецепту. Усі майстер рецепти організовані в масив. Номер елемента в масиві є ідентифікатором конкретного майстер рецепта (аналог MSRECIPE_ID), за яким відбувається звернення. Усі інші поля майстер-рецепту по суті є параметрами формули.

Рис. 22. Приклад структури майстер рецепта

На Рис. 23. представлений приклад структури керівного рецепта, який включає формулу. При створенні даного рецепта в його поля формули копіюються відповідні поля майстер рецепта. Параметри формули керівного рецепта можна змінювати в процесі виконання і відповідно ці зміни ніяк не відображаються на майстер рецепті. У цьому керівному рецепті є поля BATCHID, структурне поле CFG для конфігурування параметрів процедури, структурне поле CTRL для керування процедурою, час та дата запуску процедури рецепта і час та дата завершення процедури рецепта (у структурі CFG). Додатково в цю ж структуру можна вписувати необхідні поля зі статистичною інформацією (наприклад значення лічильників при старті та завершенні рецепту). Зрештою, значення цієї структури можна записувати в базу даних для виведення на звіти та можливої реалізації внутрішньої простежуваності.

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

Навіть при такій простій реалізації рецептів, в якій вся процедура технологічної комірки є частиною устатковання, є сенс ділити її на менші процедурні елементи (етапи) для більшої гнучкості програми. Наприклад, можна вручну завершувати виконання одного етапу і починати виконання іншого. При цьому процедура технологічної комірки буде залишатися в стані ВИКОНУЄТЬСЯ, а етапи будуть проходити по своєму автомату станів. У свою чергу, зміна станів кожного етапу може фіксуватися в журналах і трендах для аналізу історії приготування партії. Наприклад на Рис. 24 зображено як процедура приготування добрив розділяється на декілька етапів перемішування, мийка, наповнення і т.д, кожен з яких може керуватися через окреме вікно. Даний підхід полегшує пусконалагоджувальні роботи, оскільки можна перевіряти програму керування незалежними частинами.

4. Підходи до реалізації функцій звітів порційного виробництва

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

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

Реалізація підсистеми звітності з використанням керівних рецептів стає можливою навіть з використанням класичних засобів автоматизації, без використання спеціалізованих модулів. Наприклад, на одному з об’єктів цукрового виробництва [9] для звітності в системі керування вакуум-апаратами було використано ПЛК та SCADA без спеціалізованих модулів. За наведеним вище принципом для кожного керівного рецепту створювався окремий запис (структурна змінна), який включав в себе BATCHID партії, початок та кінець процесу варки, ID технологічного вузлу та додаткову інформацію (наприклад, час перебування в стані HOLDING). При завершенні варки (відповідно і виконання керівного рецепту) у таблицю бази даних заносився цей запис, що давало можливість передивлятися історію варок звичайним переглядачем таблиць в БД (див. рис.25).

Рис. 25. Приклад реалізації історії «варок»

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

Рис. 26. Приклад реалізації онлайн-звіту по конкретному керівному рецепту

У проекті автоматизації тепличного комплексу [11] архівування даних проводилося безпосередньо на контролері. Це може здатися дивним, але виявилося, що зберігати дані по партії в ПЛК зручніше, ніж в SCADA/HMI. Інша справа – формування звітів за цими даними. У цьому проекті файли за необхідності копіювалися на ПК (через FTP), де аналізувалися в Excel з використанням скриптів VBA. Тоді це було найшвидшим рішенням, але зараз у нас є інше бачення формування звітів для такого типу задач. У цьому проекті ПЛК циклічно записував значення змінних стану процедурних та апаратурних елементів в текстовий файл, для їх простежуваності і подальшого аналізу. Також при зміні стану процедурних елементів, зокрема керівного рецепту, контролер генерував подію, яка записувалась в журнал на карту пам’яті ПЛК. У подальшому даний файл (Рис. 27) можна було аналізувати і обробляти спеціальним VBA макросом, або аналізувати через візуальний інтерфейс Excel. У тексті даного файла зберігались час події, BATCHID партії а також символьна назва певного етапу поливу. Як видно з даних записів, BATCHID унікальне для конкретної мийки, при подальшому аналізі саме воно повинне бути критерієм для виділення необхідної інформації.

Рис. 27. Запис звітної інформації засобами контролера

2. Використання процедурного керування згідно стандартів IEC-61512

Олександр Пупена,
Роман Міркевич,
Олег Клименко

Перейти до початку посібника

Для кращого розуміння подальшого матеріалу варто ознайомитися з основами порційного виробництва, наприклад з роботи [1].

2.1. Процедури

Вище описані принципи використання устатковання нижнього рівня як програмних об’єктів в проектах АСКТП незалежно від типу виробництва. У стандарті IEC 61512 до його функцій ставляться певні вимоги, які забезпечують можливість виготовлення продукту порційним способом з використанням різних рецептів. Перш за все, устатковання в стандарті розглядається як незалежний від виготовлення конкретного продукту або напівпродукту набір сутностей. Іншими словами, робочий центр, який в IEC 61512 носить назву технологічної комірки (див.рис.11), може робити певні технологічні операції, але не зав’язане на конкретній технології (конкретному рецепті). У свою чергу ці операції реалізовуються через певні технологічні дії, які може виконувати устатковання нижніх рівнів (технологічні вузли та модулі). Це значить, що технологічна комірка повинна спрямовувати діяльність устатковання нижніх рівнів для виготовлення конкретної партії напівпродукту відповідно до вказаного рецепту.

Таким чином, головним принципом побудови систем керування порційним виробництвом згідно стандарту IEC 61512 є початкове розділення функцій керування на дві взаємопов’язані групи:

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

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

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

Щоб пов’язати технологію з устаткованням, використовуються елементи технологічних дій – процедури. Технологія порційного виробництва продукту або напівпродукту передбачає виконання «технологічної програми», яка складається з кроків, кожен з яких передбачає виконання певної процедури, наприклад: 1) наповнили; 2) охолодили до 15 °С; 3) вкинули фермент в пропорції 1:100 … Ця технологія означується в рецепті, який вміщує також параметри (формулу) та іншу інформацію. По суті, «технологічна програма» в рецепті є також процедурою. Тобто рецептурна процедура складається з менших процедур, а ті, в свою чергу, посилаються на конкретні екземпляри в устаткованні, яке може їх виконувати. Так відбувається зв’язок рецепту з устаткованням. Найменші процедури називаються етапами.

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

2.2. Автомат станів та режими процедур

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

Стандарт пропонує один із варіантів набору станів та умов переходу між ними (див. Рис. 13). Перехід від стану до стану відбувається за командою, або за внутрішньою умовою завершення (для перехідних станів). Як рецептурна процедура, так і процедури, з якої вона складається, описуються автоматом станів. Наприклад, коли запускається рецептурна процедура (оператор натискає «ЗАПУСТИТИ»), вона переходить зі стану «ПРОСТІЙ» в стан «ВИКОНУЄТЬСЯ», і перша процедура в ній (етап) також переходить в стан «ВИКОНУЄТЬСЯ». Якщо необхідно призупинити технологічний процес за командою оператора, або за відсутністю сировини чи енергії процедура рецепту переходить в стан «ПРИЗУПИНЯЄТЬСЯ», що призведе до переходу в такий же стан усіх активних етапів.

Рис. 13. Варіант автомату станів процедурного елементу, означеного в стандарті IEC 61512

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

2.3. Ієрархія процедур

Як зазначалося вище, процедури мають ієрархічну структуру. Ієрархія процедур показує яким чином менші процедури реалізують виконання процедур вищого рівня (Рис. 14). Процедура, що означує приготування партії продукту є процедурою технологічної комірки (у стандарті її називають просто «процедурою»). Найменші процедури, які не можуть включати в себе інші, називаються етапами. Таким чином, процедури вищого рівня включають процедури нижчого, тобто координують їх роботу. Принципи взаємодії в цій ієрархії дещо схожі на ієрархію устатковання, яка розглянута вище. Процедура технологічної комірки виконується в межах однойменного устатковання, яке є робочим центром порційного типу (див.рис.11). В межах технологічної комірки можна виготовляти одну або кілька партій (Batch) одночасно. Виготовлення партії у порційному виробництві потребує технологічних вузлів (апаратів), в яких послідовно відбуваються виконання крупних технологічних дій – процедур апаратів. Ті у свою чергу можуть складатися з операцій, а ті – з етапів. Наявність процедур технологічної комірки і етапів в ієрархії є обов’язковою умовою, інші – за необхідності.

Рис. 14 Ієрархічне представлення процедурних елементів

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

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

2.4. Реалізація процедур в ПЛК

Згідно нашої практики розробки та впровадження, програмна реалізація процедури в ПЛК включає наступні змінні:

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

На Рис. 16. представлений фрагмент програмного коду реалізації процедури керування станцією водопідготовки. З даного фрагменту видно, що процедура виконує базове керування технологічним устаткованням через команди на виконавчі механізми (#VLVD1.CMD:=2 – команда на закриття клапана), а також координацію процедур нижчого рівня, які входять до її складу (наприклад “PHCTRL”.PH_BDWASHIRF200[#i].CMD_START := TRUE – це команда на запуск процедури PH_BDWASHIRF200). Відповідно до стану процедур нижчого рівня, процедура вищого рівня посилає їм команди керування та змінює свій стан. В залежності від стану в якому знаходиться процедура змінюються алгоритми керування, наприклад в стані ПРОСТОЮ (#CTRL.STA_IDLE = TRUE) не виконується нічого, окрім закриття клапанів.

Рис. 16. Фрагмент програми реалізації процедури керування станцією водопідготовки

2.5. Практика використання процедур

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

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

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

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

Можна означити як вести себе при кожному стані (при паузі, при аварії).
Одне технологічне устатковання може виконувати декілька процедур, як одночасно так і послідовно.
Кожну процедуру можна виконувати окремо, а потім з них будувати загальну програму виготовлення продукту, яка відповідатиме технологічному процесові;
Багато різного устатковання може виконувати один і той самий тип процедури, але реалізовувати його зовсім по різному (навіть з точки зору ступені автоматизованості);
Можна вести статистику по технологічним діям (порахувати скільки часу процедура виконувалась в конкретному устаткованні);
В процедуру можна ввести ручні операції, тобто певна процедура може завершитись лише в результаті підтвердження оператора. Так в проекті поливу теплиць приготування розчину добрив виконувалось з залученням ручних операцій по додаванню суміші добрив. Після кожної ручної операції оператор вносив в систему кількість доданих сумішей і підтверджував їх додавання. Після цього система самостійно рахувала і набирала необхідну кількість води. Вся ця інформація заносилась в архіви та звіти по кожному поливі.
Процедури можуть взаємно блокуватись – одна блокує або дозволяє виконання інших. Наприклад в проекті станції водопідготовки необхідно було блокувати запуск СІР-мийки, якщо відбувалось виготовлення продукції, і навпаки.

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

Подібні рішення ми використовували на ряді підприємств, де не було потреби у змінній рецептурі, але використовувались періодичні процеси. Зокрема, процедурне керування разом з рядом іншими підходами IEC 61512 використовувалось в цукровому виробництві, де наша команда працювала в субпідряді ТОВ «САУТКОМ» [9]. На Рис. 17 зображено приклад інтерфейсу оператора для керування процедурою уварювання утфелю у вакуум-апараті. Варка відбувається в декілька кроків, послідовність яких можна змінювати за необхідності. Кожен крок можна запускати окремо, якщо це дозволено технологією. Програма досить просто реалізується, коли кожен крок процедури технологічної комірки є окремим етапом зі своїм автоматом станів. Команди «СТАРТ» та «СТОП» інтуїтивно зрозумілі. Етап «Утримування на воді» реалізує однойменну команду. Команда «Переривання» є налагоджувальною і доступна тільки в режимі для наладки.

Рис. 17. Інтерфейс оператора для керування процесом уварювання утфелю

Ці ж підходи були використані в ряді об’єктів «ЛВТ Інжиніринг», ПЗ для яких розробляла наша команда [10]–[11]. На рис.18 показаний налагоджувальний інтерфейс процедури рівня технологічного вузлу та етапів. Кожну процедуру можна запустити і зупинити, деякі мають ще команду та відповідний стан «ПАУЗА». У даному випадку одночасне виконання кількох етапів блокується.

Рис. 18. Інтерфейс налагодження для процедури технологічного вузла «Робота фільтру» та етапів.

На рис.19 наведений інтерфейс керування етапом «Полив» для АСКТП тепличного комплексу. Особливістю даного проекту в тому, що система складається з 15 ПЛК, кожен з яких відповідає за своє устатковання і має власний набір процедур. Один з ПЛК виконував роль координатора, який спрямовував дії процедур. Оператор також може запускати процедури окремо, використовуючи відповідний інтерфейс (рис.19)

Рис. 19. Інтерфейс керування для етапу «Полив»

Використання моделі устатковання в Citect для задач календарного планування

Олександр Пупена
Параграф з посібника «Розробка людино-машинних інтерфейсів та систем збору даних з використанням програмних засобів SCADA/HMI»

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

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

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

Планувальники як правило надають наступні можливості в середовищі виконання:

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

У Citect підсистема календарного керування базується на механізмі ієрархії устатковання (Equipment) . Для устатковання повинні бути зконфігуровані Стани (Equipment States), у властивостях яких вказано що саме необхідно робити при активації та активності цього Стану. Їх налаштування розглянуто в кінці статті.

Для устатковання, яке повинно керуватися з планувальника повинна бути виставлена в TRUE властивість «Заплановано» (Scheduled).

Для реалізації графічного інтерфейсу на одній із дисплейних сторінок необхідно розмістити ActiveX компонент «Scheduler» (рос.лок.«Планировщик»), який є на палітрі компонентів Citect. Він не потребує конфігурування в середовищі розробки, це може знадобитися хіба що для прив’язки певних властивостей до змінних. Уся діяльність налаштовується у Планувальнику у режимі виконання (рис.1). На ньому доступні кілька вкладок, які дають можливість налаштовувати календарний план (у вигляді дня, тижня, місяця, хронології), контролювати кінцевий стан планування. Можна також додавати спеціальні дні в календарі, для яких можна окремо конфігурувати поведінку устатковання.

У дереві відображається все доступне для планування устаткування (що має властивість Scheduled=TRUE). При виділенні устатковання, у календарному плані можна подивитися, встановити та змінити дату та час переходу на конкретний стан.

Рис.1. Зовнішній вигляд планувальника в Citect

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

Автоматичний (automatic) – режим в якому стан задається планувальником відповідно до означеного календарного плану;
Заміщення (Override), також називається ручним – коли станом керує оператор через контекстне меню.

У контекстному меню устатковання є відповідні команди переходу в режим, та у стан (у режимі Override). Перехід у режим та стан доступний також через функцію Cicode «EquipSetProperty». Функція «EquipGetProperty» дає можливість отримати активний режим та стан.

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

Про стани, режими, механізми поширення станів та режимів відповідно до IEC 61512 можете прочитати за посиланням.

Для устатковання, яке необхідно використовувати у підсистемі календарного планування необхідно вказати перелік Станів, для кожного з яких треба вказати (рис.2):

дію при вході в стан (Entry Action, рос.лок «Действие ввода») – дія, яка буде виконуватися, в момент переходу в цей Стан.
затримку (Delay, рос.лок. «Задержка») – час, який повинен пройти після активації стану до виконання дії; це може знадобитися тоді, коли прийшов час на активацію кількох одиниць обладнання, і треба уникнути одночасності, наприклад для зменшення сплесків струмів при вмиканні кількох двигунів;
повторювану дія (Repeat Action, рос.лок. «Действие повтора») – дія, яка буде повторюватися з вказаним періодом при активності стану;
період (Period) – час, через який буде виконуватися повторювана дія;
пріоритет (Priority) – число, що вказує пріоритет стану, якщо кілька станів виникають одночасно (при поширенні станів);

Режим DR (DR Mode) дає можливість задати кілька станів з різними діями на основі вибраного режиму споживання (Demand and Response); можна змінювати також через функцію EquipSetProperty;

рис.2. Налаштування обладнання та Станів для нього.

Модулі керування CM

Олександр Пупена,
Роман Міркевич,
Олег Клименко

Перейти до початку посібника

1.11. Модулі керування CM

Клапан, який розглядається у прикладах вище, виконує функцію керування фізичним устаткованням. З точки зору рольової ієрархії IEC 61512, що наведена на рис.11, він займає найнижчий рівень устатковання – модулів керування (Control Module, CM). Згідно стандарту є певні вимоги щодо приналежності устатковання до певного рівня, але на них ми зупинимося пізніше. Наразі будемо вважати так: все, що має відношення до засобів КВПіА, які показуються на схемах автоматизації можна віднести до модулів керування. Наприклад, датчики, виконавчі механізми та регулюючі органи, регулятори, частини контролерів та засобів SCADA/HMI що виконують конкретну функцію в контурах контролю, керування та регулювання. Устатковання не обов’язково є фізичним об’єктом, це може бути певне об’єднання взаємопов’язаних функцій. Типовим прикладом є ПІД-регулятор, який реалізований у вигляді виклику програмного бібліотечного функціонального блоку, або – весь контур регулювання, в який він входить.

Стандарт дозволяє включати одні модулі керування в інші. Тобто, контур регулювання може бути представлений модулем керування, який може включати в себе датчики, задатчики, функціональний блок регулятора, виконавчий механізм, оповіщувач і т.п., які у свою чергу також є CM. Розділення чи об’єднання CM робиться виключно з позицій зручності. Наприклад, у каркасі [8], незалежно від типу технологічного процесу, яким керує АСКТП, на рівні модулів керування пропонується виділяти типові об’єкти 3-х рівнів (Рис.12):

0-й (LVL0) канали контролеру – для діагностики каналу, прив’язки логічних каналів до фізичних, форсування входів/виходів:
- DICH – дискретні входи,
- DOCH – дискретні виходи,
- AICH – аналогові входи,
- AOCH – аналогові виходи,
- COMCH – комунікаційні канали
1-й (LVL1) – технологічні змінні для повної обробки інформації з процесу, включаючи прив’язку до каналу, фільтрацію, масштабування, інверсію і т.п.; для зручності відлагодження процесу; для функцій імітаційного моделювання; для функцій технологічної сигналізації;
- AIVAR – аналогові вхідні,
- AOVAR – аналогові вихідні,
- DIVAR – дискретні вхідні,
- DOVAR – дискретні вихідні:
2-й (LVL2) – для зручності налагоджування процесу; для функцій імітаційного моделювання; для функцій технологічної сигналізації; для ведення статистики:
- виконавчі механізми (запірні клапани, регулюючі клапани, двигуни, насоси);
- контури регулювання та керування: для функцій керування зі зворотним зв’язком.

Рис. 12. Ієрархія модулів керування в програмному забезпеченні

Така трирівнева архітектура передбачає модель взаємодії між рівнями CM:

обробка усіх елементів незалежно від рівня проводиться паралельно, тобто вкладеності виклику функцій та функціональних блоків немає, модель підлеглості реалізовується через механізм надання, або звичайними програмними зв’язками;
2-й рівень (виконавчий механізм, регулятор) не може взаємодіяти безпосередньо з 0-м (каналом);
усі елементи вищого рівня можуть взаємодіяти з будь-якими елементами нижчих, за винятком 0-го рівня (див. попередній пункт);
вищий рівень може змінювати стан нижчого: змінювати його значення, переключати в різні режими (форсування, імітація), змінювати налаштування тривог і т.д.;
елемент 1-го рівня (змінні) може заволодіти (allocation) елементом нульового (канали);
0-й рівень (канал) має інформацію про те, хто ним володіє;
1-й рівень (змінна) має інформацію про те, ким він володіє;
при реалізації об’єктів на різних пристроях (в розподілених системах) механізм взаємодії між ними відбувається через пару СЛОВО СТАНУ – СЛВО КОМАНДИ, а при реалізації в тому ж пристрої дозволяється використовувати як безпосередню зміну значення у підлеглого об’єкту (прямий доступ), так і через взаємодію СЛОВО СТАНУ – СЛВО КОМАНДИ.

Детальніше про реалізація багаторівневості модулів керування описані у роботі [8].

Практичні рекомендації до реалізації елементів стандарту IEC 61512 в програмному забезпеченні систем керування

Олександр Пупена,
Роман Міркевич,
Олег Клименко

1. Використання підходів ієрархії устатковання при розробці програмного забезпечення.

Тільки деякі з об’єктів автоматизації відносяться до порційного (Batch) типу. Тим не менше, як показує практика, багато підходів, викладених в стандарті IEC 61512 варто використовувати при впровадженні систем автоматизації незалежно від типу виробництва. Перш за все це відноситься до погляду на автоматизований комплекс з точки зору проектувальника та програміста АСКТП. Класичним є представлення автоматизованого комплексу у вигляді набору устатковання (залізо) та засобів автоматизації (набір датчиків, виконавчих механізмів, функцій/задач). Традиційний підхід до автоматизації йде через взаємопов’язані в контури функції:

«датчики -> входи регулятора (контролера) -> функції -> виходи регулятора (контролера) -> виконавчі механізми»

У противагу класичному «контурному» підходу, багато програмістів АСКТП вже давно застосовують об’єктно-орієнтовані підходи, у якому взаємопов’язані функції стають частиною якогось об’єкту, що описується та реалізовується як єдине ціле. Стандарт IEC 61512 опирається на об’єктне представлення доступного устатковання а також технологічного процесу. Це стає зручним механізмом як для учасників життєвого циклу АСКТП, так і з позицій спеціалістів, що проводять інтегрування з верхніми рівнями керування. У цій частині посібника розглянемо використання моделей устатковання, без прив’язки до інших моделей, означених в стандарті. Коротко про призначення та зміст стандарту Ви можете прочитати в білій книзі, тут зупинимося більше на практичних аспектах.

1.1. Устатковання (Equipment)

Відповідно до стандарту, при проектуванні та розробці програмного забезпечення кожен об’єкт автоматизації розглядається як окрема сутність. У свою чергу усі об’єкти автоматизації на рівні АСКТП розділяються окремо на «технології» (як виробити продукт) і «устатковання» (на чому виробити продукт). Автоматизація «побудови технології» стосується тільки виробництв зі змінною рецептурою (для цього власне і створений стандарт), практичні рекомендації щодо неї наведені в наступних розділах. На відміну від технологічної частини, автоматизація устатковання (equipment) стосується усіх типів виробництв, навіть якщо використовуються виключно неперервні процеси з однаковою технологією.

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

орган керування (безпосередньо клапан або заслінка);
виконавчий механізм з одним керуючим пневматичним сигналом «ВІДКРИТИ»;
два датчика кінцевого положення «ВІДКРИТИЙ», «ЗАКРИТИЙ»;

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

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

Рис. 1. Зображення клапан на схемі автоматизації

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

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

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

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

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

Для багатьох інженерів АСКТП використання об’єктного підходу стало типовою практикою. Тим не менше, її застосовують не всі. Крім того, часто зустрічається частково-об’єктний підхід, що пов’язано з погано проробленою методологією створення ПЗ. Стандарт IEC 61512 дає певні правила виділення та оперування таким об’єктами-устаткованнями, хоч не обмежує в цьому, зокрема:

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

Отже, окрім набору функцій та відповідних їм змінних в програмі контролера чи SCADA/HMI, передбачається наявність окремих сутностей (об’єктів) – устатковання (equipment), яке включає в себе інші об’єкти (дрібніші частини устатковання) та функції. Надалі під словом «устатковання» будуть розумітися спеціалізовані об’єкти в системі керування, які є двійниками їх фізичних сутностей. Функції устатковання надалі будемо називати функціональними елементами.

Взаємодія з устаткованням проводиться через його змінні стану та команди.

1.2. Стани (States)

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

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

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

операційна функція (функція керування/контролю позицією клапану): ВІДКРИТИЙ, ЗАКРИТИЙ, ВІДКРИВАЄТЬСЯ, ЗАКРИВАЄТЬСЯ, НЕ ВИЗНАЧЕНИЙ (наприклад одночасне спрацювання обох кінцевиків) та ін.;
функція тривожної сигналізації: НЕМАЄ ТРИВОГ, НЕ ВІДКРИВСЯ, НЕ ЗАКРИВСЯ, ДОВІЛЬНИЙ ЗСУВ та ін; у свою чергу кожна з цих тривог також описується певним станом: НЕ АКТИВНА, АКТИВНА НЕ ПІДТВЕРДЖЕНА, АКТИВНА ПІДТВЕРДЖЕНА та ін; тому загальний стан наявності тривог клапана є певною згорткою;
режим функціонування: АВТОМАТИЧНИЙ (алгоритми системи керування), РУЧНИЙ (дії оператора), МІСЦЕВИЙ (керування за допомогою перемикачів по місцю), БЛОКОВАНИЙ (функції керування не активні);
функція імітації роботи (наприклад, з метою налагодження): РЕАЛЬНИЙ(зчитує значення з входів та записує виходи) та ІМІТОВАНИЙ (значення датчиків генеруються алгоритмом імітації, значення виходів не записуються);
функція обслуговування: НА РЕМОНТІ, ФУНКЦІОНУЄ; останній час обслуговування; кількість переключень;

Перелік функціональних елементів та їх станів варіюється від вимог до контролю та керування устаткованням і не обмежуються стандартом. Оскільки устатковання можуть бути складеними, то станів може бути набагато більше, оскільки воно включає в себе кілька об’єктів. Наприклад, для устатковання типу «насос з перетворювачем частоти» стан представляється узагальнюючим набором станів функціональних елементів 2-х об’єктів: двигуна та перетворювача частоти. Крім того, з точки зору функції операційної діяльності розглядаються не лише дискретні набори станів (ВКЛЮЧЕНИЙ, ВІДКЛЮЧЕНИЙ) а й додаються аналогові значення плинної частоти (швидкості), струму, напруги, тощо. У той же час на основі аналогових значень можуть формуватися набори дискретних станів функцій, такі як «працює на мінімальній частоті» або «на максимальній».

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

бітові статуси = дискретні стани або їх комбінація

Сукупність цих станів функціональних об’єктів є об’єднання (конкатенація) цих статусів. У цьому випадку всі стани функціональних об’єктів можна об’єднати в певний упорядкований набір бітів для всього устатковання – статусне слово (status word).

статусне слово = набір бітових статусів функцій елементів устатковання

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

Наприклад, для клапану статусне слово може мати вигляд як в таблиці 1. Біти стану можуть взаємно виключати один одного, наприклад «ВІДКРИТИЙ» і «ЗАКРИТИЙ», а їх рівність 0 – представляти інший стан. Наприклад, якщо біти 5-8 дорівнюють нулю – це вказує на стан «НЕ ВИЗНАЧЕНИЙ».

Таб.1. Приклад статусного слова для 2-х позиційного клапану.

Біт	Опис
0 ALMOPN	=1 тривога НЕ ВІДКРИВСЯ
1 ALMCLS	=1 тривога НЕ ЗАКРИВСЯ
2 BLCK	=1 БЛОКОВАНИЙ
3 ALMSHFT	=1 тривога ДОВІЛЬНИЙ ЗСУВ
4 ALMSNSR	=1 тривога ПОМИЛКА ДАТЧИКА
5 OPNING	=1 ВІДКРИВАЄТЬСЯ
6 CLSING	=1 ЗАКРИВАЄТЬСЯ
7 OPNED	=1 ВІДКРИТИЙ
8 CLSED	=1 ЗАКРИТИЙ
9 DISP	=1 РУЧНИЙ режим (з ПК/ОП), =0 – АВТОМАТИЧНИЙ
10 MANBX	=1 МІСЦЕВИЙ режим
11 ALM	=1 загальна тривога
13 FRC	=1 хоча би одна зі змінних в об’єкті форсована
14 SML	=1 режим імітації

1.3. Автомати станів (State Machines)

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

якщо клапан в стані «ЗАКРИТИЙ» і прийшла команда «ВІДКРИТИ», перейти в стан «ВІДКРИВАЄТЬСЯ»

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

якщо клапан в стані «ВІДКРИВАЄТЬСЯ» і не спрацював датчик кінцевого положення і час відкриття більше максимального, то перейти в стан «НЕ ВІДКРИВСЯ»

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

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

Автомати станів не є новаторством стандарту IEC 61512. Це класичний механізм формалізації та моделювання, який використовується у багатьох галузях, у тому числі в автоматизації. Наприклад, на рис.2 показана діаграма класичного автомату станів для тривог, що описаний в стандарті IEC 62682 з певними спрощеннями. Стани тривоги представлені на рисунку колами з підписами, в яких наводиться опис, що включає комбінацію статусів: статусу тривоги та статусу підтвердження. У даному випадку, стан тривоги – це узагальнюючий показник, який залежить від плинного значення статусів та від попереднього стану. Стрілки на Рис. 2 відповідають переходам між станами з вказаними умовами цих переходів.

Не дивлячись на те, що станів тривоги всього чотири, діаграма виглядає досить просто. Але стандарт IEC 62682 передбачає ще три можливих стани блокування, в які можна перейти з будь якого іншого стану. Діаграма показана на рис.3., але усі переходи показати там не вдасться.

Рис. 3. Повний автомат станів тривог згідно IEC 62682

Розглянемо діаграму станів для операційної функції для клапану. У найпростішому випадку клапан має два стани – «ВІДКРИТИЙ» та «ЗАКРИТИЙ». У залежності від наявності датчиків кінцевого положення, клапан може описуватися автоматами станів, що показані на рис.4. На перший погляд, кожен з цих варіантів є самодостатнім. Однак кожен з них має ряд вад.

Рис. 4. Приклади найпростіших варіантів автомату станів для клапану

У варіанті з двома кінцевиками при виникненні несправності одного з них, жоден з них не буде дорівнювати одиниці, або спрацюють обидва. Це автоматом не передбачено. Аналогічна ситуація може відбуватися і з другим варіантом, коли датчик кінцевого положення буде несправним. Третій варіант взагалі немає контролю стану, тому в цьому випадку для алгоритмів керування можливо треба врахувати час переміщення, для уникнення, наприклад, гідроударів. Будь який з цих варіантів не передбачає формування тривог на базі станів, так як автомату станів тривог ні на що орієнтуватися. Очевидно в наведених вище станах з датчиками кінцевого положення необхідно передбачити в якості умов переходу команд керування. Під останніми розуміється команди на об’єкт-устатковання, а не на його апаратну частину (тобто виконавчий механізм). Також, для спрощення побудови автомату станів тривожної сигналізації варто ввести додаткові перехідні стани «ВІДКРИВАЄТЬСЯ» та «ЗАКРИВАЄТЬСЯ». Крім того, варто ввести стан «НЕ ВИЗНАЧЕНО», якщо конкретну позицію неможливо ідентифікувати. З цього стану можна стартувати автомат при ініціалізації програми керування, або переходити туди при поломці датчиків положення (обидва в одиниці). У такому випадку, діаграма станів операційного функціонального елементу матиме вигляд як на рис.5.

Рис. 5. Приклад розширеного автомату станів для операційного функціонального елементу клапану

У кожному з наведених станів можна робити певні керуючі дії. Наприклад в стані «ВІДКРИВАЄТЬСЯ» вмикати дискретний вихід контролера, що керує клапаном. Крім того, можна вмикати таймер, який буде вказувати на час активності стану, що можна буде використати для керування тривогами. Використовуючи діаграму операційного функціонального елементу клапану можна описувати алгоритм керування, який в свою чергу може спиратися на інші автомати станів. Інші функціональні елементи цього ж клапану можуть використовувати цей автомат для формування логіки своїх автоматів. Для прикладу розглянемо автомати станів для одного з функціональних елементів тривожної сигналізації «НЕ ЗАКРИВСЯ». Для спрощення ми будемо розглядати тільки статус активності тривоги, тобто без урахування статусу підтвердження і блокування (див.рис.6). Тривога виникає тоді, коли клапан знаходиться в операційному стані «ЗАКРИВАЄТЬСЯ» і час цього стану більше максимально дозволеного.

Рис. 6. Спрощений вигляд автомату станів для тривоги «НЕ ЗАКРИВСЯ»

Як видно, автомати станів функціональних елементів тривожної сигналізації тісно пов’язані з операційними. Тому в ряді випадків автомати станів різних функціональних елементів показують зв’язаними на одній діаграмі. Однак слід розуміти, що якщо два автомати станів з рис.5 та з рис.4 поєднати в одну діаграму, то в один момент часу будуть активні два стани, наприклад «ЗАКРИВАЄТЬСЯ» та «НЕ ЗАКРИВСЯ», що з графічного зображення може бути неочевидним. Тим не менше, в ряді випадків кілька автоматів станів можна звести в один, як це показано нижче на прикладі перетворювача частоти. У будь якому випадку програмна реалізація може базуватися на станах операційного функціонування, в яких будуть реалізовані керування станами інших функціональних елементів.

Для прикладу з клапаном, устатковання описуватися кількома взаємозалежними автоматами станів:

операційний;
4 автомати для тривог (НЕ ВІДКРИВСЯ, НЕ ЗАКРИВСЯ, ДОВІЛЬНИЙ ЗСУВ, ПОМИЛКА ДАТЧИКА);
блокування;
режимів роботи;
імітування

1.4. Режими (Modes)

Набір функціональних елементів і їх станів не означується стандартом. Тим не менше, подібні до описаних вище операційних функцій відносяться до так званого базового керування (basic control), опис якого дається в наступних розділах. Крім того, у стандарті окремо виділяються функції керування режимами (mode) устатковання. Режим вказує на те, у який спосіб відбувається керування операційними функціями. Зрештою, «режими» це окремо виділені стани, які впливають на особливість виконання (алгоритмів) функцій устатковання, а інколи – і на їх автомати станів.

Для устатковання стандарт рекомендує використовувати два режими: РУЧНИЙ та АВТОМАТИЧНИЙ. У РУЧНОМУ режимі, операційний стан устатковання означується командами з HMI, у АВТОМАТИЧНОМУ – з алгоритму керування. На практиці режимів може бути більше. Наприклад, для згаданого вище клапану, на Рис. 7. показана діаграма з додатковими режимами «РУЧНИЙ ПО МІСЦЮ» і «ЗАБЛОКОВАНИЙ». У «РУЧНОМУ ПО МІСЦЮ» режимі, клапан керується байпасним щитком, що знаходиться біля клапану. У «ЗАБЛОКОВАНОМУ» режимі на клапан завжди подається команда «ЗАКРИТИ».

Рис. 7. Автомат станів переключення режимів устатковання типу клапана

У даному випадку на автомат станів, що наведений на рис.5, будуть подаватися команди керування з різних джерел. Але, у ряді випадків автомати станів деяких функцій можуть змінюватися в залежності від режиму устатковання. Наприклад, діаграма на рис.5 не передбачає контроль команди ВІДКРИТИ та ЗАКРИТИ у режимі «РУЧНИЙ ПО МІСЦЮ», так як ці команди не можуть бути простежені системою. Тому, для цього режиму варто продумати інший автомат.

Вище наведені приклади станів, які є взаємно-виключеними. Наприклад, стани ВІДКРИВАЄТЬСЯ і ЗАКРИВАЄТЬСЯ з рис.5 ніколи не можуть бути активними одночасно. Для прикладу з 4-ма режимами, все не так однозначно, оскільки наприклад режим РУЧНИЙ(з HMI) і РУЧНИЙ ПО МІСЦЮ (з байпасу) можуть виникнути одночасно. Необхідно чітко розставити пріоритети при керуванню станами в програмі. У цьому випадку, «РУЧНИЙ ПО МІСЦЮ» має пріоритет, оскільки команди з контролеру, нівелюються.

1.5. Умови переходів та команди

Як зазначалось вище, автомати станів описуються станами та переходами, для яких задаються умови. Умовами переходу можуть бути як команди алгоритму керування (або HMI), так і вияв системою керування зміни стану устатковання, як правило за допомогою датчиків. Наприклад, на рис.5 перехід з ВІДКРИТО в ЗАКРИВАЄТЬСЯ відбувається по команді ЗАКРИТИ з системи керування, а з ЗАКРИВАЄТЬСЯ у ЗАКРИТО по стану датчика кінцевого положення. Слід звернути увагу, що датчик кінцевого положення, який є елементом клапану, теж є устаткованням, яке має свої стани. Він може мати стан ВІДМОВА, який може впливати на стани (або навіть режими) устатковання вищого рівня, тобто клапану.

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

Керовані умови переходу формуються командами. Можна виділити кілька джерел команд: з алгоритму керування, засобів HMI, системи верхнього рівня і т.п. У деяких випадках вони можуть відпрацьовуватися за різними алгоритмами, тоді діаграма станів має це відображати. Команди можуть бути реалізовані як бітові (ВІДКРИТИ, ЗАКРИТИ) або у вигляді числового слова команди (command word), де конкретна команда задається числом. Враховуючи, що за один раз устаткованню передається одна команда, як правило достатньо одного слова (числової змінної) для передачі всіх можливих команд керування. Обробник команд може не реагувати на ті команди, які недоступні в даному стані або режимі.

1.6. Приклад автомату станів в перетворювачах частоти

Описаний вище підхід на базі автомату станів використовується для керування перетворювачами частоти (ПЧ) для різноманітних профілів, в тому числі, які стандартизовані в IEC 61800-7 (ProfiDRIVE, CiA 402, SERCOS, CIP Motion).

На Рис. 8. представлений приклад автомату станів керування перетворювачем частоти ALTIVAR (Schneider Electric) по профілю CiA 402. У кожному стані ПЧ доступні певні функції, керування обертами доступні тільки в стані «Operational enabled». Внутрішня логіка оперується на стани та умови переходу. По мережі передається слово статусу (ETA), яке показує значення стану. По суті воно є комбінацією статусних бітів, але для простоти їх показують в 16-ковому форматі як єдине значення. CMD – це командне слово, яке переводить автомат з одного стану в інший. Ці два слова, разом з заданою і плинною частотою циркулюють по мережі при обміні з контролером, що керує ПЧ. Таким чином, алгоритм керування даним устаткованням повинен спостерігати за його станом і керувати ним, передаючи конкретну команду. Слід зауважити, що на рис.8 не показані усі внутрішні умови переходу між станами, це винесено на внутрішню реалізацію в ПЧ. Також зверніть увагу, що стани операційного функціонального елементу та контролю помилок показані в контексті однієї діаграми. Детальніше про керування перетворювачами частоти по мережі Ви можете почитати за цим посиланням.

Рис. 8. Автомат станів керування перетворювачем частоти ALTIVAR по профілю CiA 402.

З наведених вище прикладів можна зробити наступні висновки:

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

1.7. Стано-орієнтоване керування в ПЛК

Для керування функціями устатковання в програмах ПЛК зручно використовувати механізм стано-орієнтованого програмування. Воно передбачає структуру типу CASE, в якій для кожного значення стану прописується алгоритм роботи та вказуються умови переходу. Структура програми на базі CASE добре читається сумісно з діаграмою станів, яку вона реалізовує. На рис.9 показаний приклад реалізації автомату станів з використанням структури CASE на мові ST. Аналогічну структуру можна побудувати на комбінації IF…THEN…ELSE, або з використанням компараторів в мовах LD, FBD чи CFC. Для автомату станів функції керування соленоїдним виконавчим механізмом використовується змінна кроку (STEP1) та бітові команди, які вище в програмі визначаються зі слова команди. У залежності від значення кроку виконуються команди керування та перевіряються умови переходу.

Рис. 9. Програмна реалізація операційного автомата станів клапана.

Для ПЛК існує окрема графічна мова SFC, яка представляє діаграму станів. Ця мова дуже зручна з точки зору реалізації автоматів станів, але може мати ряд недоліків, пов’язаних з ресурсами та способом реалізації в конкретній платформі.

1.8. Правила декомпозиції та ієрархія устатковання

У стандартах IEC 61512 та IEC 62264 все устатковання (Equipment) на підприємстві займає певний рівень в ієрархії в залежності від того, яку роль воно відіграє в ланцюжку виробництва і навіть в бізнес-процесах підприємства. При проектуванні систем керування з використанням описаних підходів, необхідно зробити декомпозицію устатковання відповідно до його рольового призначення. Це значить, що все наявне виробниче (і не тільки) устатковання необхідно об’єднати а інколи розділити в окремі сутності, що будуть виконувати певну роль, описуватися своїм набором автоматів станів. У залежності від типу виробництва (неперервне, порційне, дискретне) принципи виділення устатковання будуть відрізнятися. У будь якому випадку, на стадії проектування правила декомпозиції устатковання повинні бути означені максимально детально, так як недостатньо продумані правила можуть ускладнити розробку і експлуатацію в майбутньому.

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

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

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

Рис. 10. Ієрархія устатковання на рівні клапана

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

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

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

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

враховувати стан об’єкта нижчого рівня (норма/тривога/достовірність) та діагностичну інформацію при керуванні логікою виконання; наприклад, якщо датчик кінцевого положення в стані НЕДОСТОВІРНІСТЬ (відмова модуля входів/виходів), клапан переходить в режим ЗАБЛОКОВАНИЙ;
проводити імітацію роботи підлеглих датчиків, шляхом оперування їх станами за імітаційним алгоритмом (наприклад для тестування або навчання персоналу);
керувати станом НЕДОСТОВІРНОСТІ підлеглих датчиків за алгоритмом, наприклад коли обидва датчика показують спрацювання.

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

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

Прикладом поширення станів можуть бути аварійні стани, які з нижчого рівня поширюються по ієрархії вгору. Це значить, що усі тривоги відслідковуються на вищому рівні ієрархії устатковання (для кожної категорії відповідно до IEC 62682). В IEC 61512 та IEC 62264 рольова ієрархія устатковання має вигляд як на Рис.11. Відповідно до цієї ієрархії кожне устатковання виконує певну роль у процесі виготовлення продукції. При інтегруванні верхніх рівнів з системами АСКТП, керування та контроль відбувається через стани та команди устатковання. Які правила виділення устатковання на кожному з рівнів обговорюються в інших розділах посібника.

Рис. 11. Рольова ієрархія устатковання підприємства

1.9. Використання спільних ресурсів

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

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

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

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

Описаний вище спосіб надання був використаний на ряді об’єктів, де ми розробляли прикладне ПЗ для АСКТП. Зокрема на станції водопідготовки необхідно було, щоб один і той самий клапан мав керуватися двома незалежними об’єктами вищого рівня: СІР-мийкою та фільтром. Те устатковання, яке раніше отримувало доступ до ресурсу, перше резервувало цей клапан для своєї роботи, інше в цей час не мало до нього доступу для керування.

У стандарті IEC 61512 механізми вирішення пріоритетності надання описуються як задачі надання та арбітражу.

1.10. Рекомендації щодо реалізації

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

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

При першому погляді на ієрархію устатковання та фізичну його реалізацію у вигляді вкладеності, виникає бажання робити відповідну вкладеність функцій (або функціональних блоків). Але наш практичний досвід показує, що це не дуже вдале рішення. Бажано викликати програми обробки логіки роботи устатковання паралельно. Підпорядкування відповідно до ієрархії відбувається шляхом обміну станами та командами. Це не є вкладеністю, а координацією роботи відповідно до ролей. Подібні підходи були неодноразово випробувані на власному програмному каркасі [8]. Кожне устатковання реалізоване як окрема функція, в яку при виклику передаються дані реального часу (стани та команди) та конфігураційні.

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

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

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

Програмна реалізація таких об’єктів передбачає:

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

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

Читати далі > 1.1. Модулі керування

Приклади використання ієрархії устатковання IEC-61512/IEC-62264 в засобах SCADA/HMI

Олександр Пупена, ТК-185

Місце SCADA/HMI в інтегрованій системі керування

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

Як видно з рис.1, у сучасних системах керування підприємством рівень SCADA/HMI не є найвищим. Для ефективного керування всією виробничою діяльністю використовують системи керування виробництвом (АСК В) які прийнято називати MOM (Manufacturing Operations Management). До задач MOM входять функції керування різними виробничими операціями, зокрема (не повний перелік):

Рис. 1. Типова технічна структура інтегрованої системи керування підприємством

керування операціями основного виробництва (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, але вони стосуються тільки порційного типу виробництва, хоч можуть бути так саме прийняті і до інших типів виробництв.

Рис 2. Функціональна ієрархія виробничого підприємства

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

Рис 3. рольова ієрархія устатковання підприємства

Модуль керування (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).

Рис 4. Зв’язок устатковання з тегами вводу/виводу

Після створення екземпляра устатковання, його можна вказати в налаштуваннях тегів, трендових тегів та тегів тривог. Наприклад тег з назвою LOOP_1_PV слугує елементом ProcessVariable в устаткуванні Loops.Level (див.рис.4). Тепер до тегу у будь якому місці проекту можна звертатися двома способами:

через ім’я тегу “LOOP_1_PV”
або через елемент устатковання “Loops.Level.ProcessVariable”

Слід відмітити, що після встановлення середовище розробки Citect, за замовчуванням редактор графіки відображає вікно вибору тегу саме за іменем устатковання а не імені тегу. Це можна змінити в налаштуваннях параметрів Citect Studio.

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

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

Рис 5. Використання устатковання у якості фільтра в середовищі виконання

Використання устатковання в якості фільтру значно спрощує вибір необхідних тривог, тегів в списку або трендів. У першому випадку, оператор робить аналіз тільки тих тривог та подій з журналу, що стосується конкретної частини процесу. При цьому він робить це звичайним вибором в навігаторі. Те саме стосується відображення трендів. Зрештою, можна зробити окремі вікна, що динамічно прив’язуються до конкретного устатковання і надають усю необхідну інформацію саме по ньому. Для цього в 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. Налаштування правил створення тегів, асоційований з елементом

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

Аналогічним чином можна означувати акумулятори. Через вкладку типу States (рос.лок.«Состояния») означуються стани (див.рис.6).

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

Використання ієрархії устатковання в SCADA zenon

У SCADA zenon ієрархія устатковання створюється у відповідному розділі проекту «Equipment Modeling» (див.рис.8). Ім’я групи устатковання (Equipment group) може бути вказано в якості додаткового параметру для більшості елементів проекту, у тому числі:

змінних (Variables) та типів змінних
екранів (Screens) та шаблонів (frames)
функцій та скриптів
стандартних рецептів та груп рецептів
часових функцій
моделей планувальника
пунктів меню
користувачів
матриць реакцій
переприсвоєнь (Allocation)
класів, груп та дільниць тривог

Один елемент може одночасно назначений кільком групам устатковання. Назначивши елемент устаткованню, воно може бути використано в якості фільтра в середовищі виконання. Фільтр налаштовується шляхом вибору груп устатковання, до якого має входити елемент щоб відображатися в таблиці. Крім того в ієрархії устатковання можна отримати інформацію про прив’язані до нього елементи через пункт «Linked elements» контекстного меню.

Рис 8. Створення ієрархічної моделі устатковання та використання в змінній

У середовищі виконання устатковання може бути використано в якості фільтрів та додаткових параметрів в функціях. Наприклад, в аргументах функцій виклику екранів AML, CEL, Recipegroup Manager, або керування змінами (Shift management) в якості фільтру можна вказати групу устатковання. При цьому можна вказати чи необхідно відображати елементи тільки вибраного рівня, чи також усіх підлеглих (опція «Hierarchic filter»). Ієрархію устатковання також можна використовувати в означенні тривог.

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

Рис 9. Налаштування аргументів функції «Screen switch» для відкриття екрану моделі устатковання та вигляд екрану в режимі виконання

Висновки.

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

Впровадження PackML: Інтерв’ю з Ярославом Люлько

Ми поспілкувалися з Ярославом Люлько, інженером з автоматизованих систем керування в ТОВ «Сілоджік Груп», щодо досвіду впровадження спорідненої до стандарту IEC 61512 специфікації PackML.З цього інтерв’ю Ви можете дізнатися, що саме стало передумовою використання специфікації, які переваги це дає, і як це вплинуло на подальші проекти.

Ви розповідали, що мали досвід впровадження PackML, на якому підприємстві це було і які основні завдання стояли? Вперше з PackML я зустрівся на підприємстві Mondelez, де наша організація проводила роботи по впровадженню системи контролю та оптимізації існуючої виробничої лінії. Передумовою для цих робіт стала презентація компанією Siemens концепції OPL (Optimized Packaging Line). Ця концепція поєднує кращі практики, які перевірені багаторічним досвідом компанії Siemens у найширшому спектрі галузевих рішень, з різноманітними ноу-хау, що застосовуються для задач пакування. Метою OPL є пришвидшення виходу на ринок рішень з автоматизації задач пакування та суміжних до них, а також оптимізація вже діючих рішень за рахунок моніторингу та аналізу їх роботи. Саме це (моніторинг та аналіз) і було основним завданням, яке повинна була вирішувати на даному підприємстві модернізована нами система.

З точки зору розробника концепція OPL – це перш за все:

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

У коді, що генерується конфігуратором для окремого Unit`а, важливим елементом для проекту ПЗ Step 7 є лише один блок даних (Data Block «PackTags»). Пізніше дізнався, що це у незначній мірі модифікований набір PackTag`ів із стандарту PackML. Усі PackTag`и розділені на три групи:

Command, Status – використовуються для координації роботи між Unit`ом та лінією;
Admin – містить дані для систем вищого рівня, що дозволяють аналізувати різні показники ефективності (KPI).

У цьому проекті необхідно було підготувати дані саме для груп Status та Admin, які стосувалися кожного Unit`а на лінії. На основі них в подальшому можна буде проводити моніторинг та аналіз.

Познайомившись зі стандартом PackML (а точніше технічним звітом ISA–TR88.00.02) я дізнався про ISA-88 (аналог IEC 61512, прим. редактора), який був взятий за основу його створення. Цей приклад добре демонструє яким чином ISA-88 може бути використано для задач автоматизації інших типів виробництв, зокрема пакувальних машин.

Яке устатковання було на лінії? Це були рецептурні станції, дозувальні станції, CIP-станції, пакувальні машини, печі, охолоджуючі тунелі, темперувальні машини і ін. Слід відмітити, що інформація, яка зібрана у PackTag`ах охоплює весь набір даних, необхідних для моніторингу та аналізу роботи практично будь-якого типу Unit`а.

Замовнику потрібно було тільки спостереження? Так, тільки спостереження та аналіз для виявлення вузьких місць. Конкретно для цього проекту НЕ знадобилася значна частина функціоналу ISA-88, зокрема: рецепти та звіти; сегментація (модульність) процесу; автомат станів; exclusive-use resources та shared-use resources, allocation і інше. Усі ці функції були б більш доречні при розробці нових виробничих ліній чи окремих технологічних вузлів. Але, тим не менше, час від часу з’являються різні запити модернізації на окремих технологічних вузлах, де знання 88-го дуже допомагають.

Які переваги від впровадження отримав замовник? Насправді проект ще не реалізовано у повній мірі, і говорити про якісь серйозні переваги ще рано, оскільки наразі відсутня підсистема аналізу показників. Поки що організовано мережеву інфраструктуру, до якої підключені Unit’и десяти виробничих ліній. Також встановлено сервер, куди від кожного Unit’а передаються теги груп Status та Admin, які включають інформацію про:

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

Наразі Unit`и приведено до стандарту PackML, вони мають всі необхідні дані для розрахунку OEE та інших KPI, необхідно лише обрати та розгорнути систему збору та аналізу даних.

Тобто KPI зав’язані на станах, означених в PackML? Якщо взяти складові OEE Availability та Performance – то так, на одному із станів.

Availability = Operating Time / Planned Production Time

Performance = Total Pieces / (Operating Time* Ideal Run Rate)

Якщо підсумувати кількість часу, коли Unit знаходився у стані Execute (це стан у якому Unit безпосередньо випускає продукцію) – то це і буде Operating Time.

Третя складова OEE – це Quality = Good Pieces / Total Pieces. Звісно, щоб отримати значення всіх складових не достатньо лише Operating Time, необхідні також значення Total Pieces, Ideal Run Rate, Good Pieces. Всі вони передбачені у PackTags. Не вистачає лише значення Planned Production Time, яке має надаватись системою збору та аналізу даних, цього наразі не має у проекті

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

Чи можна було для розрахунку KPI обійтись без означення станів? Звичайно можна, але треба добре розуміти код програми, щоб чітко визначити стан, при якому можемо підсумовувати Operating Time. А ідентифікувати цей стан у чужій програмі зазвичай не просто. Якщо ще взяти до уваги, що це можуть бути програмні засоби від різних постачальників, то додатково треба знати (орієнтуватись) у їхніх платформах розробки, та і, зрештою, мати їх (нерідко ще і різні версії). Тому начебто така проста задача, як пошук тегу, що вказує на роботу головного приводу, може забрати занадто багато часу, що неодноразово перевірив на власному досвіді. У разі, коли програму розроблено згідно стандарту, і існує PackTags, – достатньо лише знати адресу потрібного тегу.

У нас в ТК185 є група по ISO 22400 (виробничі KPI), їм би було цікаво чи за стандартною формулою розраховувалося OEE (https://www.oee.com ), чи використовувалася інша формула? Наче за стандартною.

Які переваги використання PackML ви побачили з точки зору розробника програмного забезпечення? По-перше – це термінологія, коли різні розробники розуміють певні поняття однаково. По-друге – це певний ієрархічний порядок проекту, коли швидко орієнтуєшся у чужому коді. По-третє – модульність, коли розробка програми базується на комбінації певних модулів (шматків коду, блоків). По-четверте – підхід до проекту з думкою про те, що він має бути готовим як до горизонтальної (мається на увазі в межах цеху, прим. редактора) так і до вертикальної інтеграції. По-п’яте, наявність моделі станів та PackTags, що за замовчуванням роблять за вас частину роботи. Звичайно, що це не “панацея”. Багато чого ми використовували і до знайомства зі стандартом. Але для чого вигадувати колесо, якщо його вже використовують?

Які нові наробки Ви перенесли у всі свої наступні проекти в якості частини фреймворка? Наразі для кожного нового проекту використовується шаблонний проект, у якому міститься базовий “скелет” програми, що є необхідним для практично будь-якого проекту. Код цього проекту взаємодіє з даними стандарту PackML як для читання так і для запису. Якщо повернутись до попереднього питання, то замовник зекономив би велику кількість часу та ресурсів, якби всі Unit`и на його виробничих лініях були розроблені згідно стандарту PackML.

Після PackML Ви познайомилися з ISA-88 (на ТДА16-2), що знайшли там схоже і що для себе відкрили? Схожою була модель станів. Відкрив для себе, що модель станів для EM з ISA-88 (модуль устатковання – рівень фізичної моделі між технологічним вузлом та модулем керування, прим. редактора) може бути такою самою як для Unit`а з PackML. Крім того, модель станів з PackML означена у стандарті строго, а та що дана у ISA-88 – показана в якості прикладу, тому може бути іншою при реалізації. Стандарт ISA-88 охоплює значно більше задач. На відміну від ISA-88, рецепти у PackML – це лише частина PackTag`ів куди передаються значення кількості та типу продукту, що має виготовлятись. Рецепти у нашому звичному розумінні, це лише формула у поняттях ISA-88. Для мене було новим, що у ISA-88 рецепти набагато ширше та глибше поняття. Означення звітів, exclusive-use resources або shared-use resources, allocation у PackML немає.

Чи була колись необхідність у Ваших проектах у використанні ISA-88 (IEC-61512)? У повній мірі – ні, але певні елементи 88-го – так. Дуже часто у проектах з наявними рецептурними станціями замовники просять зробити звіти для виведення кількості, часу та рецепту виготовлення продукції. Також для рецептурних станцій просять додати гнучкості у процедуру приготування. В основному продукція виготовляється за чітко написаною програмою контролера (послідовність операцій без варіантів). Коли вони хочуть проекспериментувати, наприклад, якусь операцію пропустити, повторити, то доводиться розбирати та правити практично весь код. У кількох проектах необхідно було реалізувати механізм використання спільного ресурсу.

Щось вдавалося реалізувати? По звітах є кілька реалізацій на SSRS (SQL Server Reporting Services – служби звітності від Microsoft, прим. редактора). Для кожного виготовленого чи навіть перерваного batch`у (партії, прим. редактору) створюється окремий запис з:

унікальним ID (поточні дата-час запуску на виконання);
датою та часом початку та завершення;
заданими та фактичними значеннями компонентів;
задіяними вузлами.

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

Чи бачили Ви впроваджені системи ISA-88 (IEC-61512)? На жаль, не бачив.

Як Ви думаєте, чи потрібно автоматнику знати основи стандарту ISA-88 (IEC-61512)? Поясніть чому. Обов’язково потрібно знати. У стандарті зібрані найкращі практики світових лідерів автоматизації, тому треба використовувати ці напрацювання. Як результат – проекти будуть більш структуровані, гнучкі та функціональні.

Як ви думаєте, чи потрібно виробничникам порційного виробництва знати основи стандарту ISA-88 (IEC-61512)? Поясніть чому. Так, основи їм знати потрібно. На мою думку, технологи мають добре оперувати такими поняттями як процедура, операція, етап. У програмах автоматчика, який не знайомий з ISA-88, зазвичай виконується базове керування без врахування процедурного. Саме у таких ситуаціях виробничник порційного виробництва з базовими знаннями ISA-88 зможе уникнути недоліків відсутності можливості процедурного управління програмою автоматчика. Він може краще сформулювати програмісту відповідну постановку задачі. Знання основ стандарту для виробничника – це “запобіжник” від некваліфікованої реалізації проекту.

Який стан згідно Ваших спостережень обізнаності в стандартах ISA-88 (IEC-61512) в Україні? Одиничні випадки.

Яка на Вашу думку причина такого стану? Як це можна покращити? Насправді, я думаю, що в тій чи іншій мірі стандарт вже використовується. Поясню.

У кінцевому рахунку різні інтегратори приходять до того, що необхідно мати у себе готову бібліотеку для технологічних об’єктів (насос, клапан, транспортер, датчик і т.п.), що є по суті Control Module з ISA-88. Якщо ж інтегратор займається впровадженням однотипних проектів, то 100% у нього має бути логічний функціонал, який вирішує основну задачу (чи кілька задач, коли проект біль складний). Наприклад, якщо взяти станцію водопідготовки, то там можна виділити певні логічні функції, що по суті є Equipment Module з ISA-88 – перекачування води насосними станціями, очищення води механічними фільтрами, станції дозування різних хімічних компонентів для знезараження води, зворотній осмос для очищення води на молекулярному рівні. І всі ці функції реалізовуються у програмі контролера з використанням крокових послідовностей (так просто зручніше), які теж існують у ISA-88. А згодом замовник замовляє розробку звітів, тому що хоче бачити наскільки ефективно працює Unit в порівнянні з минулим місяцем, кварталом, роком; скільки і якого ресурсу було використано – і знову приходимо до звітів ISA-88.

Ваша організація є партнером Siemens Україна. Чи багато знаєте Ви людей в Siemens, або їх партнерів, хто займається ISA-88 (IEC-61512) професійно? Таких людей не знаю. Чув від свого керівництва, що Siemens в Україні чомусь не підтримує simatic batch. У чому причина мені не відомо.

Які відомі Вам стандарти вважаєте за необхідне для впровадження в Україні? ISA-88, ISA-95 та ISO 22400-2:2014 – в комплексі, тому що тісно пов’язані між собою. Стандарт ISA-101 для покращення front-end. Також ISA-99 та IEC 61508.

Досвід використання стандарту IEC 61512 в проектах та в навчанні

Слід відмітити досить важливу річ, яку потрібно розуміти тим, хто має на меті впровадити систему керування порційним виробництвом згідно стандарту IEC 61512: стандартними засобами АСКТП (SCADA/HMI + контролер) без використання спеціалізованого пакету, або модулю SCADA-програми чи MES/MOM) це зробити дуже важко. Це розуміння повинно бути і у замовника, оскільки впровадження повноцінного функціоналу потребує додаткових затрат.

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

1. Власний досвід впровадження у проектах.

З 2017-го року ми (www.i4u.in.ua) почали впроваджувати елементи стандарту в свої проекти. Протягом цього періоду (з 2017-го по сьогодні) ми зробили з десяток проектів, де в тій чи іншій мірі використовувалися діяльності систем керування відповідно до вимог, означених в стандарті. На сьогоднішній день у нас є свій каркас (PAC Framework) що є власним стандартом для розробки ПЛК та SCADA/HMI, що базується на IEC 61512. Також у нас є бачення, як можна доповнити цей каркас для реалізації усіх функцій стандарту IEC 61512. Відмітимо також, що тільки кілька з цих об’єктів були частиною порційного виробництва, інші хоч і вміщували періодичні процеси, належали до неперервного або дискретного виробництва. Нижче наводяться результати впровадження елементів стандарту в проектах, у яких ми виступали у якості програмістів АСКТП.

Проектування програми керування. Використання стандарту впливає на всі стадії та етапи життєвого циклу. Ми мали відношення та вплив тільки на розробку прикладного ПЗ. Після отримання технічного завдання і схеми автоматизації ми обговорювали разом як найкраще виділити процедури та апаратурні об’єкти (устатковання + функції керування). Враховуючи, що проекти стосувалися тільки однієї технологічної комірки, а на рівні модулів керування правила були означені каркасом (PAC Framework), залишалося виділити тільки технологічні вузли (Unit) та модулі устатковання (Equipment Module). Задача була не тривіальною, мала ітераційний характер однак з досвідом ми навчилися це робити.

Означення процедур зводилося до визначення правильного набору найменших елементів – етапів. Усе що відносилося до опису технології, мало початок і закінчення в межах якогось набору устатковання і більше не могло ділитися на елементи з означеним автомату станів – ставало етапом. З процедурами технологічних вузлів було простіше, бо це означувалося наявністю таких вузлів. Коли етапів було багато, а в технологічному вузлі різні процедури повинні були задіюватися у різних рецептах, ми їх об’єднували в операції (наприклад мийка технологічного вузла). У стандарті процес виділення процедурних елементів і устатковання показана у пункті 6.1.3 «Інженерія (проектування та розробка) технології і систем керування» та графічно показана на рис.1.

рис.1. Вибір процедурних елементів і апаратурних об’єктів згідно стандарті

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

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

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

Згідно IEC-61512 для устатковання може (хоч і не обов’язково) використовуватися поширення режимів. Виявилося, що це досить зручний механізм з точки зору експлуатації, так як переведення технологічного вузла в один із режимів (ручний/автоматичний/блокування) приводило до відповідної зміни режиму усього підлеглого устатковання.

До ознайомлення зі стандартом один із програмістів нашої команди мав досвід розробки програми керування об’єктами, де один і той самий виконавчий механізм, або їх група використовувалися у алгоритмах різних програмних об’єктів. Необхідно було вирішити ряд питань: визначення того, кому належить даний об’єкт, як забезпечити обмеження одночасного доступу в програмі, а також одночасно з якою процедурою він повинен переходити в автоматичний та ручний режим. Рішення було знайдено, але його пошук і перевірка зайняли багато часу. У стандарті ця задача має стандартне вирішення через механізм надання (allocation) спільного ресурсу. Яким це чином робиться стандарт не описує, але сам підхід використання надання вже є великою частиною вирішення цієї задачі. Зрештою, керування та контроль зайнятості ресурсу може вирішуватися зміною та перевіркою звичайної властивості об’єкту, що ми неодноразово використовували у своїх проектах. У каркасі PAC Framework ми також використовуємо механізм Allocation. Технологічні змінні займають для себе спільний ресурс з ексклюзивним доступом – канал контролера. Це дає змогу «перекидати» канали, не змінюючи програму в ПЛК. Незалежно від об’єкта керування нижній рівень модулів керування (CM) включає в себе три під-рівні (рис.2).

У стандарті кожний апаратурний об’єкт відповідає за процедурне (технологічне) і базове керування, що є його частиною, а взаємодія між процедурами відноситься до координаційного керування. Це спрощує побудову розподіленої системи керування. На одному з об’єктів (система поливу теплиць) в системі керування було закладено більше десятка ПЛК, кожен з яких відповідав за певну функціональну частину установки. Представник замовника (інжинірингова компанія) пропонував зробити з усіх ПЛК крім одного – центрального, – розподілені засоби вводу/виводу. Враховуючи потенційну можливість надмірного об’єму необхідної пам’яті та часу циклу, а також можливі проблеми з живучістю, ми вирішили побудувати систему за іншим принципом – функціонально розподілену. Відверто кажучи, для нас це був перший досвід, де в межах однієї технологічної комірки будувалася розподілена система з такою кількістю зв’язаних між собою ПЛК. Однак, зробивши відображення (mapping) ієрархії устатковання відповідно до IEC-61512 на ці ПЛК, все стало логічним і зрозумілим. Така структура зробила з кожної ділянки самостійну підсистему, що схоже на підходи DCS та відповідає принципам розподіленості в кібер-фізичних системах Індустрії 4.0. Взаємодія між апаратурними об’єктами в ПЛК була реалізована через промислову мережу (команди, статуси, властивості Allocation). Автономність контролерів зробила можливим перевіряти кожен функціональний вузол окремо і надало живучості системи. Механізм Allocation дав змогу вирішити проблему одночасності доступу до того самого апаратурного об’єкту. Звісно, там були інші трудності, пов’язані з проблемами відлагодження взаємодії на рівні рецепту «на дому», оскільки потребувало наявності всіх ПЛК. Однак, це є ціною усіх розподілених систем керування на базі ПЛК.

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

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

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

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

У PAC Framework ми означили свій рушій (engine) для процедури, який забезпечує базову функціональність автомату станів, описану в IEC-61512. У свою чергу кожен стан вміщує кроки, змінну часу виконання кроку, змінну часу стану процедури а також налаштування уставок максимальних та мінімальних інтервалів виконання. По суті, усі необхідні базові налаштування були завжди під рукою, достатньо було їх використати у потрібному місці. З самого початку ми вагалися, чи закладати в процедури функціональність, яка початково не була затребуваною. Дуже скоро ми неодноразово переконалися в тому, що треба обов’язково
реалізовувати весь функціонал з самого спочатку .

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

Майстер-рецепти та керівні рецепти. Багато рецептурних виробництв не потребують зміни процедури, а тільки зміни параметрів, яка в термінах IEC-61512 зветься формулою. У цьому випадку класичним для систем АСКТП є використання рецептів, які є наборами записів з певною назвою, що за необхідності записуються у задані параметри процесу. Ми вирішили, що і для цього випадку використання двох типів рецептів — майстер-рецепту та керівного рецепту матиме переваги. Зокрема, можна змінити керівний рецепт під час його використання, не змінюючи прототип в «бібліотеці». За потребою можна замінити налаштування майстер-рецепту параметрами з керівного. Ми застосовували цей механізм на всіх об’єктах, які потребували рецепти, як зі зміною так і без зміни процедури.

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

рис.3. Фіксації параметрів керівних рецептів

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

У наших проектах практично не було необхідності означувати режими для процедурних елементів, бо не потребувалася ця функціоанальність. У той же час, означення станів для процедурного керування дала можливість реалізувати чіткі алгоритми поведінки, в залежності від ситуації. Отримавши в ТЗ опис алгоритму, який по суті не визначав і 50% усіх ситуацій, ми задавали питання технологам, «а що буде коли … ?». Зрештою, ми створювали таблиці з переліком станів процедурних елементів, дій, які необхідно робити в цих станах, і умови переходу в інші стани. Заповнивши такі таблиці ми отримували добре формалізований алгоритм, який можна було змінювати достатньо просто і на папері і в програмі.

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

Окрім визначених в стандарті для базового керування режимів «ручний» та «автоматичний», ми застосовуємо режими «імітоване»/«реальне», «форсування»/«без форсування». Для введення нових режимів необхідно було чітко означити правила їх пріоритетної дії на керування. Так, наприклад, форсування що забезпечує заміну значення вказаною величиною має найвищий пріоритет. Поки ми не зафіксували ці правила на папері, завжди була плутанина в їх використанні.

Для режимів і станів ми використовуємо правила поширення. Як і в багатьох випадках, стандарт тільки оговорює факт можливості поширення, але це вже спричинює необхідність означення цих правил. Так, наприклад, аварійні стани поширюються на апаратурні об’єкти вгору за ієрархією, а режим – вниз. Це значить, що усі тривоги відслідковуються на рівні всієї технологічної комірки (для кожної категорії відповідно до ISA-18.2) а зміна технологічного вузла в режим «ручний» приводить до переведення в ручний режим усіх підлеглих апаратурних об’єктів. У першому проекті, розробленому згідно IEC-61512 ми використовували стандартний автомат станів, який означений в 1-й частині стандарту. У цьому автоматі процедура переходить зі стану “Idle” в стан “Running”, і якщо процедура завершилася – в стан “Complete”. Враховуючи, що об’єкт мав складні алгоритми запуску і завершення нам не вистачало додаткових проміжних станів, які ми добавили в автомат (рис.4). До речі, ми були не першими, подібні модифікації зустрічаються у статтях, а також у версії ISA-88 2010-го року.

рис.4. Фрагмент зміненого автомату станів

Використання анімації стану при візуалізації (кольором або підсвічуванням) дало можливість значно підвищити ситуаційну обізнаність.

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

Під час впровадження перших проектів ми мали певний негативний досвід, який врахували в наступних проектах. Зокрема, перший проект містив повний набір операторських команд зі стандарту: START, STOP, PAUSE, RESTART, HOLD, RESUME, ABORT, RESET (рис.6). Оператори часто плуталися, наприклад натискали ABORT замість STOP. Окрім надмірної кількості команд, було ще кілька причин:

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

рис.6. Вікно керування процедурою: велика кількість кнопок плутає оператора

У наступних проектах ми об’єднали команди, що схожі за призначенням (START, RESTART, RESUME), ввели обмеження на доступ до особливої команди ABORT, прибрали команди HOLD та PAUSE в процедурах, де вони не були передбачені.

Звіти по виробництву партії, простежуваність. Однією із найбільших переваг впровадження стандарту – це спрощення реалізації формування архіву та звітів по виробництву партії, яка допомагає внутрішній простежуваності процесів виробництва. Стандарт вказує на те, які дані слід зберігати, яким чином організовувати логічне зв’язування записів. Четверта частина стандарту «Batch Control Part 4: Batch Production Records» детально описує необхідну структуру записів при потребі обміну записами між різними підсистемами. У своїх проектах у нас не було необхідності такого обміну, тому ми реалізовували архівування в зручному і достатньому для нас вигляді.

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

У одному з проектів архівування даних проводилося безпосередньо на ПЛК. Це може здатися дивним, але виявилося, що зберігати дані по партії в ПЛК зручніше ніж в SCADA/HMI. Інша справа – формування звітів за цими даними. У тому проекті файли за необхідності копіювалися на ПК, де аналізувалися в Excel з використанням скриптів VBA. Тоді це було найшвидшим рішенням, але зараз у нас є інше бачення рішення для такого типу задач. У іншому проекті усі дані окрім рецептурних писалися в SCADA класичними способами: тренди додатково включали номер кроку, журнали подій включали події змін станів процедурних елементів. У окрему таблицю БД додатково зберігався запис керівного рецепту. Це дало можливість достатньо просто реалізувати онлайн звіти, як показані на рис.7. Тренди виводилися за вказаний період з початку до кінця виготовлення партії.

Зробивши кілька проектів з використанням елементів стандарту означених в IEC-61512 ми зробили наступні висновки:

стандарт повинні знати усі спеціалісти з автоматизації технологічних процесів та виробництв, так як він вміщує методологічні засади побудови алгоритмічного та програмного забезпечення систем керування;
впровадження стандарту не обов’язково повинно бути повним, не всі виробництва цього потребують
ми виділили основні ключові моменти, які повинні стати базовими для всіх систем: відділення процедурного керування від базового, означення режимів і станів, означення чіткого автомату станів для процедурних елементів, означення ієрархії устатковання, наявність керівних рецептів та майстер-рецептів для рецептурного виробництва;
реалізація стандарту можлива без використання спеціалізованого ПЗ, хоча останнє може значно зменшити трудозатрати та збільшити функціональність;
реалізація стандарту можлива навіть з використанням ресурсів ПЛК «середньої канальності» (наприклад S7 1200, Modicon M241)
за умови використання керівних рецептів простежуваність процесів в межах технологічної комірки реалізовується досить просто стандартними засобами SCADA та PLC

2. Про досвід впровадження інших колег.

Нам, на жаль, особисто не відомі колеги, які впроваджували свої системи керування згідно стандарту IEC 61512. Враховуючи наші активні пошуки, ми можемо зробити два припущення: 1) таких людей в Україні мало і вони не є публічними, що, до речі, дуже характерно для автоматників; 2) таких людей в Україні немає, або вони працюють виключно за кордоном.

Ми чули певні відгуки автоматників, що обслуговували такі системи. Зокрема, вони виділяли зручність і багатофункціональність. Двічі нам зустрічалося наслідування чужих проектів, що базувалися на IEC 61512. Дотепним був той факт, що ці проекти протиставлялися стандарту IEC 61512. Тобто, на нашу фразу «Такі системи робляться за стандартом ISA-88 (IEC 61512)» відповідали приблизно так «То все теорія, а от подивіться як роблять практики!». Це черговий раз показує скептичне відношення спеціалістів з автоматизації до стандартів, при цьому наслідуючи готові чужі реалізації.

Тим не менше, один наш колега по цеху, Ярослав Люлько із ТОВ Сілоджик Груп, мав досвід впровадження хоч і не самого IEC 61512, то хоч специфікації PackML (вірніше концепції OPL що на ній основана), яка у свою чергу базується на ISA-TR88.00.02 Machine and Unit States: An Implementation Example of ISA-88 (2008). Ми взяли в нього інтерв’ю, яке повністю можна прочитати за посиланням . Також про технічні деталі впровадження Ви можете подивитися на відео запису з його виступу на ТДА16-2 . Нижче коротко наведемо основний зміст інтерв’ю.

Основне призначення впровадження системи керування згідно концепції OPL на вказаному підприємстві – було контроль роботи лінії на предмет виявлення вузьких місць. Лінія включала різне устатковання: рецептурні станції, дозувальні станції, CIP-станції, пакувальні машини, печі, охолоджуючі тунелі і ін. Використання PackML зрештою потрібне було для розрахунку виробничих KPI, зокрема OEE. Для цього для технологічного устатковання було забезпечено передачу:

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

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

Ярослав виділяє наступні переваги використання PackML:

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

Ярослав використовує певний «скелет» для своїх проектів ПЛК. Код цього проекту взаємодіє з даними стандарту PackML заповнюючи їх, або ж, у разі необхідності, до звертаючись до них (деталі за посиланням ).

Ярослав має великий практичний досвід впровадження різних систем керування, тому ми спитали його і щодо потреб стандарту IEC 61512, тобто функцій, що не входять в PackML. Серед найбільш затребуваних функцій він виділив Batch-звіти для внутрішньої простежуваності процесів виготовлення партії. «Також для рецептурних станцій просять додати гнучкості у процедуру приготування. В основному продукція виготовляється за чітко написаною програмою контролера (послідовність операцій без варіантів). Коли вони хочуть проекспериментувати, наприклад, якусь операцію пропустити, повторити, то доводиться розбирати та правити практично весь код.»

Ярослав вважає, що автоматнику обов’язково потрібно знати основи стандарту ISA-88 (IEC-61512). «У стандарті зібрані найкращі практики світових лідерів автоматизації, тому треба використовувати ці напрацювання. Як результат – проекти будуть більш структуровані, гнучкі та функціональні».

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

3. Використання в навчальному процесі.

Ми усвідомлюємо той факт, що стандарт не може впроваджуватися в Україні автоматниками без підготовки та перепідготовки спеціалістів. З 2016-го року на кафедрі АКТСУ Національного університету харчових технологій у навчальний процес був впроваджений курс по керуванню порційним виробництвом, матеріали якого доступні за посиланням. У 2017-му та 2018-их роках ми також проводили 2-дневні курси по підготовці спеціалістів по ISA-88 (IEC-61512), матеріали для яких доступні за цим посиланням. У цьому підрозділі ми поділимося досвідом проведення цих курсів, та думками щодо подальшого їх вдосконалення.

Звичайно, що проведення курсу для студентів-магістрантів та спеціалістів сильно відрізняється. Ми наразі не маємо зворотного зв’язку про використання ідей, викладених у курсі студентам магістрантам в реальних проектах. Протягом навчання студенти мали можливість прослухати теорію на лекціях і спробувати побудувати систему керування на практиці. Зрештою лабораторні роботи повинні були закінчитися готовою системою, як це показано на відео. Така форма, де теорія дається в один час а лабораторні в інший мабуть не є дуже вдалою. Це стосується не тільки викладання Batch Control, а і інших дисциплін. Найкращим способом, на нашу думку, є комбінація лекційної і лабораторної частини в одному занятті, хоч це розходиться з форматом офіційного навчання. Складність даного курсу для студентів також в тому, що вони не відчувають виробничих потреб. Тим не менше, маємо сподівання що основи курсу таки знайдуть відображення у їх реальних майбутніх проектах.

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

Явні скептики використання стандартів після курсів почали відноситися до даного стандарту як до кращих практик.
- Кілька досвідчених спеціалістів, які розробляли багато великих та складних проектів, відкрили для себе автомат станів. Це було видно за їх реакціями і відгуками. Якби дати оцінку корисності підходів, які дає стандарт, автомат станів мабуть зайняв би перше місце.
- Важко сприймався, але з часом ставав нормою для слухачів принцип відокремлення технології від устатковання, і відповідно процедурного керування від базового.
- На курсах були слухачі, що мали певні представлення про Batch Control. Їх цікавили питання підходів щодо визначення процедурних елементів та виділення устатковання (апаратурних об’єктів). На той час у нас не було такого досвіду, наразі є певні напрацювання, однак вони потребують певної формалізації.
- На курсах необхідно піднімати складні питання, які краще допомагають зрозуміти сутність ключових понять. Наприклад, було питання типу: «Чи є пастеризатор технологічним вузлом порційного типу і чому?», навколо якого піднялася цікава дискусія.
- Слухачі пропонували цікаві пропозиції, які перекликаються з викладеними в розділі 4 даної книги. Це черговий раз доводить необхідність таких семінарів, де спеціалісти можуть спільно вирішити ряд насущних задач.
- На курсах було мало практичних занять, з іншого боку – він був пересичений лекційним матеріалом. З цього можна зробити висновок, що курс треба робити більшим (4 або 5 днів) але обов’язково з практичними заняттями.

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

Матеріали курсу Batch Control у НУХТ

Конспект лекцій

Лабораторні роботи

Кому потрібен стандарт IEC 61512?

Стандарт IEC 61512 розроблений в технічному комітеті ISA, робота якого стосується систем автоматизованого керування. Складається враження, що стандарт потрібен виключно для інженерів з автоматизованого керування. Але чи це дійсно так?

У життєвому циклі систем керування порційними виробництвами залучені різні стейкхолдери (зацікавлені особи). На нашу думку стандарт IEC 61512 відноситься до інших інженерів так само, як відноситься до них схема автоматизації (P&ID). Тобто деталі стандарту повинні бути відомі усім автоматникам, а основи – усім хто задіяний в життєвому циклі порційного виробництва, побудованого відповідно до його вимог.

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

Усі учасники життєвого циклу.

Наявність єдиного стандарту дає можливість розмовляти однією мовою і мислити одними категоріями усім учасникам життєвого циклу. Досвід показує, що непорозуміння між учасниками проекту можуть привести до значного затягування термінів реалізації або невдалої реалізації і проблеми подальшого супроводження. У нашій практиці неодноразово зустрічалися випадки, коли у головного проектанта змішувалися поняття режимів, станів і методів доступу в один незрозумілий і заплутаний конгломерат, що приводило до необхідності неодноразової переробки.
Стандарт дає готові підходи до побудови ієрархії устатковання та процедурного керування, що впливає не тільки на розробку системи керування а і на проектування об’єкта взагалі. Тобто прийняття стандарту на усіх рівнях дозволяє проектувати «залізо» за правилами гнучкого виробництва.
Побудова систем на базі парадигм Індустрії 4.0. Стандарт є одним з базових, що входять до різних платформ І4.0, зокрема німецької (RAMI 4.0). Це значить, що побудова сучасних систем неможлива без знання стандарту.

Експлуатаційний персонал (оператори та відповідальні за основне виробництво).

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

Наявність єдиного стандарту на підприємстві робить його експлуатацію простішою, так як використовуються однакові правила.
Можлива реалізація стандарту, при якому можна переносити рецепти між різними технологічними комірками.
Стандарт організовує виконання ручних дій. Тобто самі дії залишаються ручними, але ініціювання їх виконання може проводитись відповідно до рецепту, а підтвердження результату є умовою завершення певного технологічного кроку.
Автоматична фіксація усіх дій в журнал. Не потрібно вести виробничі журнали, так як усі дії (у тому числі ручні) пишуться в архів виготовлення партії.
Гнучке керування станом процедури керівного рецепту. Нерідко системи керування розробляють таким чином, коли неможливо «проштовхнути» процедуру на інший крок. Згідно стандарту така можливість передбачена через зміну режиму та станів. Крім того стандарт передбачає в ручному режимі запуск будь якого етапу за необхідності.
Вибір устатковання за потребою. У випадку непередбачуваних причин оператор може вибрати інше устатковання ніж було вибрано початково.
Можливість гнучкого планування виробництва. Хоч у стандарті не означені методи планування, навіть при ручному календарному плануванні за історією партії можна визначити інтервали часу для приготуванні різних продуктів у різному устаткованні.

Технологи.

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

Усі спеціалісти з автоматизації, задіяні в розробці та наладці системи.

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

Програмісти АСКТП.

Стандарт означує стійку структуру програми. Правильно побудована прикладна програма зменшує кількість помилок і спрощує її відлагодження. Хоч стандарт явно не вказує на правила побудови прикладної програми у ньому є певні вимоги, які вказують на них. Наприклад, речення «підлеглі апаратурні об’єкти повинні мати можливість виконати свою задачу(-чі) незалежно і асинхронно, дозволяючи апаратурним об’єктам вищого рівня координувати діяльність своїх підлеглих» вказує на те, що ієрархічно організовані функції повинні виконуватися паралельно а не вкладено;
Спрощення колективної розробки. У великих проектах можуть приймати участь кілька програмістів. Стандарт означує правила декомпозиції об’єкта з точки зору устатковання та процедурного керування. Це дає змогу розділити роботу як по горизонталі, тобто на одному ієрархічному рівні, так і по вертикалі, коли функції або функціональні блоки розробляють різні люди.
Єдиний стандартизований інтерфейс на усі проекти. Наявність означених автоматів станів передбачає розробку чітко означених інтерфейсів функцій/ФБ, які відповідають стандарту. По суті, велика частина роботи по означенню інтерфейсів вже зроблена в стандарті.
Використання стано-орієнтованого програмування. Для реалізації цього стандарту використання стано-орієнтованого програмування є обов’язковим. Практика показує, що цей стиль вимагає чітких правил, що значно зменшує можливу невизначеність роботи програми, кількість помилок та спрощує процедуру перевірки.
Означені принципи архітектури об’єктів. Програмісту не потрібно придумувати власні правила виділення об’єктів, декомпозиція проводиться колективом розробників за правилами, що означені в стандарті.
Спрощення побудови розподілених систем керування. Асинхронність виклику процедур та функцій базового керування дають можливість повністю розподіляти їх між різними засобами автоматизації. Це також дуже важливо для роботи згідно ідеології Індустрії 4.0, що передбачає інтелектуальність устаткування різного рівня. Взаємодія через пару COMMAND/STATUS дає можливість побудувати систему з використанням архітектур IIoT (Industrial Internet of Things).
Використання правил надання (Alloction). Означення механізму надання вирішує конфлікти доступу до спільних ресурсів. Навіть без повної реалізації стандарту, його розуміння вже дає відповіді на питання правил розподілу ресурсів.
Спрощення реалізації KPI. Використання процедур та устатковання на базі станів спрощує реалізацію розрахунку KPI, так як умови початку і кінця зміни стану або режиму явно відслідковуються. Явне виділення об’єктів устатковання дає можливість робити розрахунок складових KPI (наприклад кількості, сумарного часу) на першому рівні ієрархії (контролери).