Trade‑offs: Was man gewinnt – und was man aufgibt

  • Latenz vs. Flexibilität:

  • Pro Edge: Millisekunden bis wenige 100 ms Entscheidung, robust gegen Netzausfälle.

  • Contra: Mehr Variantenvielfalt in der Flotte, sorgfältiges Deployment nötig.

  • Bandbreite vs. Transparenz:

  • Pro Edge: Zwei bis drei Größenordnungen weniger Datenvolumen im Uplink; praktikabel bei 100+ Maschinen/Zügen.

  • Contra: Forensik hängt von guter Event‑Pufferung ab. Wer nie Rohfenster schickt, steht im Post‑Mortem ohne Beweise da.

  • Genauigkeit vs. Rechenbudget:

  • Pro Edge: Leichte Modelle sind oft “gut genug”. Stabilität gewinnt gegen letzte Prozentpunkte Genauigkeit.

  • Contra: Sehr komplexe Ensembles / tiefe Netze passen ggf. nicht auf kleine ARM‑Knoten; dann Hybrid: schwere Entscheidung zentral, aber nur bei geplanten Analysen.

  • Standardisierung vs. Domänenspezifik:

  • Pro Edge: Domänenspezifische Features (z. B. Ordnungsanalyse) sind näher am Prozess und robuster gegen Drift.

  • Contra: Mehr Engineering‑Aufwand als “Rohdaten -> generisches Deep Learning”.

  • Betrieb vs. PoC‑Tempo:

  • Pro Edge: Produktionsreife von Anfang an (Observability, OTA, Rollback).

  • Contra: PoC dauert länger, weil man Deployment‑Wege baut – zahlt sich aber bei der Skalierung aus.

Praxisbeispiel 1: Textilfertigung – Lagerschaden am Hochgeschwindigkeitswebstuhl
Ausgangslage

  • 800–1.200 U/min, drehzahlvariable Profile je Produkt. Kritische Lager laufen bei hohen Flankenbeschleunigungen. Stromaufnahme des Hauptantriebs korreliert mit mechanischen Problemen.

  • Netzwerkinfrastruktur der Halle ist alt, WAN begrenzt. Externe Cloud ist ausgeschlossen; Werksvorgabe On‑Prem only.

Implementierung

  • Sensorik: 2× MEMS‑Beschleuniger pro Lagerblock (±16 g, 25 kHz), PT100 an Lagergehäuse, Stromzange am Antrieb (2 kHz).

  • Edge‑Hardware: Lüfterloser x86‑IPC mit 4‑Kern‑CPU; PTP‑fähige NIC; lokale NVMe 128 GB für Ringpuffer.

  • Vorverarbeitung:

  • Fenster 2048 Samples @25 kHz (≈81,9 ms), 50 % Overlap.

  • Hüllkurvenanalyse mit Bandpass 1–5 kHz; FFT‑Leistung in definierter Bandmaske.

  • Zeitsignal: RMS, Kurtosis, Crest‑Faktor, Impulsrate.

  • Order‑Tracking über Drehzahlsignal; Normalisierung der Features auf Ordnungen statt absolute Hz.

  • Modell:

  • Autoencoder (1D‑CNN, 100k Parameter, INT8), auf fehlerfreien Daten der letzten 8 Wochen trainiert.

  • Gradient‑Boosted Trees auf handgemachten Features als Second‑Opinion‑Klassifikator.

  • Fusionslogik: Score‑Ensemble mit drehzahlabhängigem Schwellwert.

  • Inferenz:

  • Latenz ca. 120–150 ms ab Fensterende, CPU‑Last <20 %.

  • Edge-Bescheide triggern SPS‑Flag für Reduktion der Geschwindigkeit um 10 % bei “Warnung”, Stop bei “Alarm” plus optische Signale.

  • Uplink:

  • Normalbetrieb: Health‑Index (0–1), Feature‑Mittelwerte jede 5 s via MQTT; ca. <5 kB/s pro Maschine.

  • Ereignis: Rohfenster 10 s vor/nach Alarm, gz‑komprimiert, einmalig; im Schnitt 30–50 MB je Event.

  • Ergebnisse:

  • Datenreduktion um ~10.000× verglichen mit Dauerstreaming der Rohdaten.

  • Falschalarme initial hoch durch Produktwechsel; gelöst durch Ordnungsanalyse und produktabhängige Baselines (Kontext aus ERP: Auftragsnummer → Rezeptur).

  • Technischer Lerneffekt: Schraubensicherung und Kabelführung sind nicht “Detailarbeit” – Vibrationsartefakte durch lose Halter sind die Fehlerquelle Nr. 1. Wir haben mechanische QA in den Deploy‑Runbook aufgenommen.

  • Betrieb:

  • OTA‑Rollout in 10er‑Batches nachts; Shadow‑Inferenz für 2 Wochen parallel; automatisches Rollback bei Abweichung >20 % in Score‑Quantilen.

Praxisbeispiel 2: Bahn – Flachstellen- und Lagerdiagnose im Flottenbetrieb
Ausgangslage

  • Flotte von Triebzügen, Sensorik pro Drehgestell: Vibration (10 kHz), Körperschall, Temperatur; Fahrzeuggeschwindigkeit aus Fahrzeugbus.

  • LTE‑Konnektivität lückenhaft, Depots mit WLAN/ETH‑Andockpunkten. Sicherheits- und Zulassungsanforderungen schließen Public‑Cloud aus.

Implementierung

  • Edge‑Knoten: Ruggedized ARM‑Box pro Wagen, 4 GB RAM, 64 GB eMMC. Zeit via GNSS‑disziplinierter PTP‑Grandmaster im Zugverbund.

  • Vorverarbeitung:

  • Ereignisdetektion für Stoßimpulse; Zeit‑ und Frequenzfeatures ähnlich wie oben.

  • Geschwindigkeitsskalierung: Normierung der Spektren auf Ordnungen; Segmentierung nur bei v > 20 km/h.

  • Dynamische Schwellen pro Streckenabschnitt (Gleisqualität variiert); Strecken‑IDs aus Fahrplan/Positionsdaten im Depot gemappt.

  • Modell:

  • Klassifikator für Flachstellen (Impulsfolge, Energieverteilung), separater One‑Class‑Anomaliedetektor für Lagerdegradation.

  • Ensemble‑Entscheidung liefert Schweregrad 0–3 und empfohlenen Zeithorizont bis Inspektion.

  • Kommunikation:

  • Online: Minimal‑Telemetrie im 30‑s‑Raster (Zustandsindex je Achse).

  • Depot: Bulk‑Upload von Eventfenstern und Logs via WLAN; Synchronisation gegen On‑Prem‑Cluster im Werk.

  • Integration:

  • CMMS‑Schnittstelle: Automatisches Erstellen von Arbeitsaufträgen mit Fahrzeug‑, Achs‑ und Kilometerstandangabe; SLA‑Logik für Fristen.

  • Werkzeuge für Instandhalter: Event‑Viewer mit Zeitsignal/FFT, Kontext (Geschwindigkeit, Temperatur), Vergleich historischer Events.

  • Ergebnisse:

  • Keine Produktiv‑Abhängigkeit vom Mobilfunk. Ereignisdaten stehen spätestens im Depot zur Verfügung.

  • Verbesserung der Trefferquote durch streckenabhängige Baselines; anfängliche Fehlalarme auf “rauen” Gleisabschnitten sanken nach Einführung von Segment‑Profilen erheblich.

  • Ein wichtiger Betriebsaspekt: Autoskalierende Puffer, um auch bei zwei Wochen Depot‑Ausfall keine Daten zu verlieren. Speicherbudget pro Wagen: ca. 10–20 GB nur für forensische Windows.

Technische Leitplanken und Empfehlungen

  • Wenn eine der folgenden Bedingungen wahr ist, gehört die Inferenz an die Maschine:

  • Reaktionszeit 1 % der Zeit.

  • Rohdatenrate >1 MB/s langfristig.

  • Strikte Datensouveränität/Regulatorik gegen externe Clouds.

  • Trennung von Rollen:

  • Edge: deterministisch, begrenzte Variabilität, debuggbar ohne Internet.

  • Zentral: Experimentieren, Retraining, Auswertung, Governance.

  • Quantisierung und Portabilität:

  • Modelle im ONNX‑Format und quantisiert bereitstellen. Edge‑Runtime klar definieren (z. B. OnnxRuntime mit spezieller EP). Keine exotischen Ops, die nur auf dem Entwickler‑Laptop existieren.

  • Feature‑Engineering schlägt “blindes” Deep Learning:

  • Order Tracking bei variabler Drehzahl ist der Unterschied zwischen robust und instabil.

  • Kurtosis/Crest‑Faktor geben schnelle Hinweise auf Impulsfehler, Hüllkurvenanalyse hebt Lagermodulationen hervor. Diese einfachen Features sind Edge‑tauglich und gut erklärbar.

  • Synchronisation und Drift:

  • Ohne stabile Zeitbasis driftet alles auseinander. Monitoring für Clock‑Offset einbauen.

  • Konzeptdrift: Score‑Verteilungen überwachen, saisonale/produktabhängige Effekte modellieren, Shadow‑Tests vor Freischaltung.

  • Sicherheit by default:

  • Nur ausgehende Verbindungen, minimale Angriffsfläche.

  • Zertifikatsrotation automatisieren. Keine “ewigen” Secrets im Image.