The RUL Prediction Problem

The Fuel Gauge for Machines

Every car has a gauge that says “42 miles to empty.” You do not get a stream of fuel-tank pressures, fuel-pump currents, and ECU error codes — the gauge has already collapsed all of that into one number you can act on. Predictive maintenance is the same idea, applied to anything that wears out: squeeze the multi-dimensional sensor history into a single scalar — Remaining Useful Life — that a maintenance scheduler can actually use.

That is why nearly every paper, dashboard, and commercial diagnostic product in this space ultimately reports one number: $\widehat{\text{RUL}}$ in cycles, hours, or kilometres remaining. It is the actionable statistic. The model can be a transformer, a CNN, an LSTM, or three of them stacked — the output that the maintenance crew sees is one number.

RUL, Formally

Let $\mathbf{x}_t \in \mathbb{R}^{d}$ be the vector of sensor readings at cycle $t$, where $d$ is the number of sensors (14 for C-MAPSS, 20 for N-CMAPSS DS02). A run-to-failure trajectory is the sequence $\mathbf{x}_1, \mathbf{x}_2, \ldots, \mathbf{x}_{t_{\text{fail}}}$.

At any moment $t \le t_{\text{fail}}$, the true remaining useful life is the trivially obvious quantity

$\text{RUL}_t = t_{\text{fail}} - t.$

The prediction problem is to estimate $\text{RUL}_t$ from a window of past readings only — the model never gets to peek at $t_{\text{fail}}$. Concretely, given a window of the last $W$ cycles

$\mathbf{X}_t = (\mathbf{x}_{t-W+1},\, \mathbf{x}_{t-W+2},\, \ldots,\, \mathbf{x}_t) \in \mathbb{R}^{W \times d},$

we want a function $f_\theta$ (a neural network with parameters $\theta$) such that

$\widehat{\text{RUL}}_t \;=\; f_\theta(\mathbf{X}_t) \;\approx\; t_{\text{fail}} - t.$

That is the entire problem statement. The next 28 chapters are how to choose $f_\theta$ well, what training objective to put on $\theta$, and how to get good values for $\theta$ from data.

Interactive: One Sample, Up Close

The diagram below is a single engine that fails at cycle 200. Five sensors are drifting away from their healthy baselines on physically-motivated curves (vibration up, oil pressure down, exhaust temperature up, and so on). The orange band is the model's 30-cycle input window; the green panel is the scalar RUL the model is asked to predict.

Drag the cursor and watch how a single engine generates many training samples — each cursor position is one row of the supervised dataset. Drag the failure cycle down to 100 and you simulate a short-lived engine; drag the window size down to 5 and the model has almost no context to work with. By Chapter 7 we will commit to $W = 30$ and $d = 17$ for C-MAPSS — this is just where those numbers come from.

Where Do RUL Labels Come From?

For supervised learning we need ground-truth RUL labels on the training data. There is exactly one way to obtain them: run the engine to failure and timestamp the moment it dies. Once you know $t_{\text{fail}}$, every earlier cycle gets its label $t_{\text{fail}} - t$ for free.

That single-sentence procedure has a consequence that haunts every working prognostic dataset: most engines never run to failure. They get pulled for unrelated reasons (lease return, fleet retirement, regulatory inspection), and you have a sensor history but no label. NASA C-MAPSS dodges this by being a simulation: every trajectory in FD001-FD004 is run to failure by construction. Real-world prognostic projects almost always have to confront the “censoring” problem — we will return to it at the end of this section.

Python: Build (X, y) Pairs From One Engine Run

Before any neural network, the labelling procedure is forty lines of NumPy. We simulate one run-to-failure trajectory, slide a 30-cycle window across it, and emit one (input, target) pair per cursor position — 171 pairs from a single engine with 200 cycles of life.

1import numpy as np
2
3# ----- Step 1. Simulate one engine's run-to-failure trajectory -----
4np.random.seed(7)
5n_cycles  = 200          # this engine fails at cycle 200
6n_sensors = 5            # five physical sensors
7
8baseline  = np.array([1.0, 2.0, 0.5, 1.5, 0.8])     # nominal value of each sensor
9drift_dir = np.array([-0.5, +0.7, -0.3, +0.4, -0.6]) # which way each one drifts
10alpha     = np.array([1.5, 2.0, 1.2, 1.8, 2.5])     # how steep the drift becomes
11
12cycles  = np.arange(n_cycles)            # 0, 1, ..., 199
13t_norm  = cycles / n_cycles              # normalised time in [0, 1)
14sensors = np.zeros((n_cycles, n_sensors))
15for s in range(n_sensors):
16    sensors[:, s] = (baseline[s]
17                     + drift_dir[s] * t_norm ** alpha[s]
18                     + 0.05 * np.random.randn(n_cycles))
19
20print("sensor matrix shape:", sensors.shape)        # (200, 5)
21
22
23# ----- Step 2. Slice into supervised (X, y) training pairs -----
24WINDOW = 30
25
26def build_pairs(sensors, failure_cycle, window=WINDOW):
27    """One run-to-failure trajectory -> (X, y) regression pairs."""
28    n = len(sensors)
29    X_list, y_list = [], []
30    for end in range(window, n + 1):
31        X_list.append(sensors[end - window:end])    # past window of cycles
32        y_list.append(failure_cycle - end)          # cycles still to go
33    return np.stack(X_list), np.array(y_list)
34
35X, y = build_pairs(sensors, failure_cycle=n_cycles)
36
37print("X.shape:", X.shape, "y.shape:", y.shape)     # (171, 30, 5) (171,)
38print("first pair RUL :", y[0])                     # 170
39print("last  pair RUL :", y[-1])                    # 0

From one engine to a fleet

Real C-MAPSS gives you 100 engines in FD001 and 260 in FD002. The pattern stays identical — loop over engines, call build_pairs for each, concatenate the results. We will do exactly that in Chapter 7 once we have a real PyTorch Dataset.

PyTorch: The Same Idea, but as a Dataset

Now the same logic in PyTorch idiom. Two changes only: numpy.ndarray becomes torch.Tensor, and the loop becomes a Dataset subclass that DataLoader can batch and shuffle. The numerical output is identical.

1import numpy as np
2import torch
3from torch.utils.data import Dataset, DataLoader
4
5class EngineRunDataset(Dataset):
6    """One engine's run-to-failure trajectory wrapped as a PyTorch Dataset."""
7
8    def __init__(self, sensors: np.ndarray, failure_cycle: int, window: int = 30):
9        super().__init__()
10        self.window = window
11        self.failure_cycle = failure_cycle
12        # Move sensor matrix onto a tensor once; slicing later is free.
13        self.sensors = torch.from_numpy(sensors).float()
14        self.starts = list(range(0, len(sensors) - window + 1))
15
16    def __len__(self) -> int:
17        return len(self.starts)
18
19    def __getitem__(self, idx: int) -> tuple[torch.Tensor, torch.Tensor]:
20        start = self.starts[idx]
21        end   = start + self.window
22        X = self.sensors[start:end]                        # (window, n_sensors)
23        y = torch.tensor(float(self.failure_cycle - end))  # scalar RUL target
24        return X, y
25
26
27# ----- Use it -----
28ds = EngineRunDataset(sensors, failure_cycle=200, window=30)
29loader = DataLoader(ds, batch_size=8, shuffle=False)
30
31X_batch, y_batch = next(iter(loader))
32print("batch X:", tuple(X_batch.shape))   # (8, 30, 5)
33print("batch y:", tuple(y_batch.shape))   # (8,)
34print("y values:", y_batch.tolist())     # [170, 169, 168, 167, 166, 165, 164, 163]

RUL Beyond Aerospace

The (window, sensor)-to-scalar regression formulation is dominant outside aerospace too. Whenever the failure mode is gradual, monotonic, and partially observable through sensor data, the same machinery applies. The label definition shifts because the “cycle” is replaced by whatever unit of life the equipment uses.

Every row of that table consumes a window-shaped input and emits a scalar time-to-event. The CNN-BiLSTM-Attention backbone we build in Part III, the gradient-balancing loss in Part VI, the Pareto-frontier picture in Chapter 23 — all of them transfer with at most a renaming of variables.

The Censoring Pitfall

Every introduction to RUL skips the elephant in the corner: the only engines you can label are the ones that did fail. Engines pulled early, swapped out for unrelated reasons, or still happily running at the moment your dataset snapshot is taken provide censored observations — you know the engine survived past some cycle, but you do not know $t_{\text{fail}}$.

C-MAPSS sidesteps the problem by being entirely run-to-failure simulation data, which is one of the reasons it has dominated the prognostic benchmark landscape since 2008. Real-world projects almost always need to either restrict the training set to fully-observed runs or borrow techniques from the survival literature. We flag it here, defer it to Chapter 29 (“Limitations & Open Research Questions”), and proceed with the un-censored idealisation for the next twenty-eight chapters.

The clean version of the problem. Run-to-failure trajectories with known failure cycle. Sliding-window inputs. Scalar RUL targets. A neural network $f_\theta$ that maps one to the other. That is the world we will work in.

Takeaway

• RUL is the fuel gauge for machines. Every model in this book, no matter how exotic its internals, ultimately emits one scalar per window: cycles to failure.
• Supervised pairs come from sliding windows. One engine with 200 cycles of life and a window size of 30 yields 171 (input, target) pairs.
• Python and PyTorch say the same thing differently. NumPy gives you the math directly; PyTorch Dataset/DataLoadergives you batching, shuffling, and parallel I/O for free.
• Most real datasets are censored. C-MAPSS hides this behind simulation; outside it, censoring is the thing you have to engineer around.