Multi-State Objekte & Programm-Objekte: Mehr als Ein und Aus

Manche Zustände lassen sich nicht in Ein und Aus pressen. Eine Anlage kennt Auto, Hand, Aus und Alarm. Eine Lüftung fährt Stufe 1, 2 oder 3. Eine Kältemaschine ist bereit, im Anlauf, in Betrieb oder gestört. Für genau solche Fälle gibt es in BACnet die Multi-State-Objekte, und mit den Programm-Objekten kommt eine weitere, oft missverstandene Objektfamilie hinzu.

In Teil 2 haben wir die analogen und binären Objekte kennengelernt, die Arbeitspferde jeder Anlage. Binäre Objekte beherrschen genau zwei Zustände, active und inactive. Das reicht für eine Pumpe, die läuft oder steht. Sobald ein Datenpunkt aber drei, vier oder mehr klar benannte Zustände hat, wird das binäre Modell unhandlich. Man müsste mehrere Bits kombinieren und ihre Bedeutung irgendwo dokumentieren. Genau diese Lücke schliessen die Multi-State-Objekte.

Dieser Teil zeigt, wie Multi-State Input, Output und Value aufgebaut sind, warum lesbare Zustandstexte über die Betriebsqualität einer Anlage entscheiden und wo in der Praxis regelmässig gezählt und beschriftet wird, dass es später Ärger gibt. Danach schauen wir uns die Programm-Objekte an und klären die wichtigste Frage gleich zu Beginn: Wann sind sie sinnvoll und wann besser nicht.

Warum Ein und Aus nicht immer genügen

Stellen Sie sich die Betriebsart eines Aggregats vor: Auto, Hand, Aus und Alarm. Das sind vier Zustände, die sich gegenseitig ausschliessen. Mit binären Objekten liesse sich das nur umständlich abbilden, etwa über zwei oder drei einzelne Merker, deren Kombination man kennen muss. Ein Aussenstehender müsste raten, was «Bit 1 aktiv, Bit 2 inaktiv» bedeutet.

Ein Multi-State-Objekt löst das in einem einzigen, sauber benannten Datenpunkt. Es trägt einen von mehreren nummerierten Zuständen und liefert zu jedem Zustand einen Klartext mit. Aus «Bit 1 aktiv, Bit 2 inaktiv» wird schlicht «Hand». Das ist nicht nur eleganter, sondern auch betriebssicher, weil die Bedeutung im Objekt selbst steckt und nicht in einer separaten Tabelle, die niemand pflegt.

Typische Einsatzfälle in der Gebäudetechnik sind Betriebsarten von Aggregaten, Lüftungsstufen, die Zustände einer Kältemaschine oder eines Kessels, Ventilstellungen in Stufen sowie zusammengefasste Statusanzeigen. Überall dort, wo ein Datenpunkt mehr als zwei, aber eine überschaubare und feste Zahl von Zuständen kennt, ist das Multi-State-Objekt das richtige Werkzeug.

Die drei Multi-State-Objekte: MSI, MSO und MSV

Auch die Multi-State-Familie folgt dem vertrauten Raster aus Teil 2. Die Frage nach der Herkunft des Werts, gemessen, gestellt oder intern, teilt sie in drei Rollen:

• Multi-State Input (MSI): der gemeldete Zustand aus dem Feld, etwa der Betriebszustand einer Kältemaschine, den das Gerät über mehrere Sammelmeldungen zurückgibt. Der Present_Value ist aus Sicht des Leitsystems lesend.
• Multi-State Output (MSO): die gestellte Vorgabe ans Feld, etwa die gewünschte Lüftungsstufe oder eine Betriebsartenvorgabe an ein Aggregat. Wie bei AO und BO wird der Present_Value über eine Prioritätenlogik geschrieben.
• Multi-State Value (MSV): der interne Zustand ohne eigene Klemme, etwa die softwareseitige Betriebsart einer Anlagengruppe oder ein zentraler Modus, den mehrere Programme lesen. Ein MSV ist der klassische Ort für eine Betriebsart, die der Bediener umschalten darf.

Ein Beispiel aus der Lüftung zeigt das Zusammenspiel. Ein MSV hält die zentrale Betriebsart der Anlage, etwa Auto, Hand oder Aus. Ein MSO gibt die konkrete Lüftungsstufe an den Frequenzumrichter vor. Und ein MSI meldet den vom Gerät tatsächlich erreichten Zustand zurück. Drei Objekte, ein durchgängig lesbares Bild vom Sollzustand bis zur Rückmeldung.

Present_Value: eine ganze Zahl, die bei Eins beginnt

Hier liegt der wichtigste technische Unterschied zu den analogen Objekten. Der Present_Value eines Multi-State-Objekts ist keine Fliesskommazahl, sondern eine vorzeichenlose ganze Zahl. Sie nummeriert den aktuellen Zustand durch. Und, das ist der entscheidende Punkt: Die Zählung beginnt bei Eins, nicht bei Null.

Ein Multi-State-Objekt mit vier Zuständen hat also die gültigen Werte 1, 2, 3 und 4. Der Wert 1 steht für den ersten Zustand, der Wert 4 für den vierten. Ein Present_Value von 0 ist ungültig. Diese scheinbar kleine Konvention ist die Quelle eines der hartnäckigsten Fehler in der Praxis, weil Programmierer aus anderen Welten gewohnt sind, ab Null zu zählen. Wird die Zuordnung um eine Stelle verschoben, zeigt die Anlage «Hand», wo «Auto» gemeint ist, und alle Zahlen wirken trotzdem plausibel.

Kurz erklärt: Zwei Properties legen den Wertebereich fest. Number_Of_States gibt an, wie viele Zustände das Objekt kennt. Der Present_Value darf sich nur zwischen 1 und diesem Wert bewegen. Wer die Zahl der Zustände nachträglich ändert, muss zwingend die zugehörigen Texte und alle Verknüpfungen mitziehen, sonst zeigen Visualisierung und Alarmierung auf die falschen Zustände.

State_Text: der Unterschied zwischen Daten und Information

Eine nackte Zahl wie 3 sagt einem Betreiber nichts. Erst der zugehörige Klartext macht daraus eine Information. Genau diese Aufgabe erfüllt die Property State_Text. Sie ist eine geordnete Liste von Zeichenketten, in der jeder Zustandsnummer ihr Klartext zugeordnet ist. Beim Present_Value 3 liest die Visualisierung den dritten Eintrag der Liste, etwa «Stufe 3» oder «Alarm».

State_Text ist bei Multi-State-Objekten das, was Units bei den analogen Objekten ist: die Property, die über Verständlichkeit oder Ratespiel entscheidet. Fehlt sie oder ist sie unvollständig, sieht der Betreiber nur Zahlen und muss die Bedeutung anderswo nachschlagen. Sind die Texte kryptisch abgekürzt oder in einer fremden Sprache aus der Werksvorlage übernommen, ist der Effekt derselbe.

Drei typische Szenarien zeigen, was auf dem Spiel steht:

• Fehlender Zustandstext: die Visualisierung zeigt «Modus: 2», und niemand weiss, ob das nun Hand, Stufe 2 oder Störung bedeutet. Jede Störungssuche beginnt mit dem Griff zur Herstellerdokumentation.
• Falsch zugeordneter Text: die Texte sind um eine Position verschoben, meist als Folge des Zählfehlers von Null gegen Eins. Die Anzeige lügt konsequent, ohne dass es sofort auffällt.
• Uneinheitliche Texte: dieselbe Betriebsart heisst an einer Stelle «Automatik», an anderer «Auto» und an dritter «AUT». Übergreifende Auswertungen und Suchfunktionen scheitern an dieser Uneinheitlichkeit.

Die Lehre ist dieselbe wie bei den Units. Zustandstexte gehören in jede Ausschreibung, in jede Datenpunktliste und in jede Abnahme. Ein Multi-State-Objekt ohne saubere, vollständige und einheitliche State_Text-Liste ist nicht fertig, egal wie richtig die Zahl dahinter ist.

Priority_Array: auch der Zustand will koordiniert gestellt werden

Beim Multi-State Output gilt dieselbe Frage wie bei den analogen und binären Ausgängen aus Teil 2: Was passiert, wenn mehrere Quellen gleichzeitig einen Zustand vorgeben wollen? Die Zeitsteuerung möchte auf Stufe 1 herunterfahren, die Handbedienung möchte Stufe 3, und ein Sicherheitsprogramm möchte in den sicheren Zustand zwingen.

Die Antwort ist auch hier der Priority_Array mit seinen sechzehn Prioritätsebenen. Jede schreibende Quelle legt ihren gewünschten Zustand auf ihrer Ebene ab, wirksam wird der Wunsch mit der höchsten Priorität. Fällt er weg, greift die nächsttiefere Ebene, und liegt gar kein Befehl an, gilt der Relinquish_Default, also der bewusst definierte Ruhezustand des Ausgangs.

Für die Planung folgt daraus dieselbe Regel wie bei AO und BO. Sicherheits- und Handfunktionen gehören auf hohe Prioritäten, die normale Automatik auf tiefe, und der Relinquish_Default muss bewusst gewählt sein. Bei einem MSO ist das besonders wichtig, denn der Ruhezustand ist hier kein neutraler Nullwert, sondern ein konkret benannter Zustand. Es macht einen grossen Unterschied, ob eine Lüftung im Zweifel auf «Aus» oder auf «Stufe 1» zurückfällt.

Aus der Praxis: die häufigsten Missverständnisse bei Multi-State

Aus unseren BACnet-Analysen kehren bei den Multi-State-Objekten immer wieder dieselben Fehler zurück. Fast alle lassen sich mit sorgfältiger Planung vermeiden:

• Vom Null-Index ausgegangen. Der Klassiker. Weil der Present_Value bei Eins beginnt, aber ab Null zugeordnet wurde, sind alle Zustände um eine Position verschoben. Die Anzeige wirkt stimmig und ist doch durchgehend falsch.
• State_Text vergessen oder aus der Werksvorlage übernommen. Ohne saubere Zustandstexte bleibt dem Betreiber nur die nackte Zahl. Fremdsprachige oder kryptische Werkstexte sind kaum besser.
• Multi-State missbraucht, wo Aufzählung nicht passt. Multi-State eignet sich für sich gegenseitig ausschliessende Zustände. Wer damit Werte abbildet, die eigentlich analog sind oder gleichzeitig gelten können, erzwingt später umständliche Umwege.
• Zu viele Zustände in ein Objekt gepackt. Wird jede erdenkliche Kombination als eigener Zustand geführt, entsteht eine unübersichtliche Liste, die weder Bediener noch Alarmierung sinnvoll nutzen können.
• Relinquish_Default beim MSO nicht definiert. Ohne bewusst gesetzten Ruhezustand fällt der Ausgang beim Rückzug aller Befehle in einen undefinierten Zustand, der im schlechtesten Fall alles andere als sicher ist.
• Number_Of_States geändert, Texte nicht. Wird die Zahl der Zustände erweitert, ohne die State_Text-Liste und die Verknüpfungen mitzuziehen, zeigen Anzeige und Alarm auf die falschen Zustände.

Programm-Objekte: Logik, die im Gerät wohnt

Kommen wir zur zweiten Objektfamilie dieses Teils, den Programm-Objekten. Ein Program Object bildet ein Anwendungsprogramm ab, das im Automationsgerät selbst läuft. Über das Objekt lässt sich dieses Programm von aussen beobachten und in Grenzen steuern, ohne dass man die eigentliche Programmiersprache des Geräts kennt.

Das Herzstück ist die Property Program_State. Sie zeigt, in welchem Zustand sich das Programm gerade befindet, etwa bereit, ladend, laufend, wartend oder angehalten. Über die Property Program_Change lässt sich ein Steuerbefehl geben, etwa starten, anhalten oder neu starten. Ergänzende Properties wie Reason_For_Halt geben Auskunft, warum ein Programm gestoppt hat. So wird ausführbare Logik im Gerät über ein standardisiertes BACnet-Objekt sichtbar und bedienbar.

Kurz erklärt: Program Object ist nicht gleich Programmierung. Das Objekt steuert und beobachtet ein Programm, es enthält die eigentliche Logik nicht in lesbarer Form. Wie das Programm intern arbeitet, hängt vollständig vom Hersteller ab. Das Program Object ist also ein Fenster auf die Logik, kein herstellerneutrales Abbild davon. Genau daraus ergibt sich seine grösste Stärke und zugleich sein grösstes Risiko.

Wann Programm-Objekte sinnvoll sind, und wann nicht

Programm-Objekte sind mächtig, und Mächtigkeit will mit Bedacht eingesetzt sein. Sinnvoll sind sie, wenn eine geschlossene, klar umrissene Logik im Gerät laufen muss, die von aussen kontrolliert gestartet und gestoppt werden soll, etwa eine komplexe Anlaufsequenz oder eine geräteinterne Sonderfunktion, die dokumentiert und übergeben wird.

Heikel werden sie, sobald wesentliche Anlagenlogik unsichtbar in solchen Programmen verschwindet. Dann entsteht eine Blackbox: Die Anlage tut Dinge, die in keiner Datenpunktliste stehen und die ein anderer Fachbetrieb bei einer späteren Erweiterung nicht nachvollziehen kann. Was als elegante Lösung beginnt, wird zur Abhängigkeit von genau einem Lieferanten, und das widerspricht dem Grundgedanken von BACnet, der Interoperabilität.

Für Ausschreibung und Übergabe ergibt sich daraus eine klare Haltung. Wo Programm-Objekte eingesetzt werden, müssen ihr Zweck, ihr Verhalten und ihre Steuerbefehle vollständig dokumentiert sein. Verdeckte, undokumentierte Programmlogik gehört nicht in eine interoperable Anlage. Im Zweifel ist die nachvollziehbare Kombination aus sichtbaren Objekten und einer klar geplanten Regelstrategie der verdeckten Programmierung im Gerät vorzuziehen.

Was das für Betrieb und Übergabe bedeutet

Für Betreiber lässt sich dieser Teil auf zwei praktische Forderungen eindampfen. Verlangen Sie erstens bei jedem Multi-State-Objekt eine vollständige und einheitliche State_Text-Liste sowie die dokumentierte Zahl der Zustände, damit die Visualisierung Klartext statt nackter Zahlen zeigt. Verlangen Sie zweitens für jedes eingesetzte Program Object eine Beschreibung, was es tut, wie es gesteuert wird und in welchen Zuständen es sein kann.

Für Planer und Bauherren gilt der Umkehrschluss. Wer die Multi-State-Objekte und ihre 1-basierte Zählung kennt, kann Zustände, Texte und Ruhezustände in der Ausschreibung konkret vorschreiben und bei der Abnahme prüfen. Und wer weiss, welche Risiken verdeckte Programmlogik birgt, verlangt Transparenz statt Blackbox. Aus der vagen Anforderung «Betriebsarten steuerbar» wird so eine überprüfbare Liste aus Zuständen, Texten, Prioritäten und dokumentierten Programmen.

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 die Zustandstexte zu belegen sind. Grössere Betreiber ergänzen diesen Rahmen häufig durch eigene, teils strengere Vorgaben für Betriebsarten und Zustandsbezeichnungen.

Fazit

Multi-State-Objekte bilden ab, was sich nicht in Ein und Aus zwängen lässt: Betriebsarten, Stufen und mehrwertige Zustände. Drei Rollen ordnen sie ein, gemeldet, gestellt oder intern, als MSI, MSO und MSV. Zwei Dinge entscheiden über ihre Qualität: die 1-basierte Zählung des Present_Value, an der die häufigsten Fehler entstehen, und die State_Text-Liste, die aus Zahlen erst lesbare Information macht. Beim MSO kommt der bewusst gesetzte Ruhezustand hinzu.

Programm-Objekte machen Logik im Gerät sichtbar und steuerbar. Richtig eingesetzt und sauber dokumentiert sind sie ein nützliches Werkzeug. Verschwindet in ihnen dagegen wesentliche Anlagenlogik unsichtbar, entsteht eine Blackbox, die der Interoperabilität zuwiderläuft. Die Regel lautet daher: einsetzen, wo es Sinn ergibt, und immer vollständig dokumentieren.

In Teil 4 verlassen wir die einzelnen Zustände und wenden uns der Zeit zu. Dann geht es um Trend Log und Trend Log Multiple, also darum, wie BACnet Betriebsdaten aufzeichnet, wann sich COV-basiertes gegen intervallbasiertes Trending lohnt und wie man die Datenmengen von Anfang an richtig plant.

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