Modellwahl nach Signalcharakteristika

  • Hohe Bandbreite, lokale Muster (Lagerdefekte, Stoß): 1D-CNN/TCN oder klassische Band-Features + Gradient Boosting. CNN/TCN eignet sich gut für quantisierte Edge-Deployments; 200–500 k Parameter liefern oft ausreichend Trennschärfe ohne GPU.

  • Niedrige Bandbreite, glatte Trends (Temperatur): robuste Regressions-/Change-Point-Modelle, EWMA, CUSUM für Drifts.

  • Stromsignaturen (Antriebe): THD + Oberwellenverhältnisse -> Gradient Boosting/Random Forest; bei variabler Last ordnungsnormalisierte Merkmale.

  • Wenig Labels: Unüberwachte Anomalieerkennung, später Semi-Supervised mit Feedback der Instandhaltung.

Trade-offs: Was man gewinnt und was man dafür aufgibt

Gewinne durch Edge-Inferenz

  • Robustheit: Entscheidungen fallen unabhängig von WAN/Cloud. Züge, die 3 h offline sind, bleiben überwacht. Werke mit restriktiven Netzen arbeiten autark.

  • Latenz und Determinismus: Reaktionszeiten <100 ms erreichbar; deterministische Pfade ohne schwankende Netzwerkjitter.

  • Bandbreite: Nur verdichtete Features und Events gehen ins Backend; Rohdaten selektiv bei Bedarf.

  • Souveränität und Compliance: Sensible Prozessdaten verlassen das Werk nicht ungefiltert; keine Abhängigkeit von US-Clouds.

Kosten/Nachteile

  • Flottenmanagement: Heterogene Hardware, Softwarestände, Zertifikate, Überwachung – ohne Tooling schnell unbeherrschbar.

  • Ressourcenlimits: Speicher/Compute am Edge begrenzt; Modellgrößen und Bibliotheken müssen optimiert werden (Quantisierung, statisches Linking, keine aufgeblähten Runtimes).

  • Debugging-Komplexität: Vor-Ort-Reproduktionen, Variation sensorischer Montagen, EMV-Einflüsse. Ohne strukturiertes Telemetrie-Design wird Fehlersuche zäh.

  • Software-Updates: Rolling Updates, Safe Rollbacks und kompatible Migrationspfade sind Pflicht – in der Fertigung gibt es keine „wir probieren mal“.

Wann trotzdem zentral (Rechenzentrum, on-prem oder souveräne Cloud)?

  • Niedrige Datenraten (1–10 Hz), unkritische Latenz (Minuten), saubere, stabile Netzanbindung.

  • Sehr komplexe Modelle (große Sequenzmodelle, Graph-Modelle), die edge-seitig nicht tragfähig sind – dann Features am Rand, schwere Inferenz zentral.

  • Explorative Analysen, Root-Cause-Suche, interaktive Dashboards – nicht auf Edge, sondern im gesicherten Backend.

Praxis: Szenarien aus Fertigung und Bahn

Textilfertigung – Spindel- und Antriebsüberwachung

Ausgangslage:

  • Ring- und Rotorspinnmaschinen mit mehreren hundert bis tausend rotierenden Einheiten. Typische Ausfälle: Lagerpittings, Unwuchten, Fadenführer-Vibrationen, Überhitzung an Antrieben.

  • Sensorik: Beschleunigungssensoren nahe am Lagerschild, Stromaufnahme der Antriebseinheiten, Umgebungstemp. Drehzahl über PLC.

Architekturentscheid:

  • Abtastrate Vibration 12 kHz, 2 s Fenster, 50 % Overlap. Strom 2 kHz für Oberwellen. Temperatur 0,5 Hz.

  • Edge-Hardware: lüfterloser ARM-IPC mit 4 Kernen (A53/A72), 4–8 GB RAM, industrietauglich, 24 V Versorgung. Ein Gerät pro Maschine, über isolierte Analog-Eingänge/IEPE mit den Sensoren verbunden.

  • Feature-Set:

  • Vibration: RMS, Crest, Kurtosis, Hüllkurven-FFT in drei Bändern (z. B. 1–2 kHz, 2–4 kHz, 4–6 kHz), sideband energy um Lagerfrequenzen (über Drehzahl normalisiert).

  • Strom: THD, 3., 5., 7. Harmonische relativ zur Grundwelle, Ripple vs. Last.

  • Temperatur: EWMA und Gradient.

  • Modellierung:

  • 1D-TCN (quantisiert, ~350 k Parameter) auf normalisierten Hüllkurvensegmenten zur Anomalieerkennung.

  • Gradient Boosting auf Hand-Features zur Zustandsklassifikation (OK/Beobachten/Kritisch).

  • Inferenzleistung:

  • Feature-Pipeline ~15–25 ms pro Fenster (NEON), Modellinferenz ~5–10 ms. Gesamt <40 ms. CPU-Last <35 % auf einem Kern.

  • Betriebslogik:

  • Anomalie-Score wird über 3–5 Fenster geglättet, Hysterese 10 s. Bei anhaltend „Kritisch“: Maschinen-spezifisches Interlock-Signal setzen (über digitale E/A), Drehzahlreduktion oder Spindelabschaltung; parallel Event via MQTT ins Werk-Backend.

  • Ergebnisse aus dem Betrieb:

  • Die Quote der Fehlalarme sank nach Einführung drehzahl-normalisierter Features deutlich; ohne Order-Tracking waren Wartungseinsätze bei Lastwechseln zu häufig.

  • Der größte Hebel kam nicht vom neuronalen Netz, sondern von sauberer Sensorbefestigung: gelöste Montageschrauben erzeugten dreimal so viele „Anomalien“ wie reale Defekte. Konsequenz: Montage-Checkliste, Anzugsmomente, Epoxid für Sensorfüße.

Worauf es ankam:

  • Zeitbasis: PLC-Drehzahl und Sensor-Zeit auf gemeinsame Referenz gemappt; erst danach stimmte die Ordnungsanalyse.

  • Edge-Updates: Maschinen laufen im Drei-Schicht-Betrieb. Updates nur im 20-min-Fenster zwischen den Linien verabreden; Blue/Green-Deployment mit lokalem Health-Check. Rollbacks innerhalb von Sekunden per A/B-Partition.

Bahn – Achslager und Antrieb

Ausgangslage:

  • Überwachung von Achslagerzuständen und Traktionsmotoren; Ziel: frühzeitige Warnung vor Erwärmung/Vibrationssignaturen, die auf beginnende Schäden hindeuten.

  • Sensorik: 3-Achsen-Beschleuniger an den Lagergehäusen, Temperaturfühler, optionale Stromsensorik der Antriebe. Abtastrate 512–1024 Hz stabil, höhere Raten nur punktuell. GNSS verfügbar, Funk nicht durchgehend.

Architekturentscheid:

  • Edge-Computer EN50155-zertifiziert, x86 low-power mit NVMe für Ringpuffer. GNSS als Zeitquelle, PTP als Fallback im Depot.

  • Vorverarbeitung: 4 s Fenster, 75 % Overlap bei Verdacht (Lastereignisse), sonst 25 %. Bandpass 5–250 Hz für Fahrwerk.

  • Feature-Set:

  • Vibration: bandbegrenzte RMS, Crest, Kurtosis, Spektralenergie in 5–10 festgelegten Bändern (Radordnungen), Envelope demodulation um Lagerfrequenzen.

  • Temperatur: EWMA + Alarm bei Anstieg >ΔT/Δt Schwellwert, relativ zur Umgebung.

  • Modellierung:

  • Unüberwachter Autoencoder auf band-pass-gefilterten Signalen (kompakt, quantisiert).

  • Für Temperaturalarm einfache Schwellen und Change-Point-Detection – robust, erklärbar.

  • Kommunikation:

  • Während Fahrt: lokale Entscheidungen; Events puffern.

  • Im Depot/WLAN: Synchronisierung von Features/Events, selektiver Rohdatenupload bei Alarmen (z. B. letzte 10 s je Sensor, verlustfrei komprimiert).

  • Betriebserkenntnisse:

  • Ohne strikte Trennung von „Fahren/Geradeaus“, „Kurve“, „Bremsen“ produziert jedes Modell Artefakte. Lösung: Zustandsdetektor (aus Gyro + Raddrehzahl) wählt pro Betriebsmodus die passenden Modelle/Schwellen.

  • Lokale Hysterese plus Meldungsbestätigung durch Werkstatt reduzierte Eskalationskaskaden. Zentrum bekommt erst „verifizierte“ Alarme.

Worauf es ankam:

  • Autarker Betrieb: 48–72 h Puffer an Bord, read-only Systempartition, Watchdog und automatischer Neustart bei Ressourcen-Leaks.

  • Sicherheitskette: Überwachung ist nicht Safety-Funktion, interagiert aber mit Betriebsprozessen. Keine direkten Eingriffe in Bremse/Traktion – nur Meldungen an Leitsystem, klarer Prozess zur Geschwindigkeitsreduktion nach menschlicher Entscheidung.

Engineering-Details, die Projekte machen oder brechen