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. Запис звітної інформації засобами контролера

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *