Event Enrollment & Notification Class: Alarmmanagement nach BACnet

Eine Anlage, die Daten aufzeichnet, aber niemanden warnt, wenn etwas aus dem Ruder läuft, ist nur die halbe Miete. Irgendwann friert eine Leitung ein, läuft ein Speicher über oder fällt eine Pumpe aus, und die entscheidende Frage lautet: Merkt es jemand rechtzeitig, und weiss diese Person, was zu tun ist? Genau das regelt in BACnet das Alarmmodell mit seinen beiden zentralen Objekten, dem Event Enrollment und der Notification Class.

In Teil 4 ging es um Trend-Log-Objekte, also darum, wie eine Anlage Betriebsdaten aufzeichnet und ein Gedächtnis bekommt. Jetzt geht es um die Reaktion: Wie erkennt das System, dass ein Zustand nicht mehr in Ordnung ist, wie stellt es die Meldung dem richtigen Empfänger zu und wie stellt es sicher, dass die Meldung auch quittiert und bearbeitet wird.

Dieser Teil erklärt die beiden Wege, auf denen in BACnet Alarme entstehen, wie das Event Enrollment Object eine Grösse überwacht und in Alarmzustände übersetzt, wie die Notification Class die Meldung an die richtigen Empfänger verteilt und warum eine durchdachte Alarmphilosophie den Unterschied zwischen einem hilfreichen und einem ignorierten Alarmsystem ausmacht.

Warum ein strukturiertes Alarmmodell nötig ist

Ohne ein sauberes Alarmmodell entsteht schnell eines von zwei Extremen. Entweder meldet die Anlage viel zu wenig, dann bleiben echte Störungen unbemerkt, bis Schaden entsteht. Oder sie meldet viel zu viel, dann geht die eine wichtige Meldung in Hunderten belangloser unter, und die Betreiber gewöhnen sich an, Alarme wegzuklicken. Beide Extreme sind gefährlich, das zweite oft mehr als das erste.

Ein gutes Alarmmodell beantwortet für jede Meldung drei Fragen. Was genau wird überwacht und ab wann gilt es als nicht in Ordnung? Wer soll die Meldung erhalten, und zwar zur richtigen Zeit? Und muss die Meldung aktiv quittiert werden, damit klar ist, dass sich jemand kümmert? BACnet stellt für genau diese drei Fragen standardisierte Objekte und Properties bereit.

Damit wird Alarmierung planbar. Statt Meldungen dem Zufall der Werkseinstellung zu überlassen, lassen sich Quellen, Grenzwerte, Empfänger, Prioritäten und Quittierungspflichten bewusst festlegen. Genau das ist der Kern einer Alarmphilosophie, und sie gehört in die Planung, nicht in die hektische Nacharbeit nach den ersten Störungen.

Zwei Wege zum Alarm: eingebaut oder über Event Enrollment

BACnet kennt zwei Arten, wie ein Alarm entsteht. Der erste Weg ist das eingebaute Melden, das intrinsic reporting. Viele Objekte wie Analog Input oder Binary Input bringen die Fähigkeit zur Überwachung selbst mit. Über Properties wie High_Limit, Low_Limit, die zugehörige Grenzwertüberwachung und Event_Enable meldet das Objekt direkt, wenn sein Present_Value einen Grenzwert verletzt. Für einfache Fälle, etwa eine Temperaturüberwachung mit oberer und unterer Schranke, ist das der schlanke, naheliegende Weg.

Der zweite Weg ist das algorithmische Melden über ein eigenes Objekt, das Event Enrollment Object. Es überwacht eine beliebige Eigenschaft eines anderen Objekts von aussen und wendet darauf einen Ereignisalgorithmus an. Das entkoppelt die Überwachung vom überwachten Objekt und erlaubt komplexere Bedingungen, als sie das eingebaute Melden bietet, etwa gleitende Grenzwerte oder die Überwachung von Grössen, die selbst keine eingebaute Alarmfähigkeit haben.

Die Wahl zwischen beiden Wegen ist eine Planungsentscheidung. Das eingebaute Melden ist einfacher und in vielen Geräten sofort verfügbar. Das Event Enrollment ist flexibler und macht die Überwachung als eigenes Objekt sichtbar und dokumentierbar. In der Praxis existieren oft beide Wege nebeneinander, und wichtig ist vor allem, dass man weiss, welcher Weg wo genutzt wird.

Das Event Enrollment Object: von der Grösse zum Zustand

Das Event Enrollment Object übersetzt einen Messwert in einen Ereigniszustand. Es kennt über die Property Event_State, in welchem Zustand sich die überwachte Grösse gerade befindet. Die wichtigsten Zustände sind Normal, wenn alles in Ordnung ist, Offnormal, wenn eine Grenze verletzt wird, und Fault, wenn die Messung selbst gestört ist, etwa bei einem Sensordefekt. Der Offnormal-Zustand kann je nach Algorithmus feiner unterschieden werden, etwa in eine obere und eine untere Grenzüberschreitung.

Welcher Algorithmus angewendet wird, bestimmt der Ereignistyp. Gebräuchlich sind die Überwachung gegen feste Grenzen, die Erkennung eines unerlaubten Zustandswechsels bei binären und mehrwertigen Objekten sowie gleitende Grenzwerte, die sich an einem Sollwert orientieren. Wichtig ist dabei die Idee einer Totzone: Ein Alarm soll nicht bei jedem winzigen Zittern um den Grenzwert herum auslösen und wieder verschwinden, sondern erst bei einer echten, anhaltenden Verletzung. Dafür sorgen eine Verzögerungszeit und eine Rückstellschwelle.

Der entscheidende Punkt für die Planung ist, dass ein Ereignis noch keine Meldung an einen Menschen ist. Das Event Enrollment stellt nur fest, dass ein Zustand vorliegt. Wer davon erfährt, entscheidet ein zweites Objekt. Damit trennt BACnet sauber zwischen der Frage, was passiert ist, und der Frage, wer es erfahren soll.

Die Notification Class: wer erfährt was, und wie dringend

Hier kommt die Notification Class ins Spiel. Sie ist die Verteilstelle für Meldungen. Mehrere Alarmquellen verweisen über ihre Property Notification_Class auf dieselbe Notification Class und werden damit einheitlich behandelt. Das ist enorm praktisch, denn statt bei jeder einzelnen Quelle die Empfänger zu pflegen, definiert man sie einmal zentral und ordnet die Quellen zu.

Drei Dinge legt die Notification Class fest. Erstens die Empfänger, über die Property Recipient_List. Dort steht, wer eine Meldung erhält, zu welchen Zeiten, für welche Art von Übergang und ob die Zustellung bestätigt werden muss. Zweitens die Priorität, über die Property Priority. Sie lässt sich getrennt für die drei Übergänge festlegen und bestimmt, wie dringend eine Meldung behandelt wird. Drittens die Quittierungspflicht, über die Property Ack_Required.

Die drei Übergänge, die BACnet unterscheidet, sind der Wechsel nach Offnormal, der Wechsel nach Fault und die Rückkehr nach Normal. Für jeden lassen sich Priorität und Empfänger getrennt einstellen. So kann eine kritische Grenzverletzung sofort und an alle gehen, während die Rückkehr in den Normalzustand nur protokolliert und niemanden mehr aktiv stört. Diese Feinsteuerung ist der Schlüssel zu einem Alarmsystem, das informiert, ohne zu überfluten.

Wie viele Notification Classes eine Anlage braucht, ist ebenfalls eine Planungsfrage. Sinnvoll ist eine überschaubare Zahl klar benannter Klassen, die sich an der Organisation des Betreibers orientieren, etwa eine Klasse für kritische Störungen mit sofortiger Zustellung, eine für wartungsrelevante Meldungen und eine rein informative Klasse. Werden dagegen für jede Quelle eigene Empfänger direkt gepflegt, wird die Anlage schnell unübersichtlich und im Betrieb kaum noch wartbar. Die zentrale Bündelung über wenige, gut dokumentierte Klassen ist deshalb fast immer die bessere Wahl.

Quittierung und Eskalation

Eine Meldung, die niemand bestätigen muss, sagt nichts darüber aus, ob sich jemand kümmert. Genau dafür gibt es die Quittierung. Ist über Ack_Required festgelegt, dass ein Übergang quittiert werden muss, bleibt die Meldung so lange als unquittiert sichtbar, bis ein Bediener sie aktiv bestätigt. Die Property Acked_Transitions hält fest, welche Übergänge bereits quittiert sind. Damit wird aus einem flüchtigen Signal ein nachvollziehbarer Vorgang mit klarer Verantwortung.

Die Quittierungspflicht sollte man bewusst und sparsam einsetzen. Sie gehört auf die Meldungen, bei denen wirklich eine Handlung nötig ist, nicht auf jede beiläufige Statusinformation. Muss ein Bediener Dutzende belangloser Meldungen wegquittieren, verkommt die Quittierung zur lästigen Routine und verliert genau die Ernsthaftigkeit, die ihren Sinn ausmacht.

Eskalation entsteht in BACnet nicht durch ein eigenes Objekt, sondern durch die durchdachte Gestaltung der Empfängerliste und der Zeitfenster. Eine Meldung kann tagsüber an die Haustechnik gehen und nachts an einen Pikettdienst. Wird eine kritische Meldung nicht rechtzeitig quittiert, kann ein übergeordnetes System die nächste Stufe alarmieren. Die Bausteine dafür liefern Recipient_List und die zeitabhängige Zustellung, die eigentliche Eskalationslogik plant und dokumentiert man drumherum.

Aus der Praxis: die häufigsten Fehler beim Alarmmanagement

Beim Alarmmanagement sehen wir in unseren Analysen immer wieder dieselben Muster. Fast alle entstehen, weil eine Alarmphilosophie fehlt:

• Alarmflut. Zu viele Meldungen mit zu hoher Priorität überfordern die Betreiber. Wenn alles wichtig ist, ist nichts mehr wichtig, und die entscheidende Meldung geht unter.
• Fehlende Totzone und Verzögerung. Ohne Rückstellschwelle und Verzögerungszeit flattern Meldungen bei jeder kleinen Schwankung um den Grenzwert. Das erzeugt Rauschen statt Information.
• Unklare Empfängergruppen. Ist nicht festgelegt, wer welche Meldung wann erhält, landen Alarme bei niemandem oder bei allen. Beide Fälle führen dazu, dass sich niemand zuständig fühlt.
• Quittierung ohne Prozess. Eine Quittierungspflicht ohne definierten Bearbeitungsprozess ist reine Formsache. Meldungen werden weggeklickt, ohne dass etwas geschieht.
• Prioritäten nicht differenziert. Werden alle Übergänge gleich behandelt, stört die harmlose Rückkehr in den Normalzustand genauso wie die kritische Störung. Die drei Übergänge gehören bewusst unterschieden.
• Kein Bezug zwischen Alarm und Handlung. Jeder Alarm braucht einen Adressaten und eine klare Handlungsanweisung. Ein Alarm, zu dem niemand weiss, was zu tun ist, ist wertlos.

Eine kohärente Alarmphilosophie planen

Eine Alarmphilosophie ist kein technisches Dokument, sondern eine Reihe bewusster Entscheidungen. Sie beginnt mit der Frage, welche Ereignisse überhaupt einen Alarm rechtfertigen, und trennt dabei streng zwischen dem, was eine sofortige Handlung erfordert, und dem, was nur zur Information protokolliert wird. Nur die erste Kategorie gehört in eine aktive Meldung mit Quittierungspflicht.

Im zweiten Schritt legt man die Prioritätsstufen fest und ordnet ihnen klare Bedeutungen zu, etwa kritisch, wichtig und informativ. Zu jeder Stufe gehören ein Empfängerkreis, ein Zeitfenster und eine erwartete Reaktionszeit. Erst diese Zuordnung macht aus einer Prioritätszahl eine handhabbare Regel. Im dritten Schritt beschreibt man die Empfängergruppen und die Eskalation: wer zuerst, wer danach, und was geschieht, wenn niemand reagiert.

Wer diese Entscheidungen vorab trifft und in der Ausschreibung vorgibt, bekommt am Ende ein Alarmsystem, das zur Organisation des Betreibers passt. Aus der vagen Anforderung «wichtige Störungen melden» wird so eine überprüfbare Struktur aus Quellen, Grenzwerten, Prioritäten, Empfängern und Quittierungsregeln.

Was das für Betrieb und Übergabe bedeutet

Für Betreiber lässt sich dieser Teil auf eine klare Forderung eindampfen: Verlangen Sie eine dokumentierte Alarmliste. Sie hält fest, welche Ereignisse gemeldet werden, mit welcher Priorität, an welche Empfänger, mit welchen Zeitfenstern und mit welcher Quittierungspflicht. Diese Liste ist Teil der Übergabe, und zu jeder kritischen Meldung gehört eine kurze Handlungsanweisung.

Für Planer und Bauherren gilt der Umkehrschluss. Wer das Zusammenspiel von Event Enrollment und Notification Class kennt, kann Alarmquellen, Prioritäten und Empfänger konkret vorschreiben und bei der Abnahme prüfen, ob Totzonen gesetzt, Prioritäten differenziert und Empfänger sinnvoll gruppiert sind. Ein gutes Alarmsystem entsteht nicht durch Zufall, sondern weil jemand die Philosophie dahinter geplant hat.

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 die Gestaltung des Alarmmanagements liefert zusätzlich die VDI 3814 wertvolle Hinweise zu Alarmphilosophie, Priorisierung und Bedienung. Viele Betreiber ergänzen diesen Rahmen durch eigene Vorgaben zu Prioritätsstufen, Empfängergruppen und Reaktionszeiten.

Fazit

Das BACnet-Alarmmodell trennt sauber zwischen zwei Fragen. Das Event Enrollment Object stellt fest, was passiert ist: Es überwacht eine Grösse, wendet einen Algorithmus an und führt sie in die Zustände Normal, Offnormal und Fault. Die Notification Class regelt, wer davon erfährt: Sie bündelt Quellen, verteilt an Empfänger, setzt Prioritäten je Übergang und steuert die Quittierung. Daneben steht das einfachere eingebaute Melden für die schlanken Fälle.

Entscheidend ist nicht die Technik allein, sondern die Alarmphilosophie dahinter. Ein System, das jede Kleinigkeit meldet, ist so unbrauchbar wie eines, das schweigt. Wer Quellen, Prioritäten, Empfänger und Quittierung bewusst plant, bekommt Alarme, die informieren statt zu überfluten, und die zu einer Handlung führen statt weggeklickt zu werden.

In Teil 6 wenden wir uns der Zeitsteuerung zu. Dann geht es um Schedule- und Calendar-Objekte, also darum, wie BACnet Wochenprogramme, Ausnahmen und Feiertagskalender abbildet und was Betreiber bei der Übergabe dieser Zeitprogramme wissen müssen.

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 (Alarmmanagement in der Gebäudeautomation)
• SIA 386.110
• Eigene Planungserfahrung WENGET