Most maintenance metrics look backward โ MTBF, MTTF, failure counts, downtime hours. Remaining useful life (RUL) is the one that looks forward. It answers the question every planner asks every morning: how much longer can I run this asset before I have to stop and fix it?
Get it right and you run an asset to the last safe hour without an unplanned stop. Get it wrong โ or just guess โ and you either spend a shutdown replacing a perfectly healthy component, or you run a bearing until it seizes and takes the line down with it.
RUL Is Measured From Today, Not From Installation
This is the first thing that trips people up. An asset installed two years ago against a ten-year design life does not have eight years of RUL. If it has been running hot, overloaded, or in dirty service, the real RUL may be a fraction of that. RUL is measured forward from the asset's current condition, not subtracted from a nameplate number.
That gap โ between the life the designer promised and the life the asset is actually delivering โ is the entire reason condition-based RUL exists. Nameplate life assumes the asset degrades the way its catalogue said it would. Real assets degrade according to how you actually operate them.
The Simplest Formula (And Where It Breaks)
For components with a clean, well-defined design life โ timing belts, filter cartridges, calendar-limited seals โ the life-fraction method is enough:
RUL = Total Useful Life โ Current Age
Worked example. A pump bearing rated for an L10 life of 25,000 hours has run 18,400. RUL = 6,600 hours. At 6,000 running hours a year, that is roughly 13 months โ you schedule the change inside the next planned outage.
The method is cheap and needs no sensors. Its flaw is just as obvious: it assumes the bearing is degrading at the rate the catalogue promised. If the pump is over-speeding to push past a throttled valve, the real fatigue life is shorter, and 6,600 hours becomes a wish, not a number.
Three Ways to Estimate RUL
When nameplate subtraction is not good enough, reliability engineers reach for one of three families.
1. Life-fraction (age-based). What we just did. Rated life minus operating age. Right for consumables with predictable failure patterns โ belts, filters, seal kits, time-limited aircraft parts. No condition data needed. Completely blind to actual health.
2. Physics-of-failure (degradation models). Model the degradation mechanism directly โ crack growth, bearing spall progression, insulation breakdown. Define a failure threshold, measure where the asset sits today with sensors, and project the curve forward to the threshold. The inputs are the indicators you already collect: vibration amplitude, temperature rise above baseline, oil particle count, motor-current signature distortion. The output is a RUL range with a confidence bound, not a single number.
3. Data-driven (machine learning). Train on historical run-to-failure sensor data; the model learns the signature of approaching failure without you specifying the physics. LSTMs for time-series, gradient-boosted trees, Gaussian-process regression (which hands you a probability distribution for free). Powerful for complex assets โ gearboxes, multi-stage compressors โ where a physics model would be unbuildable. The catch: it needs enough historical failures to learn from, which is exactly what critical, rarely-failing assets refuse to give you.
Mature programs use more than one. Physics-of-failure for the critical few where you understand the mechanism; life-fraction for the consumable many; data-driven where you have the failure history and the asset is complex enough to justify it.
RUL Is Not a Number โ It Is a Range
A RUL estimate of "3,800 ยฑ 800 hours" is useful. A RUL estimate of "somewhere between 3,000 and 8,000 hours" is barely better than a coin flip. The confidence interval widens as you look further into the future, which means short-horizon RUL โ driven by degradation you can already see in the sensors โ carries almost all of the decision-making value. Long-horizon RUL is for planning budgets, not for scheduling work orders. (For the statistical machinery behind turning failure history into these confidence bounds, see our Weibull analysis for maintenance piece.)
How RUL Fits the Predictive Maintenance Loop
RUL is the output of a pipeline, not a standalone calculation. The loop has four stages:
- Acquire. Sensors on the asset โ vibration, temperature, current, oil โ sampled fast enough to catch the failure mode you care about. Bearing faults want kHz-rate vibration; oil health is fine at 1 Hz.
- Extract. Turn raw signals into health indicators: overall RMS velocity, bearing fault frequencies (BPFI, BPFO, BSF), kurtosis, crest factor, particle counts. This compresses a flood of raw data into the handful of numbers that actually predict failure.
- Model. Feed those indicators to whichever of the three methods fits the asset. Project forward to the failure threshold.
- Trigger. When RUL drops below an intervention threshold โ set with real lead time for parts and labour โ a work order opens automatically.
Here is the part most teams miss: the value is not in step 3. The value is in step 4 happening without a human remembering to check a dashboard. A RUL number that nobody acts on is decoration.
RUL vs MTBF vs MTTF
These get conflated constantly. They answer different questions.
- RUL โ forward-looking, individual asset, real-time. When does THIS machine need work?
- MTBF โ backward-looking, fleet average, historical. How often does this asset CLASS fail? Drives preventive schedules.
- MTTF โ backward-looking, non-repairable components. How long do consumables last before replacement?
A bearing class can have an MTBF of 8,000 hours fleet-wide while one specific bearing running in high vibration has a RUL of 400 hours. Both numbers are correct. They are not interchangeable.
When Not to Trust a RUL Estimate
- Operating conditions shift. A model trained on normal load goes wrong the day the load profile, ambient temperature, or lubricant quality changes materially. Recalibrate after major process changes.
- Rare failure modes. Data-driven models need run-to-failure examples. Catastrophic cracking and contamination events do not happen often enough to train on โ use physics-of-failure there instead.
- Bad data. Sensor dropout, calibration drift, and poor placement all widen the confidence band until the estimate is meaningless.
- Threshold set wrong. Too conservative and you replace healthy parts โ quietly destroying the economic case for predictive maintenance. Too aggressive and the asset fails before the work order lands.
How OpexMX Handles RUL
OpexMX estimates RUL per asset, per failure mode, from the condition data your sensors already produce โ and ties each estimate to the operational trigger that actually opens a work order. For assets with enough failure history, the estimate learns from that history; for the rest, degradation models carry the load. Either way, "remaining useful life" is a range with a confidence bound and a deadline attached โ not a number on a dashboard.
See how OpexMX turns condition data into RUL-driven work orders โ