The problem with fixed limits
Most plants start condition monitoring with alarm limits. A vibration velocity of 4.5 mm/s RMS is "alert", 7.1 mm/s is "danger", and a technician gets an email when a sensor crosses the line. It is simple, explainable and cheap, and it has carried reliability teams for decades.
Classical baseline · fixed thresholds
One number per measurement point, compared with a limit taken from a standard such as ISO 20816 or from experience. The same limit applies whether the pump runs at 40% or 100% load, in winter or in summer, on a new impeller or a worn one.
That last sentence is the weakness. A machine's normal vibration depends on speed, load, temperature and process conditions. A limit set high enough to stay quiet at full load is too high to notice a developing fault at part load. Set it lower and every load increase triggers a false alarm. After a few weeks of false alarms, people stop reading the emails.
A second weakness is that a single overall number throws information away. An early bearing defect produces short impacts that barely change RMS but change the shape of the signal: its kurtosis, its envelope spectrum, its high-frequency energy. The overall level only moves when the damage is already advanced.
What machine learning adds
The explainer below runs 180 days of a pump whose load changes every nine days. A bearing defect starts on day 104. The top panel shows what a threshold sees. The bottom panel shows a simple ML model that learned, from healthy data, how vibration depends on load, and alarms on the residual: the difference between what it measured and what it expected for today's load.
This is the core idea behind most industrial ML, and it does not require deep learning. The model learns normal behaviour in context, so that deviations stand out against the right baseline. Three capabilities follow from it.
Threshold thinking
- One limit per sensor
- Ignores speed, load, temperature
- Looks at one overall number
- Says "too high", not why
- Says nothing about time to failure
ML thinking
- Learns normal behaviour per asset
- Conditions on operating context
- Uses many features, including signal shape
- Classifies the likely fault
- Estimates remaining useful life with uncertainty
Detection, diagnosis, prognosis
Prognostics and health management (PHM) splits the job into three questions. Each has its own family of ML methods, and each has its own page on this site.
| Question | ML task | Typical methods | Needs labels? |
|---|---|---|---|
| Is something wrong? | Anomaly detection | Isolation Forest, autoencoders, one-class SVM, forecasting residuals | No, only healthy data |
| What is wrong? | Classification | Random Forest, gradient boosting, SVM, 1D and 2D CNNs | Yes, examples of each fault |
| How long do we have? | Regression or survival | Health indicators, exponential and Bayesian degradation models, LSTMs, survival models | Run-to-failure histories |
The order matters for planning a project. Anomaly detection needs only healthy data, which every plant has in abundance. Diagnosis needs labelled faults, which are rarer. Prognosis needs complete degradation histories, which are rarest of all. Most successful programmes start with detection and grow from there.
Earlier warning on the P-F curve
Reliability engineers describe a failure with the P-F curve: from the point P where a defect can first be detected, to the point F where the asset fails. The interval between them is the time you have to plan a repair. Every technique sits somewhere on this curve. ML moves detection to the left because it combines many weak signals and compares them with learned normal behaviour.
Where ML is the wrong tool
Machine learning is not automatically better. It is the wrong choice when:
- A physical rule already answers the question. If a bearing temperature above 95 °C always means stop the machine, encode the rule. A model adds nothing but risk.
- There is no healthy reference. A model trained on a machine that was already damaged learns damage as normal.
- The decision cannot tolerate unexplained output. Safety trips belong to certified protection systems, not to an anomaly score.
- Nobody will act on the alert. An early warning only creates value if maintenance planning uses it. The workflow matters as much as the model.
Key takeaways
- Fixed limits ignore operating context, which forces a trade-off between false alarms and late detection.
- ML learns normal behaviour in context and alarms on deviations from it, which removes much of that trade-off.
- Detection needs only healthy data; diagnosis and prognosis need increasingly rare labelled data.
- Keep fixed limits as a sanity check and for safety; use ML for earlier, more specific warnings.
Try it in the apps
The Vibration Analyzer computes the features an ML model would use, including kurtosis and envelope spectra, on your own data.
Race a fixed alarm yourself
In the Anomaly Detection Lab, inject a cooling fault that stays inside the normal range and see which detectors notice.