> For the complete documentation index, see [llms.txt](https://docs.buildings.ability.abb/collection/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buildings.ability.abb/collection/german/akademie/building-intelligence-ki-und-maschinelles-lernen-in-buildingpro-suites/maschinelles-lernen/einfuhrung-in-die-anomalieerkennung-in-intelligenten-gebauden/wie-buildingpro-suites-die-herausforderungen-der-anomalieerkennung-angeht.md). # Wie BuildingPro Suites die Herausforderungen der Anomalieerkennung angeht Viele Anomalieerkennungstools für Gebäude machen weitreichende Versprechen und lassen die Details vage. Diese Seite macht das Gegenteil. Sie beschreibt konkret, was ABB Ability™ BuildingPro Suites heute leistet, wie die echten Herausforderungen der Gebäude-Anomalieerkennung adressiert werden und wo die ehrlichen Lücken weiterhin bestehen. Die Anomalieerkennung in Gebäuden ist kein gelöstes Problem. Die Daten sind kontextabhängig, nicht stationär und durch eine Kette von Ursachen geprägt, die das eigentliche Problem an der Oberfläche nur selten sichtbar macht. Baselines verschieben sich, Labels sind rar, und die teuersten Anomalien sind oft die stillsten. Ein System, das diese Herausforderungen gut bewältigt, bedeutet weniger Zeit für das Triageen von Fehlalarmen, mehr Energieverschwendung, die entdeckt wird, bevor sie unbemerkt anwächst, und Betreiber, die dem vertrauen, was das Tool aufzeigt, weil es dieses Vertrauen im Laufe der Zeit verdient hat. Diese Seite erklärt, wie das erreicht wird — und wo die verbleibenden Lücken benannt statt versteckt werden. Kein einzelnes System löst jede Herausforderung vollständig. Manche Einschränkungen, etwa das Lernen aus unvollständigen historischen Daten, gelten für jeden Ansatz, der in realen Gebäuden ohne gelabelte Beispiele arbeitet. Entscheidend ist, ob die richtigen Probleme adressiert werden, die richtigen Kompromisse eingegangen werden und die verbleibenden Lücken einen glaubwürdigen Weg nach vorn haben. *** ## Die elf Anforderungen: Wo wir heute stehen Diese Seite verwendet die in [-> Von Gebäudedaten zu Erkennungsherausforderungen](/collection/german/akademie/building-intelligence-ki-und-maschinelles-lernen-in-buildingpro-suites/maschinelles-lernen/einfuhrung-in-die-anomalieerkennung-in-intelligenten-gebauden/von-gebaudedaten-zu-erkennungsherausforderungen.md) definierten Anforderungen als Referenz:
#Anforderung
R1Kontextbewusste Baseline
R2Wahrscheinlicher Erwartungsbereich
R3Persistenzverfolgung für anhaltende Abweichungen
R4Kontrollierte Anpassung ohne Aufnahme von Störungen
R5Trennung von Datenartefakten und physischen Anomalien
R6Funktioniert ohne gelabelte Daten und verbessert sich mit Feedback
R7Funktioniert mit begrenzten historischen Daten oder kleinen Datensätzen
R8Robust gegenüber unvollständigen historischen Baselines
R9Schätzung der finanziellen Auswirkung zur Priorisierung
R10Hierarchische Ursachenzuordnung
R11KI-gestützte Erklärung und empfohlene Maßnahmen
*** ## Wie wir die Baseline aufbauen: Kontext, nicht nur Historie ### R1 — Kontextbewusste Baseline ✓ Die Grundlage der Erkennungspipeline ist eine kontextabhängige Baseline. Statt einen Messwert mit einem festen Grenzwert oder einem einfachen gleitenden Durchschnitt zu vergleichen, schätzt das System, wie das erwartete gesunde Verhalten dieses Zählers genau in diesem Moment aussehen sollte — unter Berücksichtigung des aktuellen Wetters, der Tageszeit, des Wochentags, ob es sich um einen Feiertag oder einen normalen Arbeitstag handelt, und, sofern verfügbar, der Belegungsgrade und Produktionseinheiten. Diese Schätzung wird durch hochmoderne KI-Prognosemodelle unterstützt, die Zero-Shot-Inferenz verwenden — das heißt, sie benötigen kein Training an einem neuen Gebäude, bevor sie dafür genaue Vorhersagen liefern können. Diese Modelle sind auf Daten von Tausenden von Gebäuden aus einer breiten Vielfalt von Gebäudetypen, Klimazonen, Belegungsmustern und Betriebsregimen vortrainiert, und sie bringen dieses angesammelte Wissen vom ersten Tag an direkt in jedes neue Gebäude ein. Das bedeutet, dass die Baseline nicht eine starre Größe ist. Sie bewegt sich mit den Betriebsbedingungen des Gebäudes. Ein kalter Montagmorgen und ein warmer Feiertag erzeugen unterschiedliche Erwartungsbereiche für denselben Zähler. Eine Abweichung wird immer relativ zu dem bewertet, was unter den aktuellen Bedingungen erwartet wurde — nicht relativ zu einem allgemeinen historischen Durchschnitt. Dies ist das Baseline-Verhalten, das in [-> Energie-Anomalieerkennung](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection.md)verwendet wird. Sie konfigurieren den Umfang, die Schwellenwerte und die Betriebsparameter in [-> Energie-Anomalieerkennung konfigurieren](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/energie-anomalieerkennung-konfigurieren.md).

Echte Energiedaten in Gebäuden folgen selten einer einzigen Glockenkurve. Das Histogramm zeigt zwei klar getrennte Verbrauchscluster — unbesetzte und besetzte Modi. Eine einzelne Gauß-Verteilung (orange) spannt sich über beide und platziert ihr Maximum in der Lücke dazwischen, wo reale Daten fast nie auftreten. Das Mischmodell (grün) passt die tatsächliche Struktur an: zwei separate Modi, jeweils präzise dargestellt. Eine Beobachtung in der Lücke erhält beim Mischmodell eine niedrige Wahrscheinlichkeit — und ist korrekt anomal. Bei der einzelnen Gauß-Verteilung liegt sie nahe am Zentrum und bleibt unentdeckt.

*** ### R2 — Wahrscheinlicher Erwartungsbereich ✓ Das System erzeugt nicht einen einzelnen vorhergesagten Wert. Es modelliert die vollständige erwartete Verteilung des normalen Verhaltens zu jedem Zeitpunkt. Dies ist kein Konfidenzintervall um eine einzelne Vorhersage. Es ist eine vollständige Wahrscheinlichkeitsverteilung, die mehrere unterschiedliche Betriebsmodi gleichzeitig darstellen kann. Ein Gebäude, das zwischen einem unbesetzten Zustand mit niedrigem Verbrauch und einem besetzten Zustand mit hohem Verbrauch wechselt, hat nicht einen normalen Bereich. Es hat zwei, und der Bereich dazwischen ist einer, den ein gesunder Betrieb nur selten besucht. Hier versagen einfachere probabilistische Ansätze stillschweigend. Ein Konfidenzintervall oder ein symmetrisches Band um eine zentrale Vorhersage wird so breit, dass beide Modi abgedeckt werden, wobei die höchste Wahrscheinlichkeitsmasse in der Lücke dazwischen liegt — genau in dem Bereich, den reale Daten fast nie einnehmen. Eine Beobachtung in dieser Lücke wirkt unauffällig, weil sie numerisch nahe am Zentrum des Bandes liegt. Sie ist jedoch gerade deshalb anomal, weil sie in einem Bereich liegt, den keiner der beiden Betriebsmodi erzeugt. Das dem BuildingPro Suites zugrunde liegende Modell lernt die tatsächliche Form des erwarteten Verhaltens für jeden Zähler in jedem Kontext. Es nimmt nicht an, dass sich normales Verhalten um ein Zentrum gruppiert. Es entdeckt die echte Struktur der Gebäudebetriebsweise und weist entsprechend Wahrscheinlichkeiten zu. Ein Wert in der Lücke zwischen zwei Modi wird korrekt als wahrscheinlichkeitsarm erkannt — und damit als wirklich anomal — selbst wenn er absolut gesehen nicht extrem ist. Die Signifikanz der Anomalie spiegelt daher wider, wie unwahrscheinlich eine Beobachtung im Hinblick auf die vollständige erwartete Verteilung in diesem Moment ist. Das ermöglicht es, dass eine kleine nächtliche Abweichung korrekt als bedeutsamer eingestuft wird als eine größere Abweichung am Tag. Die nächtliche Verteilung ist eng und konzentriert, sodass schon eine moderate Abweichung davon wirklich ungewöhnlich ist.

Ein scharfer Ausschlag am 30. April 2026 hebt sich deutlich vom erwarteten Bereich ab. Das System identifiziert die Anomalie, markiert ihren Zeitbereich und kennzeichnet den Moment, in dem der tatsächliche Wert den erwarteten Bereich verlassen hat. Das ist der einfache Fall — eine kurze, stark ausgeprägte Abweichung. Die betrieblich wichtigere Herausforderung ist das Erkennen der Abweichungen, die moderat, aber anhaltend sind. Die finanzielle Auswirkung unterscheidet die beiden.

Jeder vertikale Ausschnitt zeigt die vollständige Wahrscheinlichkeitsverteilung des erwarteten Verbrauchs in diesem Moment — grün dort, wo das Modell eine hohe Wahrscheinlichkeit zuweist, rot dort, wo es eine geringe Wahrscheinlichkeit zuweist. Die tatsächliche Verbrauchskurve (schwarz) folgt während des normalen Betriebs den grünen, hochwahrscheinlichen Bereichen. Am 29. März hält sich der Verbrauch auf einem Mittelwert, der vollständig im roten Bereich liegt — einem Bereich, den das Modell angesichts des normalen Zweimodusverhaltens des Gebäudes als hoch unwahrscheinlich ansieht. Die Anomalie ist nicht deshalb sichtbar, weil der Wert extrem ist, sondern weil er dort liegt, wo das Gebäude fast nie betrieben wird.

*** ## Wie wir Anomalien über die Zeit verfolgen ### R3 — Persistenzverfolgung für anhaltende Abweichungen ✓ Zu erkennen, dass etwas zu einem Zeitpunkt ungewöhnlich ist, reicht nicht aus. Anhaltende Anomalien — also die, die am meisten kosten — treten selten als dramatische Einzelereignisse auf. Sie erscheinen als moderate, aber konsistente Abweichungen, die sich über Stunden, Nächte oder Wochen hinweg aufsummieren. BuildingPro Suites adressiert dies durch eine Erkennung über mehrere Zeithorizonte. Die Anomalieerkennung läuft gleichzeitig über mehrere zeitliche Granularitäten. Eine Abweichung, die sich auf einem kürzeren Zeithorizont konsistent zeigt — zum Beispiel erhöhter Nachtverbrauch in jedem 15-Minuten-Intervall über drei Nächte hinweg — wird sich auch als erhöhter Aggregatwert auf Tagesebene zeigen. Beide Ebenen werden unabhängig überwacht. Die Erkennung auf kurzer Zeitskala macht das Muster früh und präzise sichtbar. Die Erkennung auf längerer Zeitskala erfasst das kumulative Bild und bestätigt die Bedeutung dessen, was auf der unteren Ebene zu sehen ist. Dieser mehrschichtige Ansatz bedeutet, dass eine anhaltende Anomalie nicht davon abhängt, dass ein einzelnes Erkennungsereignis stark genug ist, um allein einen Schwellenwert zu überschreiten. Eine moderate, aber konsistente Abweichung auf 15-Minuten-Ebene summiert sich zu einer klar signifikanten Abweichung auf Tagesebene. Das System sieht beides. Eine Anomalie, die am Dienstagabend beginnt und bis Mittwoch andauert, wird nicht als Folge unzusammenhängender Alarme behandelt. Sie wird als ein zusammenhängendes Ereignis mit kumulativer finanzieller Auswirkung verfolgt, die so lange wächst, wie die Abweichung anhält. Ein kurzer Ausschlag und eine einwöchige nächtliche Abweichung mögen in einer Einintervallansicht ähnlich aussehen. Im Hinblick auf die Gesamtauswirkung sind sie jedoch völlig unterschiedliche Ereignisse. Das System bildet diesen Unterschied ab. Diese zeitübergreifende Sicht wird sichtbar in [-> Anomalie-Center](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaliezentrum.md) und zusammengefasst in [-> Dashboard mit Anomalieerkennungsstatistiken](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/statistik-dashboard-zur-anomalieerkennung.md). *** ### R4 — Kontrollierte Anpassung ohne Aufnahme von Störungen ✓ Eine Baseline, die sowohl aktuell als auch vertrauenswürdig ist, gehört zu den wichtigsten Designherausforderungen in der Gebäude-Anomalieerkennung. Eine Baseline, die sich nie anpasst, erzeugt mit dem Wechsel der Jahreszeiten und sich wandelnden Betriebsmustern Fehlalarme. Eine Baseline, die sich zu frei anpasst, absorbiert aktive Störungen und bleibt genau dann stumm, wenn sie etwas melden sollte. Der Ansatz in BuildingPro Suites löst diesen Konflikt durch denselben Zero-Shot-Inferenzmechanismus, der auch die kontextbewusste Baseline antreibt. Statt periodisch auf angesammelten Daten neu zu trainieren — was das Risiko birgt, Störungen zu absorbieren — passt sich das Modell kontinuierlich an jede neue Beobachtung an. Jeder neue Datenpunkt informiert sein Verständnis des aktuellen Zustands des Gebäudes. Das bedeutet, dass die Baseline legitime saisonale Übergänge und betriebliche Änderungen natürlich verfolgt, ohne einen geplanten Re-Trainingszyklus zu benötigen. Die entscheidende Schutzmaßnahme ist diese: Wenn eine Beobachtung als anomal markiert wird, gilt sie nicht als gesunder Datenpunkt. Sie trägt nicht zum sich weiterentwickelnden Verständnis des Modells darüber bei, was für dieses Asset normal ist. Die Anomalie wird vermerkt, verfolgt und sichtbar gehalten — die Baseline wird jedoch so aktualisiert, als wäre stattdessen der erwartete gesunde Wert aufgetreten. Das Ergebnis ist ein System, das in beide Richtungen korrekt arbeitet. Eine schrittweise saisonale Verschiebung — etwa ein von Woche zu Woche steigender Heizbedarf, während der Winter näher rückt — wird reibungslos verfolgt, ohne Fehlalarme auszulösen. Eine anhaltende Störung, die seit zwei Wochen läuft, zeigt weiterhin die vollen zwei Wochen kumulierter Auswirkungen, weil jede anomal gemessene Lesung von der Baseline ferngehalten und nicht in sie aufgenommen wurde. Die Erkennung über mehrere Zeithorizonte verstärkt dies zusätzlich. Eine Anomalie, die auf der kürzeren Zeitskala konsequent markiert wird, ist auch auf Tagesebene als erhöhter Aggregatwert sichtbar, wodurch anhaltende Störungen schwieriger zu übersehen sind, unabhängig davon, wie lange sie andauern.

Mit angewendeter Korrektur zur Inferenzzeit bleibt die Baseline sauber. Wenn eine anomale Beobachtung erkannt wird, wird sie nicht in den Kontext des Modells eingespeist — stattdessen wird der erwartete gesunde Wert verwendet. Die Vorhersage bleibt stabil und der Anomaliescore bleibt über die gesamte Dauer beider Störungen erhöht, einschließlich des kleineren zweiten Ereignisses. Die Störung ist von Anfang bis Ende sichtbar, und ihre gesamte kumulierte Auswirkung kann genau gemessen werden.

*** ## Wie wir die Datenqualität vor der Erkennung handhaben ### R5 — Trennung von Datenartefakten und physischen Anomalien ✓ Bevor irgendeine Anomalieerkennung stattfindet, führt die Pipeline regelbasierte Prüfungen auf eingehender Telemetrie durch, um Muster zu identifizieren, die mit bekannten Verbindungsproblemen übereinstimmen — Kommunikationslücken, verzögerte Wiederübertragungsstöße und Aggregationsartefakte aus gepufferten Datenauslieferungen. Wenn eine Anomalie gefunden wird, bewertet eine zusätzliche regelbasierte Prüfung, ob das Muster bekannten Verbindungs-Signaturen entspricht. Falls ja, wird es entsprechend behandelt und nicht als physische Anomalie dargestellt. Dadurch werden Datenqualitätsereignisse zu keinen falschen Anomaliesignalen, bevor Betreiber sie überhaupt sehen. Dieser Schritt läuft in der Produktion still im Hintergrund und automatisch ab. Der Betreiber muss ihn weder konfigurieren noch überprüfen. Er stellt lediglich sicher, dass das, was in den Anomalieansichten erscheint, das reale Gebäudeverhalten widerspiegelt und nicht das Netzwerkverhalten. Die gefilterten Ergebnisse erscheinen dann in [-> Anomalie-Center](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaliezentrum.md)statt Telemetrie-Artefakte in den Arbeitsablauf des Betreibers zu mischen. *** ## Wie wir mit begrenzten Daten und unvollständigen Baselines umgehen ### R6 — Funktioniert ohne gelabelte Daten, verbessert sich mit Feedback ✓ Das System benötigt zum Start keine gelabelten Anomaliedaten. Wenn ein neues Gebäude oder ein neuer Standort angeschlossen wird, beginnt die Erkennung sofort und nutzt das vortrainierte Wissen des Modells sowie die lokal verfügbaren Historiedaten, ohne dass Anomaliebeispiele manuell konfiguriert werden müssen. Mit der Zeit verbessert das Feedback der Betreiber das Verhalten des Systems. Nach der Prüfung einer Anomalie kann der Betreiber sie validieren als: * **Bestätigt** — die Anomalie war real und betrieblich relevant * **Falsch** — die Anomalie war kein echtes Problem

Nach der Prüfung einer Anomalie markiert der Betreiber sie als Bestätigt oder Falsch und kann einen Kommentar hinzufügen, der die tatsächliche Ursache beschreibt. Eine einzelne Validierung wirkt sofort. Falsch-Positive lehren das System, dass dieses Muster für dieses Asset erwartetes Verhalten ist. Bestätigte Anomalien schützen die Baseline davor, die Störung aufzunehmen. Der Kommentar steht dem KI-Analyseagenten außerdem zur Verfügung, wenn künftig Erklärungen für ähnliche Ereignisse auf diesem Asset erzeugt werden.

Betreiber können auch einen Kommentar hinzufügen, der erklärt, was das markierte Verhalten tatsächlich verursacht hat, etwa eine geplante Renovierung, ein besonderes Ereignis oder einen bekannten Test eines Geräts. Eine einzelne Validierung wirkt sofort — sie erfordert kein wiederholtes Feedback zum gleichen Muster, um zukünftige Behandlungen zu beeinflussen. Die Wirkung funktioniert in beide Richtungen: * Eine Falsch-Positive-Validierung lehrt das System, dass dieses Muster für dieses Asset normal ist. Zukünftige Vorkommen desselben Musters werden als erwartetes Verhalten und nicht als Anomalie behandelt. * Eine bestätigte Anomalie-Validierung bewirkt das Gegenteil: Sie signalisiert, dass dieses Muster nicht als gesund in die Baseline aufgenommen werden sollte. Das System bewahrt seine Sensitivität für diese Art von Abweichung auch künftig. Die Wirkung verstärkt sich mit der Zeit. Ein System, das an einem gut betriebenen Standort seit mehreren Monaten im Einsatz ist, hat eine deutlich niedrigere Fehlalarmrate als am ersten Tag, weil das Wissen des Betreibers schrittweise erfasst und integriert wurde. Diese Feedbackschleife ist sichtbar in [-> Anomalie-Center](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaliezentrum.md) und in [-> Tab "Anomalien"](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/registerkarte-anomalien.md)wo Betreiber Anomalien prüfen, validieren und kommentieren. *** ### R7 — Funktioniert mit begrenzten historischen Daten oder kleinen Datensätzen ✓ Ein neu angeschlossenes Gebäude, ein neu hinzugefügter Zähler oder ein Standort, der kürzlich erhebliche betriebliche Änderungen durchlaufen hat, stehen alle vor derselben Herausforderung: Die lokale Historie ist zu kurz oder nicht mehr repräsentativ, um allein eine verlässliche Baseline zu stützen. Dem wird direkt durch das Zero-Shot-Fundamentmodell im Kern der Pipeline begegnet. Da das Modell auf Daten von Tausenden von Gebäuden vortrainiert ist, benötigt es keine monatelange lokale Historie, um zu verstehen, wie ein Gebäude aussehen sollte. Es bringt Wissen darüber mit, wie sich Gebäude über eine breite Spanne von Typen, Klimazonen und Betriebsregimen verhalten, und nutzt den lokalen Kontext, um dieses Wissen auf das konkrete Gebäude anzupassen. Ein im August angebundenes Gebäude muss nicht bis zum folgenden Winter warten, um eine gültige Erwartung dafür zu haben, wie der Betrieb bei kaltem Wetter aussieht. Das Modell weiß bereits, wie Gebäude im Winter aussehen. Wenige Wochen lokaler Kontext reichen aus, um ihm zu zeigen, wie sich genau dieses Gebäude verhält, und das vortrainierte Wissen übernimmt den Rest. Dasselbe gilt nach erheblichen betrieblichen Änderungen. Da sich das Modell kontinuierlich aus dem jüngsten Kontext anpasst, statt sich auf ein festes historisches Fenster zu verlassen, reagiert es innerhalb von Tagen — nicht Monaten — auf eine Änderung der Betriebsmuster. *** ### R8 — Robust gegenüber unvollständigen historischen Baselines ◑ Wenn das System für ein Gebäude erstmals aktiviert wird, lernt es aus der verfügbaren lokalen Historie. Enthält diese Historie bereits anhaltende Ineffizienzen — eine Pumpe, die seit Monaten kontinuierlich läuft, ein Heizplan, der nach einer Renovierung nie korrigiert wurde —, können diese Muster in der erlernten Baseline vorhanden sein. Das System wird sie anfangs nicht markieren, weil ihm eine unabhängige Referenz dafür fehlt, wie das Gebäude vor dem Auftreten dieser Muster hätte aussehen sollen. Das ist eine strukturelle Einschränkung jedes Ansatzes, der aus realen Betriebsdaten ohne vorab gelabelte Beispiele für gesundes Verhalten lernt. Das wird hier offen anerkannt. Was heute hilft: * Nutzerfeedback verfeinert schrittweise das Verständnis des Systems dafür, was normal ist, und bestätigte Anomalien werden davor geschützt, aufgenommen zu werden. * Das Filtern nach finanzieller Auswirkung hält den Fokus auf Verhalten, das betrieblich relevant ist, und reduziert den Einfluss eingebetteter Ineffizienzen mit geringer Auswirkung. **Roadmap-Richtung:** Der geplante Ansatz ergänzt die statistische Energienanomalie-Ebene um regelbasierte und betriebslogische Fähigkeiten, die automatisch aus der Asset-Ontologie der Plattform erzeugt werden. Statt Regeln pro Standort manuell zu erstellen, werden diese Prüfungen automatisch aus der Gebäude-Konfiguration und der technischen Struktur generiert. Ihre Ergebnisse können dann verwendet werden, um wahrscheinliche ineffiziente Zeiträume in historischen Daten zu identifizieren und das Bereinigen der Baseline zu informieren, bevor das statistische Modell aus dieser Historie lernt. Dies zielt direkt auf die teilweise bestehende Lücke hier ab. *** ## Wie wir die finanzielle Auswirkung schätzen ### R9 — Schätzung der finanziellen Auswirkung zur Priorisierung ✓ Jede erkannte Anomalie erhält eine vorzeichenbehaftete Schätzung der finanziellen Auswirkung. Dies ist ein berechneter Wert, der aus der gemessenen Abweichung zwischen tatsächlichem Verbrauch und der kontextkonsistenten erwarteten Baseline abgeleitet und mit dem konfigurierten durchschnittlichen Energiepreis multipliziert wird. Da sich die erwartete Baseline mit dem Kontext verschiebt, spiegelt die Schätzung wider, was dieser spezielle Zähler unter diesen spezifischen Bedingungen hätte verbrauchen sollen — nicht einen pauschalen Durchschnitt über alle Betriebszustände. Das macht die Schätzung regimeskonsistent: Eine nächtliche Abweichung wird gegen das gemessen, was nachts erwartet wurde, nicht gegen den gesamten Tagesdurchschnitt des Gebäudes. Die Schätzung ist außerdem bewusst konservativ. Ziel ist es, eine belastbare und auf gemessener Abweichung beruhende Auswirkung zu berichten und nicht die scheinbare Größe von Einsparungen zu maximieren. Eine konservative Schätzung, die einer Prüfung zuverlässig standhält, schafft mehr betriebliches Vertrauen als eine optimistische, die Betreiber irgendwann abwerten lernen. Die Schätzung ist vorzeichenbehaftet: * Ein positiver Wert bedeutet Mehrausgaben — das Gebäude hat mehr als erwartet verbraucht. * Ein negativer Wert bedeutet einen niedrigeren als erwarteten Verbrauch, was Einsparungen oder eine Unterperformance darstellen kann, die untersucht werden sollte. Die finanzielle Auswirkung ist das wichtigste Werkzeug zur Priorisierung. Zwei Anomalien mit ähnlicher Form, aber sehr unterschiedlichen finanziellen Folgen, werden entsprechend eingestuft. Zwei konfigurierbare Schwellenwerte unterstützen dies: * **Schwellenwert für finanzielle Auswirkungswarnung** — nur Anomalien über einer definierten Auswirkung lösen einen aktiven Alarm aus. * **Zählerschwellenwert für finanzielle Auswirkung** — Zähler, deren maximal mögliche tägliche Auswirkung unter einer definierten Untergrenze liegt, werden von der Analyse ausgeschlossen. Sie können diese Priorisierung sehen in [-> Dashboard mit Anomalieerkennungsstatistiken](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/statistik-dashboard-zur-anomalieerkennung.md) und [-> Anomalie-Center](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaliezentrum.md)und sie konfigurieren in [-> Energie-Anomalieerkennung konfigurieren](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/energie-anomalieerkennung-konfigurieren.md).

Die Anomalieliste ist nach geschätzter finanzieller Auswirkung sortiert, wobei die größten Abweichungen oben stehen. Jede Zeile zeigt das Quell-Asset, den Anomalietyp, den Schweregrad, die finanzielle Auswirkung in Währung, die vorhergesagten und tatsächlichen Werte sowie die Abweichung. Negative Auswirkungswerte stehen hier für einen niedriger als erwarteten Verbrauch — Unterschreitungsanomalien, die aus betrieblichen Gründen untersucht werden sollten. Der Betreiber muss nicht entscheiden, wo er anfangen soll. Das finanzielle Ranking macht die Priorität explizit.

*** ## Wie wir die wahrscheinliche Ursache zuordnen ### R10 — Hierarchische Ursachenzuordnung ✓ Wenn auf hoher Ebene eine Anomalie erkannt wird — zum Beispiel auf Standort- oder Gebäudeebene —, durchläuft das System automatisch die physische Asset-Hierarchie, um zu identifizieren, welche Unter-Assets am stärksten zur beobachteten Abweichung beigetragen haben. Diese Kaskade wird automatisch ausgelöst, wenn eine Anomalie gefunden wird. Sie erfordert kein manuelles Triage. Das System nutzt die physische Containment-Hierarchie der Plattform — Standort, Gebäude, Etage, System, Gerät —, um die aggregierte Abweichung bis hinunter auf die niedrigste in der Hierarchie verfügbare Ebene in ihre beitragenden Teile zu zerlegen. Jedes beitragende Asset wird nach seinem Anteil an der gesamten Abweichung eingestuft. Der Betreiber sieht nicht nur, dass ein Gebäude eine Anomalie hat, sondern welche Etage, welches Teilsystem oder welches Asset auf niedrigerer Ebene am meisten dazu beigetragen hat und in welchem Zeitfenster. Das grenzt die Untersuchung von einem ganzen Gebäude auf einen konkreten Problembereich ein, bevor der Betreiber die Oberfläche verlassen muss. Dieses Drill-down wird abgebildet in [-> Anomalie-Center](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaliezentrum.md), [-> der Anomalie-Detailseite](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/detailseite-der-anomalie.md)und [-> Typ der Anomalie-Erkennungsanalyse](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/analytischer-typ-der-anomalieerkennung.md).

Wenn auf Gebäudeebene eine Anomalie erkannt wird, erweitert die Kaskade automatisch die physische Asset-Hierarchie, um zu zeigen, welche Unter-Assets dazu beigetragen haben. Hier zeigt Gebäude 132 eine Unterschreitungsanomalie. Die Kaskade macht sichtbar, dass die Etage Production Hall und bestimmte Assets darin — Assembly Unit Beta, MCB Assembly Line ML2, Testing and Quality Lab — jeweils einen Anteil an der gesamten Abweichung beigetragen haben. Der Betreiber kann die Anomalie vom Gebäude über die Etage bis zum einzelnen Asset nachverfolgen, ohne die Oberfläche zu verlassen.

*** ## Wie wir erklären und Maßnahmen empfehlen ### R11 — KI-gestützte Erklärung und empfohlene Maßnahmen ✓ Sobald die Anomalie erkannt, über die Zeit verfolgt und hierarchisch zugeordnet wurde, werden die strukturierten Belege an einen KI-Analyseagenten übergeben, der von einem großen Sprachmodell angetrieben wird. Dieser Agent hat Zugriff auf Ort und Zeit der Anomalie, die finanzielle Auswirkung, das Abweichungsmuster, die damaligen Kontextbedingungen und die durch die Kaskade identifizierten beitragenden Unter-Assets. Aus diesen Belegen erzeugt der Agent zwei Ausgaben, die in der Anomalie-Detailansicht angezeigt werden: * **Eine für Menschen lesbare Erklärung** dessen, was die Anomalie wahrscheinlich verursacht hat — abgeleitet aus den spezifischen Belegen für genau dieses Ereignis, nicht aus einer generischen Vorlage. * **Eine Liste empfohlener nächster Schritte** — konkrete Schritte, die der Betreiber zur Untersuchung oder Behebung des Problems unternehmen kann. Wichtige Abgrenzung: Der KI-Agent arbeitet ausschließlich mit Belegen, die bereits von der Erkennungs- und Zuordnungspipeline erzeugt wurden. Er übersetzt diese Belege in Sprache und Vorschläge. Er entscheidet nicht, ob eine Anomalie existiert, und er verändert auch nicht das Anomalieergebnis selbst. Seine Rolle ist Interpretation und Kommunikation, nicht Erkennung. Dies erscheint im Untersuchungsablauf über [-> der Anomalie-Detailseite](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/detailseite-der-anomalie.md) und [-> Typ der Anomalie-Erkennungsanalyse](/collection/german/suiten/energy-and-sustainability-intelligence/energy-anomaly-detection/analytischer-typ-der-anomalieerkennung.md).

Die Anomalie-Detailansicht zeigt drei KI-generierte Ausgaben. Diagnostics fasst die kontextuellen Fakten zusammen — Zeit, Temperatur, Wetterbedingungen und verfügbare Unterzählerdaten. Die KI-Erklärung übersetzt die Belege in eine für Menschen lesbare Ursache: in diesem Fall deutlich niedriger als erwarteter Verbrauch auf bestimmten Stromkreisen, mit einem konsistenten Muster auf dem Unterzähler, was darauf hindeutet, dass die angeschlossenen Geräte abgeschaltet waren oder mit reduzierter Last betrieben wurden. Empfohlene Maßnahmen geben dem Betreiber konkrete nächste Schritte — geplante Wartung prüfen, Automatisierungsprotokolle überprüfen, auf unerwartete Abschaltungen untersuchen. Der KI-Agent verändert das Anomalieergebnis nicht. Er gibt dem Betreiber einen Ausgangspunkt.

*** ## Was dieser Ansatz heute leistet und was nicht ### Was er heute leistet * Erkennt Abweichungen, die unter dem aktuellen Betriebs kontext im konfigurierten Energiebereich unwahrscheinlich sind * Modelliert die vollständige Wahrscheinlichkeitsverteilung des erwarteten Verhaltens, nicht nur ein Band oder Konfidenzintervall, und ermöglicht so das Erkennen von Anomalien zwischen Betriebsmodi * Verfolgt Anomalien gleichzeitig über mehrere Zeithorizonte — Muster auf kurzen Intervallen verdichten sich zu einer Bestätigung auf Tagesebene * Bewertet die Signifikanz von Anomalien im Kontext, nicht nur anhand der absoluten Abweichungsgröße * Passt sich kontinuierlich an legitime Veränderungen an, ohne aktive Störungen in die Baseline aufzunehmen * Funktioniert ab Tag eins ohne lokale Historie durch ein auf Tausenden von Gebäuden vortrainiertes Fundamentmodell * Trennt Verbindungsartefakte vor der Erkennung von physischen Anomalien * Schätzt für jede erkannte Anomalie eine vorzeichenbehaftete, regimeskonsistente und konservative finanzielle Auswirkung * Durchläuft automatisch die physische Asset-Hierarchie, um beitragende Unter-Assets zu identifizieren * Erzeugt über einen KI-Analyseagenten, der von einem großen Sprachmodell angetrieben wird, für Menschen lesbare Erklärungen und empfohlene Maßnahmen * Startet ohne gelabelte Anomaliedaten und verbessert sich fortlaufend durch Feedback der Betreiber ### Was es heute nicht vollständig löst **Bereits eingebettete historische Ineffizienzen** Bereits in der Trainingshistorie vorhandene anhaltende Ineffizienzen können zunächst als normal gelernt werden. Nutzerfeedback und finanzielle Filterung helfen, und die auf der Roadmap vorgesehene regelbasierte Baseline-Bereinigung zielt direkt auf diese Lücke ab. **Widersprüche in der Betriebslogik als separate Erkennungsebene** Die statistische Anomalieerkennung ist nicht das ideale Werkzeug für Probleme wie gleichzeitiges Heizen und Kühlen oder ein Ventil, das festzustecken scheint, wenn solche Muster bereits Teil des langfristigen Gebäudeverhaltens sind. Für diese Problemklasse ist eine Regel das richtige Werkzeug. **Direkte Anomalieerkennung auf Geräteebene überall** Der aktuelle Ansatz ist energieorientiert und hierarchiebasiert. Eine breitere direkte Erkennung auf Geräteebene ist eine geplante zukünftige Erweiterung. **Breitere Kontextsignale in allen Konfigurationen** Kontext wie Personenzahl oder produktionsbezogene Signale ist noch nicht in jeder Gebäudekonfiguration verfügbar. ### Roadmap-Richtung Die geplante Richtung besteht darin, die statistische Ebene der Energieanomalien um regelbasierte und betriebslogische Funktionen zu ergänzen, die automatisch aus der Asset-Ontologie der Plattform erzeugt werden. Dadurch würden Widersprüche wie gleichzeitiges Heizen und Kühlen erkannt, die Bereinigung historischer Baselines unterstützt und die Lücke bei anhaltenden, aber bereits normalisierten Ineffizienzen verringert. *** ## Anforderungen: Wo jede einzelne steht
#AnforderungStatus
R1Kontextbewusste Baseline✓ Wetter, Kalender, Belegung, Produktionseinheiten
R2Vollständige Wahrscheinlichkeitsverteilung des erwarteten Verhaltens✓ Mehrmodige Verteilung, Lückenerkennung, kontextskalierte Signifikanz
R3Persistenzverfolgung über Zeithorizonte hinweg✓ Erkennung über mehrere Zeithorizonte mit Verfolgung der kumulativen Auswirkung
R4Kontrollierte Anpassung ohne Aufnahme von Störungen✓ Kontinuierliche Zero-Shot-Anpassung, anomale Messwerte werden von der Baseline ferngehalten
R5Trennung von Verbindungsartefakten und physischen Anomalien✓ Regelbasierte Pipeline-Stufe, still und automatisch
R6Keine Labels erforderlich, Verbesserung durch Feedback✓ Zero-Shot-Start, Feedbackschleife mit Einzelnvalidierung
R7Funktioniert mit begrenzter oder saisonal unvollständiger lokaler Historie✓ Fundamentmodell, vortrainiert auf Tausenden von Gebäuden
R8Robust gegenüber unvollständigen historischen Baselines◑ Feedbackschleife hilft; regelbasierte Baseline-Bereinigung auf der Roadmap
R9Schätzung der finanziellen Auswirkung zur Priorisierung✓ Konservative, regimeskonsistente, vorzeichenbehaftete Auswirkung mit konfigurierbaren Schwellenwerten
R10Hierarchische Ursachenzuordnung✓ Automatische Kaskade durch die physische Asset-Hierarchie
R11KI-gestützte Erklärung und empfohlene Maßnahmen✓ KI-Analyseagent, angetrieben von einem großen Sprachmodell
*** ## Fazit Gebäude-Anomalieerkennung ist schwierig, weil die schwierigen Teile real sind: Der Kontext ändert sich, Baselines verschieben sich, Labels sind rar, die Datenqualität ist unvollständig und das Signal, das ein Problem offenbart, ist oft nicht der Ort, an dem das Problem begonnen hat. Entscheidend ist nicht, so zu tun, als gäbe es diese Schwierigkeiten nicht. Entscheidend ist, sie auf eine Weise zu adressieren, die in realen Betriebsabläufen nützlich ist. Der aktuelle Ansatz von BuildingPro Suites adressiert bereits die wichtigsten Anforderungen: kontextbewusste Erkennung, vollständiges probabilistisches Erwartungsverhalten über Betriebsmodi hinweg, Persistenzverfolgung über mehrere Zeithorizonte, Trennung der Datenqualität, konservative finanzielle Priorisierung, hierarchische Zuordnung und KI-gestützte Erklärung. Die verbleibenden Lücken — insbesondere bei unvollständigen historischen Baselines und Widersprüchen in der Betriebslogik — sind real und anerkannt. Genau deshalb stehen sie auf der Roadmap. Und das alles im Portfolio-Maßstab, über alle angeschlossenen Gebäude hinweg, ohne dass eine manuelle Konfiguration pro Standort oder pro Zähler erforderlich ist. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.buildings.ability.abb/collection/german/akademie/building-intelligence-ki-und-maschinelles-lernen-in-buildingpro-suites/maschinelles-lernen/einfuhrung-in-die-anomalieerkennung-in-intelligenten-gebauden/wie-buildingpro-suites-die-herausforderungen-der-anomalieerkennung-angeht.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.