Anomalieerkennung vs. RUL-Prognose in der Industrie: Wann Sie welches PdM-Verfahren wirklich brauchen

Problem: Warum so viele PdM-Initiativen am Ziel vorbeischießen
Predictive Maintenance scheitert in der Praxis selten an fancy Algorithmen, sondern an falschen Problemannahmen und am Mismatch zwischen Datenlage, Ausfallarten und Instandhaltungsprozessen. Der häufigste Fehler: Es wird eine “Remaining Useful Life” (RUL)-Prognose gefordert, ohne dass je eine Maschine bis zum tatsächlichen Ausfall durchgelaufen ist oder eine belastbare Historie mit Zeit-zu-Ausfall vorliegt. Das zweite Missverständnis: Anomalieerkennung wird als “billiger Vorstufe” gesehen, die bald durch RUL ersetzt wird. In realen Anlagen – Textilfertigung, Bahn, Produktion – sind das oft zwei verschiedene Klassen von Problemen, die unterschiedliche Daten, Architekturen und Metriken verlangen.

Was in der Praxis schiefgeht, ganz konkret:

  • Keine run-to-failure-Daten: Es werden präventive Wechsel gefahren, so dass keine echten RUL-Labels existieren. Daraus lässt sich keine seriöse Lebensdauer-Prognose lernen.

  • Falsches Ziel: Algorithmen optimieren MAE/MSE auf der Zeitachse, während die Instandhaltung ein 3–10-tägiges Planungsfenster braucht und Falschalarme härter bestrafen muss als verpasste Alarme – oder umgekehrt.

  • Nicht-stationäre Betriebsmodi: Drehzahl, Last, Temperatur und Material wechseln. Modelle, die “Normalzustand” als einen festen Punkt sehen, driften oder schießen Fehlalarme.

  • Feature-Armut: Reine Trendbetrachtungen auf Temperatur oder Strom verschleiern dynamische Effekte (z. B. Lagerschäden), die nur in Spektren und Ordnungsanalysen sichtbar werden.

  • Fehlende Integrationsstrategie: PdM-Ausgaben landen als PDF-Report statt als strukturiertes Ereignis im CMMS/ERP. Keine Rückkopplung, keine Label-Qualität, keine Lernschleife.

  • Data-Sovereignty wird ignoriert: Cloud-first-Ansätze scheitern spätestens beim Werksrat, in der Bahnzulassung oder in Verteidigungs- und kritischen Fertigungsumgebungen.

Kurz: Ohne eine explizite Entscheidung zwischen Anomalieerkennung (AD) und RUL – und die passende Architektur dazu – wird PdM zum teuren Dashboard.

Lösung: Eine technische Entscheidungsmatrix mit Architektur-Blueprint
Stellen Sie vor der ersten Zeile Code drei Fragen:
1) Welche Ausfallmodi dominieren und sind sie monotone Alterung oder sprunghafte Störungen?
2) Gibt es verlässliche Labels für “Zeit bis Ausfall/Intervention” oder nur “Normal vs. Auffällig”?
3) Welche Vorwarnzeit und Fehlertoleranzen verlangt die Instandhaltung konkret?

Daraus folgt die Verfahrenswahl.

Wann Anomalieerkennung das richtige Mittel ist:

  • Ausfälle sind selten und heterogen (z. B. textile Spindellager unter wechselnden Garnen).

  • Es existieren viele Stunden “guter” Daten und kaum dokumentierte Ausfälle.

  • Frühindikatoren sind subtil und eher “abweichend” als “monoton fortschreitend”.

  • Ziel ist ein robustes Frühwarnsystem mit konfigurierbarer Alarmrate.

Techniken:

  • Unüberwacht/halbüberwacht: Autoencoder (zeit- oder frequenzbereich), Isolation Forest, One-Class SVM, Robust PCA.

  • Spezifische Methoden:

  • Vibrationsdaten: RMS, Kurtosis, Crest-Factor, Hüllkurvenanalyse, Spektralpeaks auf Lagerkennfrequenzen (BPFO/BPFI), spektrale Entropie, Ordnungsanalyse bei variabler Drehzahl.

  • Stromaufnahme (MCSA): Seitenbänder um Netz- und Schlupffrequenzen, Oberschwingungen unter Laständerung.

  • Temperatur: Trendbruch, Gradient, saisonale Entkopplung.

  • Kalibrierung: Schwellwerte als Funktion des Betriebsmodus; erwartete Alarmrate auf Instandhaltungskapazität ausrichten.

Wann RUL-Prognose sinnvoll ist:

  • Monotone Verschleißprozesse mit systematischer Abnutzung (z. B. Bremsbelag, Filter, Radsatzprofil).

  • Vorhandene oder herstellbare Lebensdauer-Labels: Laufleistung, Lastzyklen, Differenzdruck bis Grenzwert, reale run-to-failure-Sequenzen.

  • Anforderungen verlangen planbare Tauschfenster und Flottenoptimierung (Teile, Werkstattkapazitäten, Umläufe).

Techniken:

  • Statistisch: Parametrische Lebensdauermodelle (Weibull/Lognormal), Cox-Modelle, Survival-Forests.

  • Zustandsraum: Gesundheitsindex mit Monotoniebedingungen, Kalman-/Partikelfilter für schrittweise Degradation.

  • Sequenzmodelle: TCN/LSTM/Transformer für multimodale Zeitreihen (Last, Temperatur, Schwingung), optional hierarchisch-bayesisch für Flotten mit Asset-spezifischen Varianzen.

Architektur-Blueprint (On-Premise, Edge-first)
1) Datenerfassung und Synchronisation

  • Sensorik:

  • Vibration: 3-achsige IEPE/ICP-Beschleunigungssensoren, typische Abtastraten 6,4–25,6 kHz für Lager- und Getriebeanalyse.

  • Strom/Spannung: 1–10 kHz (MCSA, Oberschwingungen).

  • Temperatur/Prozess: 1–10 Hz (Trends, Last).

  • Zähler/Events: Betriebszyklen, Drehzahl, Materialwechsel, Werkstück-ID.

  • Zeitbasis:

  • Edge-Boxen mit PTP/NTP-Sync, Trigger-Sampling entlang Maschinenereignissen (z. B. pro Umdrehung).

  • Order Tracking: Resampling in Winkelkoordinaten bei variabler Drehzahl.

  • Protokolle:

  • OPC UA, MQTT, Feldbus-Gateways (PROFINET, EtherCAT), proprietäre CNC/PLC-Treiber.

2) Datenfluss On-Prem

  • Stream-Ingestion: Kafka/Redpanda für Hochfrequenz, MQTT für Low-Rate.

  • Storage:

  • Rohdaten mit Lifecycle-Policies in Objektspeicher (z. B. MinIO on-prem).

  • Downsampled Timeseries in TimescaleDB/InfluxDB für schnelle Abfragen.

  • Feature-Pipelines:

  • Sliding-Window-Berechnung am Edge oder im Stream (Flink/Spark Structured Streaming).

  • Frequenzmerkmale per FFT/Welch, Envelope, Kurtosis, Ordnungsanalyse.

  • Feature-Drift-Metriken (Population Stability Index, KS-Test) kontinuierlich loggen.

  • Governance: Datenkatalog mit Sensor-Metadaten, Versionierung von Feature-Rezepten.

3) Modellierung

  • AD-Setup:

  • Normalitätsfenster je Betriebsmodus lernen (z. B. je Drehzahlband, Materialtyp).

  • Rekonstruktionsfehler (Autoencoder) oder Score (Isolation Forest) als health score.

  • Konfidenzkalibrierung per Platt-Scaling/Isotonic auf Validierungsperioden.

  • RUL-Setup:

  • Gesundheitsindex definieren (z. B. Differenzdruck Filter, Radabnutzung) mit Monotonieconstraint.

  • Lebensdauermodelle je Assetklasse, hierarchische Partial Pooling für standortspezifische Effekte.

  • Kovariaten: Last, Temperatur, Umgebung, Schichtregime.

  • Unschärfe kommunizieren: Prediction Intervals statt Punktwerte.

4) Online-Inferenz und Edge-Deployment

  • Edge-Container (z. B. K3s) mit:

  • Feature-Service in C++/Rust für HPC-nahe Signalverarbeitung.

  • Modell-Service in Python/C++ (ONNX-Runtime, TensorRT, libtorch) für geringe Latenz.

  • Windowing:

  • Vibrationsfenster 0,5–2 s, Überschneidung 50 %, für RUL eher länger aggregieren.

  • Ressourcen:

  • CPU-Vektor-Instruktionen nutzen (AVX2/AVX-512); GPU nur wenn vorhanden und nötig.

  • Robustheit:

  • Watchdogs, Backpressure ins Message-System, Offline-Buffering bei Netzstörung.

  • Sicherheit:

  • On-Prem-AuthN/Z, Audit-Logs, kein Datentransfer in Public Clouds, DSGVO-konform.