Kaggle: NASA Turbofan Jet Engine (C-MAPSS)

Kaggle: NASA Turbofan Jet Engine (C-MAPSS) is the benchmark remaining-useful-life dataset for predictive maintenance, packaged as a product rather than an archive. Underneath sits NASA's Commercial Modular Aero-Propulsion System Simulation: four fleets of commercial turbofans degraded in simulation from healthy to failure, flown under one or six flight conditions and failing through one or two fault modes (HPC degradation alone, or HPC plus fan). Around it, Datadory delivers the same cycles as queryable rows - one observation per engine per operational cycle, 26 columns wide, with true remaining-useful-life labels joined to their test units.

The numbers explain the reputation. FD001 alone carries 20,631 labeled training cycles across 100 engines; the four subsets together put more than 80,000 cycles and roughly 700 engines into one schema. Roughly 46,500 recorded downloads and 161 linked notebooks make these fleets the default first contact teams have with prognostics - which is precisely why a normalized, sample-first route to them matters: everyone compares against this data, so getting it clean is worth doing once.

One cycle of one simulated engine, straight off the FD001 training trajectory, with the column vocabulary annotated beside it:

Five field groups carry the whole grid, and they are identical across all four subsets - what changes between FD001 and FD004 is how many flight conditions and fault modes each fleet flies, never the columns. Two groups identify the observation (unit number, time, in cycles), one fixes the operating context (three operational settings covering altitude, Mach number and throttle-resolver-angle regimes), one carries the physics (twenty-one sensor channels spanning temperatures, pressures, rotor speeds, fuel flow and oil characteristics, with simulated sensor noise deliberately mixed in), and the last supplies the target: true remaining useful life per test unit.

The folds below the table cover the derived views teams usually ask for next - named sensor channels instead of numbered ones, piecewise-RUL targets capped at the conventional 130-cycle maximum, and flight-regime clusters for the six-condition subsets. A scoped sample shows any of them cut to the subset you name.

• Geography - none, honestly. These are simulated engines, not tail numbers; there is no country, carrier or airport dimension to join against. The value is physical fidelity, and market resolution comes from other datasets in the slice.
• Temporal - a fixed research version: simulated at NASA, mirrored since 2019, complete run-to-failure trajectories rather than rolling windows. Nothing goes stale, and nothing new accrues by the calendar.
• Granularity - one row per engine per operational cycle, 26 columns wide, rolling up to per-unit training trajectories of roughly 128 to 198 cycles per engine in FD001 and materially longer lives under the six-condition subsets.

The honest caveat: because the fleets are fixed, the corpus grows by new experiments rather than new weeks. Plan for a deep baseline you validate against, not a live stream you monitor.

API, files, or your warehouse. Daily, weekly, or hourly.

You pick the channel and the cadence; the 26-column semantics above hold across all three. Rows arrive flattened - one observation per engine per cycle, sensor channels already named, the RUL label joined to its test unit - so no space-delimited parsing reaches your pipeline. Cadence changes are a settings conversation rather than a re-integration project, and a sample cut to your chosen subsets comes first either way.

• Data scientists and ML engineers train degradation and RUL models on labeled run-to-failure trajectories, publishing scores comparable to the literature because everyone evaluates on the same fleets.
• Developers and data-product builders wire ingestion once against a schema that never shifts mid-project, with labels arriving joined rather than as a separate file to reconcile.
• Reliability engineers calibrate alarm thresholds and maintenance intervals against simulated degradation before trusting them on live plant telemetry.
• Journalists, academics and students cite the benchmark behind the prognostics literature with provenance that survives review.
• Competitive-intel and product teams test condition-monitoring vendors' accuracy claims against published ground truth instead of vendor-selected case studies.

Data scientists and ML engineers land at relevance 3 - ground-truth failure labels are the rarest commodity in maintenance modeling, and 20,631 labeled cycles in FD001 alone make model comparison reproducible. Developers and builders also hit relevance 3: a fixed 26-column grid means ingestion tooling gets written once. Reliability engineering teams sit at relevance 2, calibrating thresholds against simulated failures cheaply. Academics and journalists ride at relevance 2 on citable provenance. Competitive-intel teams and market researchers land at relevance 1 - useful reference points, not recurring feeds. When the job widens beyond engines to batteries, bearings and tooling, the counterpart shelf is the NASA Prognostics Data Set Repository; when the job is macro machinery economics instead, it is the NBER-CES Manufacturing Industry Database - and the catalog stages the head-to-head vs NBER-CES Manufacturing Industry Database.

• The NASA Prognostics Data Set Repository widens the aperture to about twenty-one component archives - lithium-ion battery aging, bearing vibration, CNC milling tool wear, IGBT and capacitor aging - when the failure question outgrows turbofans.
• The NBER-CES Manufacturing Industry Database supplies the macro counterpoint: sixty-one years of output, employment and productivity per US manufacturing industry, for sizing the market a prognostics model serves.
• VDMA mechanical engineering statistics tracks German machine-building orders and shipments in near real time - demand context for the machinery these models will monitor.

The pairing logic is simple: this dataset answers how does a component fail, the others answer who cares and how much. Models built on failure physics get funded by business cases built on the macro panels.

Four things, all knowable upfront. First, the fleets are simulated: fidelity is physical, not geographic, so any analysis needing carriers, countries or routes needs a different dataset. Second, the sensor noise is deliberate - in the simulation as in real rigs - and treating it as a defect will mislead preprocessing. Third, the four subsets differ in difficulty, not schema: one condition and one fault mode in FD001, six conditions and two fault modes in FD004, so scope the sample to whichever spread matches your problem. Fourth, the mirror has been stable since 2019, which means reproducibility forever and freshness never - pair it with live telemetry when a model reaches production.

Because a benchmark is only as good as its cleanest copy. Datadory flattens the space-delimited originals to one schema, names the 21 sensor channels so columns stop being numbers, joins the RUL labels to their test units, and keeps the four subsets distinguishable so your FD001 baseline never quietly mixes with FD004. Start with a sample scoped to the subsets and channels you care about, then browse the rest of the slice on the industrial machinery supplies components data hub or the best industrial machinery datasets ranking.