Jak AI czyta dane z KNX i BMS budynku i odpowiada, czemu w strefie jest za zimno?

AI podłączona do systemu BMS odczytuje dane z magistrali KNX, z Siemens Desigo CC i z Tridium Niagara 4, a potem odpowiada na pytania technika lub zarządcy normalnym językiem. Nie steruje niczym. Czyta, kojarzy, odpowiada. Dla zarządcy oznacza to jedno: zamiast wchodzić do kilku paneli i ręcznie porównywać alarmy z historią pomiarów, piszecie pytanie i dostajecie gotową diagnozę z numerem obiektu i godziną zdarzenia.

Co siedzi w danych BMS i co stamtąd wyciągamy

BMS zbiera setki, czasem tysiące punktów pomiarowych. Temperatura w strefie, pozycja zaworu grzewczego, stan wentylatora, aktualny przepływ powietrza w skrzynce VAV, licznik energii elektrycznej lub cieplnej. Każdy z tych punktów ma swoją nazwę i typ.

W środowisku BACnet, na którym pracuje i Desigo CC, i Niagara, punkty są obiektami. Analog Input to pomiar ciągły, na przykład temperatura. Binary Input to stan dwustanowy: otwarty/zamknięty, włączony/wyłączony. Accumulator zlicza energię. TrendLog (w Desigo) lub History (w Niagarze) przechowuje historię zmian danego punktu w czasie. Alarm ma pola AlarmState, Priority, TimeStamp i MessageText. Priorytety w BACnet idą od 1 do 255, w Desigo CC używa się kategorii A, B i C.

W KNX każdy punkt to adres grupowy w formacie 1/1/5. Typ danych opisuje DPT: DPT 9.001 to temperatura w stopniach Celsjusza, DPT 1.001 to sygnał dwustanowy. Projekt ETS definiuje, co się kryje pod każdym adresem. Bez znajomości projektu ETS same adresy są ciągiem liczb bez znaczenia. AI korzysta z tej mapy przy interpretacji.

Z Desigo CC czytamy pole PresentValue dla każdego obiektu. Desigo ma moduł Metering i Energy Reports, z których AI pobiera zestawienia zużycia. W Niagarze odpowiednikiem PresentValue jest pole curVal. Dane historyczne w Niagarze to obiekty History, alarmy trafiają do AlarmDb.

Schedule, czyli harmonogram, to osobny obiekt BACnet z wzorcem tygodniowym i polem Exception_Schedule dla dni wyjątkowych. To ważny punkt, do którego wrócimy przy przykładach.

Jak fizycznie działa połączenie: REST, Haystack i osobna sieć

To pytanie zadają prawie wszyscy zarządcy na pierwszym spotkaniu. Odpowiedź jest prosta, choć wymaga kilku słów o architekturze sieciowej.

Siemens Desigo CC od wersji 4.0 wystawia REST API na porcie 4719. Przez ten interfejs można pobierać wartości punktów, historię trendów, aktywne alarmy i dane energetyczne. Do połączenia potrzebne jest konto z rolą Viewer lub Operator Read-Only, adres serwera BMS i dostęp sieciowy. Żadna modyfikacja konfiguracji sterowników nie jest potrzebna.

Tridium Niagara 4 obsługuje protokół Haystack. Dane dostępne są przez moduł nhaystack lub Haystack Connector w formacie haystack-json. Niagara Web Services obsługuje zapytania HTTP. Także tutaj wystarczy konto tylko do odczytu i reguła firewall zezwalająca na ruch z serwera AI.

KNX nie ma otwartego API. To ważne. Magistrala KNX to sieć OT, do której dostęp z zewnątrz odbywa się przez bramkę KNX IP. Dane z magistrali KNX musi najpierw zebrać BMS, który wystawia je dalej przez swoje API. AI nigdy nie łączy się bezpośrednio z magistralą KNX. Łączy się z BMS, a BMS wie, co się kryje pod adresem 1/1/5.

Serwer AI powinien stać w osobnej sieci IT, oddzielonej od sieci OT firewallem. Najlepiej w wydzielonym VLAN-ie. Ruch jest jednostronny: serwer AI łączy się z serwerem BMS po HTTPS, wyłącznie w kierunku odczytu. Żaden pakiet nie płynie z serwera AI do sterowników. To nie jest kwestia konfiguracji oprogramowania. To jest topologia sieci zablokowana na poziomie firewalla. Dział IT definiuje reguły: serwer AI może odpytywać port 4719 na serwerze Desigo. Nic więcej.

AI nie steruje budynkiem. Powtarzamy to, bo to fundament całej architektury.

Odpowiedź dla technika: czemu w strefie jest za zimno

Pokażemy to na konkretnym przypadku, bo teoria nic tu nie zastąpi.

Technik pisze: "Dlaczego w strefie 5-A jest za zimno od rana?" Zamiast wchodzić do Desigo i ręcznie przeszukiwać alarmy, wysyła to pytanie do AI.

AI robi następujące kroki. Pobiera TrendLog dla obiektu Zone_5A_RoomTemp z ostatnich 12 godzin. Widzi, że temperatura zaczęła spadać około godziny 7:00. Sprawdza alarmy w Desigo CC dla urządzeń obsługujących tę strefę. Znajduje alarm na AHU-05 (centrala wentylacyjna obsługująca strefę 5-A): "Supply Air Temp Sensor Fault", TimeStamp 06:51, priorytet B, AlarmState: aktywny. Sprawdza obiekt Zone_5A_HeatValve_Status: zawór grzewczy jest otwarty, zawór próbuje kompensować, ale bez sprawnego czujnika temperatury nawiewanej sterownik AHU pracuje na wartości awaryjnej. Sprawdza Schedule dla AHU-05: harmonogram tygodniowy bez zmian, brak wpisów w Exception_Schedule.

Odpowiedź dla technika: "Strefa 5-A wystygła po awarii czujnika temperatury nawiewanej w AHU-05. Alarm pojawił się o 06:51, priorytet B. Zawór grzewczy strefy jest otwarty, ale bez prawidłowego pomiaru nawiewu sterownik nie reguluje poprawnie. Harmonogram AHU bez zmian. Zalecane działanie: wymiana lub weryfikacja czujnika SAT w AHU-05."

Technik dostaje gotowe zlecenie serwisowe z lokalizacją, przyczyną i godziną zdarzenia. Sam szukałby tego 20–30 minut. Zamiast tego sprawdza odpowiedź przez minutę i jedzie na miejsce.

Podobnie działa analiza stref VAV. AI czyta zarówno setpoint przepływu powietrza, jak i wartość rzeczywistą (Analog Input albo Analog Output). Duże, utrzymujące się odchylenie przez kilkanaście minut wskazuje na zablokowaną przepustnicę, problem z siłownikiem albo błąd kalibracji. Technik dostaje lokalizację strefy i opis rozbieżności, zamiast przeglądać wszystkie strefy ręcznie.

Zgłoszenie najemcy kontra odczyt z czujnika

Najemca dzwoni z pretensjami: "W naszym biurze jest za gorąco od tygodnia." Zarządca chce wiedzieć, czy to prawda, kiedy zaczęło się, i co to powoduje. Bez dostępu do danych BMS zaczyna się gra w telefon z technikiem.

AI łączy dwie informacje: datę i godzinę zgłoszenia najemcy z historią pomiarów z obiektu Analog Input dla tej strefy. Jeśli sensor potwierdza odchylenie, AI pokazuje, kiedy temperatura zaczęła rosnąć powyżej zadanej wartości setpoint. Jeśli sensor pokazuje normę, AI mówi to wprost i daje zarządcy twarde dane do rozmowy z niezadowolonym najemcą.

U jednego z zarządców, z którymi pracujemy, powiązanie skarg z odczytami BMS ujawniło coś, czego nikt wcześniej nie zauważył. Osiemdziesiąt procent zgłoszeń dotyczących temperatury z pięter 3 i 4 trafiało w piątki po godzinie 15:00. AI sprawdziła harmonogram central wentylacyjnych obsługujących te piętra i znalazła przyczynę: Schedule dla AHU-03 i AHU-04 miał ustawiony czas wyłączenia o 15:30, podczas gdy najemcy na tych piętrach pracowali regularnie do 18:00. Nikomu nie przyszło do głowy sprawdzić, bo harmonogram ustawiał poprzedni zarządca budynku trzy lata wcześniej, pod dawne godziny pracy biur.

Bez systematycznego łączenia skarg z danymi BMS ten wzorzec byłby niewidoczny przez kolejne lata. AI przetworzyła historię zgłoszeń z ostatnich sześciu miesięcy i nałożyła ją na trendy temperatur z BMS w kilka minut.

Zużycie energii, urządzenia po godzinach i zlecenia serwisowe

Refakturowanie energii na najemców to proces, gdzie błędy wychodzą na jaw dopiero przy sporach. BMS zbiera dane z podliczników. W Desigo CC są to obiekty Accumulator przypisane do stref lub liczników elektrycznych, plus moduł Metering z eksportem przez Energy Reports. AI czyta te obiekty, przypisuje je do najemców według słownika stref i generuje zestawienie zużycia za wybrany okres.

Zarządca dostaje tabelę: najemca, strefa, zużycie kWh, przedział czasu. Gotowe do faktury. Bez ręcznego przepisywania z panelu BMS do arkusza.

Urządzenia pracujące po godzinach to inny problem. AI sprawdza obiekty Binary Value dla urządzeń w strefach z aktywnym harmonogramem. Jeśli Schedule mówi "wyłączone po 20:00", a Binary Value dla danego urządzenia pokazuje "1" (aktywne) o 22:00, AI flaguje to jako anomalię. Zarządca dostaje listę: które urządzenia, w których strefach, jak długo. W Niagarze ta sama analiza opiera się na obiektach History dla każdego punktu: czas trwania stanu "true" poza wzorcem tygodniowym.

Zlecenia serwisowe AI przygotowuje na podstawie aktywnych alarmów. Zbiera pola MessageText, Priority, TimeStamp i lokalizację obiektu z nomenklatury BMS. Dla alarmów kategorii A lub B w Desigo CC proponuje gotowy opis zlecenia z dokładną lokalizacją urządzenia, typem usterki i czasem trwania alarmu. Jeśli to samo urządzenie miało już wcześniej podobny alarm, AI dołącza historię poprzednich zdarzeń. Technik nie musi szukać w panelu BMS ani przepisywać informacji do systemu CMMS. Dostaje gotowy tekst do zatwierdzenia.

Od czego zaczyna zarządca, który chce to wdrożyć

Zanim cokolwiek podłączymy, sprawdzamy razem trzy rzeczy.

• Wersja i stan BMS. Desigo CC poniżej wersji 4.0 nie ma REST API. Niagara 4 musi mieć zainstalowany moduł nhaystack lub skonfigurowany Haystack Connector. Sprawdzamy to na pierwszym spotkaniu technicznym z integratorem budynku.
• Sieć. Czy jest możliwość wydzielenia VLAN-u dla serwera AI? Czy dział IT może dodać regułę firewall zezwalającą na ruch z jednego adresu IP do portu 4719 serwera Desigo lub do portu Niagara Web Services? To zazwyczaj godzina pracy administratora sieci.
• Dostęp. Konto Viewer w Desigo CC lub konto tylko do odczytu w Niagarze. Bez uprawnień do zapisu, bez możliwości wydawania komend. Sam odczyt.

Nie potrzebujecie nowych czujników. Nie potrzebujecie zmian w sterowniku. Nie ruszamy konfiguracji PLC ani sterowników DDC. Wszystko, czego AI potrzebuje, już jest w BMS. Trzeba to tylko udostępnić do odczytu.

Pierwsze wdrożenie pilotażowe zazwyczaj obejmuje jeden budynek lub jeden fragment infrastruktury. Uruchamiamy odczyt danych, konfigurujemy mapowanie obiektów BMS na język zrozumiały dla zarządcy, testujemy kilka scenariuszy zapytań z technikiem. Po dwóch tygodniach wiadomo, które przypadki użycia dają największą wartość w Waszym budynku.

Zarządcy, którzy zaczęli od jednego budynku, często w ciągu kwartału podłączają kolejne. Bo odpowiedź na pytanie "czemu w strefie 5-A jest za zimno" przestaje być zadaniem na pół godziny, a staje się sprawą na 30 sekund.

Jeśli chcecie zobaczyć, jak to wygląda na Waszym BMS, umówcie się na 15 minut rozmowy. Pokażemy też realne wdrożenia z danymi z działających budynków.

--- **Uwaga do meta description:** agent zwrócił ok. 112 znaków (wymóg to 140–155). Propozycja uzupełnionej wersji: > `Jak AI czyta dane z BMS, KNX i Tridium Niagara: temperatura per strefa, alarmy techniczne, zużycie energii najemców i zlecenia serwisowe. | redAi` (145 znaków ✓)