TK 185

У коментарях додавайте посилання на наукові статті, ми будемо оновлювати список.

1. АНАЛІЗ МЕТОДОЛОГІЧНИХ ОСНОВ ФОРМУВАННЯ ІНФОРМАЦІЙНО-УПРАВЛЯЮЧИХ СИСТЕМ ПІДПРИЄМСТВ В ІНДУСТРІЇ 3.0: РУХ ДО ІНДУСТРІЇ 4.0. С.І.ДОЦЕНКО, О.О.ІЛЛЯШЕНКО, С.С.КАМЕНСЬКИЙ, Д.Р.КУПРЕЙШВІЛІ, В.С.ХАРЧЕНКО

Ми поспілкувалися з Ярославом Люлько, інженером з автоматизованих систем керування в ТОВ «Сілоджік Груп», щодо досвіду впровадження спорідненої до стандарту 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: стандартними засобами АСКТП (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.

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

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

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

Згідно 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).

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

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

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

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

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

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

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

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

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

У наступних проектах ми об’єднали команди, що схожі за призначенням (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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Технологи.

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

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

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

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

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