Trend Log & Trend Log Multiple: Wie BACnet Betriebsdaten sichert

Eine Anlage, die nur ihren aktuellen Zustand kennt, hat kein Gedächtnis. Sie zeigt die Vorlauftemperatur von jetzt, die Ventilstellung von jetzt, die Betriebsart von jetzt. Doch die spannenden Fragen im Betrieb sind fast immer zeitliche Fragen: Warum ist die Raumtemperatur letzte Nacht davongelaufen? Taktet die Wärmepumpe zu häufig? Wann genau ist die Störung aufgetreten? Antworten darauf liefert nicht der Momentwert, sondern die Aufzeichnung über die Zeit. Genau dafür gibt es in BACnet die Trend-Log-Objekte.

In Teil 3 haben wir die Multi-State- und Programm-Objekte betrachtet, also einzelne, benannte Zustände und die Logik im Gerät. Jetzt verlassen wir den Momentwert und wenden uns der Zeitachse zu. Ein Trend Log zeichnet den Verlauf eines Datenpunkts über Stunden, Tage und Monate auf und macht damit sichtbar, was ein einzelner Blick auf den Present_Value niemals zeigen kann.

Dieser Teil erklärt, wie das Trend Log Object und das Trend Log Multiple Object aufgebaut sind, wie das Buffer-Konzept funktioniert, wann sich COV-basiertes gegen intervallbasiertes Aufzeichnen lohnt und wie man die entstehenden Datenmengen von Anfang an richtig plant. Denn Trending, das erst beim Betrieb nachgerüstet wird, ist fast immer lückenhaft.

Warum Betriebsdaten aufzeichnen

Ohne aufgezeichnete Daten bleibt der Betrieb einer Anlage ein Blindflug. Man sieht, dass es gerade zu warm ist, aber nicht, seit wann und in welchem Muster. Man ahnt, dass eine Pumpe zu oft schaltet, kann es aber nicht belegen. Und wenn eine Störung nachts auftritt und sich von selbst wieder legt, ist sie am Morgen spurlos verschwunden.

Aufgezeichnete Verläufe drehen das um. Sie machen aus einem Bauchgefühl eine belegbare Tatsache. Sie zeigen, ob eine Optimierung wirklich etwas gebracht hat, sie liefern die Grundlage für die Energieauswertung, und sie sind bei Störungen oft das einzige Beweismittel, das eine schnelle Ursachensuche erlaubt. Für einen sinnvollen Betrieb, für die Inbetriebnahme und für jede spätere Optimierung sind gute Trenddaten daher kein Luxus, sondern die Voraussetzung.

Genau deshalb gehört Trending in die Planung und nicht in die Nacharbeit. Wer erst nach der Abnahme merkt, dass die entscheidenden Datenpunkte nie aufgezeichnet wurden, hat für die kritische erste Betriebsphase keine Daten. Diese Lücke lässt sich später nicht rückwirkend schliessen.

Trend Log und Trend Log Multiple

BACnet kennt für die Aufzeichnung zwei verwandte Objekttypen. Das Trend Log Object, kurz TL, zeichnet den Verlauf einer einzigen Eigenschaft auf, typischerweise den Present_Value eines Datenpunkts. Für jede aufgezeichnete Grösse gibt es also ein eigenes Trend-Log-Objekt. Das ist einfach, robust und für die meisten Fälle völlig ausreichend.

Das Trend Log Multiple Object, kurz TLM, zeichnet mehrere Eigenschaften gleichzeitig und zeitlich synchron in einem einzigen Objekt auf. Der Vorteil liegt in der gemeinsamen Zeitbasis: Alle erfassten Werte tragen denselben Zeitstempel und lassen sich damit exakt gegeneinander stellen. Das ist überall dort wertvoll, wo Zusammenhänge zwischen mehreren Grössen zählen, etwa Vorlauf, Rücklauf und Aussentemperatur einer Heizgruppe im selben Moment.

Welches Objekt richtig ist, hängt vom Zweck ab. Für die klassische Langzeitaufzeichnung einzelner Punkte ist das Trend Log Object die naheliegende Wahl. Wo mehrere Grössen zwingend im selben Takt und mit derselben Zeitbasis zusammengehören, spielt das Trend Log Multiple seine Stärke aus. In der Praxis dominiert das einfache Trend Log, während das Trend Log Multiple gezielt für zusammenhängende Messgruppen eingesetzt wird.

COV-basiert oder in festen Intervallen

Die vielleicht wichtigste Planungsentscheidung beim Trending ist die Frage nach der Aufzeichnungsmethode. Die Property Logging_Type legt fest, wodurch ein neuer Eintrag ausgelöst wird, und es gibt zwei grundsätzliche Wege.

Beim intervallbasierten Aufzeichnen, dem Polling, schreibt das Trend Log in einem festen zeitlichen Raster einen Wert, etwa alle fünf Minuten. Die Property Log_Interval bestimmt den Abstand. Das Ergebnis ist ein gleichmässiges Raster mit vorhersehbarer Datenmenge. Der Preis dafür ist, dass sich schnelle Änderungen zwischen zwei Messpunkten verstecken können und dass auch dann Werte geschrieben werden, wenn sich gar nichts ändert.

Beim COV-basierten Aufzeichnen wird nur dann ein Eintrag erzeugt, wenn sich der Wert um einen definierten Betrag ändert, das sogenannte Change of Value. Ein stabiler Wert erzeugt kaum Einträge, eine bewegte Grösse hingegen viele, genau dann, wenn etwas passiert. Das ist datensparsam und bildet Dynamik präzise ab, macht die Datenmenge aber schwerer vorhersehbar und braucht eine sinnvoll gewählte Schwelle.

Als Faustregel eignet sich das feste Intervall für träge, langsam veränderliche Grössen wie Raumtemperaturen und für alles, was für die Energieauswertung ein regelmässiges Raster braucht. Das COV-basierte Aufzeichnen lohnt sich bei Grössen, die lange konstant bleiben und sich dann sprunghaft ändern, etwa Schaltzustände oder Sollwerte. Häufig ist eine Mischung aus beidem über die verschiedenen Datenpunkte die beste Lösung.

Das Buffer-Konzept

Ein Trend Log speichert seine Werte nicht unbegrenzt, sondern in einem internen Puffer fester Grösse, dem Log_Buffer. Die Property Buffer_Size legt fest, wie viele Einträge dieser Puffer aufnehmen kann. Jeder Eintrag besteht aus einem Zeitstempel, dem Wert und einer Statusinformation. Ist der Puffer voll, gibt es genau zwei mögliche Verhalten, und die Wahl dazwischen ist eine bewusste Planungsentscheidung.

Die Property Stop_When_Full steuert dieses Verhalten. Ist sie aktiv, hört das Trend Log auf zu schreiben, sobald der Puffer voll ist, die ältesten Daten bleiben erhalten und neue gehen verloren. Ist sie inaktiv, arbeitet der Puffer als Ringspeicher: Der jeweils älteste Eintrag wird überschrieben, sodass immer die jüngste Vergangenheit vorliegt. Für die laufende Betriebsüberwachung ist der Ringspeicher der Normalfall, für eine gezielte, einmalige Messkampagne kann das Anhalten bei vollem Puffer sinnvoll sein.

Begleitende Properties runden das Bild ab. Record_Count gibt an, wie viele Einträge aktuell im Puffer liegen, Total_Record_Count zählt alle jemals geschriebenen Einträge und dient auch dazu, Lücken zu erkennen. Entscheidend für den Betrieb ist die Einsicht, dass der Puffer im Gerät nur eine Zwischenstation ist. Er überbrückt die Zeit, bis ein übergeordnetes System die Daten abholt und dauerhaft archiviert. Der Puffer muss deshalb gross genug sein, um auch einen Ausfall der Verbindung zum Auswertesystem zu überstehen, ohne dass Daten verloren gehen.

Start, Stopp und das Auslesen der Daten

Wann ein Trend Log überhaupt aufzeichnet, steuern mehrere Properties gemeinsam. Die Property Enable schaltet die Aufzeichnung grundsätzlich ein oder aus. Mit Start_Time und Stop_Time lässt sich ein Zeitfenster definieren, in dem aufgezeichnet wird, was für befristete Messkampagnen praktisch ist. Bei getriggertem Aufzeichnen löst ein separater Auslöser den Eintrag aus. In der Summe entsteht eine feine Kontrolle darüber, ob, wann und wodurch Werte in den Puffer gelangen.

Beim Auslesen der Daten kommt es auf das richtige Verfahren an. Um die einzelnen Momentwerte eines Punkts oder mehrere Properties auf einmal abzufragen, nutzt man den Dienst Read Property Multiple. Für das Abholen der aufgezeichneten Verläufe aus dem Log_Buffer gibt es dagegen einen eigenen, dafür geschaffenen Dienst, den Read Range. Er erlaubt es, gezielt einen Zeitbereich oder eine bestimmte Zahl von Einträgen anzufordern, statt den gesamten Puffer auf einmal zu übertragen. Ein Auswertesystem holt so in regelmässigen Abständen genau die neuen Einträge seit dem letzten Abruf ab.

Damit dieses Abholen nicht dem Zufall überlassen bleibt, kann ein Trend Log selbst melden, wenn es Zeit wird. Über die Property Notification_Threshold lässt sich eine Schwelle setzen, bei deren Erreichen das Objekt eine Meldung auslöst, damit das übergeordnete System die Daten abholt, bevor der Puffer überläuft. So bleibt die Kette vom Sensor bis ins Archiv auch bei grossen Datenmengen lückenlos.

Aus der Praxis: die häufigsten Missverständnisse beim Trending

Bei den Trend-Log-Objekten kehren in unseren Analysen immer wieder dieselben Muster zurück. Fast alle sind vermeidbar, wenn Trending von Anfang an geplant wird:

• Zu klein dimensionierter Puffer. Ist die Buffer_Size zu knapp und fällt die Verbindung zum Auswertesystem kurz aus, überschreibt der Ringspeicher genau die Daten, die man später bräuchte. Der Puffer muss die längste realistische Ausfallzeit überbrücken.
• Intervall passt nicht zum Datenpunkt. Ein Fünf-Minuten-Raster verschluckt schnelle Vorgänge, ein Sekundentakt für eine träge Raumtemperatur erzeugt nur Datenmüll. Das Intervall gehört zum Charakter der Grösse.
• COV-Schwelle falsch gesetzt. Eine zu kleine Schwelle flutet den Puffer bei jedem Rauschen, eine zu grosse verschluckt relevante Änderungen. Die Schwelle muss zur normalen Schwankung der Grösse passen.
• Falsche Punkte oder gar keine aufgezeichnet. Wird erst im Betrieb festgelegt, was getrennt wird, fehlen für die kritische Anlaufphase genau die Daten, die man zur Optimierung bräuchte.
• Keine dauerhafte Archivierung geplant. Der Puffer im Gerät ist endlich. Ohne ein System, das die Daten regelmässig abholt und langfristig speichert, sind Langzeitauswertungen unmöglich.
• Uneinheitliche Zeitbasis. Sind die Uhren der Geräte nicht synchronisiert, lassen sich Verläufe aus verschiedenen Geräten nicht sauber übereinanderlegen. Eine gemeinsame Zeitquelle ist Voraussetzung für belastbare Auswertungen.

Trenddatenmengen richtig planen

Die Grösse der anfallenden Daten lässt sich beim intervallbasierten Aufzeichnen gut abschätzen. Sie ergibt sich aus der Zahl der aufgezeichneten Punkte, der Aufzeichnungsrate und dem Zeitraum, den der Puffer überbrücken soll. Ein Datenpunkt im Fünf-Minuten-Raster erzeugt rund 288 Einträge pro Tag. Multipliziert mit der Zahl der Punkte und den Tagen, die im Gerät vorgehalten werden sollen, ergibt sich die nötige Puffergrösse.

Daraus folgt eine einfache Planungsdisziplin. Man legt zuerst fest, welche Punkte überhaupt aufgezeichnet werden müssen, dann für jeden Punkt die Methode und die Rate, und schliesslich die Puffergrösse anhand der geforderten Überbrückungszeit. Genauso wichtig ist die Festlegung, wie oft das übergeordnete System die Daten abholt und wie lange sie dort archiviert werden. Erst diese Kette vom Puffer im Gerät bis ins Langzeitarchiv macht Trending vollständig.

Wer diese Grössen in der Ausschreibung konkret vorgibt, statt sie dem Zufall der Werkseinstellung zu überlassen, bekommt am Ende Trenddaten, die zur Anlage und zu ihren Auswertezielen passen. Aus der vagen Anforderung «wichtige Punkte trenden» wird so eine überprüfbare Liste aus Punkten, Methoden, Raten, Puffergrössen und Archivierungsregeln.

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 Trendliste. Sie hält fest, welche Punkte aufgezeichnet werden, mit welcher Methode und Rate, wie gross die Puffer sind und wohin die Daten archiviert werden. Diese Liste ist Teil der Übergabe und gehört überprüft, denn ein Trend Log, das niemand ausliest, nützt niemandem.

Für Planer und Bauherren gilt der Umkehrschluss. Wer das Buffer-Konzept und den Unterschied zwischen COV und Intervall kennt, kann die Aufzeichnung punktgenau vorschreiben und bei der Abnahme prüfen, ob die Puffer gross genug, die Raten sinnvoll und die Uhren synchron sind. Gute Trenddaten entstehen nicht zufällig, sondern weil jemand sie 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. Sie geben den Rahmen dafür, welche Objekttypen unterstützt werden müssen und wie Datenpunkte zu benennen und zu dokumentieren sind. Für die Trendaufzeichnung ergänzen viele Betreiber diesen Rahmen durch eigene Vorgaben zu Pflichtpunkten, Aufzeichnungsraten und Archivierungsfristen.

Fazit

Trend-Log-Objekte geben einer Anlage ihr Gedächtnis. Das Trend Log Object zeichnet eine einzelne Grösse auf, das Trend Log Multiple mehrere synchron mit gemeinsamer Zeitbasis. Über die Aufzeichnungsmethode entscheidet die Wahl zwischen festem Intervall und COV, über die Ausfallsicherheit die Puffergrösse zusammen mit dem Verhalten bei vollem Puffer. Ausgelesen werden die Verläufe gezielt über Read Range, und eine Schwelle sorgt dafür, dass das Archiv rechtzeitig abholt.

Entscheidend ist, dass Trending geplant und nicht nachgerüstet wird. Wer Punkte, Methoden, Raten, Puffer und Archivierung vorab festlegt, hat vom ersten Betriebstag an belastbare Daten. Wer es dem Zufall überlässt, merkt die Lücke erst dann, wenn die Daten fehlen und nicht mehr zu beschaffen sind.

In Teil 5 geht es von der Aufzeichnung zur Reaktion. Dann betrachten wir Event Enrollment und Notification Class, also das Alarmmodell von BACnet: Wie Alarme entstehen, wie sie zugestellt und quittiert werden und wie man eine kohärente Alarmphilosophie plant, statt die Betreiber in einer Flut von Meldungen zu ertränken.

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