Remaining Useful Life Without Run-to-Failure Data

On the wall of a waste-to-energy control room sits a screen with a number on it: remaining useful life, 47 days, next to the tag for a boiler feed pump. The box updates every few minutes and is styled like a fuel gauge. A planner reads it in passing. Next outage is eight weeks out. Do they pull the pump early, or run it and trust the box?

That box is the output of a prognostics model, and the promise behind it is a good one: take the vibration, temperature and load data a plant already trends, and turn a degradation curve into a maintenance decision. Estimate how much working life a machine has left, and you can book the repair into a planned window instead of meeting it at 3 a.m. on a Sunday. Worth having. The trouble is that most of what gets sold around remaining useful life, from the integrator's pitch deck to the styling of that number, rests on a handful of claims that don't survive contact with a real plant. Five of them cost you money. Here they are, and here's what to do instead.

"You can't do prognostics without run-to-failure data"

Ask an integrator how to build a remaining-useful-life model and you'll often hear the same precondition: first, collect histories of the asset run all the way to failure, enough of them to train on. No graveyard of dead bearings, no model. It sounds rigorous. But it's backwards.

Think about what a run-to-failure dataset actually is. It's a record of the times your maintenance let a machine die. On a site that does its job, those are rare and slightly embarrassing (the pump nobody was watching, the fan that let go between inspections). Every asset you caught in time, pulled, and rebuilt on a planned outage produced no failure at all. Do good condition-based maintenance and you systematically destroy the very data this precondition demands. You'd have to run machines to destruction on purpose to collect it, which is precisely the outcome the whole exercise exists to prevent.

So where does the signal come from, if not from failures? From the physics of how things wear, and from data you already hold. A rolling-element bearing doesn't fail at random; it climbs a fairly well-understood ladder, from sub-surface fatigue to a surface spall to spreading damage to the load path breaking down. A heat exchanger fouls along a curve. A slurry pump loses head as the impeller and wear ring erode and the running clearance opens up. These are degradation paths with mechanisms behind them, and you can model the path from a handful of observed points plus what's known about the mechanism, long before any unit in your fleet has died.

The second source is the one teams overlook: censored data. Reliability engineering has a name for a unit you inspected, found healthy, and put back, or pulled and rebuilt before it let go. It's a right-censored observation, and survival models, from a plain Weibull fit to proportional-hazards approaches, are built to use exactly that partial information. You don't need the machine to reach the end. You need to know how long it ran and the state it was in when you looked. Your inspection records, your oil analysis, your vibration route history: that's censored survival data, and most plants sit on years of it without calling it that.

Where you run a fleet of near-identical assets, a third route opens up: similarity. A row of identical CIP supply pumps across a dairy won't fail on a schedule, but the ones drifting toward the limit trace a recognizable shape, and a unit further along its own curve is a preview of where its siblings are heading. Blend that with the mechanism prior and the first real transitions you do observe, and you've bootstrapped a working estimate without waiting on a single catastrophic failure. The model sharpens each time an asset crosses a stage and you confirm what it was.

Reframe it, and the data problem loosens. A useful model doesn't learn what failure looks like from a pile of failures. It tracks a degradation state, then estimates when that state will cross a limit you set from engineering, not from a training set. The limit is a vibration-severity boundary from ISO 10816, a bearing temperature your OEM won't warrant past, a clearance where efficiency starts to bleed off. Remaining useful life becomes time-to-limit, and the limit is a decision you own. The potential-failure-to-functional-failure window, the P-F interval, is old ground here; reliability-centered maintenance formalized it back in the 1970s. What changed is trending the approach to the limit continuously, at the machine, instead of on a clipboard route once a month.

There's a cost argument buried in all this, and it's the part management should hear. "Collect run-to-failure data first" is a plan to spend the next two years letting expensive machines break so a model can watch. You pay for the unplanned downtime, the secondary damage when a seized bearing takes the shaft and the coupling with it, and the safety exposure, all to manufacture training examples you could have approximated from mechanism and censored history on day one. The graveyard approach has the economics exactly inverted. Start from what the machine is doing now and what you already know about how it wears.

"The model gives you a number: so many days to failure"

Back to the box on the wall. Remaining useful life, 47 days, in a font that reads as certainty. Taken as a countdown, that number is close to dangerous, because a point estimate with no spread around it invites you to trust it exactly as far as you shouldn't.

A prognosis isn't a scalar. It's a probability distribution over time, and any honest implementation carries its uncertainty with it, usually from a state tracker like a Kalman or particle filter that widens the spread as it extrapolates. Picture a cone that starts wide and narrows as the machine approaches the limit. Far from the limit, the model is guessing politely; the spread is enormous, and "47 days" might as well read "sometime this quarter." Close in, near the knee of the degradation curve, the spread tightens and the estimate earns its keep. Still, a dashboard that shows the same crisp single number at both distances is hiding the only part that matters.

You don't schedule against the mean. You schedule against the moment the odds of crossing the limit outgrow the next planned window you can get the machine into.

That's how a distribution becomes an action. You pick a risk threshold tied to consequence. A CIP supply pump with an installed spare beside it can run closer to the edge; you'll swap it on a coffee break if it goes. A single-train induced-draft fan on a waste line, the one whose failure drops the whole boiler, gets a wide margin and an early booking. Same model, same math, different tolerance, because the cost of being wrong isn't the same. So the useful question a planner puts to the model isn't "when will it fail." It's "what's the chance it can't make the March outage," and that's a question a distribution can answer and a single number can't.

None of this is abstract if you've watched a bearing go. It advances in stages you can see in the data, each with its own signature and its own rough warning, and the warning shrinks as you climb.

Read that table as a countdown and you'll mistime the job. Read it as a state estimate feeding a schedule and it works. The point of trending the earliest stage isn't to announce a death date months out; it's to know the machine is on the ladder, so you can watch the rungs and pick your window as the picture sharpens.

"More sensors mean a better prediction"

Sell hardware and this one sells itself: more channels, more data, more accuracy. Bolt an accelerometer on every bearing, wire in extra thermocouples, stream it all to the historian, and the model gets smarter. But it doesn't. Prediction quality is set by whether your measurement actually captures the failure mode, and a pile of channels that don't is just a bigger pile.

Take vibration, where most rotating-equipment prognostics lives. One accelerometer, stud-mounted on the loaded zone of the bearing housing, reading the right axis with enough bandwidth to see the defect harmonics, will out-predict a dozen sensors stuck on with magnets. The reason is physical. A magnet mount rolls off the high-frequency response exactly where early bearing defects announce themselves, so the sensor that looked convenient is deaf to the first stage of failure. Mount it on painted sheet metal instead of the housing and you've added a resonance that has nothing to do with the bearing. Read it once a month on a handheld route and you'll miss the week the trend turns.

Then there's what you do with the samples. Raw RMS velocity trended over time is a blunt instrument: it rises late and says little about what's actually wrong. Envelope analysis, demodulating the high-frequency band where the bearing rings, pulls the defect frequencies out of the noise weeks earlier. On a variable-speed drive you need order tracking, or the spectrum smears every time the line changes rate and your "trend" is really a speed change in disguise. Sample too slowly and real energy aliases down into bands where it never lived, and now you're trending an artefact. None of that is a sensor count. It's knowing the failure mode well enough to measure the one thing that moves first.

Vibration isn't the only channel worth its wiring, either. Bearing and winding temperature, motor current signature analysis, oil debris on a gearbox: each reads a different failure mode, and the trick is matching the modality to the mechanism rather than blanketing the machine in sensors. A stator fault shows up in the current spectrum long before it reaches vibration. Wear metals in the oil flag a gearbox tooth problem an accelerometer on the casing may never cleanly resolve. Pick the channel that sees the fault first, then trend it hard.

So the money in a prognostics program doesn't go where the brochure points. It goes into the right measurement, and into the analytics that turn a raw trend into a degradation state you can schedule against, which is the harder and less photogenic half of the work. Instrument the failure mode, not the asset. That's the logic we build around: a few well-placed, well-mounted channels feeding an edge platform that tracks the degradation state at the machine, rather than a wall of gauges nobody trends.

"It scored well on the benchmark, so it'll work on our line"

A vendor demo usually arrives with an accuracy chart. The model nailed remaining life on some dataset to within a tight band, and the implication is that it'll do the same on your equipment. Ask what it was trained and tested on. The honest answer is often a set of clean, monotone run-to-failure curves that look nothing like the mess coming off your plant.

Part of this traces back to where the field cut its teeth. Many public prognostics benchmarks are aerospace and lab-rig data, the best known being NASA's turbofan degradation simulations and accelerated bearing tests in its public prognostics data repository. They're valuable for putting algorithms on an equal footing. But a turbofan flown to failure in a simulator degrades along a smooth, well-behaved trajectory, and your induced-draft fan on variable waste feed does not.

What wrecks a benchmark-tuned model on a real site is everything the benchmark left out. Speed swings as the drive follows demand. A re-lube resets the vibration signature overnight, and a naive model reads the sudden drop as the bearing healing itself. Feedstock varies, badly on a waste line, so load and temperature wander for reasons that have nothing to do with the bearing. A CIP cycle in a dairy changes the duty on a pump twice a shift. The model has to separate degradation from operating point, and one trained on tidy curves simply can't; it cries wolf on every process change and gets muted within a week.

Which is why the only validation that counts is the one you run forward, on your own machines. Backtest the approach against your history, then let it predict and check the calls against what the next teardown actually shows. Where this breaks down deserves naming: an asset with no usable baseline, a failure mode with almost no runway, a machine so lightly instrumented that its state is a guess. A model that looks brilliant on a slide and has never seen your duty cycle has told you nothing yet.

"Prognostics replaces condition monitoring"

The last claim is the most seductive, because it sells a leap. Skip the old vibration-analysis grind, the argument runs, and let the model predict remaining life directly. It gets the order exactly wrong. Prognosis isn't a replacement for condition monitoring; it's the top floor of a building that needs the lower ones to stand.

Condition monitoring runs in stages, and the field names them for a reason. Detection asks whether anything has changed. Diagnosis asks what is changing and how (which bearing, which mode: imbalance, misalignment, a lubrication fault). Only then does prognosis ask how long until it matters. ISO 13381 sits on top of the detection and diagnosis work in ISO 13374 and ISO 17359, and that order is physical, not bureaucratic. A remaining-life number for a fault you haven't identified is theatre: a curve extrapolated with no idea which curve it's on.

Diagnosis drives the model choice, which is the step that gets skipped. An outer-race spall grows one way; lubrication starvation cooks a bearing on a completely different clock; product build-up unbalancing a fan rotor is a third path with a third rate. Each wants its own degradation model and its own limit. Pick the wrong mechanism and your time-to-limit estimate comes out confident and wrong. You can't shortcut to the answer without knowing which question the machine is asking.

And the model doesn't hold still once it's running. Re-lube the bearing, rebuild the pump, change the feedstock or the product recipe, and the baseline shifts under you; a prognosis trained on the old normal quietly goes stale. A model calibrated against last winter's feedstock will misjudge a grate-drive bearing running on this summer's, and nobody gets an alert that says so. So this is a loop with an engineer in it, not a number you install and forget. The OPC-UA or Modbus feed into the historian is the easy part. Keeping the model honest as the plant changes is the standing job, and it's the one nobody puts on the quote.

Which brings it back to the box on the wall. The number was never the deliverable. The schedule is. Do this well and the pump comes out on a planned Tuesday, the spall caught while it's still a line in the envelope spectrum and not yet a groove in the race, the spare fitted, the line barely blinking. The box might read 47 days or 12; the machine can't see it and doesn't care. What it responds to is the work order you cut because the trend, not the countdown, told you it was time.

Notes

This applies to rotating and process equipment with a diagnosable degradation path: bearings, pumps, fans, gearboxes, heat exchangers, the machines that trend before they fail. Not every failure mode gives you that runway; electrical faults and some brittle mechanical failures arrive with almost no warning, and prognostics has little to offer there. Where you genuinely do hold run-to-failure records, use them, they're just neither necessary nor sufficient to begin. Treat any remaining-life figure as a distribution with a limit behind it, and check its calls against what your next teardown shows. The benchmark aside points to NASA's public prognostics data repository, linked above, useful for algorithm work and no stand-in for your own duty cycle.