Edge-Inferenz in der Praxis: Wann ML-Modelle an die Maschine gehören – und wann nicht

Problem: Warum viele PdM-POCs in der Cloud scheitern
Predictive Maintenance-Projekte laufen oft genauso ab: Man sammelt ein paar Wochen Sensordaten, lädt alles in eine Cloud, baut schnell ein Notebook-Modell, zeigt hübsche ROC-Kurven – und stellt in der Produktion fest, dass das System am Netz, an der Latenz und an den Betriebsrealitäten zerbricht. Zwei typische Bruchstellen aus der Praxis:

  • Datenvolumen und Latenz: Eine Textillinie mit 96 Spindeln und je einem triaxialen Beschleunigungssensor bei 25,6 kHz Sampling produziert schnell 8–12 MB/s Rohdaten. Selbst mit kräftiger Kompression ist permanentes Streaming illusorisch. Gleichzeitig erwarten Instandhalter Alarme innerhalb von 200–500 ms, nicht nach einer Batch-Analyse.
  • Konnektivität und Souveränität: In der Bahn ist die Funkverbindung intermittierend; Fahrzeuge sind über Stunden offline. Und in vielen DACH-Unternehmen ist klar: Sensordaten mit IP-relevanten Mustern verlassen weder Werk noch Landesgrenze. DSGVO und Geheimhaltungsanforderungen schließen „Cloud-first“ aus.

Das Ergebnis sind „schöne“ POCs, die in der Produktion scheitern: Entweder kollabiert das System an der Bandbreite, oder die Latenz macht es unbrauchbar, oder die Organisation blockiert den Abfluss von Maschinendaten in Public Clouds. Die Gegenbewegung heißt Edge-Inferenz: Modelle direkt an der Maschine, roh datennah, robust gegen Netzstörungen – und nur das Nötigste verlässt die Zelle.

Lösung: Eine Edge-first Architektur für Predictive Maintenance
Edge-first heißt nicht „alles lokal für immer“. Es heißt: Zeitkritische Inferenz und grobe Vorverarbeitung (Feature-Engineering, Verdichtung) laufen direkt am Aggregat; Flottenanalyse, Retraining und Flotten-RUL passieren on-prem zentralisiert. Der technische Aufbau, der sich in Textilfertigung und Bahn bewährt hat:

1) Signalerfassung und Vorverarbeitung

  • Sensorik: Beschleunigung (10–51,2 kHz), Motorstrom (10–20 kHz), Temperatur (1–10 Hz). Anti-Aliasing-Hardwarefilter an der DAQ, um den digitalen Filteraufwand zu senken und Sättigungen zu vermeiden.

  • Zeitbasis: PTP (IEEE 1588) oder zumindest NTP mit regelmäßigem Drift-Check. Kein verlässliches Labeling ohne stabile Zeitbasis. In fahrzeuggetragenen Systemen: GPS PPS als Referenz.

  • Fensterung: Sliding Windows mit 0,5–2,0 s je nach Drehzahlbereich. Für 25,6 kHz haben sich 2048–8192-Sample-Fenster (80–320 ms) mit 50–75 % Overlap bewährt. So erreicht man Subsekunden-Latenz bei stabilen Merkmalen.

  • Online-Features: RMS, Peak-to-Peak, Crest Factor, Kurtosis, Spektralzentroid, Band-Power um Fehlerfrequenzen (z. B. Lagerinnen-/Außenring, Käfig). Für Motorstrom: Oberwellenenergie, Sideband-Indizes um die Netz- und Inverterfrequenzen, Park-Transformation wenn Drehzahl verfügbar ist.

2) Edge-Rechner: Hardware-Tiers

  • Tier 0 (MCU/RTOS): Für einfache Grenzwert-/Anomalieindikatoren in µs–ms. 100–300 MHz Cortex-M, 256–1024 kB RAM. Kein komplexes ML, aber extrem robust und niedrige Leistungsaufnahme.

  • Tier 1 (Industrial ARM/x86, fanless): 2–8 Cores (Cortex-A53/A72 oder Intel Atom/i3), 2–8 GB RAM, 5–15 W TDP. Läuft 95 % der PdM-Workloads: Feature-Engineering + OnnxRuntime/TFLite-Modelle. Temperaturbereich -20 bis +60 °C, Schutzklasse IP50–65 in der Nähe der Maschine.

  • Tier 2 (GPU/AI-Module): NVIDIA Jetson Orin Nano/Xavier NX oder Intel iGPU/OpenVINO, 10–30 W. Für 10+ parallele Sensorströme mit 1D-CNNs oder Spektralnetzen. In Bahn: EN 50155-zertifizierte Box-PCs.

Hardwarewahl ist kein „KI-Prestigeprojekt“ – sie folgt dem Durchsatzbudget: Wie viele Kanäle mal Samplingrate, welche Features, welche Inferenzlatenz? Faustregel: Wenn Sie pro Knoten <1e9 FLOPs/s und <500 MB/s RAM-Bandbreite benötigen, genügt ein solider x86/ARM ohne dedizierte GPU. GPU lohnt erst, wenn 10+ Signale parallel mit tiefen CNNs laufen oder wenn man Energie pro Inferenz minimieren muss.

3) Betriebssystem und Runtime

  • OS: Minimal-Linux (Yocto/Ubuntu Core). Kernel mit PREEMPT-RT, wenn strikte Latenzen nötig sind. Keine Desktop-Bloatware.

  • Container: Podman/Buildah rootless, read-only rootfs, tmpfs für Runtime. SBOM gepflegt. Keine „ssh auf die Box und mal schnell was fixen“-Mentalität.

  • Scheduling: CPU-Affinität für Signalverarbeitung, isolcpus für deterministische Latenz. Thermisches Budget überwachen – Throttling killt Echtzeit-Inferenz.

  • Telemetrie: Node Exporter, Journald-Forwarding. Edge-Health wird mit überwacht (Disk-WEAR, Temp, Reboot-Counter).

4) Modelllaufzeit und Paketierung

  • Formate: ONNX als Standardartefakt. Für ARM: TFLite int8. Für Intel: OpenVINO (FP16) gut geeignet. Für NVIDIA: TensorRT mit INT8-Kalibrierung.

  • Quantisierung: Start mit FP32 im Training, Edge mit INT8. Validate auf per-Feature-Distributionen; akzeptabler Genauigkeitsverlust <1–2 %-Punkte bei 3–4x schneller Inferenz und 4x kleinerem Modell.

  • Paketierung: Signierte Artefakte (Sigstore/Cosign), Versionierung semver, „feature spec“ (welche On-Edge-Features hat das Modell erwartet). Konfig getrennt vom Modell (Thresholds, Kanal-IDs).

  • Deterministik: fester Random-Seed, gleiche FFT-Implementierung (FFTW vs. KissFFT) zwischen Entwicklung und Edge; Unterschiede führen sonst zu Drift.

5) Datenfluss und Integrationen

  • Lokal: Ringpuffer (RAM) mit 30–120 s Rohdaten; persistenter Store-and-Forward (Disk) nur für Events und verdichtete Features. Backpressure-Handling: Wenn Netz down, dann FIFO mit Prioritäten (Events zuerst, Features danach).

  • Messaging: MQTT 5.0 (QoS1, Retain für Konfig) oder OPC UA PubSub. Payloads als Protobuf/Avro. Time-series on-prem (Timescale/Influx). Keine unkomprimierten JSON-Fluten.

  • Systeme: Integration ins CMMS/ERP (z. B. SAP PM, Maximo) über Webhooks/REST oder Message Bus; Edge erzeugt technische Diagnose-Events, die zentrale Logik mappt auf Auftragsarten und Schichtkalender. Alarm-Spam wird durch Hysterese und Cooldowns verhindert.

  • Security: mTLS, Geräteidentitäten mit TPM/Hardware-Keys. Kein US-Cloud-Zwang, alle Datenflüsse on-prem, DSGVO-konform. Audit-Logs für Modellwechsel.

6) Deployment und Updates

  • OTA-Strategie: A/B-Updates, phasenweise Rollouts (1 % → 10 % → 100 %), automatisches Rollback bei Healthcheck-Fails. Update-Fenster entlang Produktionspausen/Depotaufenthalten.

  • Testpyramide: Unit-Tests für Features, Golden-File-Tests für komplette DSP-Pipelines, Replay-Tests mit aufgezeichneten Binärströmen, On-Device-Soak-Tests (24–72 h).

  • Observability: Edge sendet Confusion-Matrix-Kandidaten (Trigger vs. Techniker-Rückmeldung). Zentraler Governance-Prozess trackt Falschalarme, Drift, Modelllebensdauer. (Wir setzen hier auf eine on-prem Observability- und Governance-Schicht; Details gern im Austausch → alpitype.de/leistungen/)

Entscheidungsrahmen: Edge vs. Cloud – eine nüchterne Matrix
Die Frage ist nicht ideologisch, sondern eine einfache Bewertung entlang fünf Achsen: