Device, Network Port & Structured View: Identität und Struktur eines BACnet-Geräts

Sieben Teile lang ging es in dieser Serie um Objekte, die Werte darstellen, melden, zeitlich freigeben und aktiv regeln. In Teil 7 haben wir mit dem Loop- und dem Command-Objekt die aktive Seite der Gebäudeautomation betrachtet. Doch alle diese Objekte leben nicht für sich allein. Sie sitzen auf Geräten, kommunizieren über ein Netzwerk und müssen für den Menschen auffindbar bleiben. Genau darum geht es im letzten Teil dieser Serie.

Die drei Objekte, die diesen Abschluss bilden, halten das Ganze zusammen. Das Device-Objekt ist der Ausweis jedes Geräts im Netzwerk. Das Network-Port-Objekt beschreibt, wie ein Gerät kommuniziert. Und das Structured-View-Objekt bringt Ordnung in die oft riesige Menge an Objekten, damit ein Mensch sich darin zurechtfindet. Sie sind weniger spektakulär als ein Regler oder ein Alarm, aber ohne sie wäre ein BACnet-System weder auffindbar noch navigierbar noch sicher zu betreiben.

Dieser Teil erklärt, welche Eigenschaften ein Device-Objekt zwingend trägt und warum seine eindeutige Nummer so wichtig ist, wie Network-Port-Objekte die Netzwerkanbindung beschreiben und was der Wechsel zu BACnet Secure Connect bedeutet, und wie Structured-View-Objekte eine verständliche Navigation über Tausende von Objekten schaffen.

Das Device-Objekt: der Ausweis jedes Geräts

Jedes BACnet-Gerät enthält genau ein Device-Objekt. Es ist der Ausweis des Geräts im Netzwerk und beschreibt, wer das Gerät ist, was es kann und wie man mit ihm kommuniziert. Während alle anderen Objekte einzelne Funktionen abbilden, beschreibt das Device-Objekt das Gerät als Ganzes. Ohne ein sauberes Device-Objekt bleibt ein Gerät im Netzwerk ein anonymer Fremdkörper.

Die wichtigste Eigenschaft ist der Object_Identifier des Device-Objekts, die sogenannte Device Instance. Diese Nummer identifiziert das Gerät im gesamten BACnet-Netzwerk und muss netzwerkweit eindeutig sein. Genau hier liegt eine der häufigsten und ärgerlichsten Fehlerquellen überhaupt: Zwei Geräte mit derselben Device Instance führen zu Konflikten, die sich als sporadische, schwer auffindbare Störungen äussern. Die Vergabe dieser Nummern gehört deshalb zentral geplant und dokumentiert, nicht dem Zufall der Inbetriebnahme überlassen.

Daneben der Nummer trägt das Device-Objekt einen Object_Name, der das Gerät für den Menschen lesbar benennt. Auch dieser Name sollte einem klaren Schema folgen, damit ein Gerät in einer langen Liste auf Anhieb einzuordnen ist. Eine durchdachte Namensgebung ist kein Luxus, sondern die Grundlage für jede spätere Diagnose und Wartung.

Was das Device-Objekt über ein Gerät verrät

Ein Device-Objekt hält weit mehr als nur Nummer und Name. Über die Properties Vendor_Identifier und Vendor_Name gibt es an, von welchem Hersteller das Gerät stammt. Model_Name, Firmware_Revision und Application_Software_Version beschreiben das genaue Modell und den Softwarestand. Diese Angaben sind bei Störungen, Sicherheitsfragen und beim Ersatz von Geräten Gold wert, weil sie ohne Öffnen des Schaltschranks aus der Ferne ablesbar sind.

Eine besonders wichtige Eigenschaft ist die Property Protocol_Services_Supported. Sie beschreibt, welche BACnet-Dienste ein Gerät tatsächlich beherrscht, also ob es beispielsweise Alarme melden, Zeitprogramme bereitstellen oder Trenddaten aufzeichnen kann. Zwei Geräte, die beide BACnet sprechen, können sich in ihrem Funktionsumfang stark unterscheiden. Wer sich allein auf das Etikett BACnet verlässt, erlebt bei der Integration oft böse Überraschungen. Ein Blick auf die unterstützten Dienste gehört deshalb in jede Geräteauswahl.

Die Property Object_List schliesslich führt alle Objekte auf, die das Gerät bereitstellt. Sie ist das Inhaltsverzeichnis des Geräts und die Grundlage dafür, dass eine Leitstelle oder ein Planungswerkzeug überhaupt weiss, welche Datenpunkte ein Gerät anbietet. Ergänzt wird das durch technische Angaben wie APDU_Timeout, Segmentation_Supported und Max_APDU_Length_Accepted, die festlegen, wie die Kommunikation im Detail abläuft. Sie sind selten spektakulär, entscheiden aber darüber, ob eine Kommunikation stabil oder störanfällig ist.

Das Network-Port-Objekt: die Netzwerkanbindung

Während das Device-Objekt beschreibt, wer ein Gerät ist, beschreibt das Network-Port-Objekt, wie es kommuniziert. Es bündelt die Netzwerkparameter einer Kommunikationsschnittstelle an einem klar definierten Ort. Früher lagen solche Einstellungen oft verstreut und herstellerspezifisch irgendwo im Gerät. Das Network-Port-Objekt macht sie zu einem standardisierten, lesbaren Objekt.

Ein Gerät kann durchaus mehrere Network-Port-Objekte besitzen, etwa wenn es über mehrere Schnittstellen an unterschiedliche Netze angebunden ist. Jedes dieser Objekte hält die Parameter seiner Schnittstelle: bei BACnet/IP etwa die IP-Adresse, die Portnummer und Angaben zur Rolle im Netzwerk, beispielsweise ob das Gerät als BBMD zwischen Teilnetzen vermittelt. So wird die Netzwerkkonfiguration nachvollziehbar und dokumentierbar, statt in verstreuten Menüs versteckt zu bleiben.

Besonders an Bedeutung gewinnt das Network-Port-Objekt durch BACnet Secure Connect, kurz BACnet/SC. Diese neuere Variante von BACnet setzt auf eine verschlüsselte, gesicherte Kommunikation über moderne Netzwerkinfrastruktur und begegnet damit den gestiegenen Anforderungen an die IT-Sicherheit in der Gebäudeautomation. Die Parameter einer solchen sicheren Verbindung, etwa die Zertifikate und die Adresse der Vermittlungsstelle, werden über Network-Port-Objekte verwaltet. Wer heute plant, sollte den Weg zu BACnet/SC zumindest mitdenken, auch wenn eine Anlage zunächst noch klassisch über BACnet/IP kommuniziert.

Warum IT-Sicherheit in BACnet zum Thema wird

Lange galt Gebäudeautomation als abgeschottete Welt, die mit dem Internet wenig zu tun hatte. Das hat sich grundlegend geändert. Anlagen werden aus der Ferne bedient, Daten wandern in Cloud-Dienste, und Gebäudenetze sind zunehmend mit der übrigen IT verbunden. Damit wird auch die Gebäudeautomation zu einem möglichen Angriffsziel, und die Frage der Sicherheit lässt sich nicht mehr ausblenden.

Genau hier setzt BACnet/SC an. Statt unverschlüsselter Kommunikation, die jeder im selben Netz mitlesen könnte, tritt eine gesicherte Verbindung mit Zertifikaten und Verschlüsselung. Für Planer und Betreiber bedeutet das, dass Netzwerkfragen nicht mehr allein Sache der Automationstechnik sind, sondern in Abstimmung mit der IT geplant werden müssen. Das Network-Port-Objekt ist dabei die standardisierte Schnittstelle, an der diese Sicherheitsparameter sichtbar und verwaltbar werden.

Wichtig ist, das Thema früh einzuplanen. Eine nachträgliche Umstellung von BACnet/IP auf BACnet/SC ist deutlich aufwändiger als eine von Anfang an mitgedachte Architektur. Wer heute eine Anlage plant, tut gut daran, die Sicherheitsanforderungen mit der IT abzustimmen und die gewählte Kommunikationsvariante bewusst zu dokumentieren, statt sie dem Zufall zu überlassen.

Das Structured-View-Objekt: Ordnung für den Menschen

Ein grösseres Gebäude bringt schnell Tausende von BACnet-Objekten mit sich. Eine ungeordnete Liste von Tausenden Einträgen ist für einen Menschen praktisch unbrauchbar. Genau dieses Problem löst das Structured-View-Objekt. Es dient nicht der Steuerung oder Messung, sondern ausschliesslich der Gliederung: Es ordnet Objekte in einer nachvollziehbaren, hierarchischen Struktur an.

Das Herzstück ist die Property Subordinate_List. Sie legt fest, welche Objekte oder welche weiteren Structured Views einem Knoten untergeordnet sind. So lässt sich eine Baumstruktur aufbauen, die der Logik des Gebäudes folgt, etwa nach Geschoss, dann nach Raum, dann nach Anlage. Ergänzende Angaben wie Node_Type und Node_Subtype beschreiben, wofür ein Knoten steht, ob er also beispielsweise ein Geschoss, einen Raum oder ein funktionales System repräsentiert.

Der Nutzen zeigt sich spätestens im Betrieb. Sucht ein Betreiber die Temperatur eines bestimmten Raums, klickt er sich über eine sinnvolle Struktur schnell dorthin, statt in einer endlosen Liste zu suchen. Eine gute Structured View bildet die reale Ordnung des Gebäudes ab und macht die Anlage damit begreifbar. Sie ist die Brücke zwischen der technischen Objektwelt und dem Menschen, der sie bedienen soll.

Wie die drei Objekte zusammenspielen

Device, Network Port und Structured View wirken erst im Zusammenspiel. Wenn eine Leitstelle oder ein Planungswerkzeug ein Netzwerk erkundet, findet es zuerst die Device-Objekte und damit die einzelnen Geräte. Über deren Object_List erfährt es, welche Objekte jedes Gerät bereitstellt, und über die Network-Port-Objekte, wie es mit ihnen kommuniziert. Erst danach sorgen die Structured Views dafür, dass die gefundene Fülle an Objekten für den Menschen in eine sinnvolle Ordnung fällt. Aus einer technischen Bestandsaufnahme wird so ein bedienbares System.

Dieses Zusammenspiel erklärt auch, warum die Sorgfalt bei diesen scheinbar unscheinbaren Objekten so wichtig ist. Ein fehlendes oder falsch konfiguriertes Device-Objekt macht ein Gerät unauffindbar. Eine lückenhafte Netzwerkkonfiguration führt zu instabiler Kommunikation. Und eine fehlende Struktur lässt selbst eine technisch einwandfreie Anlage im Betrieb unübersichtlich wirken. Die drei Objekte entscheiden gemeinsam darüber, ob eine Anlage nicht nur funktioniert, sondern auch verstanden und gepflegt werden kann.

Gerade bei Erweiterungen zeigt sich der Wert einer sauberen Grundlage. Kommt Jahre nach der Inbetriebnahme ein neues Gerät hinzu, muss seine Device Instance in das bestehende Nummernkonzept passen, seine Netzwerkanbindung zur vorhandenen Architektur, und es muss an der richtigen Stelle in die Navigationsstruktur eingeordnet werden. Wo diese Grundlagen von Anfang an dokumentiert sind, ist eine Erweiterung eine überschaubare Aufgabe. Wo sie fehlen, wird jede Änderung zum Risiko.

Aus der Praxis: die häufigsten Fehler bei Struktur und Netzwerk

Bei Device-, Network-Port- und Structured-View-Objekten begegnen uns in Analysen und Abnahmen immer wieder dieselben Schwachstellen:

• Doppelte Device Instances. Zwei Geräte tragen dieselbe Nummer, was zu sporadischen, schwer auffindbaren Kommunikationskonflikten führt.
• Keine zentrale Nummernvergabe. Device Instances werden bei der Inbetriebnahme spontan vergeben, ohne Plan und ohne Dokumentation. Spätere Erweiterungen werden zum Ratespiel.
• Chaotische Namensgebung. Geräte und Objekte heissen kryptisch oder uneinheitlich, sodass niemand ohne Zusatzwissen erkennt, was sich hinter einem Eintrag verbirgt.
• Fehlende Structured Views. Die Objekte sind nur als flache, endlose Liste verfügbar. Eine Navigation nach Geschoss, Raum oder Anlage fehlt, und der Betrieb wird zur Sucharbeit.
• Ignorierte Geräteeigenschaften. Angaben wie Protocol_Services_Supported werden bei der Auswahl nicht geprüft, sodass ein Gerät sich später als ungeeignet erweist.
• BACnet/SC nicht mitgeplant. Die Sicherheitsarchitektur wird ausgeklammert, sodass eine spätere Umstellung aufwändig und teuer wird.

Was Planer und Betreiber sicherstellen sollten

Aus diesen drei Objekten ergibt sich eine klare Planungshaltung. Die Vergabe der Device Instances und die Namensgebung gehören zentral geplant, dokumentiert und konsequent eingehalten. Ein sauberes Nummern- und Namenskonzept ist die Grundlage für jede spätere Diagnose, Erweiterung und Wartung und kostet in der Planung fast nichts, während sein Fehlen über Jahre teuer wird.

Ebenso gehört eine durchdachte Navigationsstruktur in jede Ausschreibung. Verlangen Sie sinnvolle Structured Views, die die reale Ordnung des Gebäudes abbilden, statt sich mit einer flachen Objektliste zufriedenzugeben. Und stimmen Sie die Netzwerk- und Sicherheitsarchitektur frühzeitig mit der IT ab, damit der Weg zu einer gesicherten Kommunikation über BACnet/SC offen bleibt.

Für den Betrieb gilt: Ein Betreiber sollte wissen, wie die Geräte benannt und nummeriert sind, wie er sich über die Struktur zurechtfindet und welche Kommunikationsvariante seine Anlage nutzt. Diese Grundlagen entscheiden darüber, ob eine Anlage über ihren ganzen Lebenszyklus beherrschbar bleibt oder mit jeder Änderung ein Stück unübersichtlicher wird.

Wichtig: Massgebend für Objekte, Datenpunkte und deren Benennung sind in der Schweiz die KBOB-Empfehlung «BACnet Anwendung», die einschlägigen SIA-Normen der Reihe 386 sowie ISO 16484. Für Fragen der Netzwerk- und Sicherheitsarchitektur ist zusätzlich die Abstimmung mit den IT-Verantwortlichen und den einschlägigen Sicherheitsvorgaben unerlässlich. Viele Betreiber ergänzen diesen Rahmen durch eigene Namens- und Nummernkonzepte.

Fazit

Device-, Network-Port- und Structured-View-Objekte sind das Gerüst, das eine BACnet-Anlage zusammenhält. Das Device-Objekt ist der eindeutige Ausweis jedes Geräts und verrät, wer es ist und was es kann. Das Network-Port-Objekt beschreibt die Kommunikation und wird zum Schlüssel für eine sichere, zukunftsfähige Vernetzung über BACnet/SC. Die Structured View schliesslich bringt Ordnung in die Objektwelt und macht sie für den Menschen begreifbar.

Damit schliesst sich der Kreis dieser Serie. Wir haben mit den einfachen Ein- und Ausgabeobjekten begonnen, haben Werte, Meldungen, Zeitprogramme, Regelungen und koordinierte Befehle betrachtet und enden bei den Objekten, die alles zusammenhalten. Der rote Faden durch alle acht Teile war stets derselbe: Was eine Anlage tut, soll sichtbar, dokumentiert und nachvollziehbar sein. Objekte mit klaren Eigenschaften sind die Grundlage für eine Gebäudeautomation, die man versteht, prüft und über Jahrzehnte beherrscht, unabhängig von einem einzelnen Hersteller.

Wer die Objekte versteht, hat die Sprache von BACnet gelernt. Der nächste Schritt ist, diese Sprache in Ausschreibung, Vertrag und Abnahme richtig einzusetzen, damit aus verstandenen Objekten auch eine sauber geplante Anlage wird.

Diese Serie ergänzt unsere Serie «BACnet Planung»: «Objekte verstehen» erklärt, was die Objekte sind und wie sie sich verhalten. «BACnet Planung» zeigt, wie man sie in Ausschreibung, Vertrag und Abnahme richtig vorschreibt. Wer beides verbindet, plant und betreibt Gebäudeautomation, die den Namen Interoperabilität verdient.

Sie haben Fragen dazu?

Haben Sie Fragen zu diesem Thema oder zu Ihrer eigenen Anlage? Sprechen Sie uns an, wir unterstützen Sie gerne mit unserer Planungs- und Analyseerfahrung. Eine Übersicht aller Fachartikel finden Sie unter https://wenget.ch/insights/

WENGET, Ihre unabhängige Fachinstanz für BACnet-Planung, -Analyse und -Abnahme in der Schweiz.

Quellenverzeichnis

• ASHRAE Standard 135-2024 (BACnet)
• ISO 16484-5
• KBOB-Empfehlung «BACnet Anwendung» V2.0 (Juli 2021)
• BACnet International: Object Reference (The Language of BACnet)
• BACnet International: BACnet Secure Connect (BACnet/SC)
• SIA 386.110
• Eigene Planungserfahrung WENGET