Loop & Command Objekte: Regelkreise und koordinierte Befehle in BACnet

Bis zu diesem Punkt der Serie ging es vor allem darum, wie eine Anlage Werte darstellt, meldet und zeitlich freigibt. In Teil 6 haben wir gesehen, wie Schedule- und Calendar-Objekte dafür sorgen, dass eine Anlage zur richtigen Zeit den richtigen Betriebszustand einnimmt. Doch ein Zeitprogramm gibt nur vor, welcher Wert wann gelten soll. Wie eine Anlage einen Sollwert tatsächlich einhält und wie sie mehrere Objekte in einem Zug koordiniert schaltet, ist Aufgabe von zwei ganz anderen Objekttypen.

Genau darum geht es in diesem Teil. Das Loop-Objekt ist der Regler von BACnet, es hält eine Grösse auf ihrem Sollwert, indem es fortlaufend nachstellt. Das Command-Objekt ist der Dirigent, es löst mit einem einzigen Befehl eine ganze Folge koordinierter Schreibvorgänge an mehrere Objekte aus. Beide Objekte gehören zur aktiven Seite der Gebäudeautomation, sie beobachten nicht nur, sie greifen ein.

Dieser Teil erklärt, wie ein Loop-Objekt eine PID-Regelung direkt im Gerät abbildet, welche Rolle die Parameter für Proportional-, Integral- und Differentialanteil spielen, wie ein Command-Objekt über eine Aktionsliste mehrere Objekte gleichzeitig ansteuert und worauf man bei beiden in Planung und Betrieb achten muss.

Das Loop-Objekt: Regelung als eigenständiges Objekt

Eine der häufigsten Aufgaben in der Gebäudeautomation ist das Halten einer Grösse auf einem Sollwert. Eine Raumtemperatur soll konstant einundzwanzig Grad betragen, ein Vorlauf einen bestimmten Wert einhalten, ein Kanaldruck stabil bleiben. Dahinter steht immer dasselbe Prinzip: Ein Regler vergleicht den gemessenen Istwert mit dem gewünschten Sollwert und stellt eine Stellgrösse so nach, dass die Abweichung möglichst klein wird.

In BACnet bildet das Loop-Objekt genau diesen Regelkreis als eigenständiges, über das Netzwerk sichtbares Objekt ab. Das ist bemerkenswert, denn Regelung findet oft tief im Programm einer Steuerung statt, wo sie von aussen unsichtbar bleibt. Ein Loop-Objekt macht die Regelung dagegen ansprechbar: Man kann den Sollwert, den Istwert, die Stellgrösse und die Reglerparameter über das Netzwerk lesen und, soweit freigegeben, auch verändern.

Der aktuelle Reglerausgang, also die berechnete Stellgrösse, steht in der Property Present_Value des Loop-Objekts. Sie ist das Ergebnis der laufenden Regelung und wird typischerweise an ein Stellglied geschrieben, etwa an ein Ventil oder eine Klappe. Damit ist das Loop-Objekt kein passiver Anzeigewert, sondern ein aktiv eingreifendes Objekt.

Sollwert, Istwert und Stellgrösse

Ein Loop-Objekt verbindet drei Grössen miteinander. Der Sollwert ist der Zielwert, den die Regelung anstrebt. Er kann fest hinterlegt sein oder über die Property Setpoint_Reference auf ein anderes Objekt verweisen, etwa auf einen Sollwert, der selbst wieder von einem Schedule vorgegeben wird. So entsteht die saubere Kette aus Teil 6: Der Zeitplan gibt den Sollwert vor, der Regler hält ihn ein.

Der Istwert ist die gemessene Grösse, die geregelt werden soll. Über die Property Controlled_Variable_Reference verweist das Loop-Objekt auf das Eingangsobjekt, das diesen Messwert liefert, etwa auf einen Analog-Input mit der Raumtemperatur. Der aktuelle Messwert steht in Controlled_Variable_Value. Der Regler kennt damit jederzeit die Differenz zwischen Soll und Ist, die sogenannte Regelabweichung.

Die Stellgrösse schliesslich ist das, was der Regler nach aussen gibt. Über die Property Manipulated_Variable_Reference verweist das Loop-Objekt auf das Objekt, an das die berechnete Stellgrösse geschrieben wird, typischerweise ein Analog-Output für ein Ventil oder eine Klappe. Ob der Regler bei steigendem Istwert seine Stellgrösse erhöhen oder verringern soll, legt die Property Action fest, die zwischen direkter und umgekehrter Wirkrichtung unterscheidet. Eine falsch gesetzte Wirkrichtung ist ein klassischer Grund dafür, dass eine Regelung wegläuft statt sich einzupendeln.

P, I und D: die drei Anteile der Regelung

Der Kern eines Loop-Objekts ist sein Regelalgorithmus, meist eine PID-Regelung. Die drei Buchstaben stehen für die drei Anteile, aus denen sich die Stellgrösse zusammensetzt, und jeder hat eine klar verständliche Aufgabe.

Der Proportionalanteil reagiert direkt auf die aktuelle Regelabweichung. Je grösser die Differenz zwischen Soll und Ist, desto kräftiger stellt der Regler nach. Seine Stärke bestimmt die Property Proportional_Constant. Ein hoher Wert lässt den Regler schnell reagieren, kann ihn aber zum Überschwingen bringen. Ein zu tiefer Wert macht die Regelung träge. Der Proportionalanteil allein hat allerdings eine Schwäche: Er hinterlässt eine bleibende Restabweichung, weil er nur dann eine Stellgrösse liefert, wenn überhaupt eine Abweichung besteht.

Genau diese Restabweichung beseitigt der Integralanteil. Er summiert die Abweichung über die Zeit auf und stellt so lange nach, bis sie verschwindet. Seine Wirkung steuert die Property Integral_Constant. Der Integralanteil sorgt dafür, dass der Istwert am Ende exakt den Sollwert erreicht, wirkt aber langsamer und kann bei zu starker Einstellung ebenfalls zu Schwingungen führen.

Der Differentialanteil schliesslich reagiert auf die Geschwindigkeit der Änderung. Ändert sich der Istwert schnell, wirkt er dämpfend und beugt einem Überschwingen vor. Er wird über die Property Derivative_Constant eingestellt und in der Praxis oft vorsichtig oder gar nicht genutzt, weil er empfindlich auf Messrauschen reagiert. Das Zusammenspiel dieser drei Anteile richtig einzustellen ist die eigentliche Kunst der Regelung.

Wo ein Loop-Objekt sinnvoll ist

Nicht jede Regelung muss als Loop-Objekt umgesetzt sein. Viele Hersteller regeln intern mit eigenen, hochoptimierten Algorithmen und stellen nach aussen nur die relevanten Werte als einzelne Objekte bereit. Das ist kein Nachteil, solange Sollwert, Istwert und Stellgrösse sichtbar und bedienbar bleiben. Ein Loop-Objekt ist dann besonders wertvoll, wenn die Regelung herstellerunabhängig sichtbar, prüfbar und anpassbar sein soll.

Der grosse Vorteil des Loop-Objekts liegt in seiner Transparenz. Weil Sollwert, Istwert, Stellgrösse und Parameter offen zugänglich sind, lässt sich das Verhalten der Regelung nachvollziehen, dokumentieren und bei Bedarf optimieren, ohne dass man auf ein herstellerspezifisches Werkzeug angewiesen ist. Gerade bei Anlagen mit vielen Beteiligten und langen Lebenszyklen ist das ein echter Gewinn.

Gleichzeitig ist ein Loop-Objekt kein Ersatz für sorgfältige Inbetriebnahme. Die Reglerparameter müssen zur Anlage passen und beim ersten Einregulieren bewusst eingestellt werden. Werden sie einfach aus einem anderen Projekt übernommen oder auf Standardwerten belassen, schwingt die Regelung oder reagiert träge. Ein sichtbares Loop-Objekt erleichtert diese Arbeit, nimmt sie aber niemandem ab.

Das Command-Objekt: koordiniert schalten

Während das Loop-Objekt eine einzelne Grösse regelt, löst das Command-Objekt ein ganz anderes Problem. Oft muss eine Anlage nicht nur einen Wert setzen, sondern viele Objekte gleichzeitig und in der richtigen Reihenfolge in einen bestimmten Zustand bringen. Wenn ein Gebäude vom Tag- in den Nachtbetrieb wechselt, müssen zahlreiche Objekte koordiniert umschalten: Lüftung reduzieren, Sollwerte absenken, Beleuchtungsfreigaben zurücknehmen, Türfreigaben ändern.

Genau dafür gibt es das Command-Objekt. Es bündelt eine ganze Folge von Schreibvorgängen hinter einem einzigen Befehl. In seiner Property Action_List steht, welche Werte an welche Objekte geschrieben werden sollen, wenn das Command-Objekt ausgelöst wird. Ein einziger Schreibvorgang auf den Present_Value des Command-Objekts stösst damit eine ganze, vordefinierte Sequenz an.

Der Wert, den man in den Present_Value schreibt, wählt dabei aus, welche der hinterlegten Aktionslisten ausgeführt wird. So kann ein einziges Command-Objekt mehrere Betriebszustände abbilden, etwa Tagbetrieb, Nachtbetrieb und Notbetrieb, und mit einem Wert zwischen ihnen umschalten. Das macht koordinierte Zustandswechsel nachvollziehbar und einheitlich, statt sie in verstreuter Programmlogik zu verstecken.

Rückmeldung und Nachvollziehbarkeit beim Command-Objekt

Ein koordinierter Mehrfachbefehl ist nur dann vertrauenswürdig, wenn man weiss, ob er wirklich vollständig ausgeführt wurde. Deshalb kennt das Command-Objekt Rückmeldeeigenschaften. Die Property In_Process zeigt an, dass eine Befehlssequenz gerade abgearbeitet wird. Die Property All_Writes_Successful meldet, ob alle Schreibvorgänge der Aktionsliste erfolgreich waren.

Diese Rückmeldung ist in der Praxis entscheidend. Schaltet ein Command-Objekt zwanzig Objekte um und eines davon lässt sich nicht beschreiben, etwa weil ein Gerät offline ist, dann darf das nicht unbemerkt bleiben. Über All_Writes_Successful wird ein solcher Teilfehler sichtbar und kann weiterverarbeitet werden, etwa als Alarm über das in Teil 5 beschriebene Ereignismodell.

Damit wird ein wichtiger Grundsatz erfüllt: Koordinierte Befehle dürfen keine Blackbox sein. Wer eine Betriebsart umschaltet, muss nachvollziehen können, welche Objekte betroffen sind und ob der Wechsel vollständig gelungen ist. Ein sauber dokumentiertes Command-Objekt mit klarer Aktionsliste und funktionierender Rückmeldung ist genau das Gegenteil einer undurchschaubaren Automatik.

Aus der Praxis: die häufigsten Fehler bei Loop und Command

Bei Loop- und Command-Objekten begegnen uns in Analysen und Abnahmen immer wieder dieselben Schwachstellen:

• Nicht dokumentierte Reglerparameter. Die PID-Werte wurden bei der Inbetriebnahme irgendwie eingestellt, aber nie festgehalten. Nach einem Gerätetausch beginnt das Einregulieren bei null.
• Nie nachjustierte Regelung. Kp, Ki und Kd stehen seit der Inbetriebnahme unverändert, obwohl sich die Anlage oder ihre Nutzung längst geändert hat. Die Regelung schwingt oder reagiert träge.
• Falsche Wirkrichtung. Eine verkehrt gesetzte Action lässt die Stellgrösse in die falsche Richtung laufen, sodass die Regelabweichung wächst statt kleiner zu werden.
• Command-Objekte als Blackbox. Die Aktionsliste ist nicht dokumentiert. Niemand weiss genau, welche Objekte ein Betriebsartenwechsel wirklich umschaltet.
• Ignorierte Rückmeldung. All_Writes_Successful wird nicht ausgewertet, sodass ein teilweise fehlgeschlagener Befehl unbemerkt bleibt und die Anlage in einem gemischten Zustand hängt.
• Regelung im Feld unklar abgegrenzt. Es ist nicht klar, ob eine Grösse über ein Loop-Objekt, über einen internen Herstellerregler oder über eine übergeordnete Steuerung geregelt wird. Doppelte Regelungen arbeiten gegeneinander.

Was Planer und Betreiber beachten sollten

Für die Planung folgt daraus eine klare Haltung. Regelungen und koordinierte Befehle gehören dokumentiert, nicht versteckt. Wo eine Regelung herstellerunabhängig sichtbar sein soll, ist ein Loop-Objekt die richtige Wahl, und seine Parameter gehören bei der Inbetriebnahme bewusst eingestellt und festgehalten. Wo mehrere Objekte koordiniert schalten, macht ein Command-Objekt mit klarer Aktionsliste den Ablauf nachvollziehbar.

Für den Betrieb ist die Nachvollziehbarkeit entscheidend. Ein Betreiber sollte wissen, welche Grössen aktiv geregelt werden, wo er den Sollwert findet und wie er erkennt, ob eine Regelung sauber arbeitet. Ebenso sollte er verstehen, was beim Umschalten einer Betriebsart im Hintergrund passiert und woran er erkennt, ob der Wechsel vollständig gelungen ist. Diese Transparenz ist der Unterschied zwischen einer Anlage, die man versteht und beherrscht, und einer Anlage, der man ausgeliefert ist.

Gerade weil Loop- und Command-Objekte aktiv eingreifen, verdienen sie besondere Sorgfalt in der Abnahme. Eine funktionierende Regelung, dokumentierte Parameter und eine geprüfte Befehlssequenz mit funktionierender Rückmeldung sind Zeichen einer Anlage, die nicht nur läuft, sondern beherrschbar bleibt.

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. Für Planung und Auslegung von Regelungen und Regelkreisen liefert zusätzlich die VDI 3814 wertvolle Hinweise. Viele Betreiber ergänzen diesen Rahmen durch eigene Vorgaben zu Regelgüte, Parametrierung und Dokumentation der Regelungen.

Fazit

Loop- und Command-Objekte sind die aktive Seite von BACnet. Das Loop-Objekt bildet einen Regelkreis als sichtbares Objekt ab: Es kennt Sollwert, Istwert und Stellgrösse, berechnet über seine PID-Anteile die richtige Reaktion und macht die Regelung herstellerunabhängig prüfbar. Das Command-Objekt bündelt viele Schreibvorgänge zu einem koordinierten Befehl, schaltet ganze Betriebszustände in einem Schritt und meldet über seine Rückmeldeeigenschaften, ob alles gelungen ist.

Beide Objekte zeigen dieselbe Grundhaltung, die sich durch die ganze Serie zieht: Was eine Anlage tut, soll sichtbar, dokumentiert und nachvollziehbar sein. Eine Regelung, deren Parameter niemand kennt, und ein Betriebsartenwechsel, den niemand durchschaut, sind Risiken. Sichtbare Objekte mit klaren Eigenschaften sind die Grundlage für eine Anlage, die man versteht, prüft und über ihren ganzen Lebenszyklus beherrscht.

In Teil 8, dem Abschluss dieser Serie, geht es um die Objekte, die das Ganze zusammenhalten: das Device-Objekt als Ausweis jedes Geräts, das Network-Port-Objekt für die Netzwerkanbindung und das Structured-View-Objekt für eine navigierbare Ordnung der vielen Objekte.

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)
• VDI 3814 (Gebäudeautomation, Regelungen und Regelkreise)
• SIA 386.110
• Eigene Planungserfahrung WENGET