BMS и IBMS — надзор или интеграция?

Глубина интеграции: шлюзы или общая модель

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

Когда IBMS оправдывает себя

IBMS оправдывает свои затраты там, где решения выходят за границы систем: пожарное событие, которое должно разблокировать доступ; вход арендатора, который должен запустить ОВК и освещение; кампус, которому нужен единый энергетический обзор; диспетчерская, которая контролирует несколько зданий. Он также помогает там, где ответственность распределена, поскольку общий журнал аудита делает каждое действие прослеживаемым. Отдельное здание с небольшим оборудованием, одним оператором и небольшим числом сторонних систем обычно не нуждается в таком механизме; хорошо проработанная BMS с открытым экспортом проще в эксплуатации. Критерий — не размер здания, а количество взаимосвязанных решений. Если в здании одно техническое помещение и одна команда, IBMS может добавить затраты, не добавив решений, которые кому-либо нужно принимать.

Риск при реализации — это объём работ, а не технология

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

• Строки: каждая подсистема, включая явно исключённые
• Глубина: мониторинг, управление, тревога, блокировка или отчёт
• Интерфейс: протокол, владелец шлюза и карта точек
• Приёмка: тест, подтверждающий каждую строку