Predictive Maintenance scheitert an der Verschraubung: Datenqualität für Vibration, Temperatur und Strom in der Praxis richtig aufbauen

Problem: Warum PdM-Projekte in der Produktion oft schon vor dem ersten Modell scheitern
Die meisten gescheiterten Predictive-Maintenance-Initiativen, die ich in Textilfertigung und Bahn gesehen habe, hatten kein Modellproblem, sondern ein Physikproblem. Typische Muster:

  • Falsche Sensorik oder falsche Montage: Beschleunigungssensoren auf lackierten Gehäusen mit weichem Klebepad statt starrer Montage; Temperaturfühler in Luft statt am Lager; Stromzangen ohne Kalibrierung.

  • Abtastrate und Anti-Aliasing ignoriert: 1–2 kHz Sampling bei Wälzlagerdiagnose, obwohl relevante Resonanzen im 3–20 kHz-Bereich liegen. Kein analoges Anti-Aliasing vor dem ADC.

  • Zeitbezug fehlt: PLC-Zustände im 100-ms-Takt, Vibration bei 12 kHz, CMMS-Ereignisse ohne Sekundengenauigkeit. Ergebnis: keine saubere Zuordnung von Lastzuständen zu Signalfenstern, kein Ground Truth.

  • Fehlende Metadaten: Kein Überblick, welcher Lagersatz wann getauscht wurde, welcher Antriebstyp verbaut ist, welche Übersetzung/Wellendrehzahl anliegt. Modelle “sehen” Mischpopulationen ohne Kontext.

  • Labelrauschen aus dem CMMS: “Fehlercode 17 – Antrieb defekt” für fünf unterschiedliche Ausfallmodi. Opportunistische Tauschaktionen erzeugen zensierte Daten (Komponenten getauscht, bevor sie ausgefallen sind).

  • Bandbreite/Storage falsch dimensioniert: Entweder wird Rohsignal permanent in Gigabyte/Tag weggeschrieben (unbezahlbar), oder es wird so aggressiv aggregiert (RMS pro Minute), dass keine Diagnose mehr möglich ist.

  • Kein Sensor-Health-Monitoring: Drift, Entkopplung, lose Schraube – das Modell lernt auf Müll. Nach drei Monaten kippt die Datenbasis und die False-Positive-Rate explodiert.

Wenn Sie eines davon erkennen: Sie brauchen kein neues “besseres” ML-Modell. Sie brauchen ein robustes Datenerfassungs- und Governancesystem, das die Physik der Maschine respektiert und in Ihre On-Prem-IT passt.

Lösung: Referenzarchitektur für PdM-Datenqualität – von der Verschraubung bis zum Feature
Aus der Praxis hat sich eine Architektur bewährt, die vier Ebenen klar trennt: Sensorik & Montage, deterministische Erfassung am Edge, on-prem Datenspeicher mit Datenverträgen, und ein Feature-/Labeling-Layer als Schnittstelle zu Modellen.

1) Sensorik und Montage (Physik zuerst)

  • Beschleunigung (Vibration):

  • Sensor: Piezoelektrische IEPE-Beschleunigungsaufnehmer, 100 mV/g, 10 kHz nutzbares Band (besser 20–30 kHz, wenn Hüllkurvenanalyse geplant).

  • Montage: Metallisch blanke Fläche, plan gefräst; M5/M8-Gewinde mit Drehmoment gemäß Datenblatt; kein Magnetfuß für Dauerbetrieb an Hochfrequenzdiagnosen.

  • Orientierung: Achsen dokumentieren (radial/axial/tangential); Fotos in die Asset-Doku; Richtung im Datensatz als Vektor speichern.

  • Temperatur:

  • Sensor: PT100/RTD mit Federdruckfühler oder Gewindefühler; direkte Ankopplung ans Lagergehäuse; Wärmeleitpaste; thermisch entkoppelte Kabelführung.

  • Sampling: 1–10 Hz reichen; wichtig ist Stabilität und Kalibrierung (Offset/Spanne).

  • Stromaufnahme (MCSA):

  • Sensor: Hall-Effekt-Stromwandler oder Rogowski-Spule mit bekannter Übertragungsfunktion und Kalibration.

  • Montage: Phasenbezug konsistent dokumentieren; möglichst nah an der Maschine (weniger Störeinflüsse).

  • Zusatz: Tacho/Encoder für Order-Tracking (Drehzahl). Ohne stabilen Drehzahlkanal wird Ordnungsspektrumanalyse zum Ratespiel.

2) Deterministische Erfassung am Edge (Sampling, Zeit, Trigger)

  • Sampling-Faustregeln:

  • Wälzlagerdiagnose mit Hüllkurve: 48 kHz oder 96 kHz pro Achse, 24-Bit-ADC, analoges Anti-Aliasing. Fenster 1–4 s, 50% Überlappung.

  • Motorstromanalyse: 5–10 kHz reichen oft; fundamental 50 Hz plus Sidebands, aber Oberwellen und Inverter-PWM erfordern Reserve.

  • Temperatur: 1–10 Hz; Mittelwert/Median über 1–5 s.

  • Zeitbasis:

  • PTP (IEEE 1588) für Sub-Millisekunden-Zeitstempel auf DAQ und Edge-Gateway. NTP genügt für PLC/CMMS, aber nicht für Sensor-Fusion bei schnellen Signalen.

  • Jedes Segment bekommt Startzeit, Abtastrate, Sample-Count; kein “floating time”.

  • Trigger und Puffer:

  • Ringpuffer mit z. B. 30–60 s Rohsignal, permanenter Feature-Stream (RMS, Peak, Kurtosis, Bandenergie, Hüllkurvenspektrum).

  • Ereignisbasierte Rohdatenspeicherung: Rohdaten nur bei Anomalie-Score > Schwellwert, bei Statuswechsel (Last hoch/runter), oder zyklisch (z. B. 10 min pro Schicht).

  • Edge-Compute:

  • Vorverarbeitung: Entzerrung (Sensor- und Antialias-Übertragungsfunktion), DC-Entfernung, Hanning-Fenster, Spektrum (FFT), Hüllkurvenbildung (Bandpass 3–10 kHz + Demodulation).

  • Feature-Extraktion: RMS, Crest-Faktor, Kurtosis, Spectral Kurtosis, Ordnungsbandenergien, Peaks an BPFO/BPFI/BSF/FTF±Sidebands (lagerabhängig), THD, Slip-bedingte Sidebands im Strom.

  • Health-Monitoring: Rauschpegel, SNR, Verschraubungsindikator (Vergleich hochfrequente Flatness), Achs-Korrelation, Offset-Drift bei Temperatur.

  • Datenformate:

  • Rohsignal: segmentierte Parquet/Feather-Dateien mit Spalten (t, ax, ay, az), Metadaten im Footer (Sensor-ID, Kalibrierfaktoren, Montage).

  • Feature-Stream: Pro Fenster JSON/Protobuf mit Versioniertem Schema.

3) On-Premises Datenspeicher und Datenverträge (Souveränität statt Streaming in US-Cloud)

  • Ingestion:

  • gRPC/HTTPS für Bulk-Daten; OPC UA oder MQTT für Zustände (Betriebsart, Last, Störung).

  • Message Bus (z. B. NATS JetStream/Kafka) für asynchrone Verarbeitung, Backpressure und Replays.

  • Speicherung:

  • Rohdaten: On-Prem-Objektspeicher (z. B. S3-kompatibel wie MinIO) in einer Lake-Struktur (asset_id/year/month/day/segment.parquet).

  • Features/Labels/Metadaten: Relationale/Time-Series-DB (TimescaleDB/Postgres), indiziert nach asset_id, window_start, operating_state.

  • Datenverträge:

  • Strikte Schemas mit Einheiten, Abtastrate, Sensor-Orientierung, Kalibrierung, Messkette. Versionierung und Validierung (z. B. pydantic/JSON Schema).

  • Asset-Stammdaten: Lagersatz (Hersteller, Typ, Abmessungen), Übersetzung, Nenndrehzahl, Invertertyp, Tauschhistorie mit Zeitstempeln.

  • Governance:

  • Sensor-Health-Dashboards (Grenzwerte, Drift, SNR-Trends).

  • Auditierbare Daten-Lifecycle-Regeln: Rohdaten-Retention differenziert (kritische Assets 12 Monate, sonst nur Events), Feature-Archive länger.

  • Sicherheit und Betrieb:

  • Netzwerksegmentierung, kein ausgehender Internetzwang.

  • Deployment auf Bare-Metal/Kubernetes On-Prem. DSGVO- und ITAR/BAFA-Sensibilität berücksichtigen. Keine US-Cloud-Abhängigkeit.

  • Wenn LLMs für Textauswertung von CMMS-Notizen genutzt werden: strikt on-prem, abgesicherte Modelle, Observability/Governance (→ alpitype.de/leistungen/).