On-Premise und Datensouveränität: Technische Konsequenzen statt Schlagworte

  • Datenpfad unter eigener Kontrolle: MQTT/Kafka on-prem, Timeseries DB on-prem, Modell-Registry on-prem. Kein Vendor-Lock-in durch proprietäre Cloud-Services.

  • Performance: Edge-Inferenz reduziert Latenz und Datenvolumen (Feature statt Rohdaten übertragen). Rechenbudget planen: z. B. 100 Maschinen mit je 25.6 kHz Vibration -> Edge-Feature-Extraktion ist Pflicht.

  • Governance: Versionierung, Rollbacks, Audit-Trails der Modelle; Datenhaltungs- und Löschkonzepte DSGVO-konform.

  • Security-by-Design: Segmentierung (OT/IT), signierte Container, Härtung der Gateways.

  • Wirtschaftlich: Bandbreitenkosten sinken; Trainingscluster on-prem sind mit modernen Workstations/GPU-Knoten ausreichend, wenn Feature-Engineering am Edge geschieht.

Konkrete Implementierungs-Schritte (90–180 Tage)

  • Woche 0–4: Zieldefinition und Daten-Scoping

  • Welche Komponenten, welche Fehlermodi, welche geschäftliche Zielfunktion (Stillstandskosten, Ersatzteilkosten)?

  • Sensor-Audit: Samplingraten, Synchronisierung, Tachoeingang vorhanden?

  • CMMS-Assessment: Datenqualität, Ticket-Workflow, Feld für Rückmeldungen definieren.

  • Woche 4–10: Edge-Pipeline und Feature-Set

  • Filterketten, Windowing, Feature-Extraktion; Datenqualität-Metriken einbauen.

  • On-Prem-Infrastruktur (MQTT/Kafka, Timeseries, Objekt-Store) bereitstellen.

  • Woche 8–14: AE-MVP

  • Unsupervised Modell + Change-Point; adaptive Schwellen; Alarm-Hysterese.

  • CMMS-Integration mit Pflichtfeldern für Befunde; Dashboard mit Lead-Time, Bestätigungsquote.

  • Woche 12–20: RUL-Fokus für häufige Moden

  • Auswahl 1–2 Moden mit >20 Fällen; HI-Definition, Degradationsmodell, Unsicherheiten.

  • Validierung out-of-time; wirtschaftliche Scorefunktion definieren.

  • Woche 18–26: Betriebsfestigkeit

  • Drift-Monitoring, Canary-Rollouts, Edge-Failover testen (Store-and-Forward).

  • Dokumentation/Audit-Trail; Schulung Instandhaltung; Alarm-Playbooks verankern.

Metriken, die wirklich zählen

  • Anomalie: Lead-Time-Verteilung, Bestätigungsquote, Alarmrate/Maschine/Tag, Zeit bis Erstreaktion, MTBF-Shift.

  • RUL: Termintreue innerhalb Unsicherheitsintervall, wirtschaftlicher Nettonutzen, Anzahl gebündelter Wartungen, vermeidene Ausfälle.

  • Daten: Prozent valide Windows, Sensor-Drift-Rate, Lückenquote, Synchronisationsfehler.

  • Betrieb: Deployment-Zeit bis Rollback, Edge-Downtime, Latenz Puffer bis Alarm.

Typische Stolpersteine und Gegenmaßnahmen

  • Label-Armut: Erzwingen Sie Rückmeldungen im CMMS. Kleine Pflichtformulare schlagen Freitext.

  • Nichtstationarität: Lastzustände clustern (aus Strom/Speed), per Cluster eigene Modelle/Schwellen.

  • Frühzeitige “RUL-Showcases”: Ohne robuste Daten -> bei AE bleiben und Fehlerkatalog aufbauen; RUL später.

  • Thresholds per Bauchgefühl: Quantil- und Kosten-basierte Schwellen, keine Magic Numbers.

  • Black-Box-Blindflug: Erklärbare Features beibehalten, auch wenn ein DL-Modell eingesetzt wird. Für Audits und Akzeptanz entscheidend.

Welche Rolle spielt AlpiType?
Wir bauen produktionsreife, souveräne PdM-Systeme – keine Demos. Unsere Architekturen laufen on-prem, DSGVO-konform, ohne US-Cloud-Abhängigkeit. Wir übernehmen technische Verantwortung: Requirements, Entwicklung, Qualitätssicherung, Betrieb. Und wir sagen auch “nein”, wenn die Datenlage RUL nicht hergibt – dann liefern wir eine robuste Anomalieerkennung mit sauberem Eskalationspfad. Mehr dazu: (→ alpitype.de/leistungen/)

FAQ

1) Wie viele Run-to-Failure-Fälle brauche ich für eine belastbare RUL?

  • Für einfache, homogene Verschleißmodi: ab ~20–30 vollständigen Fällen kann ein parametrisches Modell (z. B. Weibull) mit sinnvollen Unsicherheiten funktionieren.

  • Für heterogene Moden oder variierende Duty-Cycles: eher 50+ Fälle und/oder hierarchische Modelle, die Maschinenunterschiede explizit modellieren.

  • Wichtiger als die reine Anzahl sind: saubere Zeitstempel, definierter Ausfallkriterium (Failure Definition), Dokumentation von Wartungsresets.

2) Wie evaluiere ich eine unüberwachte Anomalieerkennung ohne Labels?

  • Proxy-Metriken: Alarmrate pro Zeit, Stabilität der Scores je Lastzustand, Drift-Indikatoren.

  • Operativ: Bestätigungsquote der Alarme nach Inspektion, Lead-Time bis Befund, wirtschaftliche Wirkung (vermeidene Schäden).

  • Einführung von “Weak Labels”: einfache Regeln (z. B. Vibration > X + Temperaturanstieg), die als vorläufige Ground Truth dienen, bis echte Labels vorhanden sind.

3) Welche Samplingrate ist “richtig” für Vibration?

  • Hängt am Ziel und Bauteil. Für Wälzlagerdiagnose ist häufig 6.4–25.6 kHz sinnvoll, um relevante Bänder und Hüllkurven gut abzubilden.

  • Zu hoch ist auch schlecht: Datenlawinen ohne Mehrwert. Besser: zielgerichtetes Bandpass- und Feature-Engineering am Edge, Rohdaten nur ereignisbasiert puffern.

4) Wie integriere ich PdM sauber ins CMMS?

  • Einheitliche Fehler-Taxonomie und Pflichtfelder für Rückmeldungen; keine Freitext-Wildwiese.

  • Ticket-Anreicherung: Sensor-Snippet, Feature-Vektor, Lastzustand, Modellversion.

  • Rückkopplung: Jede Bestätigung/Ablehnung fließt in Threshold-Update/Modellretraining; ideal als periodischer, automatisierter Prozess.

5) Edge oder Cloud?

  • Für industrielle Umgebungen mit Souveränitätsanforderungen: Edge-Inferenz + On-Prem-Backend. Rohdaten bleiben lokal, Features/Alarme gehen ins zentrale System.

  • Cloud ist nicht per se böse – aber in DACH-Industrien kollidieren oft Compliance, Performance und Abhängigkeiten mit den realen Anforderungen. Wir priorisieren On-Prem und vermeiden US-Cloud-Lock-ins.

Fazit
Wählen Sie das Verfahren nach Ziel und Daten, nicht nach Hype. Anomalieerkennung ist Ihr Arbeitstier für schnellen Start und breiten Abdeckungsgrad – wenn Schwellen, Eskalation und Feedback sitzen. RUL entfaltet seinen wirtschaftlichen Hebel dort, wo die Daten Disziplin zeigen: konsistente Degradation, saubere Wartungshistorien, stabile Sensorik. Beide Ansätze sind keine Gegensätze, sondern Phasen eines Reifegrads. Bauen Sie die Architektur souverän, on-prem und erklärbar – dann wird aus PdM kein Experiment, sondern ein Betriebsmittel.