> 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-ai-and-machine-learning-in-buildingpro-suites/machine-learning/introduction-to-anomaly-detection-in-smart-buildings/how-buildingpro-suites-addresses-the-challenges-of-anomaly-detection.md). # Wie BuildingPro Suites die Herausforderungen der Anomalieerkennung adressiert Viele Tools zur Anomalieerkennung für Gebäude machen weitreichende Behauptungen und lassen die Details vage. Diese Seite macht das Gegenteil. Sie beschreibt konkret, was ABB Ability™ BuildingPro Suites heute leistet, wie die realen 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 machen. Baselines verschieben sich, Labels sind knapp, und die Anomalien, die am meisten kosten, sind oft die stillsten. Ein System, das mit diesen Herausforderungen gut umgeht, bedeutet weniger Zeit für das Abarbeiten von Fehlalarmen, mehr frühzeitig entdeckte Energieverschwendung, bevor sie unbemerkt anwächst, und Betreiber, die dem vertrauen, was das Tool anzeigt, weil es dieses Vertrauen über Zeit verdient hat. Diese Seite erklärt, wie das erreicht wird — und wo die verbleibenden Lücken ausdrücklich benannt statt verborgen werden. Kein einzelnes System löst jede Herausforderung vollständig. Manche Einschränkungen, wie 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 gewählt 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 Detektionsherausforderungen](/collection/german/akademie/building-intelligence-ai-and-machine-learning-in-buildingpro-suites/machine-learning/introduction-to-anomaly-detection-in-smart-buildings/from-building-data-to-detection-challenges.md) definierten Anforderungen als Referenz:
#Anforderung
R1Kontextbewusste Grundlinie
R2Probabilistischer erwarteter Bereich
R3Persistenzverfolgung für anhaltende Abweichungen
R4Kontrollierte Anpassung ohne Fehlerabsorption
R5Trennung von Datenartefakten und physischen Anomalien
R6Funktioniert ohne gelabelte Daten und verbessert sich mit Feedback
R7Funktioniert mit begrenzten historischen Daten oder kleinen Datensätzen
R8Robustheit gegenüber unvollständigen historischen Baselines
R9Schätzung des finanziellen Einflusses zur Priorisierung
R10Hierarchische Ursachenzuordnung
R11KI-gestützte Erklärung und empfohlene Maßnahmen
*** ## Wie wir die Baseline aufbauen: Kontext statt nur Historie ### R1 — Kontextbewusste Baseline ✓ Die Grundlage der Detektionspipeline 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 Messpunkts genau zu diesem Zeitpunkt aussehen sollte — unter Berücksichtigung des aktuellen Wetters, der Tageszeit, des Wochentags, ob Feiertag oder regulärer Arbeitstag ist, und, sofern verfügbar, Belegungsgraden und Produktionseinheiten. Diese Schätzung wird durch modernste KI-Forecasting-Modelle unterstützt, die Zero-Shot-Inferenz verwenden — das heißt, sie benötigen kein Training auf einem neuen Gebäude, bevor sie dafür genaue Vorhersagen erzeugen können. Diese Modelle sind mit Daten aus Tausenden von Gebäuden über eine große Bandbreite an Gebäudetypen, Klimazonen, Belegungsmustern und Betriebsregimen vortrainiert und bringen dieses angesammelte Wissen vom ersten Tag an direkt in jedes neue Gebäude ein. Das bedeutet, die Baseline ist nichts Festes. Sie bewegt sich mit den Betriebsbedingungen des Gebäudes. Ein kalter Montagmorgen und ein warmer Feiertag ergeben unterschiedliche erwartete Bereiche für denselben Messpunkt. 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 Basisverhalten, das in [-> Energy Anomaly Detection](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection.md). Sie konfigurieren den Umfang, die Schwellenwerte und die Betriebsparameter in [-> Configure Energy Anomaly Detection](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/configure-energy-anomaly-detection.md).

Reale Gebäudeverbrauchsdaten folgen selten einer einzigen Glockenkurve. Das Histogramm zeigt zwei klar getrennte Verbrauchscluster — ungenutzte und genutzte Modi. Eine einzelne Gauß-Verteilung (orange) spannt beide auf und legt ihr Maximum in die Lücke zwischen ihnen, wo reale Daten nahezu nie auftreten. Das Mischmodell (grün) passt die tatsächliche Struktur an: zwei getrennte Modi, jeweils korrekt dargestellt. Eine Beobachtung in der Lücke erhält unter dem Mischmodell eine niedrige Wahrscheinlichkeit — und ist korrekt anomal. Unter der einzelnen Gauß-Verteilung liegt sie nahe am Zentrum und bleibt unentdeckt.

*** ### R2 — Probabilistischer erwarteter Bereich ✓ Das System erzeugt nicht einen einzelnen Vorhersagewert. Es modelliert die vollständige erwartete Verteilung des normalen Verhaltens zu jedem Zeitpunkt. Das ist kein Konfidenzintervall um eine einzelne Vorhersage. Es ist eine vollständige Wahrscheinlichkeitsverteilung, die mehrere unterschiedliche Betriebsmodi gleichzeitig abbilden kann. Ein Gebäude, das zwischen einem verbrauchsarmen ungenutzten Zustand und einem verbrauchsintensiven genutzten Zustand wechselt, hat nicht einen normalen Bereich. Es hat zwei, und der Bereich dazwischen ist einer, den der gesunde Betrieb nur selten besucht. Hier versagen einfachere probabilistische Ansätze stillschweigend. Ein Konfidenzintervall oder ein symmetrisches Band um eine zentrale Vorhersage wird sich so ausdehnen, dass beide Modi abgedeckt werden, wodurch die höchste Wahrscheinlichkeitsmasse in der Lücke zwischen ihnen liegt — genau dort, wo reale Daten fast nie liegen. Eine Beobachtung in dieser Lücke wirkt unauffällig, weil sie numerisch nahe am Zentrum des Bands liegt. Aber sie ist gerade deshalb anomal, weil sie in einen Bereich fällt, den keiner der beiden Betriebsmodi erzeugt. Das dem BuildingPro Suites zugrunde liegende Modell lernt die tatsächliche Form des erwarteten Verhaltens für jeden Messpunkt in jedem Kontext. Es nimmt nicht an, dass sich normales Verhalten um einen einzigen Mittelpunkt gruppiert. Es entdeckt die wahre Struktur der Gebäudeoperation und weist entsprechende Wahrscheinlichkeiten zu. Ein Wert in der Lücke zwischen zwei Modi wird korrekt als niedrig wahrscheinlich — und damit wirklich anomal — erkannt, selbst wenn er absolut gesehen nicht extrem ist. Die Anomaliebedeutung spiegelt daher wider, wie unwahrscheinlich eine Beobachtung angesichts der vollständigen erwarteten Verteilung in diesem Moment ist. Das ermöglicht es, dass eine kleine nächtliche Abweichung korrekt als signifikanter gilt als eine größere Abweichung am Tag. Die nächtliche Verteilung ist eng und konzentriert, sodass schon ein moderater Abstand davon wirklich ungewöhnlich ist.

Ein deutlicher Ausschlag am 30. April 2026 hebt sich klar vom erwarteten Bereich ab. Das System erkennt die Anomalie, markiert ihren Zeitbereich und kennzeichnet den Moment, in dem der tatsächliche Wert das erwartete Band verlassen hat. Das ist der einfache Fall — eine kurze, starke Abweichung. Die betrieblich wichtigere Herausforderung ist das Erkennen der moderaten, aber anhaltenden Abweichungen. Der finanzielle Einfluss unterscheidet die beiden.

Jeder vertikale Schnitt zeigt die vollständige Wahrscheinlichkeitsverteilung des erwarteten Verbrauchs zu diesem Zeitpunkt — grün dort, wo das Modell hohe Wahrscheinlichkeit zuweist, rot dort, wo es niedrige Wahrscheinlichkeit zuweist. Die tatsächliche Verbrauchslinie (schwarz) folgt im Normalbetrieb den grünen, wahrscheinlichen Bereichen. Am 29. März hält der Verbrauch einen mittleren Wert, der vollständig im roten Bereich liegt — einem Bereich, den das Modell angesichts des normalen Zweimodus-Verhaltens des Gebäudes als höchst unwahrscheinlich einstuft. Die Anomalie ist nicht 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 — Persistenz-Tracking für anhaltende Abweichungen ✓ Zu erkennen, dass zu einem bestimmten Zeitpunkt etwas ungewöhnlich ist, reicht nicht aus. Anhaltende Anomalien — die teuersten — treten nur selten als dramatische Einzelereignisse auf. Sie erscheinen als moderate, aber konsistente Abweichungen, die sich über Stunden, Nächte oder Wochen aufsummieren. BuildingPro Suites begegnet dem mit einer Mehrzeitrahmen-Erkennung. Die Anomalieerkennung läuft gleichzeitig über mehrere zeitliche Granularitäten. Eine Abweichung, die auf kürzerer Zeitebene konsistent auftritt — zum Beispiel erhöhter Nachtverbrauch in jedem 15-Minuten-Intervall über drei Nächte — zeigt sich auch als erhöhter Gesamtwert auf Tagesebene. Beide Ebenen werden unabhängig überwacht. Die Erkennungen auf kurzer Zeitebene machen das Muster früh und präzise sichtbar. Die Erkennung auf längerer Zeitebene erfasst das kumulative Bild und bestätigt die Bedeutung dessen, was auf der unteren Ebene gesehen wird. Dieser mehrschichtige Ansatz bedeutet, dass eine anhaltende Anomalie nicht davon abhängt, dass ein einzelnes Erkennungsereignis allein stark genug ist, um eine Schwelle 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 unabhängiger Alarme behandelt. Sie wird als ein zusammenhängendes Ereignis mit kumulativen finanziellen Auswirkungen verfolgt, die so lange wachsen, wie die Abweichung anhält. Ein kurzer Ausschlag und eine einwöchige nächtliche Abweichung können in einer Ansicht mit einem Intervall ähnlich aussehen. In Bezug auf die Gesamtauswirkung sind es völlig unterschiedliche Ereignisse. Das System bildet diesen Unterschied ab. Diese Sicht über mehrere Zeitrahmen hinweg wird in [-> Anomaliezentrum](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-center.md) sichtbar gemacht und in [-> Dashboard für Anomalieerkennungsstatistiken](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-detection-statistics-dashboard.md). *** ### R4 — Kontrollierte Anpassung ohne Fehlerabsorption ✓ Eine Baseline zu halten, 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 wechselnden Jahreszeiten und sich verändernden Betriebsabläufen Fehlalarme. Eine Baseline, die sich zu frei anpasst, absorbiert aktive Fehler und wird genau dann still, wenn sie eigentlich etwas melden sollte. Der Ansatz in BuildingPro Suites löst dieses Spannungsfeld durch denselben Zero-Shot-Inferenzmechanismus, der auch die kontextbewusste Baseline antreibt. Statt periodisch auf akkumulierten Daten nachzutrainieren — was das Risiko birgt, Fehler zu absorbieren — passt sich das Modell kontinuierlich an jeder neuen Beobachtung an. Jeder neue Datenpunkt beeinflusst sein Verständnis des aktuellen Zustands des Gebäudes. Das bedeutet, die Baseline folgt legitimen saisonalen Übergängen und betrieblichen Änderungen natürlich, ohne einen geplanten Nachtrainingszyklus zu benötigen. Die entscheidende Schutzmaßnahme ist folgende: Wenn eine Beobachtung als anomal markiert wird, gilt sie nicht als gesunder Datenpunkt. Sie trägt nicht zum sich entwickelnden Verständnis des Modells von normalem Verhalten für diesen Asset bei. Die Anomalie wird vermerkt, verfolgt und sichtbar gehalten — die Baseline wird jedoch so aktualisiert, als wäre stattdessen der gesunde erwartete Wert eingetreten. Das Ergebnis ist ein System, das in beide Richtungen korrekt reagiert. Ein gradueller saisonaler Wandel — steigender Heizbedarf von Woche zu Woche mit dem nahenden Winter — wird glatt verfolgt, ohne Fehlalarme zu erzeugen. Ein anhaltender Fehler, der seit zwei Wochen läuft, zeigt weiterhin die vollen zwei Wochen kumulierter Auswirkungen, weil jede anomale Messung von der Baseline zurückgehalten und nicht in sie aufgenommen wurde. Die Mehrzeitrahmen-Erkennung verstärkt dies zusätzlich. Eine Anomalie, die auf der kürzeren Zeitebene konsequent markiert wird, ist auch als erhöhter Gesamtwert auf Tagesebene sichtbar, wodurch anhaltende Fehler schwerer zu übersehen sind, unabhängig davon, wie lange sie bestehen.

Mit angewandter 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 Fehler erhöht, einschließlich des kleineren zweiten Ereignisses. Der Fehler ist von Anfang bis Ende sichtbar, und seine gesamte kumulierte Wirkung kann genau gemessen werden.

*** ## Wie wir die Datenqualität vor der Erkennung behandeln ### R5 — Trennung von Datenartefakten und physischen Anomalien ✓ Bevor irgendeine Anomalieerkennung stattfindet, führt die Pipeline regelbasierte Prüfungen auf eingehenden Telemetriedaten durch, um Muster zu erkennen, die mit bekannten Verbindungsproblemen übereinstimmen — Kommunikationslücken, verzögerte Wiederübertragungs-Bursts und Aggregationsartefakte durch gepufferte Datenlieferung. Wenn eine Anomalie gefunden wird, bewertet eine zusätzliche regelbasierte Prüfung, ob das Muster bekannten Verbindungssignaturen entspricht. Wenn ja, wird es entsprechend behandelt und nicht als physische Anomalie angezeigt. Dadurch werden Probleme mit der Datenqualität daran gehindert, zu falschen Anomaliesignalen zu werden, bevor Betreiber sie überhaupt sehen. Dieser Schritt läuft in der Produktion still und automatisch. Der Betreiber muss ihn weder konfigurieren noch prüfen. Er stellt lediglich sicher, dass das, was in den Anomalieansichten angezeigt wird, reales Gebäudeverhalten widerspiegelt und nicht Netzwerkverhalten. Die gefilterten Ergebnisse erscheinen dann in [-> Anomaliezentrum](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-center.md), statt Telemetrieartefakte 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 keine gelabelten Anomaliedaten, um zu starten. Wenn ein neues Gebäude oder ein neuer Standort verbunden wird, beginnt die Erkennung sofort — mit dem vortrainierten Wissen des Modells und der verfügbaren lokalen Historie, ganz ohne manuelle Konfiguration von Anomaliebeispielen. Mit der Zeit verbessert das Feedback der Betreiber das Verhalten des Systems. Nach der Prüfung einer Anomalie kann der Betreiber sie bestätigen als: * **Bestätigt** — die Anomalie war real und betrieblich relevant * **Falsch** — die Anomalie war kein echtes Problemv

Nach der Prüfung einer Anomalie markiert der Betreiber sie als Bestätigt oder Falsch und kann einen Kommentar mit der tatsächlichen Ursache hinzufügen. Eine einzelne Validierung wirkt sofort. Falschpositive lehren das System, dass dieses Muster für diesen Asset erwartetes Verhalten ist. Bestätigte Anomalien schützen die Baseline davor, den Fehler zu absorbieren. 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 außerdem 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 Anlagentest. Eine einzelne Validierung wirkt sofort — sie erfordert kein wiederholtes Feedback zum selben Muster, um zukünftige Behandlungen zu beeinflussen. Die Wirkung funktioniert in beide Richtungen: * Eine Validierung als Falschpositiv lehrt das System, dass dieses Muster für diesen Asset normal ist. Zukünftige Vorkommen desselben Musters werden als erwartetes Verhalten statt als Anomalien behandelt. * Eine bestätigte Anomalie wirkt umgekehrt: Sie signalisiert, dass dieses Muster nicht als gesund in die Baseline aufgenommen werden sollte. Das System behält seine Sensitivität für diese Art von Abweichung auch künftig bei. Die Wirkung verstärkt sich mit der Zeit. Ein System, das mehrere Monate an einem gut betriebenen Standort 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 [-> Anomaliezentrum](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-center.md) und in [-> Anomalien-Tab](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomalies-tab.md), wo Betreiber Anomalien prüfen, validieren und kommentieren. *** ### R7 — Funktioniert mit begrenzten historischen Daten oder kleinen Datensätzen ✓ Ein neu angebundenes Gebäude, ein kürzlich hinzugefügter Messpunkt oder ein Standort, der kürzlich erhebliche betriebliche Änderungen erfahren hat, stehen alle vor derselben Herausforderung: Die lokale Historie ist zu kurz oder nicht mehr repräsentativ genug, um allein eine zuverlässige Baseline zu stützen. Dies wird direkt durch das Zero-Shot-Grundlagenmodell im Kern der Pipeline adressiert. Da das Modell mit Daten aus 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 große Bandbreite an Typen, Klimazonen und Betriebsregimen verhalten, und nutzt den lokalen Kontext, um dieses Wissen auf das jeweilige 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. Einige Wochen lokaler Kontext reichen aus, um ihm zu zeigen, wie sich dieses konkrete Gebäude verhält, und das vortrainierte Wissen erledigt den Rest. Dasselbe gilt nach erheblichen betrieblichen Änderungen. Weil das Modell sich kontinuierlich aus dem aktuellen Kontext anpasst statt sich auf ein festes historisches Fenster zu verlassen, reagiert es innerhalb von Tagen — nicht Monaten — auf veränderte Betriebsabläufe. *** ### 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. Wenn diese Historie bereits dauerhafte Ineffizienzen enthält — eine Pumpe, die seit Monaten durchgehend läuft, ein Heizplan, der nach einer Renovierung nie korrigiert wurde —, können diese Muster in der gelernten Baseline vorhanden sein. Das System wird sie anfänglich nicht markieren, weil ihm eine unabhängige Referenz dafür fehlt, wie das Gebäude vor dem Entstehen dieser Muster hätte aussehen sollen. Dies ist eine strukturelle Einschränkung jedes Ansatzes, der aus realen Betriebsdaten ohne vorab gelabelte Beispiele für gesundes Verhalten lernt. Das wird hier offen eingeräumt. Was heute hilft: * Nutzerfeedback verfeinert schrittweise das Verständnis des Systems dafür, was normal ist, und bestätigte Anomalien werden davor geschützt, absorbiert zu werden. * Die Filterung nach finanziellen Auswirkungen hält den Fokus auf Verhalten, das betrieblich relevant ist, und reduziert den Einfluss von eingebetteten Ineffizienzen mit geringer Wirkung. **Richtung auf der Roadmap:** Der geplante Ansatz ergänzt die statistische Energieanomalie-Ebene um regelbasierte und betriebslogische Funktionen, die automatisch aus der Anlagenontologie der Plattform erzeugt werden. Dadurch ließen sich Widersprüche wie gleichzeitiges Heizen und Kühlen erkennen, die historische Baseline-Bereinigung unterstützen und die Lücke bei dauerhaften, aber bereits normalisierten Ineffizienzen verringern. Das 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. Weil sich die erwartete Baseline mit dem Kontext bewegt, spiegelt die Auswirkungsschätzung wider, was dieser spezifische Messpunkt unter diesen spezifischen Bedingungen hätte verbrauchen sollen — nicht einen flachen Durchschnitt über alle Betriebszustände. Dadurch ist die Schätzung regimekonsistent: Eine nächtliche Abweichung wird mit dem verglichen, was nachts erwartet wurde, nicht mit dem gesamten Tagesdurchschnitt des Gebäudes. Die Schätzung ist außerdem bewusst konservativ. Ziel ist es, eine vertretbare und auf gemessenen Abweichungen basierende Auswirkung zu berichten, statt die scheinbare Höhe der 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 nicht mehr ernst nehmen. Die Schätzung ist vorzeichenbehaftet: * Ein positiver Wert bedeutet Mehrverbrauch — das Gebäude hat mehr verbraucht als erwartet. * Ein negativer Wert bedeutet einen geringeren 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: * **Alarm-Schwelle für finanzielle Auswirkung** — nur Anomalien über einer definierten Auswirkung lösen einen aktiven Alarm aus. * **Messpunkt-Schwelle für finanzielle Auswirkung** — Messpunkte, deren maximal mögliche tägliche Auswirkung unter einem definierten Mindestwert liegt, werden von der Analyse ausgeschlossen. Sie können diese Priorisierung in [-> Dashboard für Anomalieerkennungsstatistiken](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-detection-statistics-dashboard.md) und [-> Anomaliezentrum](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-center.md)sehen und sie in [-> Configure Energy Anomaly Detection](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/configure-energy-anomaly-detection.md).

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

*** ## Wie wir die wahrscheinliche Ursache zuordnen ### R10 — Hierarchische Root-Cause-Zuordnung ✓ Wenn auf hoher Ebene eine Anomalie erkannt wird — etwa 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 Gesamtabweichung in ihre beitragenden Teile zu zerlegen, bis hinunter zur niedrigsten in der Hierarchie verfügbaren Ebene. Jedes beitragende Asset wird nach seinem Anteil an der Gesamtabweichung eingestuft. Der Betreiber sieht nicht nur, dass ein Gebäude eine Anomalie hat, sondern auch, welche Etage, welches Teilsystem oder welches Asset auf niedrigerer Ebene am meisten dazu beigetragen hat und in welchem Zeitfenster. Dadurch wird die Untersuchung von einem ganzen Gebäude auf einen konkreten Problembereich eingegrenzt, noch bevor der Betreiber die Oberfläche verlassen muss. Dieses Drill-down wird in [-> Anomaliezentrum](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-center.md), [-> die Anomalie-Detailseite](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-detail-page.md), und [-> Anomalieerkennungs-Analysetyp](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-detection-analytic-type.md).

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

*** ## Wie wir erklären und Aktionen empfehlen ### R11 — KI-gestützte Erklärung und empfohlene Maßnahmen ✓ Sobald die Anomalie erkannt, verfolgt und über die Hierarchie zugeordnet wurde, werden die strukturierten Belege an einen KI-Analyseagenten übergeben, der von einem großen Sprachmodell unterstützt wird. Dieser Agent hat Zugriff auf Ort und Zeitpunkt der Anomalie, die finanzielle Auswirkung, das Abweichungsmuster, die kontextuellen Bedingungen zum Zeitpunkt sowie die durch die Kaskade identifizierten beitragenden Unter-Assets. Aus diesen Belegen erzeugt der Agent zwei Ausgaben, die in der Detailansicht der Anomalie angezeigt werden: * **Eine menschenlesbare Erklärung** dessen, was die Anomalie wahrscheinlich verursacht hat — abgeleitet aus den spezifischen Belegen für dieses konkrete Ereignis, nicht aus einer generischen Vorlage. * **Eine Liste empfohlener nächster Schritte** — konkrete Maßnahmen, die der Betreiber ergreifen kann, um das Problem zu untersuchen oder zu beheben. Wichtige Abgrenzung: Der KI-Agent arbeitet strikt 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 vorliegt, und verändert das Anomalieergebnis selbst nicht. Seine Aufgabe ist Interpretation und Kommunikation, nicht Erkennung. Dies erscheint im Untersuchungsablauf über [-> die Anomalie-Detailseite](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-detail-page.md) und [-> Anomalieerkennungs-Analysetyp](/collection/german/pakete/energy-and-sustainability-intelligence/energy-anomaly-detection/anomaly-detection-analytic-type.md).

Die Detailansicht der Anomalie 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 menschenlesbare Ursache: in diesem Fall deutlich geringer 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. Die empfohlenen Maßnahmen geben dem Betreiber konkrete nächste Schritte — geplante Wartung prüfen, Automatisierungsprotokolle durchsehen, nach unerwarteten Abschaltungen suchen. Der KI-Agent verändert das Anomalieergebnis nicht. Er gibt dem Betreiber einen Ausgangspunkt.

*** ## Was dieser Ansatz heute tut und nicht tut ### Was er heute tut * Erkennt Abweichungen, die im aktuellen Betriebskontext innerhalb des konfigurierten Energiebereichs unwahrscheinlich sind * Modelliert die vollständige Wahrscheinlichkeitsverteilung des erwarteten Verhaltens, nicht nur ein Band oder Konfidenzintervall, wodurch Anomalien zwischen Betriebsmodi erkannt werden können * Verfolgt Anomalien gleichzeitig über mehrere Zeitrahmen hinweg — Muster über kurze Intervalle verdichten sich zur Bestätigung auf Tagesebene * Bewertet die Bedeutung von Anomalien im Kontext und nicht nur nach der absoluten Größe der Abweichung * Passt sich kontinuierlich an legitime Veränderungen an, ohne aktive Fehler in die Baseline aufzunehmen * Funktioniert vom ersten Tag an ohne lokale Historie, durch ein Foundation Model, das auf Tausenden von Gebäuden vortrainiert ist * Trennt Verbindungsartefakte vor der Erkennung von physischen Anomalien * Schätzt für jede erkannte Anomalie eine vorzeichenbehaftete, regimekonsistente und konservative finanzielle Auswirkung * Läuft automatisch durch die physische Asset-Hierarchie, um beitragende Unter-Assets zu identifizieren * Erzeugt menschenlesbare Erklärungen und empfohlene Maßnahmen über einen von einem großen Sprachmodell unterstützten KI-Analyseagenten * Startet ohne gelabelte Anomaliedaten und verbessert sich schrittweise durch Feedback der Betreiber ### Was es heute nicht vollständig löst **Bereits eingebettete historische Ineffizienzen** Bereits in der Trainingshistorie vorhandene dauerhafte Ineffizienzen können zunächst als normal gelernt werden. Nutzerfeedback und finanzielle Filterung helfen, und die auf der Roadmap vorgesehene regelbasierte Baseline-Bereinigung adressiert diese Lücke direkt. **Widersprüche der Betriebslogik als separate Detektionsschicht** Statistische Anomalieerkennung ist nicht das ideale Werkzeug für Probleme wie gleichzeitiges Heizen und Kühlen oder ein scheinbar festhängendes Ventil, wenn diese Muster bereits Teil des langfristigen Gebäudeverhaltens sind. Für diese Problemklasse ist eine Regel das richtige Werkzeug. **Direkte Anomalieerkennung auf Geräteebene überall als erstklassige Funktion** Der aktuelle Ansatz ist energiezentriert 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äude-Konfiguration verfügbar. ### Roadmap-Richtung Die geplante Richtung ist, die statistische Ebene der Energieanomalien durch regelbasierte und betriebslogische Fähigkeiten zu ergänzen, die automatisch aus der Anlagenontologie der Plattform erzeugt werden. Dadurch ließen sich Widersprüche wie gleichzeitiges Heizen und Kühlen erkennen, die historische Baseline-Bereinigung unterstützen und die Lücke bei dauerhaften, aber bereits normalisierten Ineffizienzen verringern. *** ## Anforderungen: Wo jede einzelne steht
#AnforderungStatus
R1Kontextbewusste Grundlinie✓ Wetter, Kalender, Belegung, Produktionseinheiten
R2Vollständige Wahrscheinlichkeitsverteilung des erwarteten Verhaltens✓ Mehrmodus-Verteilung, Lückenerkennung, kontextskalierte Signifikanz
R3Persistenz-Tracking über Zeitrahmen hinweg✓ Mehrzeitrahmen-Erkennung mit kumulativer Wirkungsverfolgung
R4Kontrollierte Anpassung ohne Fehlerabsorption✓ Kontinuierliche Zero-Shot-Anpassung, anomale Messwerte werden von der Baseline zurückgehalten
R5Trennung von Verbindungsartefakten und physischen Anomalien✓ Regelbasierter Pipeline-Schritt, still und automatisch
R6Keine Labels erforderlich, verbessert sich mit Feedback✓ Zero-Shot-Start, Feedbackschleife mit Einzelvalidierung
R7Funktioniert mit begrenzter oder saisonal unvollständiger lokaler Historie✓ Foundation Model, vortrainiert auf Tausenden von Gebäuden
R8Robust gegenüber unvollständigen historischen Grundlinien◑ Feedbackschleife hilft; regelbasierte Baseline-Bereinigung auf der Roadmap
R9Schätzung des finanziellen Einflusses zur Priorisierung✓ Konservative, regimekonsistente, 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, unterstützt von einem großen Sprachmodell
*** ## Fazit Die Anomalieerkennung in Gebäuden ist schwierig, weil die schwierigen Teile real sind: Der Kontext ändert sich, Baselines verschieben sich, Labels sind knapp, 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 so anzugehen, dass sie im realen Betrieb nützlich sind. Der aktuelle Ansatz von BuildingPro Suites deckt bereits die wichtigsten Anforderungen ab: kontextbewusste Erkennung, vollständiges probabilistisches erwartetes Verhalten über Betriebsmodi hinweg, Mehrzeitrahmen-Persistenz-Tracking, Trennung der Datenqualität, konservative finanzielle Priorisierung, hierarchiebasierte Zuordnung und KI-gestützte Erklärung. Die verbleibenden Lücken — insbesondere bei unvollständigen historischen Baselines und Widersprüchen der Betriebslogik — sind real und benannt. Genau deshalb stehen sie auf der Roadmap. Und das alles erfolgt im Portfoliomaßstab, über alle verbundenen Gebäude hinweg, ohne dass eine manuelle Konfiguration pro Standort oder pro Messpunkt 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-ai-and-machine-learning-in-buildingpro-suites/machine-learning/introduction-to-anomaly-detection-in-smart-buildings/how-buildingpro-suites-addresses-the-challenges-of-anomaly-detection.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.