Anomalieerkennung vs. Remaining-Useful-Life-Prognose: Wann welche PdM-Strategie in der Industrie wirklich trägt

Problem: Warum PdM-Projekte hier scheitern
Die meisten Predictive-Maintenance-Initiativen scheitern nicht am Algorithmus, sondern an einer falschen Problemformulierung und an Daten, die das gewählte Verfahren nicht tragen. Zwei Muster sehen wir immer wieder:

  • Zu früh auf RUL springen: Teams wollen gleich eine Restlebensdauer in Tagen prognostizieren, obwohl es keinen verlässlichen, monotonen Degradationsindikator gibt und nur wenige echte Ausfälle dokumentiert sind. Ergebnis: Modelle, die hübsch aussehen, aber in Produktion entweder schweigen oder konfident falsche Zahlen liefern.
  • Anomalieerkennung ohne Kontext: Unsupervised Modelle werden auf “alles, was da ist” trainiert, ohne Betriebszustände (Last, Drehzahl, Temperatur) zu trennen. Die Folge sind Alarmfluten bei Lastwechseln und Wetterumschwüngen. Nach ein paar Wochen schaltet die Instandhaltung die Alarme ab.

Dazu kommen typische Praxisprobleme:

  • Ground Truth Mangel: Run-to-Failure-Daten sind selten; Wartungslogs sind unvollständig oder nicht zeitlich synchronisiert mit Sensordaten. Censoring (Komponenten werden getauscht, bevor sie ausfallen) verzerrt RUL-Labels.

  • Falsches Sampling: Vibrationen werden bei 1 kHz erfasst, obwohl Lagerfehler-Banden >5 kHz brauchen; Stromaufnahme wird nur jede Sekunde geloggt, während relevante Transienten im Millisekundenbereich liegen.

  • Kein “Closing the Loop”: Anomalien landen als E-Mails, nicht als strukturierte CMMS-Arbeitsaufträge. Keine Rückkopplung heißt: keine Labels, kein Lernen.

  • Vernachlässigte Betriebsmodi: Modelle sehen Mischdaten aus Anfahren, Stationärbetrieb, Leerlauf. Ohne Modusklassifikation ist Drift vorprogrammiert.

  • Cloud-first gegen die Realität: In Bahn und Fertigung ist Konnektivität begrenzt, Datenhoheit Pflicht. Latenz- und Compliance-Anforderungen werden ignoriert, bis es zu spät ist.

Lösung: Eine Entscheidungsarchitektur, die Daten- und Ausfallmodi ernst nimmt
Bevor es um Algorithmen geht, kommt die Instandhaltungsstrategie und das Datenfundament. Unser Fahrplan, der sich in Textilfertigung und Bahn bewährt hat:

1) Failure Mode zuerst, nicht Modell zuerst

  • FMEA/FMECA kurz und hart: Was fällt aus? Wie kündigt es sich an? Welche Sensorik “sieht” diese Physik?

  • Klassifiziere Ausfallmodi:

  • Monoton degradierend (z. B. Rollenlagerverschleiß, Bürsten- oder Belagabnutzung)

  • Intermittent/Random (z. B. Türstörung durch Verklemmen, Kabelbruch, Feuchtigkeit)

  • Abrupt/Katastrophal (z. B. elektronische Bauteile ohne Vorwarnung)

  • Ordne jedem Modus einen beobachtbaren Indikator zu (z. B. Hüllkurvenenergie in einem Band, Seitenbandamplituden, Temperaturgradient, Stromsignatur).

2) Daten-Audit mit harter Metrik

  • Abtastrate vs. Physik:

  • Vibrationen für Lager/Getriebe: typischerweise 10–20 kHz, bei langsamlaufenden Achsen ggf. niedriger, aber mit Ordnungsanalyse. Ohne Tachometer/Order-Tracking: Vorsicht vor Alias-Effekten.

  • Stromaufnahme (MCSA) von Induktionsmotoren: 5–10 kHz für Nebenbänder; Netzfrequenz und Oberwellen trennen.

  • Temperatur: Sekundenbereich reicht, wichtig sind Gradienten und stationäre Offsets pro Lastzustand.

  • Betriebszustände: Definiere diskrete Modi (z. B. Drehzahlbänder, Lastkorridore). Label diese online (aus SPS/OPC UA) oder via HMM/Cluster, sonst driftet alles.

  • Ground Truth: Synchronisiere CMMS/ERP-Ereignisse mit Sensorzeitachsen. Definiere T0 pro Ereignis (Ausfall, Tausch), Censoring markieren.

3) Entscheidungsbaum: Anomalie vs. RUL

  • Wähle Anomalieerkennung, wenn:

  • Kaum/keine verlässlichen Ausfall-Labels existieren.

  • Ausfallmodi vielfältig sind oder Sensorik nur “Normalzustand” sicher erfasst.

  • Die Aktion Inspektion/Diagnose ist akzeptabel.

  • Wähle RUL, wenn:

  • Ein (nahezu) monotoner Degradationsindikator existiert.

  • Ausreichend Ereignisse (Ausfälle/Tausche) für Kalibrierung vorhanden sind oder physikalische Degradationsmodelle genutzt werden können.

  • Planungsvorteile (Teile-Lead-Times, Umlauf-/Mission-Planung) die Komplexität rechtfertigen.

4) Modellarchitektur pro Strategie

  • Anomalieerkennung (semi-/unsupervised):

  • Feature-Engineering: Zeit- und Frequenzdomäne pro Modus (RMS, Peak, Kurtosis, Crestfaktor, Bandenergien, Seitenbandamplituden, spektrale Entropie; Hüllkurvenanalyse für Lager).

  • Modelle: One-Class SVM, Isolation Forest, PCA/Autoencoder, Deep SVDD. Für sequenzielle Muster: LSTM/TCN-Autoencoder; für Probabilistik: Normalizing Flows.

  • Thresholding: Per-Modus, dynamisch; Score-Glättung (EWMA), Alarmverifikation über mehrere Fenster.

  • RUL-Prognose:

  • Degradationsindikator definieren: z. B. monotone Trendgröße (Hüllkurvenband E, Temperaturanstieg ΔT pro kW, Anstieg des Oberwellenanteils).

  • Modellfamilien:

  • Klassisch: Accelerated Failure Time (Weibull/Log-Logistic), Cox mit zeitvariablen Kovariaten (Achtung: Proportionalitätsannahmen prüfen).

  • State-Space/Bayesian: Kalman-/Particle-Filter mit latenter Health-Variable; Unsicherheiten explizit.

  • Deep: RNN/TCN mit monotonic constraints oder ordinal regression auf Bins; Loss mit Time-to-Event/Censoring.

  • Kalibrierung: Prognose-Intervall, Monotonie-Metrik, Alpha-Lambda-Kriterien.

5) Systemarchitektur und Datenfluss (On-Prem/Edge-first)

  • Erfassung:

  • Sensorik nahe Maschine/Subsystem; Takt-/Drehzahlsignal, wenn rotierende Komponenten relevant.

  • Edge-Knoten (x86/ARM) mit ADC, lokaler Vorverarbeitung (Bandpässe, Hüllkurve, FFT), Fenster 1–4 s mit 50 % Overlap für Vibrationen.

  • Transport/Storage:

  • MQTT/OPC UA für Telemetrie; Protobuf/Avro für binäre Payloads.

  • On-Prem Timeseries-DB (z. B. Timescale/Influx-kompatibel) für Roh- und Feature-Zeitreihen; Dateiablage für hochfrequente Schnappschüsse (WAV/Parquet).

  • Inferenz:

  • Anomalie-Modelle am Edge, per Modus aktiv; RUL eher zentral/on-prem wegen Flottenbezug, aber mit lokalen Features.

  • Laufzeitumgebung: ONNX Runtime/TensorRT; Modelle versioniert, signiert, rollenbasiert ausgerollt.

  • Integration:

  • CMMS/ERP über REST/OPC UA: Anomalie → Inspektionsauftrag mit Sensorbezug; RUL → geplanter Tauschauftrag mit Vorlaufzeit und Teilenummer.

  • Feedbackschleife: Auftragsergebnis (Befund, Restlauf, Tauschgrund) wird strukturiert an den PdM-Store zurückgespielt.

6) Erfolgsmessung

  • Anomalie:

  • False Alarms per 1000 Betriebsstunden pro Modus

  • Time-to-Detect vor Ereignis (Median, 10-/90-Perzentil)

  • Precision/Recall über Ereignisfenster

  • RUL:

  • MAE in Stunden/Zyklen innerhalb 30 Tage vor Event

  • Kalibrierung (z. B. 80-%-Intervalldeckung)

  • Monotonie-Score des Health-Index

  • Prognosehorizont (PH) bei gegebener Fehlergrenze