Практичні рекомендації до реалізації елементів стандарту 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. Модулі керування

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

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