Was ist ein BACnet-Objekt? Die gemeinsame Sprache der Gebäudeautomation

Objekte, Properties und Services, die Grundbausteine, auf denen jede BACnet-Anlage aufbaut. Und der Grund, warum «BACnet gefordert» noch lange keine funktionierende Interoperabilität bedeutet.

Wer eine Gebäudeautomation plant, ausschreibt oder betreibt, kommt an BACnet nicht vorbei. In fast jeder grösseren Liegenschaft treffen heute Geräte mehrerer Hersteller aufeinander: die Heizzentrale vom einen Anbieter, die Lüftung vom nächsten, Zähler und Ventilantriebe von weiteren. Damit sie zusammenspielen, brauchen sie eine gemeinsame Sprache, und diese Sprache ist BACnet.

Doch «BACnet» auf dem Datenblatt ist nur die halbe Miete. Die eigentliche Interoperabilität entsteht eine Ebene tiefer: bei den Objekten. Sie sind das Herzstück des Standards und der rote Faden dieser Serie. Teil 1 legt das Fundament, auf dem alle weiteren sieben Teile aufbauen.

BACnet ist eine Sprache: Objekte sind ihr Vokabular

BACnet steht für «Building Automation and Control Networks» und ist international als ASHRAE 135 sowie identisch als ISO 16484-5 genormt. Man kann sich den Standard als lebendige Sprache vorstellen: Ihr Vokabular sind die Objekte, ihre Grammatik sind die Properties, und ihre Redewendungen sind die Services.

Ein BACnet-Objekt ist die kleinste sinnvolle Informationseinheit, die eine einzelne Funktion vollständig abbildet. Der Raumtemperaturfühler wird zu einem Objekt. Die Pumpe, die geschaltet wird, wird zu einem Objekt. Der Sollwert, den der Betreiber verstellen darf, wird zu einem Objekt.

Der entscheidende Punkt: Ein Objekt ist nicht bloss ein Messwert, sondern ein kleines, genormtes Datenblatt. Es liefert den Wert mitsamt seinem Kontext, Name, Einheit, Gültigkeit. Weil ASHRAE 135 diesen Aufbau verbindlich festlegt, versteht jedes BACnet-fähige System die Struktur sofort, egal von welchem Hersteller das Gerät stammt.

Kurz erklärt: Objekt statt Datenpunkt. Umgangssprachlich ist ein «Datenpunkt» einfach ein Wert im System. Ein BACnet-Objekt dagegen ist ein normiertes Gebilde mit fest definierten Eigenschaften. Jeder Datenpunkt, der über BACnet läuft, ist als Objekt eines bestimmten Typs abgebildet. Wer in Objekten denkt statt in losen Datenpunkten, plant von Anfang an strukturiert und herstellerunabhängig.

Die Anatomie: ein Objekt besteht aus Properties

Jedes Objekt setzt sich aus Eigenschaften zusammen, den Properties. Man kann sich ein Objekt als Steckbrief vorstellen, dessen Zeilen fest benannt sind. Diese Namen sind normiert und immer gleich geschrieben. Genau diese Einheitlichkeit macht eine Anlage les- und wartbar.

Die wichtigsten Pflicht-Properties eines messenden Objekts sind:

• Object_Identifier: die eindeutige Kennung innerhalb des Geräts, bestehend aus Objekttyp und Nummer, zum Beispiel (Analog Value, 12). Über sie findet das Leitsystem den Wert maschinell wieder.
• Object_Name: der sprechende Name, etwa AV_Raumtemp_2OG. Er ist im Gerät eindeutig und entscheidet massgeblich über die spätere Wartbarkeit.
• Object_Type: die Art des Objekts, zum Beispiel analog-value. Der Typ bestimmt, welche weiteren Properties überhaupt zulässig sind.
• Present_Value: der aktuelle Wert, also die eigentliche Information. Genau ihn lesen Regelung, Trend und Visualisierung.
• Units: die physikalische Einheit, etwa degrees-Celsius. Ohne definierte Einheit ist eine Zahl wertlos.
• Status_Flags: vier Statusbits, die anzeigen, ob dem Wert zu trauen ist.

Dazu kommen optionale Properties wie Description für einen Klartext oder Reliability für die genauere Störungsdiagnose. Welche Property Pflicht und welche optional ist, legt ASHRAE 135 für jeden Objekttyp exakt fest. Das ist keine Spitzfindigkeit, sondern die Grundlage jeder sauberen Ausschreibung: Wer weiss, was Pflicht ist, kann es einfordern und bei der Abnahme prüfen.

Status_Flags: warum ein Messwert allein nicht genügt

Ein verbreiteter Irrtum ist die Annahme, der Present_Value sei die ganze Wahrheit. Ist er nicht. Ein Fühler kann 22 Grad melden, obwohl er defekt ist und gar nicht mehr misst. Deshalb definiert ASHRAE 135 für jedes messende Objekt die vier Status_Flags:

• In_Alarm: das Objekt befindet sich in einem Alarmzustand.
• Fault: es liegt eine Störung vor, etwa ein Fühlerbruch. Der Wert ist dann nicht vertrauenswürdig.
• Overridden: der Wert wurde vor Ort manuell übersteuert, zum Beispiel per Handschalter.
• Out_Of_Service: das Objekt ist ausser Betrieb, der Present_Value wird nicht mehr aktualisiert.

Zwei Objekte können denselben Wert zeigen und trotzdem völlig unterschiedlich zu bewerten sein. Erst die Status_Flags entscheiden, ob ein Wert für Regelung, Alarmierung und Auswertung taugt. Wer sie ignoriert, regelt im schlimmsten Fall auf eine Zahl, die nichts mehr mit der Realität zu tun hat.

Services: wie Objekte kommunizieren

Objekte beschreiben, welche Information es gibt. Damit Geräte sie austauschen, definiert ASHRAE 135 zusätzlich Services, also standardisierte Anfragen und Meldungen. Für den Einstieg genügen zwei Muster.

Beim klassischen Polling fragt das Leitsystem einen Wert in festen Abständen ab, auch wenn sich nichts ändert. Einfach, aber datenintensiv. Eleganter ist Change of Value (COV): Das Objekt meldet von sich aus, sobald sich sein Present_Value über eine festgelegte Schwelle hinaus ändert. Gleiche Information, deutlich weniger Netzlast. Diese Schwelle steckt im COV_Increment, ein kleines Property mit grosser Wirkung, das uns in Teil 4 (Trending) und Teil 5 (Alarming) wieder begegnet.

Der Schweizer Rahmen: die KBOB-Empfehlung

International gilt ASHRAE 135 / ISO 16484-5. In der Schweiz kommt für öffentliche Bauherrschaften eine entscheidende Ergänzung dazu.

KBOB sagt dazu: Die KBOB-Empfehlung «BACnet Anwendung», Version 2.0 (Juli 2021) ist der massgebende Schweizer Anwendungsrahmen. Sie legt fest, welche Objekttypen unterstützt werden müssen, welche BIBBs und Geräteprofile gelten und nach welchen Konventionen Properties wie Object_Name, Description und Units belegt werden. Zusätzlich stellt sie Werkzeuge für die Praxis bereit: Prüf-Checklisten (Anhang C1/C2), eine Entscheidungsmatrix (E1) sowie Vorlagen für Zustands- und Eventmeldetexte (T1/T2). Der Standard sagt, was möglich ist, die KBOB-Empfehlung sagt, was in der Schweiz gefordert wird.

Wichtig: Grössere Betreiber wie Universitätsspitäler oder einzelne Kantone ergänzen die KBOB-Empfehlung durch eigene, teils strengere Vorgaben, etwa eine festgelegte BACnet-Protokollrevision oder detaillierte Namenskonventionen. Die KBOB ist die Basis, nicht das Ende der Planung. Massgebend für Objekte und Datenpunkte sind KBOB-Empfehlung, SIA 386.110 und ISO 16484.

Aus der Praxis: die häufigsten Missverständnisse

Aus unseren BACnet-Analysen kehren dieselben Grundfehler immer wieder, fast alle lassen sich auf ein fehlendes Objektverständnis zurückführen:

• «BACnet gefordert» genügt. Das Wort «BACnet» in der Ausschreibung sagt nichts über Objekttypen, Pflicht-Properties, Namenskonventionen oder den geforderten PICS aus. Ohne diese Angaben liefert jeder Hersteller sein Hausmodell: interoperabel ist das selten.
• Present_Value ohne Status_Flags auswerten. Wer im Monitoring nur den Zahlenwert nimmt, übersieht Fühlerbrüche, Handübersteuerungen und Ausser-Betrieb-Zustände. Ein plausibel aussehender Wert kann komplett ungültig sein.
• Object_Name uneinheitlich oder herstellerdefiniert. Ohne durchgängige Namenskonvention wird jede spätere Wartung, Migration und Auswertung zur Sucharbeit. Die Namensstruktur entscheidet über die Betriebsqualität: Details in Teil 2.
• Alles auf optionale oder proprietäre Properties bauen. Was heute komfortabel ist, wird beim Herstellerwechsel zur Sackgasse. Als Faustregel gilt: Die betriebskritischen Funktionen müssen über Pflicht-Properties abbildbar sein.
• COV_Increment «irgendwie» gesetzt. Werkseinstellungen passen selten zum realen Bedarf. Zu fein bedeutet Netzlast, zu grob bedeutet blinde Flecken in Trend und Alarm.

Was das für Betrieb und Übergabe bedeutet

Für Betreiber ist die Konsequenz einfach: Eine Anlage ist nur so gut, wie ihre Objektstruktur dokumentiert ist. Verlangen Sie bei der Übergabe nicht irgendeine Datenpunktliste, sondern eine, die pro Objekt Object_Type, Object_Identifier, Object_Name, Einheit und, wo relevant, COV_Increment und Alarmzuordnung ausweist. Diese Liste ist Ihre Landkarte für jede spätere Wartung, Erweiterung oder Betriebsoptimierung.

Und für Planer und Bauherren gilt: Wer die Objektsprache versteht, kann eine BACnet-Offerte inhaltlich prüfen, statt auf das Etikett «BACnet-fähig» zu vertrauen. Genau darum geht es in dieser Serie.

Fazit

BACnet ist eine Sprache, und ihr Vokabular sind Objekte, ihre Grammatik sind Properties, ihre Redewendungen sind Services. Wer diese drei Ebenen einmal sauber verinnerlicht hat, versteht die restlichen sieben Teile dieser Serie nicht nur, sondern kann sie direkt in Planung, Ausschreibung und Betrieb anwenden. Aus «wir haben BACnet» wird dann «wir wissen, was unsere BACnet-Anlage kann, und was wir von ihr verlangen».

In Teil 2 steigen wir in die Arbeitspferde jeder Anlage ein: die analogen und digitalen Objekte (AI, AO, AV, BI, BO, BV), ihre Properties, ihre Einheiten und die Frage, warum eine fehlende oder falsche Einheit im Betrieb überraschend teuer 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)
• SIA 386.110
• Eigene Planungserfahrung WENGET