Trending, Alarming & Scheduling: Die drei Betriebsfunktionen, die oft vergessen werden

In den bisherigen Teilen dieser Serie haben wir die Grundlagen der BACnet-Planung behandelt: Objektvorgaben, Datenpunktlisten, Beschriftungsregeln und Netzwerkplanung. In diesem fünften Teil widmen wir uns drei Betriebsfunktionen, die bei der Planung häufig vergessen werden, aber für den Anlagenbetrieb entscheidend sind: Trending, Alarming und Scheduling.

Diese drei Funktionen haben eines gemeinsam: Sie wirken erst im Betrieb, aber sie müssen in der Planungsphase definiert werden. Genau das macht sie zu einem blinden Fleck: Weil der Planer ihre Wirkung nicht sofort sieht, verschiebt er die Detailarbeit auf später, und später heisst dann meistens: nie systematisch, sondern ad hoc. Wer Trending, Alarming und Scheduling erst bei der Inbetriebnahme konfiguriert, arbeitet ohne Konzept, und erzeugt Systeme, die entweder zu viel oder zu wenig melden, die falschen Daten aufzeichnen und Zeitprogramme enthalten, die niemand versteht.

Trending: Daten aufzeichnen, bevor man sie braucht

Trending bezeichnet die automatische Aufzeichnung von Datenpunktwerten über die Zeit. In BACnet wird Trending über Trend Log Objects realisiert, die Werte in einem lokalen Puffer speichern und später vom Leitsystem abgerufen werden können.

Warum ist Trending wichtig? Weil Betriebsoptimierung, Fehleranalyse und Energiemonitoring ohne historische Daten nicht möglich sind. Ein Betreiber, der herausfinden will, warum die Zulufttemperatur nachts auf 28 Grad steigt, braucht den Temperaturverlauf der letzten 48 Stunden, nicht den aktuellen Wert.

Der Planer muss in der Planungsphase festlegen:

• Welche Datenpunkte getrendet werden. Nicht jeder Datenpunkt braucht einen Trend Log. Regel- und energierelevante Werte (Temperaturen, Ventilstellungen, Verbräuche, Betriebsstunden) haben Priorität. Statusinformationen (Pumpe ein/aus) werden seltener getrendet.
• Das Aufzeichnungsintervall. Wie oft wird ein Wert gespeichert? Für Temperaturen in der Lüftung sind 5-Minuten-Intervalle üblich. Für Energiezähler können 15-Minuten-Intervalle ausreichen. Für schnelle Regelkreise (z. B. Druckregelung) können kürzere Intervalle nötig sein.
• Den Aufzeichnungsmodus. BACnet unterstützt zwei Modi: Polling (festes Intervall) und COV (Aufzeichnung bei Wertänderung). COV-basiertes Trending ist effizienter, weil es nur bei tatsächlichen Änderungen Speicher verbraucht, setzt aber COV-fähige Objekte voraus. Der Planer muss im Leistungsverzeichnis angeben, welcher Modus für welche Datenpunktgruppe gefordert wird.
• Die Puffergrösse (Buffer_Size). Wie viele Einträge speichert der Trend Log lokal? Bei einem 5-Minuten-Intervall und einem Puffer von 1000 Einträgen hält der Puffer knapp 3.5 Tage. Wenn das Leitsystem den Puffer nicht rechtzeitig ausliest, gehen die ältesten Daten verloren.

Der Planer sollte eine Trend-Matrix erstellen: eine Tabelle, die für jeden zu trendenden Datenpunkt das Intervall, den Modus und die Puffergrösse festlegt. Diese Matrix wird Teil der Ausschreibungsunterlagen.

Ein oft übersehener Aspekt: Trend-Daten müssen nicht nur aufgezeichnet, sondern auch übertragen und gespeichert werden. Der Planer muss klären, wie und wie oft das Leitsystem die Trend-Puffer ausliest. Bei einer grossen Anlage mit Tausenden von Trend Logs kann das Auslesen erheblichen Netzwerkverkehr erzeugen. Eine gestaffelte Abfrage, kritische Werte alle 15 Minuten, weniger wichtige stündlich, reduziert die Spitzenlast.

Ebenso relevant: Wo werden die historischen Daten langfristig gespeichert? Der lokale Trend-Puffer in der Automationsstation ist ein Zwischenspeicher, keine Langzeitlösung. Das Leitsystem oder ein separates Historiensystem muss die Daten übernehmen und mindestens für die in der SIA 386 oder im Energiegesetz geforderten Zeiträume aufbewahren.

Alarming: Melden, was wirklich zählt

Alarming ist die Funktion, die den Betreiber auf abnormale Zustände hinweist. In BACnet werden Alarme über Event-Objekte, Notification Classes und Alarm-Properties realisiert. Ein Alarm wird ausgelöst, wenn ein überwachter Wert definierte Grenzwerte über- oder unterschreitet.

Das Problem in der Praxis: Ohne Alarmkonzept entsteht Alarm-Überflutung. Jeder Datenpunkt meldet bei jeder kleinen Abweichung einen Alarm. Der Betreiber erhält pro Schicht Hunderte von Meldungen, und ignoriert sie irgendwann alle. Das Ergebnis ist paradox: Mehr Alarme führen zu weniger Reaktion. Studien aus der Prozessindustrie zeigen, dass Bediener ab etwa zehn Alarmen pro Stunde die Fähigkeit verlieren, kritische Meldungen zuverlässig zu erkennen. In der Gebäudeautomation gelten ähnliche Grössenordnungen, die Alarmrate muss so niedrig sein, dass jede einzelne Meldung Aufmerksamkeit erhält.

Der Planer muss deshalb ein strukturiertes Alarmkonzept erarbeiten:

Alarmklassifizierung

Nicht jeder Alarm hat dieselbe Dringlichkeit. Die AMEV «BACnet 2017» empfiehlt eine Klassifizierung in mindestens drei Stufen:

• Kritische Alarme (Priorität 1–50): Sofortige Reaktion erforderlich. Beispiel: Frostschutzalarm, Brandalarm-Rückmeldung, Pumpenstörung.
• Wichtige Alarme (Priorität 51–100): Reaktion innerhalb definierter Frist. Beispiel: Temperatur ausserhalb des Sollbereichs, Filterwarnung.
• Hinweise (Priorität 101–255): Informatorisch, keine sofortige Reaktion nötig. Beispiel: Betriebsmodenwechsel, Wartungsintervall erreicht.

Alarmgrenzen und Totband

Für jeden überwachten Datenpunkt legt der Planer die Alarmgrenzen fest: bei welchem Wert wird ein Alarm ausgelöst? Ebenso wichtig ist das Totband (Deadband), die Hysterese, die verhindert, dass ein Wert, der knapp um den Grenzwert pendelt, ständig Alarme auslöst und wieder zurücksetzt.

Beispiel: Zulufttemperatur, Sollwert 22 °C. High-Limit 26 °C mit Totband 1 °C. Der Alarm wird bei 26 °C ausgelöst und erst bei 25 °C zurückgesetzt, nicht schon bei 25.9 °C.

Notification Class

BACnet organisiert Alarme über Notification Classes, die festlegen, wohin ein Alarm gesendet wird. Der Planer definiert, welche Notification Classes das Projekt verwendet und welche Empfänger (Leitsystem, E-Mail-Gateway, SMS-Gateway) in welcher Klasse hinterlegt sind.

Ein typisches Setup: Notification Class 1 für kritische Alarme (Leitsystem + SMS an Pikettdienst), Notification Class 2 für wichtige Alarme (nur Leitsystem), Notification Class 3 für Hinweise (Leitsystem, nur Protokollierung).

Alarmunterdrückung und Aggregation

Nicht jeder Alarm soll zu jeder Zeit gemeldet werden. Wenn eine Anlage planmässig abgeschaltet ist, sollen die zugehörigen Alarme unterdrückt werden. Ebenso sinnvoll: Alarm-Aggregation, wenn 20 Raumregler gleichzeitig einen Temperaturalarm melden, genügt eine zusammengefasste Meldung statt 20 einzelner Alarme.

Der Planer sollte Regeln für die Alarmunterdrückung festlegen: Welche Alarme werden bei welchem Betriebszustand unterdrückt? Wie werden gleichartige Alarme aggregiert? Diese Regeln werden bei der Inbetriebnahme in der Alarm-Konfiguration umgesetzt.

Ein weiterer Planungsaspekt: Alarm-Eskalation. Was passiert, wenn ein kritischer Alarm nicht innerhalb einer definierten Frist quittiert wird? In professionellen Anlagen wird der Alarm an die nächste Eskalationsstufe weitergeleitet, beispielsweise vom Betriebspersonal an den Bereitschaftsdienst und von dort an die Betriebsleitung. Diese Eskalationslogik muss in der Planungsphase definiert und in den Notification Classes abgebildet werden.

Der Planer sollte auch festlegen, welche Alarme eine manuelle Quittierung erfordern und welche automatisch zurückgesetzt werden dürfen. Kritische Alarme (Frostschutz, Brandrückmeldung) sollten immer manuell quittiert werden, damit sichergestellt ist, dass ein Mensch die Ursache geprüft hat.

Scheduling: Zeitprogramme durchdacht planen

Scheduling steuert zeitabhängige Abläufe: Wann läuft die Lüftung? Wann schaltet die Beleuchtung in den Nachtmodus? Wann wird die Heizung heruntergefahren? In BACnet werden Zeitprogramme über Schedule Objects und Calendar Objects realisiert.

Schedule Objects definieren wiederkehrende Zeitpläne (Wochenprogramme: Montag bis Freitag 06:00–22:00 Betrieb, Samstag 08:00–18:00, Sonntag aus). Calendar Objects definieren Ausnahmen: Feiertage, Betriebsferien, Sonderveranstaltungen. Beide Objekttypen arbeiten zusammen: Das Calendar Object hat Vorrang vor dem regulären Wochenplan, sodass an einem Feiertag automatisch der Sonntagsbetrieb oder ein eigener Feiertags-Modus greift.

Der Planer muss festlegen:

• Welche Anlagen zeitgesteuert werden. Lüftung, Beleuchtung, Beschattung und Heizung haben in der Regel Zeitprogramme. Die Zuordnung muss klar dokumentiert sein.
• Die Standard-Zeitprogramme. Für jede Anlage: Betriebszeiten pro Wochentag, einschliesslich Vor- und Nachlaufzeiten. Eine Lüftungsanlage, die um 08:00 Nennbetrieb erreichen soll, muss je nach Aufheizzeit schon um 06:00 oder 06:30 starten.
• Die Ausnahmekalender. Welche Feiertage gelten? Gibt es Betriebsferien? Wie werden Sonderveranstaltungen (z. B. Abendanlässe in einem Bürogebäude) berücksichtigt?
• Die Prioritäten. BACnet verwendet ein 16-stufiges Prioritätensystem für Schreibzugriffe. Schedule Objects schreiben typischerweise auf Priorität 15 oder 16. Der Planer muss festlegen, auf welcher Priorität die Zeitprogramme schreiben, damit manuelle Übersteuerungen (z. B. durch den Facility Manager) korrekt funktionieren.

Die KBOB-Empfehlung fordert, dass Zeitprogramme im Leitsystem änderbar sein müssen, nicht nur im lokalen Controller. Das setzt voraus, dass die Schedule Objects über BACnet zugreifbar und beschreibbar sind.

Besondere Aufmerksamkeit verdient die Frage der Sommer-/Winterzeitumstellung: BACnet-Controller arbeiten mit lokaler Zeit. Bei der Umstellung können Zeitprogramme eine Stunde zu früh oder zu spät starten, wenn die Controller-Uhrzeit nicht korrekt synchronisiert wird. Der Planer sollte vorgeben, wie die Zeitsynchronisation erfolgt (z. B. über BACnet TimeSynchronization-Dienste oder NTP) und sicherstellen, dass alle Controller dieselbe Zeitquelle verwenden.

Zusammenspiel der drei Funktionen

Trending, Alarming und Scheduling sind nicht isoliert zu betrachten, sie wirken zusammen:

• Ein Alarm wird nur relevant, wenn die Anlage tatsächlich im Betrieb ist (gesteuert durch Scheduling). Ausserhalb der Betriebszeiten sind viele Alarme irrelevant und sollten unterdrückt werden.
• Trending liefert die historischen Daten, um Alarmgrenzen zu kalibrieren. Wenn die Zulufttemperatur regelmässig zwischen 21 und 23 Grad schwankt, ist ein High-Limit von 24 Grad sinnvoller als 26 Grad.
• Scheduling beeinflusst die Trending-Anforderungen: Während der Betriebszeiten braucht man engmaschigere Aufzeichnungen als in der Nachtabsenkung.

Der Planer sollte diese Zusammenhänge in einem integrierten Betriebskonzept dokumentieren, das die drei Funktionen aufeinander abstimmt.

In der Praxis bewährt sich ein Betriebskonzept-Dokument, das für jede Anlage (Lüftung, Heizung, Kälte, Beleuchtung) tabellarisch festlegt: welche Datenpunkte getrendet werden, welche Alarme mit welchen Grenzwerten konfiguriert werden, welche Zeitprogramme gelten und wie diese drei Funktionen aufeinander wirken. Dieses Dokument wird Teil der Ausschreibung und dient bei der Abnahme als Referenz.

Ein konkretes Beispiel: Für eine Lüftungsanlage definiert das Betriebskonzept, dass die Zulufttemperatur mit 5-Minuten-Intervall getrendet wird, ein High-Limit-Alarm bei 28 °C mit Totband 2 °C konfiguriert ist (Notification Class 2), und das Zeitprogramm die Anlage werktags von 06:00 bis 22:00 betreibt. Ausserhalb der Betriebszeiten wird der Temperaturalarm unterdrückt, und das Trending wechselt auf 15-Minuten-Intervalle.

Aus der Praxis: die häufigsten Fehler

• Kein Trendkonzept. 5000 Datenpunkte, aber nur 50 werden getrendet, und diese wurden vom Integrator zufällig ausgewählt, nicht vom Planer vorgegeben.
• Alarm-Überflutung. 300 Alarme pro Tag. Der Betreiber hat aufgehört, darauf zu reagieren. Kritische Meldungen gehen im Rauschen unter.
• Kein Totband definiert. Ein Temperaturwert pendelt um den Grenzwert: Alarm, Normal, Alarm, Normal, im 30-Sekunden-Takt. Das Alarmprotokoll ist nach einer Stunde unlesbar.
• Zeitprogramme nicht dokumentiert. Drei Jahre nach Inbetriebnahme weiss niemand mehr, warum die Lüftung am Freitag um 14:00 abschaltet. Die Dokumentation fehlt.
• Schedule-Prioritäten nicht geplant. Der Facility Manager übersteuert die Temperatur manuell: aber das Zeitprogramm setzt sie beim nächsten Zyklus zurück, weil es auf einer höheren Priorität schreibt.

Wichtig: Die KBOB-Empfehlung «BACnet Anwendung» (2021) behandelt Trending, Alarming und Scheduling als integralen Bestandteil der BACnet-Planung. Die VDI 3814 Blatt 4.1 liefert Arbeitshilfen für die Zuordnung von GA-Funktionen zu BACnet-Diensten. Die AMEV «BACnet 2017» enthält in Anhang 7 Planungshilfen für die Alarmkonfiguration.

Fazit

Trending, Alarming und Scheduling sind keine optionalen Extras, sie sind die drei Betriebsfunktionen, die darüber entscheiden, ob eine Gebäudeautomation im Alltag funktioniert oder nur installiert ist. Der Planer muss sie in der Planungsphase definieren, nicht dem Integrator oder dem Betreiber überlassen.

Ein gutes Trendkonzept liefert die Daten für Optimierung und Fehleranalyse. Ein durchdachtes Alarmkonzept meldet, was wirklich zählt. Und ein sauberes Zeitprogramm sorgt dafür, dass die Anlage läuft, wenn sie laufen soll, und nicht, wenn sie nicht soll.

Die Investition in ein sauberes Betriebskonzept zahlt sich bereits in den ersten Betriebsmonaten aus: weniger Fehlalarme, bessere Datenqualität für das Energiemonitoring und Zeitprogramme, die das Betriebspersonal versteht und selbstständig anpassen kann. Ohne dieses Konzept delegiert der Planer die Betriebslogik an den Integrator, und der kennt weder die Nutzungsbedürfnisse noch die betrieblichen Abläufe des Bauherrn.

Im letzten Teil dieser Serie fassen wir den BACnet-Planungsprozess zusammen: vom Lastenheft über die Ausschreibung bis zur Abnahme.

Diese Serie ergänzt unsere Serie «BACnet Objekte verstehen», die sich mit der technischen Mechanik der einzelnen Objekttypen befasst. Wer beide Serien kennt, versteht nicht nur, was BACnet-Objekte können, sondern auch, wie man sie richtig plant.

Sie haben Fragen dazu?

Sprechen Sie uns an, wir unterstützen Bauherren, Planer und Betreiber bei der professionellen BACnet-Planung, von der Bedarfsanalyse bis zur Abnahme.

WENGET GmbH E-Mail: info@wenget.ch Telefon: +41 44 552 34 88

Quellenverzeichnis

• KBOB, «Empfehlung BACnet Anwendung», Version 2.0, Juli 2021
• VDI 3814 Blatt 4.1, «Gebäudeautomation: Arbeitsmittel, GA-Funktionsliste», Verein Deutscher Ingenieure
• AMEV, «BACnet 2017», Anhang 7 (Planungshilfen), Arbeitskreis Maschinen- und Elektrotechnik staatlicher und kommunaler Verwaltungen
• ISO 16484-5, «Building automation and control systems: Part 5: Data communication protocol (BACnet)»
• ASHRAE, «Guideline 13-2015: Specifying DDC Systems», American Society of Heating, Refrigerating and Air-Conditioning Engineers