Misata Logo
Misata Studio

Predictive maintenance

Declare when the machine fails.
The remaining useful life is then exact.

Most public predictive-maintenance data draws every row on its own. That is right for orders and payments and wrong for equipment, because a machine has a history. Misata inverts it: a unit draws a life, damage accumulates toward that exact moment, and every sensor follows the damage. Remaining useful life is solved for rather than annotated, which is what makes the label worth training on.

Dataset on Hugging Face Download the CSVs

Try the declaration

Move a slider and the fleet changes. The YAML underneath is the real input, not a mock-up of one, and the maths matches the engine rather than approximating it.

02460%25%50%75%100%failuremm/slife consumed
8 machines, lives drawn between 155 and 256 cycles, 1,570 rows in total. Every red dot is a failure, and every one of them lands where the declaration said it would.
8

one machine each, followed to failure

220

mean cycles before failure

45

0 makes every machine identical

0.10

how differently each machine responds

0.08

measurement error on every reading

shape
the declaration
degradations:
  - table: readings
    units: 8
    life_mean: 220
    life_std: 45
    unit_variation: 0.10
    responses:
      - column: vibration_mm_s
        baseline: 0.8
        at_failure: 5.2
        shape: exponential
        noise: 0.08

That is the whole input. Paste it into a schema and misata generate produces the fleet above, with rul_cycles exact on every row.

Now generate it for real

calls misata.degradation.generate() on the server
units60

machines in the fleet

life_mean220

mean cycles before failure

maintenance history

Repairs damage part-way, logs an event, and shortens effective life a bit each imperfect repair.

Set the controls and generate. Free preview, up to 150 units, no signup.

What the existing datasets cannot give you

AI4I 2020C-MAPSSThis
A machine you can follow over time
A remaining-useful-life label
Wear that never goes backwards
Change the fleet size or failure mix
The latent damage state, for checking a model
Validated against real hardware

The last row is the honest one. C-MAPSS and AI4I describe real machinery; this describes a declared one. Use it where you need ground truth that real data cannot give you, and cite the real sets where you need real physics.

What holds, measured on the published files

  • RUL is exact on all 100 units. It decrements by exactly 1 each cycle and reaches 0 on the failure cycle. No smoothing, no clipping.
  • Tool wear never decreases, on 100% of steps. Declare a cumulative quantity monotonic and it stops going backwards, however much noise you add.
  • Wear correlates +0.849 with cycle. Something is genuinely progressing toward failure.
  • Failure mode is learnable, not decorative. Units failing by tool wear reach a mean 357 minutes against 245 to 261 for the other modes, and heat-dissipation units reach 325.6 K against about 316 K.
  • Sensors are correlated but not collinear: mean 0.62, max 0.83. Each unit draws its own susceptibility per sensor, so the fleet does not move as one body.

What it refuses to claim

A generator that claims everything is worth nothing, so these are stated here and on the dataset itself rather than buried.

  • The physics is not validated. The damage law is a simplified lumped model, unchecked against XJTU-SY, PRONOSTIA/FEMTO or IMS.
  • One damage process per unit. Real machines fail from several interacting mechanisms.
  • No per-machine attributes beyond a control type. No location, no maintenance history, no operator.
  • Not a drop-in replacement for C-MAPSS in published benchmarks.

Questions

What makes remaining useful life exact rather than estimated?
The failure time is drawn before any row exists. Each unit gets a life, damage accumulates toward exactly that moment, and the rows are solved so the countdown lands on zero on the failure cycle. Nothing is labelled after the fact, so rul_cycles decrements by exactly 1 each cycle on all 100 units in the published dataset.
How is this different from AI4I 2020?
AI4I has no unit identity and no time index. Each of its 10,000 rows is an independent snapshot of a different product, so there is no machine to follow, no trajectory, and no remaining-life label to predict. It is a good classification dataset, but nothing in it progresses toward failure.
How is this different from NASA C-MAPSS?
C-MAPSS has trajectories and RUL and remains the standard benchmark. It is also a fixed turbofan simulation from 2008: you cannot change the fleet size, the failure mix or the noise level. This is generated from a declaration, so you can change any of them and regenerate.
Is the physics validated against real bearings?
No, and that is stated on the dataset itself. The damage law is a simplified lumped model and has not been checked against XJTU-SY, PRONOSTIA/FEMTO or IMS run-to-failure data. The defensible claim is that the labels are exact and the trajectory is declared, not that the degradation is faithful to a specific machine.
Can I use it commercially?
Yes. The dataset is public domain (CC0) and Misata is MIT licensed. No real machine data was sampled and no model was fitted to real data, so there is no proprietary or personal information in it.
Can I generate a fleet of my own size and failure mix?
Yes. The schema.yaml that produced the published dataset ships with it and runs as-is. Change units, life_mean, the failure modes or the sensor responses and run misata generate. Remaining useful life stays exact because it is solved for rather than annotated.
Does this support motor current, acoustic emission, or a maintenance history?
As of misata 0.9.6.33, yes. Bearing fault frequencies (BPFO/BPFI/BSF/FTF) are wired into real per-unit columns from bearing geometry and shaft speed, checkable against the published formulas. Setting a line frequency adds motor current sidebands offset from that frequency by each defect frequency, and an acoustic emission burst rate that tracks BPFO directly, since a struck defect produces one burst per rolling-element pass. A maintenance_policy (scheduled or condition-based) adds a repair history: a companion event log, damage that resets at each intervention, and the documented finding that repeated imperfect repairs raise susceptibility to future deterioration. The published 100-machine dataset on this page predates these additions and was not regenerated with them; the engine capability and a fully worked, verified example are documented at github.com/rasinmuhammed/misata/blob/main/docs/domains/predictive-maintenance.md.

Generate your own fleet

pip install misata
misata generate --config schema.yaml --output-dir ./data

The schema.yaml that produced the published dataset ships inside it and runs unmodified. Change the fleet size, the mean life or the sensor response and regenerate. The countdown stays exact because it is solved, not labelled.

Read the docs Other free datasets