Індустріальний ІоТ у моніторингу критичної інфраструктури

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Вітаю, спільното. Я — Євген Смертенко, Head of Big Data, Industrial IoT та AI Solutions у компанії MODUS X. Маю понад десять років досвіду роботи у науково-дослідних підрозділах Міністерства оборони України, в Інституті проблем реєстрації інформації НАН України та в НДІ радіолокаційних систем «Квант-Радіолокація», де спеціалізувався на розробці систем обробки радіолокаційної інформації для протиповітряної оборони.

Згодом продовжив кар’єру у комерційному ІТ-секторі, реалізовуючи проєкти зі збору, обробки та моделювання для ринків Ізраїлю, США та Європи, зокрема у компаніях ClickmeIn, Ciklum та Luxoft.

Після початку повномасштабного вторгнення долучився до волонтерського проєкту зі створення акустичних детекторів для виявлення дронів і ракет на малих висотах — по суті, «вух» для ППО, які «чують», коли радари не бачать.

Ця стаття — за мотивами моєї доповіді на конференції DOU Day 2025, де я поділився прикладними кейсами впровадження технологій промислового інтернету речей (IIoT) у критичну інфраструктуру. Матеріал буде корисним для фахівців, які працюють на перетині інженерії, аналітики та ІТ і шукають практичні підходи до впровадження сучасних технологій — від edge computing і SCADA-систем до моделей машинного навчання у сферах енергетики та моніторингу виробничого обладнання.


IIoT (Industrial Internet of Things) — це наш інструмент реального контролю над критичною інфраструктурою. В енергетиці ми щодня маємо справу з обладнанням, яке працює під навантаженням, часто — в умовах нестабільного середовища. Завдяки сенсорам і аналітичним платформам ми бачимо, що відбувається прямо зараз, від температури турбіни до стану генератора. Це дозволяє реагувати оперативно — ще до того, як проблема стане аварією.

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

У MODUS X (група компаній ДТЕК) ми займаємося створенням і впровадженням рішень, які роблять енергетику більш адаптивною та економічно ефективною. Досвід показує: якщо система справді розуміє дані, вона може не лише запобігати помилкам, а й підказувати, як уникати зайвих витрат. Про один із таких кейсів — далі.

Енергетична система — основа критичної інфраструктури України

Після масованих атак на енергетичну інфраструктуру ніхто в Україні не ставить під сумнів: енергетика — це основа безпеки та стійкості країни. Без генерації, передавання і злагодженої роботи мереж нічого не працює — ані лікарні, ані водопостачання, ані мобільний зв’язок.

Енергосистема — це складна структура. У нас є атомні, теплові, гідро-, сонячні та вітрові станції. Особливо важливою залишається теплова генерація — саме вона бере на себе пікові навантаження, коли споживання зростає ввечері чи зранку. А ще — коли система втрачає частину потужностей через обстріли. Щоб така система працювала без збоїв, потрібен постійний контроль. Не тільки з допомогою людей, а й через автоматизовані системи, які бачать більше й масштабніше. Саме тому ми й використовуємо IIoT у критичній інфраструктурі.

Один із прикладів — Курахівська ТЕС. Це станція, яку запустили ще в 1941 році, а в 2000-х модернізували: встановили SCADA-систему Emerson, а на кожному з чотирьох блоків — по кілька тисяч сенсорів. Загалом понад 20 тисяч точок збирання даних. Щосекунди — нові показники: тиск, температура, вібрації, витрати. У пік — до 45 ГБ даних на день.

Але зібрати дані — ще не означає грамотно їх використати. Ми створили дві системи: одна — прогнозує відмови, друга — підказує, як працювати економніше. Наприклад, зменшити витрати палива без шкоди для стабільності. Результат — до 1,5% економії вугілля та менше штрафів за небаланси.

На жаль, у 2024 році КуТЕС була зруйнована. Але досвід, який ми там отримали, залишився. І ми використовуємо його для нових проєктів.

Що таке Промисловий Інтернет Речей

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

Усе починається з сенсорів. Вони зчитують, як працює техніка, й миттєво передають інформацію. Наступний елемент системи — протоколи зв’язку, наприклад, OPC-UA або MQTT, які передають ці дані до системи управління без затримок.

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

Ми створили IIoT-платформу, яка працює в складних умовах. Вона включає SCADA-системи в ізольованій технологічній мережі, демілітаризовану зону (DMZ), OPC Gateway від Kepware для уніфікації протоколів, Edge Devices для периферійних обчислень та платформу аналізу даних із підсистемою Fleet Manager для управління девайсами.

З мого досвіду, що простіше рішення, то воно надійніше. Саме тому ми обрали OPC Gateway від Kepware, щоб уникнути складних систем із перемиканням між провайдерами. Ми використовуємо хмарні сервіси AWS чи Azure, а за потреби — локальні рішення (on-premise). Це дозволяє обробляти дані, створювати звіти, дашборди та моделі машинного навчання для Data Exploration, Data Science і операційної аналітики.

Архітектурні підходи: Data Lake та Lakehouse

Для обробки величезних обсягів даних, які генеруються в IIoT, використовуємо архітектури Data Lake та Lakehouse.

Data Lake — це централізоване сховище, яке зберігає дані в їхньому первинному вигляді: неструктуровані, слабоструктуровані чи структуровані дані. Воно підтримує різноманітні формати, від бінарних файлів і аудіо до CSV, JSON, XML чи колонно-орієнтованих форматів Parquet чи ORC.

Основні переваги Data Lake:

  • Масштабованість. Дозволяє зберігати й обробляти об’єми даних, що зростають, без потреби в складній перебудові інфраструктури.
  • Гнучкість. Ви можете реалізувати будь-який архітектурний підхід. Це може бути Schema on Read, Schema on Write, ELT, Lambda-архітектура, Kappa-архітектура. Все залежить від задач, які виконуються, і від скіл-сетів команди, яка їх використовує.
  • Економія. Зазвичай Data Lake — більш економічне рішення в порівнянні з традиційним сховищем, що дозволяє зменшити витрати на зберігання та управління даними.

Lakehouse — це еволюція Data Lake, яка поєднує його переваги з можливостями Data Warehouse. Якщо Data Lake забезпечує гнучкість, масштабованість і економічність, то Data Warehouse пропонує структурованість, транзакційність (не плутати з OLTP-системами) і аналітичну оптимізацію. На практиці Lakehouse реалізується через формати Delta Lake, Apache Iceberg чи Apache Hudi у поєднанні з платформами Apache Spark чи Databricks.

Які ж ключові переваги? Lakehouse дозволяє робити снапшоти, забезпечує консистентність даних при паралельному доступі, підтримує операції Merge, Update, Delete і навіть Time Travel для доступу до даних на певну дату.

Ми використовуємо Lakehouse для batch-обробки даних, формуючи Parquet-файли на Edge Devices, щоб економити на трафіку. Дані поділяються на raw, master, pre-processed та архівні, а аналітичні сендбокси підтримують задачі Data Exploration, Data Science та операційної аналітики.

Практичні кейси впровадження IIoT

Курахівська ТЕС

На КуТЕС ми розробили три моделі машинного навчання для кожного енергоблоку: оцінка ймовірності позаштатної ситуації, типізація несправності (наприклад, димососи чи бункери пилу) та прогнозування часу до поломки. Це було непросто: спочатку оператори скептично ставилися до рекомендацій ML, але коли побачили, що система реально передбачає збої, почали довіряти.

У 2020 році система пройшла промислово-дослідну експлуатацію, а з 2021 по березень 2022 року була в промисловій експлуатації. Рекомендаційна система оптимізувала режими генерації, зменшивши витрати вугілля на 1-1,5%, що на таких обсягах дало значну економію. Вона також допомогла планувати генерацію на наступну добу та зменшити штрафи за небаланси на енергоринку.

Нагадаю, що ми приєдналися до енергосистеми Євросоюзу. Для цього нам треба було перейти до нових умов енергоринку. Що це означає? Кожна електростанція, неважливо, це атомна чи сонячна електростанція, кожну годину подають комітмент на обсягі генерації на 2 години вперед, щоб оператори НЕК «Укренерго» могли балансувати енергосистему в реальному часі. І якщо станція не підтверджує цей комітмент, генеручи більше або менше, тоді накладаються штрафи. Ця система дозволила зменшити штрафи та витрати на ліквідацію наслідків нештатних і аварійних ситуацій. Через війну в березні 2022 року система була призупинена. Зараз станції не існує. Але все обладнання, яке можна було, демонтували та вивезли. Тепер воно слугує як резервне на інших станціях.

Ми почали етап промислово-дослідної експлуатації також на Запорізький ТЕС в кінці 2021 року, але майже нічого не встигли — ЗаТЕС була окупована майже одразу на початку вторгнення.

Відновлювальні джерела енергії

До 2022 року у власності ДТЕК було сім об’єктів відновлювальних джерел енергії (ВДЕ). На жаль, чотири ВЕС (по 100 МВт кожна) опинилися на окупованій території: дві від General Electric і дві від Vestas (Нідерланди).

Одна з них, Тилігульська ВЕС, потужністю 6 МВт на турбіну, мала стати однією з найбільших у Європі. З початком повномасштабного вторгнення Vestas організувала віддалене керування проєктом. Це дозволило ввести в експлуатацію 19 турбін, які працюють і нині.

Для решти об’єктів ми створили аналітичну платформу Watch Tower Analytics. Edge Devices через демілітаризовану зону (DMZ) збирали дані про поточну потужність, умови генерації, коефіцієнт готовності та інші показники, забезпечуючи ситуаційну обізнаність у реальному часі. Платформа також дозволяє аналізувати небаланси, оцінюючи якість прогнозів генерації від зовнішніх компаній.

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

Моніторинг шахтного обладнання

Для прохідницьких комбайнів компанії Corum ми розробили систему моніторингу, яка замінила ручне збирання даних через SD-карти в шахтах. Система забезпечує ситуаційну обізнаність у реальному часі, дозволяючи бізнесу бачити, чому комбайн зупинився, й аналізувати дані для предиктивного обслуговування обладнання. Наразі система перебуває на стадії промислово-дослідної експлуатації.

Машинне навчання в IIoT

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

У наших проєктах застосовуються регресійний аналіз, дерева рішень, кластеризація та класифікація з мінімальною ймовірністю 0,93. Наприклад, на КуТЕС моделі прогнозували несправності й оптимізували режими роботи, а для ВДЕ — аналізували небаланси та прогнозували генерацію.

Операційна аналітика

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

За Шенноном, дані несуть інформацію, якщо допомагають зменшити нашу невизначеність, тобто ентропію. Тому дані, які не знижують невизначеність, можна вважати надлишковими — їхнє збирання лише витрачає ресурси. Наприклад, на КуТЕС операційна аналітика допомагала операторам бачити аномалії в роботі димососів і одразу коригувати режими. Для ВДЕ було дві задачі: онлайн моніторинг обладнання та аналіз небалансів раз на добу, тиждень тощо в реальному часі, щоб точніше прогнозувати комітменти на енергоринку.

Висновки

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

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

👍ПодобаєтьсяСподобалось11
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Велика повага автору. Дякую за статтю. Сам мав 4 роки досвід МL/DSP for Industrial 4.0 (SKF, Halliburton, LaFarge, Ternium, etc) . Працював з моделями для 100+ сенсорів, знаю шо це за звір. Прогнозування TimeToFailure для індастріал домейну — то є топ в принципі. Не знав що в Україні такі круті штуки робили.

Прогнозування TimeToFailure для індастріал домейну — то є топ в принципі

наскільки пригадую тему «час наробки до відмови» ще в радянському технікумі проходили, а зараз це «топ в принципи» O tempora, o mores!

Дякую за коментар!
Все залежить від команди інженерів та готовності бізнесу до подібних впроваджень! А ще — від того, наскільки відкритою є «неформалізована» експертиза в цехах 😊. Особливо коли йдеться про legacy-обладнання — тут без досвіду персоналу, іноді навіть «інтуїції оператора», — якісні алгоритми не розробиш. І як тільки KPI заходять у гру — така інформація миттєво стає «відомістю з грифом» 😄(як мінімум "Для службового користування).

SKF — якщо використовували Azure, то я навіть знаю, де ви працювали :)

платформу аналізу даних із підсистемою Fleet Manager для управління девайсами

І яка саме це платформа?
Шось готове чи саморобне?

Вітаю!
На жаль, єдиного рецепта немає — це завжди мікс компонентів, залежно від завдань, обмежень і доступних ресурсів.
У нашому випадку було кілька підходів. Більшість рішень реалізовано на базі AWS — з використанням IoT Core, Greengrass і супутніх сервісів, тобто значна частина логіки перебуває у хмарі. Але бувають ситуації (особливо в критичній інфраструктурі), коли хмару використовувати не можна — через політику безпеки чи відсутність доступу.
У таких випадках — on-premise рішення, яких існує чимало (і з відкритим кодом, і комерційні). Головне — добре розуміти їх сильні та слабкі сторони, бо ідеального немає (це ж інженерія 😊).
Щодо Fleet Manager — є як готові продукти (сервіси), так і можливість реалізувати власне рішення, якщо є in-house команда. Ми пішли другим шляхом і створили власну систему управління пристроями, адаптовану під специфіку завдань.
Ще один важливий аспект — інтеграція моделей Data Science. Це справжній челендж: «прикрутити» різні моделі до єдиної системи, враховуючи їх різну природу, вимоги та формати. Знову ж таки, існують різні підходи, але жоден не є універсальним — особливо коли йдеться про проєкти з різними бізнес-замовниками, об’єктами й контекстами застосування.

Как много есть что сказать автору, но главные проблемы автоматизации в том, что процессы происходят параллельно. Т.е. не детерминировано. Собственно, как и весь физический мир. Потому стремление сделать проще в императивной парадигме сталкивается с очевидным противоречием. Оно то, конечно, можно сделать и так, и есть море предложений. Тезис Черча никто не отменял. Но, вот можно сделать проще и дешевле. Смотри сюда. И обращайся. Можно сделать гораздо проще и дешевле.

Потому стремление сделать проще в императивной парадигме сталкивается с очевидным противоречием.

Поэтому пишут в реактивной парадигме.

Поэтому пишут в реактивной парадигме.

В недостаточно реактивной)

Не, эт все еще императивная, только с разблокировкой потока.
Реактивная — когда куча отдельных хендлеров сообщений (callback hell).

Дякую автору за статтю! Цікавий досвід, вражаюча експертиза команди в області IIoT

Підписатись на коментарі