Станово-орієнтоване керування (state based control) з каркасу

Це  фрагмент з опису каркасу, який постійно оновлюється https://www.slideshare.net/pupenasan/pac-framework-v1.

Станово-орієнтоване керування (state based control)

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

-          самі стани та необхідні дії (або окремі алгоритми) при їх активності,

-          та переходи (умови переходів) між ними.

Скінчені автомати можна описувати формулами, таблицями або діаграмами. Для практичного використання в програмуванні систем керування знайшли застосування таблиці (наприклад барабанний регулятор, DRUM-controller), спеціалізовані мови програмування (SFC, Grafcet). У текстових мовах (наприклад ST) такий автомат добре описується структурою CASE, де в якості змінної CASE є умовний номер стану (кроку). Формальних методів описів (моделей) доволі багато: мережі Петрі, скінчені автомати Мура, Мілі. Програмування на базі станів також називають станово-орієнтованим, автоматним, або case-програмуванням.       

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

Другий популярний приклад використання станів – це керування тривогами. У більшості випадків кожна тривога описуються класичним набором станів:

·         нормальний (Alarm OFF), коли немає тривоги за даною змінною;

·         непідтверджена активна тривога (Alarm ON not ACK), коли тривога виникла а оператор її ще не квітував;

·         підтверджена активна тривога (Alarm ON ACK), коли умова активності тривоги виконується, але оператор її підтвердив (квітував)

·         непідтверджена неактивна тривога (Alarm OFF not ACK), коли умова активації тривоги вже не виконується, але оператор ще не зробив квітування.   

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

 

 

       

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

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

-          положення: відкритий, закритий, відкривається, закривається, невизначений;

-          тривоги (кожна тривога описується своїм автоматом станів тривог): не закрився, не відкрився, довільний зсув, помилка датчиків положення;

-          блокування: заблокований, незаблокований;

-          режим роботи: ручний, автоматичний

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

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

Режими і стани означені в системі керування для різних об’єктів теж як правило взаємодіють між собою. Так, наприклад, для усієї установки можуть бути означені режими: ручний, автоматичний та наладки. При цьому зміна режиму в "наладки" може змінювати пріоритет режимів "ручний/автомат" та "заблоковано/незаблоковано".

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

-          положення: (5 значень);

-          тривоги (кожна тривога описується своїм автоматом станів тривог, тому потребується окрема змінна): не закрився (4 значення), не відкрився (4 значення), довільний зсув(4 значення), помилка датчиків положення (4 значення);

-          блокування (2 значення): заблокований, незаблокований;

-          режим роботи (2 значення): ручний, автоматичний

Оскільки системи керування передбачають наявність SCADA/HMI, стани кожної тривоги в програмі користувача ПЛК можна означити тільки 2 значеннями. Навіть при такій постановці, кількість змінних є дуже великою, а значень станів при цьому досить небагато (часто 2). Тому є сенс їх "упакувати" в одне слово статусу, біти якого будуть представляти стан/режим певного автомату. Такий підхід використовується, наприклад, при керуванні перетворювачами частоти та севроприводами по мережі (IEC 61800-7: профілі PROFIDRIVE, CIA402, CIP Motion, SERCOS). У даному каркасі усі біти станів об’єктів пакуються в одну змінну (поле структури) з назвою STA. Приклад такого упакування показаний в 1.4.

Створення лабораторного практикуму для Batch Control

Цього року я запланував створити і апробувати в навчальному процесі лабораторний практикум по Batch Control, відповідно до стандарту ISA-88. Якщо коротко – план в основному виконано. Хоч практикум не завершено до кінця (нижче напишу що саме і чому), в початковому плані цього і не було. Методичка доступна за посиланням  

Практикум базується на програмних середовищах: SCADA zenon та Unity PRO. Спочатку виникла ідея використати існуючий навчальний матеріал по Batch Control для zenon. Але вже з першої лабораторної роботи необхідно було повністю змінити тактику, так як оригінал базувався на використання SCADA без PLC а у багатьох випадках взагалі не мав конкретики виконання. Таким чином розроблений практикум зовсім відрізняється від початкового варіанту, запропонованого COPA DATA.   

Короткий зміст зроблених і апробованих лабораторних робіт.

Лабораторна №1. Інсталяція і підготовка робочого місця.

Враховуючи що починався курс дистанційною формою (3 перші лабораторні роботи), ця лабораторна робота була підготовчою. Інсталяція zenon інколи вимагає танців з бубнами протягом цілого дня. У деяких студентів танці не закінчувалися і на очній формі.

Лабораторна №2. Апарати та етапи. Основні ідеї керування майстер рецептами.

Основи роботи з Batch Control.

Ця лабораторна робота найпростіша, але дає початкові представлення про Batch-керування. Зв’язку з ПЛК немає, всі операції виконуються виключно в zenon. Вона дуже схожа на оригінальну версію від COPA DATA. У наступних лабораторних роботах схожості вже мало.

Лабораторна №3. Зв'язок рецептурного та апаратурного керування. Події та реакції на події. Команди та стани.

У даній лабораторній роботі вже відбувається зв'язок між SCADA і ПЛК. Для ПЛК підготовлений проект з імітатором об’єкта керування, як це прийнято для всіх наших курсів з програмування ПЛК та розробки проектів SCADA в НУХТ. Об’єкт начебто і простий - 2 бачка і система дозування. Але навіть для такого об’єкта необхідно вирішувати практично всі задачі, характерні для Batch control.    

Хоч зв'язок з ПЛК вже присутній, в даній лабораторній роботі вся логіка виконання етапів реалізовується тільки в zenon. ПЛК радше схожий на модуль віддаленого вводу/виводу. Тим не менше прослідковується зв'язок через команди та стани, які є також ключовими поняттями для розуміння Batch-керування.  

Лабораторна №4. Виконання процедур на рівні SCADA та ПЛК. Можливості рецептів в PFC. Режими виконання.

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

Лабораторна №5. Реалізація Модулів Керування (Control Module).

У початковому варіанті практикуму від zenon, як і у самому zenon взагалі нічого немає про Control Modules. Але це важлива частина стандарту, яка стосується не тільки Batch Control. Уцій лабораторній роботі основна увага приділяється саме цим елементам. Більша частина робіт проводиться в ПЛК, в SCADA тільки її інтерфейс на частина.

   

Лабораторна №6. Модель апаратурних об’єктів. Координаційне керування.

У даній лабораторній роботі вирисовується повна модель апаратурних об’єктів, виділяються агрегати (Equipment Modules), використовується координаційне керування для виділення та розподілення ресурсів. Ця лабораторна робота вийшла дуже великою, студенти її робили десь 4 пари.   

Лабораторна №7. Робота з майстер рецептами та керівними рецептами. Обробка винятків.

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

У лабораторній є також обробка винятків, дуже важлива частина Batch Control. Студенти її цього року не виконували, так як я добавив цей пункт пізніше. Це був один із каменів спотикання, бо в zenon ініціатором обробки винятків є SCADA, що значно ускладнило задачу. Для обробки аварійного переходу етапу ПЛК в стан "holding" прийшлося заходити через обробку помилки ПЛК.     

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

З самого початку я довго вагався чи брати zenon, чи орієнтуватися на інший модуль іншої платформи. Поверхове ознайомлення з функціональністю Batch Control в zenon не давали особливих сподівань щодо відповідності його ISA-88. Побачена картинка не співпадала з намальованою в моїй голові, що склалася в результаті опрацювання стандарту. Тому я довго шукав рішення у інших брендів. Однак довгі очікування і перемовини з представниками цих брендів не залишили мені вибору. Чесно кажучи, я не шкодую, але певні нюанси реалізації внесли свої корективи і відтягнули другу частину на невизначений термін. У деяких місцях zenon навіть перевершив мої сподівання.  

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

Лабораторна №8 (план). Планування виготовлення партій.

Лабораторна №9 (план). Формування звітів по партіям.

Сподіваюсь, що далі буде…  

Функціональний каркас для розробки програм для програмованих контролерів IEC 61131

Сьогодні допилив чорнову версію опису каркасу для ПЛК. Сам каркас (в першій робочій редакції) доробив ще на початку року для Unity PRO + Zenon. Крім того він ліг в основу з певними змінами в новий проект на TIA13. Деякі зміни були принциповими, але я їх не запам'ятав. Щоб не забути все інше вирішив добити хоча б якусь чорнову версію, бо не знаю коли наступного разу до нього доберуся.
Посилання та короткий опис тут http://asu.in.ua/viewtopic.php?f=7&t=1755
Ідея каркасу вже вітає давно, та і вона не нова. Тим не менше, реальні роботи почалися з замовлення "Саутком", яке я так і не доробив з причин "нахватався робіт більше, ніж міг виконати". Сподіваюся, що я їх не підвів, принаймні вони нічого з цього приводу не казали. Їм треба було дещо інше, але дуже близько до цього.
У той же час розробка програм для ГРС потребувала багато функціональності стосовно сервісних функцій. З кожною функцією шанхай ріс, і розробка каркасу для передбачення усіх можливих типових функцій - це була нагайна потреба. Плинний каркас добре ліг з однієї платформи (Юніті) на іншу (ТІА), практично копіпастом. Це суперперрезультат, враховуючи що реальної серйозної перевірки юнітьовський каркас не проходив. Головне не код, а ідеологія. Ті речі, за які переживав, що щось не врахував - практично усі заробили. Так, були ньюанси, але вони не порушують загальної працездатності основних приницпів.
 Оба базові рівні "канали" і "змінні" запрацювали. Рівень виконавчих механізмів сильно відрізнявся від демо-проекту (бачки) і реального (ГРС). У останньому використовуються крани, які в наших переробних процесах практично відсутні. Тому ці крани прийшлося допилювати серйозно в ТІАшному проекті. Вилізла необхідність додаткової змінної керування краном CMDPRG яка паралельно йде з CMDHMI, оскільки постійне забивання одного і того ж CMD з  програми не давало шансів ЛМІ-шному. Це характерно тільки для обєктів цього левела та вище.
Далі планую, як тільки з'явиться трохи часу (хоча він, собака, вже років десять не з'являється) описати каркас в ппт та і можливо зняти якесь відео. У будь якому випадку, буду намагатися зробити його нашим (кафедральним) корпоративним стандартом. Потрібно перетворювати написання базового рівня програм в трудовий процес а не експерементально-творчий. Тоді можна буде братися за велику об'єкти. Маю на це сподівання.          

Побував на I-й Всеукраїнській конференції «Цифрові комунікації у глобальному просторі. Змішана освіта».

Сьогодні був на I-й Всеукраїнській конференції «Цифрові комунікації у глобальному просторі. Змішана освіта». Програма з пошти:

Програма конференції:

10.00 – 11.00 – Зустріч гостей, реєстрація учасників

11.00 – 12.45 – Проведення першого пленарного засідання

• Співзасновник платформи масових відкритих онлайн-курсів «Prometheus» Іван Примаченко - Технологічна реформа навчання проти «трикутника смерті» української освіти

• Кандидат наук із соціальних комунікацій, доцент кафедри видавничої справи та редагування КПІ ім. І. Сікорського Радміла Сегол - Пілотний проект впровадження змішаного навчання: Досвід КПІ ім. І. Сікорського

• Кандидат технічних наук, доцент кафедри конструювання електронно-обчислювальної апаратури КПІ ім. І. Сікорського Євген Короткий - Досвід впровадження змішаного навчання в умовах скорочення аудиторного навантаження

12.45 – 13.30 – Кава-брейк

13.30 – 18.00 – Проведення другого пленарного засідання

• Кандидат юридичних наук, виконавчий директор Міждисциплінарного науково-освітнього центру протидії корупції в Україні НаУКМА Оксана Несторенко - Поєднання класичних та онлайн форм навчання в сфері протидії корупції

• Кандидат технічних наук, асистент кафедри комп’ютеризованих систем автоматики Національного університету «Львівська політехніка», Solution Architect компанії SoftServe Зеновій Верес - Використання змішаного навчання в рамках програми Інтернет речей

• Аспіранти факультету інформатики та обчислювальної техніки КПІ ім. І. Сікорського Артем Коротенко, Георгій Ісаченко - Особливості використання змішаного навчання у відкритих групах слухачів та в університетських групах

Відеозапис:

https://www.youtube.com/watch?v=sOZr_GMKWso

Поки я під важенням, запишу тут ці враження тезисно.

Я зрозумів, що термін "змішана освіта" доволі широкий, і відсоток і тип офлайн/онлайн може принципово відрізнятися.

Найбільш впроваджуваний курс в ВУЗи як основа змішаного навчання – це CS50. Результати показали ряд проблем (зокрема про це казав Зеновій Верес із Львівської Політехніки). Студенти не встигали все за один семестр, тому доганяли частину в іншому семестрі. Останній виступ (був доволі яскравим) від менторів змішаної версії цього ж курсу в Києві. Там теж не все так гладко.

На моє питання щодо англійської мови в Прометеусі, Примаченко відповів позитивно. Це радує.

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

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

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

Але саме вразило те, що на конференції мене впізнали колеги з НУХТ. Не те, що мене впізнали а я ні, вже якось починаю звикати. Я був у відвертому шоці, коли побачив, що їх там аж 6-ро (тих кого я побачив) і всі прийшли по добрій волі. НУХТ рулить! Усі дуже переймаються освітою і в мене знову виникла думка про формування НУХТівського колективу з таких людей, які хочуть щось рухати не для галочки а тому що … люблять свою роботу. Різноманітність компетенцій тут тільки на руку. Ще для мене було здивуванням, що ці люди вже давно (набагато раніше ніж я) приймають участь в таких заходах і знають усіх цих Примаченків, Молчановських і Романко персонально. Молодці, маю надію що будемо дружити і спільно працювати!