Категорія: Публікації

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

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

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

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

• керування операціями основного виробництва (MES – Manufacturing Execution Systems): планування, диспетчерування, запуск виконання, контроль та звітність виконання і т.п; системи призначені для різного типу керівників виробництва (начальник виробництва, начальник дільниці і т.п)
• керування операціями по обслуговуванню устатковання (ТОіР – технологічне обслуговування та ремонт; EAM – Enterprise Asset Management, який включає також функції вищого рівня): планування, контроль стану, контроль виконання, звітність, замовлення деталей і т.п.; системи призначені для інженерно-технічних підрозділів підприємства (механіки, електрики, КВПіА);
• керування операціями по керуванню якістю (LIMS – Laboratory Information Management System): планування та виконання контролю якості, формування звітної інформації по якості і т.п.; системи призначені для керівників з якості, працівників лабораторій і т.п;
• керування операціями по керуванню запасами (WMS – Warehouse Management System): планування та контроль наявності, переміщення сировини, напівпродуктів та продуктів; системи призначенні для начальників складів, виробничників та іншого персоналу, відповідального за запаси.          

У свою чергу, системи MOM взаємодіють з системами рівня керування підприємством (АСК П), а саме його фінансово-економічною діяльністю. До таких системи відносяться системи ERP (Enterprise Resource Planning), призначення яких – автоматизація планування, бізнес-процесів, організаційно-економічної діяльності, документообігу і т.п. Також там можуть виконуватися інші спеціалізовані застосунки, як SCM (Supply Chain Management) для керування ланцюжком постачань. З рівня MOM в системи рівня АСК П передаються узагальнені виробничі показники, а на рівень MOM об’ємні виробничі плани.

Системи рівня керування рівня MOM та АСТКП забезпечують виконання виробничих операцій, або іншими словами автоматизують операційні технології OT (Operation Technologies). Системи керування бізнес-процесами автоматизують інформаційні процеси і відносяться до класу IT (Information Technologies). На виробничому підприємстві ці два сектори взаємодіють для забезпечення функціонування єдиної інтегрованої системи керування усім підприємством.

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

Фізична структура інтегрованої системи може відрізнятися в залежності від підходів. Наприклад інтегрування рівнів може проводитися з використанням технологій промислового Інтернету речей (IIoT), а явно виділені системи деяких рівнів можуть бути відсутні.

Питання інтегрування зі SCADA та ієрархія устатковання

Треба розуміти, що забезпечення інтеграції на рівні даних – це лише частина задачі, інша частина – це інтерпретація цих даних.   

На сьогоднішній день ці питання інтегрування систем керування описуються рядом стандартів, зокрема  ДСТУ EN 62264 та ДСТУ EN 61512. Згідно цих стандартів керування підприємством може бути представлено у вигляді функціональної ієрархії (рис.2). На кожному рівні вирішуються окремі функції та потребують різних часових рамок. Відповідно до рис.2 обмін між другим та третім рівнем може функціонувати як обмін зі SCADA. Стандарт ДСТУ EN 62264 стандартизує представлення об’єктів та функцій, які стосуються операційної діяльності на рівні 3. Іншими словами стандарт описує які повинні бути сутності (об’єкти) і як вони повинні бути представлені в інформаційних структурах (наприклад таблицях), для того щоб представити операційну діяльність виробництва. До таких об’єктів входять різні види ресурсів: устатковання (забезпечує виробництво), персонал, матеріали (з чого виготовляється і що виготовляється), активи (наявні підконтрольні необоротні ресурси) та їх об’єднання. Для представлення об’єктів рівня 2 (АСКТП) існують стандарти групи ДСТУ EN 61512, але вони стосуються тільки порційного типу виробництва, хоч можуть бути так саме прийняті і до інших типів виробництв.

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

Модуль керування (Control Module) забезпечує виконання функцій керування обладнанням. По суті це ті засоби та їх функції, які прийнято показувати на схемах автоматизації як засоби КВПіА: датчики, виконавчі механізми, регулятори та їх об’єднання. Цей рівень устатковання може бути цікавим для систем класу ТОіР та EAM. Наприклад, системи ТОіР (технічного обслуговування та ремонт) може цікавити інформація про кількість спрацювань, мотогодини роботи, статистика тривог і т.п. Зверніть увагу, що у даному прикладі систему верхнього рівня цікавить інформація не про стан датчиків положення а про узагальнений стан виконавчого механізму.       

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

Робочий вузол (Work Unit) – робить певну одну або кілька виробничий операцій. Для порційного виробництва (Технологічний вузол, Unit) це може бути реактор, або ємність в якій виробляється певна порція продукту. Для неперервного це може бути певний апарат неперервного типу, для дискретного – якась машина (наприклад пакувальна). На верхній рівень може передаватися стан устатковання, кількість виготовленої продукції та інші узагальнені показники та статистичні дані. З верхнього рівня можуть передаватися команди на запуск (зупинку, паузу і т.п), задана кількість, потрібна операція, рецепт і т.п.  

Робочий центр (Work Center) – це набір устатковання, що робить певний напівпродукт. Як і в попередньому випадку, може відбуватися обмін станами, командами і параметрами.  

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

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

Наявність моделей устатковання на кожному з рівнів робить можливим побудувати єдину базу SCADA. Це значно спростить інтегрування з функціональної точки зору. Якщо в рівень MOM необхідно передати якусь інформацію, зручно буде якщо вона буде вже підготовленою в термінах устатковання. Це може бути також певна звітна інформація, наприклад про кількість тривог, статистика по трендам, тощо за певний період часу. У засобах SCADA/HMI деяких виробників з’являється підтримка устатковання. У більшості випадків це зроблено не з метою інтегрування, а для спрощення контролю та керування. Нижче наведені приклади використання моделей устатковання в SCADA Citect та zenon, які надають можливість в середовищі виконання фільтрувати тривоги та записи в журналах по вибраному устаткованню а також виконувати функції для нього. Для середовища розробки устатковання  можна використовувати як допоміжне поле для фільтрації. Це тільки частина з переліку доступних функцій, детальніше описано нижче.          

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

У SCADA Citect наявність устатковання не є обов’язковим. Однак, його використання значно покращує для оператора ситуаційну обізнаність, керованість процесом та може значно скоротити час розробки та модернізації. Починаючи з версії 7.4 в Citect з’явилися додаткові таблиці з означенням моделі устатковання (equipment, в рос.лок. «оборудование»). Кожен запис устатковання включає ім’я, яке має ієрархічну структуру, де ієрархічні рівні розділені крапкою. Так “Loops.Level” передбачає устатковання з іменем “Level”, що входить в устатковання верхнього рівня з іменем «Loops» (див рис.4). Ієрархію можна створювати шляхом добавлення подібних імен в редакторі моделі устатковання Citect Studio, але зручніше це робити через спеціальний редактор устатковання, який входить в середовище розробки Citect. Цей редактор відображає модель у наглядному деревовидному вигляді  (рис.4).       

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

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

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

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

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

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

Устатковання також може мати стани, за допомогою яких можна налаштувати керування ним через планувальник. Крім тегів до устатковання можуть бути прив’язані акумулятори (Accumulator). Акумулятори можуть рахувати кількість запусків, інтегрувати певну величину, та рахувати загальний час роботи. При конфігуруванні в Citect інтерфейсу OPC ієрархія устатковання може бути використана для формування простору імен ItemID.

Окрім додаткових можливостей, які надає ієрархія устатковання SCADA Citect у середовищі виконання, розробник проекту може використовувати його як вихідну точку проектування. Враховуючи, що устатковання (Equipment) є додатковою властивістю тегів, їх можна використовувати в якості фільтрації та упорядкування записів в табличних редакторах тегів. Але це не єдина можливість, механізм устатковання дає можливість зовсім по іншому побудувати процес розробки. Класичний для Citect до версії 7.3 механізм розробки передбачав створення тегів (за необхідності акумуляторів), через заповнення таблиць або полів в редакторі. Це має ряд недоліків, зокрема передбачає велику кількість рутинної роботи по заповненню. При необхідності зміни тегу, розробнику приходиться шукати його в таблиці тегів де змінювати поля, потім в таблиці тегів тривог а потім можливо ще в таблиці трендових тегів. Більшість об’єктів предбачають однотипні структури, які згуртовані навколо устатковання. Так, наприклад з насосом зв’язано кілька параметрів (частота обертів, операційний стан, температура підшипників і т.п.), тривог та трендів. Citect дозволяє процес створення почати з устатковання, яке автоматично створить пов’язані з ним теги. Спочатку визначається тип устатковання, в якому задаються правила створення устатковання та необхідних тегів, що з ним пов’язані. Тип устатковання описується файлом XML, але розробнику не обов’язково розуміти його внутрішню структуру. Типи можна створювати та редагувати через редактор типів устатковання, який представлений окремою вкладкою в редакторі устатковання (рис.6). 

Основним змістом типу є елементи (Item), кожен з яких може асоціюватися з змінним тегом, тривоговим тегом або трендовим тегом. При створенні тегів, він міг прив’язуватися до елемента існуючого устатковання. Тут же конфігурується зворотній напрямок – від створення  устатковання та його елементу до тегів. На рис.6 до елементу Setpoint будуть прив’язані змінний тег, аналоговий аларм та трендовий тег. Екземпляри устатковання одного типу матимуть однаковий набір елементів, що створюватимуться за однаковими правилами. На рис.7 показані правила створення змінного тегу для елементу з іменем «Setpoint». В лівій частині вказуються імена властивостей тегу, а справа – правила створення їх значення. Текст, що взятий у фігурні дужки «{}» передбачає вставку замінника, що означений в цьому тексті. Так, наприклад «{equipment.tagprefix}_SP» вказує на те, що значенням даної властивості буде конкатенація (поєднання) значення властивості “Tag prefix” (рос. лок. «Префикс дескриптора») устатковання та «_SP».

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

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

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

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

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

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

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

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

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

Висновки.

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

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

Щоб зрозуміти, як саме стандарт IEC 61512 дозволяє добитися виконання тих чи інших заявлених функцій, і пояснити яким чином він допоміг при впровадженні нам та нашим колегам по цеху, треба хоч поверхово розглянути його фундаментальні засади. Наведений нижче текст ніяк не претендує на повноту викладення матеріалу, а радше служить в якості дуже коротких нотаток. Ми рекомендуємо ознайомитися з самим стандартом, зокрема з його першою частиною, переклад якої українською мовою доступне за посиланням  https://tk185.appau.org.ua/61512/ukr/ .

Перша частина стандарту вийшла в світ у 1995-му році, як ANSI/ISA–S88.01–1995 “Batch Control Part 1: Models and Terminology”. Через кілька років стандарт ISA (International Society of Automation www.isa.org ) був затверджений на міжнародному рівні як  IEC 61512-1. З того часу вийшло ще кілька частин стандартів ISA та їх зеркальних варіантів IEC, зокрема:        

• IEC 61512-1 (ANSI/ISA–S88.01–1995) Batch Control Part 1: Models and Terminology.
• ANSI /ISA–88.00.01 –2010 Batch Control Part 1: Models and Terminology (Update 2010)
• IEC 61512-2 (ANSI/ISA–88.00.02) Batch Control Part 2: Data Structures and Guidelines for Languages (2001)
• IEC 61512-3 (ANSI-ISA-88.00.03) Batch Control Part 3: General and Site Recipe Models and Representation (2004)
• IEC 61512-4 (ANSI/ISA-88.00.04) Batch Control Part 4: Batch Production Records (2006)
• IEC 61512-5 (ANSI/ISA-88.00.05) Batch Control Part 5: Implementation Models & Terminology for Modular Equipment Control
• ISA-TR88.00.02 Machine and Unit States: An Implementation Example of ISA-88 (2008)
• ISA TR88-95.00.01 ISA-88/95 Technical Report Using ISA-88 and ISA-95 Together

Як видно, кілька документів ISA так і не знайшли свого відображення в IEC. Зокрема, оновлена версія 2010-го року. Тим не менше, фундаментальні основи 2-х версій залишаються незмінними, саме про них описано нижче. 

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

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

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

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

Тобто технолог створює процедуру рецепту, набираючи технологічну програму з блоків (етапів), тестує, зберігає у бібліотеці рецептів і випускає у використання на виробництві. Така програма може мати вигляд як таблиця, або як діаграма (рис.4). Послідовність роботи з рецептом можна подивитися, наприклад, за цим посиланням https://youtu.be/jCCe0jQ84fk

Рецепти можуть добавлятися, видалятися, змінюватися, але незмінними будуть залишатися будівельні блоки, які будуть частиною системи керування устаткованням. Зрештою, якщо етапи на якомусь обладнанні мають виконуватися в ручному режимі, рецепти будуть ті самі, зміниться тільки реалізація керування устаткованням.

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

Керування станами та режимами. Для виготовлення конкретної партії з майстер рецепту створюється керівний рецепт, назначається йому унікальний ідентифікатор партії (Batch ID), змінюються параметри і запускається на виконання процедура рецепту. Завершення процедури керівного рецепту приводить до завершення виготовлення партії, а уся інформація залишається в історії. Така послідовність роботи процедури («початок» –> «виконується» –> «завершено») буде у ідеальному випадку. А що, якщо щось піде не так при виготовленні партії? Що, якщо під час виготовлення партії:

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

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

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

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

Ієрархія устаткування. Для того, щоб правильно розподілити яке устатковання буде виконувати конкретні процедурні елементи (етапи) стандарт означує ієрархію устатковання. У стандарті виділяються такі рівні устатковання:

• рівень технологічної комірки (Process Cell), який відповідає за виготовлення усієї партії, тобто за виконання процедури керівного рецепту;
• рівень технологічних вузлів (Unit), в яких проходять основні технологічні операції з партією;
• рівень модулів устаткування (Equipment Module), який відповідає за додаткові технологічні операції;
• рівень модулів керування (Control Module), які невидимі для процедури але реалізовують усі керівні дії на устаткованні.

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

Ієрархія устатковання в IEC-61512 співпадає з IEC-62264 (стандарт про інтегрування MOM та ERP), що спрощує інтегрування системи з рівнем керування усім виробництвом та підприємством.     

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

     Крім детального опису наведених вище основних концепцій, в першій частині стандарту також описані:

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

Для ознайомлення з усіма функціями Ви можете прочитати навчальні матеріали за посиланням.  

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

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

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

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

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

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

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

2. Планування та перепланування. Гнучкість порційного виробництва потребує швидкого планування. Навіть якщо на виробництві є система MES, як правило вона забезпечує планування до рівня робочого центру, але не до технологічного устатковання всередині нього. Крім того, постійні зміни умов проходження процесу в середині робочого центру потребує перепланування.          

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

4. Простежуваність процесів. Простежуваність виробництва включає три складові:

1. простежуваність постачальника (зовнішня простежуваність, крок назад);
2. простежуваність процесів (внутрішня простежуваність);
3. простежуваність покупця (зовнішня простежуваність, крок вперед).

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

5. Інтегрування з верхнім рівнем. На відміну від неперервних виробництв, для вищих рівнів керування (MES/MOM, або ERP) недостатньо передавати тільки агреговані та усереднені значення основних виробничих параметрів. Необхідно надавати дані про партію, зокрема про рецепт та технологічні параметри, при яких вироблялась партія. У свою чергу система керування виробничими операціями (MOM) повинна також передавати календарний план виготовлення партій, який узгоджений зі станом виробничого устатковання.

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