Практичні рекомендації до реалізації елементів стандарту IEC 61512 в програмному забезпеченні систем керування

Олександр Пупена,
Роман Міркевич,
Олег Клименко

1. Використання підходів ієрархії устатковання при розробці програмного забезпечення.

Тільки деякі з об’єктів автоматизації відносяться до порційного (Batch) типу. Тим не менше, як показує практика, багато підходів, викладених в стандарті IEC 61512 варто використовувати при впровадженні систем автоматизації незалежно від типу виробництва. Перш за все це відноситься до погляду на автоматизований комплекс з точки зору проектувальника та програміста АСКТП. Класичним є представлення автоматизованого комплексу у вигляді набору устатковання (залізо) та засобів автоматизації (набір датчиків, виконавчих механізмів, функцій/задач). Традиційний підхід до автоматизації йде через взаємопов’язані в контури функції:

«датчики -> входи регулятора (контролера) -> функції -> виходи регулятора (контролера) -> виконавчі механізми»

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

1.1. Устатковання (Equipment)

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

Навіщо виділяти устатковання як окремі сутності, а не використовувати традиційні підходи на базі функціональних контурів? Перш за все слід розуміти, що у результаті виділення устатковання як окремих об’єктів, функції та навіть контури нікуди не діваються, вони стають частиною цього устатковання. По суті устатковання агрегують функції та їх зв’язки  у більш загальні сутності, які сприймаються як єдине ціле. Розглянемо для прикладу, як представлений в системі автоматизації 2-х позиційний клапан або заслінка:

  • орган керування (безпосередньо клапан або заслінка);
  • виконавчий механізм з одним керуючим пневматичним сигналом «ВІДКРИТИ»;
  • два датчика кінцевого положення «ВІДКРИТИЙ», «ЗАКРИТИЙ»;

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

  • базові функції контролю та керування;
  • функції взаємодії з HMI, такі як переключення режимів руч/авт, та ручне керування;
  • функції тривожної сигналізації.  
Рис. 1. Зображення клапан на схемі автоматизації

У програмах контролера та SCADA/HMI будуть відповідні змінні/теги та або/функції. Але з точки зору експлуатації клапан сприймається не які сукупність функцій, а в поняттях його станів, наприклад: функціонального («відкритий», «закритий»), режиму («у ручному режимі», «в автоматичному»), тривоги («не відкрився»). Ці поняття  характерні для клапана в цілому, а не для його частин чи функцій. Тому на дисплеях HMI засоби автоматизації можуть показуватися як згруповані разом елементи, анімація передбачатиме використання всіх тегів, які мають відношення для клапану.

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

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

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

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

Для багатьох інженерів АСКТП використання об’єктного підходу стало типовою практикою. Тим не менше, її застосовують не всі. Крім того, часто зустрічається частково-об’єктний підхід, що пов’язано з погано проробленою методологією створення ПЗ. Стандарт IEC 61512 дає певні правила виділення та оперування таким об’єктами-устаткованнями, хоч не обмежує в цьому, зокрема:

  • устатковання (equipment) існують як виділені в системі керування сутності зі своїми наборами атрибутів;
  • устатковання мають певну роль, від якої залежить, які типи функцій воно виконує;
  • устатковання формують ієрархію, розміщення в якій також впливає на керування.     

Отже, окрім набору функцій та відповідних їм змінних в програмі контролера чи SCADA/HMI, передбачається наявність окремих сутностей (об’єктів) – устатковання (equipment), яке включає в себе інші об’єкти (дрібніші частини устатковання) та функції. Надалі під словом «устатковання» будуть розумітися спеціалізовані об’єкти в системі керування, які є двійниками їх фізичних сутностей.  Функції устатковання надалі будемо називати функціональними елементами.

Взаємодія з устаткованням проводиться через його змінні стану та команди.    

1.2. Стани (States)

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

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

Для прикладу розглянемо наведений вище клапан. Його стан можна розглядати з точок зору станів його функціональних елементів:

  • операційна функція (функція керування/контролю позицією клапану): ВІДКРИТИЙ, ЗАКРИТИЙ, ВІДКРИВАЄТЬСЯ, ЗАКРИВАЄТЬСЯ, НЕ ВИЗНАЧЕНИЙ (наприклад одночасне спрацювання обох кінцевиків) та ін.;
  • функція тривожної сигналізації: НЕМАЄ ТРИВОГ, НЕ ВІДКРИВСЯ, НЕ ЗАКРИВСЯ, ДОВІЛЬНИЙ ЗСУВ та ін; у свою чергу кожна з цих тривог також описується певним станом: НЕ АКТИВНА, АКТИВНА НЕ ПІДТВЕРДЖЕНА, АКТИВНА ПІДТВЕРДЖЕНА та ін; тому загальний стан наявності тривог клапана є певною згорткою;
  • режим функціонування: АВТОМАТИЧНИЙ (алгоритми системи керування), РУЧНИЙ (дії оператора), МІСЦЕВИЙ (керування за допомогою перемикачів по місцю), БЛОКОВАНИЙ (функції керування не активні);
  • функція імітації роботи (наприклад, з метою налагодження): РЕАЛЬНИЙ(зчитує значення з входів та записує виходи) та ІМІТОВАНИЙ (значення датчиків генеруються алгоритмом імітації, значення виходів не записуються);
  • функція обслуговування: НА РЕМОНТІ, ФУНКЦІОНУЄ; останній час обслуговування; кількість переключень;

Перелік функціональних елементів та їх станів варіюється від вимог до контролю та керування устаткованням і не обмежуються стандартом. Оскільки устатковання можуть бути складеними, то станів може бути набагато більше, оскільки воно включає в себе кілька об’єктів. Наприклад, для устатковання типу «насос з перетворювачем частоти» стан представляється узагальнюючим набором станів функціональних елементів 2-х об’єктів: двигуна та перетворювача частоти. Крім того, з точки зору функції операційної діяльності розглядаються не лише дискретні набори станів (ВКЛЮЧЕНИЙ, ВІДКЛЮЧЕНИЙ) а й додаються аналогові значення плинної частоти (швидкості), струму, напруги, тощо. У той же час на основі аналогових значень можуть формуватися набори дискретних станів функцій, такі як «працює на мінімальній частоті» або «на максимальній». 

Таким чином, контроль за устаткованням відбувається через відповідні змінні стану, які повинні бути в програмі контролеру, SCADA/HMI чи іншого інтелектуального засобу. Для дискретних станів функцій це бітові статуси, які приймають значення TRUE/FALSE, або їх комбінація.

бітові статуси = дискретні стани або їх комбінація

Сукупність цих станів функціональних об’єктів є об’єднання (конкатенація) цих статусів. У цьому випадку всі стани функціональних об’єктів можна об’єднати в певний упорядкований набір бітів для всього устатковання – статусне слово (status word).

статусне слово = набір бітових статусів функцій елементів устатковання

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

Наприклад, для клапану статусне слово може мати вигляд як в таблиці 1. Біти стану можуть взаємно виключати один одного, наприклад «ВІДКРИТИЙ» і «ЗАКРИТИЙ», а їх рівність 0 – представляти інший стан. Наприклад, якщо біти 5-8 дорівнюють нулю – це вказує на стан «НЕ ВИЗНАЧЕНИЙ».

Таб.1. Приклад статусного слова для 2-х позиційного клапану.

Біт Опис
0 ALMOPN =1 тривога НЕ ВІДКРИВСЯ
1 ALMCLS =1 тривога НЕ ЗАКРИВСЯ
2 BLCK =1 БЛОКОВАНИЙ
3 ALMSHFT =1 тривога ДОВІЛЬНИЙ ЗСУВ
4 ALMSNSR =1 тривога ПОМИЛКА ДАТЧИКА
5 OPNING =1 ВІДКРИВАЄТЬСЯ
6 CLSING =1 ЗАКРИВАЄТЬСЯ
7 OPNED =1 ВІДКРИТИЙ
8 CLSED =1 ЗАКРИТИЙ
9 DISP =1 РУЧНИЙ режим (з ПК/ОП), =0 –  АВТОМАТИЧНИЙ
10 MANBX =1 МІСЦЕВИЙ режим
11 ALM =1 загальна тривога
13 FRC =1 хоча би одна зі змінних в об’єкті форсована
14 SML  =1 режим імітації

1.3. Автомати станів (State Machines)

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

якщо клапан в стані «ЗАКРИТИЙ» і прийшла команда «ВІДКРИТИ», перейти в стан «ВІДКРИВАЄТЬСЯ»

Для функції тривожної сигналізації це може виглядати так:

якщо клапан в стані «ВІДКРИВАЄТЬСЯ» і не спрацював датчик кінцевого положення і час відкриття більше максимального, то перейти в стан «НЕ ВІДКРИВСЯ»   

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

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

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

Рис. 2. Спрощений автомат станів тривог

Не дивлячись на те, що станів тривоги всього чотири, діаграма виглядає досить просто. Але стандарт IEC 62682 передбачає ще три можливих стани блокування, в які можна перейти з будь якого іншого стану. Діаграма показана на рис.3., але усі переходи показати там не вдасться.  

Рис. 3. Повний автомат станів тривог згідно IEC 62682

Розглянемо діаграму станів для операційної функції для клапану. У найпростішому випадку клапан має два стани – «ВІДКРИТИЙ» та «ЗАКРИТИЙ». У залежності від наявності датчиків кінцевого положення, клапан може описуватися автоматами станів, що показані на рис.4. На перший погляд, кожен з цих варіантів є самодостатнім. Однак кожен з них має ряд вад.     

Рис. 4. Приклади найпростіших варіантів автомату станів для клапану

У варіанті з двома кінцевиками при виникненні несправності одного з них, жоден з них не буде дорівнювати одиниці, або спрацюють обидва. Це автоматом не передбачено. Аналогічна ситуація може відбуватися і з другим варіантом, коли датчик кінцевого положення буде несправним. Третій варіант взагалі немає контролю стану, тому в цьому випадку для алгоритмів керування можливо треба врахувати час переміщення, для уникнення, наприклад, гідроударів. Будь який з цих варіантів не передбачає формування тривог на базі станів, так як автомату станів тривог ні на що орієнтуватися. Очевидно в наведених вище станах з датчиками кінцевого положення необхідно передбачити в якості умов переходу команд керування. Під останніми розуміється команди на об’єкт-устатковання, а не на його апаратну частину (тобто виконавчий механізм). Також, для спрощення побудови автомату станів тривожної сигналізації варто ввести додаткові перехідні стани «ВІДКРИВАЄТЬСЯ» та «ЗАКРИВАЄТЬСЯ». Крім того, варто ввести стан «НЕ ВИЗНАЧЕНО», якщо конкретну позицію неможливо ідентифікувати. З цього стану можна стартувати автомат при ініціалізації програми керування, або переходити туди при поломці датчиків положення (обидва в одиниці). У такому випадку, діаграма станів операційного функціонального елементу матиме вигляд як на рис.5.

Рис. 5. Приклад розширеного автомату станів для операційного функціонального елементу клапану

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

Рис. 6. Спрощений вигляд автомату станів для тривоги «НЕ ЗАКРИВСЯ»

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

Для прикладу з клапаном, устатковання описуватися кількома взаємозалежними автоматами станів:

  • операційний;
  • 4 автомати для тривог (НЕ ВІДКРИВСЯ, НЕ ЗАКРИВСЯ, ДОВІЛЬНИЙ ЗСУВ, ПОМИЛКА ДАТЧИКА);
  • блокування;
  • режимів роботи;
  • імітування

1.4. Режими (Modes)

Набір функціональних елементів і їх станів не означується стандартом. Тим не менше, подібні до описаних вище операційних функцій відносяться до так званого базового керування (basic control), опис якого дається в наступних розділах. Крім того, у стандарті окремо виділяються функції керування режимами (mode) устатковання. Режим  вказує на те, у який спосіб відбувається керування операційними функціями. Зрештою, «режими» це окремо виділені стани, які впливають на особливість виконання (алгоритмів) функцій устатковання, а інколи – і на їх автомати станів.

Для устатковання стандарт рекомендує використовувати два режими: РУЧНИЙ та АВТОМАТИЧНИЙ. У РУЧНОМУ режимі, операційний стан устатковання означується командами з HMI, у АВТОМАТИЧНОМУ – з алгоритму керування. На практиці режимів може бути більше. Наприклад, для згаданого вище клапану, на Рис. 7. показана діаграма з додатковими режимами «РУЧНИЙ ПО МІСЦЮ» і «ЗАБЛОКОВАНИЙ». У «РУЧНОМУ ПО МІСЦЮ» режимі, клапан керується байпасним щитком, що знаходиться біля клапану. У «ЗАБЛОКОВАНОМУ» режимі на клапан завжди подається команда «ЗАКРИТИ».

Рис. 7. Автомат станів переключення режимів устатковання типу клапана

У даному випадку на автомат станів, що наведений на рис.5, будуть подаватися команди керування з різних джерел. Але, у ряді випадків автомати станів деяких функцій можуть змінюватися в залежності від режиму устатковання. Наприклад, діаграма на рис.5 не передбачає контроль команди ВІДКРИТИ та ЗАКРИТИ у режимі «РУЧНИЙ ПО МІСЦЮ», так як ці команди не можуть бути простежені системою. Тому, для цього режиму варто продумати інший автомат.

Вище наведені приклади станів, які є взаємно-виключеними. Наприклад, стани ВІДКРИВАЄТЬСЯ і ЗАКРИВАЄТЬСЯ з рис.5 ніколи не можуть бути активними одночасно. Для прикладу з 4-ма режимами, все не так однозначно, оскільки наприклад режим РУЧНИЙ(з HMI) і РУЧНИЙ ПО МІСЦЮ (з байпасу) можуть виникнути одночасно. Необхідно чітко розставити пріоритети при керуванню станами в програмі. У цьому випадку, «РУЧНИЙ ПО МІСЦЮ» має пріоритет, оскільки команди з контролеру, нівелюються.

1.5. Умови переходів та команди  

Як зазначалось вище, автомати станів описуються станами та переходами, для яких задаються умови. Умовами переходу можуть бути як команди алгоритму керування (або HMI), так і вияв системою керування зміни стану устатковання, як правило за допомогою датчиків. Наприклад, на рис.5 перехід з ВІДКРИТО в ЗАКРИВАЄТЬСЯ відбувається по команді ЗАКРИТИ з системи керування, а з ЗАКРИВАЄТЬСЯ у ЗАКРИТО по стану датчика кінцевого положення. Слід звернути увагу, що датчик кінцевого положення, який є елементом клапану, теж є устаткованням, яке має свої стани. Він може мати стан ВІДМОВА, який може впливати на стани (або навіть режими) устатковання вищого рівня, тобто клапану.

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

Керовані умови переходу формуються командами. Можна виділити кілька джерел команд: з алгоритму керування, засобів HMI, системи верхнього рівня і т.п. У деяких випадках вони можуть відпрацьовуватися за різними алгоритмами, тоді діаграма станів має це відображати. Команди можуть бути реалізовані як бітові (ВІДКРИТИ, ЗАКРИТИ) або у вигляді числового слова команди (command word), де конкретна команда задається числом. Враховуючи, що за один раз устаткованню передається одна команда, як правило достатньо одного слова (числової змінної) для передачі всіх можливих команд керування. Обробник команд може не реагувати на ті команди, які недоступні в даному стані або режимі.

1.6. Приклад автомату станів в перетворювачах частоти   

Описаний вище підхід на базі автомату станів використовується для керування перетворювачами частоти (ПЧ) для різноманітних профілів, в тому числі, які стандартизовані в IEC 61800-7 (ProfiDRIVE, CiA 402, SERCOS, CIP Motion).

На Рис. 8. представлений приклад автомату станів керування перетворювачем частоти ALTIVAR (Schneider Electric) по профілю CiA 402. У кожному стані ПЧ доступні певні функції, керування обертами доступні тільки в стані «Operational enabled». Внутрішня логіка оперується на стани та умови переходу. По мережі передається слово статусу (ETA), яке показує значення стану. По суті воно є комбінацією статусних бітів, але для простоти їх показують в 16-ковому форматі як єдине значення. CMD – це командне слово, яке переводить автомат з одного стану в інший. Ці два слова, разом з заданою і плинною частотою циркулюють по мережі при обміні з контролером, що керує ПЧ. Таким чином, алгоритм керування даним устаткованням повинен спостерігати за його станом і керувати ним, передаючи конкретну команду. Слід зауважити, що на рис.8 не показані усі внутрішні умови переходу між станами, це винесено на внутрішню реалізацію в ПЧ. Також зверніть увагу, що стани операційного функціонального елементу та контролю помилок показані в контексті однієї діаграми.      Детальніше про керування перетворювачами частоти по мережі Ви можете почитати за цим посиланням.

Рис. 8. Автомат станів керування перетворювачем частоти ALTIVAR по профілю CiA 402.

З наведених вище прикладів можна зробити наступні висновки:

  • стано-орієнтований підхід вже давно використовується в різних засобах автоматизації і зарекомендувало себе як хороша практика;
  • стано-орієнтований підхід для устатковання дає можливість реалізовувати функції керування в різних пристроях, і таким чином не обмежується конкретною парадигмою типу SCADA+PLC vs DSC vs IIoT.
  • стано-орієнтований підхід дає можливість уникнути невизначеностей та помилок, пов’язаних з ними;
  • діаграма станів зрозуміла не тільки для автоматників, що дає змогу спілкуватися різним учасникам життєвого циклу однією мовою.

1.7. Стано-орієнтоване керування в ПЛК     

Для керування функціями устатковання в програмах ПЛК зручно використовувати механізм стано-орієнтованого програмування. Воно передбачає структуру типу CASE, в якій для кожного значення стану прописується алгоритм роботи та вказуються умови переходу. Структура програми на базі CASE добре читається сумісно з діаграмою станів, яку вона реалізовує. На рис.9 показаний приклад реалізації автомату станів з використанням структури CASE на мові ST. Аналогічну структуру можна побудувати на комбінації IF…THEN…ELSE, або з використанням компараторів в мовах LD, FBD чи CFC. Для автомату станів функції керування соленоїдним виконавчим механізмом використовується змінна кроку (STEP1) та бітові команди, які вище в програмі визначаються зі слова команди.  У залежності від значення кроку виконуються команди керування та перевіряються умови переходу.

Рис. 9. Програмна реалізація операційного автомата станів клапана.

Для ПЛК існує окрема графічна мова SFC, яка представляє діаграму станів. Ця мова дуже зручна з точки зору реалізації автоматів станів, але може мати ряд недоліків, пов’язаних з ресурсами та способом реалізації в конкретній платформі.

1.8. Правила декомпозиції та ієрархія устатковання

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

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

  • об’єкт має єдиний набір операційних станів;
  • об’єкт має показники якості функціонування КПЕ (КРІ, ключові показники ефективності);
  • об’єкт має свій набір режимів;
  • об’єкт має набір станів тривог;
  • об’єкт виділяється як технологічна одиниця, що робить певну технологічну операцію або кілька операцій;

Якщо об’єкт-устатковання у свою чергу складається з набору інших устатковань, то кожен елемент в його складі буде мати свої індивідуальні стани, режими, тривоги, які будуть формувати цей набір для об’єкта вищого рівня. Для прикладу можна розглянути пастеризаційно-охолоджувальну установку (ПОУ), яка складається з пастеризатора, сепаратора та гомогенізатора. З точки зору системи керування АСКТП ці три установки виконують конкретні функції по реалізації технологічного процесу. А з точки зору керування виробничою лінією, вони є одним об’єктом – ПОУ, яка виробляє продукт з певними характеристиками. У той же час, гомогенізатор може бути окремою автоматизованою машиною, яка включає в себе набір устатковання зі своїм набором станів і режимів. Ієрархічність будується за принципом підлеглості, тобто описується яким чином об’єкти вищого рівня керують/контролюють об’єктами нижчого рівня. У прикладі з клапаном це виглядає наступним чином – об’єкт клапан має в своєму складі три об’єкта нижчого рівня: датчики кінцевого положення ВІДКРИТО та ЗАКРИТО і соленоїд на відкриття (Рис. 10). При розробці програмного забезпечення, об’єкт-устатковання вищого рівня (наприклад ПОУ) буде взаємодіяти шляхом команд і статусів лише з клапанами, а не з датчиками та соленоїдом. У свою чергу, програміст АСТКП може зосереджуватися на реалізації функцій устатковання, попередньо означивши автомати станів та їх взаємодію на різних рівнях. 

Рис. 10. Ієрархія устатковання на рівні клапана

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

  • обробку вхідного/вихідного значення: масштабування, фільтрування, інвертування, тощо;
  • наявність режиму ручної зміни значення з датчика (форсування);
  • наявність режиму імітації;
  • обробку тривог (IEC 62682): реагування на порогові значення для аналогових величин, врахування затримки на спрацювання та гістерезису, формування системних біту аварії/попередження і т.п;
  • конфігурування: налаштування граничних значень та параметрів тривог, тимчасове зняття тривоги з обслуговування, налаштування масштабування, фільтрації, тощо.

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

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

  • враховувати стан об’єкта нижчого рівня (норма/тривога/достовірність) та діагностичну інформацію при керуванні логікою виконання; наприклад, якщо датчик кінцевого положення в стані НЕДОСТОВІРНІСТЬ (відмова модуля входів/виходів), клапан переходить в режим ЗАБЛОКОВАНИЙ;
  • проводити імітацію роботи підлеглих датчиків, шляхом оперування їх станами за імітаційним алгоритмом (наприклад для тестування або навчання персоналу);
  • керувати станом НЕДОСТОВІРНОСТІ підлеглих датчиків за алгоритмом, наприклад коли обидва датчика показують спрацювання.  

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

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

Прикладом поширення станів можуть бути аварійні стани, які з нижчого рівня поширюються по ієрархії вгору. Це значить, що усі тривоги відслідковуються на вищому рівні ієрархії устатковання (для кожної категорії відповідно до IEC 62682). В IEC 61512 та IEC 62264 рольова ієрархія устатковання має вигляд як на Рис.11. Відповідно до цієї ієрархії кожне устатковання виконує певну роль у процесі виготовлення продукції. При інтегруванні верхніх рівнів з системами АСКТП, керування та контроль відбувається через стани та команди устатковання. Які правила виділення устатковання на кожному з рівнів обговорюються в інших розділах посібника.    

Рис. 11. Рольова ієрархія устатковання підприємства

1.9. Використання спільних ресурсів

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

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

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

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

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

У стандарті IEC 61512 механізми вирішення пріоритетності надання описуються як задачі надання та арбітражу.

1.10. Рекомендації щодо реалізації

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

Екземпляр даних у свою чергу повинен включати змінні стану, команди та конфігураційні дані. Змінні стану включають в себе статусні слова, а також усі властивості устатковання, що показують його теперішній стан. Команди у свою чергу включають слово команди та інші змінні, що керують устаткованням. Конфігураційні (параметричні) дані потрібні для налаштування роботи алгоритмів устатковання. 

При першому погляді на ієрархію устатковання та фізичну його реалізацію у вигляді вкладеності, виникає бажання робити відповідну вкладеність функцій (або функціональних блоків). Але наш практичний досвід показує, що це не дуже вдале рішення. Бажано викликати програми обробки логіки роботи устатковання паралельно. Підпорядкування відповідно до ієрархії відбувається шляхом обміну станами та командами. Це не є вкладеністю, а координацією роботи відповідно до ролей. Подібні підходи були неодноразово випробувані на власному програмному каркасі [8]. Кожне устатковання реалізоване як окрема функція, в яку при виклику передаються дані реального часу (стани та команди) та конфігураційні.

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

Таким чином, у нашій практиці розроблення програмного забезпечення для систем керування кожне устатковання супроводжується як мінімум наступними змінними:

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

Програмна реалізація таких об’єктів передбачає:

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

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

Читати далі > 1.1. Модулі керування

Приклади використання ієрархії устатковання IEC-61512/IEC-62264 в засобах SCADA/HMI

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

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

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

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

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

Рис 2. Функціональна ієрархія виробничого підприємства

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

Рис 3. рольова ієрархія устатковання підприємства

Модуль керування (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).       

Рис 4. Зв’язок устатковання з тегами вводу/виводу

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

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

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

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

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

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

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

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

Рис 6. Редактор типів устатковання

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

Рис 7. Налаштування правил створення тегів, асоційований з елементом

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

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

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

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

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

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

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

Рис 8. Створення ієрархічної моделі устатковання та використання в змінній

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

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

Рис 9. Налаштування аргументів функції «Screen switch» для відкриття екрану моделі устатковання та вигляд екрану в режимі виконання

Висновки.

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

ВИРОБНИЧІ КПЕ: АКТУАЛЬНИЙ СТАН ТА ПЕРСПЕКТИВИ РОЗВИТКУ В УКРАЇНІ

В документі детально представлені головні положення стандарту ISO 22400, описаний їх загальний стан в Україні, вказані типові помилки при застосуванні КПЕ, визначені головні виклики експертної спільноти щодо подальшого впровадження на підприємствах України.

Продовжувати читання ВИРОБНИЧІ КПЕ: АКТУАЛЬНИЙ СТАН ТА ПЕРСПЕКТИВИ РОЗВИТКУ В УКРАЇНІ

Аналітичний звіт “Вертикальна інтеграція”

Новий аналітичний звіт «Вертикальна інтеграція. Виклики та перспективи» інтегрує всі попередні напрацювання проекту aCampus по відповідним стандртам, – в першу чергу по МЕК 62264 та ISO 22400.

Продовжувати читання Аналітичний звіт “Вертикальна інтеграція”

Стан обізнаності ринку про IEC 62264 за результатами опитування

Технічним комітетом 185 «Промислова автоматизація» разом з партнерами проведено опитування стосовно стану обізнаності зі стандартами ISA-95/IEC-62264, щодо використання систем керування виробництвом рівня MOM/MES, а також проведено оцінку важливості різних бізнес-драйверів. Незважаючи на малу кількість респондентів (8 осіб), що у свою чергу характеризує низьку зацікавленість ринку до стандарту, ми наводимо основні результати (див. таблиці 1-14) для поверхневої оцінки стану. З огляду на те, що не всі особи залишили свої контактні дані (останнє питання), це дещо зменшує довіру до їх відповідей, тому таблиці розбиті на дві частини. До опитування також долучився представник білоруської молочної компанії «Савушкін продукт», який є передовим підприємством харчової промисловості в Білорусі. Їх відповіді позначені літерою «Б».

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

На думку опитуваних, найбільш вагомими бізнес-драйверами є якість та простежуваність, а також швидке та оптимальне планування.  Якість та простежуваність – відповідність нормативним вимогам, визначення затрат на обслуговування для покращення продукту, безпечність для клієнтів та відстеження впливу небезпечних предметів на персонал (біля 90-100% опитуваних вважають показник важливим, оцінка 4-5 в діапазоні 0..5). Вдосконалене планування є ключовим бізнес-драйвером для компаній з дорогими запасами, трудомістким виробництвом, але швидкими змінами клієнтів та змінним попитом (біля 90-100%).

Трохи менш пріоритетними респонденти виділили швидке прогнозоване виконання замовлення та ефективність активів.  Автоматизована доступність прогнозування – швидко реагувати на замовлення  відповідно до стану виробництва (60-70%). Ефективність активів – орієнтація на максимізацію ефективного та економічного використання активів у виробництві продукції (60-70%)

Іншим бізнес-драйверам надали високі пріоритети від 40%-50% респондентів.

Скорочений час циклу  – час, який необхідний для виготовлення продукту з моменту розміщення замовлення (біля 50%). Оптимізація ланцюжка постачань – ведення бізнесу кожним учасником ланцюжку з використанням останньої і якісної інформації від інших учасників, щоб якнайкраще збалансувати попит і пропозицію (біля 50%). Гнучке виробництво – можливість змінювати налаштування виробничих активів для швидкого задоволення попиту на ринку (біля 40%).

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

В рамках опитування нас цікавила наявність різних систем керування виробництвом рівня MOM/MES на підприємствах респондентів. Серед опитаних найбільшої популярності досягли самописні модулі керування виробництвом (наприклад для «1С Предприятие»), які наявні на підприємствах у (75-100%) опитаних (див. таблицю 8). Розмова з представниками багатьох підприємств дає ту саму картину, що підтверджує реальність даних цифр. На нашу думку це пов’язано насамперед з двома пов’язаними причинами: тотальне впровадження 1С на рівні керування бізнес-процесами та наявністю програмістів в штаті, які й супроводжують і відповідно можуть доробити додатковий функціонал.      

У близько половини (40-60%) є системи автоматизації основного виробництва (MES), системи керування лабораторною інформацією (LIMS) та модулі виробничої аналітики. Слід відмітити, що в опитуванні приймали участь представники достатньо потужних підприємств, а отже ці дані є значно завищеними, ніж в середньому по всім українським підприємствам.   

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

За результатами опитування системи керування складом (WMS) практично відсутні на українських підприємствах.

Очевидне відставання Українських виробництв у порівнянні з передовим підприємством харчової промисловості в Білорусі, де наявні усі з перелічених систем.

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

Серед програмних засобів автоматизації підприємств (ERP-рівня) зазначали такі як SAP, 1C, Парус та власні розробки. Підтримку стандартів IEC цими засобами назвали біля 50% респондентів (MES або ERP). Відповіді сильно  розподілені, однак принаймні 50% кажуть про відсутність підтримки на всіх рівнях керування. Нам здається ця кількість дещо занижена.

Приблизно така сама ситуація в оцінці ступені інтегрування рівня MES та ERP. Системи «частково інтегровані» та «зовсім незалежні» приблизно поділилися 50% на 50%. Тільки один респондент (який не залишив своїх координат) відповів про повну інтеграцію з використанням власних стандартів.

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

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

Необхідність стандартизації відчувають біля 60% респондентів.

Хоч респондентів достатньо мало і нічого не можна сказати про репрезентативність вибірки, спробуємо зробити хоча б аналіз того, що маємо. Найбільш вагомими бізнес-драйверами, що можуть слугувати аргументом на користь використання інтегрування L4 та L3 взагалі, та з використанням IEC 62264, є контроль якості та простежуваність і швидке оптимальне планування. При цьому для реалізації функцій MOM лідирує спосіб «дописати модуль власними силами». На рівні АСКТП українські підприємства принаймні частково автоматизовані. Принаймні 50% говорять про відсутність інтегрування на всіх рівнях, і більше половини – про необхідність стандартизації. Зрештою, ми маємо і так відому картину – інтегрування потребується і стандарти в цьому можуть допомогти.         

Стандарт IEC 62264 як джерело знань: досвід впровадження в навчальний процес та на тренінгових курсах

Окрім своїх прямих цілей – забезпечення інтегрування рівнів MOM та ERP, стандарт IEC 62264 також може бути використаний для навчальних цілей. У даній статті розповідається про власний досвід авторів використання стандарту в навчальному процесі кафедри АКТСУ в Національному університеті харчових технологій та курсах підвищення кваліфікації.  

Ще з 2000-х років кафедра АКТСУ (тоді АКІТ) зробила багато дій щодо впровадження дисциплін, присвячених системам MES в навчальний процес. Свій важливий внесок в це у різні часи зробили «Індасофт-Україна»,  IT-Enterprise та інші організації, надавши промислові програмні пакети та допомагаючи навчальними матеріалами. Однак для кращого розуміння основ MES необхідний узагальнений матеріал, який би не залежав від постачальника рішень. Матеріали MESA на той час були сильно узагальненими, тому зрештою ми вийшли на стандарт ISA-95, який означував моделі представлення виробничого підприємства. Перше ознайомлення зі стандартом було невдале, він був малозрозумілим. Причин на те було декілька:

  • ми зосереджувалися на першій та другій частині першої версії, в якій було багато складних для розуміння додатків (чого варта тільки модель Perdue)
  • здебільшого уважно вичитували саме російську перекладену версію аналогічного стандарту IEC; радимо Вам не робити цього, так як переклад на нашу думку дуже не вдалий; звичайно що наш переклад може здатися Вам також не вдалим, але принаймні термінологію всередині стандарту ми узгоджували, щоб уникнути плутанини;
  • ми були недостатньо підготовлені у виробничих процесах, які відбуваються на підприємстві;
  • у нас не було досвіду впровадження модулів MES/MOM;
  • стандарт написаний не мовою автоматників, а мовою IT та виробничників;

Тим не менше, отримавши усі необхідні копії оригінальних версій стандартів ми поступово почали їх освоювати. Відкриттям стала третя та четверті частини стандарту. Якщо перші дві частини націлені на інтегрування рівня ERP та MES/MOM, то третя та четверта частина показують на функціонування MOM зсередини та дають необхідну інформацію для розуміння цих процесів. Це стало передумовою використання стандарту в якості прототипу посібника.

Цього року бельгійська фірма Brighteye залучила кількох викладачів кафедри до створення навчального контенту для підготовки інтеграторів MOM на ПЗ Momentum (в минулому, MESControl). Особливістю даного курсу було навчання саме інтеграторів АСКТП. Тобто необхідно було розробити повний курс з лекційним та лабораторним матеріалом, який би варто прослухати розробникам самим 🙂 . Складність цього завдання була в тому, що навчального матеріалу на той момент практично не було, але є довідникова система, яка, як виявилося, закриває необхідний матеріал відсотків на 80, що достатньо для його вивчення. У випадку проблемних питань спеціалісти Brighteye  надавали необхідну допомогу. Тим не менше, при досить слабкій на той момент підготовці викладачів в MES/MOM, це стало серйозним викликом. Головним висновком з точки зору навчальної діяльності став той факт, що розуміння функцій MOM приходило тільки при читанні відповідних розділів стандартів і визначення та перевірка їх відповідників у конкретному програмному забезпеченні. Відсутність одного з компонентів (стандарту або ПЗ) не мало б такого ефекту. Це можна вважати формулою навчання MOM. Слід відмітити, що Momentum  розроблений з урахуванням стандарту ISA-95 (IEC 62264). Там є певні розбіжності, зокрема в термінології, але зробивши певний mapping, все більш-менш почало співпадати зі стандартом. Таким чином, усі розділи теоретичних частин курсу починалися з означення частини стандарту. Так, наприклад, модулі Momentum розповідалися  у контексті виробничих операцій (рис.1).

Рис 1. Відображення (mapping) модулів Momentum на керування виробничими операціями

У такому саме контексті показувалися функції Momentum через модель діяльностей (рис.2).

Рис 2. Відображення (mapping) функцій Momentum на модель діяльностей MOM

Таким чином, теорія бралася зі стандарту і реалізувалася в конкретному екземплярі. З точки зору навчання – це найкращий варіант для отримання загального розуміння функціонування MOM.

Паралельно розроблений лабораторний курс почав впроваджуватися на кафедрі АКТСУ НУХТ при практично тому самому лекційному матеріалі, що був минулого року. 

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

  • поняття сегментів продукту;
  • як відбувається простежуваність продукту (внутрішня) на рівні підприємства та поза його межами (зовнішня);
  • за якими принципами відбувається налаштування планування;
  • як фізично відбувається розрахунок  КПЕ (ключових показників ефективності, KPI); стандартний OEE (ISO 22400) та відповідні вкладені КПЕ в Momentum реалізований простим конфігуруванням, інші КПЕ реалізуються також досить легко без необхідності програмування;
  • як працює керування операціями контролю якості;
  • як функціонально (не інформаційно) зв’язуються рівні MOM та ERP через передачу замовлень та звітів;
  • як зв’язуються рівні MOM та АСКТП.

Враховуючи, що курс призначений для автоматників, які на початку не усвідомлені в поняттях MOM та не володіють багатьма термінами IT, було вирішено навчальний процес будувати також на наступних принципах:

  • навчання починати від знайомих функцій: у даному випадку для автоматників це значить рухатися знизу MOM, тобто з рівня АСКТП; 
  • перший день є швидким стартом, який дає можливість оглянути усі основні діяльності MOM і може проводитися як незалежний міні-курс;
  • п’ятиденний курс повинен закрити усі діяльності, щоб почати розробляти систему MOM з типовими функціями;
  • під курс повинно бути розроблене віртуальне виробництво, з якого можна збирати дані і відправляти команди та параметри;
  • мінімальне використання кодування.

Окрім додаткових знань, отриманих від створення та викладання курсу, можна відмітити ще ряд додаткових висновків:

  • функціональність MOM можна зрозуміти за 5-дневний курс як інтеграторам так і керівному виробничому персоналу;
  • MOM можна впроваджувати і на невеликих підприємствах;
  • використання принципів ISA-88 (IEC-61512) значно спрощує інтеграцію АСКТП з MOM; зокрема дуже доречним є використання автоматів станів та процедур.       

Розроблені курси були адаптовані та проведені для кількох груп слухачів представників інтеграторів. Проводив курси Максим Романов, консультант Brighteye. Його оцінка «формули» курсу: «Подача материала в соответствии со структурой стандарта во первых отсекает некомпетентную критичность, во-вторых даёт уверенность в правильной структуре курса и материала, в комплексном охвате темы». У найближчому планується розробка курсу по IEC 62264, з елементами практики на одному із програмних продуктів класу MOM. Практика показала,  що саме такий підхід дасть можливість найкраще зрозуміти функції MOM та їх взаємодію з усіма рівнями керування. Обраний програмний пакет не обов’язково має бути Brighteye. Зрештою, курс повинен бути достатньо гнучким, щоб підлаштуватися під будь-які програмні засоби, що відповідають IEC 62264.  Слідкуйте за новинами на www.i4u.in.ua

Олександр Пупена

Стандарт IEC 62264 як основа концепції Industrie 4.0

Сьогодні класична пірамідальна методологія побудови систем керування все більше витісняється сучасними підходами прямої взаємодії між компонентами M2M, як це бачиться наприклад в RAMI4.0 або в IIC (IIoT). Тому може скластися враження, що ієрархічні моделі, що викладені в стандарті ISA-95/IEC-62264, наприклад устатковання та функції вже не можуть працювати в таких системах. Однак це не так. Нові концепції в дійсності будуються на вже існуючих технологіях, які затверджені в стандартах. Так, наприклад, ідеї, закладені в ISA-95/IEC-62264 у свою чергу базуються на  концепціях ISA-88/IEC-61512. Усі моделі, викладені в цих стандартах є нічим іншим як цифровими моделями виробництва з описом обов’язкових полів та зв’язків між об’єктами. Ці моделі вдосконалюються з кожною версією стандарту, вони можуть доповнюватися і видозмінюватися в залежності від потреб, але вони не залежать від способів організації систем керування. Більше того, ці стандарти стали основою моделі RAMI4.0 на якій базується Industrie 4.0.   

Німецька ініціатива Industrie 4.0 передбачає застосування комплексного підходу до імплементації бізнес цілей. Однією з основних особливостей такої парадигми є злиття двох світів, світу інформаційно-комунікаційних технологій (ICT) та світу операційних технологій (ОТ), тобто технологій автоматизації промислових процесів та виробництв. Останні означуються стандартами, що застосовуються в машинобудуванні, електроніці, електротехніці, автоматизації в цілому. Крім Німеччини інші країни також долучилися до здійснення четвертої промислової революції у себе. Проте, саме концепція Industrie 4.0, яка представлена моделлю Reference Architecture Model Industrie 4.0 (RAMI 4.0), сформована на основі майстерного об’єднання кращих світових практик. З метою формування швидкої відповіді на потреби ринку модель RAMI 4.0 описана німецьким інститутом стандартизації DIN та затверджена шляхом спеціальної нової процедури стандартизації, як DIN SPEC 91345:2016-04. Ця модель сформована з міцних цеглин світового досвіду – найбільш важливих стандартів для виробництва.

Автоматизоване виробництво в концепції Industrie 4.0 бачиться як взаємодія кіберфізичних компонентів I4.0, який включає в себе актив (Asset) та його віртуальну сутність (цифровий двійник). Поняття фізичного активу присутнє як в стандарті IEC-62264 так і RAMI 4.0, що робить можливим супроводжувати усі сутності, задіяні у виробництві по їх життєвому циклу. У RAMI4.0 поняття активу значно розширене (включає персонал, стандарти, софт, поширюється і на продукт), тим не менше в загальному розумінні вони з IEC-62264 мають одну основу.          Згідно моделі RAMI 4.0 компонент I4.0 представляється тривимірною моделлю (рис.21), яка відображає основні аспекти його діяльності протягом усього життєвого циклу. Перевагою використання такого підходу є чітке та наочне розуміння функції кожного рівня.  Визначальною особливістю німецької концепції є організація виробничої діяльності за рахунок об’єднання всіх активів підприємства в єдину I4.0-сумісну мережу, яка не має конкретних меж та може мати урегульований доступ для встановлення з’єднання та здійснення автоматичного обміну інформацією з іншими активами, навіть за межами підприємства. Кожен актив – це певна цінність для організації, тому до активів належать не тільки матеріальні об’єкти, але й нематеріальні, такі як програмне забезпечення та навіть ідеї. Концепція Industrie 4.0 означує процес створення правил цифрового опису активів, який доповнюється та змінюється протягом усього його життєвого циклу. Мета цієї моделі – представити актив та всі аспекти, що мають відношення до нього, від його розробки, виробництва та використання аж до його утилізації та забезпечити його взаємодію з іншими активами.

рис.21 Еталонна модель архітектури Industrie 4.0

Шість архітектурних рівнів, які лежать на вертикальній вісі еталонної моделі архітектури Industrie 4.0 означують структуру представлення компонента Industrie 4.0 (елемента єдиної мережі), тобто яким чином і якими засобами активи підприємства взаємодіють між собою в мережі та як вони в ній представленні. Модель RAMI 4.0 передбачає застосування сервісно-орієнтованої архітектури (SOA), де компоненти I4.0 надають послуги іншим компонентам через протоколи зв’язку по мережі. Огляд цієї осі виходить за рамки даної книги. 

Підхід Industrie 4.0 передбачає можливість розробки та вдосконалення продуктів, машин, заводів/фабрик і т.д. протягом всього їх життєвого циклу. Тому ліва горизонтальна вісь моделі використовується для представлення життєвого циклу систем або продуктів («Life cycle & value stream») у вигляді пов’язаних стадій «типу» («Type») та «екземпляру» («Instance»). За рахунок постійного збору даних це дає можливість простежувати стан продукту в будь-який момент часу його існування: від ідеї до експлуатації та утилізації. Розгляд активів з точки зору їх життєвого циклу спирається на стандарт IEC-62890 «Life Cycle Management». Права вісь моделі RAMI 4.0 – «Ієрархічні рівні» («Hierarchy levels») – забезпечує відображення активу на  конкретну роль у виробництві. Ієрархічні рівні RAMI 4.0 в рамках одного підприємства базуються на ієрархії технологічного устатковання на основі ролей, означених стандартом IEC-62264 та відповідно фізичній моделі технологічного устатковання, означеної в IEC-61512  (див. рис. 22). Але ця модель в деякій мірі є розширеною, що, до речі, дозволяється цими стандартами.

рис.22 Ієрархічні рівні еталонної моделі архітектури Industrie 4.0

Виділені зеленим кольором елементи на рисунку 22 присутні серед ієрархічних рівнів RAMI 4.0. Поняття «Підприємства» та «Робочих центрів» (за деякими джерелами «Робочі вузли») відображені в тому ж функціональному сенсі, що й в IEC-62264. З метою застосування концепції Industrie 4.0 на більшій кількості виробничих секторів «модулі технологічного устатковання» та «модулі керування» були замінені поняттями «Станція» та «Пристрій керування», які використовуються в ISA-TR88.00.02-2015 «Machine and Unit States – An implementation example ISA88». Можливо використання саме такої ієрархії зумовлено розвитком на території Німеччини дискретного виробництва, а саме машинобудування.

У концепції Industrie 4.0 також виділяється ще кілька нових функціональних ієрархічних рівнів, які не представленні в класичній рольовій ієрархії устатковання IEC-62264/IEC-61512. До таких рівнів належать «Польовий пристрій» («Field device») та «Продукт» («Product») в нижній частині ієрархії, а також «Зовнішній світ» у верхній частині. Польовий пристрій може представляти собою інтелектуальний датчик або виконавчий механізм та самостійно приймати рішення в реальному часі. Нам наразі невідомі принципи розділення польових пристроїв від пристроїв керування.   

Нижче польового пристрою додано рівень «Продукту» («Product»), на який варто звернути особливу увагу. Наявність рівня продукту передбачає його функціонування як повноцінного компонента I4.0, тобто він відіграє таку ж важливу роль під час свого виробництва, як і устатковання, що бере участь у його виготовленні. По-перше, продукт в машинобудуванні це також актив (Asset), який після його виготовлення на іншому виробництві може стати на місце виробничого устатковання. По-друге, етапи виготовлення продукту є частиною його життєвого циклу, яким передують процеси його проектування, поставки на виробництво та інші кроки виготовлення. Це дає змогу взаємодіяти між виробничим устаткованням та компонентом продукту безпосередньо, оскільки вся необхідна інформація знаходиться в цифровому двійнику активу та накопичується на ньому ж. Таким чином, роль продукту забезпечує самодостатність усіх компонентів для прямої взаємодії між «речами» на виробництві, що і є однією з фундаментальних основ Індустрії 4.0.       Розглянемо це більш детально через призму різних етапів життєвого циклу продукту.

Відповідно до лівої горизонтальної вісі моделі, виділяються поняття типа та екземпляра. Існування продукту за концепцією Industrie 4.0 розпочинається із виникнення ідеї виготовлення продукту. З цього ж моменту виникає тип «продукту». З часом накопичується інформація, яка стосується розроблення продукту. Як тільки продукт переходить на стадію виробництва, то він стає конкретним екземпляром, тому що тип набуває конкретного фізичного відображення у реальному світі. Виділення продукту як окремого функціонального рівня полягає в тому, що «продукт» має здатність до взаємодії з іншими пристроями. Така функція може бути реалізована, наприклад, за допомогою використання QR-коду для ідентифікації продукту на будь-якій стадії його виробництва. Ідентифікувавши продукт, інші пристрої можуть отримати інформацію, яка стосується продукту або напівпродукту. Ця інформація може стосуватися або стадії виробництва, або ж надавати конкретні вказівки щодо того, що ж робити з напівпродуктом, наприклад,  яким кольором повинен бути зафарбований напівпродукт. Тобто, під час виробництва продукт може надавати дані іншим пристроям, а інші пристрої відповідно записувати дані у цифровий двійник продукту. Реалізація рівнів вертикальної осі може бути різноманітною. Наприклад, інтеграційний рівень для конкретного продукту може бути реалізований тільки засобами ідентифікації, а комунікаційний рівень – здатністю інших пристроїв, які взаємодіють з продуктом, до комунікації. Якщо продукт зрештою стає частиною устатковання у якійсь виробничій установці конкретного підприємства, він стає на інше місце у ієрархії рольової моделі, і його функції можуть відповідати, наприклад, рівню «Станції».

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

Але кожен із зацікавлених сторін у ланцюжку вартості використовує різні типи моделей транспортера (рис. 23):

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

Таким чином польовий пристрій представлений на різних підприємствах і має різне наповнення своїх цифрових двійників. Обмін інформацією між різними підприємствами може реалізовуватися за рахунок використання ще одного нового для класичної піраміди рівня – «Зовнішній світ» («Сonnected world»). Cтандарт IEC-62264 означує ієрархію технологічного устатковання лише в межах підприємства, тому на вищому рівні ієрархії RAMI 4.0 був доданий «Зовнішній світ» («Сonnected world»), який розширює межі окремого заводу/фабрики та передбачає обмін інформацією за межами конкретного підприємства.

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

Таким чином, IEC-62264 відіграє істотну роль у формуванні передових поглядів на високотехнологічне виробництво. Обізнаність про цей стандарт, досвід його впровадження значно сприятиме переходу від Індустрії 3.0 до гнучкого, високоефективного, орієнтованого на задоволення потреб клієнта світу Індустрії 4.0. На такому підприємстві обладнання, сировина і готові продукти спілкуються між собою і спільно керують виробництвом. Заготовки самостійно знаходять свій шлях на всіх етапах виробничого процесу, а невеликі фабрики зможуть самостійно об’єднуватися в єдину промислову систему для виконання конкретного замовлення.

Тому може виникнути питання на скільки результати цих нових ініціатив чи то Німеччини, США, Китаю можна назвати Новими? Чи це просто дуже влучне об’єднання кращих світових напрацювань? Залишається також багато питань щодо самої RAMI4.0, зокрема:

  • яке місце в RAMI4.0 займають модель персоналу, матеріалу чи сегментів, означених в IEC 62264?
  • як матеріал перетворюється в продукт, і взагалі в актив?
  • як передбачається робити планування виготовлення продукції?

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

Деякі деталі RAMI4.0 Ви можете дізнатися подивившись вебінар за цим посиланням.  

Основні положення стандарту МЕК 62264

Багато з непосвячених в стандарт людей вважають що стандарт покликаний для забезпечення прозорості інформаційного обміну між застосунками на протокольному рівні, як це наприклад зроблено в OPC для інтегрування технічних та програмних засобів. Такого роду задачі вирішуються іншими стандартами та специфікаціями, і це не є сьогодні проблемою. Стандарт МЕК 62264 розроблений для інтегрування систем керування підприємством та виробництвом на функціональному рівні. Тобто задача стандарту не в забезпеченні передачі даних, а у означенні сутностей (що саме) і набору їх атрибутів (як саме). Для виділення цих сутностей (об’єктів) та їх опису в стандарті проводять послідовну процедуру розбивання (декомпозиції) системи керування підприємством на частини (див.рис.2).

Перш за все необхідно визначитися з тим, а взагалі, яку саме необхідно надавати інформацію і кому вона потрібна. Для цього стандарт  МЕК 62264 виділяє дві області керування: домен підприємства а також домен керування виробничими операціями та технологічними процесами (MO&C Manufacturing Operations and Control).  Принципи, за якими відбуваються це розділення наведені в п.5 першої частини стандарту. Умовно, все що стосується зовнішньо-економічної діяльності підприємства, стратегічного та довгострокового планування ресурсами, тощо, відносяться до домену підприємства, а виробничі операції – до MO&C. Далі, в межах кожного домену виділяються взаємопов’язані функції, частина з яких представляють інтерес в іншому домені. Так, наприклад, функція керування та контролю за ресурсами основного виробництва MO&C може бути використана в функції прогнозування випуску продукції на рівні ERP. Ці функції взаємопов’язані інформаційними потоками, які і є складовою тих даних, якими обмінюються рівні. Цю інформацію категоризують і описують у вигляді об’єктних моделей.

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

Рисунок 2 – Структура моделей у стандарті

Згідно МЕК 62264 усе підприємство з точки зору функціонування включає кілька рівнів (рис. 3): бізнес-планування та логістики (L4), керування виробничими операціями (L3), керування порційним, неперервним або дискретним виробництвом (L2-L1), а також безпосередньо саме виробництво (L0). Рівні забезпечують різні функції та працюють у різних часових рамках.

Перша частина МЕК 62264 зосереджена саме на обміні інформацією між рівнем 4 та рівнем 3 функціональної ієрархічної моделі. Наприклад, з рівня 4 може надходити замовлення на рівень 3, а рівень 3 може надсилати інформацію про фактичну кількість виробленої продукції назад на рівень 4. Частина 1 МЕК 62264 визначає зміст таких та багатьох інших інформаційних потоків між діяльностями рівня керування виробничими операціями та підприємства. Стандартом означенні діяльності, що відповідають Рівню 4 та Рівню 3 функціональної ієрархії.

Рисунок 3 – Функціональна ієрархія виробничого підприємства

Перші дві частини стандарту МЕК 62264 означують обмін між L4 та L3, частини 3 та 4 описують внутрішню архітектуру MOM та призначені для стандартизації обміну підсистем рівня L3 між собою. 5-та частина показує один із способів реалізації таких обмінів. Слід відмітити що між L2 та L3 також є потреба в функціональній інтеграції, але стандартом МЕК 62264 ця взаємодія не описується. Тим не менше, є ряд стандартів, в область яких входить питання інтеграції MOM та АСКТП, зокрема в області порційного виробництва (ISA-88/IEC 61512), дискретного (PackML) та неперервного ( ISA-106). Наведені стандарти є «генетично» сумісні, так як мають спільні витоки та призначені для інтегрування усіх рівнів керування.

У загальному, усю діяльність підприємства можна звести в кількох груп функцій (рис.4). Частина функцій цих груп, що виділені на рисунку сірим в жовтому контурі, відносяться до домена виробництва.  «Виробництво» (Manufacturing) – це не тільки операції по виготовленню продукції (Production), які в українських стандартах відносяться до «основного виробництва». До виробничих входять також операції з запасами (Inventory), операції з контролю якості (Quality) та технічне обслуговування (Maintenance). Цими діяльностями традиційно займаються різні виробничі підрозділи і часто автоматизовані з використанням різних типів програмних засобів (EAM/ТОіР, LIMS, MES і т.п.). Стандарт об’єднав ці діяльності під один спільний знаменник  «виробничі операції», які користуються спільними моделями ресурсів, що дає змогу розглядати одні і ті самі сутності підприємства з різних точок зору. Тому він на концептуальному рівні легко поєднує скажімо устатковання з точки зору виробничників і обслуговуючого персоналу. Це дає змогу інтегрувати системи не тільки на різних рівнях ієрархії, але і на одному і тому ж рівні MOM.  Стандарт також дозволяє розширювати ці типи діяльностей.       

Рисунок 4 – Функціональна модель

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

  • устатковання (equipment), яке виконує певну роль у виготовленні продукції
  • матеріали (materials) з яких виготовляється продукт і який представляє готовий продукт
  • персонал (personnel), який також приймає участь у виробництві
  • активи (asset) – устатковання з точки зору балансу підприємства

Правильне означення усіх моделей є дуже важливим при керуванні. На рис.5 показаний приклад ієрархії устатковання. Цеха включають в себе робочі центри, що виконують роль виготовлення напівпродукту за вказаними операціями, які вони можуть виконувати з вказаної сировини у вказаний період часу. Саме робочі центри, як правило, є одиницями оперативного планування. При плануванні проявляється особливість типу виробництва (неперервне, дискретне і порційне). Робочі вузли є «робочими конячками» процесу виконання операцій. Ці три рівні устатковання складають основу виробництва і описуються в термінах продуктивності і потреб в ресурсах. Устатковання на вищих рівнях цікавить діяльності L4, на нижчих – L2. Для стандартів ISA-88/IEC 61512, PackML та  ISA-106 – модель устатковання є єдиною, що робить її застосовною для інтеграції між цими рівнями.

Рисунок 5 – Модель устатковання

Слід відмітити, що з точки зору виробничників на підприємстві використовується устатковання (рольова ієрархія), а з точки зору обслуговуючого персоналу (електрики, механіки, КВПіА) – це є активами, які на певний час знаходяться в ролі певного устатковання (рис.6).

Рисунок 6 – Приклад ієрархії фізичних активів пов’язаної з ієрархією технологічного устатковання на основі ролей

Для операцій рівня L4 більш цікавими є не моделі ресурсів, а їх об’єднання з точки зору виконання певної операції. Тому окрім базових ресурсів в стандарті є «сегменти», які по суті об’єднують об’єкти різного типу для означення можливостей (сегмент процесу) або потреб (сегмент продукту) (рис.7).

Рисунок 7 – Відношення сегмента продукту до сегмента процесу

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

  1. Інформація про календарне планування – інформація про запити на виконання робіт у межах однієї або декількох категорій діяльностей.
  2. Інформація про результати діяльностей (показники виробництва) – Інформація про роботу, виконану в межах однієї або декількох категорій діяльностей.
  3. Інформація про продуктивність – інформація про можливості виконувати роботу в межах однієї або декількох категорій діяльностей.
  4. Інформація про означення – Інформація про означення роботи, яка може бути виконана в межах однієї або декількох категорій діяльностей.
Рисунок 8 – Інформація про виробничі операції

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

Третя та четверта частини стандарту зосереджені на взаємодії між функціями керування на рівні MOM (рис.9). Кожний потік описаний у вигляді моделей UML та таблиць, що дає змогу інтегрувати функції програмних засобів рівня MOM.

Рисунок 9 – Модель діяльностей MOM

Детально з перекладом стандарту українською мовою, ви можете ознайомитися, перейшовши за посиланням.