На екрані все зелене. Чи справді BMS керує будівлею?

У диспетчерській усе виглядає спокійно: вентилятори зелені, насоси обертаються на мнемосхемі, температури відображаються. Але в частині приміщень душно, а потрібний контур не отримує тепло.

Перше запитання до такої BMS — не про виробника програмного забезпечення. Що означає зелений колір: команда на запуск чи підтверджена робота обладнання?

Команда, стан і результат — три різні речі

Для вентилятора можна відобразити команду «увімкнути», сигнал роботи від перетворювача та виміряну витрату повітря. Ці параметри пов’язані, але не взаємозамінні. Навіть структуровані моделі даних окремо розрізняють команди, показання датчиків і уставки. ¹

Розглянемо умовний випадок. BMS передала команду, перетворювач повідомив про роботу двигуна, але в одній зоні закрита заслонка. Два перші сигнали правильні, а потрібного повітрообміну там немає.

Отже, для кожної функції варто визначити достатнє підтвердження. Сигнал двигуна підтверджує одне, датчик тиску — інше, вимірювання витрати в зоні — третє. Не потрібно ставити всі можливі датчики всюди. Потрібно знати, яку невизначеність залишає обраний набір.

Відкрити клапан — не означає передати тепло

У водяному контурі команда 100% на клапан не є виміряною витратою. Причиною відсутності результату можуть бути механічне положення арматури, стан насоса або неправильне відображення сигналу.

Ми б перевіряли ланцюг послідовно: що замовила автоматика, що підтвердив привід, як змінилися фізичні параметри. Це і є різниця між спостереженням за інтерфейсом та перевіркою роботи системи. Налагодження HVAC передбачає підтвердження відповідності фактичної роботи проєктним критеріям, а не лише відсутність повідомлень про несправність. ²

При цьому не варто діагностувати несправність за однією миттєвою різницею температур. Після команди потрібен обґрунтований час для реакції конкретного контуру.

Хороша BMS може більше, ніж показувати

BMS не обов’язково є пасивним екраном. Вона може координувати режими, розклади, уставки та запуски. Наприклад, PNNL розглядає оптимальний запуск і коригування тиску за потребою як функції керування будівлею — без вимоги купувати окремий «AI» лише заради цих дій. ³

Проблема виникає, коли в договорі перелічені екрани та кількість точок, але не визначено, як вони повинні працювати разом.

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

Що має бачити експлуатація

На робочому екрані я б показував не тільки стан обладнання, а й режим керування, діючу уставку, джерело команди та актуальність даних. Якщо параметр не оновлюється, його не слід видавати за поточний лише тому, що останнє значення було нормальним.

Також потрібен зрозумілий шлях до причини: чому агрегат зупинився, яке блокування активне і що має зробити оператор. Це пропоновані вимоги до інтерфейсу, а не властивість будь-якої BMS за замовчуванням.

Для замовника результатом стає не більша кількість кольорових елементів. Він отримує можливість відрізнити виконану команду від невиконаної та швидше локалізувати проблему.

BMS цінна тоді, коли можна простежити весь ланцюг: завдання → дія → підтвердження → фактичний результат у будівлі.