Remaining Useful Life Prediction: Weibull, LSTM and Particle Filters

Most condition monitoring programmes can tell you that a bearing is unhealthy today. Far fewer can tell you, with a defensible error bar, how many operating hours remain before it crosses the line you cannot afford to cross. That second question is remaining useful life prediction, and it is where predictive maintenance either pays for itself or quietly turns into an expensive alarm generator. A model that is right on average but late on the engines that matter is worse than a calendar schedule.

This matters now because three things changed together. Sensors and edge compute made dense run-to-failure style data cheaper to collect, deep sequence models made it easy to fit curves to that data, and maintenance planners started asking for probabilities rather than point estimates. The gap between a leaderboard score and a decision a planner can act on is wide, and most of it is statistical rather than architectural.

This article gives you a working map: the prognostics taxonomy, how health indicators are built, how Weibull and Cox survival models behave, how LSTM-style networks and particle filters track degradation, how to evaluate honestly, and how to deploy and monitor the result.

What this covers: the PHM taxonomy, health indicators, the NASA C-MAPSS benchmark, survival models, deep RUL models, particle-filter tracking, evaluation metrics, a deployment architecture, and the failure modes that break prognostics in production.

Context and Background

Prognostics and health management (PHM) is the discipline that turns condition data into a forecast of future health. Diagnostics answers “what is wrong now”; prognostics answers “when will it stop being acceptable”. The distinction sounds academic until you notice that the two need different data. Diagnosis needs labelled fault signatures. Prognosis needs the temporal evolution of degradation, ideally through to failure, and failures are the one thing a well-run plant tries hard not to produce.

The international vocabulary is anchored by ISO 13381-1, the general guidelines for prognostics in machine condition monitoring and diagnostics, which defines concepts such as failure threshold, remaining useful life and the prognostic horizon. The practical consequence is that RUL is always defined relative to a threshold. Change the threshold and you change the truth the model is graded against. That is a quiet source of disagreement between data scientists and reliability engineers, and we return to it in the failure-modes section.

Remaining useful life is the time between the present and the moment a health measure first crosses its failure threshold, conditional on future operating load. Notice the two hidden assumptions: a threshold and a future usage profile. A pump run at a duty cycle of 60 percent has a different RUL than the same pump at 95 percent, so any honest RUL estimate states the usage scenario it assumes.

Three families of methods dominate the literature. Physics-based models encode the damage mechanism, for example a Paris-law crack growth equation or a wear law, and fit its parameters to observations. Data-driven models learn the mapping from sensor history to RUL or to failure probability. Hybrid models run a physics or low-order degradation model inside a Bayesian filter and let data correct the parameters online. If you want the monitoring layer that feeds all three, start with our piece on condition monitoring and machinery health architecture, and for the vibration-specific features see the ISO 20816 FFT and ML pipeline.

The reference dataset for the field is the NASA turbofan degradation simulation produced with the C-MAPSS simulator, introduced by Saxena and colleagues in their 2008 paper on damage propagation modeling for aircraft engine run-to-failure simulation. Because it is public, simulated and run to failure, it became the default benchmark. It is also the reason this field has a habit of over-reporting how solved the problem is. We will be specific about what that dataset does and does not represent.

The Prognostics Reference Architecture

Remaining useful life prediction is best understood as a pipeline with one decision point in the middle: how to represent degradation. Everything upstream (cleaning, regime normalization, health indicator construction) is shared. Everything downstream (the RUL distribution and the maintenance decision) is shared. The branch in between is where you choose physics, data, or a hybrid.

Figure 1: A reference remaining useful life prediction pipeline. The shared front end builds a health indicator; the method branch produces a RUL distribution; the maintenance decision consumes the distribution, not a point estimate.

The diagram shows that all three method families converge on the same object, a distribution over remaining life. If a method hands your planner a single number with no spread, it has thrown away the information that makes the number usable.

Direct answer: what a good RUL estimate is

A good RUL estimate is a probability distribution over remaining operating time, conditional on a stated failure threshold and future load, with calibrated uncertainty and an evaluation that penalizes late predictions more than early ones. A single number is only a summary of that distribution, typically its median or a conservative lower quantile.

Taxonomy: physics-based, data-driven, hybrid

Physics-based prognostics start from a damage law. For a crack, the Paris relation says growth per cycle scales with a power of the stress intensity range. For bearing spalls, empirical growth models relate spall length to cycles. You fit the law’s constants to measured damage, then integrate forward to a critical size. The strength is extrapolation: a law that encodes mechanism keeps working outside the training range. The weakness is that real assets have competing mechanisms and unknown loads, so the law is only ever partly right.

Data-driven prognostics skip the mechanism. A regression, survival or neural model maps history to remaining life. Its strength is that it needs no mechanism knowledge and absorbs interactions you did not model. Its weakness is the dependence on failure examples. A fleet that rarely fails gives a data-driven model very little to learn from, which is the central economic paradox of the field.

Hybrid prognostics use a low-order degradation model as the state equation of a filter and let measurements update the state and parameters. They inherit some extrapolation ability from the model and some flexibility from the data. They are the natural fit for a digital twin, because the twin already maintains a state estimate; our comparison of Kalman, particle and ensemble Kalman filters for twin synchronization covers the estimator choices in depth.

Health indicators: the representation that decides everything

A health indicator (HI) is a scalar, or low-dimensional vector, that increases or decreases monotonically with damage. Good indicators have three properties often cited in the PHM literature: monotonicity, trendability across units, and prognosability, meaning that the value at failure is consistent across units even if the path differs. Prognosability is the subtle one. If every unit fails at an HI of 0.2, a threshold is meaningful. If failures land anywhere between 0.1 and 0.6, no threshold can separate them.

Indicators come in two flavours. Physical indicators come from engineering knowledge: RMS vibration in a defined band, a bearing fault frequency amplitude, an efficiency ratio, an oil particle count, a thermal resistance. Learned indicators come from compressing many sensors into one score, using principal component analysis, an autoencoder, or a regression onto a proxy such as normalized age. Physical indicators are easier to defend in a design review. Learned ones can capture combinations of sensors that no single channel shows, but they are harder to audit.

The C-MAPSS Dataset and What It Actually Teaches

C-MAPSS stands for Commercial Modular Aero-Propulsion System Simulation. The challenge data generated from it for the 2008 PHM conference competition simulates turbofan engines degrading until failure. In the damage propagation paper, degradation is injected into the high-pressure compressor through flow and efficiency modifiers, 21 of the simulator outputs are exposed as sensor channels, and the simulation stops when a health index computed from stall margins and exhaust-gas temperature margin reaches zero. The paper gives wear as an exponential-type growth in time, with the exponent and rate drawn from bounded ranges per unit, plus initial manufacturing variation and measurement noise.

The commonly used benchmark splits it into four subsets, FD001 to FD004. The table below is reproduced from a published summary of the dataset (Table 2 of arXiv 2202.10916).

Subset	Train engines	Test engines	Operating conditions	Fault modes
FD001	100	100	1	1
FD002	260	259	6	1
FD003	100	100	1	2
FD004	259	248	6	2

FD001 is the easy case: one operating condition, one fault mode. FD004 combines six operating conditions with two fault modes, and the regime mixing means raw sensor values mostly track the operating point rather than health. That is why per-regime normalization is a standard step in any serious pipeline, and why FD002 and FD004 errors are consistently larger than FD001 and FD003 in published tables.

What the benchmark teaches, and what it hides

C-MAPSS is good for comparing architectures under identical conditions. It is not representative of a real fleet in four ways. First, it has hundreds of run-to-failure trajectories, while a real fleet may have a handful of failures. Second, degradation is smooth and monotonic because it comes from a parametric simulation. Third, labels are exact: you know the cycle of failure in training. Fourth, test trajectories are truncated at a random point, which is a convenient proxy for “we observe the engine at some arbitrary moment” but hides the censoring and maintenance interventions that contaminate real data.

A practical consequence is that a leaderboard improvement of one RMSE point on FD001 tells you almost nothing about whether the method will work on your compressors. It tells you the architecture can fit smooth degradation curves. Treat C-MAPSS results as a unit test, not as a forecast of field performance.

The piecewise-linear target

Training a network to predict raw remaining cycles for a healthy engine is a poor idea, because early in life there is no observable signature separating 300 cycles remaining from 250. The widely used workaround is to clip the target at a maximum value, so early life has a constant RUL and the line only begins decaying later. A cap around 125 to 130 cycles is common in the literature; the exact value is a tuning convention rather than a physical constant, and it should be treated as a hyperparameter. Clipping encodes a sensible belief: before degradation becomes observable, the best prediction is a flat “healthy” value. It also quietly changes the problem, so always report which cap you used.

Deeper Analysis: From Weibull Survival to LSTM and Particle Filters

This section walks the method ladder from the simplest defensible model to the most flexible, with worked numbers at each rung. The ordering is deliberate. Start with survival statistics, because they force you to confront censoring. Move to deep sequence models when you have run-to-failure data. Move to filters when you have a degradation mechanism and want calibrated uncertainty.

Weibull survival analysis: the baseline you should always run

Weibull survival analysis models time-to-failure with a two-parameter distribution. The survival function is R(t) = exp(-(t/η)^β), where η is the characteristic life (the time by which 63.2 percent of units have failed) and β is the shape parameter. The hazard rate is h(t) = (β/η)(t/η)^(β-1). A β below 1 means failures concentrate early (infant mortality), β near 1 means a constant hazard (random failures), and β above 1 means wear-out, where the hazard rises with age. For rotating machinery with genuine wear-out, β commonly lands between 1.5 and 4, though your fleet’s fitted value is the only one that counts.

Here is a worked example with illustrative numbers, not taken from a real fleet. Suppose a fitted pump bearing population has β = 2.5 and η = 1,000 operating hours. A bearing that has survived to 600 hours has survival probability R(600) = exp(-(0.6)^2.5) = 0.757. The conditional distribution of residual life is R(600 + x) / R(600). Solving for the quantiles gives a residual life of about 82 hours at the 10th percentile, 389 hours at the median and 861 hours at the 90th percentile.

Two lessons follow. The spread is enormous: even with a well-fitted Weibull, population statistics alone give an 80-to-860-hour band. And the hazard at 600 hours is 0.00116 per hour, rising to 0.00213 per hour at 900 hours, so risk compounds with age. This is the baseline against which any sensor-driven model must prove its worth. If your LSTM does not beat “age plus Weibull” on a fair split, the sensors are not adding information.

The Weibull model uses age only. It ignores the condition of the specific unit, which is exactly what condition monitoring adds. Two bearings at 600 hours can have very different vibration trends, and the population model treats them identically.

Cox proportional hazards and covariates

The Cox proportional hazards model fixes that by letting covariates scale the hazard: h(t | x) = h0(t) exp(βᵀx), where h0 is an unspecified baseline hazard. The coefficient interpretation is clean. If a vibration feature has coefficient 0.8 and it rises by one standardized unit, the hazard is multiplied by exp(0.8) = 2.23. A rise of two units multiplies it by 4.95. Cox models are fit by partial likelihood, handle right-censored units naturally, and give hazard ratios that engineers can sanity-check.

The catch for prognostics is that sensor covariates change over time. A standard Cox model assumes fixed covariates, so you either use a time-dependent Cox model or the joint modelling approach that couples a longitudinal sub-model for the degradation signal with a survival sub-model. Joint models are the statistically principled route when you have repeated measurements, and they report a conditional survival curve updated at each new observation. They are underused in industry, largely because the tooling is less polished than deep learning frameworks.

Censoring deserves its own sentence because it is the most common error in homegrown RUL projects. A unit that was removed for preventive maintenance at 700 hours did not fail at 700 hours. It survived at least 700 hours. Treating it as a failure biases the failure-time distribution downward and teaches the model that the alarm threshold is reached earlier than reality. Survival models exist precisely to use that partial information correctly.

Deep sequence models for RUL estimation

When you have many run-to-failure trajectories, neural sequence models learn the mapping from a window of sensor history to RUL directly. The pipeline is standard: drop sensors with no variance, normalize per operating regime, build sliding windows (30 cycles is a common choice on C-MAPSS), encode each window, and regress a clipped RUL.

Figure 2: A typical RUL estimation pipeline on C-MAPSS. Normalization per operating regime and the clipped target are the two steps most often skipped by newcomers and most responsible for poor results.

LSTM networks are a natural fit because they carry a state across the window and can learn which past observations matter. One-dimensional convolutional networks learn local degradation motifs and train faster. Transformer encoders use attention to weight cycles across the window. Reported C-MAPSS results across these families are not directly comparable unless the preprocessing, window length, target cap and test protocol match, and they often do not.

For orientation, a recent paper on a temporal deep degradation network (arXiv 2202.10916, Table 4) tabulates published RMSE results. In that table an LSTM baseline reports RMSE of 16.14 on FD001 and 28.17 on FD004, a deep CNN reports 12.61 and 23.31, and the proposed network reports 9.47 and 11.16. Read these as the paper’s own reported comparison, not as a controlled benchmark: protocols differ across the cited works, and a paper’s proposed method is typically evaluated with more tuning effort than the baselines it is compared against. The useful signal is the pattern, namely that FD002 and FD004 are harder than FD001 and FD003 for nearly every method.

What the model is really learning

On C-MAPSS, a good deep model largely learns to read the degradation stage from a handful of sensors that drift monotonically (several temperature and pressure channels), after the regime effect has been normalized away. This is why simple models do respectably and why the leaderboard gap between architectures is smaller than the gap between careful and careless preprocessing. A cheap sanity check: fit a gradient-boosted regressor on the last-cycle features and compare. If a window-based network only matches it, the temporal modelling is not earning its complexity on your data.

Deep models also tend to give overconfident point predictions. Three practical ways to obtain uncertainty are Monte Carlo dropout, deep ensembles (train five to ten networks from different seeds and take the spread), and quantile regression heads that predict the 10th, 50th and 90th percentiles directly. Ensembles are the most reliable of the three in practice, at the price of training and serving several models. Whichever you choose, check calibration: of the units whose true RUL you later observe, roughly 80 percent should fall inside your 80 percent interval. If only 50 percent do, the interval is a decoration.

Particle filters for degradation tracking

A particle filter is the hybrid answer. You write a state-space model: the hidden state is the damage level and the growth parameters, the state equation propagates damage forward with process noise, and the measurement equation relates the observed health indicator to damage with measurement noise. A set of weighted samples (particles) approximates the posterior. Each new observation reweights the particles by how well they explain it.

Figure 3: The particle filter loop for RUL estimation. Every particle carries its own growth rate; extrapolating each to the failure threshold produces the RUL distribution directly.

The key trick for prognostics is that parameters are part of the state. Suppose degradation follows an exponential-type law, as in the C-MAPSS damage model, where health decays as a function of t raised to a power. Augment the state with the growth rate and let the filter learn it per unit. Particles with a growth rate that matches the observed trend gain weight; the others die out at resampling. To predict RUL, you freeze each surviving particle and simulate it forward until it crosses the threshold, recording the crossing time. The histogram of crossing times is the RUL distribution, and its quantiles come for free.

Particle filters beat the Kalman family when the model is nonlinear or the noise is non-Gaussian, as is common with exponential degradation and heavy-tailed sensor noise. The extended Kalman filter linearizes and can diverge on strongly nonlinear growth. The cost is compute and a known weakness called particle degeneracy: after several updates a few particles carry nearly all the weight. The standard remedy is to monitor the effective sample size and resample when it falls below roughly half the particle count, often adding small parameter jitter so that the cloud does not collapse. A frequently used sanity target is a few thousand particles for a low-dimensional state of two to four variables, though the right number depends on the problem and should be tested by repeating runs.

A subtle failure mode is that the filter confidently tracks the wrong model. If the true degradation switches from slow wear to rapid spalling, a filter built around a smooth exponential will interpret the acceleration as noise for too long. Using a model with regime switching, or inflating the process noise on the growth parameter, trades some precision for adaptability.

Choosing among the methods

Situation	Best first choice	Why
Fleet with few failures, known mechanism	Physics model plus particle filter	Mechanism supplies the extrapolation; data tunes parameters
Large run-to-failure archive, varied operating regimes	Deep ensemble on windows	Learns regime interactions; ensemble gives spread
Heavy censoring, age and a few covariates	Weibull or Cox survival model	Uses censored units correctly; interpretable
Need updating conditional survival from a degradation signal	Joint longitudinal-survival model	Coherent probabilistic update at each observation
Digital twin already maintains state	Hybrid filter in the twin	Reuses state estimate; produces RUL distribution

The table is a starting heuristic. Real programmes combine rungs: use Weibull for the fleet-level prior, a filter for unit-level tracking, and a deep model as a challenger that must beat the baseline on held-out units.

Evaluating RUL Models Honestly

Evaluation in prognostics is harder than in ordinary regression because the cost of error is asymmetric and time-dependent. Predicting 40 cycles when 20 remain is dangerous. Predicting 20 when 40 remain wastes some life. And an error at 150 cycles from failure matters far less than the same error at 15 cycles from failure.

RMSE, the NASA scoring function, and why both are needed

Root mean squared error treats early and late errors symmetrically, so it is a useful but incomplete summary. The scoring function associated with the PHM08 challenge is asymmetric. With d defined as predicted RUL minus true RUL, the score for each unit is exp(-d/13) – 1 when d is negative (early prediction) and exp(d/10) – 1 when d is zero or positive (late prediction); the total score sums over units and lower is better. The constants 13 and 10 are given in the damage propagation paper, and the branch assignment is shown explicitly in the formula as reproduced in arXiv 2202.10916 (Eq. 10).

Evaluate the function at a few errors to get a feel for the penalty. An early error of 10 cycles scores 1.16. A late error of 10 cycles scores 1.72. At 30 cycles the gap widens sharply: an early miss scores 9.05 while a late miss scores 19.09. Because the penalty is exponential, a handful of large late predictions can dominate the summed score even when most units are predicted well. This is also why the score is noisy: on a small test set one outlier moves it by tens of percent. Always report the score alongside RMSE, with a bootstrap confidence interval.

Prognostic horizon and alpha-lambda style metrics

Point-error metrics ignore when in the life the error occurs. The PHM literature, including the metrics discussion in the Saxena paper, proposes time-aware measures. The prognostic horizon asks how early before failure the prediction first enters and stays within an acceptable error band around the true RUL. A longer horizon is better: it means the system gives usable warning. Related measures such as alpha-lambda accuracy check whether predictions fall within a cone of allowable error that narrows as failure approaches. These metrics are closer to what a planner needs, because a model that is accurate only in the last ten cycles is not actionable.

Evaluate on units, not rows

A frequent leak: random-splitting windows across all engines puts adjacent, nearly identical windows in both train and test, producing optimistic scores. The unit of independence is the engine (or machine), so split by unit. For fleets, split by asset and, if possible, by time, so that the test period lies after the training period. Cross-validation should be grouped by unit. If you report C-MAPSS numbers, use the official train and test split with the official true RUL file for the test engines, and state your window length, cap and normalization.

Calibration and decision-focused evaluation

If the output is a distribution, evaluate it as one. Check interval coverage, compute the pinball loss for quantiles, and examine the reliability diagram. Then go one step further and evaluate the decision. Suppose a planner schedules maintenance when the 10th-percentile RUL falls below the maintenance lead time of, say, 30 cycles. Simulate that policy on held-out units and count missed failures, premature removals and the average life wasted. Decision cost, not RMSE, is what the business pays for.

Deployment Architecture: From Model to Maintenance Decision

A RUL model in a notebook is a research result. In production it is a service with data contracts, latency budgets, a feedback loop and an owner. The architecture below separates the concerns that usually get tangled.

Figure 4: A deployment sequence for remaining useful life prediction. The last two messages, the work order outcome and the logged label, are what make retraining possible and are the most commonly omitted.

The edge gateway batches sensor readings per operating cycle or per fixed time window and ships them to a stream layer. Windowed features land in a feature store that keeps the training and serving definitions identical, which avoids the classic skew where features are computed one way offline and another way online. The RUL service reads the latest window, returns a median and an interval, and raises an alert when a conservative lower bound drops below the maintenance lead time. The computerized maintenance management system (CMMS) records what was actually done.

Where each piece should run

Prognostics rarely need millisecond latency. Degradation unfolds over hours to months, so a prediction refreshed every cycle or every few minutes is plenty. That relaxes the architecture: feature extraction that reduces raw vibration or current waveforms belongs on the edge, because shipping raw high-frequency data is expensive, while the RUL model itself can run on a central service that sees the whole fleet. Fleet-level learning, such as the Weibull prior and population drift monitoring, only works centrally.

For filters, the per-unit state (particles or covariance) is the thing you persist. Store it keyed by asset, version it alongside the model parameters, and make updates idempotent so a replayed message cannot double-count an observation. For deep models, store the model version with every prediction so that you can attribute a bad alert to a specific release.

The label feedback loop

The hardest part of deploying prognostics is not predicting. It is learning from outcomes. When the system alerts and the planner replaces the part, you never observe the failure you prevented, which censors the label. That is a good outcome for the plant and a problem for the training set. Record at least three things for every intervention: the time, the as-found condition (a teardown inspection grade is gold), and whether the intervention was triggered by the model or by something else. The inspection grade lets you treat the replacement as a partially observed degradation state instead of a missing label, and it supports survival methods that handle censoring correctly.

Capacity and cost, with an illustrative calculation

The following numbers are illustrative assumptions, not measurements. Suppose a fleet of 2,000 assets each emits one feature window every 5 minutes, which is 288 windows per asset per day and about 576,000 windows per day in total. If the RUL service scores each window with an ensemble of five small networks, that is under 3 million small inferences per day, roughly 33 per second on average. This is trivial for a single modest CPU instance. The expensive part is almost never inference; it is the engineering of data quality, labelling and monitoring. If a particle filter with 2,000 particles runs per asset every 5 minutes, that is 4 million particle updates per cycle across the fleet, still small for vectorized code, though it argues for batching rather than per-asset processes.

Trade-offs, Gotchas, and What Goes Wrong

This is the section most prognostics write-ups skip, and the one that matters most in practice.

Few failures, many survivors

The central problem is data scarcity. A well-maintained fleet produces very few failures, so run-to-failure data is rare and biased toward whatever mechanism failed first. Deep models trained on a handful of failures memorize them. Mitigations include pooling similar asset types, using physics-based simulation to generate synthetic degradation (as C-MAPSS itself does), transfer learning from a related fleet, and falling back to survival models that use censored units. None of these removes the problem, and you should tell stakeholders honestly that the first year of a prognostics programme is spent collecting labels.

Censoring and maintenance contamination

Data from machines under active maintenance is not natural degradation. Lubrication, adjustments and part swaps reset the health trajectory. If you do not mark these events, the model sees health jump upward for no reason and learns noise. Always join maintenance records to the sensor series and either split trajectories at resets or model the reset explicitly.

Drift and the changing operating envelope

Sensors drift, firmware changes scaling, and a plant starts running a new product at a different load. Each shifts the input distribution without any change in health. Regime normalization helps, but you should also monitor input drift (population stability index or a two-sample test per feature) and the residual between predicted and realized health. A rising residual is an early sign that the model has become stale.

Threshold ambiguity

Because RUL is defined against a failure threshold, an argument about the threshold masquerades as an argument about model accuracy. A functional failure (the pump cannot meet flow) differs from a reliability alarm (vibration exceeds a limit) and from a conservative engineering limit (replace at 80 percent of the failure value). Write the threshold into the model card. Changing it should create a new model version.

Overconfident extrapolation

Deep networks extrapolate poorly, and a window that looks unlike anything in the training set can produce a confident, wrong number. Out-of-distribution detection, for example a distance measure in the learned embedding space, should gate the output: if the window is unfamiliar, return “unknown” and escalate to a human, rather than a number.

Alert fatigue and the cost of false positives

A model that cries wolf is switched off. Tune thresholds on decision cost, include a hysteresis band so alerts do not flap near the boundary, and require persistence across several consecutive predictions before raising an alert. A stable but slightly conservative alert beats a jumpy accurate one.

Benchmark overfitting

Because C-MAPSS is small and public, hyperparameters and architectures get tuned against the test set across the literature, whether deliberately or through iterative publishing. Treat headline RMSE improvements on it with caution, prefer papers that report variance across seeds, and validate on your own held-out units before trusting any ranking.

Practical Recommendations

Start with the simplest model that handles your data honestly, and make it earn its way up. A Weibull or Cox baseline using age and a few condition covariates should come first, because it forces you to deal with censoring and gives you a number to beat. Add a data-driven model only after you have established that sensors carry information beyond age. Add a filter when you have a plausible degradation law and want calibrated uncertainty for individual assets.

Spend your effort on health indicators and labels rather than architecture. A monotonic, trendable, prognosable indicator makes a modest model work; a poor indicator defeats any architecture. Invest in capturing as-found inspection grades at every teardown, because they are the cheapest source of ground truth you will ever get.

Report distributions, not points, and evaluate the decision. Use RMSE for continuity with the literature, the asymmetric score to expose late predictions, the prognostic horizon to show usable warning, and a policy simulation to show money. Run the model in shadow mode for one or two failure cycles before it triggers work orders.

A short checklist before go-live:

Failure threshold and usage scenario are written down and versioned with the model.
Splits are grouped by asset and ordered in time; censored units are handled, not dropped.
Uncertainty is calibrated on held-out assets, with coverage reported.
A Weibull or age-only baseline is beaten on the same split.
Input drift and prediction residual monitors exist, with a retraining trigger.
Every intervention logs time, trigger source and as-found condition.
Alerts use a lower quantile, persistence and hysteresis.

Frequently Asked Questions

What is remaining useful life prediction?

Remaining useful life prediction estimates how much operating time or how many cycles an asset has left before its health crosses a defined failure threshold. It is the core output of prognostics and health management. A good estimate is a probability distribution, not one number, and it depends on both the chosen threshold and the assumed future load on the machine.

How is RUL estimation different from anomaly detection?

Anomaly detection flags that current behaviour departs from normal and says nothing about time. RUL estimation forecasts when degradation will reach an unacceptable level, so it needs a degradation trend and a threshold. In practice anomaly detection often triggers prognostics: detect the onset of a fault first, then start tracking the health indicator toward failure.

What is the C-MAPSS dataset and is it enough to validate a model?

C-MAPSS is a NASA simulation-based turbofan degradation dataset with four subsets, FD001 to FD004, which differ in operating conditions and fault modes. It is a good unit test for sequence architectures. It is not enough to validate a production model, because it is simulated, smooth, fully labelled and has many failures, unlike a real fleet.

Do I need run-to-failure data to predict RUL?

For supervised deep models, yes, or at least many trajectories with degradation. Without it, use survival analysis that exploits censored units, a physics-based degradation law tracked with a filter, or transfer from a similar fleet or simulation. Many real programmes combine them: a population Weibull prior, then unit-level updating from condition data as evidence accumulates.

Should I use LSTM, a transformer or a survival model?

Choose by data and need, not fashion. With large run-to-failure archives and varied regimes, sequence models such as LSTMs, CNNs or transformers are reasonable, and an ensemble gives uncertainty. With heavy censoring and few failures, survival models are safer and more interpretable. Always benchmark against an age-only Weibull baseline on the same grouped split.

How do I measure whether an RUL model is good?

Use several measures. RMSE summarizes average error, the asymmetric PHM08 score penalizes late predictions more than early ones, and the prognostic horizon shows how early the model gives usable warning. Check interval calibration and, above all, simulate the maintenance policy to count missed failures and wasted life on held-out assets.