Predictive Maintenance: From Sensors to Decisions

Predictive maintenance is often presented as a machine-learning problem:

1. collect sensor data;
2. train a failure model;
3. predict the next breakdown.

That description is incomplete. A useful predictive-maintenance system has at least four layers:

The final step matters because a prediction has value only if it changes a decision at the right time.

Condition-based maintenance and predictive maintenance

Condition-based maintenance uses information about the current state of an asset to decide when maintenance should be performed. Predictive maintenance adds a forward-looking component. It may estimate:

• failure probability over a future horizon;
• time to a specific fault;
• remaining useful life;
• probability of crossing a degradation threshold;
• or the future distribution of a health indicator.

These are different statistical targets. They should not be collapsed into one generic “failure prediction” label.

Diagnostics and prognostics are different tasks

Diagnostics asks:

What is wrong now?

A diagnostic system may classify a bearing fault, detect misalignment, or identify an abnormal operating state. Prognostics asks:

What is likely to happen next, and when?

A prognostic model may estimate remaining useful life

conditional on the information available at time $t$. A good diagnostic classifier does not automatically produce a good RUL model. The targets, losses, labels, and evaluation schemes are different.

The data-generating process begins with the machine

Sensor data are not abstract features. They arise from physical processes. Vibration, temperature, pressure, acoustic emissions, current, lubricant chemistry, and operational loads each respond to different failure mechanisms. The observed signal can be written schematically as

where:

• $H_t$ is latent health state;
• $L_t$ is operating load;
• $E_t$ is environment;
• $S_t$ is sensor or acquisition state;
• $\varepsilon_t$ is measurement noise.

A temperature rise caused by higher workload is not the same event as a temperature rise caused by degradation. This is why operating context belongs in the model.

Health indicators

Raw waveforms are often converted into health indicators. For a vibration signal $x_1,\ldots,x_n$, simple examples include root-mean-square amplitude

kurtosis, spectral-band energy, crest factor, or features extracted from time-frequency representations. A useful health indicator should ideally vary with degradation rather than with irrelevant operating conditions. That is a stronger requirement than being predictive in one historical dataset.

Failure labels are usually difficult

Supervised predictive-maintenance models often assume clean labels. Real maintenance data rarely provide them. Common problems include:

• failures are rare;
• preventive maintenance removes components before failure;
• root cause may be uncertain;
• maintenance logs use inconsistent terminology;
• a component can be replaced for administrative reasons rather than degradation;
• several failure modes can compete.

This produces censoring and selection. A unit removed before failure does not have an observed failure time. Treating it as a healthy negative indefinitely is wrong.

Censoring belongs in RUL analysis

Suppose an asset is observed until time $C$ without failing. We know only

That is right censoring. Survival-analysis and reliability methods are designed for this information structure. Discarding censored units wastes information. Assigning an arbitrary failure time invents data. For time-to-event targets, the censoring process should be part of the model and validation design.

Maintenance changes the data you later learn from

This is one of the most important problems in predictive maintenance. Suppose the system detects degradation and replaces a component. The failure that would have occurred is never observed. Successful maintenance therefore removes exactly the future failures the model would otherwise learn from. The historical data satisfy a feedback loop:

This means maintenance policy is part of the data-generating process. Ignoring it can create biased estimates of failure risk.

Anomaly detection is not failure prediction

Anomaly detection estimates whether current behavior is unusual relative to a reference distribution. A score might be

where $\mathcal R$ represents normal operating data. A high anomaly score does not imply imminent failure. An anomaly can arise from:

• a new operating regime;
• sensor drift;
• environmental change;
• maintenance activity;
• a genuine fault;
• or a harmless rare state.

Anomaly detection is useful when labels are scarce. It should not be marketed as a failure-probability model unless that relationship has been validated.

Clustering has a narrower role than many articles imply

Clustering can reveal operating regimes or groups of similar assets. That can be useful when a single model would otherwise mix incompatible behaviors. But cluster membership does not automatically correspond to fault modes. K-means optimizes within-cluster squared Euclidean distance. DBSCAN identifies density-connected regions under its scale and neighborhood parameters.

Neither algorithm knows what “healthy” or “failing” means. Those meanings require external validation.

Remaining useful life is a distribution, not just a number

A point prediction

looks actionable. But maintenance decisions also need uncertainty. A probabilistic model aims at

where $\mathcal F_t$ contains the information observed up to time $t$. Two assets can have the same expected RUL and very different risk profiles. For one asset,

while another may have a broad or skewed distribution. The maintenance decision should not treat those forecasts as equivalent.

Lead time matters

A correct failure prediction can still be operationally useless if it arrives too late. Suppose maintenance requires 12 hours of planning and parts procurement. An alarm 30 minutes before failure has excellent event classification but almost no scheduling value. Evaluation therefore needs a prediction horizon. Useful questions include:

• How early is the first reliable warning?
• How often does the system oscillate between alarm and normal?
• What fraction of failures are detected with sufficient lead time?
• How many false alarms are generated per asset-month?

These are more operationally meaningful than global accuracy alone.

Random train-test splits create leakage

Sensor data from the same machine are strongly correlated over time. If observations from one asset appear in both training and test sets, a model can partially memorize machine-specific behavior. The same problem occurs when windows from the same degradation trajectory are split randomly. A better validation design holds out:

• entire assets;
• future time periods;
• sites;
• operating regimes;
• or combinations of these.

The split should mimic deployment.

Feature leakage can be subtle

Maintenance databases often contain variables recorded after the decision that the model is supposed to predict. Examples include:

• work-order status;
• technician diagnosis;
• replacement codes;
• post-inspection measurements;
• timestamps generated by maintenance workflows.

Such fields can make a model look spectacular offline. They are unavailable at prediction time. A strict feature timestamp is therefore essential:

Accuracy is not the operational objective

Suppose failures occur in 0.1% of observation windows. A model that always predicts “no failure” has 99.9% accuracy. That metric is useless. Precision and recall are better but still incomplete. A false alarm may cause:

• an unnecessary inspection;
• production stoppage;
• spare-parts use;
• or technician travel.

A missed failure may cause:

• lost production;
• secondary damage;
• safety risk;
• contractual penalties.

The relevant objective is closer to expected maintenance cost:

The exact terms depend on the asset and organization.

A threshold is a maintenance policy

A failure-probability model may produce

Choosing a threshold

defines an intervention rule. Different thresholds generate different false-alarm rates, missed failures, and maintenance costs. So model selection and threshold selection should be separated. A model with better AUC may still produce a worse maintenance policy at the operational threshold.

Classical reliability models remain useful

Predictive maintenance does not require machine learning. Useful models include:

• Weibull lifetime models;
• proportional-hazards models;
• accelerated failure-time models;
• state-space models;
• hidden Markov models;
• degradation processes such as Wiener or Gamma processes;
• change-point methods;
• Bayesian hierarchical models.

These models can be especially attractive when failure data are scarce and physical interpretation matters. The appropriate model follows the degradation mechanism and decision target.

Machine learning is useful when the signal warrants it

Machine-learning methods can help when the relationship among sensor streams, operating regimes, and failure outcomes is too complex for a simple parametric model. Examples include:

• gradient-boosted trees for engineered condition features;
• convolutional models for spectra or raw vibration signals;
• sequence models for multivariate trajectories;
• representation learning for high-dimensional sensor streams.

The burden of validation rises with model flexibility. A complex model should earn its complexity through out-of-asset and out-of-time performance, not through training fit.

Physics and data can be combined

Purely data-driven models can extrapolate badly outside historical operating regimes. Purely physics-based models can omit complex degradation mechanisms. Hybrid models combine physical structure with statistical calibration. For example,

can represent degradation dynamics while sensor observations follow

Unknown parameters and states can then be inferred statistically. This is often more defensible than treating every sensor channel as an unrelated tabular feature.

Deployment needs monitoring too

A predictive-maintenance model changes as the fleet changes. Potential drift sources include:

• firmware updates;
• replacement sensor models;
• new suppliers;
• changed workloads;
• maintenance-policy changes;
• aging fleet composition;
• seasonal environment changes.

Monitoring should therefore cover both prediction quality and the input process. A model can remain numerically stable while the operational meaning of its features changes.

A defensible workflow

A strong predictive-maintenance project usually follows:

1. define the maintenance decision;
2. define the prediction horizon;
3. identify failure modes separately;
4. map available sensors to physical mechanisms;
5. reconstruct the maintenance and censoring process;
6. create leakage-safe features;
7. split by asset and time;
8. establish simple reliability or statistical baselines;
9. add complex models only when they improve the relevant target;
10. propagate uncertainty into the maintenance policy;
11. evaluate cost, lead time, false alarms, and missed failures;
12. monitor the deployed system.

The algorithm appears in the middle of the process, not at the beginning.

Conclusion

Predictive maintenance is not a leaderboard problem. It is a reliability and decision problem supported by data. The core chain is

A model is useful only when that full chain is valid.

References

• Jardine, A. K. S., Lin, D., & Banjevic, D. (2006). A review on machinery diagnostics and prognostics implementing condition-based maintenance. Mechanical Systems and Signal Processing, 20(7), 1483–1510. https://doi.org/10.1016/j.ymssp.2005.09.012
• Lei, Y., Li, N., Guo, L., Li, N., Yan, T., & Lin, J. (2018). Machinery health prognostics: A systematic review from data acquisition to RUL prediction. Mechanical Systems and Signal Processing, 104, 799–834. https://doi.org/10.1016/j.ymssp.2017.11.016
• Si, X.-S., Wang, W., Hu, C.-H., & Zhou, D.-H. (2011). Remaining useful life estimation: A review on the statistical data driven approaches. European Journal of Operational Research, 213(1), 1–14.
• Zhang, Z., Si, X., Hu, C., & Lei, Y. (2018). Degradation data analysis and remaining useful life estimation: A review on Wiener-process-based methods. European Journal of Operational Research, 271(3), 775–796.