HLK-Telemetrie für einen mehrstandortigen Gebäudebetrieb

Ein Facility-Betreiber führt ein landesweites Portfolio gemischt genutzter Gebäude: Büros, Light-Industrial-Standorte und eine Handvoll Kühlhäuser. Keine zwei Standorte teilen denselben HLK-Jahrgang. Manche laufen auf einer aktuellen BACnet/IP-Anlage, einige auf Modbus-RTU-Schleifen, und mehrere hängen an geschlossenen OEM-Controllern, die nichts als einen undokumentierten Service-Port nach außen geben.

Die Vorgabe war eng und anspruchsvoll: drei Kennzahlen, jeder Standort, eine normalisierte Sicht. Echtzeit-Energieverbrauch pro Anlage. Eine Stör- und Alarmhistorie mit Zeitstempeln, die sich anbieterübergreifend decken. Laufzeitstunden pro wichtigem Asset, damit die Wartung dem Verschleiß folgt statt dem Kalender. Dem Betreiber war ein Pro-Standort-SaaS-Abo mit fünfjähriger Mindestbindung angeboten worden, und er lehnte es aus Prinzip ab. Daten sind operative Wahrheit, und operative Wahrheit gehört in die eigene Infrastruktur des Betreibers, nicht in die Miete eines Dritten.

Der Reflex bei einem solchen Programm ist, ein neues BMS vor das alte zu setzen. Wir haben aus drei Gründen dagegen argumentiert.

Es erfindet ein Rad neu, das bereits läuft. Die meisten Standorte hatten schon ein funktionierendes BMS auf Anlagenebene, das Kältemaschinen und Lüftungsgeräte zuverlässig sequenziert. Diese Schicht zu ersetzen, kostet ein Jahr Störung und einen mehrjährigen Beschaffungszyklus, im Tausch gegen Funktionen, die der Standort längst hat.

Es löst das standortübergreifende Problem nicht. Ein zweites BMS ist nur ein zweites Silo. Die Frage war nie „was tut diese Anlage gerade": sie lautete „was passiert heute Nacht um 02:00 über das gesamte Portfolio hinweg", und kein Einzelstandort-BMS beantwortet das.

Es tauscht ein Lock-in gegen ein anderes. Der Betreiber lebte bereits mit Vendor-Lock-in auf Anlagenebene. Dafür zu zahlen, sich ein zweites einzuhandeln, diesmal über die Datenschicht, ergab keinen Sinn.

Also haben wir das Gegenteil eines neuen BMS gebaut: eine dünne Telemetrieschicht, die aus den bereits vorhandenen Systemen liest und normalisierte Datensätze in die Datenebene des Betreibers schickt. Sie schafft einen Weg, auf dem die Daten reisen. An der Art, wie die Gebäude gesteuert werden, ändert sie nichts.

Jeder Standort bekommt ein offenes Linux-Gateway von Owasys, neben den bestehenden Controllern installiert, nicht zwischen ihnen und der Anlage. Das Gateway spricht BACnet/IP mit den modernen Anlagen, Modbus RTU über eine serielle Schleife mit den älteren und einen Custom-Adapter mit den geschlossenen OEM-Controllern. Dieser Adapter wurde mit dem OEM unter dem eigenen Vertrag des Betreibers verhandelt, nicht unter unserem, und das war entscheidend: die Zugriffsrechte blieben bei der Partei, der die Gebäude gehören.

Ein Erfassungs-Daemon pollt jedes vorgelagerte System in seinem eigenen Takt, schneller bei Energiezählern, langsamer bei trägen Sollwerten, und normalisiert jeden Messwert gegen ein gemeinsames HLK-Asset-Modell: Lüftungsgerät, Kältemaschine, Pumpe, Kühlturm, Zone. Er schreibt einen Datensatz pro Asset pro Minute in einen lokalen Zeitreihen-Puffer, sodass eine abgerissene Netzverbindung nur ein kurzes Nachspielen kostet. Aus diesem Puffer überträgt ein MQTT-Publisher zu einem vom Betreiber gehosteten Broker. Ein Stream-Worker verteilt die Daten dann in zwei Richtungen: in Timescale für die Live-Dashboards und in Langzeit-Objektspeicher für Compliance und Audit.

Das Asset-Modell ist ein flaches Schema, das wir liefern und das der Betreiber besitzt. Jeder Datenpunkt an jedem Standort wird darauf abgebildet. Nichts im Pfad ist ein Pro-Anbieter-Adapter-Dashboard, denn in dem Moment, in dem die Daten eines Standorts nur in der Maske eines Anbieters Sinn ergeben, ist die portfolioweite Sicht tot.

Welle 1, Referenzstandort (Wochen 1 bis 4). Ein Bürogebäude mit der vollständigsten BACnet-Anlage. Damit haben wir das Asset-Modell festgezurrt, die Energie-KPIs gegen Zählerwerte validiert, denen der Betreiber bereits vertraute, und bestätigt, dass das bestehende BMS dem neuen Gateway auf dem Bus nicht in die Quere kommt.

Welle 2, die schwierigen Standorte (Wochen 5 bis 12). Drei Standorte mit geschlossenen OEM-Controllern. Der Engpass war hier nie der Code. Es war die juristische Arbeit, den OEM-Service-Port unter dem Vertrag des Betreibers freizugeben, die wir zuerst abgewickelt haben, bevor wir den Adapter nach erteiltem Zugriff im Account des Betreibers gebaut haben. Langsam im Kalender, schnell, sobald entsperrt.

Welle 3, der Rest des Portfolios (Wochen 13 bis 26). Inzwischen war die Installation Routine: ein vorgeflashtes Gateway, eine Standort-Checkliste, ein Zwei-Stunden-Verkabelungsfenster und ein Kalibrierdurchlauf gegen die Werte, die das bestehende BMS ohnehin meldete. Servicekräfte führten die Installationen aus. Wir sahen jede einzelne von der Konsole des Betreibers aus online gehen.

Die Dashboards waren der kleinere Teil. Entscheidend war, dass das Betriebsteam eine Frage über das gesamte Portfolio stellen und der Antwort vertrauen konnte.

• HLK-Energie-KPI über das gesamte Portfolio, stündlich: live über alle Standorte innerhalb von Minuten nach den Anlagedaten, gegenüber einem zuvor ein- bis dreitägigen Berichtsversatz.
• Zeit, um zu erkennen, welcher Standort einen Alarm außerhalb der Betriebszeit ausgelöst hat: Sekunden, aus einer einzigen Rangliste, statt der Reihe nach jeden Facility Manager des Standorts anzurufen.
• Dashboards, für deren Veröffentlichung der Betreiber noch von einem Anbieter abhängt: null.
• Wartung wird jetzt nach Laufzeitstunden pro wichtigem Asset geplant, nicht nach einem festen Kalenderintervall.

Das Programm lief als Consulting, Umsetzung, Betrieb, mit einem fest in den SOW eingeschriebenen Übergabedatum. Bei der Übergabe erhielt der Betreiber das Gateway-Image und die Anleitung, es aus dem Quellcode neu zu bauen, den Quellcode des Erfassungs-Daemons, das HLK-Asset-Modell, die Dashboards samt der zugrunde liegenden Queries und ein Runbook, um einen neuen Standort ohne uns in Betrieb zu nehmen.

Zwölf Monate später hat der Betreiber vier Standorte selbständig hinzugefügt. Das ist die Aussage, die uns am wichtigsten ist, weil sie falsifizierbar ist: das Team kann das System erweitern, ohne unseren Vertrag erneut zu öffnen, und es hat es getan.