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

Рис. 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. Практика використання процедур  

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

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

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

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

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

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

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

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

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

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

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

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

Читати далі…

Модулі керування 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 відповідають переходам між станами з вказаними умовами цих переходів.

Рис. 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. Модулі керування