5) Output und Integration in CMMS/ERP

  • Ereignisse als strukturierte Payload:

  • asset_id, timestamp, mode, score, score_delta, confidence, predicted_RUL, expected_window, recommended_action.

  • Schnittstellen:

  • SAP PM/Maximo/IFS via REST oder BAPI, OPC UA Methods zur Auftragserzeugung.

  • Closed-Loop-Labelling:

  • Techniker meldet Fehlerursache, Teiletausch, visuelle Befunde zurück. Diese Labels fließen in die nächste Trainingsrunde.

6) Monitoring, QA und Retraining

  • Data & Concept Drift:

  • PSI/KS-Metriken, Out-of-Distribution-Rate, Score-Shift je Modus.

  • Alert-Qualität:

  • Frühwarnzeit-Verteilung, False-Positive-Quote pro 1000 Betriebsstunden, verpasste Ereignisse.

  • RUL-Metriken:

  • MAE/MAPE der RUL, C-Index, Calibration Curves, Anteil Predictions im akzeptablen Fenster.

  • Retraining-Plan:

  • Zeit- oder ereignisbasiert (z. B. nach X neuen Ausfällen oder Moduswechseln).

  • Auditierbarkeit:

  • Modell-, Daten- und Feature-Versionen in einem Registry (z. B. MLflow) mit reproduzierbaren Artefakten.

Trade-offs: Was Sie gewinnen und was Sie aufgeben
Anomalieerkennung

  • Vorteile:

  • Funktioniert mit “nur normal”-Daten und knappen Labels.

  • Robust gegenüber neuen, unbekannten Fehlerbildern.

  • Schnelle Time-to-Value, geringer Labelierungsaufwand.

  • Nachteile:

  • Keine direkte Restlebensdauer; Alarme müssen in Planungsfenster übersetzt werden.

  • Interpretierbarkeit variiert; Aufwand, Score auf Betriebsmodi zu kalibrieren.

  • Alarm-Fatigue, wenn Governance und UI fehlen.

RUL-Prognose

  • Vorteile:

  • Planbare Ersatzteil- und Werkstattlogistik, Flottenoptimierung.

  • Höhere Akzeptanz, wenn physikalische Verschleißprozesse sichtbar und monoton sind.

  • Nachteile:

  • Hoher Daten- und Label-Bedarf (run-to-failure oder verlässliche Surrogate).

  • Modellrisiko bei Moduswechseln und Re-Engineering der Maschine.

  • Überkalibrierung auf historische Flotten, Transfer auf neue Standorte schwierig.

Edge- vs. zentraler Betrieb

  • Edge:

  • Geringe Latenz, keine Datenabflüsse, DSGVO-konform, autark bei Netzausfall.

  • Begrenzte Rechenressourcen, Wartung vieler Knoten.

  • Zentrale On-Prem-Cluster:

  • Einfachere Verwaltung, Training zentral, Inferenz teils edge, teils zentral.

  • Netzabhängigkeit für Nicht-Edge-Teile, höhere Anforderungen an OT/IT-Segmentierung.

Praxis: Drei Szenarien aus Textil, Bahn und Fertigung
1) Textil: Spindellager und Greifer – variable Drehzahl, wechselndes Garn
Problem: Lager und Greifer in Spinn- und Webmaschinen laufen mit hochvariablen Drehzahlen, wechselnden Garnen und Spannungen. Temperaturtrends reichen zur Früherkennung nicht aus. Run-to-failure-Daten fehlen, da Lager oft vorsorglich gewechselt werden.

Ansatz:

  • Sensorik: 3-achsige Beschleunigungssensoren nahe Lager, Abtastung 12,8 kHz, Drehzahlsignal aus der Steuerung.

  • Feature-Engineering: Ordnungsbasiertes Resampling, Hüllkurvenanalyse, Peaks bei Lagerkennfrequenzen, spektrale Entropie. Ergänzend: Motorstromseitenbänder bei Lastwechseln.

  • Modell: Halbüberwachter Autoencoder pro Betriebsmodus (Drehzahlband, Garnart). Score als Rekonstruktionsfehler normalisiert auf Modus-Statistik.

  • Deployment: Edge-Container je Maschinenreihe, Windowing 1 s mit 50 % Overlap, Score-Glättung über Minuten.

  • Integration: Score-Event löst in CMMS eine visuelle Kontrolle in der planbaren Stillstandsphase aus. Wiederholte High-Score-Fenster innerhalb 48 h erzeugen konkreten Tauschvorschlag.

  • Ergebnis in der Praxis: Frühwarnungen erfolgen üblicherweise in Tage- statt Stundenabständen vor kritischen Geräuschspitzen oder Temperaturanstiegen. Falschalarme wurden durch Modus-spezifische Kalibrierung deutlich reduziert.

Warum keine RUL? Mangels belastbarer run-to-failure-Historie und wegen diskontinuierlicher Lastprofile wären Punktprognosen unseriös. Eine gut kalibrierte AD mit abgestufter Eskalation passt besser in Schicht- und Wartungsfenster.

2) Bahn: Verschleißprozesse mit flottenweiter Planung – RUL auf Komponentenebene
Problem: Bestimmte Komponenten (z. B. Filter, Bremsbeläge, Radsatzprofil) unterliegen monotonem Verschleiß. Ziel ist eine flotteweite Planung von Teilen, Werkstattkapazitäten und Umläufen – nicht nur Einzelfallwarnungen.

Ansatz:

  • Daten: Laufkilometer, Bremszyklen, Umgebung (Topografie, Temperatur), Differenzdruck an Filtern, Profiltiefe aus Messportalen, Ereignisse (Sanding, Notbremsungen).

  • Feature-Engineering: Nutzungsintensität (Zyklen pro km), Gradienten, Temperatur-Exposure, Streckenmix. Quality-Flags der Messsysteme zwingend berücksichtigen.

  • Modell:

  • Parametrische Lebensdauer (Weibull) je Baureihe, Standort als Kovariate.

  • Hierarchisches Partial Pooling: Asset-spezifische Zufallseffekte, um Unterschiede zwischen Zügen/Wartungsregimen sauber zu modellieren.

  • Optional: TCN für Sequenzen, um Nichtlinearitäten aufzunehmen, aber mit Monotonie- oder Trend-Regularisierung.

  • Deployment: Zentrale On-Prem-Inferenz täglich, Ausgabe Prediction Intervals (z. B. 80/95 %) und empfohlene Tauschfenster. Keine Public Cloud, Daten verbleiben im Betriebsnetz.

  • Integration: SAP PM Arbeitsvorschläge mit Priorisierung nach Überschneidung von RUL-Intervallen mit geplanten Werkstattaufenthalten; automatische Konsolidierung für Flotten-Termine.

  • Ergebnis in der Praxis: Statt starrer Kilometergrenzen werden Tauschtermine auf Grundlage tatsächlicher Nutzung und Umgebungsbedingungen geplant. Die Streuung der Restlaufzeitprognosen wird explizit kommuniziert, um konservative vs. aggressive Strategien transparent zu machen.

Warum nicht AD? Für monotone Verschleißteile liefert AD nur wiederholte “abweichend”-Signale, aber keinen Flottenplan. RUL ist hier betriebswirtschaftlich die überlegene Kenngröße – vorausgesetzt, Mess- und Labelqualität stimmen.

3) Serienfertigung: Druckluftfilter und Pumpen – beides in Kombi
Problem: In Druckluftsystemen altern Filter monoton (Differenzdruck steigt), während Pumpenlager eher sprunghafte Anomalien zeigen.

Ansatz:

  • Filter (RUL):

  • Sensorik: Differenzdruck, Temperatur, Volumenstrom.

  • Modell: Trend + Survival-Modell mit Grenzwert als Ausfallkriterium, Prediction Intervals.

  • Pumpe (AD):

  • Sensorik: Vibration (6,4–12,8 kHz), Motorstrom (2 kHz).

  • Feature-Set: Hüllkurve, Kurtosis, Seitenbandenergie, Ordnungen.

  • Modell: Isolation Forest/Autoencoder pro Betriebsmodus.

  • Planung:

  • RUL-Termine für Filter werden mit Werkstattfenstern abgeglichen.

  • AD-Alerts für Pumpen erzeugen Prüfaufträge mit kurzer SLA.

  • Governance: Gemeinsames UI zeigt beide Kanäle, aber unterschiedliche Semantik: Termine vs. Alarme.