Edge-Inferenz in der Predictive Maintenance: Warum das Modell an die Maschine gehört – und wann nicht

Problem: Warum Cloud-first-PdM in der Praxis scheitert
Predictive Maintenance wird oft mit einem einfachen Bild verkauft: Sensoren senden Rohdaten in die Cloud, dort rechnet ein großes Modell, und zurück kommt ein Wartungstermin. In der Praxis scheitert dieser Ansatz an drei Stellen:

1) Bandbreite und Kosten

  • Vibration: Ein 3-Achsen-Beschleunigungssensor mit 24 kHz Sampling, 16 Bit, produziert rund 24.000 Samples/s × 3 Achsen × 2 Byte ≈ 144 kByte/s pro Sensor. Bei 50 Sensoren an einer Linie sind das >7 MByte/s kontinuierlich. Über ein normales Werksnetz ist das noch beherrschbar, aber dauerhaft in eine Cloud zu schieben, frisst Budget und erzeugt Latenzen. In der Bahn (Fahrzeug-zu-Land über 4G/LTE) ist es schlicht unrealistisch.

  • Stromaufnahme (MCSA) und Akustik sind in ähnlichen Größenordnungen. Ohne Vorverarbeitung werden Millionen nutzloser Normalzustands-Samples verschickt.

2) Latenz und Verfügbarkeit

  • Viele PdM-Signale sind drehzahl- oder lastabhängig. Wichtige Ereignisse (z. B. Impulsfolge eines beginnenden Lagerrisses) dauern Millisekunden. Wenn der Trigger in der Cloud liegt, ist das Ereignis vorbei, bevor jemand es bemerkt. In der Textilfertigung saßen wir genau auf diesem Problem: sporadische Rollerflatter-Ereignisse waren 30–50 ms lang – mit Pufferung und Upload kam die Auswertung Sekunden später. Nicht brauchbar.

  • In der Bahn ist die Verfügbarkeit begrenzt: Tunnel, Grenzübertritte, Funklöcher. Eine Cloud-zentrierte Auswertung führt zu Lücken genau dann, wenn reale Anomalien auftreten (z. B. Schlagstellen).

3) Governance und Souveränität

  • Im industriellen Kontext ist „Maschinendaten sind doch unkritisch“ naiv. Vibrationsspektren, Ströme, Taktdiagramme bilden Prozess-Know-how ab. DSGVO mag nur am Rand greifen, aber IP-Schutz und NIS2/Critical-Infrastructure-Anforderungen schon. Viele Betreiber wollen oder dürfen Produktionsdaten die Anlage nie verlassen lassen – Cloud fällt damit aus. On-Premise ist kein Nice-to-have, sondern Anforderung.

Kurz: Reine Cloud-PdM ist in Fertigung und Bahn meist ein teurer Telemetriesammler mit schlechter Erkennungsleistung. Produktionsreif wird es erst mit Edge-Inferenz und einer klaren Steuerung, welche Daten wann wohin gehen.

Lösung: Eine edge-zentrierte, hybride Architektur
Das funktionierende Muster in Projekten sieht so aus:

1) Datenerfassung an der Maschine (Edge)

  • Sensorik: Industrie-IEPE-Beschleunigungssensoren (z. B. 10 kHz–51,2 kHz), Stromzangen oder Shunts für Phasenströme, Temperatur (PT100/DS18B20), optional Tacho/Encoder für ordersynchrone Analysen.

  • Zeitbasis: PTP oder NTP mit Monitoring. Bei mehreren Sensoren an einer Maschine: Hardware-getriggerte, gemeinsame Abtastung oder zumindest gemeinsame PPS/Triggerleitung. Ohne saubere Zeitbasis ist jede spektrale Diagnostik wackelig.

  • Anti-Aliasing: Analogfilter vor ADC, digitaler Guard (z. B. digitale Butterworth 5. Ordnung). Wir sehen regelmäßig alias-bedingte Phantomfrequenzen in PoCs, die später im Feld kollabieren.

  • Puffer: Ringpuffer im Edge-Agent (RAM) für 10–60 s Rohdaten pro Kanal, plus Rolling-Window-Statistiken. Rohdaten werden nur rund um Events persistiert (vor/nach Trigger), nicht permanent.

2) DSP + Inferenz am Edge

  • Signalverarbeitung:

  • Vibration: Windowing (Hann), FFT (2048–8192 Pt), Envelope-Detektion, bandbegrenzte RMS, Crest-Factor, Kurtosis, Ordnungsanalyse (order tracking) bei variabler Drehzahl, Spectral Kurtosis für Impulsfundstellen.

  • MCSA (Motorstrom): Grundschwingungssperre, Park/Clarke-Transformation, Harmonische, Sidebands zur Fehleridentifikation (Rotor-/Stator-Ungleichgewichte).

  • Temperatur/Strom langsam: Exponentiell gleitende Mittelwerte, Trend- und Drift-Schätzer, saisonale De-Trends pro Schicht/Los.

  • Modelle:

  • Anomalieerkennung: One-Class SVM, Isolation Forest, Autoencoder (1D-CNN/LSTM) für maschinenspezifische Normalmodelle.

  • Klassifikation: Leichte 1D-CNNs für spezifische Fehlerbilder (z. B. Lagerinnenring vs. Außenring), Gradient Boosted Trees auf Hand-Features.

  • RUL grob vor Ort: Zustandsindex + Trendextrapolation (z. B. ARIMA/ETS) oder simple Stückweise-linear-Modelle; die feinere RUL-Schätzung erfolgt zentral.

  • Laufzeitumgebungen:

  • x86/ARM-IPC: ONNX Runtime, OpenVINO, TensorRT (Jetson), TFLite.

  • MCUs: TFLM nur für sehr einfache Logik (wir nutzen das selten für PdM, eher als Pre-Trigger).

  • Quantisierung: INT8 für CNNs ist in 80% der Fälle ausreichend, wenn quant aware trainiert. Vorteile: 2–4× schneller, 50–75% weniger RAM. Bei sehr impulsdominierten Signalen auf SNR achten.

  • Ressourcenbudget: Zielwerte unter 50 ms pro 1 s Fenster auf einem ARM A53 Quad-Core, <2 W zusätzliche Leistungsaufnahme. Das ist erreichbar mit 1D-CNNs (<200k Parameter) + FFT durch FFTW/PFFFT.

3) Ereignis- und Datenstrategie (Data Triage)

  • Kontinuierliche Health Scores und Summary Stats (z. B. je 1–5 s) werden an die Zentrale übertragen.

  • Rohdaten werden nur bei Triggern (Schwellwerte, z-Score, Change-Point, ML-Score) persistiert: z. B. 5 s vor bis 5 s nach Event. Zusätzlich: 1% Sampling des Normalzustands für Drift-Analyse.

  • Protokolle: MQTT (QoS1) vom Edge zu einem lokalen Broker, optional OPC UA Server auf dem Edge für SCADA/PLC-Integration. TLS mit mTLS und werksinterner CA.

4) Zentrale On-Premise-Instanz

  • Timeseries- und Feature-Store: TimescaleDB oder InfluxDB für Health/Feature-Zeitreihen; Rohdaten im Objekt-Storage (MinIO/S3, Ceph). Metadata/Konfiguration in PostgreSQL.

  • Training/Refit: GPU ist selten nötig; CPU-Training reicht für 1D-CNNs mittlerer Größe. Versionierte Datasets (Delta/Parquet) und Feature-Pipelines (Feast/Feature-Registry) beschleunigen Refits.

  • Modellverwaltung: Signierte Modelldateien (Ed25519), SBOM für Runtimes, Kompatibilitätsmatrix (Board/OS/Treiber) – Update nur, wenn Prüfungen bestehen. Canary-Ringe: 5% Maschinen, dann 25%, dann 100%.

  • Drift-Überwachung: PSI/JS-Divergenz auf Features, AUC/PR bei gelabelten Events, „Silence-Alarm“ (keine Events über X Tage kann schlecht sein). Automatisierte Rückroll-Regeln.

  • Integration CMMS/ERP: Ereignis → Rule Engine → Wartungsvorschlag mit Maschine/Bauteil/Vermutungsgrad/Frist → Ticket im CMMS via REST/SOAP oder via Message Bus (MQTT/AMQP) → bidirektionales Feedback (Workorder abgeschlossen, Befund). Nur so entsteht ein Label für spätere Trainings.

5) Update- und Betriebskonzept für Edge

  • OTA-Updates: Container-Images (Docker/containerd) aus der On-Prem-Registry, signiert. Für Air-Gap: signierte Update-Pakete auf Wechseldatenträger.

  • Ressourcenisolierung: CPU-Pinning für FFT/NN-Threads, I/O-Priorisierung, Watchdogs. Keine unkontrollierte Python-Umgebungen auf Edge – stabiler sind statische Binaries (C++/Rust) für die heiße Schleife; PyTorch nur in einem klar gekapselten Prozess.

  • Observability: Edge sendet Heartbeats, CPU/RAM/NAND-Wear, Sensorausfälle. Zentral: Flotten-Übersicht und Alarmkonsolidierung.