Edge-Inferenz in der Praxis: Warum Predictive Maintenance nur am Rand stabil läuft (und wann nicht)

Problem

Die meisten PdM-Pilotprojekte starten mit einer hübschen Notebook-Pipeline in der Cloud und enden mit einer ernüchternden Erkenntnis auf dem Hallenboden: Das Netz ist nicht stabil genug, die Latenzen sind unvorhersehbar, die Sensorik rauscht mehr als gedacht und niemand will dauerhaft Rohdaten in ein fremdes Rechenzentrum schieben. Was im POC mit Sample-Dateien funktioniert, kollabiert in der Produktion an genau fünf Stellen:

  • Datenrate und Latenz: Vibrationsdaten mit 12–25 kHz pro Kanal, mehrere Kanäle pro Maschine, plus Stromaufnahme und Temperatur. Wer das ungefiltert ins Rechenzentrum schiebt, kommt bei Dutzenden Maschinen sofort in Engpässe. Gleichzeitig erwarten Instandhalter eine lokale Reaktionszeit <100 ms (z. B. Spindelstopp, wenn der Zustand kippt), nicht „Ergebnis kommt, wenn die Batch-Analyse durch ist“.
  • Netz- und Betriebsrealität: In Textilfertigungen sind VLANs streng getrennt; Maintenance-Clients hängen in anderen Zonen als Maschinen. In der Bahn ist Konnektivität physisch nicht verfügbar (Tunnel, Strecken ohne Empfang). Updates, die „kurz“ einen Neustart brauchen, sind in Produktionsschichten schlicht nicht akzeptabel.
  • Datenqualität auf Sensorebene: Erdschleifen, lose Befestigung von Beschleunigungssensoren, fehlende Kalibrierung der Stromzangen. In der Cloud lässt sich das mit Filtern „korrigieren“. Vor Ort schlägt es als Drift, Schein-Anomalien und Fehlalarme durch.
  • Zeitbasis und Synchronisation: Ohne saubere Zeitstempel sind Kreuzkorrelationen (z. B. Vibration vs. Last) wertlos. In der Praxis sehen wir Zeitquellen-Mix (PLC-Zeit, Host-Zeit, Sensor-intern), der im POC ignoriert wird.
  • Governance und Souveränität: Produktionsdaten enthalten Prozess-Know-how. Viele Werke schließen US-Clouds aus Compliance-Gründen aus. Ein POC mit gehosteter Pipeline ist politisch nett, operativ aber nicht tragfähig.

Konkret: In einer Textillinie kollabierte ein Cloud-PdM-Pilot bei Schichtwechseln, weil Logging-Spitzen das Routing überlasteten und die Maschinensteuerung Priorität bekam. Ergebnis: 20–40 % Paketverluste, die Modelle kippten in den „unsicher“-Zustand. In einem Bahnszenario mit Achslagerüberwachung wären reine Cloud-Entscheider überhaupt nicht möglich gewesen – der Zug ist stundenlang offline, trotzdem braucht es vor Ort Entscheidungen zu Geschwindigkeitsreduktion oder Abschaltungen.

Meine Erfahrung: Wenn PdM im Kern auf laufzeitkritischen, hochfrequenten Signalen basiert, muss die Inferenz an den Rand (Edge) – dicht an die Maschine, in den Triebzug, ins Stellwerk. Die Cloud (oder das zentrale Rechenzentrum on-prem) bleibt für Training, Flottenmanagement, Reporting.

Lösung: Architektur, Datenfluss, Modellwahl

Zielbild ist eine mehrstufige Architektur, die Rohdaten lokal vorverarbeitet, Inferenz in Echtzeit ermöglicht und nur verdichtete Informationen und Stichproben an ein zentrales on-prem-Backend übergibt.

1) Sensorebene

  • Sensorik: Piezo-Beschleunigungssensoren (vib), PT100/NTC (Temperatur), Rogowski-Spulen/Hall-Sensoren (Strom), ggf. Drehgeber/PLC-Signale (Last, Drehzahl).

  • Abtastraten:

  • Vibration: 6–25 kHz (Maschinenbau/Textil), 512–2048 Hz (Bahn-Fahrwerk), synchron zu Drehzahl, wenn möglich.

  • Strom: 1–10 kHz für THD/Harmonische, 1–10 Hz für Mittelwerte/Drift.

  • Temperatur: 0,1–1 Hz.

  • Zeit: GNSS/PTP oder mindestens NTP lokal. Ein Edge-Zeitdienst normalisiert alle Takte auf eine Maschinenzeitbasis. Ohne konsistente Zeitstempel keine brauchbare Feature-Fusion.

2) Edge-Collector und Vorverarbeitung

  • Echtzeitfähige Datenerfassung auf IPC oder Embedded (ARM/x86), Prozessprioritäten gesetzt (SCHED_FIFO oder isolierte CPU-Kerne).

  • Vorverarbeitung:

  • Windowing: 1–4 s Fenster, 50 % Overlap für Vibration; 10–60 s für Strom/Temperatur-Trends.

  • Filterung: Bandpass (z. B. 500–5000 Hz), Notch (Versorgungsfrequenz), Entzerrung je Sensor.

  • Feature-Engineering:

  • Vibration: RMS, Peak, Crest-Faktor, Kurtosis, Spektralenergie in Bändern, Hüllkurvenanalyse, Ordnungsanalyse (drehzahlnormalisiert), Spektrale Kurtosis für Stoßdiagnostik.

  • Strom: Total Harmonic Distortion (THD), Oberwellenamplituden, Fluss der Wirkleistung, Oberwellenverteilung vs. Last.

  • Temperatur: EWMA-Trend, Gradient, Residuum vs. Umgebung.

  • Optional: adaptive Segmentierung bei Lastwechseln (Trigger via PLC-Tag).

  • Kompression: Nur Features und selektive Rohdaten-Snippets (z. B. 2–5 s bei Anomalie) werden persistiert/weitergeleitet.

3) Edge-Inferenz

  • Modellklassen:

  • Anomalieerkennung: One-Class SVM, Isolation Forest, Autoencoder (1D-CNN/TCN), Rekonstruktion-Fehler als Score.

  • Zustandsklassifikation: Gradient Boosting auf Hand-Features, kleine 1D-CNNs, TCNs.

  • RUL grob: Survival-Modelle (Cox-Variante) oder degradationsbasierte Regression auf Langzeit-Features (Trend der Hüllkurvenbande).

  • Deployment:

  • Modelle als ONNX/TorchScript, quantisiert (int8/fp16) für ARM NEON/Intel VNNI/GPU.

  • Containerisiert (Docker/Podman), minimale Images, read-only Root-FS, persistentes Volume nur für Konfiguration/Cache.

  • Latenzbudgets:

  • Vibration: <50 ms pro Inferenzfenster inkl. Feature-Berechnung.

  • Strom/Temperatur: <1 s reicht i. d. R.

  • Entscheidungslogik:

  • Score-Glättung (Exponentiell, Median).

  • Zustandsautomaten (Normal – Beobachten – Alarm – Stopp).

  • Hysterese und Minimum-Dwell-Times, um Flattern zu vermeiden.

4) Edge-Eventbus und lokale Persistenz

  • Message-Bus: MQTT oder OPC UA PubSub. Topics/Namen strikt versioniert. Payloads als kompaktes Binary (z. B. Protobuf/FlatBuffers) statt JSON.

  • Datenspeicher am Edge:

  • Ringpuffer (z. B. 24–72 h) für Features und ggf. komprimierte Rohdaten (FLAC/Parquet), um bei Störungen rückwirkend zu analysieren.

  • Health-Metriken: CPU, Drop-Rates, Sensorstatus, Modellsignale.

5) Site- oder Depot-Backend (on-prem)

  • Ingest: Kafka/Timeseries-DB (InfluxDB/Timescale) für Features und Events.

  • Model Registry und Rollout-Service: Versionen, Signaturen, Kompatibilitätsmatrix Hardware/Modell.

  • Monitoring: Flotten-Dashboard, Drift-Detektion (Verteilung der Features/Scorings), Alarmqualität (Precision/Recall, wenn GT verfügbar).

  • Training/Retaining: Periodisch, auf Stichproben-Rohdaten und aggregierten Features; Export kompakter Modelle zurück an Edge.

  • Integration CMMS/ERP: Ereignisse und Workorders an SAP PM/Maximo via OData/IDoc/REST. Eskalationslogik mit Quittierung der Technik. (→ alpitype.de/leistungen/)

6) Governance und Sicherheit

  • Keine externen Clouds: Rechenzentrum on-prem oder souveräne europäische Cloud, wenn nötig.

  • Mutual TLS, geräteindividuelle Zertifikate, Offline-Root-CA. Rotierende Kurzzeit-Zertifikate über lokales Enrollment.

  • Software-Lieferkette: signierte Images, SBOM, CVE-Scans, Zulassung je Werk.