Wer vergibt Ihre BACnet Device IDs? Warum ein BACnet-Netz eine verantwortliche Stelle braucht

Fragt man Betreiber, wer in ihrem Portfolio die BACnet Device IDs vergibt, kommt fast immer dieselbe Antwort: «Das macht jeweils der Integrator.» Beim ersten Projekt funktioniert das. Beim zweiten wird es eng, und spätestens wenn zwei Integratoren am selben Netz arbeiten, zeigen sich die Folgen: doppelte Adressen, Geräte, die plötzlich nicht mehr erreichbar sind, und eine Fehlersuche, die Tage dauert. Dieser Auftakt unserer Serie zeigt, warum das kein Softwareproblem ist, sondern eine fehlende Rolle, was die KBOB dazu vorgibt und an welchen fünf Warnsignalen Sie erkennen, dass in Ihrem BACnet-Netz die Verantwortung fehlt.

Die Ausgangslage in typischen Portfolios

In den meisten Liegenschaftsportfolios ist die Gebäudeautomation über Jahre gewachsen. Jede Sanierung, jeder Neubau und jede Erweiterung wurde als eigenes Projekt ausgeschrieben, oft mit unterschiedlichen Integratoren und Herstellern. Jeder Integrator bringt seine eigenen Gewohnheiten mit: eine eigene Logik für die Device IDs, eigene Namenskonventionen für Objekte und eine eigene Art, Netzwerkdaten zu dokumentieren.

Solange jedes Projekt in einem abgeschlossenen Netz lebt, fällt das kaum auf. Doch heute werden Anlagen zusammengeführt. Eine übergeordnete Managementebene soll alle Gebäude zeigen, ein Energiemonitoring soll Daten aus mehreren Liegenschaften auswerten, und die IT verlangt eine saubere Segmentierung. In diesem Moment treffen die verschiedenen Adresslogiken aufeinander, und was einzeln funktioniert hat, funktioniert gemeinsam nicht mehr.

Dazu kommt ein organisatorischer Punkt: Die Projektleitung der Bauherrschaft wechselt, Integratoren werden neu ausgeschrieben, Mitarbeitende im Facility Management gehen in Pension. Das Wissen, nach welcher Logik die Adressen vergeben wurden, steckt dann in den Köpfen einzelner Personen oder in Projektordnern, die niemand mehr öffnet.

Was die KBOB zur Eindeutigkeit vorgibt

Die KBOB hat diese Problematik früh erkannt. Der KBOB-Leitfaden zur Empfehlung BACnet Anwendung (Version 2.0, Juli 2021) hält im Kapitel zur Strukturierung fest, dass der Object Identifier des Device-Objekts im BACnet-Netzwerk einzigartig vergeben werden muss. Dafür stehen Nummern zwischen 1 und 4'194'303 zur Verfügung. Um Überschneidungen bei der Vergabe zu vermeiden, soll diese Nummer strukturiert werden, und zwar so, dass die Bauherrschaft die Struktur vorgängig einmalig definiert und in den Dokumenten für die Realisierung vorgibt.

Der Kern dieser Vorgabe ist nicht technisch, sondern organisatorisch. Die Nummernstruktur gehört der Bauherrschaft, nicht dem Integrator. Wer sie festlegt, muss sie auch über alle Projekte hinweg durchsetzen, Nummernbereiche reservieren und dokumentieren, welche Nummer wo vergeben ist. Genau dafür beschreibt der Leitfaden eine eigene Funktion: den BACnet-Administrator.

Auch die KBOB-Empfehlung BACnet Anwendung selbst verlangt Eindeutigkeit: BACnet-Objekte müssen in einem Gerät eindeutig gekennzeichnet sein, und der Objektname des Device-Objekts muss im gesamten Netzwerk eindeutig sein. Wer diese Anforderungen projektweise erfüllt, aber nicht projektübergreifend, erfüllt sie im Ergebnis nicht.

Was passiert, wenn die Verantwortung fehlt

Doppelte Device IDs sind tückisch, weil sie nicht immer sofort auffallen. Ein BACnet-Client, der ein Gerät über seine Device ID sucht, erhält im ungünstigen Fall Antworten von zwei verschiedenen Geräten. Je nach Implementierung verbindet er sich mit dem falschen, zeigt wechselnde Werte an oder verliert die Verbindung ganz. Für den Betrieb heisst das: Alarme kommen nicht an, Trendaufzeichnungen haben Lücken, und Sollwerte werden im falschen Gerät verändert.

Die Fehlersuche ist aufwendig, weil die Ursache nicht dort liegt, wo das Symptom auftritt. Der Integrator des neuen Projekts sieht ein Gerät, das nicht sauber antwortet. Der Integrator des bestehenden Gebäudes hat nichts verändert. Beide haben aus ihrer Sicht korrekt gearbeitet. Erst wer das ganze Netz kennt, findet den Konflikt.

Die Folgekosten zeigen sich selten als eigene Position. Sie verstecken sich in Regiestunden, in verlängerten Inbetriebnahmen, in Nachträgen und in der Zeit, die Facility Management und IT mit Rückfragen verbringen. Vor allem aber leidet das Vertrauen in die Daten. Wenn niemand sicher weiss, ob ein Wert aus dem richtigen Gerät stammt, nützt auch die beste Managementebene wenig.

Fünf Warnsignale in Ihrem BACnet-Netz

Aus unserer Praxis in BACnet-Analysen und Fehlerprüfungen kennen wir fünf typische Hinweise darauf, dass die Rolle des BACnet-Administrators fehlt. Je mehr davon zutreffen, desto dringender lohnt sich ein Blick auf die Organisation.

1. Doppelte Device IDs nach einer Erweiterung

Nach einer Erweiterung oder einem Geräteersatz tauchen Geräte doppelt auf oder verschwinden zeitweise aus der Managementebene. Das ist das deutlichste Zeichen dafür, dass Nummern ohne zentrale Übersicht vergeben werden. Oft liegt der Konflikt zwischen einem alten und einem neuen Projekt, die beide bei derselben Startnummer begonnen haben.

2. B-PAT nur pro Projekt

Die BACnet Project Address Table (B-PAT) ist das Werkzeug, das der KBOB-Leitfaden für die Dokumentation der BACnet-Infrastruktur und den Austausch von Adressdaten nennt. In vielen Portfolios existiert sie, aber nur als Projektbeilage. Eine gesamthafte Tabelle, die alle Netzwerknummern, Device IDs und Netzwerkparameter über alle Gebäude zeigt, fehlt. Damit ist jede neue Vergabe ein Blindflug.

3. Unbekannte Firmware- und Softwarestände

Das BACnet-Device-Objekt kennt Eigenschaften für Hersteller, Modell, Firmware-Revision und Version der Anwendungssoftware. Wenn diese Angaben nirgends zusammengeführt sind, weiss niemand, welche Geräte von einer Sicherheitslücke oder einem bekannten Fehler betroffen sind. Spätestens bei der Frage der IT nach einem Inventar wird das zum Problem.

4. Wissensverlust nach einem Integratorwechsel

Wechselt der Integrator, geht häufig das Wissen über die Adresslogik mit. Der neue Integrator beginnt mit seiner eigenen Struktur, weil die alte nicht dokumentiert ist. So entstehen in einem einzigen Gebäude zwei Logiken nebeneinander, und die nächste Erweiterung wird noch schwieriger.

5. IT-Segmentierung ohne BACnet-Übersicht

Die IT segmentiert das Netz in VLANs und vergibt IP-Bereiche, kennt aber die BACnet-Netzwerknummern, die BBMD-Konfiguration und die Broadcast-Wege nicht. Umgekehrt kennt der Integrator die IT-Vorgaben nicht vollständig. Der KBOB-Leitfaden weist die Koordination der IT-Netzwerkdaten mit der internen IT ausdrücklich dem BACnet-Administrator zu. Fehlt diese Schnittstelle, entstehen Konflikte, die weder die IT noch der Integrator allein lösen kann.

Warum das kein Softwareproblem ist

Wer diese Warnsignale erkennt, sucht oft zuerst ein Werkzeug: ein Inventarisierungstool, einen Netzwerkscanner oder eine neue Managementebene. Solche Werkzeuge helfen, aber sie lösen das Grundproblem nicht. Ein Scanner zeigt, welche Device IDs heute im Netz sind. Er entscheidet nicht, welche Nummer das nächste Projekt erhalten soll, und er sorgt nicht dafür, dass der Integrator diese Nummer auch verwendet.

Die eigentliche Lücke ist eine Rolle: eine Stelle, die die Vorgaben der Bauherrschaft pflegt, Adressen vergibt, die B-PAT führt, mit der IT spricht und bei jedem Projekt prüft, ob die Vorgaben eingehalten werden. Ohne diese Stelle bleibt jedes Werkzeug eine Momentaufnahme.

Was eine zentrale Vergabe konkret verändert

Mit einer verantwortlichen Stelle ändert sich der Ablauf grundlegend. Vor Projektbeginn erhält der Integrator einen reservierten Nummernbereich und die gültigen Vorgaben. Während der Ausführung werden die Adressdaten gegen das Gesamtinventar geprüft. Bei der Abnahme fliesst die revidierte B-PAT in das zentrale Inventar zurück. Und bei jeder späteren Änderung im Betrieb gilt derselbe Weg.

Das Ergebnis ist unspektakulär, und genau das ist der Punkt: Neue Projekte lassen sich einbinden, ohne dass bestehende Anlagen gestört werden. Die IT erhält eine nachvollziehbare Übersicht. Und wenn der Integrator wechselt, bleibt das Wissen bei der Bauherrschaft.

Ausblick: die Rolle im Detail

Die KBOB beschreibt die Rolle des BACnet-Administrators mit Aufgaben, Kompetenzen und Verantwortungen. Was das im Einzelnen heisst, welche Festlegungen die Bauherrschaft selbst treffen muss und wo die Grenze zur IT-Sicherheitsverantwortung liegt, zeigt der nächste Teil dieser Serie.

Der rote Faden zu unseren Fachbeiträgen

Wie eine BACnet-Struktur von Beginn an sauber geplant wird, zeigt unsere Serie zur BACnet-Planung. Was hinter Objekten, Properties und Device-Objekt steckt, erklärt die Serie «BACnet Objekte verstehen». Und wie BACnet/SC die Kommunikation absichert, behandelt unsere Serie zu BACnet/SC, Sicherheit und Migration.

Fazit

Doppelte Device IDs, projektweise B-PAT und unbekannte Firmwarestände sind Symptome derselben Ursache: Niemand ist für das BACnet-Netz als Ganzes verantwortlich. Die KBOB gibt klar vor, dass der Device Object Identifier netzweit eindeutig sein muss und die Bauherrschaft dafür die Struktur festlegt. Wer diese Vorgabe ernst nimmt, braucht eine Stelle, die sie über alle Projekte und den Betrieb hinweg durchsetzt. Diese Stelle heisst BACnet-Administrator.

Sie haben Fragen dazu?

Sie wissen nicht genau, wer in Ihrem Portfolio die BACnet-Adressen vergibt, oder erkennen eines der Warnsignale wieder? Wir übernehmen die Rolle des BACnet-Administrators nach KBOB als unabhängiges Mandat und starten mit einem BACnet-Governance-Check, der Ihren Ist-Zustand sichtbar macht. Mehr dazu unter wenget.ch/services/bacnet-administrator/ oder direkt über info@wenget.ch.

Quellenverzeichnis

• KBOB Leitfaden zu KBOB Empfehlung BACnet Anwendung, Version 2.0, Juli 2021 (Kap. 3.2.1 Object Identifier des Device-Objekts, Kap. 4.1 BACnet Administrator, Kap. 5 Verwalten von BACnet Inventar, Kap. 5.1 B-PAT)
• KBOB Empfehlung BACnet Anwendung, Version 2.0, Juli 2021 (Eindeutigkeit von Objekten und Objektnamen)
• SN EN ISO 16484-5 (SIA 386.155): Systeme der Gebäudeautomation, Datenkommunikationsprotokoll BACnet
• Eigene Projekterfahrung der WENGET GmbH aus BACnet-Analysen und Fehlerprüfungen