N-CMAPSS DS02: Realistic Flight Envelopes

Simulator vs. Black Box: A Step Closer to Reality

Driving simulators have come a long way, but every autonomous-vehicle team in the world also collects real road miles — because no simulator captures the full distribution of weather, road wear, and bizarre human drivers you encounter on day one of deployment. The same realisation eventually came to the prognostics community.

C-MAPSS taught a generation of researchers how to compare RUL methods. But its operating conditions are six fixed centroids that the simulator samples uniformly — an idealisation that hides the slow, structured way real flights move through the envelope. NASA's 2021 release of the N-CMAPSS dataset added that missing realism: real flight profiles, variable-length missions, and a richer sensor catalog including unmeasurable internal states.

What Makes N-CMAPSS Different

The two qualitative changes that matter most: continuous flight profiles (cycles within a flight are correlated, not i.i.d.) and virtual sensors (channels representing internal engine states like turbine efficiency margins, which a real airline cannot directly instrument but a simulator can expose). Together they make N-CMAPSS more physically realistic but also more demanding of the model.

Interactive: One Flight, Two Datasets

Below is the same time horizon, plotted twice. Red is a 200-cycle slice of a C-MAPSS FD002 engine: altitude jumps every cycle between the six fixed regimes from Section 2.2. Green is one representative N-CMAPSS DS02 flight profile: smooth taxi → takeoff → climb → cruise → descent → approach → landing.

Both arrangements are valid prognostic data. The C-MAPSS view is statistically clean — conditions are uniformly sampled so every cycle stands on its own. The N-CMAPSS view is physically real — cycles are correlated within a flight and the regime is autocorrelated for tens or hundreds of cycles at a time.

The HDF5 Layout, Up Close

DS02 is a single HDF5 file with ten top-level datasets. Knowing the names is 90% of the battle:

The development split (suffix _dev) carries engines 2-9; the held-out test split (_test) carries different engines never seen during training. Standard 80/20 split machinery does not apply — you get a fully held-out engine population.

Python: Loading DS02 With h5py

Twenty lines, no surprises if you have used HDF5 before. The trick is the boolean mask on the auxiliary units column — HDF5 evaluates it on disk so we never materialise the whole 5-million-row matrix in memory.

1import h5py
2import numpy as np
3import pandas as pd
4
5# DS02 ships as a single ~2.3 GB HDF5 file.  Each top-level group is one
6# of the eight subsets {DS01..DS08}; we focus on DS02 in this book.
7PATH = "data/raw/N-CMAPSS_DS02-006.h5"
8
9
10def load_ds02_unit(path: str, unit_id: int):
11    """Load all flights from one engine ('unit') in DS02.
12
13    Returns
14    -------
15    X_s   : (N, 14)  float32 - 'sensor' channels (Xs)
16    X_v   : (N, 14)  float32 - 'virtual sensor' channels (Xv)
17    aux   : (N, 8)   float32 - auxiliary metadata (unit, cycle, ...)
18    rul   : (N,)     float32 - per-cycle Remaining Useful Life
19    """
20    with h5py.File(path, "r") as f:
21        # Use boolean mask on the auxiliary 'unit' column to slice by engine.
22        units = f["A_dev"][:, 0].astype(np.int32)
23        mask  = units == unit_id
24
25        X_s   = f["X_s_dev"][mask].astype(np.float32)
26        X_v   = f["X_v_dev"][mask].astype(np.float32)
27        aux   = f["A_dev"  ][mask].astype(np.float32)
28        rul   = f["Y_dev"  ][mask, 0].astype(np.float32)
29
30    return X_s, X_v, aux, rul
31
32
33# ----- Use it on engine 2 of DS02 -----
34X_s, X_v, aux, rul = load_ds02_unit(PATH, unit_id=2)
35
36print("X_s shape :", X_s.shape)
37print("X_v shape :", X_v.shape)
38print("aux shape :", aux.shape)
39print("rul range :", rul.min(), "->", rul.max())
40print("flights   :", int(aux[:, 1].max()))    # column 1 of A is flight number
41
42# X_s shape : (104897, 14)
43# X_v shape : (104897, 14)
44# aux shape : (104897, 8)
45# rul range : 0.0 -> 64.0
46# flights   : 64

Why one engine at a time?

DS02 is large enough that loading all 8 dev units in one shot eats nearly a gigabyte. Real preprocessing pipelines load one unit, slice into windows, save the windowed tensor, and move on — never holding more than one engine in memory.

PyTorch: A Flight-Level Dataset

A close cousin of the C-MAPSS Dataset from Section 2.1, with two differences: a longer default window (50 vs 30, since DS02 cycles are denser) and an option to include the 14 virtual-sensor channels alongside the 14 physical ones.

1import h5py
2import numpy as np
3import torch
4from torch.utils.data import Dataset
5
6
7class NCMAPSSFlightDataset(Dataset):
8    """One DS02 unit (engine), exposed as sliding windows over its
9    concatenated flight history.
10
11    For each window we return:
12        X     : (window, n_features) - X_s + X_v concatenated
13        rul   : scalar RUL target at the end of the window
14    """
15
16    def __init__(self, h5_path: str, unit_id: int, window: int = 50,
17                 use_virtual: bool = True):
18        with h5py.File(h5_path, "r") as f:
19            units = f["A_dev"][:, 0].astype(np.int32)
20            mask  = units == unit_id
21
22            X_s = f["X_s_dev"][mask].astype(np.float32)
23            if use_virtual:
24                X_v   = f["X_v_dev"][mask].astype(np.float32)
25                feats = np.concatenate([X_s, X_v], axis=1)   # (N, 28)
26            else:
27                feats = X_s                                  # (N, 14)
28
29            ruls = f["Y_dev"][mask, 0].astype(np.float32)
30
31        self.feats   = torch.from_numpy(feats)
32        self.ruls    = torch.from_numpy(ruls)
33        self.window  = window
34        self.starts  = list(range(0, len(self.feats) - window + 1))
35
36    def __len__(self) -> int:
37        return len(self.starts)
38
39    def __getitem__(self, idx: int):
40        s = self.starts[idx]
41        e = s + self.window
42        X = self.feats[s:e]              # (window, n_features)
43        y = self.ruls[e - 1]             # scalar RUL at end of window
44        return X, y
45
46
47# ----- Use it -----
48ds = NCMAPSSFlightDataset(
49    "data/raw/N-CMAPSS_DS02-006.h5", unit_id=2,
50    window=50, use_virtual=True,
51)
52print("samples:", len(ds))
53X, y = ds[0]
54print("X shape:", tuple(X.shape), "  y:", float(y))
55# samples: 104848
56# X shape: (50, 28)   y: 64.0

Realism-Check Datasets in Other ML Areas

The pattern “train on a clean simulator, validate on a realism-check dataset” is everywhere in modern ML. Each pair below maps one-to-one to the C-MAPSS → N-CMAPSS relationship.

The book's methodological core (multi-task learning + gradient balancing + asymmetric safety loss) transfers to all of these — what you swap is the loader and the per-condition normaliser.

Where C-MAPSS Numbers Fail to Transfer

Two reasons. First, N-CMAPSS's virtual sensors are physics-rich information that encodes pressure ratios and turbine efficiencies; methods like DKAMFormer that build a knowledge graph over them get a real boost. Second, the continuous flight envelope means conditions are autocorrelated - a model can implicitly track the regime over tens of cycles rather than learning to invariate to abrupt jumps. The accuracy-safety tradeoff is still real, but the relative weights between RMSE and NASA do shift.

The book's honest claim. The proposed framework wins decisively on multi-condition C-MAPSS and matches the best within the framework on N-CMAPSS. It does not displace domain-specific physics engineering on benchmarks where physics knowledge is the primary lever.

Takeaway

• N-CMAPSS is the realism check. Real flight envelopes, variable-length missions, 28 channels (14 physical + 14 virtual), one ~2.3 GB HDF5 file.
• HDF5 lets you slice on disk. f['X_s_dev'][mask] reads only the rows you need.
• Different geometry, different winners. The continuous flight envelope makes physics-based methods (DKAMFormer) comparatively stronger on N-CMAPSS than on multi-condition C-MAPSS.
• Same Dataset shape, longer windows. Window=50 is conventional on N-CMAPSS; the rest of the API matches our C-MAPSS class.
• Use both. Train and ablate on C-MAPSS for compute economy; validate the headline result on N-CMAPSS before claiming victory.