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

Problem: Warum Cloud‑POCs in der Praxis scheitern
Die meisten Predictive‑Maintenance‑POCs beginnen gleich: Sensordaten in die Cloud streamen, dort Features rechnen und Modelle laufen lassen, Dashboard bauen. Im Labor klappt das. Im Feld bricht es an ganz konkreten Stellen:

  • Bandbreite und Kosten: Rohvibrationen mit 25 kHz Abtastrate und 16 Bit Auflösung von nur vier Achsen bedeuten rund 3,2 MB/s pro Maschine unkomprimiert. Selbst mit Kompression sprengen Wochenpuffer und Mobilfunkkosten schnell jedes Budget. In der Bahn ist LTE/5G entlang der Strecke lückenhaft – im Tunnel hilft die schönste Cloud nicht.
  • Latenz und Robustheit: Entscheidungen, die in Millisekunden bis Sekunden passieren müssen (z. B. Stoppen bei Lagerschaden), dürfen nicht von einer WAN‑Rundreise abhängen. Paketverlust, Roaming, Overhead – in der Realität gibt es immer Lücken.
  • Datensouveränität: Produktionsdaten sind Betriebsgeheimnisse. In Europa fordern viele Werke: keine US‑Cloud, DSGVO‑konform, Offline‑Betrieb möglich, Audit‑fähig. Im Bahnkontext kommen Safety‑Anforderungen und Zulassungsfragen dazu.
  • Signalqualität und Kontext: Vibrationen ohne Betriebskontext (Drehzahl, Last, Temperatur) sind oft nicht interpretierbar. Wer nur “blind” rohes Zeitreihenrauschen hochlädt, bekommt im Training bunte Plots, aber im Betrieb Fehlalarme. Ohne saubere Zeitsynchronisation und Prozessvariablen sind Modelle im Feld nutzlos.
  • Betriebsfähigkeit: Ein PoC‑Skript in einem Notebook ist kein Produkt. Edge‑Geräte brauchen Remote‑Updates, Watchdogs, Log‑Aggregation, Rolling‑Deployments, Rückfall auf alte Modelle – sonst steht die Linie beim ersten Crash.

Aus unseren Projekten in Textilfertigung und Bahn ist die Quintessenz eindeutig: Wenn die Maschine schnell reagieren muss, die Konnektivität unsicher ist oder Datensouveränität Pflicht ist, gehören Feature‑Berechnung und Inferenz an die Maschine. Die Cloud (oder ein zentrales On‑Prem‑Cluster) bleibt Trainings‑ und Flotten‑Management‑Ort – nicht der Hot‑Path der Entscheidung.

Lösung: Eine Edge‑first‑Architektur, die in der Produktion funktioniert
Die Architekturkomponenten, die sich wiederholt bewährt haben, sehen so aus:

1) Datenaufnahme nah an der Physik

  • Sensorik: Beschleunigungsaufnehmer (z. B. IEPE, MEMS), Temperatursensoren (PT100/1000), Stromzangen (MCSA), ggf. Körperschall. Samplingraten je nach Fehlerbild: 5–50 kHz für Lager/ Zahnrad, 1–5 kHz für Stromsignaturen, 1–10 Hz für langsame Prozessgrößen.

  • Zeitsynchronisation: PTP (IEEE 1588) im Maschinen‑LAN wenn verfügbar, ansonsten NTP mit Monotonic‑Clock für lokale Auswertung. Ohne stabile Zeitbasis sind Ordnungsanalyse und Multi‑Sensor‑Fusion wertlos.

  • Kontext: Drehzahl (Inkrementalgeber), Last, Schichtplan, Prozesszustände via OPC UA, Profinet oder Modbus. Für Bahn: Fahrzeugbus (z. B. MVB, CAN/ETH‑Gateway) für Geschwindigkeit und Achslast.

2) Edge‑Vorverarbeitung und Inferenz

  • Vorverarbeitung:

  • Fensterung mit 50–200 ms, Überschneidung 50 %.

  • Zeitsignal‑Features: RMS, Varianz, Crest‑Faktor, Kurtosis, Peak‑to‑Peak, Hüllkurvenanalyse (Demodulation), impulsivitätsbasierte Maße.

  • Frequenzfeatures: Spektrale Bänder (z. B. 1–5 kHz für Lager), Seitenbandenergie, spektrale Entropie, Ordnungsanalyse (Order Tracking) bei variabler Drehzahl.

  • Stromaufnahme: Oberwellenamplituden, Slotting‑Frequenzen, spektrale Asymmetrie.

  • Modellfamilien:

  • Anomalieerkennung: Autoencoder (1D‑CNN oder LSTM‑leicht), Isolation Forest, One‑Class SVM für schnelle Erkennung ohne lückenlosen Labelbestand.

  • Klassifikation spezifischer Fehlerbilder: 1D‑CNN/TCN, Gradient Boosted Trees auf handgemachten Features.

  • RUL‑Schätzung: Nur, wenn ausreichend Degradationsverläufe vorhanden sind; andernfalls lieber Zustandsklassen und Trendbewertung.

  • Inferenz on device:

  • Zielbudget auf gängigen Edge‑Rechnern (ARM Cortex‑A53/A72, x86 Industrial PC): <15 % CPU pro Kanal bei 10 kHz, Latenz <200 ms vom Fensterende bis zur Entscheidung.

  • Quantisierung (INT8) spart 2–4x CPU; OnnxRuntime, TensorRT, OpenVINO oder TFLite sind praxistauglich.

  • Containerisiert (Docker/Podman), Supervisor/Watchdog, lokaler Ringpuffer für Rohfenster (z. B. 60–120 s) zur forensischen Sicherung bei Alarm.

3) Ereignisgesteuerter Uplink statt Dauerstreaming

  • Normalbetrieb: Nur verdichtete Metriken (Feature‑Statistiken, Scores, Health‑Index) im Sekund‑ bis Minutenraster via MQTT/AMQP an einen zentralen Broker.

  • Ereignisse: Bei Schwellenübertritt oder starkem Trend Rohfenster für T+/-10 s puffern und komprimiert übertragen – wenn Konnektivität verfügbar.

  • Offline‑First: Backpressure‑fähige Warteschlange auf dem Edge‑Gerät, Priorisierung: Telemetrie < Modelle/Policies < Alarme.

4) Zentrales (On‑Prem) Training und Flotten‑Management

  • Datenhaltung: Timeseries‑DB für Telemetrie (InfluxDB/Timescale), Objektspeicher (S3‑kompatibel) für Rohfenster, strikt On‑Prem wenn Datensouveränität gefordert ist.

  • Feature Store: Deterministische, versionsierte Feature‑Pipelines. Gleiches Code‑Artefakt für Edge‑Runtime (z. B. Rust/C++/Python‑Numba) und Offline‑Training.

  • Model Registry: Versionierung, Signaturen, Hardware‑Kompatibilität, Canary‑Markierungen.

  • Deployment: OTA‑Updates über abgesicherte Kanäle (mTLS), Rollout in Batches, automatische Rollback‑Strategie, Shadow‑Inferenz zum A/B‑Vergleich.

  • Monitoring: Edge‑Health (CPU, Disk, Dropped Windows), Modellmetriken (Score‑Verteilung, Drift‑Indikatoren), Audit‑Logs.

5) Sicherheit und Compliance

  • mTLS zwischen Edge und Broker, Geräte‑Identitäten per TPM/PKI, kein eingehender Port am Edge; Pull‑basiertes Update über gesicherte Outbound‑Verbindung.

  • Protokollwahl: OPC UA für Maschinenkontext (mit Security Profile), MQTT 5.0 für Telemetrie. Klare Tenant‑Trennung je Linie/Zug.

  • DSGVO und Betriebsrat: Personenbezug ausschließen (keine Audio‑Rohdaten mit Sprachanteil), Speicherfristen technisch durchsetzen.

Was kommt wo zum Einsatz?

  • Edge: Feature‑Engineering, Anomalie‑Scores, einfache Klassifikation, Schwellenlogik, lokale Eskalation (Signallampe, SPS‑Flag).

  • Zentral (On‑Prem/Privat‑Cloud): Labeling, Retraining, Fleet‑KPIs, Workflows zur Instandhaltungsplanung, Reporting, Modell‑Governance.