ИИ в энергетике: как предиктивное обслуживание снижает риск аварий и простоев

Любой проект по ИИ начинается с одного и того же вопроса: где живут данные и кто к ним имеет доступ. В энергетике отвечать на него сложнее, чем почти где бы то ни было ещё, и причин для этого несколько.

Во-первых, режим работы. Генерация, передача, распределение — всё это работает 24/7, без выходных и технологических пауз «на обед». У ИТ-директора банка есть ночное окно для регламентных работ. У главного инженера ТЭЦ такого окна часто нет вовсе: остановка блока — это не строчка в журнале, а согласования, потеря отпуска тепла и деньги.

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

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

И четвёртое, что часто недооценивают, — консервативность среды. SCADA-системе на объекте может быть пятнадцать лет. АСУ ТП собиралась поэтапно, разными подрядчиками, с разной документацией. Инженеры эксплуатации видели уже не одну «волшебную систему», которая обещала всё автоматизировать, а потом стояла мёртвым грузом. Доверие здесь зарабатывается не демонстрацией, а тем, что система не мешает работать и хотя бы раз оказывается права в неочевидной ситуации.

В обслуживании промышленного оборудования сосуществуют три логики, и на реальном объекте они обычно перемешаны.

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

Планово-предупредительный ремонт (ППР) — основа отраслевой культуры эксплуатации. Узлы обслуживают по календарю и наработке независимо от фактического состояния. Это предсказуемо и управляемо, но платой становятся «лишние» ремонты исправного оборудования и при этом — отказы между плановыми ТО, потому что календарь не знает, что конкретный подшипник перегревается уже неделю.

Предиктивное обслуживание (по состоянию) опирается не на дату, а на данные. Модель отслеживает поведение узла и сигнализирует, когда отклонения указывают на развивающийся дефект. Ремонт назначается не «по плану» и не «по факту аварии», а в окне, когда дефект уже виден, но до отказа ещё есть время.

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

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

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

Фундамент — это SCADA и АСУ ТП: токи, напряжения, давления, температуры, обороты, положения арматуры. С ними сразу две оговорки. Дискретизация у разных параметров разная, а историю не всегда архивируют — то, что видно на экране диспетчера сейчас, через месяц может быть уже недоступно для анализа. Поверх этого слоя обычно собирают остальное:

Источники данных для предиктивной модели — от потоковой телеметрии до текстовых ремонтных журналов

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

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

Поток данных в закрытом контуре: от SCADA и телеметрии до рекомендаций инженеру — без выхода за периметр

[ SCADA / АСУ ТП ]
        |
        v
[ Телеметрия, вибро-, акустика, тепло- ]
        |
        v
[ Хранилище / data lake ]  <-- журналы, отчёты ремонтов
        |
        v
[ ML-модуль (аномалии, прогноз) + LLM-модуль (разбор текста) ]
        |
        v
[ Рекомендации и приоритеты ]
        |
        v
[ Инженер / диспетчер ]  -->  принятие решения
        |
        v
[ Журнал действий ]  -->  обратная связь, дообучение

Контур здесь замкнут — и это не оговорка в спецификации, а условие, без которого проект на КИИ не согласуют. Данные SCADA не покидают периметр, модели разворачиваются на инфраструктуре заказчика, обращений к внешним API нет.

Что для таких объектов критично заложить в архитектуру с самого начала:

Подход к развёртыванию ИИ в закрытом контуре подробно разобран в руководстве по развёртыванию LLM в закрытом контуре, а общая рамка работы с объектами КИИ — в статье про ИИ и КИИ.

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

Вывод не в том, что облако «плохое». Для аналитики обезличенных данных или для непроизводственных задач оно вполне применимо. Но как только речь о телеметрии действующего энергообъекта, вопрос упирается не в цену и удобство, а в допустимость выноса данных за периметр. На объектах КИИ ответ обычно отрицательный, и это снимает спор о выборе ещё до его начала.

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

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

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

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

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

Подробный разбор того, из чего складывается бюджет такого проекта, — в материале о стоимости пилота.

Реалистичный пилот — это не «внедрить ИИ на станции», а проверить гипотезу на одном объекте и одном-двух узлах. Типовая последовательность:

Сроки 6–8 недель достижимы, если данные доступны и владелец процесса на стороне заказчика определён. Если данные приходится «добывать» — этап аудита и подключения растягивается, и это нормально.

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

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