Любой проект по машинному обучению в энергетике начинается не с архитектуры трансформера, а с того, что слесари переваривают врезки датчиков на трубах. Искусственный интеллект — это звучит дорого, но пока у вас в обратке стоят расходомеры, смонтированные без соблюдения прямых участков, вы будете прогнозировать шум. Полноценная ИИ-оптимизация режимов теплосети и котельной — где спрятаны проценты КПД и перетопа — возможна только поверх жесткой индустриальной базы. В MoranaLabs мы занимаемся тяжелым промышленным ИИ: крутим high-load инференс на edge-железе прямо в периметре клиента, обучаем Reinforcement Learning модели для управления агрегатами. И я могу сказать наверняка: магия начинается только там, где заканчивается бардак с контрольно-измерительными приборами.
Зачем вообще тащить алгоритмы в котельную? Классический ПИД-регулятор не справляется? Не справляется. ПИД работает с прошлым и настоящим: видит отклонение температуры от уставки и дергает клапан. Но теплосеть — это объект с колоссальной транспортной задержкой. Горячая вода не телепортируется. Тепловая волна от коллектора ТЭЦ или котельной идет до удаленного потребителя часами. Если на улице резко похолодало, а вы начали поднимать температуру на выходе только по факту падения температуры в обратке — вы уже опоздали. Район замерз. А когда вы наконец продавите сеть, на улице может снова потеплеть, и начнется классический перетоп — люди откроют форточки, выпуская оплаченные кубометры газа в атмосферу.
Предиктивная аналитика и тепловая инерция: прогноз вместо реакции
Чтобы управлять теплосетью адекватно, нужно смотреть в будущее. Но банально скормить алгоритму прогноз погоды из API недостаточно. У каждого района и даже здания есть тепловая емкость. Хрущевки из бетонных панелей выстывают мгновенно, современные монолиты с вентфасадами держат тепло сутками. Это физика аккумуляции.
ML-модель профилирует эту инерцию на исторических данных телеметрии. Мы предсказываем не погоду, а требуемое теплопотребление с учетом лага. Если сильный мороз ударит в 3 часа ночи, но по прогнозу продержится всего пару часов, алгоритм может вообще не запросить поднятие температуры подачи. Бетонные коробки зданий сами отработают как массивные теплоаккумуляторы, а к утру солнце и внутренние тепловыделения (люди проснулись, включили плиты и чайники) скомпенсируют просадку. Классическая АСУ ТП в этой ситуации раскочегарила бы пиковый котел на полную мощность ровно к тому моменту, когда нужда в нем уже отпала.
Но настоящий монстр сидит не в газовой трубе. Он сидит на клеммах сетевых насосов. Оптимизация ради газа — это половина картины. Основная финансовая дыра — перекачка. Когда сеть разбалансирована, а до концевых домов не доходит тепло, диспетчер решает проблему в лоб: задирает уставку частотников на сетевых насосах. Котельная начинает давить расходом. В этот момент удельный расход электроэнергии на перекачку улетает с нормативных 12 до 26 кВт·ч/Гкал. Вы жжете электричество, загоняя насосы в неэффективные зоны, просто чтобы протолкнуть воду через забитые шайбы.
Модель предиктивной аналитики находит баланс: она вычисляет Парето-оптимальную точку между температурой подачи и расходом теплоносителя. Выгоднее чуть поднять температуру (потратив лишний газ), чем пытаться прокачать холодную воду бешеным давлением (сжигая дорогое электричество).
RL-агент в контуре: комбинаторика машинного зала
Здесь проходит жесткая граница между предиктивной аналитикой и реальным управлением. Вычислить требуемую температуру подачи ($T_s$) и нужный расход — это supervise-задача. Вы получили цифры, отправили их диспетчеру как рекомендацию. Но как именно котельная обеспечит эти гигакалории?
У вас в машинном зале стоит пять котлов разной мощности, износа и года выпуска. У каждого своя режимная карта, свой реальный, деградировавший со временем КПД. Какой агрегат оставить в базе? Какой вывести в резерв? Как распределить нагрузку? Это задача комбинаторной оптимизации, и здесь обычные алгоритмы пасуют. В игру вступает Reinforcement Learning (обучение с подкреплением).
def compute_dispatch_reward(state, action, next_state, required_heat, prices):
# Текущая выработка тепла по всем котлам с учетом их актуального КПД
produced_heat = torch.sum(next_state.boiler_loads * next_state.efficiencies)
# Жесткий штраф за срыв теплового графика (недотоп/перетоп)
demand_penalty = torch.abs(produced_heat - required_heat) * 1000.0
# Экономика: стоимость сожженного газа + электричество насосов
fuel_cost = torch.sum(next_state.gas_consumed) * prices['gas']
pumping_cost = next_state.pump_power * prices['electricity']
# Штраф за износ оборудования (лишние пуски/остановы и резкая смена нагрузки)
wear_penalty = torch.sum(torch.abs(action.delta_loads)) * 50.0
# Агент максимизирует эту награду (минимизирует издержки)
return -(fuel_cost + pumping_cost + demand_penalty + wear_penalty)Котел — это не лампочка, его нельзя дергать вкл/выкл каждую минуту. Продувка топки перед розжигом — это прямые потери тепла в трубу (выгоняем горячий воздух холодным). Изменение нагрузки изнашивает металл. RL-агент учится диспетчеризировать нагрузку так, чтобы минимизировать суммарные затраты на топливо и электроэнергию, избегая лишних переключений. Он видит цифры из предиктивного блока на несколько часов вперед и заранее готовит состав агрегатов к плавному переходу.
Но есть правило, написанное кровью инженеров, и мы в MoranaLabs соблюдаем его железобетонно. Разделяйте зоны ответственности:
- Уровень ИИ (Edge-устройство): Вычисляет глобальные уставки, распределяет нагрузку, прогнозирует погоду.
- Уровень локальной автоматики (ПЛК): Держит заданную уставку ПИД-регулятором, управляет задвижкой.
- Уровень противоаварийной защиты (ПАЗ): Аппаратно отрубает все, если что-то пошло не так.
Аварийные блокировки алгоритму не отдают. Контроль пламени, защита по давлению газа, уровню воды, загазованности котельной — все это остается в жесткой логике нижнего уровня, а часто вообще на аппаратных реле. Если нейросеть сойдет с ума и прикажет выдать 180°C или закрыть обратку на полном ходу, ПАЗ просто оборвет цепь питания и переведет объект в безопасное состояние. ИИ работает строго поверх железобетонного фундамента автоматики. Только так внедряются системы, которым доверяют управление инфраструктурой городов.