Снижаем энергопотребление здания на 30% с AI-управлением

AI умное здание: когда автоматика работает вхолостую

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

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

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

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

Предиктивное управление климатом: измеримый эффект

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

Снижение энергопотребления без потери комфорта

До внедрения тепло и холод подавались циклично, по расписанию рабочих часов: нагрузка росла ступенями, пики совпадали, оборудование дольше работало на повышенной мощности. Прогноз нагрузки на инженерные системы даёт упреждающий старт — к приходу людей воздух уже в норме, а не разгоняется в первые часы. На объектах с непрерывным измерением расход на отопление и охлаждение упал на 27–34% за сезон, отклонения температуры сократились с ±2,5 °C до ±0,8 °C.

Меньше отказов оборудования и внеплановых выездов

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

Способы внедрения: облако, локальный модуль, гибрид

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

Как выбрать режим: критерии и ограничения

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

Этапы внедрения: аудит, схема, настройка, передача

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

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

Что делаем на этапе пилота на одном контуре

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

Что передаём заказчику: конфигурации и регламенты

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

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

Документация и регламенты эксплуатации

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

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

Кейс: как снизили энергопотребление офисного центра

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

Сначала собрали историю: телеметрию с контроллеров и данные существующей автоматизации здания за полный сезон. Слой аналитики развернули поверх работающей системы на Schneider Electric EcoStruxure Building Operation — без замены оборудования и остановки эксплуатации.

Модель спроса считает потребность на тепло и холод по часам, погоде и заполненности здания. Уставки меняются упреждающе, с горизонтом до 4 часов, приводы заслонок работают в «мёртвой зоне» и не раскачиваются, а расхождение «уставка / факт» уходит в заявку на сервис, пока это ещё отклонение, а не авария.

За отопительный сезон потребление снизилось на 31%, пиковая мощность — на 18%, аварийные выезды — с 9 до 2 в месяц, реакция на отклонение — с нескольких часов до 15 минут. Вложения окупились за 14 месяцев за счёт снижения потребления.

Где эффект оказался выше ожиданий

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

Чем предиктивное управление отличается от расписания

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

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

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

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

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

Ограничения: где AI-управление не заменит инженера

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

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

Как система ведёт себя при потере связи или отказе датчика?

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

Кто отвечает за решения и можно ли вернуться к ручному управлению?

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

Насколько решение совместимо с существующей автоматикой здания?

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

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

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

Пришлите то, что есть — даже частичный набор даёт рабочую картину:

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

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