• Feature-Drift-Überwachung am Edge: Berechne und sende nicht nur Scores, sondern auch die Verteilung zentraler Features (Mittel, Varianz, Top-Quantile) je Woche. So fällt Verschlechterung der Sensorbefestigung oder neue Prozessmodi früh auf.
  • Versionierung der Datenformate: Protobuf-Schemas mit expliziten Feldern und Major/Minor-Version. Niemals „JSON mit optionalen Keys“. Edge und Backend können dann unabhängig aktualisiert werden.
  • Ressourcen-Planung: CPU-Pinning für Erfassung/FFT getrennt von Netzwerkthreads. Puffer so dimensionieren, dass 1–2 s Backpressure die Pipeline nicht kippen lassen.
  • Kalibrierung und Selbsttest: Beim Start kurze Selbsttest-Sequenz (weißes Rauschen per Shaker in der Werkstatt, im Feld: synthetische Kalibrierungsmuster selten möglich). Temperatur-Sensoren gegen bekannten Referenzpunkt vergleichen.
  • Schattenmodus: Neue Modelle laufen 2–4 Wochen „shadow“, Entscheidungen werden geloggt, aber nicht wirksam. Erst nach Gegenüberstellung mit Realität und alten Modellen aktivieren.
  • Rollout-Kanäle: „Stabil“, „Vorabtest“ pro Werk/Maschine/Zug. Kein Big-Bang. Klare Metriken für Promotionskriterien (Alarmpräzision, CPU, Drop-Rate, Uptime).

Wann Anomalieerkennung, wann RUL?

  • Anomalieerkennung:
  • Wenn kaum Labels vorliegen, Fehlerbilder variieren, schnelle Detektion wichtiger ist als genaue Restlaufzeit.
  • Gute Wahl für Vibration im Frühstadium (Stoßanteile), Stromsignaturen bei variabler Last.
  • Liefert Scores, braucht betriebliche Schwellen/Hysteresen.
  • RUL:
  • Wenn klarer Degradationsprozess messbar ist (z. B. Anstieg der Hüllkurvenenergie in bandbegrenztem Bereich, Temperaturanstieg unter konstanter Last), ausreichend historische Verläufe bis zum Ausfall existieren und Wartungsfenster planbar sind.
  • RUL-Modelle sollten konservativ sein; auf Edge nur leichte Regressoren (lineare/GBM auf Langzeit-Features), schwere Zeitreihenmodelle zentral trainieren und validieren.
  • Hybrid:
  • Erst Anomalieerkennung -> bei persistenter Anomalie wechselt die Pipeline in den Degradationsmodus und beginnt RUL-Schätzung. Das funktioniert gut in Textillinien, wenn Anomalien länger als X Zyklen anhalten.

On-Premise-Anforderungen: Datensouveränität in der Produktion

  • Datenlokalität: Rohdaten verbleiben im Werk oder Fahrzeug. Nur Feature-Aggregate und selektive Stichproben verlassen das Edge-Gerät. Kein kontinuierlicher Stream von Roh-Vibrationen nach außerhalb.
  • Getrennte Domänen: Produktionsnetz (OT) und Unternehmens-IT bleiben entkoppelt. Der Edge-Computer hängt in der OT, spricht per streng kontrollierter Demilitarized Zone mit dem on-prem-Backend.
  • Audit und Nachvollziehbarkeit: Jede Modellentscheidung mit Hash der Modellversion, Feature-Summary, Schwellenstand und Kontext (Betriebsmodus, Drehzahl) protokollieren. So sind spätere Audits möglich.
  • Lieferkette und IP-Schutz: Keine Abhängigkeit von externen Cloud-Runtimes/Lizenzservern. Laufzeitbibliotheken lokal verfügbar, Lizenzen offline validierbar.

Werkzeuge und Betrieb

  • Build-Pipeline: reproduzierbare Builds, signierte Container, minimalistische Base-Images, statische Verlinkung wo sinnvoll. Test-Matrix (ARMv8/x86_64, mit/ohne AVX2/NEON).
  • Continuous Verification: synthetische Signale + aufgezeichnete Edge-Snippets als Regressionstests. Ziel ist nicht „Model Accuracy“ im Labor, sondern „Alarmqualität“ im Feld.
  • Observability: Edge sendet Health-Heartbeat (CPU, RAM, Sensorstatus, Zeitdrift, Paketverluste) alle 10–60 s. Alerting nicht nur auf Modellalarme, sondern auch auf Systemgesundheit.
  • Supportbarkeit: Remote-Shells sind in OT-Zonen oft verboten. Deshalb: Log-Bundles per Ein-Knopf-Export, klare Rotlicht-GRÜNLICHT-Indikatoren am Gerät, Service-USB-Stick mit Offline-Update inkl. Signaturprüfung.

Wie man entscheidet: Edge vs. Zentral – eine praktische Heuristik

  • Sampling >1 kHz, Reaktionszeit <500 ms, intermittierende Konnektivität: Edge-Inferenz.
  • Sampling 1 min, stabile Verbindung, Aggregation reicht: zentral.
  • Sicherheitsrelevante Nebenwirkung der Entscheidung (z. B. Abschaltbefehl): Edge, aber mit klarer Safety-Abgrenzung und menschlicher Bestätigung.
  • Hohes Volumen an variierenden Betriebszuständen, wenige Labels: Edge-Anomalieerkennung + zentrales Lernen aus verifizierten Fällen.

Fazit

PdM, das im Betrieb trägt, ist eine Architektursache, keine „KI-Demo“. Bringen Sie die Inferenz an den Rand, dort wo Signale entstehen und Entscheidungen gebraucht werden. Halten Sie Training, Governance und Flottenbetrieb im souveränen Backend. Investieren Sie in Sensorik, Zeitbasis, Feature-Engineering und Update-Mechanik – das schlägt jedes zusätzliche Prozentpunktchen Modell-Accuracy aus dem Labor.

Wenn Sie eine bestehende Cloud-Pipeline haben, ist der Weg nicht „zurück“, sondern „nach vorn“: Features und leichte Modelle an den Rand, zentrale Schwergewichte für Analyse und Training behalten. So bleibt das System robust, auditierbar und im Eigentum Ihrer Organisation. (→ alpitype.de/leistungen/)

FAQ

1) Wie rolle ich Modellupdates über 500 Edge-Geräte aus, ohne die Produktion zu stören?

  • Nutzen Sie Rollout-Kanäle (Vorabtest/Stabil), zeitgesteuerte Wartungsfenster und A/B-Partitionen mit atomischen Switches. Modelle und Container signieren, Hardware/Modell-Kompatibilität in einer Registry pflegen. Erst Shadow-Mode, dann Aktivierung. Rollbacks müssen ohne physische Präsenz möglich sein.

2) Wie gehe ich mit unterschiedlicher Hardware (ARM/x86, mit/ohne Beschleuniger) um?

  • Modelle in ONNX/TorchScript halten, Build-Varianten mit Quantisierung (int8/fp16) erzeugen. Eine Kompatibilitätsmatrix in der Registry verhindert Fehlrollouts. Performance-Tests sind Teil der CI (synthetische Workloads + echte Snippets).

3) Wie erkläre ich Entscheidungen am Rand?

  • Loggen Sie Feature-Summaries und Zustandsautomatenübergänge neben dem Score. Bei Gradient Boosting: Feature-Importances pro Entscheidung. Bei CNN/TCN: saliente Frequenzbänder/Zeitscheiben ausweisen (z. B. via integrierter Gradients auf Feature-Maps), nicht „Neuron Heatmaps“. Wichtig ist die Übersetzung in domänenspezifische Befunde (z. B. „Anstieg Hüllkurvenenergie bei 3,1× Drehzahl“).

4) Wie verhindere ich, dass schlechte Sensorik mein PdM torpediert?

  • Mechanische Montage-Standards (Checklisten, Anzugsmomente), initiale Kalibrierung, regelmäßige Plausibilitätschecks (Sensor-Noise-Floor, Spektren-Referenz). Edge-seitig Drift-Wächter auf zentralen Features, Alarme bei Montagedefekten separat führen (keine „Zustands“-Alarme).

5) Wie beweise ich Nutzen ohne 12 Monate zu warten?

  • Starten Sie mit Anomalieerkennung und definieren Sie betriebliche KPIs: Fehlalarmrate, Erkennungszeit bis Ereignis, vermiedene Stillstände. Sammeln Sie verifizierte Fälle, um gezielte RUL-Modelle nachzuschieben. Nutzen Sie Shadow-Phasen und AB-Vergleiche über Linien/Züge hinweg.