Daten für Monitoring und KI: Was sauber sein muss, bevor Algorithmen helfen

Wer heute über KI in der Gebäudetechnik spricht, meint meistens automatische Fehlererkennung, vorausschauende Wartung oder optimierte Betriebsführung. Das sind sinnvolle Ziele. Doch in der Praxis scheitern solche Vorhaben selten an der Technologie, sondern an den Daten, die darunter liegen. Algorithmen können nur auswerten, was vorhanden, vollständig und plausibel ist. Fehlen Zeitstempel, stimmen Einheiten nicht überein oder sind Trendlücken die Regel statt die Ausnahme, produziert jede Auswertung Unsinn, egal wie leistungsfähig das Werkzeug ist.

Dieser vierte und letzte Teil der Serie «Gebäudedaten nutzbar machen» zeigt, welche Datenqualität Monitoring, Fehlererkennung und KI-Anwendungen in der Gebäudetechnik tatsächlich brauchen. Wir beschreiben, wo die häufigsten Schwachstellen liegen, was man vertraglich absichern muss und warum saubere Daten keine einmalige Aufgabe sind, sondern eine Betriebspflicht.

Warum KI keine schlechten Daten heilt

Es gibt eine verbreitete Vorstellung, dass KI-Systeme mit unvollständigen oder fehlerhaften Daten umgehen können, weil sie ja «lernen». Das stimmt in einem sehr engen Sinn: Manche Algorithmen erkennen Ausreisser oder füllen kurze Lücken statistisch. Doch das ist kein Ersatz für Datenqualität, sondern ein Notbehelf für Ausnahmesituationen.

Wenn ein Temperatursensor seit Monaten einen konstanten Wert liefert, weil er klemmt oder die Verbindung unterbrochen ist, erkennt kein Algorithmus automatisch, ob das ein stabiler Betriebszustand oder ein Defekt ist. Wenn Zählerdaten in unterschiedlichen Einheiten ankommen, weil ein Gerät Kilowattstunden und ein anderes Megawattstunden liefert, und das nirgends dokumentiert ist, rechnet das System falsch, ohne es zu merken. Wenn Trendaufzeichnungen Lücken von mehreren Stunden haben, fehlt genau der Zeitraum, in dem ein Fehler aufgetreten sein könnte.

KI ist ein Werkzeug zur Mustererkennung in grossen Datensätzen. Dieses Werkzeug setzt voraus, dass die Datensätze repräsentativ, konsistent und vollständig genug sind, um Muster überhaupt zu erkennen. Wer das nicht sicherstellt, bekommt keine besseren Erkenntnisse, sondern schnellere Fehler.

Die vier Dimensionen der Datenqualität

In unserer Arbeit mit Monitoring-Systemen und Betriebsoptimierung haben wir gelernt, Datenqualität in vier Dimensionen zu beurteilen. Diese Dimensionen sind nicht unabhängig voneinander, aber sie helfen, Schwachstellen gezielt zu finden.

Vollständigkeit

Vollständigkeit bedeutet zunächst, dass alle relevanten Datenpunkte überhaupt erfasst werden. Das klingt selbstverständlich, ist es aber nicht. In vielen Anlagen werden Sollwerte, Betriebsmeldungen und Stellsignale nicht aufgezeichnet, weil niemand beim Aufbau des Monitoring-Systems definiert hat, was gebraucht wird. Für eine einfache Verbrauchsübersicht reicht das. Für Fehlererkennung oder Betriebsoptimierung fehlt dann der Kontext: Man sieht den Energieverbrauch, aber nicht, ob die Anlage im Nennbetrieb, im Teillastbetrieb oder im Störungszustand war.

Vollständigkeit betrifft auch die zeitliche Dimension. Ein Datenpunkt, der mit einem Intervall von 15 Minuten aufgezeichnet wird, liefert 96 Werte pro Tag. Fehlen davon regelmässig 10 oder 20, weil das Gerät neu startet, die Verbindung abbricht oder der Puffer überläuft, entstehen systematische Lücken. Solche Lücken sind besonders tückisch, weil sie in Auswertungen oft nicht sichtbar sind: Das System interpoliert oder überspringt den Zeitraum, und niemand bemerkt, dass genau dort ein Betriebsproblem war.

Konsistenz

Konsistenz bedeutet, dass gleiche Dinge gleich dargestellt werden. Das betrifft Einheiten, Vorzeichen, Zeitstempel und Bezeichnungen. In der Praxis sehen wir regelmässig Anlagen, in denen ein Wärmezähler die Leistung in Kilowatt liefert, ein anderer in Watt, und ein dritter als Impulszähler, dessen Auflösung nirgends dokumentiert ist. Wer diese Daten zusammenführt, ohne das zu wissen, rechnet falsch.

Zeitstempel sind ein eigenes Kapitel. Automationsstationen, Gateways und Monitoring-Plattformen haben oft unterschiedliche Zeitquellen. Wenn ein Gerät keine Zeitsynchronisation hat oder die Sommerzeit falsch behandelt, verschiebt sich der Zeitstempel um eine Stunde oder mehr. Für eine Lastganganalyse, die Spitzen erkennen soll, ist das fatal: Die Spitze erscheint zu einem anderen Zeitpunkt als sie tatsächlich aufgetreten ist.

Konsistenz betrifft auch die Bezeichnungen. Wenn derselbe Datenpunkt in der Automationsstation «RLT_01_ZUL_TEMP», in der Managementebene «Zulufttemperatur RLT1» und in der Monitoring-Plattform «AHU-1-SA-T» heisst, braucht jede Auswertung eine manuelle Übersetzungstabelle. Das ist fehleranfällig und teuer. Wie Datenpunktbezeichnungen von Anfang an sauber strukturiert werden, haben wir in Teil 1 dieser Serie, «Datenpunktbezeichnung: Warum der Name eines Datenpunkts Geld spart», ausführlich beschrieben.

Plausibilität

Plausibilität bedeutet, dass die Werte physikalisch und betrieblich sinnvoll sind. Ein Temperatursensor, der im Sommer minus 40 Grad meldet, ist offensichtlich defekt. Schwieriger sind die subtilen Fälle: Ein Sensor, der immer genau 21,0 Grad meldet, weil er klemmt. Ein Volumenstromzähler, der nachts Werte liefert, obwohl die Pumpe ausgeschaltet ist. Ein CO2-Sensor, der bei geschlossenem Gebäude keine Veränderung zeigt, obwohl er sollte.

Plausibilitätsprüfungen können automatisiert werden. Man definiert Grenzwerte, Plausibilitätsregeln und Quervergleiche zwischen verwandten Datenpunkten. ASHRAE Guideline 36 beschreibt solche Ansätze für die Fehlererkennung in Lüftungsanlagen sinngemäss: Wenn ein Zuluftventilator läuft, muss der Volumenstrom über einem Mindestwert liegen. Wenn die Heizung aktiv ist, muss die Vorlauftemperatur über der Rücklauftemperatur liegen. Solche Regeln sind einfach zu formulieren, aber sie setzen voraus, dass alle beteiligten Datenpunkte vorhanden und konsistent sind.

Metadaten

Metadaten sind die Informationen über die Daten: Was misst dieser Datenpunkt? In welcher Einheit? Mit welcher Abtastrate? Zu welchem Gerät, welcher Anlage, welchem Gebäude gehört er? Ohne Metadaten ist ein Datenpunkt ein Zahlenstrom ohne Bedeutung.

In der Praxis fehlen Metadaten häufig oder sind unvollständig. Einheiten sind nicht dokumentiert. Die Abtastrate ist nirgends festgehalten. Der Bezug zur physischen Anlage existiert nur im Kopf des Inbetriebnahmetechnikers. Wenn dieser Techniker das Unternehmen wechselt, ist das Wissen weg.

Semantische Modelle wie Brick Schema und Project Haystack, die wir in Teil 2 dieser Serie, «Brick und Haystack: Semantische Modelle für Gebäudedaten einfach erklärt», vorgestellt haben, sind ein strukturierter Ansatz, um Metadaten maschinenlesbar zu machen. Sie lösen das Problem nicht von selbst, aber sie geben einen Rahmen vor, der verhindert, dass Metadaten im Freitext verschwinden.

Trendintervalle: Was wirklich gebraucht wird

Die Wahl des Trendintervalls ist eine technische Entscheidung mit grossen Auswirkungen auf die Auswertbarkeit. Zu grosse Intervalle verbergen Ereignisse. Zu kleine Intervalle erzeugen Datenmengen, die niemand verarbeiten kann und die Systeme überlasten.

Für Energiemonitoring und Verbrauchsauswertung sind 15-Minuten-Intervalle in der Schweiz weit verbreitet und für die meisten Zwecke ausreichend. Sie entsprechen dem Abrechnungsintervall vieler Energieversorger und erlauben eine sinnvolle Lastganganalyse. Für Fehlererkennung in Regelkreisen kann ein kürzeres Intervall nötig sein, etwa eine Minute oder weniger, weil Regelabweichungen sich schnell entwickeln und bei 15-Minuten-Werten bereits wieder verschwunden sein können.

Wichtig ist, das Intervall nicht pauschal für alle Datenpunkte gleich zu wählen. Ein Aussentemperatursensor ändert sich langsam, ein Minutenintervall wäre Verschwendung. Ein Druckdifferenzschalter an einem Filter kann innerhalb von Sekunden auslösen und wieder zurückfallen. Wer das mit einem 15-Minuten-Intervall aufzeichnet, sieht das Ereignis möglicherweise nie.

BACnet bietet mit dem Trend-Log-Objekt die Möglichkeit, ereignisgesteuert aufzuzeichnen, also immer dann, wenn sich ein Wert um mehr als einen definierten Betrag ändert. Das ist für viele Datenpunkte effizienter als ein festes Intervall. Wie Trend-Log-Objekte in BACnet konfiguriert werden, haben wir in «BACnet Objekte verstehen, Teil 4: Trend Log und Trend Log Multiple. Wie BACnet Betriebsdaten sichert» ausführlich erklärt.

Lücken erkennen und bewerten

Lücken in Trendaufzeichnungen sind unvermeidlich. Geräte werden neu gestartet, Verbindungen unterbrochen, Puffer überlaufen. Die Frage ist nicht, ob Lücken entstehen, sondern wie man sie erkennt, bewertet und dokumentiert.

Ein erster Schritt ist die systematische Lückenanalyse. Für jeden Datenpunkt wird geprüft, wie viele Werte im Verhältnis zur erwarteten Anzahl fehlen. Ein Datenpunkt mit einem 15-Minuten-Intervall sollte pro Tag 96 Werte liefern. Liefert er nur 80, fehlen 17 Prozent. Das ist ein Warnsignal, das untersucht werden muss.

Ein zweiter Schritt ist die Bewertung der Lücken. Kurze Lücken von wenigen Minuten, die durch einen Geräteneustart entstehen, sind meist unkritisch. Lücken von mehreren Stunden oder Tagen können bedeuten, dass ein Gerät ausgefallen ist, eine Verbindung dauerhaft unterbrochen ist oder ein Konfigurationsfehler vorliegt. Solche Lücken müssen nicht nur technisch behoben, sondern auch in der Auswertung gekennzeichnet werden: Berechnungen, die auf lückenhaften Daten basieren, müssen als unsicher markiert sein.

Ein dritter Schritt ist die Ursachenanalyse. Lücken, die immer zur gleichen Zeit auftreten, deuten auf ein systematisches Problem hin: ein Backup-Prozess, der die Verbindung blockiert, ein Gerät, das täglich neu startet, oder ein Netzwerksegment, das zu bestimmten Zeiten überlastet ist. Solche Muster sind mit einfachen Mitteln erkennbar, wenn man danach sucht.

Plausibilisierung: Automatisch und manuell

Plausibilitätsprüfungen können auf verschiedenen Ebenen stattfinden. Auf der Ebene einzelner Datenpunkte prüft man, ob Werte innerhalb physikalisch sinnvoller Grenzen liegen. Auf der Ebene verwandter Datenpunkte prüft man, ob Werte zueinander passen. Auf der Ebene des Betriebszustands prüft man, ob die Kombination von Werten einem bekannten Betriebsmuster entspricht.

Automatische Plausibilisierung ist effizient, aber sie erkennt nur, was man ihr beibringt. Regeln müssen formuliert, parametriert und gepflegt werden. Wenn sich eine Anlage ändert, müssen die Regeln angepasst werden. Das ist Aufwand, der oft unterschätzt wird.

Manuelle Plausibilisierung durch erfahrene Fachleute bleibt deshalb unverzichtbar. Wer eine Anlage kennt, erkennt Auffälligkeiten, die kein Algorithmus findet: Ein Wert, der zwar innerhalb der Grenzen liegt, aber für diese Jahreszeit oder diese Betriebsphase ungewöhnlich ist. Ein Muster, das auf einen schleichenden Defekt hindeutet, der sich über Wochen entwickelt. Eine Kombination von Werten, die einzeln plausibel sind, zusammen aber keinen Sinn ergeben.

Wir empfehlen deshalb, automatische Plausibilisierung und regelmässige manuelle Durchsicht zu kombinieren. Die Automatisierung filtert offensichtliche Fehler und markiert Auffälligkeiten. Die manuelle Durchsicht bewertet, was die Automatisierung nicht einordnen kann. Wie Monitoring-Daten für die Betriebsoptimierung genutzt werden, beschreiben wir in «Einsparpotenziale lesen und priorisieren: was die Monitoring-Daten wirklich zeigen».

Metadaten und Datenhoheit: Was vertraglich geregelt sein muss

Monitoring-Plattformen werden heute oft als Cloud-Dienste betrieben. Das hat Vorteile: keine eigene Infrastruktur, einfache Skalierung, regelmässige Updates. Es hat aber auch Risiken, die vertraglich geregelt sein müssen.

Das erste Risiko ist die Datenhoheit. Wer besitzt die Daten, die auf der Plattform gespeichert sind? Kann der Betreiber die Daten jederzeit vollständig exportieren? In welchem Format? Mit welchen Metadaten? Wenn ein Betreiber nach fünf Jahren den Plattformanbieter wechseln will, muss er die Daten mitnehmen können, sonst verliert er die gesamte Betriebshistorie.

Das zweite Risiko ist die Verfügbarkeit. Was passiert, wenn der Plattformanbieter seinen Dienst einstellt oder insolvent wird? Gibt es einen Notfallplan? Sind die Daten in einem offenen Format gespeichert, das auch ohne die Plattform lesbar ist?

Das dritte Risiko ist die Datennutzung. Viele Plattformanbieter nutzen die Daten ihrer Kunden für eigene Zwecke, etwa für das Training von Algorithmen oder für Benchmarking-Dienste. Das kann legitim sein, muss aber transparent und vertraglich geregelt sein. Betreiber sollten wissen, welche Daten zu welchem Zweck genutzt werden und ob sie dem widersprechen können.

Das vierte Risiko betrifft die Metadaten. Wenn Metadaten nur in der Plattform selbst gespeichert sind und nicht exportiert werden können, ist der Betreiber von der Plattform abhängig. Metadaten sollten deshalb in offenen, dokumentierten Formaten vorliegen, die unabhängig von der Plattform nutzbar sind. Semantische Modelle nach Brick Schema oder Haystack 4 sind dafür geeignet, weil sie auf offenen Standards basieren.

Wir empfehlen, diese Punkte vor dem Abschluss eines Vertrags mit einem Plattformanbieter schriftlich zu klären und im Vertrag festzuhalten. Ein Monitoring-System, das man nicht verlassen kann, ohne die Daten zu verlieren, ist kein Werkzeug, sondern eine Abhängigkeit.

Was SN EN ISO 52127-1 dazu sagt

Die SN EN ISO 52127-1 beschreibt Anforderungen an Gebäudeautomations- und Steuerungssysteme im Kontext der Energieeffizienz. Sie gibt sinngemäss vor, dass Monitoring-Systeme in der Lage sein müssen, relevante Betriebsdaten zu erfassen, zu speichern und für Auswertungen bereitzustellen. Dazu gehören nicht nur Messwerte, sondern auch Betriebszustände, Sollwerte und Alarme.

Die Norm betont, dass die Datenerfassung so gestaltet sein muss, dass Abweichungen vom Sollbetrieb erkannt werden können. Das setzt voraus, dass Sollwerte und Istwerte gemeinsam aufgezeichnet werden, nicht nur einer von beiden. Es setzt auch voraus, dass die Aufzeichnung kontinuierlich und lückenlos genug ist, um Abweichungen zeitlich einordnen zu können.

In der Praxis bedeutet das: Ein Monitoring-System, das nur Zählerstände aufzeichnet, erfüllt diese Anforderung nicht. Es braucht auch die Betriebsdaten der Anlage, also Laufzeiten, Betriebsmodi, Stellsignale und Regelabweichungen. Nur so lässt sich beurteilen, ob ein erhöhter Verbrauch auf einen Defekt, eine Fehleinstellung oder veränderte Nutzung zurückzuführen ist.

Datenqualität als Betriebspflicht

Ein häufiger Irrtum ist, Datenqualität als einmalige Aufgabe zu verstehen: Man richtet das Monitoring ein, prüft die Daten einmal und geht davon aus, dass alles in Ordnung bleibt. In der Realität verschlechtert sich die Datenqualität über die Zeit, wenn niemand sie aktiv pflegt.

Sensoren driften. Verbindungen werden instabil. Geräte werden ersetzt, ohne dass die Konfiguration des Monitoring-Systems angepasst wird. Neue Anlagenteile werden in Betrieb genommen, aber nicht ins Monitoring integriert. Metadaten veralten, weil sich die Anlage verändert hat, die Dokumentation aber nicht.

Datenqualität braucht deshalb eine verantwortliche Stelle und einen regelmässigen Prozess. Das muss nicht aufwendig sein, aber es muss systematisch sein. Wir empfehlen mindestens eine jährliche Überprüfung der Datenqualität, bei der Lücken, Plausibilitätsprobleme und veraltete Metadaten identifiziert und behoben werden. Bei Anlagen mit hohen Anforderungen an Fehlererkennung oder KI-Auswertung sollte diese Überprüfung häufiger stattfinden.

Wie Datenqualität im Energiemonitoring konkret bewertet wird und welche Fehler falsche Entscheide erzeugen, beschreiben wir in «Datenqualität im Monitoring: warum falsche Zähler falsche Entscheide erzeugen». Den Aufbau eines vollständigen Monitoring-Systems von der Messkonzeption bis zum Messstellenplan behandeln wir in «Vom Messkonzept zum Messstellenplan».

Der rote Faden zu unseren Fachbeiträgen

Dieser Artikel schliesst die Serie «Gebäudedaten nutzbar machen» ab. Die ersten drei Teile haben die Grundlagen gelegt: Teil 1, «Datenpunktbezeichnung: Warum der Name eines Datenpunkts Geld spart», zeigt, warum konsistente Bezeichnungen die Voraussetzung für jede Auswertung sind. Teil 2, «Brick und Haystack: Semantische Modelle für Gebäudedaten einfach erklärt», erklärt, wie Metadaten strukturiert und maschinenlesbar gemacht werden. Teil 3, «BIM to FM: Welche Daten der Betrieb wirklich braucht», beschreibt, welche Informationen aus dem Planungsprozess in den Betrieb übernommen werden müssen.

Für den Betrieb von Monitoring-Systemen empfehlen wir ausserdem unsere Artikel «Energiemonitoring aufbauen: was brauche ich wirklich?» und «Einsparpotenziale lesen und priorisieren: was die Monitoring-Daten wirklich zeigen». Wer verstehen will, wie Trenddaten in BACnet technisch konfiguriert werden, findet die Grundlagen in «BACnet Objekte verstehen, Teil 4: Trend Log und Trend Log Multiple. Wie BACnet Betriebsdaten sichert» und «Trending, Alarming & Scheduling: Die drei Betriebsfunktionen, die oft vergessen werden». Die Verbindung zwischen sauberen BACnet-Daten und energetischer Betriebsoptimierung beschreibt «Saubere BACnet-Daten als Grundlage für die energetische Betriebsoptimierung».

Fazit

KI und automatische Fehlererkennung sind keine Wundermittel. Sie sind Werkzeuge, die auf sauberen Daten aufbauen. Vollständige Trendaufzeichnungen, plausible Werte, konsistente Einheiten, vollständige Metadaten und klare Bezeichnungen sind keine optionalen Extras, sondern die Grundvoraussetzung dafür, dass jede automatische Auswertung verlässliche Ergebnisse liefert.

Datenqualität entsteht nicht von selbst und bleibt nicht von selbst erhalten. Sie braucht eine verantwortliche Stelle, einen regelmässigen Prozess und vertragliche Absicherung gegenüber Plattformanbietern. Wer das in den Betrieb integriert, schafft eine Grundlage, auf der Monitoring, Fehlererkennung und KI-Anwendungen tatsächlich funktionieren. Wer es nicht tut, investiert in Technologie, die schnellere Fehler produziert als manuelle Auswertung.

Sie haben Fragen dazu?

Sie möchten wissen, wie es um die Datenqualität in Ihrem Monitoring-System steht, oder Sie planen den Aufbau eines neuen Systems und wollen von Anfang an auf saubere Grundlagen setzen? Wir begleiten Sie von der Bestandsaufnahme bis zur laufenden Qualitätssicherung. Nehmen Sie Kontakt auf unter wenget.ch oder info@wenget.ch.

Quellenverzeichnis

• SN EN ISO 52127-1: Gebäudeautomation, Steuerung und Gebäudemanagement. Anforderungen an Systeme für die Energieeffizienz von Gebäuden.
• ASHRAE Guideline 36: High-Performance Sequences of Operation for HVAC Systems (sinngemäss, insbesondere Abschnitte zur Fault Detection and Diagnostics).
• Brick Schema: Open-Source-Ontologie für Gebäudedaten, RDF/Turtle-basiert. brickschema.org.
• Project Haystack: Tagging-Modell für Gebäudedaten, Haystack 4 mit Defs. project-haystack.org.
• SN EN ISO 16484-5 (SIA 386.155): Datenkommunikationsprotokoll BACnet, insbesondere Trend-Log-Objekte und Objekteigenschaften.
• SN EN ISO 52120-1 (SIA 386.111): Energieeffizienz von Gebäuden. Beitrag der Gebäudeautomation, -steuerung und des Gebäudemanagements.
• SN EN ISO 19650 (Teile 1 und 2): Organisation und Digitalisierung von Informationen zu Bauwerken und Ingenieurleistungen, einschliesslich Informationsmanagement mit BIM.
• Eigene Projekterfahrung der WENGET GmbH aus Monitoring-Aufbauten, Datenqualitätsanalysen und Betriebsoptimierungen in der Gebäudetechnik.