BMS и АСУЗ: что это и когда зданию нужен единый пульт управления

На объекте уже стоит автоматика вентиляции, отдельный регулятор в тепловом пункте и свой контроллер на насосной — три щита, три логики, три места, куда нужно прийти, чтобы понять, что происходит со зданием. Всё исправно работает по отдельности, но у диспетчера нет ни одного экрана, где видно здание целиком. Термин для решения этой задачи — BMS, он же АСУЗ. Ниже — что это означает на практике, когда без BMS не обойтись, а когда до неё ещё рано, и что реально показывают диспетчеру, когда она есть.

BMS и АСУЗ — одно и то же под двумя именами

BMS (Building Management System) и АСУЗ (автоматизированная система управления зданием) — это не два разных решения, а один термин на двух языках: BMS — как его называют в проектах и на оборудовании, АСУЗ — как он обозначен в российских нормативных документах. Путаницы здесь меньше, чем с SCADA и диспетчеризацией: расхождение чисто терминологическое, а не по составу системы.

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

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

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

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

Когда зданию действительно нужна BMS

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

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

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

Когда хватает диспетчеризации одной-двух систем — и в чём тут частая ошибка

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

Диспетчеризации одной-двух систем обычно достаточно, если:

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

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

Из чего физически состоит BMS

BMS — это не одна программа, а слой, который сводит вместе то, что уже автоматизировано по отдельности:

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

Сеть и протоколы. Контроллеры разных систем и разных производителей должны «говорить» на понятном верхнему уровню языке. Для инженерных систем зданий профильный протокол — BACnet, также в ходу Modbus RTU/TCP, для освещения и климата встречается KNX, для учёта ресурсов — M-Bus. Разнородное оборудование сводят через шлюзы и драйверы протоколов; закрытый фирменный интерфейс отдельного узла иногда требует конвертера или не интегрируется вовсе — это стоит проверять по моделям оборудования до подписания договора, а не обещанием «подключим всё».

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

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

Как это выглядит на объекте: BMS торгового или бизнес-центра глазами дежурного

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

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

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

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

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

Пять ошибок, которые встречаются на объектах при переходе к BMS

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

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

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

Экономят на количестве сигналов на старте, планируя расширение «когда-нибудь потом». Контроллер, из которого наружу выведено пять параметров вместо реально доступных пятнадцати, при расширении BMS придётся перепрограммировать заново — переделка выходит дороже, чем закладка запаса сразу.

Не определяют заранее, кто и что имеет право менять на объединённом пульте. Когда систем много и подрядчиков по ним тоже несколько, вопрос прав доступа — кто может квитировать аварию, кто менять уставки, кто только смотреть — стоит решить на старте проекта BMS, а не после первого спорного случая, когда кто-то из персонала случайно изменил режим чужой системы.

Частые вопросы про BMS и АСУЗ

В чём разница между BMS и АСУЗ? Никакой по сути — это один и тот же уровень автоматизации под двумя названиями: BMS (Building Management System) — международный термин, АСУЗ (автоматизированная система управления зданием) — русскоязычный эквивалент, который используют в проектной документации.

Мы автоматизировали вентиляцию всего здания — это уже BMS? Нет, пока это диспетчеризация вентиляции, даже если установок много. BMS начинается там, где на один пульт сведены разные по природе инженерные системы — не только вентиляция, но и тепловой пункт, насосные, электрика, освещение вместе.

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

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

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

Чем BMS отличается от диспетчеризации нескольких объектов? Это разные оси масштабирования. BMS — одно здание, много разных систем на одном пульте. Диспетчеризация нескольких объектов — несколько зданий или площадок, часто с одной и той же системой (например, сеть котельных), под единым центром. Как организуют сведение нескольких площадок — отдельный разбор: SCADA для нескольких объектов.

Когда переходить от разбора к проекту

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