PACFramework > 1. Основні ідеї
Вимоги до функціональності каркасу сформовані у результаті аналізу вимог до функціонування АСКТП різного призначення, проблем їх розроблення, введення в дію та експлуатації. Серед них варто виділити наступні:
Нижче ці проблеми та ідеї їх вирішення розглядається більш детально.
Проблеми інтеграції з засобами рівня MES/MOM та іншими підсистемами перш за все лежать не в площині комунікаційного обміну (зараз ці проблеми вирішується, наприклад, шляхом використання стандартних протоколів, OPC, технологій EDDL, FDT/DTM, FDI і т.п) а у функціональному представленні сутностей (об’єктів) нижнього рівня для верхнього та взаємної координації засобів одного рівня. У багатьох існуючих рішеннях на верхній рівень АСКТП (SCADA/HMI) передається "сирі" дані, які попередньо необхідно оброблювати. У зв’язку з недостатньою кількістю інформації (наприклад про дані що не відображаються) та порівняно невеликою швидкістю обміну між контролерами та SCADA/HMI, деякі важливі KPI (Key performance indicators, ключові показники ефективності) та статистичні чи агреговані дані на 2-му рівні, які потребуються 3-му (MES/MOM) важко обрахувати, або їх значення не може бути забезпечено з заданою точністю.
Додатковою проблемою також є відсутність (як правило) інформації про достовірність даних. Так, наприклад, ігнорується відмова каналу ПЛК при відображенні на SCADA/HMI та передачі недостовірних даних на верхні рівні MES/MOM.
У той же час, обчислювальні ресурси засобів керування, зокрема промислових контролерів, значно виросли. Тому попередню обробку даних варто робити безпосередньо в засобах автоматизації рівня керування процесом чи машиною (та навіть польового рівня). У запропонованій концепції пропонується використовувати ідеї та модель ієрархії обладнання зі стандартів ISA-88/95/106 та RAMI4.0 (німецька референтна модель Industry 4.0), відповідно до яких, інформація по кожному обладнанню представляється своїм набором структур в пристрої, що керує/контролює цим обладнанням. Це дає можливість робити розрахунки саме за місцем проведення вимірювань та керування конкретним обладнанням а також робить систему більш гнучкою стосовно варіантів функціонального розподілення. Використовується принцип функціонального розподілення (IEC TR 62390), який передбачає розділення всього застосунку (Application) на функціональні блоки і може бути використаний в різних парадигмах керування (централізована або децентралізована IEC 61131 та розподілена IEC 61499). Прикладом такого підходу є використання структур та функцій, що відповідають за керування двигуном, безпосередньо в системах управління електроприводами (PDS, частотні перетворювачі) за профілями CiA402, ProfiDrive, тощо.
Для реалізації ідей, покладених у основу вищезазначених стандартів інтеграції необхідна підтримка їх на рівні програмно-технічних засобів рівня контролерів та нижче. Як показує практика, підтримка наведеного в стандартах функціональності в конкретних засобах SCADA/HMI сильно відрізняється. Це приводить до того, що більшу частину функціональності приходиться реалізовувати самостійно, що найпростіше і гнучкіше зробити в самому програмованому контролері, якщо використовується парадигма IEC 61131 або гібридна.
Сучасні дослідження в області побудови та експлуатації людино-машинних інтерфейсів в АСКТП показали необхідність формування контексту для кращої ситуаційної обізнаності. Іншими словами, відображення числового значення часто не супроводжується його контекстом (місцезнаходження в межах норми, порівняння з середнім і т.п.) що погано впливає на спостережність об’єкта.
Супроводження контекстною інформацією вимагає використання структурованих а не "плоских" змінних, які би містили усю необхідну у будь-якому місці інформацію про технологічну змінну. Для прикладу – це стан технологічного параметру (наявність тривог різного рівня, достовірність значення, стан обслуговування і т.п), межі норми, мінімум/максимум величини і т.п. Контекст може використовуватися як на засобах ЛМІ, так і в функціях обробки програм контролера.
У той же час, є велика кількість невикористаних ресурсів пристроїв усієї системи. Стрімке впровадження перетворювачів частоти та інших інтелектуальних засобів в АСКТП разом з тотальним розповсюдженням промислових мереж (польових шин) дає можливість отримувати велику кількість додаткових даних про стан процесу без додаткових витрат. Це дає можливість аналізувати проходження процесу на більш високому рівні.
Наприклад, з перетворювача частоти можна отримати інформацію в реальному часі про споживану потужність, момент, напруги та струми в даний час, та розраховувати KPI, за яким можна судити про його ефективність роботи. Незначні несправності, як правило, не проявляються в процесі роботи, однак збільшують енерговитрати та, зрештою, все одно приводять до нештатних зупинок. Розрахунок KPI та порівняння його з нормою дає можливість звернути увагу на несправність ще до аварійної зупинки.
Можливе збільшення ситуаційної обізнаності використання порівняння з еталонною моделлю. Наприклад, баланс за рівнем в ємності та витратами, або порівняння тиску з напірною характеристикою насосу при вказаних обертах. При інтеграції пристрою керування з хмарними сервісами, контекст може формуватися на базі хмарних обчислень, а ті в свою чергу, можуть використовувати існуючий контекст змінної.
Наведені вище можливості можна порівняно легко реалізувати при використання принципів об’єктно-орієнтованого програмування та розробки загальної гнучкої концепції.
Проблеми невдалої розробки тривогової підсистеми та способи боротьби з ними добре описані в ANSI/ISA–18.2. Зокрема найбільш типовими є затоплення повідомленнями (alarm flooding) викликане несправним обладнанням або невірними налаштуваннями тривогової підсистеми. Реалізація функцій тривогової підсистеми сильно залежить від можливостей SCADA/HMI. Так, типовим невикористаними можливостями пакета SCADA/HMI (або відсутністю такої можливості взагалі) є тимчасове виведення тривоги з обслуговування. Це нерідко приводить до нівелювання функцій підсистеми тривог взагалі. Можливість виведення каналу з експлуатації значно б спростило обслуговування системи, так як несправний канал не приводив би до обробки тривог. Крім того, факт виведення каналу може оброблятися в інших частинах програми, наприклад обробка керування клапаном з кінцевим вимикачем, який тимчасово виведений з експлуатації.
Додатковою проблемою є узгодження підсистеми тривог SCADA/HMI та керування світлозвуковою сигналізацією. Враховуючи велику залежність реалізації тривогової підсистеми від можливостей SCADA/HMI є сенс винести більшість функцій обробки тривог на рівень контролера, в якому як правило більше можливостей щодо реалізації алгоритмів. Додатковим аргументом до цього є необхідність використання функцій блокування на рівні ПЛК та означення додаткового стану поведінки логіки керування.
Для періодичних багато-рецептурних виробництв, характерне простоювання обладнання між виробничими періодами та зміна вимог до проходження процесу в залежності від рецепту. Тобто класичний підхід для АСКТП неперервних процесів, в якому формування уставок для технологічних тривог проводиться під час розробки ПЗ (та навіть в процесі налаштування) не підходить для даного випадку. Наприклад, контроль значення температури на виході теплообмінника повинен проводитися тільки під час проходження процесу нагрівання/охолодження продукту (не під час простою чи мийки), а аварійні та попереджувальні значення залежать від типу продукту. Для вирішення цієї задачі, підсистема тривог повинна адаптуватися під вимоги в залежності від типу продукту, стану обладнання та процесу, що у більшості випадків простіше зробити на рівні контролеру, аніж SCADA/HMI. Враховуючи, що для керування періодичними виробництвами розроблений та неодноразово перевірений стандарт ISA-88, є сенс базуватися на його базисах.
"Плоский" (неструктурований) простір змінних, які використовувалися в ПЛК ще 20-му столітті, нерідко є базою для програмного забезпечення і по сьогодні, хоч сучасні засоби дають можливість використовувати елементи об’єктно-орієнтованого програмування. "Плоскі" змінні вміщують тільки значення технологічного параметру, однак для правильного керування процесом необхідно мати весь його контекст. Як зазначалося вище, дуже важливою властивістю технологічної змінної є достовірність даних, яка визначається рядом показників, серед яких є відмова каналу. Сучасні ПЛК дають доволі багато можливостей програмної діагностики, тим не менше, значні затрати (не передбачені на початку життєвого циклу) на написання програми додаткової обробки достовірності в функціях керування у більшості випадків приводять до нехтування цими можливостями і відсутністю програмної діагностики взагалі. Це не стосується АСКТП для функціонально-небезпечних процесів.
Достовірність можна відобразити в статусі кожного каналу та змінної, яка пов’язана з цим каналом. Передаючи статус достовірності разом зі значенням в усі частини АСКТП, додатково до процесних станів можна ввести стан "недостовірності" (наприклад відмова каналу), в якому можна прописати окрему логіку обробки. Це цілком відповідає усім сучасним реалізаціям автомату станів в пристроях автоматизації процесів. Слід зазначити, що обробка недостовірності проводиться в тих самих програмних блоках, де обробляється технологічна змінна. Наприклад, якщо використовується функція стабілізаційного регулювання температури на виході теплообмінника, то при відмові каналу її значення може перейти в крайні положення, або (що ще гірше) залишитися без змін. При наявності властивості недостовірності, буде згенерована окрема тривога саме для цього параметру (наприклад, "Відмова каналу вимірювання температури теплообмінника") а функція стабілізації переведе клапани в безпечний для цього випадку стан. Слід відмітити, що така структура програми вимагає стано-орієнтованого підходу навіть для функцій регулювання.
Відсутність контекстної діагностики процесу, обладнання та системи керування приводить до значної затрати часу на вияв факту та причини несправності. Наприклад, при обриві вхідного аналогового каналу може формуватися тривога надмірно низького рівня. При цьому елементарний програмний аналіз міг би дати результат, що канал є недостовірним. Треба відмітити, що такий рівень часто присутній в сучасних АСКТП. Тим не менше, несправність каналу може бути викликана рядом причин: наприклад несправністю вимірювального каналу до ПЛК, чи несправністю електроніки каналу в самому ПЛК. Сучасні ПЛК, надають можливість глибокої програмної діагностики каналів, з виявленням причин несправності. Ця додаткова інформація дає можливість набагато швидше усунути несправність.
Іншою проблемою є усунення дефектних частин ПЛК та заміна технічних засобів з одними характеристиками на інші. Наявність в складі підприємства запасних модулів контролерів, як правило, характерна тільки для найбільш критичних позицій. Іншими словами, для усунення несправності інколи необхідно очікувати новий модуль протягом кількох місяців, що недопустимо для всіх процесів. Враховуючи, що часто виходять з ладу канали (або групи каналів) а не весь модуль, а при цьому в ПЛК є наявні вільні (невикористані) канали такого ж типу, доречним би було надати можливість "перекидання каналів". Зміна технічних засобів нерідко потребує зміни діапазону вимірювання, що також необхідно передбачити в АСКТП.
При налагодженні системи виникають ряд труднощів, пов’язаних з реалізацією АСКТП. Налагодження програми та системи в цілому потребують забезпечення виконання наступних вимог:
1) необхідність зміни стану вхідної змінної незалежно від значення фізичного каналу для перевірки роботи алгоритму;
2) необхідність швидкої реакції імітованих сигналів датчиків при перевірці роботи алгоритму без наявного процесу (наприклад датчики кінцевого положення клапанів, при їх відкритті);
3) необхідність зміни значення вихідного каналу, незалежно від стану програми при перевірці вихідних каналів.
Для виконання перших 2-х вимог за класичного підходу до налагодження програми (покрокова перевірка виконання дій, оформлених в таблиці, тощо) потребується велика кількість рутинної роботи, що виконується постійно. У світі комп’ютерного програмування використовують для цього програмні тести, однак в АСКТП ці механізми недостатньо пророблені. Третя вимога потребує участь розробника ПЗ для контролерів для виконання операцій форсування, зміни значення невикористаного каналу, тощо. Допомогти в цьому може програмна імітація та форсування, які повинні бути доступні з засобів ЛМІ.
Нерідко навчанню персоналу взагалі не приділяється увага. Проблема пов’язана з необхідністю навчання роботи персоналу безпосередньо на реальному об’єкті. При цьому, більшість ситуацій неможливо змоделювати вручну, так як вони цілком залежать від проходження реального процесу. Критичні ситуації змоделювати на реальному об’єкті взагалі не дозволяється.
Як варіант подолання цих обмежень є використання імітаційного моделювання безпосередньо в програмі контролеру, що дасть можливість також простіше робити налагодження програмної частини системи без наявного об’єкту. Крім того, в складі програмних пакетів для розробки ПЗ контролерів великої та середньої складності як правило є імітатори ПЛК, що дає можливість "розгорнути" систему управління у будь якому місці.
При створенні великих проектів потребується велика кількість рутинної роботи. Все ще більше ускладнюється, коли процес розроблення ПЗ виконується паралельно з процесами проектування, що приводить до постійних змін у вихідних даних для ПЗ. У результаті програми потрібно постійно змінювати в кількох місцях що приводить до помилок, пов’язаних з людським фактором.
Виділення повторюваних частин та їх правила впровадження в прикладну програму значно прискорює процес розроблення та зменшує кількість помилок. Зміна алгоритму типового об’єкту за такої побудови коду приводить до зміни в одному місці.
Крім того, враховуючи ітеративний процес розроблення, постійну зміну вимог та початкових даних, варто автоматизувати процеси розроблення. Першим кроком до цього є стандартизація представлення програмних об’єктів, другим - створення програмного забезпечення для автоматизації перетворення вихідних даних проекту (перелік технологічних змінних, ВМ, тощо) в код програми.