5) MLOps am Edge: wie man Modelle im Feld kontrolliert

  • Versions- und Rollout-Strategie:

  • Jedes Modell ist ein versioniertes, signiertes Artefakt mit klarer Input/Output-Spezifikation.

  • Canary- und A/B-Rollouts auf Teilflotten, mit automatisiertem Rollback bei KPIs-Verschlechterung.

  • Observability:

  • Statistiken pro Feature (Mittelwert, Varianz, PSI/Drift-Kennzahlen), Auslastung, Latenz, Dropped Windows.

  • Audit-Log: Welches Modell hat welchen Alarm ausgelöst, auf welchen Features, mit welchen Parametern? Ohne diese Nachvollziehbarkeit gibt es keine Akzeptanz im Betrieb.

  • Retraining-Loop:

  • Training/Experimentierung zentral (on-prem Cluster). Edge liefert nur Events + kuratierte Rohdaten-Snips. Keine Wild-West-Online-Lernexperimente direkt an der Maschine.

6) Integration in CMMS/ERP: Nutzen entsteht erst im Prozess

  • Ereignisse werden in eine saubere Domäne übersetzt: Asset-ID, Komponente (ISO 14224 Taxonomie bewährt), Fehlerhypothese, Evidenz (Spektrum, Zeitreihe), empfohlene Aktion.

  • Fehler-Persistenz und Hysterese: Ein Alarm wird erst nach z. B. drei aufeinanderfolgenden Zyklen scharf. „Flatteralarme“ zerstören Vertrauen.

  • Tickets automatisch erzeugen, aber „review required“-Gate für den Instandhaltungsmeister. Rückmeldung aus dem CMMS (work done / root cause) ist Trainingsgold für spätere Supervised-Modelle.

  • Schnittstellen: REST/GraphQL on-prem, keine ausgehenden Verbindungen in US-Cloud-Dienste. Das ist nicht Ideologie, sondern Risikomanagement. (→ alpitype.de/leistungen/)

Trade-offs: Was man gewinnt und was man dafür aufgibt
Vorteile der Edge-Inferenz:

  • Determinismus und Latenz: Sub-100-ms-Pfade sind realistisch, auch bei Netzproblemen.

  • Bandbreite: 1000× weniger Datenverkehr durch Event-basiertes Senden.

  • Resilienz: Auch bei WAN-Ausfall bleibt der Schutz aktiv; Alarme laufen lokal weiter.

  • Souveränität: Daten verlassen das Werk/den Zug nicht unkontrolliert; regulatorische und vertragliche Vorgaben werden eingehalten.

Nachteile bzw. Kosten:

  • Flottenmanagement: 20–2000 Edge-Knoten upzudaten, zu überwachen und zu patchen braucht Disziplin und Automatisierung.

  • Debuggability: Fehlersuche verteilt über Gerät, Netzwerk, Backend – ohne gutes Telemetrie-Design wird das schmerzhaft.

  • Hardware-Budget: Pro Asset fallen einmalige Kosten für robuste Edge-Computer und Sensorik an. Meist amortisiert durch vermiedene Cloud-Traffic- und Egress-Kosten, aber CapEx bleibt CapEx.

Vorteile der Cloud-zentrierten Analyse (on-prem-Cloud eingeschlossen):

  • Vereinfachtes Betriebsmodell: Eine zentrale Plattform, homogenes Update.

  • Schwere Jobs: Training, hyperparametrische Suche, lange Historienauswertung – zentral ist sinnvoller.

  • Kollaboration: Datenwissenschaft, Instandhaltung, Betrieb sehen denselben „Single Source of Truth“ – vorausgesetzt, sie ist on-prem erreichbar.

Nachteile der Cloud-Only-Idee:

  • Latenz und Verfügbarkeit sind Fremdvariablen.

  • Sicherheitszertifizierung in produktionsnahen Netzen wird aufwändig.

  • Laufende Kosten (Traffic, Egress, Managed-Services) sind schwer kalkulierbar und im Worst Case höher als Edge-CapEx.

In der Praxis fahren wir hybride Architekturen: Feature-Engineering + Erstinferenz am Edge, Training + Flottensteuerung + Langzeitanalyse zentral (on-prem). Cloud im Public-Sinne wird nur genutzt, wenn es keine Souveränitätsbedenken gibt und die Latenzanforderungen es erlauben.

Praxis: Lessons learned aus Textil und Bahn
Textilfertigung: Spinnereien und Webmaschinen

  • Herausforderung:

  • Spindeln laufen 12.000–20.000 U/min, Drehzahl variiert mit Material und Auftrag. Klassische FFT ohne Ordnungsanalyse führt zu wandernden Peaks und Fehlalarmen.

  • Sensor-Montage ist heikel: Dünnwandige Gehäuse führen zu Basisbiegeeffekten, die hochfrequente Signale verfälschen. Magnetfüße sind bequem, aber schlecht für >5 kHz Diagnostik.

  • Lösung:

  • Tacho-Abgriff am Antrieb, resampling auf Winkel (Order Tracking). Damit werden Lagerdefektfrequenzen stationär und detektierbar.

  • Envelope-Analyse im Band 5–15 kHz für Wälzlager; spektrale Kurtosis zur Bandwahl. Features: Hüllkurven-RMS, Peaks bei BPFI/BPFO/Harmonics, Seitenbänder mit Abstand der Rotationsordnung.

  • Klein gehaltenes Modell: Gradient Boosted Trees auf ~30 handgebauten Features, quantisiert und am Edge ausgeführt. Kein Blackbox-CNN notwendig.

  • Alarmlogik mit Persistenz über drei Produktionszyklen; zusätzlich Auftragswechsel als Reset-Event, um Kontextwechsel sauber zu behandeln.

  • Ergebnis:

  • >90% Reduktion der Fehlalarme gegenüber einer naiven FFT+Schwellwert-Lösung.

  • Rohdaten-Export nur bei Ereignissen; täglicher Traffic pro Maschine 100 GB.

  • Integration mit CMMS: Automatisiertes Ticket mit Komponententyp, Defekthypothese, verlinkter Spektrums-PNG aus dem Edge.

Bahnbetrieb: Traktionsmotoren und Getriebe

  • Herausforderung:

  • Funklöcher, harte Umweltbedingungen (Temperatur, Vibration), sporadische Energiezyklen. Zugriff auf TCMS-Signale ist möglich, aber mit strengen Sicherheits- und Zertifizierungsauflagen verbunden.

  • Lastprofile ändern sich stark (Steigungen, Anfahrten). Klassische Schwellen sind unbrauchbar.

  • Lösung:

  • Nutzung vorhandener Stromsensorik (MCSA), Abtasten 10 kHz, Spektrogramme werden nicht übertragen, sondern am Edge in Kennzahlen verdichtet: Seitenbandenergie um Netz-/PWM-Grundfrequenzen, Schlupfbandbreiten, harmonische Muster.

  • Hybridmodell: Anomalieerkennung (Isolation Forest) zur Frühwarnung + regelbasierte Detektoren für bekannte Fehlerbilder (z. B. defekte Zahnflanken → Seitenband-Peaks in Ordnungen 1× bis 3× Rotationsfrequenz). Modelle laufen in C++/Rust-Services mit harter Latenzgarantie.

  • Store-and-forward: Ereignisfenster ±60 s werden im Zug gepuffert und über Depot-WLAN nachts in den on-prem Objektspeicher gekippt. KPIs gehen periodisch via MQTT, wenn Netz vorhanden.

  • Sicherheitsarchitektur gemäß IEC 62443: Zonen/Conduits, ausgehende Verbindungen, mutual TLS, signierte Updates.

  • Ergebnis:

  • Frühere Detektion von beginnenden Lager- und Zahnradschäden, planbare Tauschfenster.

  • Kein betriebskritischer Pfad hängt am Mobilfunk. Bei Netzausfall bleibt die Anomaliedetektion aktiv.

Fertigung allgemein: Druckluft und Hilfsaggregate

  • Herausforderung:

  • Stark schwankende Lasten, aber niedrige Frequenzinhalte. Hier sind hohe Abtastraten unnötig.

  • Lösung:

  • Edge aggregiert 1-Hz-KPIs (Druck, Temperatur, Stromaufnahme, Einschaltdauer) und berechnet einfache Drift-/Wirkungsgradkennzahlen. Alarme werden per MQTT an das on-prem Backend gegeben, das die Work Orders erstellt.

  • Ergebnis:

  • Mit minimaler Edge-Rechenleistung werden echte Energiekosten- und Ausfallrisiken transparent, ohne Cloud-Abhängigkeit.