Основы автоматизации зданий
BAS, BMS и IBMS: практическое руководство
Чем система автоматизации зданий (BAS), система управления зданием (BMS) и интегрированная система управления зданием (IBMS) различаются по объёму, архитектуре и эксплуатации и как выбрать подходящий уровень.
Краткий ответ
BAS управляет инженерными системами на уровне оборудования, BMS осуществляет диспетчеризацию и управление этими системами в пределах одного здания, а IBMS объединяет несколько зданий и подсистем в единую эксплуатационную платформу. На практике они пересекаются, но их объём, модель данных и эксплуатационная ответственность различаются.
Три термина — три уровня охвата
BAS, BMS и IBMS часто используют так, будто это взаимозаменяемые понятия. Это не так. Система автоматизации зданий — это уровень управления: контроллеры, входы и выходы, полевые устройства и алгоритмы, которые управляют оборудованием. Система управления зданием — это расположенный над ним уровень диспетчеризации: расписания, тревоги, тренды, отчёты и операторский интерфейс инженерных систем. Интегрированная система управления зданием идёт дальше, связывая несколько подсистем и часто несколько зданий в одну эксплуатационную модель. Пересечение реально, поскольку многие продукты объединяют управление и диспетчеризацию, а многие платформы BMS сегодня предлагают функции интеграции. В закупочной документации одна и та же аббревиатура может обозначать отдельный контроллер, лицензию на программное обеспечение и сервисный контракт. Надёжный вопрос — не как называется система, а чем она владеет, что может изменить и кто несёт ответственность при отказе. Это определение следует внести в спецификацию до выбора продукта. Общее определение также делает коммерческую границу яснее: что поставляется, что интегрируется и что остаётся за существующими системами. Три уровня могут использовать общее оборудование и при этом сохранять различные зоны ответственности; название значит меньше, чем граница. Полезная привычка — записать определение в начале спецификации и ссылаться на него в каждом последующем пункте.
- BAS отвечает за управление на уровне оборудования и резервные состояния
- BMS отвечает за диспетчеризацию, тревоги, тренды и отчёты
- IBMS отвечает за межсистемные правила и представления портфеля объектов
- Определения должны быть в спецификации, а не в рекламных материалах
Чем управляет BAS
BAS управляет оборудованием, которое делает здание пригодным для использования: чиллерами, котлами, тепловыми насосами, насосами, приточными установками, фанкойлами, боксами VAV, вентиляторами, осветительными цепями, солнцезащитой и счётчиками. Полевые устройства измеряют температуру, влажность, давление, расход, CO2 и присутствие; контроллеры считывают эти сигналы и управляют клапанами, воздушными заслонками, вентиляторами и контакторами. Логика управления находится рядом с оборудованием, поэтому местные алгоритмы должны оставаться работоспособными, когда сеть или уровень диспетчеризации недоступны. Поэтому BAS оценивают не столько по панели управления, сколько по перечню точек, алгоритмам и поведению на нижнем уровне. Эти три артефакта определяют, что система действительно умеет, и именно их опытный инженер в первую очередь просит показать на проектной проверке. Освещение и солнцезащита могут работать на тех же контроллерах или в отдельных сетях KNX или DALI, но принцип один: определённый выход, определённый алгоритм и определённое резервное состояние. BAS, не способная управлять своей установкой при отключённом диспетчере, — это система дистанционного управления, а не система управления. Перечень точек должен различать физические I/O, шинные точки, программные точки и резерв, поскольку у каждого вида своя стоимость и свой характер отказа. Если контроллер отвечает за алгоритм, его отказ должен ограничиваться оборудованием, которое он обслуживает, а резервная ёмкость на этапе проектирования дешевле второго шкафа, установленного позже.
- Оборудование: чиллеры, котлы, тепловые насосы и насосы
- Воздушная сторона: приточные установки, фанкойлы, боксы VAV и вентиляция
- Терминальное оборудование: тёплый пол, радиаторы и фанкойлы
- Инженерные системы: освещение, солнцезащита, учёт и тревоги
Что добавляет BMS
BMS добавляет диспетчеризацию. Она приводит точки одной или нескольких систем управления к общей модели, применяет расписания и уставки, маршрутизирует тревоги, хранит тренды и формирует отчёты. Обычно это интерфейс, которым оператор пользуется ежедневно, и место, где инженер проверяет, почему оборудование запустилось в необычное время. BMS может диспетчеризировать оборудование сторонних производителей через BACnet, Modbus или шлюз, поэтому она не ограничена контроллерами одного поставщика. Различие с BAS носит эксплуатационный, а не физический характер: BMS может работать в той же сети и даже на том же программном стеке, но её задача — управлять и объяснять, а не владеть каждым контуром регулирования. Полезная проверка — спросить, что произойдёт с оборудованием при выключенном сервере BMS. Если ответ «ничего не работает», значит, в проекте перепутаны диспетчеризация и управление. BMS также должна указывать, какие тревоги она формирует, какие лишь транслирует и как оператор квитирует событие, возникшее в другой системе. Рационализация тревог — часть проекта BMS, а не фильтр, применяемый после пусконаладки. Количество тревог — результат проектирования, а не мера усердия; экран с четырьмя сотнями постоянных тревог никто не читает.
- Тревоги с приоритетом, маршрутизацией и квитированием
- Расписания и переопределение уставок
- Тренды, отчёты и базовые уровни энергопотребления
- Операторский интерфейс для повседневной эксплуатации
Что меняет IBMS
IBMS расширяет интеграцию за пределы инженерных систем. Контроль доступа, CCTV, охранные тревоги, парковка, лифты, речевое оповещение, мониторинг пожарной безопасности, системы гостиничных номеров и счётчики энергии могут быть объединены в одну модель данных и тревог. Ценность проявляется в межсистемном поведении: событие доступа включает освещение и ОВК, пожарная тревога принудительно переводит системы в безопасные состояния, портал арендатора показывает потребление в нерабочее время. Она проявляется и в отчётности по портфелю объектов, где одинаковые имена точек и KPI применяются во всех зданиях. Граница важна. Системы обнаружения пожара и обеспечения безопасности жизни остаются определяющими для своих функций; IBMS контролирует и координирует, не заменяя их. IBMS без чёткой эксплуатационной модели становится дорогой панелью управления. Прежде чем заказывать такую систему, определите, какие решения платформа вправе принимать, какими системами может управлять и какие остаются независимыми по замыслу. Этот вопрос управления сложнее технологического и обычно определяет, будет ли проект полезен через два года после передачи объекта. Единая модель данных — техническая основа; таблица прав на принятие решений — организационная. Нужны обе, и вторая обычно отсутствует в тендерной документации. Та же таблица должна уточнять, кто может изменить уставку, а не только кто может отдать команду.
- Межсистемные блокировки и корреляция тревог
- Панели управления портфелем и бенчмаркинг
- Представления для арендаторов и гостей
- Чёткие границы команд для систем безопасности жизни
Архитектура, которая переживает передачу объекта
Три уровня делают проект понятным: устройство, диспетчеризация и приложение. Уровень устройств отвечает за местное управление; уровень диспетчеризации — за общую модель данных, тревоги и блокировки; уровень приложений — за панели управления, отчёты и ролевые представления. У каждого уровня одна задача, и данные проходят через модель диспетчеризации, а не копируются в каждое приложение. Сохранится ли это на практике, решают практические детали: соглашение об именовании, принятое до конфигурирования, перечень точек с единицами измерения и состояниями отказа, философия тревог с приоритетами и журнал аудита команд. Открытые протоколы снижают зависимость от одного поставщика, но открытость помогает только при передаче карты точек и документации. Плоская архитектура — не схема с тремя прямоугольниками, а правило, по которому ни одно приложение не хранит собственную версию истины. При передаче объекта должны передаваться резервные копии, лицензии, учётные данные, схемы сети и проверенная процедура восстановления, а не только папка со скриншотами. Архитектура должна выдерживать и смену интегратора — это практическая проверка документации. Если двум приложениям нужен один и тот же KPI, расчёт должен выполняться на уровне диспетчеризации, а не в каждой панели. Передача, для которой нужен ноутбук исходного инженера, — не передача, как бы полно ни выглядел комплект чертежей.
- Устройство: местные алгоритмы и безопасные состояния
- Диспетчеризация: единая модель данных и модель тревог
- Приложение: ролевые представления и отчёты
- Передача объекта: резервные копии, учётные данные и проверенное восстановление
Ориентировочные диапазоны: точки, зоны и персонал
Ориентировочные диапазоны полезны для бюджетирования и для проверки проекта при условии, что они обозначены как типичные. Гостиничному номеру обычно требуется от 12 до 30 точек с учётом освещения, солнцезащиты, ОВК, статуса доступа и тревог. Офисный этаж может нести от 150 до 400 точек в зависимости от того, открытое это пространство, кабинетная планировка или лаборатория. Центральное техническое помещение может насчитывать от нескольких сотен до более тысячи точек, если чиллеры, насосы, приточные установки и учёт полностью охвачены мониторингом. Эти цифры — вспомогательные ориентиры, а не коммерческие предложения. Определяющим является перечень точек. Численность персонала подчиняется той же логике: одним зданием с BMS могут управлять один-два оператора при технической поддержке, тогда как портфелю нужна центральная команда по стандартам и отчётности плюс местное реагирование первой линии. Диапазоны следует заменять, как только появляются шаблон помещения или перечень оборудования, потому что диапазон, доживший до закупки, превращается в предмет спора. Их также следует приводить вместе с допущениями, чтобы изменение объёма работ приводило к изменению числа, а не к конфликту. Диапазоны следует обновить после первой фиксации проекта, когда шаблоны помещений наконец известны.
- Типичные диапазоны точек с указанием допущений
- Шаблоны помещений и этажей заменяют усреднённые коэффициенты
- Численность персонала зависит от эксплуатационной модели, а не от площади
- Диапазоны — вспомогательный инструмент планирования, а не основа для расчёта цены
Критерии решения: выбор уровня
Выбор уровня — это решение о зоне ответственности, а не только о масштабе. Начните с результатов: что нужно контролировать, что нужно видеть вместе и кому и о чём нужно отчитываться. Если в здании одно техническое помещение и несколько инженерных систем, может быть достаточно грамотно спроектированной BAS с интерфейсом BMS. Если несколько систем должны реагировать друг на друга или несколько объектов должны отчитываться совместно, стоит обсудить IBMS. Разбивайте объём работ на этапы так, чтобы управление и документация были завершены до расширения интеграции. Спросите, кто будет эксплуатировать систему, какие тревоги важны, какие отчёты требуются и что должно продолжать работать при отказе сети. Небольшая система, задокументированная и используемая, ценнее крупной, которой никто не доверяет. Та же дисциплина применима к модернизации: повторно используйте то, что пригодно к эксплуатации, заменяйте то, что нельзя задокументировать, и оставляйте резерв на следующий этап. Решения по объёму работ следует фиксировать как допущения в коммерческих документах, поскольку работы по интеграции обычно и становятся причиной изменения бюджета. Письменное исключение дешевле спорного включения. Если ответ неясен, меньший объём с документированным путём расширения обычно оказывается более выгодным коммерческим решением.
- Начинайте с эксплуатационной модели и требуемых результатов
- Отделяйте обязательное управление от дополнительной интеграции
- Выполняйте поставку поэтапно и документируйте каждый этап
- Фиксируйте исключения и допущения в договоре
Типичные отказы и проверки при пусконаладке
Большинство отказов проявляется гораздо позже проектной проверки, но восходит именно к ней. BAS с неполными алгоритмами работает в ручном режиме. BMS, транслирующая все тревоги без рационализации, приучает операторов игнорировать экран. IBMS, которая всё интегрирует, но не определяет права на принятие решений, превращается в платформу для просмотра с амбициозным названием. Другие типичные отказы — перечень точек без резерва, соглашение об именовании, применённое после конфигурирования, сеть без источника времени и комплект передачи объекта со скриншотами вместо резервных копий. Пусконаладка должна проверять отказы, а не только нормальный алгоритм: отключите датчик, остановите диспетчер, разорвите связь со шлюзом, принудительно перезапустите контроллер и убедитесь, что здание остаётся безопасным, а оператор видит достоверную картину. Финальная проверка — документальная: сможет ли новый инженер объяснить архитектуру, найти карту точек и восстановить резервную копию, не обращаясь к исходному интегратору? Если нет, система не завершена. Протокол пусконаладки, в котором перечислены только пройденные тесты без условий, при которых они проводились, не является доказательством. Для каждого теста отказа ожидаемый результат должен быть записан до его выполнения, иначе это демонстрация, а не проверка.
- Проверяйте потерю датчика, диспетчера и шлюза
- Подтвердите резервные состояния и видимость тревог
- Проверьте, что резерв и именование сохраняются после конфигурирования
- Подтвердите восстановление и передачу без участия исходного инженера
Сравнение BAS, BMS и IBMS по зоне ответственности
16 rows| Аспект | BAS | BMS | IBMS |
|---|---|---|---|
| Основная роль | Прямое цифровое управление оборудованием | Диспетчеризация и управление инженерными системами | Интеграция множества систем и объектов |
| Типичный объём | ОВК, освещение, солнцезащита и счётчики | Все инженерные системы одного здания | Здание, безопасность, парковка, лифты, PMS и энергетика |
| Ответственность за управление | Алгоритмы на уровне контроллера | Расписания, уставки и переопределения | Межсистемные правила и политика для портфеля |
| Модель данных | Объекты I/O и оборудования | Нормализованные точки здания | Общая модель для подсистем и объектов |
| Обработка тревог | Тревоги оборудования и безопасности | Тревоги с приоритетами и маршрутизацией | Межсистемная корреляция и эскалация |
| Расписания | Местные временные программы | Расписания здания и зон | Календари портфеля и правила для арендаторов |
| Отчётность по энергопотреблению | Импульсы счётчиков и моточасы | Тренды потребления и базовые уровни | Бенчмаркинг портфеля |
| Блокировки | Аппаратная или местная логика | Настраивается в рамках инженерных систем | Межсистемная и для нескольких объектов |
| Типичные пользователи | Техники и инженеры по пусконаладке | Операторы и инженеры службы эксплуатации | Руководство эксплуатацией и арендаторы |
| Распространённые протоколы | BACnet, Modbus, KNX и DALI | BACnet, Modbus, API и шлюзы | API, шлюзы, базы данных и панели управления |
| Типичное применение | Одно техническое помещение или этаж | Одно здание с несколькими системами | Кампус, гостиничная группа или портфель из нескольких объектов |
| Основной риск | Ошибки алгоритмов и плохая настройка | Перегрузка тревогами и устаревшие точки | Расползание объёма интеграции и неясная ответственность |
| Документация | Перечень точек, алгоритмы и исполнительные чертежи | Философия тревог, мнемосхемы и определения отчётов | Реестр интерфейсов, словарь данных и права на принятие решений |
| Удалённый доступ и безопасность | Местный порт обслуживания, ограниченный доступ поставщика | Ролевой доступ операторов и журнал аудита | Федеративные идентичности и сегментированные сети |
| Доказательства пусконаладки | Проверки точек и испытания алгоритмов | Валидация тревог, трендов и отчётов | Межсистемные сценарии и испытания отказоустойчивости |
| Путь обновления | Прошивка контроллера и расширение I/O | Версия программного обеспечения и ёмкость по точкам | Новые подсистемы, объекты и расширения модели данных |
Изображения проекта
3 images
Частые вопросы
01BAS — это то же самое, что BMS?
Нет. BAS — это уровень управления, который запускает оборудование. BMS — уровень диспетчеризации, который формирует расписания, тревоги, тренды и отчёты по инженерным системам. Некоторые продукты объединяют оба уровня, поэтому в договоре следует указать, какие функции относятся к какому уровню. Практическая проверка — что продолжает работать при выключенном сервере диспетчеризации.
02Может ли BMS работать без IBMS?
Да, и большинство зданий так и работает. BMS осуществляет диспетчеризацию инженерных систем в пределах одного здания. IBMS оправдана, когда несколько подсистем, несколько объектов или отчётность для арендаторов требуют единой эксплуатационной модели. Добавление уровня IBMS без такой потребности обычно приводит к панели, дублирующей то, что уже показывает BMS.
03Нужна ли IBMS каждому зданию?
Нет. IBMS добавляет ценность, когда её оправдывают межсистемное поведение, отчётность по портфелю или большая эксплуатационная команда. Небольшим зданием с хорошо задокументированной BMS может быть проще управлять и обслуживать, чем недоиспользуемой интеграционной платформой. Решение должно следовать эксплуатационной модели, а не амбициям спецификации.
04Где находится управление ОВК?
Алгоритмы ОВК обычно выполняются в контроллерах BAS рядом с оборудованием. BMS обеспечивает расписания, уставки, тревоги и тренды. Критичная защита и защита от замерзания остаются местными, независимыми от уровня диспетчеризации. Если алгоритм чиллера зависит от доступности сервера, значит, управление размещено не на том уровне.
05Можно ли добавить IBMS позже?
Обычно да, если первый этап оставляет открытые протоколы, согласованное именование, документированные карты точек и сетевой доступ. Доинтегрировать недокументированную систему возможно, но дорого. Самая дешёвая подготовка — документация и резервная ёмкость, а не дополнительная лицензия на программное обеспечение, купленная заранее.
06Чем BMS отличается от EMS?
Система управления энергопотреблением (EMS) сосредоточена на учёте, базовых уровнях и отчётности. BMS охватывает эти функции плюс ОВК, освещение, тревоги и повседневную эксплуатацию. На практике они пересекаются, и границу следует определить в объёме работ. Если существуют обе системы, укажите, какая отвечает за базовый уровень, а какая — за эксплуатационное расписание.
07Сколько точек нужно BAS?
Это зависит от систем, алгоритмов и уровня мониторинга. Количество должно следовать из перечня точек, а не из эмпирического правила. Перечень также показывает, какие точки физические, какие программные и какие резервные. Типичные диапазоны существуют для планирования, но до фиксации цены их следует заменить перечнем.
Следующий шаг
Приведите нам здание.
Расскажите о типе здания, системах в объёме работ и нужном результате. Мы покажем кратчайший путь к работающей системе.