• Latenz: Erfordert Ihr Use Case 10 s lässt sich leichter zentralisieren.
  • Bandbreite: Rohdatenrate >1 MB/s pro Anlage? Edge-Feature-Engineering spart 10–100x Bandbreite. Unter 100 kB/s kann man mit Batch-Uploads arbeiten.
  • Verfügbarkeit: Ist das Netz >99,5 % verfügbar? In vielen Fabriken real eher 95–98 %. In Bahnfahrzeugen teils <80 %. Je schlechter, desto mehr Edge.
  • Souveränität/Compliance: Dürfen Rohsignale das Werk verlassen? Wenn „nein“ oder „nur pseudonymisiert/verdichtet“, ist Edge Pflicht.
  • Flottennutzen: Brauchen Sie Fleet-over-Fleet-Vergleiche/Population-Modelle? Dann mischen: Edge für Erstentscheidung, zentrale Aggregation für Trends/Training.

Trade-offs: Was man gewinnt – und was es kostet
Gewinne:

  • Robustheit: Alarme auch bei Netzausfall. Keine Produktionsstopps „weil Cloud down“.

  • Latenz: Subsekunden-Entscheidungen möglich (z. B. Soft-Stopp statt Not-Aus).

  • Bandbreite: 10–100x weniger Daten, gezielte Event-Snippets statt Dauerstream.

  • Souveränität: Datenhoheit, Auditierbarkeit, keine externen Abhängigkeiten.

Kosten:

  • Plattformaufwand: Gerätemanagement, OTA, Security – muss man bauen oder sauber einkaufen. Ohne das wird Edge zum „Snowflake-Zoo“.

  • Debugging: Distributed debugging ist härter. Reproducible Pipelines, Golden Files und gute Telemetrie sind Pflicht.

  • Hardware-BOM: 200–800 € pro Knoten sind realistisch für Tier-1/2. Rechnet sich nur, wenn Stillstandskosten hoch sind oder viele Anlagen pro Knoten bedient werden.

  • Pflege: Modelle altern. Konzeptdrift, neue Chargen, geänderte Lager – Edge zwingt zu diszipliniertem MLOps on-prem.

Praxisbeispiele

Textilfertigung: Spinnereilinie mit hochfrequenter Vibration
Ausgangslage: Ring- und Rotorspinnen mit 20–60 kRPM, mehrere Dutzend Lagerstellen, Inverter-induzierter EMV-Lärm. Ziel: Frühwarnung vor Lagerschäden und Unwucht, Reaktionszeit <500 ms, keine Cloud.

Architektur:

  • Sensorik: Triaxiale IEPE-Sensoren bei 25,6 kHz, Motorstrom über Hall-Shunt bei 12,8 kHz, PT100-Temperatur.

  • Edge: Fanless x86 (4 Cores), 8 GB RAM, PREEMPT-RT. Feature-Pipeline in C++ (FFTW), Inferenz via ONNX Runtime.

  • Modelle: Zweistufig

1) Anomalieerkennung (Autoencoder mit 1D-CNN, INT8 quantisiert). Ziel: 5–10x Verdichtung durch Features und Reconstruction Error.
2) Fehlerklassifikation (Gradient Boosted Trees) auf aggregierten Features + Drehzahl. Vorteil: Erklärbarkeit, Robustheit gegenüber leichtem Drift.

  • Datenfluss: 320 ms Fenster, 75 % Overlap. Pro Fenster 60–120 Features; Edge sendet pro 5 s ein Aggregat. Ereignisse enthalten 1–3 s Rohdaten-Snippet zum späteren Root-Cause-Analysis.

  • Integration: MQTT → on-prem Timeseries DB → Event Router → SAP PM. Aufträge werden parametrisiert (Maschine, Achse, Dringlichkeit).

Ergebnisse aus der Praxis:

  • Bandbreite: Reduktion von ~10 MB/s Rohsignal auf ~5–20 kB/s Features/Events pro Linie.

  • Latenz: 200–350 ms bis zum Edge-Alarm, <2 s bis CMMS-Eintrag.

  • Genauigkeit: Mit INT8-Quantisierung <1 %-Punkt Verlust; Falschalarmrate nach Tuning <2/Woche/Linie.

  • Stolpersteine: EMV-Einkopplungen im Motorstromkanal führten zu False Positives. Lösung: bessere Schirmung und digitale Notch-Filter um Inverter-Schaltfrequenzen; gemeinsame Erdungspunkte. Außerdem: FFT-Library-Wechsel verursachte minimale Spektralverschiebungen – nachträglich durch Golden-File-Tests fixiert.

Bahn: Flottenweite Lagerüberwachung auf Fahrzeugen
Ausgangslage: Achslager- und Getriebeüberwachung in Triebzügen. LTE-Verbindung intermittierend, Fahrzeuge oft stundenlang offline. Ziel: Früherkennung und RUL-Schätzung, alle Daten on-prem im Betreiberrechenzentrum, Hardware EN 50155.

Architektur:

  • Hardware: EN 50155 Box-PC mit Intel i7/i5, 16 GB RAM, M.2-NVMe mit Power Loss Protection. Temperaturbereich -25…+70 °C.

  • Synchronisation: GPS-Zeit, PTP im Fahrzeugnetz. Geschwindigkeit via Tachopulse/CAN, für Ordnungsanalyse.

  • Edge-Algorithmen:

  • Spektrale Kurtosis und Envelope Detection zur Bandbegrenzung auf Fehlerfrequenzen, normiert auf Drehzahl (Order Tracking).

  • Klassifikation via 1D-CNN (FP16/OpenVINO) auf Hüllkurven-Subbändern bei hoher Überdeckung, output: Damage Index.

  • RUL-Schätzung zentral: State-Space-Modell (Kalman-Variante) und Weibull-Fit, gespeist aus Damage-Index-Zeitreihen pro Achse.

  • Datenstrategie: On-Edge Entscheidung (OK/Watch/Alarm) sofort für Fahrzeug-HMI; Features und komprimierte Snippets werden im Depot per WLAN synchronisiert (einmal pro Tag). 30 Tage lokale Retention als Puffer.

  • Security/Betrieb: mTLS, Gerätezertifikate im TPM, Rootless Container, A/B-OTA während Depotzeitfenstern. Kein Offboard in Public Clouds, alle Backends on-prem.

Erfahrungen:

  • Robustheit: Keine Service-Degradationen trotz Funklöchern. Alarme erscheinen auf Fahrzeug-HMI unabhängig vom Backend.

  • Kameradschaft mit Mechanik: Temperaturgradienten während Langsamfahrt erzeugten scheinbar erhöhte Damage-Indizes; Lösung: Zustandsmodell mit Fahrtprofil als Kovariate, Hysterese beim Übergang Watch→Alarm.

  • Update-Disziplin: Canary auf wenigen Fahrzeugen verhinderte Flotten-Fails durch eine fehlerhafte FFT-Optimierung, die auf zwei CPU-Steppings anders lief.

Checkliste: Ist Ihr Use Case Edge-fit?

  • Muss die Entscheidung <1 s kommen?

  • Überschreitet Ihre Rohdatenrate 1 MB/s pro Maschine?

  • Ist die Netzverbindung <99,5 % zuverlässig oder intermittierend?

  • Dürfen Rohsignale das Werk/den Zug nicht verlassen?

  • Gibt es lokale Daten, die für die Entscheidung notwendig sind (Drehzahl, Schichtplan), die nicht zuverlässig zentral vorliegen?

Wenn Sie >3 Fragen mit „ja“ beantworten, planen Sie Edge-Inferenz – und zwar als Produkt, nicht als POC: mit OTA, Observability, Tests, Security. Wenn nicht, prüfen Sie eine gemischte Architektur: Edge für Featureverdichtung/Pre-Filtering, zentrale Inferenz on-prem.

Konkrete technische Empfehlungen

  • Windowing: Beginnen Sie konservativ (1 s/50 % Overlap), messen Sie Latenz und CPU, reduzieren Sie dann auf 320 ms/75 % Overlap, wenn die Physik es erlaubt.

  • Features zuerst, Deep Learning danach: Robustheit gewinnt. Ein solider Feature-Stack macht das Modell unempfindlich gegen Sensorwechsel, Abtastraten und DSP-Details. 1D-CNNs sparen Sie sich für echte Nichtlinearitäten oder stark variierende Bedingungen auf.

  • Quantisierung mit Kalibrierung: Sammeln Sie 10–20 Minuten repräsentative Edge-Daten für INT8-Kalibrierung. Prüfen Sie per-Feature-Distributionen vor/nach Quantisierung.

  • Zeit- und Drehzahl-Normalisierung: Ohne Order Tracking vergleichen Sie Äpfel mit Birnen. Drehzahl rein ins Feature-Set (oder als Resampling-Achse).

  • Edge-Tests wie Software: Golden-File-Replays auf der Zielhardware, deterministische Seeds, CPU-Pinning, Soak-Tests mit Telemetriealarmen.

Governance und Integration in den Betrieb
Technisch gute Modelle scheitern organisatorisch, wenn niemand Verantwortung für Updates, Alarme und Rückmeldungen trägt. Etabliert hat sich: