За моїми спостереженнями, більшість розумних фахівців АСУ, які працюють зі SCADA, проходять кілька стадій «емоційного зростання»: освоєння якоїсь SCADA, пошук чогось кращого, ідеї і спроби написання свого варіанту, вироблення філософського ставлення до проблеми і використання одного з існуючих продуктів.
Так, бувають винятки. Наприклад, зустрічаються сильно захоплені і наполегливі ентузіасти, які створюють щось працююче, але картини вони не змінюють абсолютно.
Спробуємо розібратися, чому так відбувається і чи може бути вихід з цього порочного кола.
Примітка: подальші міркування стосуватимуться переважно комерційних продуктів, але багато в чому справедливі і для проектів з відкритим кодом, про які буде сказано окремо.
У першому наближенні процес роботи зі SCADA-системою зводиться до кількох дій: вибір параметрів обміну даними з ПЛК, розробка мнемосхем у спеціальному редакторі, налаштування логування подій і станів параметрів. Для забезпечення складної поведінки графічних елементів мнемосхем і нескладних математичних розрахунків використовується написання скриптів або взагалі передбачається, що достатньо засобів найпростішої анімації, налаштовуваної в редакторі.
Такий підхід багато в чому себе виправдовує - легко навчитися, можна швидко реалізувати нескладні проекти. За великим рахунком, можна навіть не мати мінімальних знань про програмування для початку роботи.
Сьогодні існує досить велика кількість SCADA-систем, що розрізняються за своїми можливостями, вартістю, зручністю розробки тощо. Здавалося б, вибирай відповідний варіант і починай творити добре, світле, вічне... Але тут-то і з'ясовується, що все не так просто.
- Як тільки виникає необхідність у створенні великого проекту з великою кількістю елементів на мнемосхемах або потреба в скільки-небудь помітних обсягах обчислень, відразу кидається в очі дуже низька швидкість роботи. Особливо комічно виглядає ситуація, коли доводиться перекладати розрахунки на ПЛК, хоча його швидкодія непорівнянно нижче сучасних ПК. Найчастіше і про організацію виконання декількох потоків також можна забути.
- Спроба зробити що-небудь, не передбачене розробниками SCADA, легко виливається в дуже нетривіальні рішення з величезними трудовитратами.
- Закритість внутрішніх механізмів і неповна документація. Наприклад, спробуйте знайти для комерційних SCADA повноцінний опис форматів зберігання даних і структури БД.
- Багато авторів статей про сучасні стратегії розробки ПЗ негативно відгукуються про поширений підхід, коли створенню нового функціоналу приділяється незрівнянно більша увага, ніж оптимізації та тестуванню коду. На жаль, це часто спостерігається і в світі SCADA. Часом у процесі розробки доводиться більше часу витратити на обходження недокументованої поведінки системи, ніж власне на розробку. Адже це промислові системи з підвищеними вимогами до надійності.
- Висока вартість - при створенні великого промислового об'єкта вартістю в кілька мільйонів виділити 5-10 тис. євро проблема не велика, але якщо мова ведеться про відносно недороге обладнання, що випускається великим тиражем, витрати навіть в 200 євро на один екземпляр можуть виявитися недозволеною розкішшю.
Декілька слів про системи з відкритим кодом. При щирій повазі до розробників мені здається, що ідея, незважаючи на всю привабливість, практично не реалізується. Причина - величезні трудовитрати за відсутності помітної спільноти. Занадто мало людей, зацікавлених у подібному продукті і при цьому здатних писати якісний код об'єктно-орієнтованою мовою, готових витрачати свій вільний час на такий проект. Власне, усвідомлення обсягів роботи для створення чогось, здатного конкурувати з існуючими комерційними продуктами, і змушує опускати руки.
Тепер, отримавши уявлення про труднощі, спробуємо сформулювати вимоги до ідеальної SCADA і подивимося, чи можна вирішити проблему, якщо злегка вийти за рамки традиційної парадигми.
- Необхідна висока швидкість роботи. Це означає, що не повинно бути ніяких інтерпретаторів, на виході треба отримати виконуваний машинний код.
- Можливість легко і без істотних ризиків змінювати поведінку існуючих компонентів або додавати свої.
- Прозорість форматів зберігання параметрів та історичних даних. Наприклад, необхідність зробити специфічну вибірку з архівів для побудови звітів не повинна виливатися в тривалий реверсинжиніринг інструментів, що входять до складу SCADA.
- Простота і швидкість розробки. Необхідно звести до мінімуму написання коду і по максимуму використовувати візуальне програмування. Якщо для роботи над проектом з автоматизації буде необхідно витрачати помітно великі зусилля порівняно з комерційними SCADA, то кому це все буде треба?
- Зручне і сучасне середовище розробки (IDE). Необхідні звичні інструменти будь-якого програміста: автодополнення коду, контроль версій тощо.
- Низька вартість стороннього ПЗ, а в ідеалі безкоштовність і відкритість вихідного коду.
- Всі ці вимоги необхідно реалізувати при мінімально можливих витратах зусиль декількох розробників.
Звідси напрошується рішення - треба взяти існуюче гарне середовище для візуального програмування і створити до нього бібліотеку компонентів, заточених під специфічні завдання SCADA-систем. Розмірковуючи подібним чином я зупинив свій вибір на Qt. Тут і маса готових компонентів, і відмінна IDE, і величезна спільнота розробників.
Коли я вперше познайомився з Qt, то був просто вражений внутрішньою логічністю і багатством цієї бібліотеки. Як тільки виникає завдання зробити що-небудь, дуже часто з'ясовується, що це вже практично реалізовано в Qt і треба просто адаптувати під свої потреби.
Коли завдання правильно сформульоване, залишається його просто реалізувати, що я і почав робити деякий час тому. До поточного моменту вдалося реалізувати мінімальний джентльменський набір компонентів.
Створений набір можна умовно поділити на кілька груп.
- Компоненти, призначені для забезпечення обміну даними з ПЛК
- Система міток. Фактично, деякий буфер між драйверами та іншими частинами бібліотеки, що забезпечує доступ до даних з різних компонентів програми.
- Драйвер-клієнт для OPC DA2. На мою думку, на даний момент це найпопулярніший спосіб обміну даними з ПЛК і досить складно знайти хоч скільки-небудь поширений пристрій без OPC-сервера.
- Забезпечення запису та доступу до архівної інформації
- Система аварійних повідомлень.
- Журнали технологічних параметрів.
- Набір графічних компонентів (widgets).
- Побудова графіків і трендів з журналів технологічних параметрів. Тут все класично - вибір і налаштування відображення накопичених даних.
- Робота з аварійними повідомленнями - виведення активних повідомлень, підтвердження оператором (квитування), доступ до архівної інформації.
- Відображення різних елементів мнемосхем. Як показали опитування, у більшості компаній використовують власні іконки для показу станів технологічного обладнання. З цієї причини було створено компонент, що дозволяє виводити графічні зображення (в тому числі і з ефектом миготіння) залежно від значень тегів.
- Побудова великих анімованих схем трубопроводів. Готових аналогів мені не доводилося зустрічати в жодній SCADA, адже потреба очевидна - спробуйте прокласти маршрут у розгалуженій системі з двома - трьома сотнями засувок.
- Набір компонентів для полегшення створення елементів користувача.
Звичайно, належить пройти ще чималий шлях, але вже зараз проглядається кілька можливих напрямків для застосування, крім власне всіх видів класичних завдань промислової автоматизації:
- Створення утиліт для вирішення побічних завдань у вже існуючих системах. Так наприклад, мені довелося написати аналог Matrikon OPC Data Manager з більш багатим функціоналом, витративши на це всього близько чотирьох годин і заощадивши досить значні кошти.
- Розробка додатків для роботи з науковими приладами.
- Системи «розумний будинок».
Якось непомітно для мене, моє хобі перетворилося на щось більше, що викликає інтерес у інших людей. З'явилася думка перетворити цю творчість на стартап, але поки все впирається в нестачу людей, готових розділити зі мною цю роботу. Якщо у Вас є бажання взяти участь у розвитку стартапу, стати біля витоків нової компанії або спробувати себе в ролі співзасновника, напишіть мені в личку.
Трохи більше інформації можна знайти на сторінці у Facebook.
Також буду дуже вдячний за конструктивну критику і нові ідеї.
І насамкінець, невелике відео FAQ:
