Anomalieerkennung vs. Remaining-Useful-Life (RUL) in der vorausschauenden Instandhaltung: Ein Entscheidungsrahmen aus Bahn- und Textilpraxis

Problem: Was in der Praxis schiefgeht
Wenn Industrieunternehmen „Predictive Maintenance“ starten, passiert häufig Folgendes: Jemand setzt eine Ziel-Folie mit hübschen RUL-Kurven auf, das Team sammelt ein paar Wochen Daten, trainiert einen LSTM auf Zeitreihen – und nach ein paar Sprints ist klar: keine sauberen Labels, keine echten Run-to-Failure-Datensätze, wechselnde Sensorik nach Wartungen, und die Anlagen laufen zum Glück zu selten kaputt, um ein robustes Lebensdauermodell zu lernen. Ergebnis: ein POC, der auf historischen „Best-of“-Beispielen gut aussieht, aber in der Schicht 3 um 02:15 Uhr nicht ausrollbar ist.

Die typischen Stolpersteine:

  • RUL ohne Datenbasis: RUL-Modelle brauchen systematisch erfasste Verläufe bis zum Ausfall für denselben Fehlermechanismus und dieselbe Asset-Familie. Häufig existieren davon <10 Beispiele – oder keins.
  • Falsche Labels aus dem CMMS: „Failure“ vs. „Preventive Maintenance“ ist nicht sauber getrennt, Timestamps sind Off-by-hours, oder ein Tausch des Aggregats wird nicht mit dem Sensor-Reset verknüpft.
  • Sensor- und Prozessdrift: Nach einer Überholung verschieben sich Baselines (z. B. Vibrations-RMS -30%). Ohne Reset-Logik feuern Schwellen entweder dauernd oder nie.
  • Datenlatenz und -qualität: Rohdaten mit 12 kHz Vibration via Cloud-API zu schieben ist illusorisch, Edge-Pufferung fehlt, Anti-Aliasing nicht konfiguriert, Sampling jittert.
  • Organisatorische Asymmetrie: Der Schaden eines False Negative (Ausfall im Betrieb) ist groß, der Schaden eines False Positive (unnötiger Werkstattbesuch) auch – aber unterschiedlich je Assetklasse. Das spiegelt sich selten in den Modellen oder Metriken wider.

Kurz: Viele Teams starten „technology first“. In der Praxis funktioniert „problem first“: Welche Ausfallarten? Welche Eingriffe sind realistisch? Welche Daten sind sicher verfügbar – on-prem, souverän, dauerhaft? Erst dann folgt die Modellwahl.

Lösung: Architektur, Datenfluss, Modellwahl – und ein klarer Entscheidungsbaum
Es gibt keine Einheitslösung. Wir nutzen einen einfachen Entscheidungsrahmen, der in der Textilfertigung (Spindeln, Lager) und im Bahnbereich (Kompressoren, Lüfter, HVAC) tragfähig ist.

1) Entscheidungsrahmen: Anomalieerkennung oder RUL?

  • Wenn Sie <20 dokumentierte Run-to-Failure-Verläufe pro homogenem Fehlermechanismus haben: Anomalieerkennung.
  • Wenn Ausfälle selten sind (MTBF > 2–3 Jahre) und operative Eingriffe auch bei „unscharfen“ Vorwarnungen planbar sind: Anomalieerkennung mit stabilen Baselines und Kontextsignalen (Last, Temperatur).
  • Wenn es einen klaren, monotonen Degradationspfad gibt (z. B. definierter Verschleiß), wiederkehrend über dieselbe Asset-Familie, und belastbare Run-to-Failure-Daten (≥20–50 Fälle) vorliegen: RUL oder Survival-Analyse.
  • Wenn Wartung ohnehin zustandsbasiert erfolgt (Inspektionsfenster, Depotturnus), und die Frage „ob bald etwas nicht stimmt“ wichtiger ist als „wie viele Stunden noch“: Anomalieerkennung.
  • Wenn Teilebeschaffung/Lieferkette lange Vorläufe hat und Sie Just-in-Time planen müssen (z. B. teure, seltene Komponenten): RUL – sofern oben genannte Datenbasis realistisch.

2) Datenerfassung und Vorverarbeitung

  • Vibration (Lager, Getriebe, Spindeln): 3-Achsen-Beschleunigung 6–12 kHz, 16-bit ADC, Anti-Aliasing-Filter. Fenster 1–2 s mit 50% Überlappung, Hann-Fensterung für FFT/STFT. Feature-Sets: RMS, Crest-Faktor, Kurtosis, Spektralenergie in Bändern, Hüllkurven-FFT um BPFO/BPFI/BSF-Frequenzen.
  • Temperatur: 1–2 Hz (Echtzeit reicht), Median-Filter gegen Spikes, Kontext zur Last.
  • Stromaufnahme (Motoren, Kompressoren): 2–5 kHz, ggf. Phasenströme getrennt, Harmonische (THD), Slip-bezogene Spektralanteile (MCSA).
  • Akustik (Lager/Fans): 24–48 kHz, nur edge-aggregiert verschicken (mel-spektro Feature-Vektoren), keine Rohdaten in die Zentrale.

3) Edge- und On-Prem-Architektur (souverän, cloud-unabhängig)

  • Edge-IPC (Industrie-PC/RT-Controller): C++/Rust-Komponenten zur Signalaufbereitung, Feature-Extraktion, lokalem Inferenzdienst. Pufferung (Ringbuffer) 1–4 h.
  • Nachrichtenschicht: MQTT/Kafka on-prem. Keine US-Cloud. Air-gapped optional.
  • Time-Series-Storage: TimescaleDB/InfluxDB on-prem. Feature Store in PostgreSQL.
  • Orchestrierung: Kubernetes on-prem, Rolling Updates, Canary-Deployments pro Linie/Depot.
  • Model Registry & CI/CD: Selbstgehostetes MLflow/Argo-Workflows. Unit-/Integrationstests gegen synthetische und Replays.
  • Betrieb/Monitoring: Prometheus/Grafana, technische KPIs (Latenz, Dropped Windows), ML-KPIs (Alarmrate/24h, Drift-Indikatoren).
  • Integration: CMMS/ERP via REST/SOAP, bidirektional. Alarm -> Ticket, Ticket/Workorder -> Label-Feedback. (→ alpitype.de/leistungen/)

4) Modellfamilien und wann sie Sinn ergeben

Anomalieerkennung (unsupervised/semi-supervised)

  • Ziel: Abweichung vom gesunden Zustand detektieren. Keine expliziten Ausfall-Labels nötig.
  • Muster:
  • Robust-basierte Schwellen: Z-Scores auf Features mit EWMA-Baseline, „Seasonality“-Korrektur (Schicht, Drehzahlbänder).
  • Multivariat-Gauß und Mahalanobis-Distanz auf Feature-Vektoren; adaptiv kalibriert nach Wartung.
  • Isolation Forest/One-Class SVM für nichtlineare Trennungen; gut bei gemischten Sensor-Features.
  • Autoencoder (1D-CNN/LSTM) auf Feature-Sequenzen; Rekonstruktionsfehler als Anomaliescore; Edge-tauglich mit kleinen Netzen.
  • Change Detection (CUSUM/ADWIN) auf Health-Indizes oder Energiebändern für plötzliche Sprünge (z. B. Unwucht).
  • Vorteile: Wenig gelabelte Ausfälle nötig; robuste Frühwarnungen möglich; schneller Time-to-Value.
  • Nachteile: Keine explizite Restlebensdauer; Alarme müssen in Betriebslogik übersetzt werden (Ampellogik, Eskalation).

RUL/Survival-Modelle (supervised)

  • Ziel: Prognose der verbleibenden Nutzungsdauer (Stunden/Zyklen) oder Ausfallwahrscheinlichkeit in Zeitintervallen.
  • Muster:
  • Degradationsmodelle: Log-linear/Exponentialtrend eines Health-Index; Kalman-Filter/Bayesian State Space.
  • Survival-Analyse: Weibull/Cox mit Kovariaten (Last, Temperatur, Nutzungsprofile), zensierte Daten inklusive.
  • Deep Sequence zu RUL: LSTM/Temporal ConvNet auf Feature-Sequenzen mit spezialisierter, asymmetrischer Verlustfunktion.
  • Voraussetzungen: Viele konsistente, gleichartige Ausfälle des Ziel-Fehlertyps; nach Maintenance Reset des Lebenszyklus; stabile Messkette.
  • Vorteile: Planbarkeit (Ersatzteil, Werkstattfenster); Simulation von Ausfallrisiko vs. Takt.
  • Nachteile: Hoher Datenhunger; empfindlich für Konzeptdrift; aufwendige Validierung.

5) Labeling, Health-Index und zensierte Daten