Use Case
RUL-Prognose
Ziel des POC ist die Vorhersage der verbleibenden Nutzungsdauer von Turbofan-Triebwerken auf Basis von Betriebszyklen, Settings und Sensorsignalen. Der POC adressiert damit einen klassischen Predictive-Maintenance-Fall.
Predictive Maintenance POC • Stand 24.03.2026
Turbofan Predictive Maintenance POC auf NASA C-MAPSS: Daten, Modellwahl, Vierdatensatz-Vergleich und Visualisierung der Modellgüte.
Diese Seite beschreibt den aufgebauten Predictive-Maintenance-Prototypen für Turbofan-Engines. Im Mittelpunkt stehen die NASA-C-MAPSS-Daten, die RUL-Prognose (Remaining Useful Life), die Modellwahl, die Bewertungsmethodik und der Vergleich aller vier Standard-Datensätze FD001 bis FD004.
Management Summary
Kompakte Einordnung des POC und der wichtigsten Ergebnisse.
Daten
NASA C-MAPSS
Verwendet wurde das NASA C-MAPSS Turbofan Engine Degradation Simulation Data Set mit vier Standard-Subsets FD001 bis FD004, die sich deutlich in Betriebsbedingungen und Fehlerkomplexität unterscheiden.
Bestes Modell
HistGradientBoosting
In der schnellen Mehrdatensatz-Runde war HistGradientBoostingRegressor auf allen vier Datensätzen das beste Modell. Damit zeigt der POC, dass ein gut gebauter tabellarischer Ansatz für diesen Anwendungsfall bereits sehr belastbare Ergebnisse liefern kann.
Wichtigstes Ergebnis
FD001 gut, FD002/FD004 hart
FD001 und FD003 liefern deutlich bessere Ergebnisse als FD002 und FD004. Genau dadurch wird sichtbar, dass die Schwierigkeit des Predictive-Maintenance-Problems stark von Betriebsmodi, Fehlermischung und Signalcharakter abhängt.
Was sind das für Daten?
Der POC basiert auf einem der bekanntesten Referenzdatensätze für Remaining-Useful-Life-Prognosen.
NASA C-MAPSS
Simulierte Turbofan-Degradation
Die Daten beschreiben simulierte Turbofan-Triebwerke über viele Betriebszyklen. Jede Engine startet in einem gesunden Zustand und degradiert über die Zeit. Beobachtet werden pro Zyklus mehrere Betriebsparameter und Sensorsignale. Ziel ist die Schätzung der verbleibenden Lebensdauer bis zum Ausfall.
Vier Subsets
FD001 bis FD004
Die vier Standard-Subsets unterscheiden sich vor allem in der Zahl der Betriebsbedingungen und Fehlermodi. FD001 und FD003 sind typischerweise einfacher, FD002 und FD004 deutlich schwieriger. Dadurch eignen sie sich gut, um Robustheit und Generalisierbarkeit verschiedener Modelle zu vergleichen.
| Datensatz | Train Rows | Test Units | Features nach Engineering | Bestes Modell | Test RMSE | Test MAE |
|---|---|---|---|---|---|---|
| FD001 | 20,631 | 100 | 65 | HistGradientBoosting | 14.12 | 10.76 |
| FD002 | 53,759 | 259 | 89 | HistGradientBoosting | 26.92 | 19.05 |
| FD003 | 24,720 | 100 | 70 | HistGradientBoosting | 14.64 | 10.69 |
| FD004 | 61,249 | 248 | 89 | HistGradientBoosting | 28.09 | 20.78 |
Wie wurde der POC gebaut?
Die Auswertung ist methodisch deutlich komplexer als ein einfacher Tabellen-Fit.
Zielvariable
RUL mit Cap
Für jedes Triebwerk wurde die Remaining Useful Life über die Zyklen berechnet. Für das Training wurde die Zielvariable auf 130 Zyklen gecappt, um extreme Frühphasenwerte zu stabilisieren und die Lernaufgabe praxisnäher zu machen.
Feature Engineering
Zeitreihen aus Rohsensorik
Verwendet wurden Rohsensoren, Betriebssettings, log(time_cycles), cycle², erste Differenzen pro Engine, gleitende Mittelwerte über Fenster von 5 Zyklen sowie Abweichungen vom Startzustand je Sensor. Zusätzlich wurden konstante bzw. extrem varianzarme Signale entfernt.
Leakage-Vermeidung
GroupKFold nach Engine
Die Cross-Validation wurde nicht zufällig über Zeilen gemacht, sondern per GroupKFold nach Engine-ID. Dadurch landen Zyklen derselben Engine nie gleichzeitig in Train und Validation. Genau das ist für ehrliche PdM-Auswertung zentral.
Modelle
Verglichene Verfahren
Verglichen wurden Ridge Regression als lineare Baseline, Random Forest als robuste nichtlineare Baseline und HistGradientBoostingRegressor als starker, schneller Kandidat für tabellarische Zeitreihenfeatures.
Bewertung
Mehrere Metriken
Bewertet wurde über CV RMSE, CV MAE, Test RMSE, Test MAE und zusätzlich einen PHM-ähnlichen Score. Dadurch wird nicht nur die durchschnittliche Fehlergröße sichtbar, sondern auch die asymmetrische Bestrafung von Fehlprognosen.
Charakter des POC
Schnelle, ehrliche Vergleichsrunde
Der POC ist bewusst eine beschleunigte Modellrunde. Es wurden keine tiefen neuronalen Architekturen und keine umfangreichen Hyperparameter-Suchen eingesetzt. Das Ziel war ein robuster, nachvollziehbarer und schnell kommunizierbarer Erstbenchmark.
Vergleich aller vier Datensätze
Die folgenden Grafiken zeigen für jeden Datensatz dieselben zwei Perspektiven: Modellvergleich im Backtesting und Testprognosen auf Engine-Ebene.
FD001 • CV
FD001: CV-RMSE nach Modell
FD001 ist der stärkste Datensatz im POC. HistGradientBoosting liegt klar vorn, was die Wahl als Standardmodell zusätzlich stützt.
FD001 • Test
FD001: True vs Predicted RUL (≤130)
Die Vorhersagen liegen im gecappten Bereich relativ nah an der Diagonalen. FD001 bleibt damit der anschaulichste Fall für eine gut funktionierende RUL-Prognose.
FD002 • CV
FD002: CV-RMSE nach Modell
Auch auf FD002 bleibt HistGradientBoosting vorn. Die Fehler sind aber bereits deutlich höher, was auf die gesteigerte Komplexität des Datensatzes hinweist.
FD002 • Test
FD002: True vs Predicted RUL (≤130)
Auch nach Filterung auf Werte bis 130 bleibt die Streuung deutlich größer als bei FD001. Das zeigt die höhere Schwierigkeit bei mehreren Betriebsbedingungen und komplexeren Fehlermustern.
FD003 • CV
FD003: CV-RMSE nach Modell
FD003 bestätigt den starken Eindruck eines vergleichsweise gut lösbaren Datensatzes. Die Modellwahl bleibt konsistent, und die Fehler liegen nahe bei FD001.
FD003 • Test
FD003: True vs Predicted RUL (≤130)
Auch im gefilterten Bereich bleiben die Testprognosen deutlich besser als auf FD002 und FD004. Das spricht für klarere Degradationsmuster und ein günstigeres Signal-Rausch-Verhältnis.
FD004 • CV
FD004: CV-RMSE nach Modell
FD004 gehört zu den härtesten Fällen im gesamten Benchmark. HistGradientBoosting bleibt zwar bestes Modell, aber auf deutlich höherem Fehlerniveau.
FD004 • Test
FD004: True vs Predicted RUL (≤130)
Die breite Streuung bleibt auch nach Filterung sichtbar und unterstreicht, wie herausfordernd FD004 ist. Der Datensatz zeigt klar, dass gute Resultate auf einfacheren Subsets nicht automatisch auf komplexere Szenarien übertragbar sind.
Feature-Interpretation am Beispiel FD001
FD001 ist das beste Subset und eignet sich deshalb gut, um die interne Modelllogik sichtbar zu machen.
FD001 Feature Importance
Welche Signale waren wichtig?
Die Feature-Importance-Ansicht für FD001 zeigt, dass die Prognose nicht auf einem einzelnen Sensor beruht. Das Modell nutzt mehrere kombinierte Signale aus Sensorik, Verlauf und Abweichung vom Startzustand.
Interpretation
Warum FD001 gut funktioniert
- geringere Komplexität als FD002 und FD004,
- klarere Degradationsmuster,
- stärker nutzbare Beziehung zwischen Sensorverläufen und Restlebensdauer,
- weniger schwierige Kombinationen aus Betriebsmodi und Fault-Szenarien.
Was zeigt der Vierdatensatz-Vergleich fachlich?
Genau hier wird die eigentliche Komplexität des POC sichtbar.
Nicht alle Datensätze sind gleich
Problemcharakter ändert sich stark
FD001 und FD003 verhalten sich deutlich günstiger als FD002 und FD004. Ein Modell, das auf einem „einfachen“ Subset gut aussieht, muss deshalb nicht automatisch auf komplexeren Szenarien überzeugen.
Modellwahl bleibt stabil
Robuste Baseline
Trotz unterschiedlicher Datensatzschwierigkeit bleibt HistGradientBoosting auf allen vier Subsets das beste Modell der schnellen Runde. Das spricht für eine stabile, gut begründbare Startwahl im POC.
Mehr als nur ein guter Plot
Generaliserbarkeit ist der eigentliche Test
Die Vierdatensatz-Auswertung macht sichtbar, dass der POC nicht nur ein einzelnes gutes Beispiel zeigt, sondern das Problem über mehrere Schwierigkeitsgrade hinweg systematisch prüft.
Warum ist die Auswertung fachlich komplex?
Der POC wirkt auf den ersten Blick tabellarisch, ist methodisch aber deutlich anspruchsvoller.
Zeitreihe pro Asset
Kein i.i.d.-Problem
Die Daten bestehen aus Verläufen pro Engine. Dadurch sind klassische zufällige Splits problematisch, weil dieselbe Engine über viele Zyklen Informationen über ihre Zukunft preisgibt. Saubere Auswertung muss assetbezogen denken.
Mehrere Datensatzcharaktere
FD001 bis FD004 unterscheiden sich stark
Ein Modell, das auf FD001 sehr gut funktioniert, muss auf FD004 nicht annähernd dieselbe Qualität erreichen. Genau deshalb ist die Mehrdatensatz-Auswertung wichtig: Sie zeigt, wie robust ein Ansatz wirklich ist.
Featurefrage
Was ist signalhaltig?
Nicht jeder Sensor trägt gleich viel Information. Manche Signale sind konstant, manche rauschen, manche werden erst in Kombination mit Differenzen, gleitenden Mitteln oder Verlaufsmustern nützlich. Das erklärt die starke Rolle des Feature Engineerings im POC.
Metriken
RMSE allein reicht nicht
Predictive Maintenance bewertet nicht nur Durchschnittsfehler. Zu frühe und zu späte Warnungen haben unterschiedliche operative Konsequenzen. Deshalb ist ein zusätzlicher PHM-orientierter Score sinnvoll.
Business-Sicht
RUL ist keine Klassifikation
Der POC prognostiziert keine einfache Ja/Nein-Störung, sondern eine verbleibende Nutzungsdauer in Zyklen. Das macht Interpretation, Fehlerkosten und Entscheidungslogik anspruchsvoller.
Produktionsreife
PoC ist nicht Endzustand
Für einen späteren produktionsnahen Einsatz wären zusätzliche Modellfamilien, Unsicherheitsabschätzung, Drift-Logik, Asset-spezifische Kalibrierung und Dashboard-/Alerting-Logik die nächsten sinnvollen Schritte.
Fazit des POC
Was aus der bisherigen Analyse belastbar abgeleitet werden kann.
Was der POC zeigt
- Das NASA-C-MAPSS-Setting lässt sich sauber als Predictive-Maintenance-RUL-Aufgabe operationalisieren.
- Ein gut gebauter tabellarischer Ansatz mit Zeitreihenfeatures kann bereits belastbare Ergebnisse liefern.
- HistGradientBoosting ist in dieser beschleunigten Vergleichsrunde der beste Standardkandidat.
- Die Vierdatensatz-Sicht macht die echte Schwierigkeit des Problems sichtbar.
Was der nächste Schritt wäre
- zusätzliche Modelle wie XGBoost, LightGBM, TCN, LSTM oder Transformer vergleichen,
- Unsicherheiten und Alarmgrenzen modellieren,
- Dashboard mit Engine-Risiko, Priorisierung und Wartungsempfehlungen bauen,
- Business-Übersetzung von RUL in Wartungslogik und Asset-Entscheidungen ergänzen.
Artefakte und Quellen
Relevante Projektdateien und Ergebnisartefakte aus dem Workspace.
Wichtige lokale Projektpfade:
- Projekt: `nasa-cmapss-pdm-demo/`
- Training: `src/train_cmapss_fast.py`
- Ergebnisse: `results_fast/`
- Präsentationen: `presentation/`