ИИ для энергетики и ЖКХ: какие задачи диспетчерской и сетей решаются и с чего начать

Предприятие удобно разложить на три контура с разными владельцами и правилами внесения изменений. ИИ-проект сначала привязывается к одному из них.

• Технологический. Контроллеры, терминалы защиты, телемеханика. Здесь работает автоматика, и менять её может только тот, кто за неё отвечает. Мы в этот контур не входим.
• Диспетчерский. Журнал событий, оперативные схемы, приём заявок, телефония. Сюда приходят копии данных, здесь работают подсказки диспетчеру и разбор обращений.
• Корпоративный. Биллинг, абонентская база, учёт приборов, документооборот. Здесь живут проверка показаний, прогноз потребления, распознавание бумаг и поиск по документам.

Данные из технологического контура приходят в остальные копией, а как устроена передача, решает ваша служба, отвечающая за этот контур. Канала обратно в оборудование проект не создаёт. Неверную подсказку человек проверяет за минуту, а неверная команда в сеть может оставить квартал без тепла, поэтому управление строится на проверенной автоматике. Для объектов, отнесённых к значимой инфраструктуре, категорирование выполняет заказчик; требования к ИИ-системам разобраны в статье «Требования КИИ к ИИ-системам». Лицензии ФСТЭК у нас нет, аттестацию не проводим.

Условный пример. Утром в мороз пропало отопление, и за час приходит много обращений из разных домов. Часть повторяет друг друга, часть описывает другое событие. Дежурный видит длинный список вместо двух-трёх происшествий.

• Тема и адрес. Теплоснабжение, водоснабжение, электроснабжение, лифт. Адрес сопоставляется со справочником домов и узлов.
• Связь с одним событием. Обращения по одному дому или участку в одном окне времени предлагаются как группа. Группу подтверждает оператор.
• Приоритет по вашим правилам. Правила (социальный объект, мороз, угроза людям) пишет ваша служба, модель показывает, какое правило сработало.
• Черновик ответа. Читает и отправляет оператор. Срок восстановления называет дежурный, который знает ход работ, а не модель.

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

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

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

Цифр качества заранее не обещаем: допустимая ошибка записывается как критерий приёмки до обучения. Общий подход описан в статье «Предиктивная аналитика: как не ошибиться».

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

Типовые задачи описаны в разборах: поток обращений в реестре обращений граждан, кадры обходов в разборе аэроснимков ЛЭП, старое оборудование в разборе про данные с оборудования разных лет. Если не ясно, какая задача первая, начните с аудита готовности к внедрению ИИ и статьи «Как выбрать первый ИИ-проект».