Fehlererkennung und Diagnose (FDD) für Heizung, Lüftung und Klima in Gebäuden

Heizungs-, Lüftungs- und Klimaanlagen laufen oft monatelang in beeinträchtigtem Zustand: undichte Ventile, offen klemmende Klappen, Economiser, die nichts einsparen, driftende Sensoren, Zeitpläne, die Feiertage ignorieren. Niemand merkt es, weil das Gebäude noch „komfortabel“ ist. FDD-Software analysiert fortlaufend die Daten, die die Gebäudeautomation (GLT/BACS) ohnehin aufzeichnet, meldet solche Fehler, ordnet sie nach vergeudeter Energie und nennt dem Techniker eine wahrscheinliche Ursache. Sie ist das Gegenstück zur Regelungsoptimierung (OPT-007) im Monitoring und wird zu einem Compliance-Baustein unter der überarbeiteten EU-Gebäuderichtlinie (EPBD).

Problem & Nutzen

• Heute: Facility-Teams reagieren auf Komfortbeschwerden und Alarme. Ein GLT-Alarm löst nur aus, wenn eine harte Grenze überschritten wird; „gleichzeitiges Heizen und Kühlen“, in Handbetrieb belassene überschriebene Datenpunkte oder ein undichtes Heizungsventil im Sommer erzeugen keinen Alarm. Regelmäßige Begehungen oder Retro-Commissioning finden einen Teil davon, dann schleichen sich die Fehler wieder ein.
• KI-Nutzen: kontinuierliche Inbetriebnahme (Continuous Commissioning). Die Erkennung läuft rund um die Uhr an jedem Lüftungsgerät (RLT/AHU), VAV-Kasten, jeder Kältemaschine, jedem Heizkessel und jeder Pumpe; Befunde werden nach Kostenwirkung priorisiert, sodass ein kleines Team die 20 wichtigen Punkte bearbeitet statt tausender Alarme. Energieeinsparung, Komfort und Lebensdauer der Anlagen verbessern sich; Serviceeinsätze werden gezielt.
• Belege: Analytikbasierte Inbetriebnahme und FDD gehören zu den am besten untersuchten Maßnahmen zur Gebäudeeffizienz; die Literatur der US-Nationallabore (LBNL, PNNL) dokumentiert Einsparungen durch die Behebung von Fehlern, die per Analytik gefunden wurden, mit stark schwankenden Ergebnissen je nach Gebäudetyp, Ausgangszustand und Konsequenz, mit der Befunde umgesetzt werden [3][4]. Es sollte keine allgemeingültige Einsparzahl versprochen werden; messen Sie gegen Ihre eigene Basislinie (IPMVP, siehe Kennzahlen).
• Regulatorischer Treiber: Die Neufassung der EPBD (Richtlinie (EU) 2024/1275) verlangt Gebäudeautomations- und Steuerungssysteme in größeren Nichtwohngebäuden (HVAC > 290 kW) und erwartet ein Monitoring, das Effizienzverluste erkennt und das Facility Management informiert; Deutschland setzt dies über das GEG um [1]. FDD ist der praktische Weg, die Anforderung „Effizienzverlust erkennen“ in der Breite zu erfüllen.

Varianten

• Portfolio-FDD (Cloud, viele Standorte): eine Analyseplattform für Hunderte Handels-, Büro- oder Schulgebäude; ein zentrales Energiemanagement-Team priorisiert.
• Einzelner großer Campus / Krankenhaus / Rechenzentrumshalle: Analytik On-Premises oder am Edge, eng integriert mit dem CAFM und mit strikter Trennung der Betriebstechnik (OT).
• Öffentliche Gebäude und Kommunen: FDD für Pflichten des Energiemanagements und Förderberichte.
• Vermieter/Servicedienstleister (Contracting, Facility Services): FDD als Grundlage leistungsbasierter Serviceverträge.
• Kleine Gebäude ohne GLT: nachgerüstete Sensoren/IoT-Gateways plus regelbasiertes Cloud-FDD; einfache „Light“-Angebote.
• Private Nutzung: Hinweise auf Auffälligkeiten bei Wärmepumpen und Smart-Thermostaten für Hausbesitzer (wenige einfache Regeln, z. B. Takten, hohe Rücklauftemperatur) → siehe PRED-031, PRED-048.

So funktioniert es

1. GLT / Feldbus (BACnet, KNX, Modbus, OPC UA, MQTT) + Zähler + Wetter
2. Gateway / Konnektor (Edge, nur lesend)
3. Zeitreihenspeicher
4. semantisches Modell (Brick / Haystack: welcher Datenpunkt ist „Zulufttemperatur von RLT-3“)
5. Fehlererkennung (Regeln aus ASHRAE-artigen Bibliotheken + ML-Basislinien + Residuenmodelle)
6. Diagnose (Fehlerbaum / Klassifikator; LLM entwirft Erklärung aus Datenpunkttrends und Handbüchern)
7. Wirkungsquantifizierung (kWh, EUR, CO2 gegenüber fehlerfreier Basislinie)
8. priorisierte Fehlerliste
9. Ticket im CAFM/CMMS
10. Techniker behebt
11. Verifikation (Fehler behoben?)

• Regeln bleiben das Rückgrat. Etablierte Regelsätze (AHU Performance Assessment Rules, Abweichungen von den Sequenzen nach ASHRAE Guideline 36, „Ventil > X % offen, während der Wärmetauscher keinen Temperaturanstieg sieht“) sind transparent und brauchen keine Trainingsdaten.
• ML ergänzt: (a) gelernte Modelle des Normalverhaltens je Anlage (Regression/Gradient Boosting auf Wetter, Last und Zeitplan), deren Residuen Drift anzeigen; (b) multivariate Anomalieerkennung; (c) Zeitreihen-Basismodelle (Foundation Models) (Chronos, TimesFM, Moirai) als Zero-Shot-Basislinien bei dünner Datenlage; (d) Klassifikation von Fehlertypen, wenn gelabelte Historie vorliegt.
• Semantische Metadaten sind der eigentliche Engpass. Herstellerspezifische Datenpunktnamen auf ein gemeinsames Modell (Brick, Project Haystack) abzubilden, macht Regeln zwischen Gebäuden übertragbar [5][6]. LLMs helfen inzwischen beim Taggen von Datenpunkten anhand von Namen und Beschreibungen; die Ergebnisse muss eine Ingenieurin bzw. ein Ingenieur prüfen (siehe DATA-016 für den allgemeinen Ansatz).
• LLM-Schicht: verwandelt einen Fehler samt Kontext in einen Text für den Arbeitsauftrag, fasst wöchentliche Befunde zusammen, ruft die passende Stelle im Servicehandbuch ab (KNOW-004) und beantwortet „Warum verbraucht AHU-3 so viel Wärme?“. Fehler erkennt es nicht.
• Mensch-in-der-Schleife (Human-in-the-Loop): Das Facility Management bestätigt oder verwirft Befunde (die Rückmeldung stimmt Schwellenwerte ab); Reparaturen und jede Änderung an Regelsequenzen führen qualifizierte Techniker aus und geben sie frei. Das Zurückschreiben in die GLT ist nicht Teil von FDD; falls gewünscht, gehört es zur Optimierung (OPT-007) hinter Freigaben.

Datenaufbereitung

Die Daten stammen aus der Gebäudeleittechnik (GLT/BMS), von Reglern und Zählern über BACnet, Modbus oder OPC UA, dazu Datenpunktlisten, Anlagenschemata und Wartungsunterlagen. In der Praxis liegen sie in der GLT-Datenbank, in PDFs der Servicetechniker, in CAFM-Werkzeugen und in Wartungsprotokollen auf Papier.

Typische Lücken: uneinheitliche oder fehlende Datenpunktnamen (kein Tagging nach Brick oder Haystack), nicht kalibrierte Sensoren, Lücken und unterschiedliche Abtastraten, keine Schemata, die Datenpunkte mit Anlagen verknüpfen, und abgeschaltete Trendaufzeichnung zum Sparen von Speicher. Der Zugang zur GLT liegt oft beim Dienstleister, daher sind vertragliche Zugriffsrechte wichtig.

Schritte der Aufbereitung: Datenpunkte und Quellen inventarisieren (PREP-001, PREP-005), Trenddaten exportieren und Zeitstempel normalisieren, Datenpunkte nach einem Namensschema taggen (PREP-010), ein Glossar der Anlagenbegriffe erstellen (PREP-015), Papierprotokolle digitalisieren (PREP-006, PREP-008) und Labels aus früheren Arbeitsaufträgen als bekannte Fehler gewinnen (PREP-020). Werkzeuge: Python- oder n8n-Pipelines, eine Zeitreihendatenbank, Tagging auf Basis von Brick.

Grober Anteil am Aufwand: etwa 40 bis 50 Prozent, vor allem Zuordnung der Datenpunkte und Datenzugang. Siehe auch GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU (Immobilieneigentümer, kleine Betreiber): Weg A, weil FDD als Cloud-Dienst oder Modul von Gebäudeleitsystemen angeboten wird und die HVAC-Fehler Standard sind.
• Großunternehmen (Portfolio-Eigentümer, Facility Manager): Weg B, da viele Gebäude mit unterschiedlichen Gebäudeleitsystemen eine integrierte Datenschicht und eigene Regel- und Modelllogik brauchen.
• Entwickler: Weg C, da Open-Source-Stacks (Zeitreihendatenbank, offene FDD-Regelbibliotheken) auf HW1 laufen und zu Integratoren passen, die einen eigenen Dienst aufbauen.
• Öffentliche Hand (kommunale und staatliche Gebäude): Weg B in einer souveränen EU- oder deutschen Cloud, die Vergabe- und Souveränitätsanforderungen für Gebäudedaten erfüllt.

Weg A — Kaufen (Standardsoftware) (für die meisten Organisationen empfohlen)

• Analytik der GLT-Hersteller: Siemens (Building X / Desigo CC), Schneider Electric (EcoStruxure Building Advisor), Johnson Controls (OpenBlue), Honeywell (Forge); EU-/deutsche/Schweizer GLT-Anbieter mit Analytik- oder Energiemonitoring-Modulen: Kieback&Peter, Sauter, Ennovatis (aktuelles Angebot je Anbieter prüfen).
• Unabhängige FDD-/Analyseplattformen: SkyFoundry SkySpark, Clockworks Analytics, Mapped, Willow, Gridium und ähnliche; unabhängige Plattformen sind herstellerneutral und decken gemischte GLT-Bestände ab.
• Prüfen: BACnet-/OPC-UA-Anbindung ohne eingreifende Änderungen, Datenhaltung in der EU oder On-Premises-Option, Brick-/Haystack- Export (Lock-in vermeiden), Nachvollziehbarkeit jedes Fehlers (Trend zeigen), Schätzung der Kostenwirkung, CAFM-Integration, Vertragsbedingungen zum Dateneigentum.
• A wählen, wenn: Sie eine GLT mit Trendaufzeichnung, kein eigenes Data-Science-Team und Ergebnisse binnen Wochen wollen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Pipeline: Gateway veröffentlicht per MQTT → Cloud-Zeitreihendienst (Azure Data Explorer/Digital Twins, AWS IoT SiteWise/TwinMaker, Google BigQuery in EU-Regionen oder verwaltetes Timescale/Influx in einer EU-Region) → Regel- und ML- Jobs → Dashboards.
• LLM-Einsatz: führende LLMs mit Tool-Calling (Claude, Gemini, GPT, Mistral — EU-Regionen, wo angeboten) für Erklärungen, Entwürfe von Arbeitsaufträgen und die Zuordnung von Datenpunktnamen zu Brick; die Verarbeitung der Rohdaten bleibt deterministisch.
• B wählen, wenn: Sie Dienstleister oder großer Eigentümer sind, ein differenziertes Produkt bauen und bereits eine Cloud-Datenplattform betreiben.

Weg C — Selbst betreiben (Open Source)

• Daten & Semantik: Brick Schema + BrickServer/Ontologiewerkzeuge, Project-Haystack-Tags, TimescaleDB oder InfluxDB, Grafana, Node-RED oder Apache NiFi, Mosquitto/EMQX für MQTT, BACnet-Zugriff über bacpypes3 oder die VOLTTRON-Plattform (PNNL) [7].
• Erkennung: Regelbibliotheken in Python/SQL umgesetzt; scikit-learn/LightGBM/PyOD für Basislinien; Chronos oder TimesFM für Residuen aus Zero-Shot-Prognosen; Modelica Buildings Library, EnergyPlus und das BOPTEST-Framework für simulationsbasierte Tests der Regeln vor dem Produktivstart [8].
• LLM (optional): ein kleines Modell mit offenen Gewichten (z. B. Qwen3 oder Mistral/Llama-Familie 7–14B), betrieben über Ollama oder vLLM, für Erklärungen und Ticket-Texte.
• Hardware: HW1 (ein CPU-Server oder industrieller Edge-PC) genügt für Regeln und klassisches ML auf tausenden Datenpunkten; HW2 nur, wenn ein lokales LLM hinzukommt. Betriebsaufwand: erheblich für Datenmodell und Konnektoren.
• C wählen, wenn: OT-Netze vom Internet getrennt (Air-Gap) sind, Souveränitätsanforderungen einer Behörde gelten oder eigenes Engineering vorhanden ist.

Weg D — Eigenes Training

Selten nötig. Lohnt sich für Portfoliobetreiber mit vielen baugleichen Gebäuden: Modelle auf Anlagenebene mit mehrjähriger gelabelter Historie aus Fehlern und Arbeitsaufträgen trainieren (Fehlerklassifikator, Restnutzungsdauer, Regression der Kostenwirkung) oder ein kleines Sprachmodell für die Zuordnung von Datenpunktnamen zu Brick feintunen. Erforderlich sind gelabelte Fehlerepisoden, die den meisten Eigentümern fehlen: Beginnen Sie damit, die Urteile der Techniker zu jedem gemeldeten Befund zu erfassen und als Trainingsmenge zu nutzen.

Stand der Technik (2026)

• Standardisierte Semantik: Brick und Project Haystack sind die etablierten Metadatenmodelle; ASHRAE 223P (semantisches Modell für Gebäudesysteme) kommt in den Normeneinsatz. Die Übertragbarkeit von Regeln zwischen Gebäuden hat sich verbessert, doch die Anbindung eines Gebäudes ist weiterhin überwiegend Datenengineering [5][6].
• Der hybride Ansatz gewinnt: Produktivsysteme kombinieren transparente Regelbibliotheken (verlässlich, erklärbar) mit ML- Basislinien (erfassen, was Regeln übersehen). Reine Black-Box-Deep-Learning-Ansätze sind im Betrieb selten, weil Techniker eine Begründung brauchen, nicht nur einen Score.
• LLMs im Ablauf: Forschung und Produkte von Anbietern setzen 2025–2026 LLMs ein, um Fehler zu erklären, Arbeitsaufträge zu erzeugen, Datenpunktnamen zuzuordnen und Gebäudedaten in natürlicher Sprache abzufragen. Berichtete Erkennungsgenauigkeiten rein LLM-basierter Ansätze sind mit Vorsicht zu behandeln; die meisten veröffentlichten Ergebnisse stammen aus Simulationen oder Labordaten.
• Validierung durch Simulation: BOPTEST und Simulation mit digitalen Zwillingen erlauben das Einspeisen von Fehlern, um Erkennungsalgorithmen vor dem Einsatz zu testen [8].
• Grenzen und Fehlerbilder: schlechte Datenqualität (fehlende Trends, falsche Einheiten, überschriebene Datenpunkte, falsch bezeichnete Sensoren) verursacht die meisten Fehler; Fehlalarme untergraben das Vertrauen und führen zu Alarmmüdigkeit; unbekannte Planungsvorgaben machen „Fehler“ und „gewolltes Verhalten“ mehrdeutig; Einsparungen entstehen nur, wenn Fehler tatsächlich behoben werden, daher ist die Einbindung in den Arbeitsablauf wichtiger als der Algorithmus.

Gemeinsame Bausteine & Kombinationen

• Gleiche Datengrundlage wie OPT-007 (Energiemanagement von Gebäuden & HVAC-Optimierung): BACnet-Konnektoren, Brick-Modell, Zeitreihenspeicher. Erst FDD, dann Optimierung; eine fehlerhafte Anlage zu optimieren vergeudet Aufwand.
• ANOM-005 / PRED-006: derselbe Stack für Anomalieerkennung und Zeitreihen und dasselbe Edge-Gateway (HW1) können industrielle Anlagen bedienen; FDD liefert den Modellen für vorausschauende Wartung die Fehlerhistorie.
• DATA-016: Kontextualisierung von Anlagen/Datenpunkten (Unified Namespace) wird mit industriellen Datenprojekten geteilt.
• PRED-048 / PRED-031: Prognose der Energieeffizienz von Gebäuden und Smart-Meter-Analysen liefern Basislinien und Benchmarks; FDD-Ergebnisse priorisieren Sanierungsmaßnahmen.
• KNOW-004: RAG über Servicehandbücher für Techniker; AGENT-002: Workflow-Engine für Tickets und Eskalationen.
• SEC-015: die Überwachung und Segmentierung des OT-/GLT-Netzes, die den Pfad über das Gateway schützen muss.
• ANOM-030: der Ansatz zur Erläuterung von Kennzahlen und Anomalien lässt sich für das Reporting der Energiekosten wiederverwenden.
• Hardware: ein Edge-PC oder kleiner Server je Standort oder je Portfolio; eine optionale HW2-GPU, die mit anderen LLM-Aufgaben geteilt wird.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen für Anbindung und Abstimmung je Standort; üblicherweise Abopreis je Gebäude, je Datenpunkt oder je Geschossfläche. Weg B: 2–6 Monate für eine Plattform mit wenigen Gebäuden; Kostentreiber sind Cloud-Ingest und Engineering. Weg C: 3–9 Monate, überwiegend Metadatenmodellierung und Konnektoren; geringe Lizenzkosten.
• Hauptkostentreiber: Datenanbindung (Zuordnung der Datenpunkte, Konfiguration der Trendaufzeichnung) und die Kapazität des Serviceteams zur Behebung, nicht der Algorithmus.
• Kennzahlen: Anzahl und Alter offener Fehler; Zeit von der Erkennung bis zur Behebung; verifizierte eingesparte Energie und Kosten je Fehler (Messung und Verifizierung nach IPMVP); Fehlalarmquote (Anteil der von Technikern verworfenen Befunde); Komfort- beschwerden; Anteil der Anlagen mit nutzbaren Daten; vermiedene Notfalleinsätze.

Menschen & Veränderung

Beziehen Sie die Geschäftsleitung für die Energie- und Komfortziele ein, die Leitung des Facility Managements als Prozessverantwortliche, die Techniker (Endanwender), die Fehler bearbeiten, die IT und die IT-Sicherheit, weil GLT-Netze kritische Infrastruktur sind, den GLT-Hersteller oder Dienstleister (Lieferanten) für den Datenzugang und die Datenverantwortlichen der Gebäudedaten. Die Beteiligung der Datenschutzbeauftragten ist meist gering, doch Belegungssensoren, Raumbuchungen oder Zutrittsdaten können personenbezogen sein; klären Sie dies vor ihrer Nutzung und schließen Sie mit Cloud-Anbietern einen AVV.

Betriebsrat: abhängig. Anlagendaten allein überwachen keine Beschäftigten. Werden Reaktionszeiten der Techniker, Arbeitsaufträge oder die Belegung nach Personen sichtbar, gilt §87 Abs. 1 Nr. 6 BetrVG, und §90 Abs. 1 Nr. 3 verlangt frühzeitige Unterrichtung. Halten Sie Berichte auf Anlagenebene.

Bedenken: die Angst, dass Diagnosen die Techniker ersetzen und Fehlalarme Zeit kosten. Pilotieren Sie in einem oder zwei Gebäuden, lassen Sie Techniker jeden Befund bestätigen oder verwerfen und nutzen Sie ihre Urteile, um Regeln abzustimmen. Das System schlägt vor; Menschen entscheiden über Eingriffe und sicherheitsrelevante Maßnahmen. Fördern Sie die KI-Kompetenz (Art. 4 KI-Verordnung) durch kurze Schulungen. Siehe GUIDE-009, GUIDE-008 und GUIDE-013.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko. FDD berät Menschen bei der Wartung; es ist kein Sicherheitsbauteil im Betrieb kritischer Infrastruktur nach Anhang III (es steuert zum Beispiel nicht selbst Wärmeversorgungsnetze). Eine geschlossene Regelung, die eine Sicherheitsfunktion ist, bräuchte eine gesonderte Bewertung. Die Pflicht zur KI-Kompetenz (Art. 4) gilt [2].
• DSGVO: überwiegend Maschinendaten. Personenbezogene Daten können aus Belegungs- und Zutrittsdaten, Raumbuchungsdaten und mieterbezogener Zählung entstehen; nutzen Sie nach Möglichkeit aggregierte Daten und einen Auftragsverarbeitungsvertrag mit SaaS-Anbietern. Die Mitbestimmung des Betriebsrats (BetrVG §87) kann greifen, wenn Belegung oder individuelle Nutzung analysiert werden.
• Baurecht: EPBD 2024/1275 (BACS, Monitoring), deutsches GEG, ISO 52120-1 (Einfluss von BACS auf die Energie- effizienz), DIN EN ISO 16484 (BACS), ASHRAE Guideline 36 für Sequenzen [1].
• Sicherheit: GLT-Netze sind OT; halten Sie die Verbindung schreibgeschützt, segmentieren Sie das Netz, folgen Sie NIS2 und einer an IEC 62443 ausgerichteten Praxis; Cloud-Anbindung über Gateways, die nur ausgehend verbinden.
• Betriebsrisiko: falsche Diagnosen, die zu unnötigen Reparaturen führen; mindern Sie dies, indem Sie zu jedem Befund die Belege zeigen und nach der Reparatur validieren.

Erste Schritte

1. Systeme inventarisieren: GLT-Hersteller, Protokolle, vorhandene Trendaufzeichnung, Anzahl der Lüftungsgeräte, Kältemaschinen, Heizkessel; prüfen, ob die 290-kW-Schwelle der EPBD/des GEG gilt.
2. Einen Piloten wählen: ein oder zwei Gebäude mit bekannten Komfort- oder Energieproblemen und ausreichender Trendhistorie (mehrere Monate, 5–15 Minuten Auflösung).
3. Eine Auswahlliste von Anbietern oder Open-Source-Regeln an diesem Piloten laufen lassen; die Befunde mit einer Begehung durch Techniker vergleichen.
4. Den Ablauf vereinbaren: Wer prüft Befunde, wer behebt sie, wie werden Einsparungen verifiziert (Basislinie und IPMVP-Option).
5. Das Metadatenmodell (Brick/Haystack) bei der Anbindung des ersten Standorts aufbauen, damit die Regeln auf das Portfolio skalieren.

Quellen

Hinweis: Die Quellen wurden im Okt. 2026 aus stabilen Primärseiten zusammengestellt; das Budget für die Websuche der Recherchesitzung war erschöpft, daher stammen einige Anbieterangaben aus Vorwissen und sind mit „prüfen“ gekennzeichnet. 1. Directive (EU) 2024/1275 on the energy performance of buildings (recast) — https://eur-lex.europa.eu/eli/dir/2024/1275/oj 2. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj 3. Lawrence Berkeley National Laboratory — Building Technology & Urban Systems, fault detection and diagnostics research — https://buildings.lbl.gov/ 4. Pacific Northwest National Laboratory — building energy research — https://www.pnnl.gov/ 5. Brick Schema — https://brickschema.org/ 6. Project Haystack — https://project-haystack.org/doc/index 7. VOLTTRON (PNNL) — https://volttron.org/ 8. BOPTEST (IBPSA Project 1) — https://ibpsa.github.io/project1-boptest/ 9. ASHRAE Guideline 36 — High-Performance Sequences of Operation for HVAC Systems — https://www.ashrae.org/technical-resources/standards-and-guidelines