Впровадження 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.

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

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

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