AI-система Smart Grid: інтелектуальне управління енергомережами

Розробка Smart Grid: де ламається управління мережею

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

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

Друге джерело відмов — ручні перемикання. Рішення ухвалює оператор за неповною картиною, і між виявленням відхилення та перемиканням минає час, за який аварійні режими мережі поширюються на сусідні ділянки.

Розробка smart grid починається саме з цього місця: поки кожне перемикання потребує ручного підтвердження, швидкість реакції обмежена людиною, а не логікою мережі.

Окремо варто відзначити відсутність єдиної моделі мережі. Топологія живе у схемах, навантаження — у журналах, історія аварій — у звітах, і кожна задача починається зі зведення цих джерел вручну.

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

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

Ефект керованої мережі: баланс, втрати, аварії

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

Зниження втрат у мережі дає не алгоритм сам по собі, а зміна режиму: перемикання секціонувальних апаратів, регулювання напруги, керування реактивною потужністю. На розгалужених фідерах із нерівномірним завантаженням це дає 1,5-3 процентних пункти відносно вихідного режиму.

Окрема стаття — комерційні втрати: зіставлення відпуску та корисного споживання за ділянками виявляє помилки вимірювань і втрати на стороні абонента.

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

Балансування розподіляє навантаження між фідерами та накопичувачами, тому перевантаження трансформаторів переходять із регулярних подій у рідкісні.

Локалізація аварій спирається на телеметрію та напрямок струму короткого замикання: система звужує ділянку до найближчого секціонувального апарата й пропонує схему перемикань. Час від спрацювання захисту до відновлення живлення на непошкоджених ділянках падає з годин до хвилин.

Розрахунки режимів і втрат звіряємо з моделлю мережі в OpenDSS — підсумкові цифри підтверджує модель, а не звіт.

Підходи до побудови: централізований, гібридний, острівний

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

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

Гібридна схема переносить частину рішень на локальні контролери, залишаючи центру загальну координацію — ділянка витримує обрив каналу й не втрачає керованість. Острівний режим іде далі: фрагмент працює повністю автономно й синхронізується з центром після відновлення зв'язку. Нижче — порівняння підходів з обмеженнями, які проявляються вже в експлуатації.

Порівняння підходів — це не пошук «найкращої» архітектури, а прив'язка схеми до карти мережі, якості каналів і ціни помилки на кожній ділянці.

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

Етапи впровадження: від аудиту мережі до передачі в експлуатацію

Впровадження системи управління енергомережею йде фіксованою послідовністю: спочатку описуємо фактичний стан мережі та якість телеметрії, потім проєктуємо логіку, і лише після цього підключаємо її до живого обладнання.

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

1. Обстеження об'єкта. Збираємо схему мережі — склад підстанцій, точки вимірювань, добові профілі навантажень, якість каналів зв'язку. На виході карта даних із переліком ділянок, де телеметрії бракує або вона надходить із затримкою.
2. Аудит енергомережі та вимог. Узгоджуємо цільові режими, межі допустимих відхилень і сценарії, які система має відпрацьовувати автономно.
3. Цільова схема та налаштування системи. Визначаємо склад контурів, правила пріоритетів між ними, пороги спрацювання та порядок ескалації рішень диспетчеру.
4. Пілотний контур. Розгортаємо систему в ізольованому середовищі на історичних даних і моделюємо аварійні сценарії — перемикання, відключення фідерів, зростання навантаження.
5. Дослідна експлуатація. Підключаємо реальні вимірювання в режимі порадника: система пропонує рішення, диспетчер підтверджує. Розбіжності розбираємо та коригуємо логіку.
6. Пусконалагодження. Переводимо окремі контури в автоматичний режим, перевіряємо спрацювання захистів і коректність відкату до ручного управління.
7. Передача в експлуатацію. Навчаємо зміну, передаємо регламенти, схеми та журнали налаштувань, фіксуємо метрики приймання.

Кожен етап закривається результатом, який можна перевірити: картою даних, схемою контурів, протоколом випробувань або актом приймання.

Комплект постачання: моделі мережі, конфігурації, регламенти

Комплект постачання: моделі мережі, конфігурації, регламенти

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

Ми віддаємо комплект документації у версіонованому вигляді, щоб правки можна було відстежити, порівняти та відкотити.

• Модель мережі — топологія, приєднання, зв'язки між вузлами та параметри обладнання у форматі, який читає розрахунковий модуль. Оновлюється з диспетчерської відомості, а не переписується вручну.
• Схеми та конфігурації — уставки, пороги спрацювання, сценарії перемикань, довідники обладнання та правила пріоритету навантажень. Кожен набір прив'язаний до версії моделі, тому розбіжностей між «як намальовано» і «як працює» не виникає.
• Матриця прав — ролі диспетчера, чергової зміни, інженера супроводу та спостерігача, з межею: хто змінює уставки, хто лише підтверджує, хто бачить журнал.
• Регламенти експлуатації — порядок дій чергової зміни при відхиленні режиму, втраті телеметрії від ділянки та розбіжності прогнозу з фактом: що перевіряється першим, коли втручається людина, коли система переходить у безпечний режим.
• Інструкції із супроводу — як додати приєднання, перерозмітити датчик, оновити модель без зупинки контуру та повернути попередню конфігурацію.
• Протоколи випробувань — контрольні сценарії, на яких приймалася система, із зафіксованою очікуваною поведінкою.

Ми проганяємо з інженерами замовника один контрольний сценарій на переданому комплекті — так видно, що документація робоча, а не написана «для приймання».

Кейс: локалізація аварій і втрати в розподільній мережі

В оператора розподільної мережі — 128 фідерів середньої напруги та близько 900 трансформаторних підстанцій.

Телеметрія збиралася, але жила в трьох незв'язаних системах: диспетчер бачив «немає зв'язку» та «перевантаження», а місце пошкодження шукав вручну — обдзвоном бригад і за непрямими ознаками.

До впровадження: пошук наосліп

Середній час від першого сигналу до локалізації пошкодження — 47 хвилин, на віддалених фідерах сягало двох годин.

Частка втрат у мережі трималася на 11,4%, а повторні відключення на одній і тій самій ділянці давали 38 випадків за квартал: захист спрацьовував, причину не знаходили, ділянку повертали в роботу.

Що змінили

Звели телеметрію, історію спрацювань захистів і схему мережі в загальний контур та навчили прогнозні моделі на розмітці минулих аварій.

Локалізація тепер іде за сукупністю ознак — просідання напруги, асиметрія фаз, порядок спрацювання захистів, — а перевантаження прогнозується на 30–60 хвилин уперед, тож диспетчер встигає переключити навантаження до відключення.

Розрахунки режимів виконували на OpenDSS, топологію взяли з наявної розрахункової моделі без перемальовування.

Після

Час локалізації — 6 хвилин у середньому й не більше 12 на віддалених ділянках. Частка втрат знизилася до 7,8%, повторні відключення — 9 за квартал замість 38, хибні виїзди бригад скоротилися приблизно вдвічі.

Відмовостійкість мережі зросла не за рахунок нових захистів, а за рахунок того, що диспетчер перестав працювати наосліп.

Чим відрізняється Smart Grid від класичної автоматизації?

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

Такий контур надійний, але він не знає, що буде в мережі за годину, і не вміє вибирати між варіантами управління.

Smart Grid — це надбудова над захистом, а не його заміна. Завдання шару — прогнозувати та оптимізувати режим: перерозподіляти потоки, планувати виведення обладнання в ремонт, узгоджувати роботу розподіленої генерації та накопичувачів. Рішення спирається на телеметрію, модель мережі та прогноз навантаження за кожною точкою.

Відмінність проявляється в трьох речах. Горизонт: реакція на факт проти прогнозу на кілька годин уперед. Об'єкт управління: окремий апарат проти режиму мережі загалом. Уставки: фіксовані проти тих, що перераховуються під поточну топологію, погоду та завантаження.

Наявну автоматику під час модернізації мережі не демонтують. Поверх SCADA ставиться шар розрахунків та оптимізації, а обмін іде за стандартними протоколами телеметрії.

Якщо вимірювань бракує, їх спочатку добудовують: без достовірних даних прогноз вироджується в здогад, і весь ефект втрачається.

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

Часті технічні питання щодо інтеграції та безпеки

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

Чи доведеться змінювати наявне обладнання?

Ні: система стає шлюзами поверх поточного парку. Лічильники, пристрої релейного захисту та диспетчерські системи працюють як працювали — ми знімаємо дані з їхніх штатних інтерфейсів і приводимо до єдиної моделі.

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

Як захищені канали зв'язку?

Контури управління та моніторингу розділені: дані спостереження не можуть перетворитися на команду. Обмін іде захищеними каналами з шифруванням і взаємною автентифікацією вузлів, доступ — за ролями, кожна дія потрапляє в журнал. Команда перевіряється на допустимість режиму до застосування.

Наскільки відмовостійка система і чи можна впроваджувати поетапно?

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

Обговоримо задачу: що підготувати і з чого почнемо

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

• однолінійна схема мережі: живильні центри, фідери, точки обліку та їх прив'язка до об'єктів;
• перелік вимірюваних параметрів і фактична частота знімання за кожним;
• історичні ряди за характерний період, включно із сезонними піками та аварійними добами;
• цільові показники, за якими вимірюватиметься ефект: рівень втрат, частка розподіленої генерації, час локалізації пошкодження;
• режимні обмеження та правила, які диспетчер задає вручну сьогодні;
• перелік суміжних систем, з якими потрібен обмін даними, і формат цього обміну;
• вимоги до ізоляції контурів, матриці доступів і журналювання дій;
• обмеження щодо каналів зв'язку та середовища розміщення: закритий контур, ізольований сегмент.

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

За підсумками повертаємося з оцінкою проєкту та планом робіт: етапи, склад команди, точки контролю та те, що ви отримуєте на виході кожного етапу.

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