An engine produces readings as it runs. Some change as components wear. Could a computer learn those patterns and estimate how much useful life remains?
That question gives you a concrete way to explore AI in aerospace. In a May 2024 account of its operations, easyJet described using predictive maintenance to anticipate component replacement and reduce technical delays. easyJet’s account.
For a student project, NASA provides a place to start: C-MAPSS, a collection of simulated turbofan engine degradation data. You can use it to practice building and evaluating a prediction model. NASA describes four datasets covering different operating conditions and fault combinations. NASA’s data repository.
The project below is AeroEd’s suggested learning sequence. Begin with charts in a spreadsheet; move into basic Python when you are ready to train a model. The useful outcome is a result you can explain, including where it goes wrong.
Start with one question and one dataset
Use this question to keep your scope manageable: Given the readings available at this point, how many operating cycles remain before the simulated engine fails? That quantity is called remaining useful life, or RUL.
On the NASA repository page, find dataset 6, “Turbofan Engine Degradation Simulation.” Download its archive, then unpack the enclosed CMAPSSData.zip. Start with FD001: its readme describes one operating condition, one fault mode, and 100 training engines. Dataset archive and readme.
Three files matter:
train_FD001.txtcontains engine histories that continue to failure.test_FD001.txtcontains different engine histories that stop before failure.RUL_FD001.txtsupplies the remaining-life answers at the end of those test histories.
Read the included documentation before importing the files. Each data row contains an engine identifier, a cycle number, three operating settings, and 21 sensor readings. The files use spaces as separators and have no column headings. File format and test setup.
Keep the downloaded files unchanged. Put your charts, calculations, and notes in separate files so you can retrace your work.
Look at the readings before choosing a model
Open the training file and choose one engine. Plot a sensor reading against cycle number, then repeat for a few other sensors and engines.
Write down what you see. Which readings drift? Which stay nearly constant? Does a pattern that looks clear on one engine also appear on another? Label the sensor by its documented name or column number; avoid guessing a physical meaning or unit.
If you are new to coding, this is a useful first stopping point. A chart with a careful explanation is a completed piece of analysis. Use it to decide what you want a model to learn.
Give the model examples without giving it the answers
For each row in the training file, calculate a target:
Remaining cycles = that engine’s final recorded cycle − its current cycle.
For example, if a training engine’s history ends at cycle 200, its target at cycle 150 is 50. This calculation uses a completed history to label an earlier observation. Keep the final cycle and calculated target out of the model’s input columns: they reveal the answer.
Next, split the training engines into two groups. A reasonable first experiment uses 80 engines for learning and 20 for validation, which means checking your choices on engines withheld from training. Keep every row from a given engine in the same group. Save the engine lists so you can repeat the comparison.
In Python, scikit-learn’s GroupShuffleSplit can make this division using engine IDs as groups; its split sizes refer to groups. Use the identifier to organize the experiment and exclude it from the prediction inputs. Grouped splitting documentation.
Treat NASA’s separate test files as a final check after you have chosen your approach. If you normalize readings or select useful sensors, learn those choices from the training group alone. Information from validation or test data can otherwise make a result look better than it deserves. scikit-learn’s explanation of data leakage.
Compare against a simple starting point
Before training a model, make a baseline: predict the median remaining life from your training rows for every validation row. Record its error. This gives your next experiment something concrete to improve on.
Then try a small regression model, such as a decision tree, using sensor readings as inputs. Regression estimates a number. Change one choice at a time and compare both approaches on the same validation rows.
Once you settle on an approach, fit it using the full training file. For the final test, make one prediction at each test engine’s last recorded cycle and compare it with the corresponding answer in RUL_FD001.txt, in engine-number order. Do not treat the last observed test cycle as a failure: those histories were deliberately cut short.
Explain the mistakes in cycles
Calculate mean absolute error: find the distance between each prediction and its answer, then average those distances. Report the result in cycles and specify whether it comes from validation rows or the final test endpoints.
Also inspect individual mistakes. Consider this invented example, where an engine actually has 30 cycles remaining:
| Prediction | Absolute error | What the mistake means |
|---|---|---|
| 50 cycles remaining | 20 cycles | The estimate gives the engine too much remaining life. |
| 10 cycles remaining | 20 cycles | The estimate gives the engine too little remaining life. |
Both predictions have the same absolute error. Their implications differ. Show a few overly optimistic estimates in your report, alongside cases where the model works well.
A result on this simulation establishes how your experiment performed under its test conditions. Using predictions for actual maintenance would require further evidence about the equipment, operating conditions, and consequences of errors. Keep your project’s claim tied to the data you tested.
Turn the work into something you can discuss
Package the project so a classmate, teacher, or mentor can understand it:
- The question and data: identify FD001, link the source, and credit A. Saxena and K. Goebel, as NASA requests.
- The method: show your input columns, engine split, baseline, and model settings.
- The evidence: include sensor charts, comparison scores, and examples of prediction errors.
- The limits: explain what you have learned from simulated engines and what you would need to investigate next.
If you use an AI assistant for coding help, keep a note of its contribution and check that you can explain each calculation. Reproduce a few labels and errors by hand before trusting the output.
Your interests can shape the next question. The aerospace engineering pathway offers context for understanding the machinery. Aviation maintenance connects you to inspection and troubleshooting work. Avionics is a route into the electronics that produce and carry measurements.
For today, start with one engine, one sensor chart, and a paragraph explaining what you observe.
Sources and the NASA download checked September 14, 2026. The project sequence is AeroEd’s educational suggestion; the numerical error example is illustrative.