Konkrete technische Bausteine, die sich bewährt haben

  • Feature-Engineering:

  • Vibrationen: RMS, Peak-to-Peak, Crest, Kurtosis; spektrale Bandenergien um Lagerkennfrequenzen; Hüllkurvenanalyse; Seitenbandamplituden um Ordnungen; spektrale Entropie.

  • Stromaufnahme: Grundwelle, Oberwellenverhältnisse, Seitenbänder; Einschaltstromspitzen; Energie pro Zyklus.

  • Temperatur: ΔT normalisiert auf kW/Last; dT/dt bei Lastwechsel; Sommer/Winter-Baselines.

  • Modusdetektion:

  • Direkte SPS-Signale (Drehzahl, Last); fehlt das, dann Clustering/Hidden-Markov auf einfachen Features (Leistung, Frequenzbänder).

  • Modellierung:

  • Anomalie: One-Class SVM/Isolation Forest als robuste Baseline; Autoencoder bei Sequenzen.

  • RUL: Isotone Regression für Health-Monotonie; Bayesian Filter für Unsicherheit; Survival-Modelle für Zensoren.

  • Deployment:

  • Edge: Containerisiert, ONNX Runtime oder TensorRT, Telemetrie via MQTT. Feature-Pipeline in C++/Rust oder performantem Python mit C-Bindings.

  • Zentral: On-Prem Kubernetes, Timeseries-DB, Feature-Store, Model-Registry; Signierte Artefakte, Rollback-Fähigkeit.

  • Integration:

  • CMMS: REST/OPC UA; eindeutige Asset-IDs, Zeitzonen-/Uhrzeitsync. Ereignisse bidirektional.

  • Governance: Versioniere Feature-Pipelines und Schwellenwerte, nicht nur Modelle. Alarme auditierbar machen (welches Feature, welcher Schwellenwert).

Entscheidungs-Checkliste: In 30 Minuten zur richtigen Strategie

  • Gibt es einen plausiblen, näherungsweise monotonen Degradationsindikator? Wenn nein → Anomalie.

  • Haben wir ≥20 relevante Ereignisse pro Asset-Typ mit verlässlicher Zeitmarke? Wenn nein → Anomalie, parallel Labels sammeln.

  • Ist die Aktion Inspektion akzeptabel und praktikabel? Wenn ja → Anomalie zuerst.

  • Sind Ersatzteil- und Einsatzplanung kritisch (Wochen Vorlauf)? Wenn ja und Daten tragfähig → RUL lohnt sich.

  • Variieren Betriebsmodi stark und schnell? Wenn ja → Modusgetrennte Modelle; Edge-Inferenz bevorzugen.

  • Können wir on-prem/edge betreiben (Souveränität, Latenz)? Wenn nein → Architektur neu denken, aber in regulierten Umfeldern ist on-prem de facto Pflicht.

Was wir konsequent vermeiden

  • RUL ohne Monotonie: Wenn der Health-Index nicht monoton ist, ist jede Lebensdauerzahl Marketing.

  • Mischmoden-Training: Ein Modell für allen Betrieb führt zu Drift und Alarmmüdigkeit.

  • Alarme ohne Integration: Ein E-Mail-Alarm ist kein PdM-System.

  • Cloud-only in Bahn/Fertigung: Wenn Connectivity/Compliance nicht garantiert ist, ist das ein Architekturfehler, kein Betriebsproblem.

FAQ
1) Wir haben nur wenige Ausfälle. Lohnt sich RUL überhaupt?

  • In der Regel nein. Starten Sie mit moderater Anomalieerkennung, sammeln Sie strukturierte Befunde im CMMS, und prüfen Sie nach 6–12 Monaten, ob ein stabiler Degradationsindikator vorliegt. Ohne Monotonie und ausreichende Ereignisse bleibt RUL eine Schätzung mit fragwürdiger Kalibrierung.

2) Wie gehe ich mit zensierten Daten (präventive Wechsel) bei RUL um?

  • Nutzen Sie Survival-Methoden, die Zensoren korrekt in die Likelihood integrieren, oder Bayes’sche State-Space-Modelle mit teilweiser Beobachtung. Kennzeichnen Sie jeden präventiven Wechsel sauber und nutzen Sie ihn trotzdem zur unteren Schranke der Lebensdauer.

3) Wie verhindere ich Alarmfluten bei wechselnden Betriebsmodi?

  • Erkennen und trennen Sie Modi explizit. Trainieren Sie pro Modus eigene Normalmodelle/Schwellenwerte. Nutzen Sie drehzahl-/lastnormierte Features (Order-Tracking). Führen Sie Score-Glättung und Mehrfachbestätigung ein.

4) Was läuft am Edge, was zentral?

  • Am Edge: Feature-Extraktion, Modusdetektion, Anomalie-Inferenz, lokale Pufferung. Zentral/on-prem: Flottenaggregation, RUL-Berechnung, Modellkalibrierung, Governance, CMMS-Integration. So behalten Sie Latenz niedrig und Souveränität hoch.

5) Welche Metriken überzeugen die Instandhaltung?

  • Für Anomalie: Weniger als 1 Fehlalarm pro 500–1000 h und Maschine/Subsystem; mediane Vorwarnzeit vor Ereignis. Für RUL: MAE <20 % des Prognosehorizonts in den letzten 30 Tagen und kalibrierte Konfidenzintervalle. Dazu klare, maschinenlesbare Arbeitsaufträge im CMMS.

Schluss
Predictive Maintenance ist kein Algorithmuswettbewerb, sondern ein Engineering-Problem an der Schnittstelle von Physik, Datenarchitektur und Instandhaltung. Wer zwischen Anomalieerkennung und RUL sauber unterscheidet, die Betriebsmodi ernst nimmt und on-prem/edge-first denkt, bekommt robuste Systeme in Produktion – nicht nur hübsche POCs. Wenn Sie diese Architektur in Ihrem Umfeld aufbauen wollen, aber keine Zeit für Trial-and-Error haben, sprechen Sie uns an. Wir bauen produktionsreife Systeme mit klarer Verantwortlichkeit, nicht PowerPoint-Prototypen. (→ alpitype.de/leistungen/)