Anomalieerkennung vs. RUL-Prognose in der Praxis: Wann welches PdM-Verfahren wirkt – und wie man es produktionsreif baut

Problem: Warum so viele PdM-Projekte am Ziel vorbeigehen
Die meisten Predictive-Maintenance-Initiativen scheitern nicht an “fehlender KI”, sondern an einer falschen Zielfunktion: Es wird ein Modelltyp gewählt, bevor das Instandhaltungsziel und die Datenlage klar sind. In der Praxis sehen wir immer wieder dieselben Muster:

  • “Wir wollen RUL”: Der Wunsch nach einer Restlebensdauerprognose (Remaining Useful Life, RUL) ist verständlich, aber ohne ausreichende Run-to-Failure-Historien, saubere Zustandsindikatoren und konsistente Rückmeldungen aus der Instandhaltung wird die Prognose entweder ungenau oder rein akademisch.
  • “Wir fangen mit Anomalieerkennung an”: Unüberwachte Anomalieerkennung ist oft ein sinnvoller Start – aber ohne Change-Management und klare Handlungslogik produziert sie Alarmmüdigkeit. Ein Score ohne wirtschaftliche Schwelle, ohne Fehler-Taxonomie und ohne Rückkopplung zum CMMS führt zu Tickets, die niemand ernst nimmt.
  • Offline-Accuracy statt operativer Nutzen: Confusion-Matrizen aus sauber gelabelten Datensätzen geben trügerische Sicherheit. In der Anlage dominieren Nichtstationarität (Lastwechsel, Schichtbetrieb), Sensor-Drift, Prozesswechsel und Wartungsereignisse, die nicht sauber verbucht sind.
  • Fehlende Souveränität in der Architektur: PdM-Daten sind oft betriebskritisch (Produktionsgeheimnisse, Betriebsprofile, Sicherheitsaspekte). Wer auf US-Cloud-Abhängigkeiten baut, zahlt bei Audits und späteren Zertifizierungen drauf – und verliert Gestaltungsmacht über sein Datenmodell.

Kurz: Die Modellwahl ist Folge des Instandhaltungsziels und der Datenökologie, nicht umgekehrt. Dieser Artikel legt eine belastbare Entscheidungslogik und konkrete Architekturen dar – aus der Praxis von Textilfertigung und Bahnflotten.

Lösung: Entscheidungslogik und Architekturpfade

1) Entscheidungslogik: Anomalieerkennung oder RUL?

Anomalieerkennung (AE) ist sinnvoll, wenn:

  • Wenige oder keine gelabelten Ausfälle vorliegen (typisch bei neuen Anlagen, seltenen kritischen Fehlern).

  • Das Ziel Frühwarnung ist: “Irgendetwas weicht signifikant vom Normalzustand ab”, um Inspektionen anzustoßen.

  • Der Prozess nicht konstant ist (Lastprofile, Produktwechsel), aber “Normalität” breit beobachtbar ist.

  • Man schnell starten will, um einen Fehlerkatalog aufzubauen (Failure Knowledge Capture).

  • Alarmierungslogik und Eskalationspfade im CMMS klar definiert sind.

Typische Methoden: robuste Statistik (Z-Score per Feature, Median Absolute Deviation), One-Class-Modelle (OC-SVM, Isolation Forest), Autoencoder (rekonstruktionsbasiert), Dichte-Schätzer, Change-Point-Detection (CUSUM, BOCPD), saisonale Dekomposition (STL) mit Residuenüberwachung.

RUL-Prognose ist sinnvoll, wenn:

  • Mehrere Run-to-Failure-Historien bzw. komplette Degradationsverläufe existieren (nicht nur punktuelle Ausfälle).

  • Zustandsindikatoren mit monotone(r) oder stückweise monotone(r) Degradation vorliegen (z. B. Verschleißmaße).

  • Wartungs- und Ersatzteilhistorie zuverlässig im CMMS dokumentiert ist (Zeitstempel, Maßnahme, Ursache).

  • Der wirtschaftliche Nutzen Tausch- oder Revisionsplanung mit präzisem Vorlauf erfordert (Teilelogistik, Stillstandsplanung).

  • Sicherheits- oder Flottenverfügbarkeit erfordern, Tauschzyklen zu synchronisieren (z. B. Bahnflotte, Fluggeräte).

Typische Methoden: parametrische/semiparametrische Zuverlässigkeitsmodelle (Weibull, Cox), State-Space-Modelle (Kalman/Particle Filter) auf Gesundheitsindex, stückweise lineare Degradationsmodelle, survival-basierte Deep-Learning-Ansätze auf sequenziellen Features (LSTM/TCN) – nur, wenn Datenlage robust.

Kurzform-Entscheider:

  • Keine Labels, aber viele Stunden Normalbetrieb: Start AE.

  • Etwa 20–50 Run-to-Failure-Fälle pro Fehlermodus und stabiler Prozess: RUL prüfbar.

  • Mischbetrieb (einige Fehler häufig, andere selten): Hybrid – RUL für häufige, AE für seltene.

2) Datenfluss und Architektur

Gemeinsame Basiskomponenten:

  • Erfassung: Edge-fähige Datenerfassung via OPC UA/MQTT/Kafka, Samplingraten je Sensor:

  • Vibration (Beschleunigung): 6.4–51.2 kHz je nach Lager/Antrieb; typ. 25.6 kHz in Textil-Spindeln.

  • Stromaufnahme (MCSA): 5–20 kHz; Synchronisation mit Netzfrequenz sinnvoll.

  • Temperatur: 1–10 Hz; für Trend/Gradient ausreichend.

  • Umdrehungssignal/Tachometer: zur Ordnungsanalyse (Order Tracking).

  • Vorverarbeitung am Edge:

  • Anti-Aliasing, digitale Filter (Bandpass um Lagerfrequenzen, z. B. BPFO/BPFI), Drehzahl-Normierung.

  • Windowing: 0.5–2.0 s, 50–75% Overlap für zeitnahe Aktualisierung.

  • Qualitätschecks: Sensor-Drift, Sättigung, Ausreißer; Drop/Impute-Strategie.

  • Feature-Engineering:

  • Zeitbereich: RMS, Peak-to-Peak, Crest Factor, Kurtosis, Skewness, Hjorth-Parameter.

  • Frequenzbereich: Spektrale Peaks um Lagerdefekt-Frequenzen, Seitbänder, spektrale Kurtosis, Band-Energie.

  • Hüllkurvenanalyse (Envelope) für Wälzlager.

  • Ordnungsanalyse (Order-Tracking) bei variabler Drehzahl.

  • Temperatur: Trend, Gradient, saisonal-detrendete Residuen.

  • Strom: Harmonische, Sidebands, Slotting-Frequenzen (z. B. bei Traktionsmotoren).

  • Speicherung on-prem:

  • Timeseries DB (TimescaleDB/InfluxDB), Rohdaten-Rollup (z. B. 7 Tage Roh, 6 Monate Features).

  • Ereignis-Store für Wartungstickets (CMMS) mit sauberer Ontologie: Fehlerart, Maßnahme, Ursache, Befund.

  • Inferenz:

  • Edge-Inferenz via ONNX Runtime/TensorRT, CPU/GPU je nach Modell; Latenz-Ziel < 500 ms für online Warnungen.

  • Versioniertes Deployment via k3s/Podman, Healthchecks, Canary-Rollouts.

  • Governance:

  • Datenhoheit: On-Premise-Betrieb, DSGVO-konform, kein US-Cloud-Zwang.

  • Monitoring von Daten- und Konzeptdrift, Performance-Metriken, Re-Train-Pläne.

  • Integration CMMS/ERP: Automatisierte Ticket-Erstellung mit Kontext (Sensor-Snippet, Feature-Vektor, Score).

Architekturpfad A: Anomalieerkennung produktionsreif

  • Modellierung:

  • Unsupervised Basis: Autoencoder (AE) auf Feature-Vektoren; Rekonstruktionsfehler als Score.

  • Ergänzend: Change-Point-Detection auf Gesundheitsindex (z. B. gleitende spektrale Kurtosis) für klare Alarme.

  • Saisonale Dekomposition für Temperatursignale; Residuen-Überwachung per quantiler Schwellwertlogik.

  • Schwellen:

  • Per-Maschine Quantil-basierte Schwellen (p99.5 der Normalphase), adaptiv pro Lastzustand.

  • Hysterese und Minimum-Alarmdauer (z. B. Score > Schwelle für 3 von 5 Fenstern) zur Robustheit.

  • Human-in-the-loop:

  • Wartung bestätigt/verwiftet Alerts im CMMS; Feedback fließt in Score-Kalibrierung (Platt Scaling/Isotonic).

  • Aufbau Fehlerkatalog: Nach n bestätigten Fällen pro Modus entsteht Label-Basis für überwachte Modelle.

  • KPI:

  • Lead Time (Median/5%-Quantil), Alarm-Frequenz/Tag, Bestätigungsquote (% Alerts mit Befund),

  • vermiedene Folgeschäden, MTBF-Änderung auf betroffenen Assets.