Korrekturen:

  • Zeit: PTP auf den Gateways mit Hardware-Timestamps; NTP nur als Fallback. Events mit ptp_status != locked als “degraded quality”.

  • Abtastrate:

  • Online: Reduziert auf 2–5 kHz für Strom, 6,4–12,8 kHz für Vibration in kurzen Fenstern. Kontinuierlich wurden nur Features gesendet.

  • Offline: Depot-Fenster mit 51,2 kHz Rohdaten archiviert für Modellpflege.

  • Mechanik: Vibration am Getriebelager mit verschraubten Sensoren; Kabelschutz gegen EMV und Vibration.

  • Labeling: Flottenübergreifender Fehlerkatalog, Work-Order-Mapping, klare Trennung zwischen geplanten Radsatzwechseln und echten Ausfällen.

  • Modelle:

  • AE mehrstufig:

  • Stufe 1: Sensorqualitäts-Klassifikator (SNR, Dropouts, Quantisierung).

  • Stufe 2: Ordnungs- und Hüllkurvenbasierte AE mit Hysterese und Load/RPM-Konditionierung.

  • RUL wurde verworfen: Zu viele Einflussgrößen (Streckenprofil, Last, Wetter), Lebenslaufdaten heterogen. Stattdessen: “Confidence-Bands” auf Anomalietrends und Entscheidungsregeln, die mit Wartungsfenstern (nächster Depottermin) verknüpft sind.

Resultate:

  • Betriebsmetrik: < 1 Fehlalarm pro 10.000 km pro Zugverband als Ziel – erreichbar nach Einführung von PTP und Qualitätspipeline.

  • Ein Fall: Ein massiver “Anstieg” im Anomaliescore korrelierte mit einem NTP-Zeitversatz und Paketduplikaten – nach Härtung der Timestamp-Chain verschwanden die Geisteralarme.

Lessons learned:

  • Infrastruktursauberkeit (Zeit, Paketverlust, EMV) schlägt Modellkomplexität.

  • RUL ist in der Bahn oft ein Management-Wunsch, aber datenmäßig selten belastbar. Besser: robuste AE + planungsrelevante Trends mit Unsicherheit und Policy-Regeln.

Implementierungs-Checkliste (kompakt)

  • Sensorik

  • Montagekonzept schriftlich fixieren; Fotos, Drehmoment, Kleber, Position.

  • Abtastrate und Filterkette je Asset-Typ definieren; Anti-Aliasing verifizieren.

  • Tachogeber wo Drehzahl variiert.

  • Zeit & Daten

  • PTP einführen, Monitoring; Timestamps an der Quelle.

  • Data Contracts erzwingen; Pakete mit fehlender Metadaten disqualifizieren.

  • Ringpuffer und Pre-Trigger implementieren.

  • Labeling

  • Einheitliche Event-Codes; Zuordnungsfenster definieren.

  • “Gesund”-Fenster kuratieren; Inspektionsdaten konsequent kennzeichnen.

  • Modelle

  • Start mit AE auf interpretierten Features; Hysterese, Last/RPM-Konditionierung.

  • RUL nur nach Proof, dass monotone Degradation messbar ist und Historie existiert.

  • Betrieb

  • Drift-Monitoring; Sensor-Health-Score einführen.

  • Canary-Rollouts; On-Prem-Observability und Audit-Trails.

  • Integration in CMMS: Alarme erzeugen Work-Orders mit Kontext, nicht nur E-Mails.

Mein Standpunkt zu Souveränität und Architektur

  • Rohwellenformen gehören nicht in die Public Cloud. Sie sind sensibel, groß und ohne Kontext kaum nutzbar. Edgebasierte Vorverarbeitung mit on-prem Speicherung ist der vernünftige Standard.

  • DSGVO und Exportkontrollen in Industrie/Verteidigung sind nicht verhandelbar. Systeme müssen auditierbar und betreibbar sein – nicht “API-abhängig”.

  • PdM ist ein Langstreckenlauf: Stabilität der Daten und Betrieb sind wichtiger als das nächste SOTA-Paper.

FAQ

Frage: Wie bestimme ich die richtige Abtastrate für Vibrationen?
Antwort: Starten Sie von den physikalischen Frequenzen. Für Lagerdiagnostik liegen relevante Hüllkurvensignale oft zwischen 2–10 kHz. Mit Anti-Aliasing-Filter sollten Sie mindestens das Doppelte bis Vierfache der höchsten interessierenden Bandgrenze abtasten (Nyquist plus Sicherheitsfaktor), in der Praxis 12,8–25,6 kHz. Wenn Sie Order-Tracking nutzen, zählen Ordnungen relativ zur Drehzahl: Sie benötigen genügend Auflösung, um die höchste relevante Ordnung stabil zu trennen. Ohne Tachogeber verschlechtert sich die erforderliche Rate, weil Sie Drehzahlschwankungen im Signal “miterfassen” müssen.

Frage: Brauche ich zwingend einen Tachogeber?
Antwort: Bei variabler Drehzahl: Ja, wenn Sie saubere Ordnungsmerkmale wollen. Ohne Tachogeber verschmiert die Energie über Frequenzbins; Unwucht, Ausrichtfehler und Zahneingriffsfehler lassen sich schlechter von Lagerdefekten trennen. Für konstante Drehzahl mit geringer Varianz kann man ihn weglassen, aber jede spätere Prozessänderung (neue Rezepte, andere Last) bricht das Modell.

Frage: Wie viele Fehlerfälle brauche ich für ein RUL-Modell?
Antwort: Für ein robustes, typübergreifendes RUL-Modell benötigen Sie pro Failure Mode idealerweise Dutzende vollständige Lebensläufe, mit konsistenter Sensorik und Labels. In vielen Fabriken/Zügen gibt es pro Jahr nur wenige echte Ausfälle. In solchen Settings funktioniert AE mit Trendanalyse oft deutlich besser. RUL kann später folgen, wenn genug Historie vorliegt und ein monotones Degradationssignal nachweisbar ist.

Frage: Wie gehe ich mit Konzept-Drift und Prozessänderungen um?
Antwort: Trennen Sie Sensor-Drift (Kalibrierung, Montage, Elektrik) von Prozess-Drift (neue Produkte, Lastprofile). Führen Sie:

  • Sensor-Health-Scores (SNR, Rausch-Floor, Offsets).

  • Operating-Window-Checks (RPM-, Load-Verteilungen).

  • Periodische Rebaselining-Phasen für AE (aktualisierte “gesund”-Fenster).

  • Versionsierung von Feature-Pipelines und harte Stopps bei Metrik-Degradation ein.

Ohne Governance werden Modelle stillschweigend schlecht.

Frage: Edge- vs. Server-Inferenz – wo rechne ich was?
Antwort: Hochfrequente Vorverarbeitung (Hüllkurve, Ordnungen) und leichte AE lokal an der Maschine; das reduziert Bandbreite und Latenz. Komplexere Analysen, Retraining und Flottenvergleiche laufen on-prem im Werk- oder Depotrechenzentrum. Halten Sie Rohfenster lokal gepuffert und übertragen Sie nur bei Events/periodisch in das zentrale Archiv. So bleiben Sie souverän und effizient.

Schluss
PdM gelingt nicht mit einem “besseren Algorithmus”, sondern mit einem sauberen technischen Fundament: passende Sensorik, harte Data Contracts, zuverlässige Zeitbasis, disziplinierte Labels und eine Architektur, die Edge-Verarbeitung mit on-prem Governance verbindet. Erst dann lohnt die Frage, ob Anomalieerkennung genügt oder RUL-Prognosen belastbar sind. Wer das beherzigt, reduziert Fehlalarme, erkennt echte Defekte früher und – vor allem – baut ein System, das in der rauen Industrieumgebung stabil läuft. Wenn Sie das systematisch aufbauen wollen, ohne Ihre Datenhoheit aus der Hand zu geben: Wir bauen solche Systeme Ende-zu-Ende, on-premise, mit klaren technischen Verträgen statt vager Versprechen. (→ alpitype.de/leistungen/)