• Unsupervised Anomaly Detection:
  • Funktioniert mit begrenzten Labeln und deckt „unbekannte Unbekannte“ ab.
  • In der Praxis robust, wenn man Betriebszustände sauber separiert (z. B. über Drehzahl und Last).
  • RUL-Modelle:
  • Brauchen echte Verschleißzyklen mit Ausfällen und lückenloser Historie. In Textil und Bahn selten verfügbar; wenn, dann oft durch Änderungen in Prozess/Design „distribution shift“ gefährdet.
  • Sinnvoll dort, wo geplante Überholungen standardisiert sind (z. B. definierte Lagerwechselintervalle in Flotten mit identischen Profilen) und genügend Zyklen vorliegen.
  • Hybride:
  • Anomalie am Edge, RUL-Schätzung on‑prem auf verdichteten Lebenszyklusfeatures; Edge zeigt „Trend“ statt kalendarischer Restlebenszeit.

Tradeoffs: Was man gewinnt und was man dafür aufgibt

Gewinne durch Edge‑Inferenz:

  • Drastische Bandbreitenreduktion: Statt 2 TB/Tag/Maschinenpark übertragen Sie 10–100 MB/Tag an Events/Features.

  • Souveränität und Compliance: Keine US‑Cloud-Pflicht, DSGVO-konforme Datenhaltung, IP‑Schutz.

  • Reaktionszeit: Millisekunden- bis Sekunden‑Latenz statt Netzwerkwabern.

  • Robustheit: Läuft auch bei Netzwerkausfall; Züge arbeiten offline und synchronisieren im Depot.

  • Datenschutz by Design: Rohdaten verlassen die Maschine nur bei klaren Anlässen und begrenzt.

Kosten/Nachteile:

  • Flottenmanagement‑Komplexität: Viele Edge‑Knoten wollen verwaltet, gepatcht, mit Zertifikaten versorgt werden. Ohne sauberes Device‑Management eskaliert der Betrieb.

  • Begrenzte Modellkomplexität: Kein 100‑Mio‑Parameter‑Netz am Cortex‑M. Dafür braucht es sinnvolle Feature Engineering und Quantisierung.

  • Debugging-Hürden: Probleme tauchen im Feld auf; Reproduktion erfordert Telemetrie, deterministische Builds und gute Logs.

  • Heterogenität: Unterschiedliche Maschinen, Sensorketten, OS‑Versionen. Standardisierung kostete in jedem Projekt mehr Zeit als die erste „KI“.

  • Sicherheit: Mehr Geräte = größere Angriffsfläche. PKI/TPM, Signaturen, minimaler Footprint sind Pflicht.

Wann Cloud‑Analyse sinnvoll ist:

  • Flottenweites Training auf großen, pseudonymisierten Feature‑Sätzen

  • „Rare event“ Mining mit zentral aggregierten Events

  • Simulationsgestütztes Pre‑Training (z. B. synthetische Signale) und Hyperparameter‑Suche

  • Kollaborative Modellentwicklung über Standorte – aber: Trainingsergebnisse wandern zurück on‑prem, Inferenz bleibt an der Kante

Praxis: Drei Szenarien aus Fertigung und Bahn

1) Textil: Lagerüberwachung an Ringspinnmaschinen

  • Ausgangslage: Häufige Klein-Störungen durch beginnenden Lagerverschleiß an Spindeln; hohe Drehzahlen, wechselnde Sortimente; POC mit Cloud scheiterte an Bandbreite und an fehlender Synchronisation.

  • Architektur:

  • Sensorik: 2× IEPE-Beschleuniger pro Aggregat, synchronisiert; Drehzahl vom Antrieb (Encoder)

  • Edge: ARM‑Gateway (i.MX8) in der Maschine; CMSIS‑DSP für FFT; Isolation Forest (100 Bäume); optional 1D‑Autoencoder (INT8, ~300 kB)

  • Zeit: PTP aus Maschinen‑IPC; Fenster 2048 Samples, 50 % Overlap

  • Speicher: 120 s Ringpuffer (Rohdaten) mit LZ4; 30 Tage Feature-Retention

  • Netzwerk: MQTT in Werks‑Broker; keine externe Cloud

  • Ergebnisse:

  • Bandbreite: <50 MB/Tag pro Maschine

  • Latenz: Anomalie‑Score <30 ms nach Fensterabschluss

  • Qualität: <1 falscher Alarm pro Maschine/Monat nach Kalibrierung; MTTD <24 h vor ausgeprägtem Fehlerbild

  • Betrieb: Updates als signierte Container; A/B‑Rollback <60 s, ohne Maschinenstopp

  • Learnings:

  • Kurtosis allein lärmig; Kombination aus Ordnungsenergie + Envelope brachte Stabilität.

  • Adaptive Schwellwerte pro Drehzahl‑Bucket halbierten Falschalarme.

  • SSD‑Schonung: noatime, Journaling‑Tuning, voralloziertes Ringfile, zentrale Log‑Drossel.

2) Bahn: Traktionsmotoren – Stromsignaturanalyse im Fahrzeug

  • Ausgangslage: Intermittierende Mobilfunkabdeckung; harte IT/OT‑Trennung; Ziel ist frühe Detektion von Stator-/Rotoranomalien ohne Ausbau der Motoren.

  • Architektur:

  • Sensorik: Stromzangen an drei Phasen, 10 kHz; Tachogeber für Ordnungsanalyse

  • Edge: lüfterloses x86‑Gateway (15 W) pro Traktionseinheit; Echtzeit‑Thread für Sampling/FFT; Prozessisolation für Inferenz

  • Inferenz: kNN‑Dichte im Ordnungsraum; später leichter 1D‑CNN‑Autoencoder (INT8) für harmonische Muster

  • Sync: GPS‑Zeit an Bord + lokaler PTP; PLL‑Abgleich für ADC

  • Kommunikation: Events lokal puffern; Bulk‑Sync per Ethernet im Depot

  • Integration: Depot‑On‑Prem nimmt Events; SAP PM generiert Inspektionsaufträge

  • Ergebnisse:

  • 70–90 % der relevanten Frühindikatoren als „gelb“ > eine Umlaufwoche vor Grenzwertverletzung

  • Zero‑Touch‑Betrieb im Feld über 6 Monate; Zertifikatsrotation via TPM‑gebundene mTLS

  • Kein Dauertransfer von Rohdaten; Event‑Payloads 50–200 kB inkl. Pre/Post

  • Learnings:

  • Latenzdeterminismus: CPU‑Affinity, isolcpus und abgeschaltetes Turbo‑Boost verringerten Jitter signifikant.

  • Fleet‑Drift: Winter/Sommer‑Betriebsprofile änderten Grundlast – Schwellwerte saisonal mit On‑Prem‑Policies adjustiert.

3) Zerspanung: Spindelüberwachung an Bearbeitungszentren

  • Ausgangslage: Hohe Oberflächenanforderungen, teure Ausschusskosten; Maschinen divers (Siemens/Heidenhain), IT‑Zugang restriktiv.

  • Architektur:

  • Sensorik: 1× Beschleuniger am Spindellager, 1× Temperatur; Drehzahl über NC‑Schnittstelle

  • Edge: x86‑IPC im Schaltschrank; OPC UA für NC‑Kontext; FFT+Envelope; One‑Class SVM

  • CMMS: Automatische Qualitäts‑Hold bei „rot“ über MES‑Integration

  • Ergebnisse:

  • 30–50 % weniger ungeplante Spindelstillstände nach 4 Monaten

  • Minimale Netzwerklast; reine Events/Features zum On‑Prem‑Core

  • Learnings:

  • Ohne saubere Drehzahl-Zuordnung (NC) waren Features unbrauchbar; Ordnungsanalyse Pflicht.

  • Ein einziges, robustes SVM‑Modell pro Spindeltyp schlug „neuronale Allzwecknetze“ im Edge‑Budget.

Konkrete Bausteine, die sich bewährt haben