BMS уже працює. Що потрібно додати, щоб перейти до AI-керування?

Не віддаємо AI задачу, яку вже вирішує контролер

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

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

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

Перетворюємо теги на зрозумілу структуру

Назва `AI_17` не пояснює, що вимірюється. До того ж у документації автоматики AI часто позначає аналоговий вхід, а не штучний інтелект. У моделі Project Haystack такі точки пов’язуються з функцією, обладнанням і об’єктом. ²

Для аналітики потрібна відповідь: це температура припливу якої установки, яку зону вона обслуговує, які команди впливають на цей параметр і де зберігається історія?

Такий контекст можна описувати через погоджену модель даних. Brick, наприклад, призначений для представлення обладнання будівлі та зв’язків між її фізичними й цифровими складовими. ³

Не обов’язково створювати складну модель всього об’єкта одразу. Для пілота достатньо узгоджено описати потрібний контур і не втратити його зв’язки із суміжними системами.

Цифровий паспорт — не те саме, що модель прогнозу

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

Для прогнозу потрібна додаткова залежність, яку налаштовують і перевіряють для задачі. Вона може бути фізичною, статистичною або комбінованою. Називати будь-який каталог обладнання готовим предиктивним двійником було б неточно.

Саме тому в технічному завданні варто розділяти результат структурування даних і результат перевірки моделі.

Від рекомендації до команди

Спочатку система може лише спостерігати: виявляти ситуації й пропонувати зміни, які оцінює інженер. Далі — перевірений пілот у погодженій зоні.

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

Хмарна модель не повинна бути єдиним виконавцем критичних захистів. Пропонуємо будувати її як оптимізуючий рівень над працездатною локальною автоматикою — саме такий напрям підключення до наявних систем описаний у HVAC AI на сайті SM Systems. ⁴

Порівнюємо з реальним базовим керуванням

Розрахунок має показувати різницю між новим рішенням і тим, що будівля вже вміє. Некоректно порівнювати AI з навмисно невдалим режимом і називати всю різницю перевагою технології.

Симуляція дозволяє порівнювати алгоритми за однакових умов. Наприклад, BOPTEST використовує віртуальні будівлі та керувальні точки для такого тестування. Але її результат залишається результатом моделі, а не показанням лічильника конкретного клієнта. ⁵

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

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