Katalog / Erkennung von Anomalien, Betrug und Integritätsverstößen / ANOM-005

Anomalieerkennung in Industrieprozessen anhand von Sensordaten

Das normale Verhalten von Maschinen und Prozessanlagen wird aus Historian-/SPS-Sensordaten gelernt. Bewegen sich mehrdimensionale Signale vom Normalzustand weg, werden Bediener und Instandhaltung frühzeitig alarmiert.

Anlagen und Maschinen liefern tausende Sensorsignale. Feste Alarmgrenzen auf einzelnen Tags lösen aber entweder ständig aus oder übersehen langsame, mehrdimensionale Drifts. Modelle zur Anomalieerkennung lernen, wie „normal“ für jede Anlage und jeden Betriebszustand aussieht, melden Abweichungen früh und zeigen, welche Signale sich verändert haben. Die Arbeit leisten überwiegend klassische statistische und neuronale Zeitreihenverfahren; LLMs und Zeitreihen-Foundation-Modelle sind eine aufkommende Schicht für Erklärungen und Zero-Shot-Basislinien, kein Ersatz.

Problem & Nutzen

  • Heute: Bediener verlassen sich auf feste Ober- und Untergrenzen, SPC-Karten und Erfahrung. Alarmfluten verdecken echte Probleme; schleichende Verschlechterung (Verschmutzung, Lagerverschleiß, Sensordrift, undichte Ventile) fällt spät auf. Ausfall-Labels sind selten, weil Ausfälle selten sind.
  • KI-Nutzen: Unüberwachte oder teilüberwachte Modelle lernen das normale mehrdimensionale Verhalten je Anlage und Betriebsart, melden frühe Abweichungen, ordnen die beitragenden Signale nach Gewicht und senken Fehlalarme gegenüber Einzel-Tag-Grenzen. Frühere Erkennung ermöglicht geplante statt ungeplanter Stillstände und erfasst Qualitätsdrift, bevor Ausschuss entsteht.
  • Belegte Evidenz: Siemens verweist auf Vorwerk, das mit der Plattform Insights Hub über 500 vernetzte Maschinen eine OEE-Verbesserung von rund 3 bis 5 % meldet (vom Hersteller berichtet, nicht unabhängig geprüft) [5]. Eine realistische Einordnung: Im großen Benchmark TSB-AD (1.070 gelabelte Zeitreihen, 40 Quellen) erreichen einfache statistische Verfahren oft die Güte komplexer Deep-Learning-Modelle oder übertreffen sie, die Erwartungen müssen also sorgfältig gesetzt werden [1].
  • Abgrenzung: Die Prognose der Restlebensdauer und der Ausfallwahrscheinlichkeit ist PRED-006; Soft Sensors für die Qualität sind PRED-014; Angriffe auf OT-Netze sind SEC-015; Lecks in Rohrnetzen ANOM-013; Netz-/Energiediebstahl ANOM-008; Gebäudetechnik ANOM-031. Dieser Anwendungsfall ist die Erkennung abnormalen Verhaltens in Prozess- und Maschinensignalen.

Varianten

  • Diskrete Fertigung: CNC, Pressen, Roboter, Spritzguss, Motorstrom-/Schwingungssignaturen.
  • Prozessindustrie: Chemie, Lebensmittel & Getränke, Pharma, Wasseraufbereitung: mehrdimensionale Drifts bei Temperatur, Druck, Durchfluss, pH; Modelle, die Chargenphasen berücksichtigen.
  • Rotierende Anlagen: Pumpen, Kompressoren, Lüfter, Getriebe (Zustandsüberwachung mit Schwingung/Akustik, siehe audio-classification).
  • Energieanlagen und Wind/Solar: Überwachung von Wechselrichtern, Turbinen und Transformatoren.
  • Edge-Variante: Das Modell läuft auf einem Gateway oder einem SPS-nahen Gerät, für Latenz im Millisekundenbereich oder abgeschottete Standorte.
  • Privat-/Maker-Nutzung: Kleine Anwendungen (3D-Drucker, Home-Lab, Wärmepumpendaten) sind mit Open-Source-Werkzeugen möglich, aber kein Marktschwerpunkt.

So funktioniert es

  1. sensors/PLC
  2. collection (OPC UA, MQTT/Sparkplug)
  3. historian / time-series DB
  4. cleaning + context (operating state, recipe, tag
  5. asset mapping)
  6. feature windows (statistics, spectra) or raw multivariate windows
  7. detector (statistical | autoencoder/transformer | foundation model)
  8. score + thresholding per asset
  9. alert deduplication / grouping
  10. explanation (top contributing tags; LLM summary with maintenance history)
  11. CMMS/MES ticket
  12. human verdict (true/false alarm)
  13. feedback to threshold/retraining
  • Detektoren: residuenbasiert (Signal vorhersagen, große Abweichung melden), rekonstruktionsbasiert (Autoencoder, Transformer), Dichte-/Isolationsverfahren (Isolation Forest, kNN, PCA) und Subsequenzverfahren (Matrix Profile). Die Konditionierung auf den Betriebszustand ist die wichtigste Designentscheidung: Eine Pumpe bei 40 % Last ist keine anomale Pumpe bei 100 % Last.
  • Foundation-Modelle: Vortrainierte Zeitreihenmodelle (MOMENT, Chronos-2, TimesFM) liefern Zero-Shot- Basislinien für Prognose oder rekonstruktionsbasierte Erkennung; MOMENT unterstützt die Anomalieerkennung direkt und schneidet in der eigenen Evaluation mit und ohne Feintuning gut ab [4]. Die Ergebnisse schwanken je nach Datensatz, und sie sind in der Produktion noch nicht der Standard.
  • LLM-Schicht: macht aus Alarm, wichtigsten Signalen und früheren Arbeitsaufträgen eine lesbare Diagnosehypothese mit Checkliste. Das LLM entscheidet nie; es fasst zusammen.
  • Mensch-in-der-Schleife (Human-in-the-Loop): Bediener und Instandhalter bestätigen oder verwerfen Alarme; automatische Eingriffe in die Anlage (Sollwertänderung, Abschaltung) müssen über die bestehende Sicherheits-/Steuerungsebene laufen, nie über dieses Modell.

Datenaufbereitung

Sensordaten liegen in SPS-/SCADA-Systemen, Prozess-Historians (z. B. PI), Edge-Gateways und oft in CSV-Exporten auf Dateiablagen; Kontext wie Rezepte, Schichten und Arbeitsaufträge steckt in MES, ERP oder im CMMS, Instandhaltungsnotizen teils auf Papier. Typische Lücken sind uneinheitliche oder undokumentierte Tag-Namen, fehlende Anlagenhierarchien, driftende Sensorkalibrierung, Lücken und falsche Zeitstempel zwischen Systemen, keine Aufzeichnung der Betriebszustände und kaum gelabelte Ausfälle. Zugriffsrechte auf das OT-Netz sind meist aus gutem Grund eingeschränkt.

Schritte der Aufbereitung: - Ein Tag-Inventar mit Anlagenhierarchie und Einheiten aufbauen; Datenverantwortliche festlegen (siehe PREP-004). - Daten über Standardschnittstellen wie OPC UA oder MQTT ziehen statt über ad-hoc-Exporte (PREP-005). - Zeitstempel abgleichen, neu abtasten, Ausfall- und Wartungszeiten markieren und Betriebszustands-Kontext (Rezept, Produkt, Sollwerte) ergänzen. - Labels aus Arbeitsaufträgen und Stillstandsprotokollen gewinnen (PREP-020) und mit dem Instandhaltungsteam einen Evaluationsdatensatz aufbauen (PREP-018). - Papier-Logbücher digitalisieren, wenn sie Ausfallhistorie enthalten (PREP-008).

Werkzeuge: Historian-Exporte, Node-RED oder n8n für die Anbindung, pandas/Polars für die Bereinigung. Rechnen Sie damit, dass etwa die Hälfte des Projektaufwands in die Datenaufbereitung geht; GUIDE-003 bietet einen Reifegrad-Check, DATA-016 verwandte Zeitreihen-Pipelines.

Umsetzungswege

Welcher Weg für wen

  • KMU: Weg A, weil ausgereifte Produkte für Zustandsüberwachung und Prozessanalytik mit EU-Hosting existieren und die Aufgabe (Normalzustand lernen, bei Drift alarmieren) Standard ist.
  • Großunternehmen: Weg C, weil Anlagendaten zentrales Know-how und sensibel sind und eine gemeinsame interne Industriedaten-Plattform Modelle über viele Anlagen hinweg amortisiert.
  • Entwickler: Weg C, weil offene Zeitreihen- und Anomalie-Bibliotheken auf Edge- oder HW1-Hardware laufen und volle Kontrolle über Modelle und OT-Integration bieten.

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

  • Industrielle Analyseplattformen: Siemens Insights Hub (DE; Asset Health & Maintenance, Quality Prediction, Production Copilot) [5], Seeq (US; Prozessdatenanalytik, Assistent Agent Q) [6], TrendMiner (BE/EU; Self-Service-Zeitreihenanalytik und Monitoring) [7], Cognite Data Fusion (Norwegen; Industriedaten-Plattform mit Anlagenkontext), AVEVA PI / CONNECT, Aspen Mtell, Honeywell Forge. Spezialisierte EU-Sensor-/ML-Anbieter gibt es für Schwingungs- und Zustandsüberwachung (z. B. KONUX, DE, für Bahnweichen).
  • Cloud-nativ: AWS IoT SiteWise bietet native mehrdimensionale Anomalieerkennung (eingeführt im Juli 2025) als von AWS empfohlenen Ersatz für Amazon Lookout for Equipment, das am 7. Okt. 2026 eingestellt wird [2]. Azure AI Anomaly Detector wurde am 1. Okt. 2026 abgeschaltet; Microsoft verweist auf die Anomalieerkennung in Fabric Real-Time Intelligence (Vorschau) und die Open-Source-Bibliothek [3][8].
  • A wählen, wenn: die Anlagenklasse Standard ist (Pumpen, Motoren, Kompressoren), Data-Science-Personal fehlt und ein Anbieter in einem bezahlten Pilotprojekt Ergebnisse auf Ihren Daten zeigen kann. Prüfen Sie EU-Datenhaltung und OPC-UA-Anbindung.

Weg B — Auf Cloud-KI-Diensten aufbauen

  • Streaming und Speicherung: Azure Event Hubs / Fabric Eventhouse, AWS IoT SiteWise/Timestream, Google Cloud Pub/Sub + BigQuery, in EU-Regionen. Die Anomalieerkennung in Fabric RTI lässt Modelle auf Eventhouse-Tabellen laufen (bis zu 30 Minuten je Analyse, Vorschau) [8].
  • Modelle: AutoML-/ML-Plattformen (SageMaker, Azure ML, Vertex AI) mit eigenen Detektoren; Foundation-Modelle (Chronos-2 auf SageMaker/AutoGluon) für Erkennung über Prognose-Residuen.
  • LLM-Erklärung: Ein Frontier-Modell über einen Endpunkt in der EU-Region fasst Alarme zusammen; senden Sie nur Tag-Namen und aggregierte Statistiken, keine rohen Produktionsgeheimnisse.
  • B wählen, wenn: Sie bereits eine Cloud-Datenplattform haben und eigene Logik über viele Standorte brauchen.

Weg C — Selbst betreiben (Open Source)

  • Bibliotheken: PyOD (BSD-2, 60+ Detektoren, auch für Zeitreihen, PyOD 3 mit benchmarkgestütztem ADEngine-Routing) [9], TSB-AD-Referenzimplementierungen [1], MOMENT (MIT) [4], Chronos-2 (Apache-2.0) [10], Darts, aeon, ADTK, River für Online-Lernen. Salesforce Merlion wurde im März 2026 archiviert und sollte keine neue Abhängigkeit sein. Die Gewichte von TimesFM 3.0 haben eine nicht-kommerzielle Lizenz (vor dem Produktiveinsatz prüfen) [11].
  • Stack: OPC-UA-/MQTT-Broker (Eclipse Mosquitto, EMQX), InfluxDB / TimescaleDB / QuestDB, Grafana Alerting, Node-RED oder n8n für das Ticket-Routing, ONNX Runtime für den Edge-Einsatz.
  • Hardware: HW1: Ein CPU-Server oder Industrie-Edge-Gateway genügt für klassische Detektoren über hunderte Anlagen; eine GPU (HW2) nur für Transformer-/Foundation-Modell-Inferenz bei hoher Frequenz oder einen lokalen LLM-Erklärer.
  • Betriebsaufwand: braucht anfangs 2–3 Monate lang einen Dateningenieur plus einen Fachexperten; danach laufende Modellüberwachung.

Weg D — Eigenes Training

Lohnt sich für Flotten identischer Anlagen (Maschinenbau-OEMs): Eine Modellfamilie wird auf den gepoolten Daten aller Maschinen trainiert, mit Konditionierung auf den Betriebszustand, und auf der Maschinensteuerung oder dem Gateway ausgeliefert. Braucht Monate an Historie im Normalbetrieb (hoher Datenbedarf) und idealerweise einige gelabelte Ausfallepisoden zur Evaluation. Föderiertes oder standortspezifisches Feintuning hilft, wenn Kunden Rohdaten nicht teilen wollen.

Stand der Technik (2026)

  • Benchmarks: TSB-AD (NeurIPS 2024) empfiehlt die Metrik VUS-PR, stellt fest, dass einfache statistische Verfahren oft fortgeschrittene neuronale Netze übertreffen, dass neuronale Netze für mehrdimensionale Daten vielversprechend sind und Foundation-Modelle für Punktanomalien [1]. Seien Sie skeptisch gegenüber Arbeiten mit punktkorrigiertem F1, das die Werte aufbläht.
  • Foundation-Modelle: Chronos-2 (120M, Zero-Shot-Prognose für univariate, multivariate Daten und mit Kovariaten) [10], TimesFM (3.0 erschienen im Aug. 2026, multivariat mit Kovariaten; nicht-kommerzielle Gewichte) [11], MOMENT für rekonstruktionsbasierte Erkennung [4]. Nutzen Sie sie als starke Basislinien.
  • Plattformkonsolidierung: Cloud-Anbieter haben eigenständige Dienste eingestellt (Lookout for Equipment, Azure Anomaly Detector) zugunsten von Funktionen innerhalb von IoT- und Datenplattformen [2][3].
  • Agentische Schicht: Anbieter ergänzen Copiloten (Siemens Production Copilot, Seeq Agent Q, TrendMiner Analytics Agent), die Alarme, Historians und Dokumente in natürlicher Sprache abfragen [5][6][7].
  • Grenzen und Fehlerbilder: Konzeptdrift nach Wartung oder Rezeptwechsel; verunreinigte „Normal“-Trainingsdaten; unbekannte Betriebszustände, die Fehlalarme auslösen; Sensorfehler, die für Prozessfehler gehalten werden (und umgekehrt); keine Grundwahrheit, um den Recall zu messen; Alarmmüdigkeit. Eine Anomalie ist keine Diagnose.

Gemeinsame Bausteine & Kombinationen

  • Gleiche Bausteine (anomaly-detection, time-series, streaming): PRED-006 vorausschauende Instandhaltung (Labels aus bestätigten Alarmen werden zu Trainingsdaten für die Ausfallvorhersage), PRED-014 Soft Sensors, PRED-046 Bauwerksüberwachung, ANOM-008 Netzanomalien, ANOM-013 Netzlecks, ANOM-030 KPI-Anomalien, ANOM-031 Fehlererkennung in der Gebäudelüftung/-klimatisierung.
  • Datengrundlage: DATA-016 (Zuordnung Tag zu Anlage, ISA-95-/AAS-Modelle) ist Voraussetzung für die Skalierung über Werke hinweg.
  • Ergänzende Signale: VIS-001 visuelle Prüfung (Qualitätskamera und Prozesssensoren korreliert); SEC-015 Überwachung des OT-Netzes, um Cyber-Manipulation von Prozessfehlern zu unterscheiden.
  • Regulierte Produktion: HLTH-029 Chargenprotokoll-Prüfung nutzt die hier erkannten Prozessabweichungen.
  • Gemeinsame Infrastruktur: ein Historian/eine Zeitreihen-DB, eine MQTT-/OPC-UA-Anbindungsschicht und ein HW1/HW2-Edge- oder Server- Host können alle genannten Fälle bedienen; ein optionales lokales LLM liefert Erklärungen für mehrere Anwendungsfälle.

Aufwand, Kosten & Kennzahlen

  • Weg A: Wochen für einen Pilot an einigen Anlagen; Abonnement je Anlage/Tag oder je Standort; die Anbindung an den Historian ist die Hauptarbeit.
  • Weg B: 2–4 Monate; Kostentreiber sind Datenaufnahme-/Speichervolumen und Entwicklungszeit.
  • Weg C: 2–4 Monate mit eigenen Fachkräften; geringe Lizenzkosten, höherer Entwicklungs- und Wartungsaufwand.
  • Weg D: 6+ Monate; lohnt sich für OEMs mit vielen identischen Maschinen.
  • Kennzahlen: Präzision der Alarme (Anteil, den Bediener bestätigen), Vorlaufzeit vor Ausfall oder Qualitätsabweichung, in der Rückschau gefundene verpasste Ereignisse, Alarme je Bediener und Schicht, ungeplante Stillstandsstunden, Ausschussquote, OEE. Berichten Sie keine „Genauigkeit“ auf ungelabelten Daten.

Menschen & Veränderung

Beziehen Sie die Geschäftsführung zu Beginn für Umfang und Budget ein, die Abteilungsleitung und die Instandhaltung als Prozessverantwortliche bei der Definition des Anwendungsfalls sowie IT und Informationssicherheit vor jeder OT-Anbindung, weil der Datenpfad Produktionsnetze berührt (GUIDE-013). Die Datenverantwortlichen von Historian- und MES-Daten müssen Quellen früh freigeben. Bediener und Instandhalter sind die täglichen Nutzer und sollten ab Woche eins in der Pilotgruppe mitarbeiten.

Betriebsrat: abhängig vom Einzelfall. Reine Maschinendaten lösen §87 Abs. 1 Nr. 6 BetrVG nicht aus, aber Alarme, die an Schichten, Bediener oder Anmeldungen geknüpft sind, können zur Überwachung von Verhalten oder Leistung geeignet werden, was das BAG als ausreichend ansieht. In jedem Fall verlangt §90 Abs. 1 Nr. 3 eine rechtzeitige Unterrichtung, wenn Arbeitsverfahren mit KI geplant werden; fangen Sie früh an (GUIDE-004). Personenbezogene Daten fehlen normalerweise, daher ist eine DSFA selten nötig; lassen Sie sich dennoch von der/dem Datenschutzbeauftragten bestätigen, wenn Bediener-IDs protokolliert werden.

Fördern Sie die KI-Kompetenz von Bedienern und Instandhaltern durch kurze praktische Sitzungen (Art. 4 KI-Verordnung, GUIDE-006). Wählen Sie eine Linie oder ein Werk als Pilotgruppe, zeigen Sie, welche Signale jeden Alarm ausgelöst haben, und stimmen Sie die Schwellen mit der Mannschaft ab, um Alarmmüdigkeit zu begrenzen. Typische Sorgen sind der Arbeitsplatz und das Gefühl, von einem Modell kontrolliert zu werden; begegnen Sie ihnen, indem Sie das Werkzeug als Assistenten positionieren, bei dem Menschen über jeden Eingriff entscheiden (GUIDE-008, GUIDE-009).

Risiken, Regulierung & Compliance

  • KI-Verordnung (AI Act): abhängig vom Einzelfall. Reine Überwachung und Instandhaltungsunterstützung ist in der Regel Minimalrisiko. KI als Sicherheitskomponente bei Verwaltung und Betrieb kritischer digitaler Infrastruktur, des Straßenverkehrs oder der Versorgung mit Wasser, Gas, Wärme oder Strom fällt unter Anhang III Nr. 2 (Hochrisiko) [12]. Die Pflichten nach Anhang III gelten ab dem 2. Dez. 2027 und Anhang I (in Produkte eingebettet) ab dem 2. Aug. 2028 gemäß den Änderungen des AI Omnibus [13]. Anomalieerkennung, die nur alarmiert, ist meist keine Sicherheitskomponente, eine, die Sicherheitsfunktionen auslöst, kann es sein.
  • Maschinenverordnung (EU) 2023/1230: gilt ab dem 20. Jan. 2027 und ergänzt Vorgaben für Maschinen mit KI-gestützten Sicherheitsfunktionen und für die Cybersicherheit von Sicherheitssteuerungen [14]. Maschinenbauer, die solche Modelle einbetten, brauchen eine Konformitätsbewertung.
  • Funktionale Sicherheit und Cyber: Halten Sie das Modell aus dem Sicherheitskreis heraus (IEC 61511 / ISO 13849 bleiben deterministisch); segmentieren Sie OT-Netze (IEC 62443); NIS2 gilt für viele Hersteller und Energiebetreiber.
  • DSGVO: Sensordaten sind überwiegend nicht personenbezogen, aber Maschinendaten mit Bezug zu Bedienern (Anmeldung, Schicht, Leistung) können personenbezogene Daten sein und die Mitbestimmung des Betriebsrats auslösen (§87 BetrVG in Deutschland). Vermeiden Sie Rückschlüsse auf die Leistung einzelner Beschäftigter.
  • Pharma/GxP: Regeln für validierte Systeme (GMP-Anhang 11) gelten, wenn Alarme die Chargenfreigabe beeinflussen.
  • Gegenmaßnahmen: menschliche Bestätigung, Prüfpfad, Driftüberwachung, dokumentierter Betriebsbereich, Datenaustauschverträge für das Fernmonitoring durch OEMs.

Erste Schritte

  1. Wählen Sie 1–3 Anlagen mit teuren Stillständen und guter Sensorabdeckung; dokumentieren Sie Tags, Abtastraten und bekannte frühere Vorfälle.
  2. Prüfen Sie die Datenqualität: Zeitsynchronisation, Lücken, Einheiten, Betriebszustands-Tags; besorgen Sie 3–12 Monate Historie mit mindestens einem bekannten Fehler.
  3. Fahren Sie eine Basislinie mit PyOD-/TSB-AD-Detektoren plus einen Anbieter-Pilot auf denselben Daten; vergleichen Sie mit VUS-PR und Bedienerbewertung statt mit Genauigkeit.
  4. Leiten Sie Alarme ins CMMS mit einer Rückmeldetaste für Bediener (Fehl-/Echtalarm) und stimmen Sie die Schwellen je Betriebszustand ab.
  5. Erst dann skalieren: Tags auf ein Anlagenmodell abbilden (DATA-016), einen LLM-Erklärer ergänzen und die Einstufung nach AI Act/Maschinenverordnung prüfen, falls es eine Sicherheitsverbindung gibt.

Quellen

  1. TSB-AD benchmark (TheDatumOrg, NeurIPS 2024) — https://github.com/TheDatumOrg/TSB-AD
  2. AWS — Preserve access and explore alternatives for Amazon Lookout for Equipment — https://aws.amazon.com/blogs/machine-learning/preserve-access-and-explore-alternatives-for-amazon-lookout-for-equipment/
  3. Microsoft Learn — Anomaly Detector (retired 1 Oct 2026) — https://learn.microsoft.com/en-us/azure/ai-services/anomaly-detector/overview
  4. MOMENT time-series foundation model (CMU Auton Lab) — https://github.com/moment-timeseries-foundation-model/moment
  5. Siemens — Insights Hub — https://www.siemens.com/en-us/products/insights-hub/
  6. Seeq — https://www.seeq.com/
  7. TrendMiner — https://www.trendminer.com/
  8. Microsoft Learn — Anomaly detection in Fabric Real-Time Intelligence — https://learn.microsoft.com/en-us/fabric/real-time-intelligence/anomaly-detection
  9. PyOD — https://github.com/yzhao062/pyod
  10. Chronos forecasting (Amazon Science) — https://github.com/amazon-science/chronos-forecasting
  11. TimesFM (Google Research) — https://github.com/google-research/timesfm
  12. AI Act Annex III — https://artificialintelligenceact.eu/annex/3/
  13. European Commission — AI regulatory framework and AI Omnibus dates — https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
  14. European Commission — Machinery Regulation (EU) 2023/1230 — https://single-market-economy.ec.europa.eu/sectors/mechanical-engineering/machinery_en
  15. Salesforce Merlion (archived March 2026) — https://github.com/salesforce/Merlion