AI-мониторинг энергосетей: детекция аномалий и прогнозирование

Почему AI-мониторинг энергосетей буксует на практике

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

Второй источник боли — ложные срабатывания защит. Уставки выставляли под худший сценарий и годами не пересматривали, а распределённая генерация и сезонные режимы меняют картину. Защита уходит на пусковой ток или наложенную помеху, потребитель теряет питание, диспетчер часами разбирает событие, а настоящая причина так и остаётся в журналах.

Там, где телеметрии нет, работу держит ручной обход оборудования: обходчик снимает показания, проверяет нагрев и состояние изоляции, записывает в журнал. Данные приходят раз в сутки, между участками расходятся, а точки, до которых обход не дошёл, не наблюдаются вовсе.

Аварии, которые всплывают уже после отключения, — следствие всех трёх разрывов. Перегрев контакта или развивающийся дефект изоляции дают слабые признаки за недели до отказа, но без непрерывного ряда их не с чем сравнить. Именно на этом буксует AI мониторинг энергосетей: модели готовы, а пригодного потока данных для обучения и проверки нет. Разбираем, как это закрывается.

Что даёт предиктивная аналитика: измеримые эффекты

Первый эффект предиктивной аналитики энергосетей — раннее обнаружение отклонений вместо реакции по факту отказа. Модель сопоставляет телеметрию с историей участка и видит дрейф параметров за часы до того, как отклонение станет аварийным: рост температуры контактного соединения, несимметрию фаз, постепенное падение сопротивления изоляции. Дежурный получает не сигнал «линия легла», а уведомление «на этом участке параметр уходит от нормы вторые сутки» — время реакции сокращается с часов до минут.

Второй — доля пропущенных аномалий. Пороговые уставки ловят только выход за границу и молчат на медленных сценариях: сезонная нагрузка, износ, единичный всплеск при переключении. Предиктивная аналитика энергосетей работает на комбинации признаков, поэтому часть ложных срабатываний отсекается, а износ и зарождающийся дефект попадают в выборку. Доля отклонений, которые раньше проходили незамеченными и всплывали только на разборе после аварии, снижается — предупреждение приходит до того, как сработала защита.

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

Четвёртый — объём внеплановых работ. Часть выездов становится профилактикой, а не восстановлением: чистка, протяжка контактов, замена участка кабеля. Суммарное число аварийных заявок и трудозатрат на них падает, ресурс бригад перераспределяется на плановое обслуживание. На выходе у заказчика — предсказуемая нагрузка на персонал и понятная картина состояния сети, а не список вчерашних пожаров.

Пакетный и потоковый мониторинг телеметрии: что выбрать

Режим обработки — это не про инструмент, а про класс задач: от него зависят задержка сигнала до диспетчера и то, какие данные вообще дойдут до модели. При высокой частоте опроса датчиков потоковый контур читает измерения по мере поступления и держит скользящее окно, а пакетный собирает архивы и считает их по расписанию.

На аварийном событии разница видна сразу. Потоковая обработка телеметрии отслеживает развитие аномалии в темпе поступления данных, тогда как пакет замечает её на следующем проходе — когда часть режима уже перезаписана. При этом пакетная обработка данных даёт полный ретроспективный контекст: по нему переобучают модели и разбирают инциденты. Поэтому в AI-мониторинге энергосетей выбирают не «одно из двух», а распределение ролей между контурами.

Когда какой контур уместен

Выбор сводим к трём вопросам: частота опроса датчиков, критичная задержка реакции и нужен ли полный архив для обучения. Обычно горячий поток отвечает за детекцию, а пакетная ветка — за прогноз и качество модели, и обе пишут в общее хранилище с согласованными метками времени.

Как мы внедряем: этапы инженерной работы

Внедрение AI-мониторинга энергосетей начинается не с выбора модели, а с данных. Пока не ясно, что и с какой периодичностью измеряется на объекте, детекция аномалий срабатывает на плановых переключениях и сезонных режимах. Поэтому работы идут этапами, и каждый заканчивается проверяемым артефактом.

1. Аудит телеметрии. Выгружаем исторические архивы измерений, проверяем полноту рядов, пропуски, рассинхронизацию меток времени и дрейф датчиков. Результат — перечень сигналов, пригодных для обучения, и того, что придётся восстанавливать расчётом.

2. Привязка к схеме сети. Сопоставляем сигналы с топологией: фидеры, каскады, границы балансовых зон. Так отсекаются «аномалии», вызванные переключением на смежном участке.

3. Разметка событий с эксплуатацией. Журналы аварий, ремонтов и плановых работ превращаем в метки. Инженеры сетевого предприятия подтверждают, что считать событием, а что — нормальным режимом.

4. Обучение модели. Делим историю по времени, а не случайно, иначе модель подглядывает в будущее и показывает завышенную точность. Порог срабатывания настраиваем под допустимую долю ложных тревог, а не под максимальную полноту.

5. Приёмка на пилотном участке. Модель работает на ограниченном сегменте параллельно с текущим контролем. Считаем, сколько событий поймали раньше диспетчера и сколько ложных срабатываний разбирали вручную.

6. Передача в эксплуатацию. Фиксируем регламент реагирования, расписание переобучения и контроль дрейфа: при смещении характера потребления точность не должна падать незаметно.

Модели, схемы и регламенты: что остаётся у вас

Обученная модель без обвязки живёт ровно до первого сбоя в данных. Поэтому передаём не набор весов, а рабочий контур: по каждому пункту ниже у вас остаётся документ или конфигурация, которую можно открыть, проверить и передать своему инженеру без нас.

• Паспорт модели — задача, тип и участок сети, на которых модель обучена, диапазон входных рядов, целевая метрика качества и границы применимости: где результат достоверен, а где требуется ручная проверка.
• Схема интеграции — откуда и с какой периодичностью забираются телеметрические данные, где стоит буфер накопления, каким каналом уходит сигнал тревоги и что происходит при обрыве связи с устройством.
• Обработка пропусков данных — правила для разрывов разной длины: короткие интервалы восстанавливаются интерполяцией, длинные помечаются как недостоверные, участок не выпадает из прогноза молча.
• Регламент реагирования — уровни тревог, сроки разбора, граница между автоматическим действием и решением диспетчера, порядок эскалации на смене.
• Документация по модели — состав входных признаков, пороги срабатывания, порядок переобучения и требования к разметке новых данных.
• Мониторинг качества — как отслеживается смещение входных данных, по каким признакам видно, что точность просела и модель пора переобучать.
• Протокол отката — возврат на предыдущую версию модели и на прежние пороги одним действием, если новая версия дала рост ложных срабатываний.

Каждый пункт согласуем с вашими инженерами до сдачи: то, что нельзя проверить на реальных данных, в перечень не попадает.

Кейс: ложные срабатывания на подстанции и их устранение

Оператор распределительной сети с несколькими десятками подстанций получал от телеметрии 180–220 сигналов в сутки. Подтверждалась примерно каждая двенадцатая — остальное давали дребезг датчиков, переходные процессы при коммутациях и сезонные сдвиги уставок. Диспетчер реагировал на всё с одинаковым приоритетом, а бригады выезжали по сигналам, которые закрывались на месте.

Что изменили в контуре

Пороги поднимать не стали — это обменяло бы ложные срабатывания на пропуски отклонений. Вместо этого модель учили на нормальных режимах каждого фидера и подали ей контекст: график нагрузки, температуру, состояние соседних присоединений, историю коммутаций. Тревога уходит диспетчеру только после подтверждения вторым независимым признаком, а вклад факторов виден на витрине Grafana — решение объяснимо по факторам.

Мониторинг энергосетей переходит от жёсткого порога к контексту: сигнал несёт смысл, а не факт превышения.

Метрики до и после

Считали на одном и том же квартале. Доля ложных срабатываний упала почти в девять раз, время от первого отклонения до подтверждённой тревоги сократилось с 22 до 4 минут, внеплановые выезды бригад — на две трети. Нагрузка на диспетчера сместилась: вместо одного подтверждённого сигнала на десять он получает восемь. Ни один размеченный исторический инцидент при этом не потерялся — это было условием приёмки. Модель дообучается на подтверждениях диспетчера, пороги пересчитываются перед сезонным пиком, новые подстанции подключаются по той же схеме.

Чем детекция аномалий отличается от прогнозирования?

Это две разные постановки, которые часто объединяют в одном требовании, а потом получают модель, не годную ни для одной из задач. Детекция аномалий отвечает на вопрос «прямо сейчас поведение сети отклоняется от нормы?» — это классификация на скользящем окне телеметрии, где эталоном служит нормальный профиль объекта: суточная кривая, сезонность, зависимость от температуры. Прогнозирование нагрузки отвечает на вопрос «какая мощность потребуется через час, сутки, неделю?» — это регрессия на будущем горизонте, и обучается она на исторических рядах, а не на сравнении с эталоном.

Различаются и данные. Для детекции нужна разметка редких событий: обрывы, отклонения учёта, отказы оборудования, — а они составляют доли процента наблюдений, поэтому модель проверяют на полноте при жёстко ограниченной доле ложных срабатываний. Для прогнозирования разметка не нужна вовсе: важны длина и качество ряда, календарные признаки, погодные данные, графики вводов и ремонтов. Признаки здесь объясняют уровень нагрузки, а не отклонение от него.

Ключевое отличие — горизонт прогноза и цена задержки. Детекции достаточно задержки в секунды-минуты, иначе событие теряет смысл для дежурного. Прогноз строится на горизонт, который диктует решение: час — для оперативной балансировки, сутки — для вывода оборудования в ремонт и резервирования мощности, неделя — для планирования режимов. Ошибку прогноза считают отдельно по пиковым часам, а не средней по ряду: модель, идеально попадающая в ночной минимум, бесполезна, если систематически занижает вечерний максимум.

Практический вывод для требований: это две отдельные системы с разными наборами данных, разными метриками приёмки и разными сценариями использования. Формулировка «система должна предупреждать об авариях и прогнозировать потребление» без указания горизонта, допустимой задержки и допустимой доли ложных срабатываний не проверяема — по ней нельзя ни обучить, ни принять решение. Корректнее описать, какие решения принимаются по сигналу и по прогнозу, — из этого выводятся горизонт, частота пересчёта и требования к качеству.

Технические сомнения: вопросы инженеров и наши ответы

Сомнения на старте обычно одни и те же: хватит ли существующих датчиков, что делать с пропусками и как контролировать модель после запуска. По AI-мониторингу энергосетей отвечаем по существу.

Что делать с пропусками и выбросами?

Пропуск не заполняем средним по парку: восстанавливаем по соседним узлам и профилю того же часа недели и помечаем флагом достоверности. Выброс отбраковывается, только если не подтверждается на смежном узле — реальная авария не сглаживается. Доля восстановленных точек видна в отчёте, поэтому слабые измерения находятся сразу.

Модель не «уплывёт» при смене сезона?

Обучение идёт на нескольких годовых циклах, в признаки входят температура, день недели и профиль суток — сезонность нагрузки модель видит заранее. Переобучение запускается по расписанию и по триггеру: рост доли ложных срабатываний. Порог чувствительности настраиваем отдельно по каждому фидеру.

Кто сопровождает модель после запуска?

Дообучение идёт в закрытом контуре на ваших данных, доступы разграничены и журналируются. Сопровождение — это разбор ложных и пропущенных срабатываний, контроль дрейфа, регламент эскалации и ответственный инженер. Без этого цикла качество проседает за пару сезонов, поэтому поддержку закладываем сразу.

Обсудим задачу: какие данные нужны для старта

Оценка AI-мониторинга энергосетей держится не на общих словах, а на данных: от них зависит и набор моделей, и то, какие аномалии вообще можно поймать. Ниже — минимум исходных сведений, который позволяет посчитать архитектуру и сроки до старта проекта, а не угадывать.

• Схема сети: топология узлов и связей, уровни напряжения, границы участка — подойдёт однолинейная схема в любом читаемом формате.
• Доступ к телеметрии: какие каналы уже собираются (системы диспетчеризации, учёта, регистраторы), в каком виде выгружаются и с какой частотой опроса по каждому измерению.
• Объём выборки: глубина истории — несколько месяцев или несколько лет; чем длиннее непрерывный ряд, тем надёжнее модель отделяет аварию от сезонного и суточного колебания.
• Перечень измерений: ток, напряжение, мощность, температура, частота — что реально доступно по каждому узлу, а что придётся досчитывать.
• Журнал событий: зафиксированные отключения, аварии, ремонты, переключения — это готовая разметка того, что считаем аномалией.
• Справочники по оборудованию: типы и паспортные характеристики, точки учёта, зоны ответственности подразделений.
• Ограничения площадки: где допустимо ставить датчики и программные агенты, требования по изоляции контуров, где разрешено обрабатывать данные.
• Целевой результат: оповещение диспетчера в реальном времени, отчёт по смене или прогноз на сутки вперёд — от этого зависит состав системы.

Если часть сведений отсутствует — это не блокирует работу: пробелы закрываем на этапе обследования. Опишите задачу и то, что уже есть под рукой, — вернёмся с оценкой и планом первого этапа, уточняющие вопросы зададим вместе с вашими инженерами.