Edge-Inferenz in der prädiktiven Wartung: Wann gehört das ML-Modell an die Maschine – und wann nicht?

Problem: Warum Cloud-zentrierte PdM-POCs im Feld scheitern
Die meisten PdM-POCs werden im Labor oder in einer Cloud-Umgebung gebaut, auf kurzen, sauberen Datenstrecken validiert und dann in der Realität von Industrie-IT und Anlagenbetrieb zerrieben. Drei Gründe tauchen immer wieder auf:

1) Bandbreite und Latenz werden falsch eingeschätzt:

  • Ein einzelner 3-Achsen-Vibrationssensor mit 25,6 kHz und 24 Bit Auflösung liefert ca. 0,5 MB/s Rohdaten. 50 Maschinen mit je 2 Sensoren erzeugen ~50 MB/s, das sind über 4 TB pro Tag. Das schiebt niemand zuverlässig durch ein Produktionsnetzwerk – und schon gar nicht über WAN in eine Cloud.

  • Prozess- und Sicherheitsanforderungen verlangen Reaktionszeiten unter 100 ms (Alarmausgabe, geregelter Stopp). Eine Cloud-Runde mit WAN-Jitter und TLS-Handshakes sprengt dieses Budget.

2) Die Realität ist nicht „always online“:

  • Im Bahnbetrieb ist LTE in Tunneln und Tälern weg; WLAN gibt es nur im Depot. Im Werk sind Produktionszellen oft segmentiert (IEC 62443), Air-Gaps sind keine Seltenheit. Ein Cloud-only-Entwurf stirbt am ersten Netz-Change.

3) Datensouveränität und Integrationen werden zu spät gedacht:

  • Produktionsdaten, Zustandsdaten und teils auch personenbezogene Kontextdaten (Schicht, Bedienereingriffe) unterliegen strengen Vorgaben. Ein US-Cloud-Stack scheidet in vielen Fällen schon aus Governance-Gründen aus.

  • PdM erzeugt keinen Nutzen ohne Aktion: CMMS/ERP müssen Work Orders verlässlich anlegen. Viele POCs enden in einem hübschen Notebook, aber ohne rückgekoppelte Instandhaltungsprozesse.

Das Ergebnis: Tolle ML-Demos, aber kein stabiler Feldbetrieb. Genau hier entscheidet Edge-Inferenz – also ML direkt an der Maschine oder im Anlagen-Netz – über Erfolg oder Misserfolg.

Lösung: Eine Edge-first-Referenzarchitektur für PdM
Die zentrale Frage ist nicht „Edge oder Cloud?“, sondern: Welche Verarbeitungsschritte müssen deterministisch, latenzarm und souverän vor Ort passieren, und was gehört ins zentrale (on-prem) Backend? Praxiserprobt hat sich das folgende Muster.

1) Sensorik richtig dimensionieren (sonst hilft die beste KI nicht)

  • Vibration: IEPE oder robuste MEMS, mechanisch starr montiert (kein Magnet bei Hochfrequenzdiagnosen), korrekte Anzugsmomente, Anti-Alias-Filter, Abtastraten passend zu Schadensfrequenzen. Für Lagerdiagnosen an Hochdrehzahlspindeln sind 25,6–51,2 kHz üblich.

  • Stromaufnahme (MCSA): Stromwandler/Spannungsteiler an Antrieben; Abtastung im Bereich 5–20 kHz zur Erkennung von Schlupf-/Seitenbändern.

  • Temperatur/Prozess: niedrigfrequent, wichtig für Kontext (Last, Umgebung).

  • Drehzahlerfassung: Tacho/Encoder sind Pflicht, sobald Drehzahl variiert. Ohne Ordnungsanalyse sind Spektren in der Praxis kaum interpretierbar.

2) Edge-Hardware: robust, vorhersagbar, administrierbar

  • Plattformen: lüfterlose x86/ARM-Boxen, Hutschienen-PCs; für Bahn nach EN 50155 (Schock, Vibration, Temperatur), für Fertigung mit Schutz vor EMV und Staub.

  • Betriebssystem: Linux LTS, Real-Time-Kernel nur bei harten Latenzanforderungen.

  • Containerisierung: Docker/Podman; im Feld hat sich K3s/Kubernetes light bewährt, wenn mehrere Dienste (Collector, Feature-Engine, Inferenz, Watchdog) sauber entkoppelt laufen sollen. Alternativ systemd-Native-Services für minimalen Stack.

  • Zeit: PTP/NTP sauber aufsetzen. Ohne konsistente Zeitstempel ist jede Multisensor-Korrelation wertlos.

  • Beschleuniger: CPU reicht in 80% der PdM-Fälle. GPU/NPU nur bei komplexer Deep-Learning-Inferenz (z. B. Rohsignal-2D-Spektrogramm-CNNs) oder bei hoher Kanalzahl. Wenn GPU, achten Sie auf Thermik und deterministische Performance.

3) Edge-Datenpfad: vom Rohsignal zur robusten Gesundheits-KPI
Ein deterministischer Streaming-Pfad ist wichtiger als ein komplexes Modell.

  • Ingestion:

  • Industrielle Protokolle: OPC UA, Modbus/TCP, PROFINET, CAN; für Rohsignale nutzen wir dedizierte DAQ-Karten oder ADC-Module mit PTP-Unterstützung.

  • Lokaler Message-Bus (z. B. NATS oder MQTT) zwischen Diensten, damit nichts „hart“ gekoppelt ist.

  • Feature-Engineering am Edge:

  • Windowing mit Hamming/Hanning, 1–5 s Fenster, 50–75% Overlap, je nach Phänomen.

  • Spektrale Features: FFT, Ordnungsanalyse (Resampling auf Winkel), Envelope-Demodulation für Lager, spektrale Kurtosis für impulsive Ereignisse, Crest-Faktor, RMS, Peak-to-Peak, harmonische Seitenbänder bei MCSA.

  • Trend-Features: exponentielle Glättung, Rolling-Stats, Persitenzmetriken über N Zyklen.

  • Kontexteinbindung: Last, Temperatur, Drehzahl als erklärende Variablen.

  • Inferenz:

  • Anomalieerkennung für unbekannte Fehler: z. B. Isolation Forest, One-Class SVM, Autoencoder (klein, quantisiert). Vorteil: funktioniert mit wenig Labeln. Nachteil: Erklären und Alarmschwellen sauber kalibrieren.

  • Klassifikation bekannter Defekte: Gradient Boosted Trees (XGBoost/LightGBM) mit handgebauten Features sind am Edge oft robuster als große CNNs auf Spektrogrammen.

  • RUL (Remaining Useful Life): Nur, wenn ausreichend Verlaufsdaten über Ausfälle/Überholungen vorliegen. Sequenzmodelle (survival regression, Cox-Varianten, probabilistische State-Space-Modelle) laufen edge-tauglich, wenn Feature-Sets klein bleiben. Sonst RUL serverseitig berechnen und am Edge nur Health Indices anstellen.

  • Output:

  • Eine kleine Zahl stabiler KPIs: Health Index (0–1), Anomalie-Score, pro-Fehlerart Score, Konfidenz.

  • Event-Kompression: Nur bei Grenzwertverletzung Rohdaten-Ringpuffer ±30–60 s persistieren und später synchronisieren. Das spart 99% Bandbreite.

4) Kommunikations- und Speicherstrategie: souverän und fehlertolerant

  • Store-and-forward: Lokaler Timeseries-Store (z. B. SQLite/Parquet + Metadaten) puffert Tage bis Wochen. Synchronisierung asynchron via MQTT/Kafka zu einem on-prem Broker. Keine Cloud-Abhängigkeit.

  • On-prem-Backend:

  • Message-Broker (Kafka/Redpanda/MQTT) als Rückgrat.

  • Time-Series-DB (TimescaleDB/InfluxDB) für KPIs.

  • Objektspeicher (S3-kompatibel, on-prem) für Ereignis-Rohdaten.

  • Feature- und Modell-Registry, MLOps-CI/CD, Dashboards.

  • Sicherheit:

  • Gerätezertifikate (TPM), signierte Container/Modelle (Sigstore), Mutual TLS, rollenbasierte Autorisierung.

  • Segmentierung nach IEC 62443: Edge-Geräte in eigene Zonen, nur ausgehende Verbindungen zum Broker.