Разработка AI-системы оптимизации энергопотребления здания

AI оптимизация энергопотребления: где здание теряет энергию

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

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

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

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

Что меняется после внедрения: метрики до и после

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

После перехода на управление по фактической нагрузке одновременная работа контуров разводится по времени. Пиковая нагрузка снижается на 15–25 % без потери комфорта: температура и качество воздуха остаются в допустимом коридоре по всем зонам. Это и есть основной вклад в энергоэффективность здания — эффект даёт не отдельное устройство, а согласование режимов между системами.

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

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

Считаем метрики на сопоставимом сезонном профиле и одинаковых границах объекта — иначе сравнение «до и после» ничего не доказывает.

Способы управления микроклиматом и их ограничения

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

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

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

Как проходит внедрение: от аудита до передачи

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

Порядок работ

1. Аудит инженерных систем: обследуем тепловой пункт, приточные установки, чиллеры и узлы регулирования, снимаем фактические уставки и суточные графики. На выходе — карта зон с перерасходом и список контуров, где есть свобода управления без потери комфорта.
2. Схема точек учёта: определяем состав датчиков, период усреднения и то, как данные сводятся в один контур. Отдельно фиксируем пропуски и «шумные» каналы, чтобы модель не училась на артефактах.
3. Цифровая модель здания: собираем теплотехническую модель с инерцией ограждающих конструкций и зонами разной нагрузки. На ней отрабатываем алгоритм до выхода на живой объект.
4. Настройка уставок и контуров: увязываем управляющие воздействия с существующей автоматикой, задаём приоритеты, минимальный шаг регулирования и жёсткие границы, за которые система не выходит ни при каких прогнозах.
5. Проверка на реальных сценариях: прогоняем ночную разгрузку, утренний разогрев, пик нагрузки и выход здания из выходного режима. Сверяем отклонения по температуре в помещениях с допустимым коридором.
6. Передача эксплуатации: передаём документацию, регламент и обучение инженеру — включая порядок возврата к штатному управлению, если поведение системы вызовет вопросы.

Схемы, уставки и регламенты обслуживания

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

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

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

Кейс: административное здание с круглосуточной нагрузкой

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

Что показали замеры до

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

Что изменили и что стало

Модель прогнозирует тепловую нагрузку по расписанию, данным датчиков присутствия и прогнозу погоды, а раз в четверть часа пересчитывает уставки по зонам; жёсткие пороги остались только как аварийные границы. Сравнение замеров до и после показывает: потребление здания снизилось на 27%, пиковая мощность — на 19%, доля часов с перегревом помещений сократилась с 31% до 4%. Откат к прежней логике — один переключатель режима, поэтому изменения вводили поэтапно, по группам оборудования.

Чем адаптивная оптимизация отличается от работы по расписанию?

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

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

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

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

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

Технические сомнения, которые стоит закрыть до старта

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

Что происходит при потере связи с сервером?

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

Как система встраивается в существующую диспетчеризацию?

Мы не заменяем её, а надстраиваемся: сервис оптимизации пишет уставки через штатные интерфейсы контроллеров, а логика безопасности, приоритеты и аварийные сценарии остаются в диспетчеризации. Объём прав системы ограничен явно.

Учитываются ли ручные действия персонала?

Ручное вмешательство оператора имеет безусловный приоритет и блокирует автоматические уставки на заданный интервал. Такие периоды помечаются в журнале как ручные и исключаются из обучения — иначе модель начинает считать отклонения нормой. Журнал доступен службе эксплуатации.

Обсудим задачу и вернёмся с оценкой и планом

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

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

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