IBMS · Объём
Объём IBMS — матрица подсистем, а не список пожеланий
Практический метод определения объёма IBMS: матрица подсистем, реалистичная глубина интеграции, исключения и критерии приёмки.
Краткий ответ
Объём IBMS задаётся матрицей подсистем: для каждой системы указывают, наблюдается ли она, управляется ли ею IBMS, включена ли она в межсистемные блокировки или лишь передаётся в отчёты. Системы безопасности жизнеобеспечения и охраны обычно сохраняют собственное управление: IBMS отслеживает их состояние и события, но не выдаёт команды.
Объём — это матрица, а не перечень
Перечень подсистем сообщает, что подключено. Матрица сообщает, что каждому подключению разрешено делать. По строкам — системы, по столбцам — наблюдение, управление, обработка тревог, межсистемные блокировки и отчётность. Добавьте столбцы для ответственного за интерфейс и приёмочного испытания. Матрица выявляет пробелы до того, как они станут дополнительными соглашениями: система, отмеченная для управления, но без записываемого интерфейса, или блокировка, зависящая от точки, которую никто не поставляет. Она также даёт оператору реалистичную картину того, что платформа будет и чего не будет делать. Матрица без столбца ответственных — схема намерений. Держите столбец приёмочных испытаний на виду при проектных проверках: он превращает обещание в результат.
Реалистичная глубина по подсистемам
ОВК обычно допускает полное наблюдение и управление. Освещение может поддерживать сцены и расписания, но не каждая группа светильников заслуживает индивидуального управления. Счётчики энергии только наблюдаются, а глубина отчётности задаётся счётчиком и шлюзом. Контроль доступа может передавать события и права, при этом решения остаются в системе контроля доступа. Пожарная сигнализация — только наблюдение состояния и событий; команды остаются за пожарной системой. Лифты, парковка и гостиничные номера сильно различаются. Правильная глубина — та, которую оператор действительно будет использовать, а не максимальная, которую допускает протокол. Управление гостиничным номером может включать сцены и ограничения энергии, а гостиничная PMS сохраняет собственный процесс. Каждое решение о глубине следует обосновывать эксплуатационным сценарием, а не перечнем возможностей протокола.
Что оставить за рамками
Исключайте всё, что нельзя поддерживать после передачи объекта. Это устаревшие контроллеры без документированного интерфейса, порталы поставщиков, требующие личной учётной записи, и системы, единственный путь интеграции которых обходит их ограничения безопасности. Команды жизнеобеспечения должны оставаться в самой системе жизнеобеспечения. Не интегрируйте подсистему только ради отображения одного значения на панели: интерфейс, шлюз и бремя обслуживания переживут новизну. Ясный перечень исключений защищает проект не меньше, чем ясный перечень включений. У каждого исключения должна быть причина и последствие, чтобы заказчик мог принять его осознанно. Если у подсистемы нет стабильного интерфейса, документированный ручной процесс часто оказывается честным ответом.
Составление описания объёма
Превратите матрицу в описание объёма из четырёх частей: включения, исключения, ответственность за интерфейсы и приёмочные испытания. Укажите протокол, владельца шлюза, основу подсчёта точек и владельца данных. Определите, что происходит при недоступности интерфейса. Задайте испытание, доказывающее каждую строку, и требуйте результат в пакете документов при передаче объекта. Пересматривайте описание на каждой стадии проектирования, потому что объём незаметно растёт из-за вопросов на площадке. Документ должен быть достаточно коротким, чтобы прочитать его за одну встречу, и достаточно конкретным, чтобы можно было оценить стоимость. Используйте те же термины, что и в тендерной документации, чтобы объём можно было сравнить построчно. Если вопрос меняет объём, зафиксируйте изменение и его стоимость до продолжения работ.
Типичная глубина интеграции IBMS по подсистемам
7 rows| Подсистема | Типичная глубина | Граница |
|---|---|---|
| HVAC | Наблюдение и управление | Последовательности остаются в контроллерах DDC |
| Освещение | Сцены, расписания и состояние | Аварийное освещение остаётся в собственной системе |
| Учёт энергопотребления | Наблюдение и отчётность | Точность счётчиков и ответственность за шлюз |
| Контроль доступа | События и права доступа | Решения о доступе остаются в системе контроля доступа |
| CCTV | События и отдельные видеопотоки | Правила конфиденциальности и хранения |
| Пожарная сигнализация | Только состояние и события | Команды остаются за системой пожарной сигнализации |
| Лифты и парковка | Состояние, тревоги и доступность | Интерфейс поставщика и ограничения безопасности |
Изображения проекта
3 images
Частые вопросы
01Должна ли IBMS управлять системой пожарной сигнализации?
Нет. Пожарная сигнализация и другие системы жизнеобеспечения сохраняют собственное выделенное управление. IBMS может отслеживать состояние и события и отображать их вместе с другими тревогами.
02Сколько подсистем должна интегрировать IBMS?
Целевого числа нет. Интегрируйте системы, поддерживающие решения, которые оператор действительно принимает; остальные оставляйте за рамками, пока не появится реальный сценарий использования.
03Можно ли добавить подсистему позже?
Да, если модель данных, именование и сеть спроектированы с учётом этого. Доинтегрировать недокументированную подсистему гораздо сложнее, чем добавить систему со стабильным интерфейсом.
04Кто отвечает за шлюз?
Ответственной должна быть одна сторона. В описании объёма следует указать, кто поставляет, настраивает, испытывает и обслуживает шлюз, включая обновления прошивки и запасные устройства.
05Что подтверждает полноту объёма?
Подписанная матрица с результатами приёмочных испытаний по каждой строке, а также перечень исключений, согласованный заказчиком и оператором.
Следующий шаг
Приведите нам здание.
Расскажите о типе здания, системах в объёме работ и нужном результате. Мы покажем кратчайший путь к работающей системе.