Engineering-Details, die man nicht weglassen darf

  • Zeit-Synchronisation: PTP in der Zelle, NTP zur Werkszeit. Ohne das sind Multi-Sensor-Merkmale (z. B. Strom vs. Vibration) nicht koregistriert und Modelle driften scheinbar „grundlos“.

  • Kalibrierung und Selbsttest: Ein wöchentlicher Selbsttest (z. B. künstliches Testsignal, Sensor-Health-Check via Bias/Noise) verhindert „stumme Sensoren“. Edge-Komponenten sollten Sensor-Drift erkennen und melden.

  • Modell-Explainability am Edge: Spektrale Heatmaps und Feature-Attributionen (z. B. SHAP auf Bäume) lokal vorrechnen und als Artefakt mitschicken. Instandhalter akzeptieren keine Blackbox-Alarme.

  • Versionsführung bis ins Kabel: Sensor-ID, Montageort, Montagedatum, Drehmoment, Firmware – alles gehört in die Metadaten. Sonst sind historische Vergleiche wertlos.

Wann Cloud-Analyse trotzdem Sinn ergibt

  • Entwicklungsphase: Zentrale Trainingsumgebung, viele Experimente, Benchmarks – ja, aber mit on-prem Ressourcen, sofern Souveränität kritisch ist.

  • Niedrigfrequente Daten: Temperaturen, Drücke, Zählerstände. Wenn Latenz unwichtig und Bandbreite klein, kann zentrale Analyse genügen.

  • Cross-Asset-Lernen: Flottenweite Mustererkennung, Transfer Learning. Rohdaten nur kuratiert und pseudonymisiert übertragen, nie ungezielt streamen.

Fazit: Edge-first ist kein Dogma, sondern eine Konsequenz aus Physik, Netzwerken und Governance. Wer Latenz, Bandbreite und Souveränität ernst nimmt, bringt Feature-Engineering und Erstinferenz an die Maschine, hält Training und Flottensteuerung zentral (on-prem) und integriert beides sauber in CMMS/ERP. Genau diese Aufteilung unterscheidet einen POC von einer produktionsreifen PdM-Lösung.

FAQ
1) Welche Hardware brauche ich am Edge – CPU, GPU, NPU?

  • Für klassische Vibrations- und Stromsignalanalyse reicht eine moderne x86/ARM-CPU. Eine 1D-FFT mit 51,2 kHz, Fenster 4096 Punkte, 75% Overlap schafft selbst ein Low-Power-SoC in <1 ms. GPU/NPU ergeben Sinn bei vielen parallelen Kanälen oder Deep-Learning-Inferenz auf Spektrogrammen. Wichtig ist thermische Reserve und Langzeitstabilität, nicht Peak-TOPs.

2) Wie aktualisiere ich Modelle sicher bei Air-Gap oder instabilem Netz?

  • Modelle als signierte Artefakte paketieren, über den on-prem Broker (MQTT/Kafka) oder periodische Wartungsfenster verteilen. Geräte authentifizieren sich per Zertifikat, validieren Signatur vor Aktivierung. Canary-Rollout auf Teilmenge, automatisches Rollback bei KPI-Verschlechterung. Für harte Air-Gaps: Wechseldatenträger mit Offline-Signaturprüfung und Audit-Log.

3) Wie verhindere ich Fehlalarme ohne monatelange Labelsammlung?

  • Edge-Features robust machen (Order Tracking, Envelope, Persistenz), Anomaliescores über Zeit glätten, Hysterese und Mindestpersistenz einbauen. Zusätzlich regelbasierte „Guards“ für bekannte Betriebszustände (Anlauf, Notstopp, Auftragwechsel) hinterlegen. Kuratierte Ereignisfenster sammeln und mit Instandhalter-Bewertungen rückspielen – wenige Dutzend gelabelte Events verbessern Schwellen massiv.

4) RUL am Edge oder zentral?

  • RUL-Modelle leben von viel Historie und guter Kontextmodellierung – das spricht für zentrale Berechnung. Am Edge liefern Sie Health Indices und kondensierte Lebensdauerschätzer (z. B. verbleibende Zyklen in grober Granularität), wenn es der Use Case verlangt. Die endgültige RUL-Prognose, insbesondere mit Unsicherheiten, gehört in die Zentrale.

5) Wie integriere ich PdM sauber in bestehende CMMS/ERP-Systeme?

  • Einheitliche Asset-IDs und Komponententaxonomie (z. B. ISO 14224), klare Event-Schemas (Fehlerhypothese, Evidenzen, Dringlichkeit), REST/GraphQL-Schnittstellen on-prem, kein Schatten-Workflow. Wichtig ist die Rückkopplung: Ticketstatus, Root Cause, getauschte Teile müssen als Labels zurückfließen. Ohne diese Schleife stagniert das Modell.

Wenn Sie eine Edge-first-Architektur für Ihre PdM-Landschaft aufbauen oder einen Cloud-POC in die Produktion überführen möchten, achten wir auf genau diese Linien: deterministischer Edge-Pfad, on-prem Governance und belastbare CMMS-Integration – kein Hype, sondern robuste Ingenieursarbeit. (→ alpitype.de/leistungen/)