6) Modellwahl: Anomalieerkennung vs. RUL-Prognose – wann was?

  • Anomalieerkennung (AE):

  • Einsatz, wenn Ausfälle selten und Labels spärlich sind (meistens in Textilfertigung und Bahnbetrieb).

  • Methoden:

  • Ein-Klassen-Modelle (One-Class SVM), Isolation Forest – schnell, robust für Basisbetrieb.

  • Rekonstruktionsbasierte AE (Autoencoder) auf Ordnungs- oder Band-Features; Vorteil: Erklärbarkeit per Rekonstruktionsfehler je Featureband.

  • Statistische Baselines (Gaussian/Robust M-Estimatoren) mit Zeitkontext: Z-Scores und CUSUM auf “gesunden” Fenstern.

  • Zielgröße: “Anomalie-Score” mit Hysterese, Alarm nur bei anhaltender Erhöhung über mehrere Fenster; Metrik: False Positives pro 1000 Betriebsstunden, mittlere Vorwarnzeit.

  • RUL-Prognose (Remaining Useful Life):

  • Einsatz, wenn es einen monotone(n) Degradationsindikator gibt, ausreichende Historie mehrerer gleicher Assets mit Ausfällen und konsistenten Labels.

  • Methoden:

  • Lineare/Log-Modelle auf Degradations-Features mit Kalman-Glättung.

  • Überlebensmodelle (Cox, AFT) mit zeitvariablen Kovariaten (Load, RPM, Temperatur).

  • Sequenzmodelle (GRU/LSTM/TCN) nur wenn genügend diverse Lebensläufe vorhanden sind; andernfalls Overfitting.

  • Zielgröße: Zeithorizonte mit Unsicherheitsintervallen, Metriken: sMAPE auf Restlaufzeit, CRPS/Pinball-Loss für Prognosebänder.

  • Hybrid:

  • AE als “Früherkennung”, danach Übergang in RUL nur für bestätigte Trends. Das reduziert das Labelproblem und sorgt für stabile Produktionsalarme.

7) On-Prem-Deployment, Edge-Inferenz und Governance

  • Edge:

  • Rohabtas­ten und Vorverarbeitung (Hüllkurve, Ordnungsanalyse) nahe an der Maschine; ONNX/TensorRT für leichte Modelle, 1–5 W Rechenbudget je Knoten ist realistisch.

  • Pre-Trigger-Rohdaten zyklisch sichern; nur bei Anomalie vollständige Fenster archivieren.

  • On-Prem-Server:

  • Timeseries-DB (z. B. mit Cold/Hot Tiering), Feature-Store, Modellverwaltung; kein US-Cloud-Lock-in, DSGVO-konform.

  • Job-Orchestrierung für Re-Training, Drift-Monitoring, Canary-Rollouts der Modelle.

  • Governance:

  • Data Lineage: Jedes Modell kennt seine Feature-Versionen, Sensor-Kalibration und Gültigkeitsbereiche.

  • Drift-Checks:

  • Sensor-Drift: Spektrale Rausch-Floor-Verschiebungen, Offsets, SNR.

  • Prozess-Drift: Last/Speed-Verteilungen; ist das neue Operating Window noch vom Training abgedeckt?

  • Alarme mit Kontext: Score, Top-Features, Vergleich mit “gesunden” Referenzfenstern; keine Blackbox-Flags.

Tradeoffs: Was man gewinnt und was man aufgibt

  • Hohe Abtastrate vs. Bandbreite/Speicher:

  • Gewinn: Bessere Diagnose (Hüllkurve, Seitenbänder).

  • Kosten: Netzlast, Storage, CPU. Praxis: 1–4 s Hochfrequenzfenster alle 30–120 s reichen oft aus; kontinuierlich nur Features streamen.

  • Starre vs. flexible Sensor-Montage:

  • Gewinn (starre Montage): Reproduzierbare Kopplung, weniger Fehlalarme.

  • Kosten: Höherer Installationsaufwand, Maschinenstillstand bei Nachrüstung.

  • Tachogeber ja/nein:

  • Gewinn: Ordnungsspektren stabil, weniger FPs bei variabler Drehzahl.

  • Kosten: Zusatzhardware, Wartung. In der Praxis lohnt es sich bei Getrieben/Lagern mit wechselnder Drehzahl fast immer.

  • AE vs. RUL:

  • AE: Geringere Labelanforderung, schneller produktiv, jedoch liefert “nur” Score/Trend und keine Lebensdauer in Tagen.

  • RUL: Hoher Nutzen für Planung, aber nur bei konsistentem Degradationssignal und genug Historie. Sonst Scheinsicherheit.

  • On-Prem/Edge vs. Cloud:

  • On-Prem/Edge: Souveränität, niedrige Latenz, kein Abfluss von Rohwellenformen; höhere Verantwortung für Betrieb/Monitoring.

  • Cloud: Elastizität, aber Datenabfluss, Compliance-Risiken, Kosten bei rohdatenlastigen Workloads.

Praxis: Szenarien aus Fertigung und Bahn

Textilfertigung – Getriebe und Lager an Schärmaschinen
Ausgangslage:

  • Ziel: Früherkennung von Lagerschäden an Schär- und Spulmaschinen.

  • Sensorik (1. Iteration): 1 kHz Vibrationssampling, Magnetmontage, keine Tachoinformation, Temperatur nur aus SPS (Niedrigrate).

  • Ergebnis: Viele Fehlalarme, kein valider Zusammenhang mit echten Defekten. CMMS hatte Work-Orders ohne klare Fehlercodes.

Korrekturen:

  • Sensorik: Umgerüstet auf 12,8 kHz IEPE, verschraubte/verklebte Montage; Tachogeber an Hauptwelle.

  • Vorverarbeitung: Hüllkurvenanalyse mit Bandpass 3–8 kHz, Ordnungsanalyse mit Resampling auf Winkel.

  • Data Contracts: PTP in der Zelle, harte Ablehnung von Paketen ohne locked-Flag. Aufnahme von calibration_id und mount_type als Pflichtfelder.

  • Labeling: Einführung einer Fehler-Typologie (BEARING_OUTER, BEARING_INNER, GEAR_TOOTH, MISALIGNMENT, UNBALANCE). CMMS-Integration mapping auf diese Codes; Zeitfenster -10 d bis 0 h für FAILURE.

  • Modelle:

  • Stufe 1: Statistische AE auf Ordnungsbändern + Hysterese.

  • Stufe 2: Bei persistenter Anomalie Fit eines linearen Degradationsmodells (Trend pro Band) für grobe Restlaufabschätzung mit Unsicherheitsintervallen.

Resultate:

  • Fehlalarme reduziert auf < 1 pro 1500 Betriebsstunden und Maschine.

  • Erste echte Lageraußenring-Schädigung 10 Tage vor Geräuschwahrnehmung erkannt; Ersatzteil rechtzeitig disponiert, kein ungeplanter Stopp.

  • Interessante Nebenwirkung: Unwuchten durch Spulendurchmesseränderung wurden als “falsche Alarme” markiert, bis der Tachogeber eingeführt wurde. Danach trennten Ordnungsfeatures Unwucht (1× Order) klar von Lagerdefekten (breitbandige Hüllkurvensignale).

Lessons learned:

  • Ohne Tachogeber und starre Montage ist pdM an variabler Drehzahl ein Ratespiel.

  • CMMS-Disziplin zahlt sich sofort aus. Freitext-Einträge sind nett, aber nicht trainierbar.

Bahnbetrieb – Traktionsmotoren und Getriebe
Ausgangslage:

  • Ziel: Überwachung von Radsatzlagern und Antriebssträngen.

  • Rahmenbedingungen: Begrenzte Kommunikationsfenster, harte On-Prem-Policy, keine Cloud. Unterschiedliche Bordnetz-Controller, teils nur NTP.

  • Sensorik: Strommessung an Inverterausgängen, Vibration am Getriebe, Temperatur am Lagergehäuse.