Edge-Inferenz in der Predictive Maintenance: Warum die Modelle an die Maschine gehören (und wann nicht)

Problem: Was in der Praxis schiefgeht

Wer Predictive Maintenance (PdM) nur in Präsentationen gesehen hat, plant Datenströme in die Cloud, trainiert Modelle im Notebook und erwartet, dass ein „Anomalie-Screen“ plattformweit funktioniert. In der Produktion und im Bahnbetrieb scheitert das regelmäßig – nicht an der Modellgüte, sondern an Randbedingungen, die im POC ausgeblendet werden:

  • Datenvolumen und Bandbreite: Vier Beschleunigungssensoren (3 Achsen) mit 25,6 kHz und 16 Bit liefern pro Maschine grob 0,6 MB/s, also rund 2,2 GB/h. Bei 30 Maschinen liegen Sie bei 1,5–2 TB/Tag. Das dauerhaft, zuverlässig und DSGVO-/souveränitätskonform aus einer Werkshalle in eine Cloud zu pumpen, ist weder wirtschaftlich noch betrieblich robust.
  • IT/OT-Segmentierung: Firewalls, kein ausgehender Traffic ohne Freigabe, kein eingehender Zugriff, Zertifikatszwänge, Proxy-Inspektion. POCs funktionieren im Labor-WLAN, aber nicht hinter produktiven Zellen-Firewalls oder auf Zügen mit intermittierender Mobilfunkabdeckung.
  • Zeitbasis und Jitter: Ohne PTP/IEEE 1588 oder harte Trigger landen Sensorströme phasenverschoben im Speicher. FFT-Merkmale aus asynchronen Streams sind unzuverlässig. Viele POCs ignorieren das, bis der erste Cross-Correlation-Plot in der Linie auseinanderfällt.
  • Rechenbudget vor Ort: Von Cortex‑M7 über i.MX8 bis zu lüfterlosen x86‑IPCs – das Spektrum ist groß, aber durch Echtzeit-Anforderungen, Wärmehaushalt, EMV und 24/7‑Verfügbarkeit eng begrenzt. Modelle, die auf einer T4‑GPU gut laufen, starben bei uns in der Praxis schon an 10‑W‑Budgets.
  • Datenhaltung und Souveränität: In Europa und speziell in regulierten Branchen ist „US-Cloud“ für Maschinendaten oft ein No‑Go. Schon das Loggen von Rohsignalen kann personenbezogene oder IP‑sensible Inhalte berühren. Anonymisierung hilft selten bei Rohzeitreihen.
  • Integration in Instandhaltung: Alerts ohne sauber definierte Kontextdaten (Maschine, Aggregat, Betriebszustand, Auftragsnummer, Drehzahl) führen zu „Nicht bearbeitbar“-Tickets. PdM ohne CMMS/ERP-Anschluss bleibt ein Dashboard ohne Wirkung.

Fazit: Das Problem ist nicht „KI“, sondern Systemarchitektur unter industriellen Nebenbedingungen. In unseren Textil- und Bahn-Projekten war die Lösung fast immer die gleiche: Inferenz an der Kante, Flottenintelligenz on‑prem, Cloud optional – und nur für klar umrissene Zwecke.

Lösung: Eine Edge‑zuerst‑Architektur, die in der Produktion läuft

Eine praxistaugliche PdM-Architektur teilt sich in drei Ebenen:

1) Sensor/Controller-Ebene (Micro‑Edge)

  • Hardware: IEPE/ICP‑Beschleunigungssensoren, PT100/NTC, Stromzangen (Hall/Rogowski), Drehzahlsensoren; Anbindung über ADC+Anti-Aliasing (z. B. 51,2 kHz), SPI/I2C, Feldbus.

  • Zeit: PTP/IEEE 1588 oder TTL‑Sync zum Triggern mehrerer ADCs. Ziel: <±100 µs Drift für kHz‑Signale. In Zügen: GPS‑Zeit als Referenz, ansonsten lokaler Grandmaster in der Zelle.

  • Vorverarbeitung:

  • Windowing (z. B. 2048–8192 Samples), Hanning/Hamming

  • FFT/PSD, Bandenergie (k‑fache Lagerfrequenzen), Envelope‑Detektion

  • RMS/Kurtosis/Crest Factor, Ordnungsanalyse bei drehzahlvariablen Antrieben

  • Stromsignaturen (MCSA) für Rotor-/Statorfehler, Oberwellen-Features

  • Rechenbudget:

  • Cortex‑M7 @ 600 MHz schafft 2048‑Punkt FFT mit CMSIS‑DSP in ~1–2 ms

  • i.MX8 Quad kann 4× 4096‑FFT <10 ms; x86‑IPC (15 W) <2 ms

  • Ergebnis: Feature-Vektoren (typisch 50–300 Dimensionen) statt Rohdaten.

2) Edge-Node (Maschinen‑IPC oder Fahrzeug‑Gateway)

  • Aufgaben:

  • Feature-Aggregation über Zeitfenster (z. B. 1 s mit 50 % Overlap)

  • Kontext-Anreicherung (Drehzahl, Produkt, Auftrags-ID, Betriebszustand)

  • Inferenz:

  • Unüberwachte Anomalie-Modelle: Isolation Forest, One‑Class SVM, kNN‑Dichte, leichte Autoencoder (1D‑CNN/LSTM) quantisiert (INT8)

  • Überwachte Klassifikation, wenn Fehlerarten gelabelt sind (selten)

  • RUL nur, wenn ausreichende Ausfallhistorik vorliegt (noch seltener)

  • Persistenz: Ringpuffer für Rohdaten (z. B. 60–180 s Pre/Post-Event) mit LZ4/Zstd; Feature-Store lokal (7–30 Tage) zur Drift-Analyse

  • Kommunikation: MQTT 5.0 oder OPC UA PubSub in die Fabrik-IT; TLS mTLS, clientseitige Zertifikate aus lokaler CA/TPM 2.0

  • Steuerung: Konfig-, Modell- und Firmware-Updates nur aus dem on‑prem Registry/Repo; signiert; A/B‑Slots; automatisches Rollback.

  • OS & Runtime:

  • Yocto/Ubuntu Core auf ARM; schlanke x86‑Distributionen

  • Containerisiert (Podman/Docker) mit Ressourcenlimits, oder Bare‑Metal‑Services wenn Echtzeit kritisch ist

  • Optional k3s für Flottenorchestrierung in der Zelle

3) On‑Prem Core (Werks‑ oder Depot‑Rechenzentrum)

  • Dienste:

  • Feature- und Event-Ingestion (MQTT/Kafka), Identity (PKI), Policy/Access

  • Model Registry und Artifactory; CI/CD für Modelle und Signalverarbeitung

  • Flottenweite Drift-Analyse (PSI/KL-Divergenz über Features), Retraining‑Pipelines

  • Observability/Governance für ML-Agenten und Inferenzpfade (z. B. Alpi‑M) inkl. Latenzen, Fehlerraten, Schwellenverlauf, Datenqualitätsmetriken

  • CMMS/ERP-Integration (SAP PM, Maximo, Infor EAM): Ticketing, Auftragsdisposition, Rückmeldung

  • Datenhaltung:

  • Rohdaten nur eventbasiert und zeitlich begrenzt (rechtlich+Speicher)

  • Features und Inferenzmetadaten längerfristig (6–24 Monate) zur Trendbildung

  • Netzwerk:

  • Kein externer Cloud‑Zwang; wenn Cloud, dann nach strikter Whitelist, pseudonymisiert und nur für ausgewählte, nicht‑souveränitätskritische Lernjobs.

Datenfluss: Von Rohsignal bis Instandhaltungsauftrag

  • Sampling: 4× 3‑Achs‑Accelerometer @ 25,6 kHz, 16 Bit, synchronisiert via PTP‑getaktetem ADC
  • Fensterung: 1,024‑Sample Fenster (40 ms) mit 50 % Overlap
  • Features pro Fenster:
  • Frequenzbänder um BPFI/BSF/BPFO/FTF (Lagerkinematik)
  • RMS, Kurtosis, Crest Factor, Spectral Entropy
  • Ordnungspegel (bei variabler Drehzahl)
  • Stromharmonische (5., 7., 11. Ordnung) für MCSA
  • Aggregation: Median/Varianz über 1 s
  • Inferenz:
  • Isolation Forest (100 Bäume) oder INT8‑Autoencoder (ca. 200–500 kB)
  • Score glätten (Exponential Moving Average), Hysterese gegen Flattern
  • Ereignislogik:
  • Anomalie > Schwellwert T1: lokales „gelb“, erhöhte Samplingrate
  • Dauer > t_hold und Score > T2: „rot“, Event erzeugen, Pre/Post‑Rohdaten aus Ringpuffer sichern
  • Versand:
  • MQTT Topic per Maschine/Aggregat; Payload: Feature-Hash, Score, Konfidenz, Kontext, Link auf lokale Rohdatenkachel
  • Offline‑Pufferung, Retry mit Backoff; auf Zügen: Bulk‑Sync im Depot
  • CMMS:
  • Regel: Mappe „rot“ + Kontext auf Inspektionsauftrag mit SLA; füge Link auf Event-Datensatz hinzu

Modellwahl: Anomalieerkennung zuerst, RUL nur bei Datenreife