Trade-offs: Was man gewinnt – und was es kostet

  • Datenbedarf

  • Anomalie: Geringer, v. a. Normdaten nötig. Robustheit aber nur mit guter Regime-Stratifizierung.

  • RUL: Hoch. Ohne ausreichende, konsistente Run-to-Failure-Daten erzeugt das Modell mehr Scheinpräzision als Nutzen.

  • Interpretierbarkeit

  • Anomalie: Gut erklärbar über Feature-Abweichungen; Changepoints zeigen “ab hier wurde es anders”.

  • RUL: Survival/Weibull gut erklärbar, tiefe Sequenzmodelle deutlich schwerer.

  • Operativer Nutzen

  • Anomalie: Frühwarnung, “Stop-the-bleed”. Hoher ROI bei kurzen Implementationszyklen.

  • RUL: Planungssicherheit, bessere Ersatzteil- und Kapazitätsplanung – aber nur bei stabilen Modi.

  • Robustheit gegen Konzeptdrift

  • Anomalie: Drift-Detektion integrierbar, aber anfällig für neue Regimes ohne Kontextfeatures.

  • RUL: Stark anfällig; Re-Training und Re-Validierung verpflichtend bei jeder Prozessänderung.

  • Rechen- und Integrationsaufwand

  • Anomalie: Edge-fähig auf ARM/x86, 50–200 MB RAM reichen oft.

  • RUL: Sequenzmodelle ggf. GPU im Training; Inferenz meist CPU-fähig, aber komplexere Serving-Logik.

Praxisbeispiele
Textilfertigung: Lager- und Düsensysteme an Luftdüsenwebmaschinen

  • Ausgangslage: Ungeplante Stillstände durch Lagerpitting an Antrieben und Drift/Verkokungen in Düsensystemen. Drehzahlen 600–1.100 U/min, Lastsprünge bei Materialwechseln. Sensorik: triaxiale Beschleunigung 6,4 kHz, Stromaufnahme 500 Hz, Temperatur 1 Hz.

  • Was nicht funktionierte: Frühe RUL-Schätzungen auf Basis von RMS-Trends starben mit jedem Schichtwechsel. Ein einzelnes LSTM pro Maschine lieferte inkonsistente Horizonte – zu wenig konsistente Failure-Runs, zu viel Produktmix-Varianz.

  • Was funktionierte:

  • Edge-Features: Spektralband-Energien um 1×/2× Drehzahl, Envelope im 5–10 kHz Band für Lager; für Düsen: duty-cycle-normalisierte Strompulse, Druckpuls-Statistik.

  • Regime-Tagging: Drehzahl/Last/Garnart als Kontext; pro Regime eigener Baseline-Schätzer.

  • Anomalie-Scoring: Isolation Forest + Autoencoder-Rekonstruktionsfehler als Ensemble. Alarme nur bei Persistenz über 3/5 Fenster und Cross-Sensor-Konsens.

  • Schwellwerte via EVT pro Asset-Familie. Alarme in SAP PM mit “Wartung innerhalb 7 Tagen”-Empfehlung, Checkliste verlinkt.

  • Ergebnis: Median-Lead-Time 5–12 Tage vor hörbarem Lagerschaden; False Alarm Rate < 1 pro 1.000 Betriebsstunden pro Linie nach Tuning. RUL? Später selektiv eingeführt für Düsennadeln (quasi-lineare Degradation): AFT-Modell mit 80%-Intervall, Buckets 45 Tage – gut genug für Bündelwartungen.

Bahnbetrieb: Traktionshilfsaggregate und Bremsbelagverschleiß

  • Ausgangslage: Strecken- und Wetterprofile führen zu stark variierenden Lastzyklen. Ausfälle von Kompressoren/Lüftern sind betriebskritisch, aber selten vollständig “bis zum Ausfall” dokumentiert. Sensorik: Vibration 12,8 kHz, Strom 1 kHz, Druck 10 Hz, Odometer und Bremszyklenzählung onboard. Edge-Rechner: x86/ARM, 4–8 GB RAM, sporadische Connectivity in Depots.

  • Ansatz:

  • Hybride Strategie: Anomalieerkennung für Kompressoren/Lüfter (impulsive Defekte, Lager); RUL für Bremsbeläge (monotone Abnutzung).

  • Anomalie: Envelope + Spectral Kurtosis für Lager, THD-Anstieg im Strom als zweiter Kanal; Bayesian Changepoint zur Erkennung plötzlicher Moduswechsel (z. B. Verunreinigung). Serving direkt am Zug, Latenz <50 ms.

  • RUL: Belagverschleiß als Funktion von Odometer, Bremsdruckprofilen und Achslasten. Weibull-basierte Hazard-Modelle mit zensierten Intervallen aus Werkstattbefunden; Ausgabe als Bucket “20.000 km”.

  • Integration: On-Prem-Server im Depot aggregiert Flottenzustände, synchronisiert Work Orders. Keine Cloud-Abhängigkeit; Offline-Pufferung auf Fahrzeugen bis 72 h.

  • Ergebnis: Frühwarnungen ermöglichten geplante Tauschfenster; RUL-Buckets reduzierten Notfall-Belagnachlieferungen signifikant. Wichtigster Punkt: striktes Governance – jede Alarmklasse hatte SLA, Prüfschritte und Feedback an das Modellteam.

Bewertung und Metriken: Weg mit Accuracy, her mit Zeitbezug

  • Anomalie

  • Time-to-Detect (TTD): Median/95%-Quantil der Vorwarnzeit.

  • False Alarms pro 1.000 Betriebsstunden und pro Asset-Familie.

  • Alert-Persistence vs. Operator-Action: Wie oft führt ein persistenter Alarm zu einer Work Order binnen x Tagen?

  • RUL

  • Prognostic Horizon: Zeitabstand, in dem der RUL-Fehler < ε bleibt (z. B. ±20%).

  • Alpha-Lambda-Performance: Anteil der Prognosen, die hinreichend früh (α) und genau (λ) sind.

  • Calibration: Deckt das 80%-Intervall in ~80% der Fälle den wahren RUL ab?

Datenqualität: Ohne das fliegt jede Methode auseinander

  • Sensor-Platzierung und Befestigung: Vibration am falschen Bauteil liefert Blindleistung. Lieber ein guter, starr montierter Sensor als drei lose geklebte.

  • Zeitsynchronisation: Strom, Vibration, Kontext müssen in Subsekunden synchron sein; sonst sind Transienten-Features wertlos.

  • Regime-Metadaten Pflicht: Drehzahl/Last/Umgebung wandern als Kontext mit. Fehlende Kontexte killen Generalisierung.

  • Health-Indicator-Drift: Regelmäßige Rekalibration (z. B. monatlich), besonders bei Austausch von Komponenten/Sensoren.

Edge vs. On-Prem: Warum wir selten Cloud-first empfehlen

  • Latenz und Verfügbarkeit: Kritische Alarme müssen auch offline funktionieren. Edge-Inferenz ist Standard, nicht Ausnahme.

  • Datenhoheit: Rohsignale bleiben lokal. Für globale Analysen genügen aggregierte Features/Scores.

  • Kostenstruktur: Permanentes Hochladen von Roh-Vibrationen (kHz) ist betriebswirtschaftlicher Unsinn und rechtlich heikel. On-Prem mit selektiver Synchronisation ist der praktikable Weg.

  • Deployment: Containerisierte Modelle, rollierende Updates in Wartungsfenstern, Blue/Green pro Depot oder Fertigungslinie. Artefakte und Datenstände versioniert (→ alpitype.de/leistungen/).

Konkreter Umsetzungsfahrplan

  • Woche 0–4: Daten-/Sensor-Audit, Failure-Mode-Effects-Analyse mit Instandhaltung, Definition von 3–5 Health Indicators pro Komponente. Metriken und Alarm-SLAs festlegen.

  • Woche 5–12: Edge-Feature-Pipeline bauen, erste Anomalie-Modelle je Regime, EVT-Schwellen, Integration in CMMS mit Ticketvorlagen. Start kleiner Operator-Feedback-Schleife.

  • Monat 3–6: Drift-Monitoring produktiv, Tuning auf False Alarms < 1/1.000 h, Dokumentation der bestätigten Fälle. Sammlung potenzieller RUL-Kandidaten (monotone Modi).

  • Monat 6–12: Survival-/AFT-Modelle für 1–2 klar definierte Komponenten. RUL als Buckets, kalibrierte Intervalle. Validierte Retrain-Policy bei Prozessänderungen.

  • Ab Monat 12: Ausweitung auf weitere Asset-Familien, wo Datenreife gegeben. Stetige Prüfung: Fügt RUL echten Planungsnutzen hinzu, oder genügt ein guter Anomalie-Lead?