Vom Sensor zur Vorhersage: Wie eine PdM-Plattform tatsächlich funktioniert

„Wir setzen einfach ML auf die Sensordaten" ist die Handwellenbewegung, die tausend gescheiterte PdM-Projekte einleitet. Die Realität ist, dass das ML-Modell vielleicht 20 % des Systems ausmacht. Die restlichen 80 % bestehen darin, Daten zuverlässig von Sensoren zu Modellen zu bringen und Vorhersagen zuverlässig von Modellen zu Menschen.

So funktioniert die gesamte Pipeline in einer modernen Plattform, vom physischen Sensor bis zum Smartphone des Ingenieurs.

Schicht 1: Edge-Erfassung

Industrielle Sensoren erzeugen Daten mit sehr unterschiedlichen Raten. Ein Schwingungs-Beschleunigungssensor an einem Lager tastet mit 12.800 Hz ab. Ein Temperaturfühler aktualisiert alle 30 Sekunden. Ein Durchflussmesser sendet alle 5 Sekunden Daten.

Ein Edge-Gateway übernimmt:

Protokollübersetzung — OPC-UA, MQTT, Modbus RTU und analoge 4-20-mA-Signale benötigen jeweils unterschiedliche Treiber
Lokale Pufferung — Netzwerkausfälle dürfen keine Daten verlieren. Das Gateway speichert Messwerte lokal und synchronisiert bei Wiederherstellung der Verbindung
Downsampling — 12,8 kHz Schwingungsdaten werden zusammengefasst (RMS, Spitzenwert, Kurtosis) für die kontinuierliche Überwachung, wobei periodisch Roh-Wellenformen für die Spektralanalyse erfasst werden

Die Protokoll-Herausforderung

Protokollübersetzung klingt einfach in einer Herstellerpräsentation. In der Praxis ist sie die Stelle, an der die meisten PdM-Installationen auf ihre erste Hürde stoßen.

OPC-UA ist der moderne Standard, doch „Standard" ist großzügig formuliert — jeder Anlagenhersteller implementiert ihn anders. Sie werden Tage damit verbringen, Sicherheitszertifikate zu konfigurieren (OPC-UA verlangt X.509-Zertifikatsaustausch), Node-IDs auf aussagekräftige Tag-Namen abzubilden und mit Servern umzugehen, die nur eine Teilmenge der Spezifikation implementieren. Neuere Anlagen sind in der Regel konform; alles vor 2015 ist ein Glücksspiel.

Modbus RTU/TCP ist zuverlässig, aber rudimentär. Das Register-Mapping ist komplett manuell — die Sensordokumentation sagt Ihnen „Register 40001 ist Schwingung X-Achse, 32-Bit-Float, Big-Endian", und Sie übersetzen das in die Konfiguration. Multiplizieren Sie das mit 50-200 Sensoren pro Standort, und Sie verstehen, warum allein das Protokoll-Mapping eine volle Woche Inbetriebnahme verschlingen kann.

4-20-mA-Analogsignale erfordern zusätzliche Hardware: Signalkonditionierer, Analog-Digital-Wandler und sorgfältige Erdung zur Vermeidung von Störeinflüssen. Ein 0,1-mA-Offset auf einer 4-20-mA-Stromschleife übersetzt sich direkt in einen Messfehler, den Ihr ML-Modell als Prozessänderung interpretieren wird.

Edge-Hardware-Anforderungen werden oft unterschätzt. Ein Gateway, das 200 Sensoren bedient, benötigt ausreichend Rechenleistung für lokale Pufferung (mindestens 32 GB Speicher für 72 Stunden Offline-Fähigkeit), Protokollübersetzung (CPU-intensiv bei OPC-UA-Verschlüsselung) und optionale Edge-Inferenz. Industrietaugliche Gateways von Herstellern wie Advantech, Moxa oder Siemens IOT2050 kosten typischerweise 500-2.000 € pro Einheit, mit ARM- oder x86-Prozessoren und industriellen Temperaturbereichen (-40 bis 70 °C).

Schicht 2: Streaming-Ingestion

Daten verlassen den Edge als MQTT-Nachrichten und gelangen in einen Message Broker (typischerweise Apache Kafka), der bereitstellt:

Persistenz — Nachrichten bleiben bis zum Konsum erhalten und überdauern Service-Neustarts
Multi-Consumer — Dieselben Daten speisen gleichzeitig Echtzeitverarbeitung, Cold Storage und ML-Pipelines
Schema-Validierung — Avro-Schemas validieren die Datenstruktur, bevor sie die Pipeline betritt

In dieser Phase werden Daten validiert: Sensor-IDs werden verifiziert, Zeitstempel auf Drift geprüft und Messwerte außerhalb physikalischer Grenzen markiert. Ein Schwingungsmesswert von -500 mm/s oder eine Temperatur von 3.000 °C wird in Quarantäne gestellt, nicht an ML-Modelle weitergeleitet. Quality Scoring (0-100) versieht jeden Messwert mit einem Tag, und alles unter 50 wird herausgefiltert, bevor es das Feature Engineering erreicht.

Schicht 3: Stream Processing

Ein Stream Processor (Apache Flink) transformiert Rohmesswerte in Echtzeit zu ML-fähigen Features:

Rolling Statistics — Mittelwert, Standardabweichung, RMS, Kurtosis über 60-Sekunden-, 5-Minuten- und 30-Minuten-Fenster
Trend-Erkennung — Steigt die Schwingung, ist sie stabil oder fällt sie in der letzten Stunde?
Sensorübergreifende Korrelation — Steigende Temperatur bei stabiler Schwingung deutet auf Umgebungsänderung hin, nicht auf Degradation
Frequenzmerkmale — FFT auf Schwingungsdaten extrahiert Lagerfrequenzen, Zahneingrifffrequenzen und Harmonische

Feature Engineering im Detail

Die Qualität der ML-Vorhersagen wird hier bestimmt, nicht in der Modellarchitektur. Einige konkrete Beispiele:

Rolling RMS vs. Spitze-Spitze: RMS-Schwingung erfasst die Gesamtenergie und eignet sich gut zur Erkennung von Unwucht oder Fluchtungsfehler. Spitze-Spitze erfasst transiente Stöße und eignet sich besser zur Früherkennung von Lagerschäden (wo Metall-auf-Metall-Kontakt kurze, scharfe Impulse erzeugt). Die Berechnung beider Werte in mehreren Fenstergrößen (60 s, 300 s, 1800 s) gibt dem Modell verschiedene Perspektiven auf denselben Degradationsprozess.

FFT und Lagerdefektfrequenzen: Für schwingungsbasierte Lagerüberwachung reicht die reine FFT nicht aus — Sie müssen wissen, wonach Sie suchen. Jedes Wälzlager hat vier charakteristische Defektfrequenzen, die alle aus der Lagergeometrie und der Drehzahl abgeleitet werden:

BPFO (Ball Pass Frequency Outer) = (N/2) × RPM × (1 - d/D × cos(α)) — Außenringdefekt
BPFI (Ball Pass Frequency Inner) = (N/2) × RPM × (1 + d/D × cos(α)) — Innenringdefekt
BSF (Ball Spin Frequency) = (D/2d) × RPM × (1 - (d/D × cos(α))²) — Wälzkörperdefekt
FTF (Fundamental Train Frequency) = RPM/2 × (1 - d/D × cos(α)) — Käfigdefekt

Dabei ist N = Anzahl der Wälzkörper, d = Kugeldurchmesser, D = Teilkreisdurchmesser, α = Kontaktwinkel. Der Stream Processor berechnet die FFT auf den rohen Schwingungswellenformen und extrahiert die Amplitude bei diesen spezifischen Frequenzen (plus 2. und 3. Harmonische). Eine steigende Amplitude bei BPFO mit Harmonischen ist ein Lehrbuch-Außenringdefekt — die Art von Muster, die im Zeitbereich-RMS unsichtbar, im Frequenzbereich jedoch unverwechselbar ist.

Die Wahl der Fenstergröße ist wichtiger, als die meisten Teams vermuten. Ein 60-Sekunden-Fenster erfasst schnelle Transienten (Motoranlauf, Laständerungen). Ein 30-Minuten-Fenster glättet diese und zeigt langsame Trends. Nur eine Fenstergröße zu verwenden, zwingt das Modell, sowohl schnelle als auch langsame Dynamik aus einer einzigen Darstellung zu lernen — beide bereitzustellen gibt dem Modell die zeitliche Auflösung, um „der Motor ist gerade angelaufen" von „dieses Lager wird schlechter" zu unterscheiden.

Schicht 4: Speicherung

Verarbeitete Daten landen in einer Zeitreihendatenbank (TimescaleDB), die optimiert ist für:

Hypertables — Automatische Partitionierung nach Zeit für schnelle Bereichsabfragen
Continuous Aggregates — Vorberechnete Rollups (1 min, 5 min, 1 h) für Dashboard-Performance
Aufbewahrungsrichtlinien — Hot-Daten (90 Tage) in PostgreSQL, Cold-Daten exportiert in Columnar Storage für Langzeitanalysen

Multi-Tenancy wird auf Datenbankebene mit Row-Level Security (RLS) erzwungen. Jede Abfrage — ob von der API, einem Dashboard oder einem internen Service — wird automatisch auf den authentifizierten Mandanten beschränkt. Dies ist keine Filterung auf Anwendungsebene, die ein Bug umgehen könnte; es ist eine Datenbankbeschränkung, die mandantenübergreifenden Datenzugriff ohne Superuser-Zugangsdaten physisch unmöglich macht.

Schicht 5: ML-Inferenz

Drei Modelltypen pro Anlage:

Anomalieerkennung

Ein LSTM Autoencoder lernt das normale Betriebsmuster jeder Anlage. Hoher Rekonstruktionsfehler = aktuelles Verhalten entspricht nicht den gelernten Mustern. Das Modell verarbeitet ein gleitendes Fenster multivariater Sensordaten (typischerweise 60 Zeitschritte) und gibt einen Rekonstruktionsfehler-Score aus. Wenn dieser Score einen gelernten Schwellenwert überschreitet (pro Anlage aus gesunden Betriebsdaten kalibriert), wird eine Anomalie markiert.

Restnutzungsdauer (RUL)

LSTM-Modelle schätzen die Tage bis zum nächsten Wartungsereignis. Ein LSTM, das 14 rohe Sensorwerte verarbeitet, erreichte einen RMSE von 11,48 Tagen auf dem NASA C-MAPSS-Benchmark — das bedeutet, die Vorhersagen sind typischerweise auf 11 Tage genau. Für die praktische Wartungsplanung ist das der Unterschied zwischen „diese Woche einplanen" und „diesen Monat einplanen".

Fehlerdiagnose

Ein 1D-CNN mit Attention klassifiziert Schwingungswellenformen in Fehlerkategorien: Innenringschaden, Außenringschaden, Wälzkörperdefekt, Käfigdefekt, Fluchtungsfehler, Unwucht. Vortrainiert auf dem CWRU-Lagerdatensatz und feinabgestimmt auf anlagenspezifische Daten.

Trainingsdaten-Anforderungen und Genauigkeitserwartungen

Die Modellleistung hängt stark vom Datenvolumen ab:

| Datenvolumen | Bestes Modell | Erwartete Genauigkeit | |---|---|---| | < 1.000 Samples | Isolation Forest | Erkennt grobe Anomalien, kein RUL | | 1.000 - 50.000 | LSTM Autoencoder | Gute Anomalieerkennung, einfaches RUL | | 50.000 - 200.000 | LSTM + LightGBM | Starke Anomalie- + RUL-Vorhersagen | | > 200.000 + GPU | TranAD (Transformer) | State-of-the-Art Anomalie + RUL |

Für eine Neuinstallation ohne historische Daten bieten vortrainierte Modelle (trainiert auf dem CWRU-Lagerdatensatz und NASA C-MAPSS-Turbofan-Daten) sofortige Basisfähigkeit. Diese sind nicht perfekt für Ihre spezifischen Anlagen, aber sie kodieren allgemeine Degradationsphysik, die sich überraschend gut auf ähnliche Anlagenklassen übertragen lässt.

Schicht 6: Alert Engine

Die Alert Engine wendet Geschäftsregeln an:

Schweregradabbildung — Anomalie-Score-Schwellenwerte werden auf Schweregrade abgebildet. Ein Score 2× über dem Schwellenwert ist WARNUNG; 4× ist KRITISCH. Diese Multiplikatoren sind pro Anlagenklasse konfigurierbar, da eine „kritische" Anomalie an einer Backup-Pumpe andere betriebliche Auswirkungen hat als derselbe Score an einem Single-Point-of-Failure-Kompressor.
Deduplizierung — Ein degradierendes Lager erzeugt kontinuierliche Anomalie-Scores über dem Schwellenwert. Ohne Deduplizierung würden Sie bei jedem Inferenzzyklus (typischerweise alle 30-60 Sekunden) einen Alarm erhalten. Die Alert Engine gruppiert zusammengehörige Anomalien nach Anlage und Fehlermodus und sendet einen einzelnen Alarm mit Aktualisierungen statt einer Flut sich wiederholender Benachrichtigungen.
Eskalation — WARNUNG innerhalb eines konfigurierbaren Zeitfensters (Standard: 4 Stunden) nicht bestätigt? Eskalation auf KRITISCH und Benachrichtigung der nächsten Ebene. KRITISCH nicht in 1 Stunde bestätigt? Alarmierung des Bereitschaftsdienstes.
SHAP-Erklärungen — Jeder Alarm zeigt, welche Sensoren wie stark beigetragen haben. Das ist keine Option oder Premium-Funktion — es ist der Unterschied zwischen einem Alarm, der untersucht wird, und einem, der abgetan wird.

Integrationsmuster

Alarme müssen die Menschen dort erreichen, wo sie arbeiten. Die Alert Engine unterstützt gleichzeitig mehrere Zustellkanäle:

PagerDuty / OpsGenie — für Bereitschaftsrotation und Eskalation
ServiceNow / SAP PM / Maximo — automatisch erstellte Arbeitsaufträge mit Diagnosekontext
Webhooks — für individuelle Integrationen mit internen Systemen
E-Mail / SMS — für Teams ohne Incident-Management-Plattform
Mobile Push — für Bediener auf dem Werksgelände

Das Cold-Start-Problem

Die häufigste Frage bei neuen PdM-Installationen: „Was passiert am ersten Tag ohne Daten?"

Hier scheitern die meisten eigenentwickelten PdM-Projekte. Das Training eines LSTM Autoencoder von Grund auf erfordert Wochen sauberer Betriebsdaten. Das Training eines RUL-Modells erfordert historische Ausfalldaten — die Sie möglicherweise nicht in strukturierter Form haben.

Eine moderne Plattform adressiert den Cold Start in drei Phasen:

Tag 1-7: Vortrainierte Modelle. Modelle, die auf öffentlichen Benchmark-Datensätzen (CWRU-Lager, NASA C-MAPSS-Turbofantriebwerke) und kundenübergreifend anonymisierten Daten trainiert wurden, bieten sofortige Anomalieerkennung. Sie erfassen keine anlagenspezifischen Fehlermodi, erkennen aber gängige Degradationsmuster (Lagerverschleiß, Unwucht, thermisches Durchgehen), die 60-70 % der Ausfälle rotierender Maschinen ausmachen.

Woche 2-4: Baseline-Lernen. Mit 2-4 Wochen kontinuierlicher Daten trainiert die Plattform anlagenspezifische Modelle. Der LSTM Autoencoder lernt, wie „normal" für jede Maschine unter ihren spezifischen Betriebsbedingungen aussieht. Die Anomalieerkennungsgenauigkeit verbessert sich deutlich, weil das Modell nun weiß, dass Pumpe 7A bei 1.800 U/min normalerweise mit 1,8 mm/s schwingt — nicht nur, dass „Pumpen zwischen 0 und 10 mm/s schwingen".

Monat 2+: Progressives ML. Mit wachsendem Datenbestand aktualisiert die Plattform automatisch die Modelle: Isolation Forest → LSTM Autoencoder → TranAD (Transformer-basiert). Jedes Upgrade verbessert sowohl die Erkennungsempfindlichkeit als auch die Vorlaufzeit. Der Übergang erfolgt automatisch — die Plattform verfolgt die Leistungskennzahlen jedes Modells und befördert das bessere Modell, wenn es sich auf zurückgehaltenen Validierungsdaten bewährt hat.

Schicht 7: Aktion

Alarme lösen aus: PagerDuty/ServiceNow-Benachrichtigungen, automatisch erstellte Arbeitsaufträge, Webhooks für individuelle Integrationen und Echtzeit-Dashboard-Visualisierung. Die letzte Schicht schließt den Kreis: vorhergesagter Ausfall → Alarm → Untersuchung → Arbeitsauftrag → Reparatur → Bestätigung. Jeder Schritt wird protokolliert, wodurch der Audit-Trail entsteht, der in das Modell-Retraining und die ROI-Messung zurückfließt.

Prevly verwaltet alle sieben Schichten als Managed Platform. Sehen Sie es in Aktion mit einer interaktiven Demo, die echte ML-Modelle verwendet.

Weiterführende Artikel: Restlebensdauer-Vorhersage erklärt · Schreibgeschütztes OPC-UA-Monitoring · Einstieg in die Schwingungsanalyse