4) Feature- und Labeling-Layer (Ground Truth ohne Wunschdenken)

  • Last- und Kontext-Normalisierung:

  • Fenster nur unter vergleichbaren Betriebszuständen vergleichen (Drehzahl ±1%, Lastbänder). Ohne das ist jeder Trend beliebig.

  • Label-Pipeline:

  • CMMS/ERP-Integration: Asset-ID-Mapping, Wartungs-/Tauschereignisse mit Zeitfenster und Komponentenbezug.

  • Weak Supervision: Regelbasierte Label-Funktionen (z. B. “Peak bei BPFO+Sidebands + Temperaturanstieg > X => Lageraußenring-Schaden-Kandidat”), die zu Kandidatenlabels führen, die Techniker freigeben.

  • Zensierungslogik: Opportunistische Tausche als “rechts-zensiert” markieren; Überlebensanalyse-geeignete Labels getrennt halten.

  • Datenqualitätstests:

  • Spektrale Flatness und Noise-Floor-Schwellen zur Erkennung gelöster Sensoren.

  • Timestamp-Monotonie, Sample-Count-Kohärenz, Abtastrate-Abweichung < 100 ppm.

  • Drift-Detektion (Population-Shift) auf Features, täglich/wöchentlich.

Modellwahl: Anomalieerkennung zuerst, RUL später – und nur mit guten Labels

  • Start mit Anomalieerkennung:

  • Gründe: Instandhaltungsdaten sind anfangs spärlich und ungenau. Unsupervised/Self-Supervised-Modelle (z. B. Isolation Forest, Autoencoder) auf lastnormierten Feature-Vektoren funktionieren früh und lassen sich schnell in Wartungsprozesse integrieren (Alarm → Sichtprüfung → Label).

  • Vorteil: Geringe False-Negative bei gutem Feature-Set; erklärt sich über Feature-Beiträge und spezifische Frequenzbänder.

  • Fehlerklassen-Modelle:

  • Wenn 50–100 bestätigte Fälle pro Ausfallmodus vorliegen und die Lastkontexte sauber sind, lohnt sich Supervised Learning (Gradient Boosting, leichte CNNs auf Spektren).

  • Feature-Importance und SHAP für Techniker-Akzeptanz.

  • RUL (Remaining Useful Life):

  • Nur mit konsistenter Zensierungsbehandlung und ausreichend Ausfällen. Survival-Modelle (Weibull, Cox) oder Deep Survival, gefüttert mit trendenden Health-Indizes. Für viele Flotten besser: “N-of-1”-Trends + Schwellwert statt präziser RUL-Zahl mit falscher Sicherheit.

  • Edge vs. Zentrale Inferenz:

  • Edge: Latenzkritische Alarme, begrenzte Bandbreite, Datenhoheit. Modelle als ONNX/TFLite, quantisiert. Update über signierte Bundles.

  • Zentral: Modelltraining, Flotten-Benchmarks, Root-Cause-Analysen.

Trade-offs: Was man gewinnt und was man aufgibt

  • Hohe Abtastraten vs. Speicher/Bandbreite:

  • Gewinn: Diagnoseschärfe (Lager, Getriebe). Preis: Mehr Edge-CPU, Rohdaten nur selektiv speicherbar.

  • Strikte Datenverträge vs. Flexibilität:

  • Gewinn: Reproduzierbarkeit, wartbare Pipelines. Preis: Höhere Anlaufkosten, stärkere Disziplin an der Linie.

  • Edge-Feature-Extraktion vs. reine Rohdatenspeicherung:

  • Gewinn: 10–100x weniger Datenvolumen, Echtzeitfähigkeit. Preis: Muss robust implementiert und versioniert werden; Fehler in der Vorverarbeitung schlagen direkt durch.

  • Anomalie-First vs. frühe RUL-Prognose:

  • Gewinn: Schnell Nutzen, weniger Labelbedarf. Preis: Weniger planungsgenaue Aussagen (Kalenderdatum). RUL lohnt erst später – realistisch kommunizieren.

  • PTP-Zeitsync vs. “Good Enough”-NTP:

  • Gewinn: Sichere Zuordnung über Sensoren/Assets hinweg, saubere Ordnungsspektren. Preis: Netzwerkinfrastruktur und Know-how.

Praxis: Drei Szenarien aus Textil, Bahn und Fertigung
1) Textilfertigung – Hochgeschwindigkeitswebmaschinen

  • Ausgangslage: POC mit 1 kHz Vibration, Magnetfüßen, nur RMS/Peak pro Minute gespeichert. Keine Korrelation mit Stillständen.

  • Problem: Keine diagnostische Information über Lagerdefekte; Peaks im niederfrequenten Bereich waren rein lastgetrieben.

  • Umbau:

  • Mechanische Montage auf blankem Gehäuse, M5, Drehmoment nach Datenblatt.

  • IEPE-Sensoren, 48 kHz Sampling, analoges Anti-Aliasing. Tacho an Hauptwelle.

  • Hüllkurvenspektren am Edge berechnet, nur 2×10 s Rohdaten pro Stunde + Events gespeichert. PTP-Zeitbasis.

  • Ergebnis:

  • Deutliche BPFO/FTF-Peaks mit Sidebands sichtbar. Frühwarnzeit vor Lagerausfall von 0 auf 3–6 Wochen.

  • Datenvolumen pro Maschine: von ~30 GB/Tag roh auf ~1–2 GB/Tag (selektive Rohdaten + Features) reduziert.

  • Falschalarme sanken um >50%, nachdem Sensor-Health-Kontrollen lose Verschraubungen detektierten.

2) Bahn – Traktionsmotoren, Stromsignaturanalyse

  • Ausgangslage: Versuche, via SCADA-Stromwerte (1 Hz, Mittelwert) Fehler zu erkennen. Keine Signatur sichtbar, CMMS-Meldungen grob.

  • Umbau:

  • 5 kHz Abtastrate je Phase, kalibrierte Hall-Sensoren nahe am Inverterausgang. PTP über Fahrzeugnetz mit Grandmaster.

  • Feature-Set: Sidebands um 50 Hz und Grundschwingungen, Slip-basierte Frequenzen, THD, Oberwellenstruktur pro Betriebszustand (Anfahren, Reise, Rekuperation).

  • Label-Pipeline über Werkstattmeldungen, manuelle Verfeinerung durch Flotteningenieure.

  • Ergebnis:

  • Frühindikatoren für Isolationsschwächen und Lagerschäden in Stromsignatur 1–4 Wochen vor auffälligem Geräuschbild.

  • Akzeptanz durch Instandhaltung dank erklärbarer Frequenzbänder und verlinkter Rohsegmente.

3) Allgemeine Fertigung – Kompressoren

  • Ausgangslage: Temperaturfühler am Gehäuse, Alarme bei >70°C. Viele False Positives bei Sommerhitze/Lastspitzen.

  • Umbau:

  • Zweiter Fühler für Umgebungstemperatur; Lastsignal aus PLC; Feature “DeltaT normiert auf Last” + Trend.

  • Einfache Zustandsmodelle (Regressionsresiduum) statt fixer Grenzwerte.

  • Ergebnis:

  • False Positives um ~80% reduziert; echte Überhitzungen (verstopfte Kühllamellen) erkannt, bevor Abschaltungen nötig waren.

Konkrete Implementierungs-Checkliste

  • Mechanik

  • Sensor-Montageplan je Asset mit Fotos, Drehmoment, Ausrichtung, Ersatzsensor-IDs.

  • Überprüfung: Frequenzgangstest am eingebauten Sensor (Klopftest/Impuls), Dokumentation Noise-Floor.

  • Edge

  • PTP einführen, DAQ mit verlässlicher Taktquelle, Anti-Aliasing vor ADC.

  • Ringpuffer und Event-Trigger implementieren; Edge-Feature-Bibliothek versionieren und testen.

  • Datenverträge

  • Schema mit Einheiten/Orientierung/Abtastrate und Metadaten. Validierung in der Ingestion-Pipeline.

  • Asset-Stammdaten aus ERP/PLM konsolidieren (Lager/Antrieb/Gearbox).

  • Storage und Compute (On-Prem)

  • Objektspeicher (MinIO), TimescaleDB/Postgres, Message Bus. Zugriffsschichten klar trennen.

  • Retention-Strategie pro Asset-Kritikalität.

  • Labeling

  • CMMS-Integration; Pflichtfelder für Komponententyp, Uhrzeit, Ursache. Weak-Supervision-Regeln und Review-Workflow.

  • Betrieb/Qualität

  • Sensor-Health-Dashboards; tägliche Drift-Checks; Release-Prozess für Edge-Feature-Updates.

  • Security: Netzwerksegmente, SBOM, signierte Artefakte, Offlinenutzung möglich (→ alpitype.de/leistungen/).