Analoge & digitale Objekte: Das Fundament der BACnet-Datenpunktstruktur

Analog oder binär, Input, Output oder Value, hinter sechs schlichten Kürzeln steckt die gesamte Datenpunktstruktur, auf der jede BACnet-Anlage im Alltag läuft. Wer sie einmal verstanden hat, liest jede Datenpunktliste wie ein Buch.

In Teil 1 haben wir das Fundament gelegt: BACnet ist eine Sprache, und ihre Objekte sind das Vokabular. Jetzt kommen die Arbeitspferde jeder Anlage ins Spiel, die analogen und binären Objekte. Sie bilden ab, was ein Fühler misst, was ein Ventil an Befehl erhält und welcher Sollwert im Regler hinterlegt ist. Erst mit ihnen wird aus einer Sammlung von Geräten eine lesbare und betreibbare Anlage.

Sechs Objekttypen genügen, um den weitaus grössten Teil einer HLK-Anlage abzubilden: Analog Input, Analog Output und Analog Value sowie Binary Input, Binary Output und Binary Value. Kurz AI, AO, AV, BI, BO, BV. Dieser Teil zeigt, was jeder Typ kann, welche Properties er zwingend braucht und an welchen Stellen in der Praxis regelmässig Geld verloren geht.

Zwei Fragen, sechs Objekttypen

Die Namen der sechs Objekttypen sind kein Zufall, sondern folgen einem klaren Raster. Zwei Fragen genügen, um jeden Datenpunkt sicher einzuordnen.

Die erste Frage lautet: Ist der Wert stufenlos oder kennt er nur zwei Zustände? Ein stufenloser Wert wie eine Temperatur, ein Druck oder eine Ventilstellung ist analog. Ein Wert mit genau zwei Zuständen wie Ein und Aus oder Auf und Zu ist binär.

Die zweite Frage lautet: Woher stammt der Wert? Ein gemessener Wert, der aus dem Feld ins System gelesen wird, ist ein Input. Ein Befehl, den das System ans Feld ausgibt, ist ein Output. Ein Wert, der nur im Gerät lebt und weder direkt gemessen noch direkt geschaltet wird, ist ein Value.

Kurz erklärt: Input, Output und Value. Input und Output beschreiben immer die Sicht des Automationsgeräts. Ein Input kommt von aussen herein, etwa vom Fühler. Ein Output geht nach aussen hinaus, etwa zum Ventil. Ein Value dagegen ist eine interne Grösse ohne eigene Hardwareklemme, zum Beispiel ein Sollwert, ein berechneter Mittelwert oder ein Freigabemerker. Wer diese drei Rollen sauber auseinanderhält, plant eine Anlage, die sich später ohne Rätselraten bedienen lässt.

Aus der Kombination beider Fragen ergeben sich genau sechs Felder und damit die sechs Objekttypen, die den Alltag bestimmen. Alles Weitere, das wir in dieser Serie behandeln, baut auf diesem Raster auf.

Die analogen Objekte: AI, AO und AV

Analoge Objekte tragen stufenlose Werte. Ihr Present_Value ist eine Fliesskommazahl, und genau deshalb ist bei ihnen die Einheit so entscheidend. Drei Rollen sind zu unterscheiden:

• Analog Input (AI): der gemessene Wert aus dem Feld, etwa Raumtemperatur, Vorlauftemperatur, Differenzdruck oder Volumenstrom. Der Present_Value ist aus Sicht des Leitsystems lesend. Geschrieben wird er vom Fühler, nicht vom Bediener.
• Analog Output (AO): der stufenlose Stellbefehl ans Feld, typischerweise eine Ventil- oder Klappenstellung von 0 bis 100 Prozent oder eine Drehzahlvorgabe. Hier wird der Present_Value aktiv geschrieben, und zwar über eine Prioritätenlogik, auf die wir gleich zurückkommen.
• Analog Value (AV): die interne stufenlose Grösse ohne eigene Klemme, etwa ein Temperatursollwert, ein berechneter Mittelwert, ein Grenzwert oder ein Parameter. Ein AV ist der klassische Ort für alles, was der Bediener verstellen darf, ohne dass eine Hardware direkt daranhängt.

Ein einfaches Beispiel aus der Lüftung zeigt das Zusammenspiel. Der AI misst die Zulufttemperatur. Ein AV hält den Sollwert, den der Betreiber anpassen kann. Der Regler vergleicht beide und schreibt das Ergebnis als AO auf das Ventil des Lufterhitzers. Drei Objekttypen, ein Regelkreis, vollständig herstellerunabhängig beschrieben.

Die binären Objekte: BI, BO und BV

Binäre Objekte kennen genau zwei Zustände. Ihr Present_Value ist entweder active oder inactive. Auch hier gelten dieselben drei Rollen:

• Binary Input (BI): die gemeldete Rückmeldung aus dem Feld, etwa eine Betriebsmeldung einer Pumpe, ein Strömungswächter oder eine Sammelstörung. Der BI sagt, in welchem Zustand sich etwas tatsächlich befindet.
• Binary Output (BO): der Schaltbefehl ans Feld, etwa eine Pumpe ein, ein Ventil auf oder eine Freigabe an einen Frequenzumrichter. Wie beim AO wird der Present_Value über die Prioritätenlogik geschrieben.
• Binary Value (BV): der interne Schaltzustand ohne eigene Klemme, etwa ein Freigabemerker, ein Betriebsartenbit oder ein softwareseitiges Verriegelungssignal.

Ein wichtiges Detail bei BI und BO ist die Property Polarity. Sie legt fest, ob der physikalische Kontakt normal oder invertiert interpretiert wird. Ist die Polarity falsch gesetzt, meldet die Anlage «Pumpe aus», während die Pumpe läuft. Solche Vorzeichenfehler gehören zu den unauffälligsten und zugleich ärgerlichsten Fehlern in der Inbetriebnahme, weil die Werte auf den ersten Blick plausibel wirken.

Kurz erklärt: active und inactive statt 1 und 0. BACnet beschreibt binäre Zustände bewusst als active und inactive, nicht als 1 und 0. Was active im Betrieb konkret bedeutet, also Pumpe läuft oder Störung liegt an, ergibt sich erst aus Object_Name, Description und der Polarity. Genau deshalb ist eine saubere Beschriftung bei binären Objekten kein Schmuck, sondern Voraussetzung für den Betrieb.

Units: die teuerste Kleinigkeit der Gebäudeautomation

Bei analogen Objekten entscheidet die Property Units darüber, ob eine Zahl überhaupt eine Bedeutung hat. Der Wert 21 ist ohne Einheit wertlos. Erst degrees-Celsius, percent oder pascal machen daraus eine Information, mit der Regelung, Trend und Auswertung arbeiten können.

BACnet definiert dafür eine feste Liste von Einheiten. Diese Einheit ist nicht bloss ein Etikett für die Anzeige, sondern eine verbindliche Zusicherung über die physikalische Natur des Werts. Wird sie falsch oder gar nicht gesetzt, entstehen Folgefehler, die weit teurer sind als der ursprüngliche Flüchtigkeitsfehler.

Drei typische Szenarien zeigen das Ausmass:

• Fehlende Einheit: die Visualisierung zeigt nackte Zahlen, und niemand weiss, ob 15 nun Grad, Prozent oder Kilopascal bedeutet. Jede spätere Auswertung beginnt mit Detektivarbeit.
• Falsche Einheit: ein Druck wird als bar statt als pascal deklariert. Grenzwerte und Alarme rechnen dann um Faktoren daneben, ohne dass es sofort auffällt.
• Uneinheitliche Einheit: dieselbe Grösse trägt an verschiedenen Stellen verschiedene Einheiten. Übergreifende Auswertungen über mehrere Anlagen werden dadurch praktisch unmöglich.

Die Lehre ist einfach. Units gehören in jede Ausschreibung, in jede Datenpunktliste und in jede Abnahme. Eine Anlage, deren Einheiten nicht durchgängig und korrekt gesetzt sind, ist nicht fertig, egal wie schön die Visualisierung aussieht.

Priority_Array: wer darf den Ausgang stellen?

Bei ausgebenden Objekten, also AO und BO, stellt sich eine Frage, die es bei Inputs gar nicht gibt: Was passiert, wenn mehrere Quellen gleichzeitig denselben Ausgang stellen wollen? Die Zeitsteuerung möchte die Pumpe einschalten, die Handbedienung am Schrank möchte sie ausschalten, und ein Sicherheitsprogramm möchte sie zwingend sperren. Wer gewinnt?

BACnet löst das mit einem eleganten Mechanismus, dem Priority_Array. Der Present_Value eines Ausgangs wird nicht einfach überschrieben, sondern über sechzehn Prioritätsebenen bestimmt. Jede schreibende Quelle legt ihren Wunsch auf ihrer Ebene ab. Wirksam wird immer der Wunsch mit der höchsten Priorität. Fällt dieser weg, greift automatisch die nächsttiefere Ebene.

Kurz erklärt: Priority_Array und Relinquish_Default. Die sechzehn Ebenen sind fest geordnet, von der Handübersteuerung und Sicherheitsfunktionen ganz oben bis zu automatischen Programmen weiter unten. Gibt keine Ebene einen Wert vor, greift der Relinquish_Default, also der definierte Ruhewert des Ausgangs. Wer diesen Ruhewert nicht bewusst festlegt, überlässt dem Zufall, was die Anlage tut, sobald alle aktiven Befehle zurückgezogen werden.

Für die Planung folgt daraus eine klare Regel. Sicherheits- und Handfunktionen gehören auf hohe Prioritäten, normale Automatik auf tiefe. Und der Relinquish_Default muss für jeden Ausgang bewusst gewählt sein, damit die Anlage im Zweifel in einen sicheren Zustand fällt. Wir vertiefen die koordinierte Ansteuerung in Teil 7 dieser Serie, wenn es um Command- und Loop-Objekte geht.

COV_Increment, Status_Flags und Reliability im Alltag

Drei Properties aus Teil 1 verdienen bei den analogen und binären Objekten einen zweiten Blick, weil sie im Betrieb den Unterschied machen.

Das COV_Increment betrifft vor allem analoge Objekte. Es legt fest, um welchen Betrag sich der Present_Value ändern muss, bevor das Objekt von sich aus eine Meldung schickt. Ein zu klein gewähltes Increment flutet das Netz mit Meldungen bei jedem Messrauschen. Ein zu gross gewähltes Increment lässt echte Veränderungen unbemerkt. Sinnvoll ist ein Wert, der knapp über dem normalen Rauschen des Fühlers liegt.

Die Status_Flags gelten für analoge und binäre Objekte gleichermassen. Sie sagen, ob dem Present_Value zu trauen ist. Gerade bei binären Rückmeldungen wird das gern übersehen: Eine Betriebsmeldung, deren Fault-Flag gesetzt ist, darf nicht als gültige Rückmeldung verwendet werden, auch wenn sie active zeigt.

Die Property Reliability ergänzt dieses Bild um die Ursache. Sie sagt nicht nur, dass ein Wert unzuverlässig ist, sondern warum, etwa wegen Fühlerbruch, Kurzschluss oder fehlender Kommunikation. Für die Störungsdiagnose im Betrieb ist Reliability daher ausgesprochen wertvoll, wird in der Praxis aber selten konsequent ausgewertet.

Aus der Praxis: die häufigsten Missverständnisse

Aus unseren BACnet-Analysen kehren bei den analogen und binären Objekten dieselben Grundfehler immer wieder. Fast alle lassen sich mit sauberer Planung vermeiden:

• Value-Objekte als Input deklariert. Sollwerte und berechnete Grössen werden fälschlich als AI oder BI angelegt. Der Bediener kann sie dann nicht verstellen, oder die Automatik überschreibt sie ungewollt. Sollwerte gehören in AV oder BV.
• Units vergessen oder aus der Werksvorlage übernommen. Fehlende oder falsche Einheiten sind der häufigste Einzelfehler überhaupt. Er macht Trends unbrauchbar und Grenzwerte unzuverlässig.
• Relinquish_Default nicht definiert. Ohne bewusst gesetzten Ruhewert fällt ein Ausgang beim Rückzug aller Befehle in einen undefinierten Zustand. Im schlechtesten Fall bleibt ein Ventil offen oder eine Pumpe läuft weiter.
• Polarity bei BI und BO falsch gesetzt. Ein Vorzeichenfehler dreht Betriebs- und Störmeldungen um. Die Werte wirken plausibel, sind aber schlicht verkehrt.
• COV_Increment auf Werkseinstellung belassen. Zu fein bedeutet Netzlast, zu grob bedeutet blinde Flecken in Trend und Alarm. Die Werkseinstellung passt fast nie zum realen Bedarf.
• Status_Flags im Monitoring ignoriert. Wer nur den Zahlen- oder Schaltwert nimmt, übersieht Fühlerbrüche und Handübersteuerungen und regelt womöglich auf eine ungültige Grösse.

Was das für Betrieb und Übergabe bedeutet

Für Betreiber lässt sich der ganze Teil auf eine praktische Forderung eindampfen. Verlangen Sie bei der Übergabe eine Datenpunktliste, die für jedes analoge und binäre Objekt den Object_Type, den Object_Identifier, den Object_Name, die Einheit und, wo relevant, den Relinquish_Default, die Polarity sowie das COV_Increment ausweist. Diese Angaben sind keine Kür, sondern die Grundlage für jede spätere Wartung, Erweiterung und Betriebsoptimierung.

Für Planer und Bauherren gilt der Umkehrschluss. Wer die sechs Objekttypen und ihre Pflicht-Properties kennt, kann sie in der Ausschreibung konkret vorschreiben und bei der Abnahme prüfen. Aus der vagen Anforderung «BACnet-fähig» wird eine überprüfbare Liste von Objekttypen, Einheiten und Ruhewerten. Genau diese Konkretheit trennt eine interoperable Anlage von einer, die es nur auf dem Datenblatt ist.

Wichtig: Massgebend für Objekte und Datenpunkte sind in der Schweiz die KBOB-Empfehlung «BACnet Anwendung», die einschlägigen SIA-Normen der Reihe 386 sowie ISO 16484. Sie legen fest, welche Objekttypen unterstützt werden müssen und nach welchen Konventionen Object_Name, Description und Units zu belegen sind. Grössere Betreiber ergänzen diesen Rahmen häufig durch eigene, teils strengere Namens- und Einheitenvorgaben.

Fazit

Analoge und binäre Objekte sind die Arbeitspferde jeder BACnet-Anlage. Zwei Fragen ordnen sie vollständig ein: stufenlos oder binär, und gemessen, gestellt oder intern. Wer AI, AO, AV, BI, BO und BV mit ihren Pflicht-Properties beherrscht, versteht den Grossteil jeder Datenpunktliste und erkennt Planungsfehler, bevor sie im Betrieb Geld kosten. Die drei grössten Hebel sind dabei immer dieselben: korrekte Einheiten, ein bewusst gesetzter Ruhewert und der ehrliche Blick auf die Status_Flags.

In Teil 3 verlassen wir die Welt von Ein und Aus. Dann geht es um Multi-State-Objekte und Programm-Objekte, mit denen sich Betriebsarten wie Auto, Hand, Aus und Alarm sauber abbilden lassen, und um die Frage, warum lesbare Zustandstexte über die Betriebsqualität einer Anlage entscheiden.

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