Machine health analytics: what the technique needs from your data before it works

The evidence has to be in the signal you captured

Bearing and gear faults show themselves in vibration at frequencies far above the rate a supervisory system typically samples, and a slowly logged temperature will not reveal them. Motor current carries a surprising amount about mechanical condition, but only if the waveform is captured rather than a smoothed average. Deciding what to capture therefore follows from the failure mode you are trying to see, and that requires knowing which failures actually matter on this machine. Starting from available data instead of from the failure mode produces models built on whatever happened to be logged, which is why they detect so little of interest.

Without a baseline there is nothing to deviate from

Detection works by comparison against normal, and normal must be defined for a specific operating condition. A pump behaves differently at different flows, a machine behaves differently on different products, and a compressor sounds different in summer. A model trained across all of that without knowing which condition applied will treat ordinary operating changes as anomalies and produce alerts on the day the schedule changes. The requirement is unglamorous: capture the operating context alongside the signal, and establish baselines per condition. Establishing them requires a period of running while the equipment is known to be healthy, which is itself an assumption worth checking.

Labelled failures are the resource nobody has

Approaches that learn to recognise a specific developing fault need examples of that fault, with reliable timing of when it began and what it turned out to be. Maintenance records rarely support this: the work order says a bearing was changed, not when the degradation started or whether the bearing was the actual cause. Building a usable labelled history means recording findings carefully from now on, which is a change to maintenance practice rather than an analytics task. In the meantime, anomaly detection against a healthy baseline is more honest, because it flags that something has changed without claiming to know what.

An alert with no action is a nuisance with a technical explanation

The measure of a deployment is not detection performance but what happens after an alert. That requires a defined recipient, an expected response, a way to record what was found, and a rule for what happens when the alert turns out to be nothing. Feeding findings back is the only route to improving thresholds, and it is the step routinely omitted. Also be explicit about false alarms: a system that cries wolf trains its audience to ignore it, and recovering that credibility takes far longer than losing it. Better to alert on fewer things with a clear meaning than on everything a model finds unusual.

Physics beats pattern matching on machines you understand

For well-characterised equipment, established engineering analysis often outperforms a learned model and comes with an explanation. Frequency analysis relates specific vibration components to specific geometry, so a rising component points at a particular element rather than at a general anomaly. Thermodynamic checks on a compressor or pump can identify degradation from measurements you already collect. These methods need fewer examples, survive changes in operating condition better, and produce a diagnosis an engineer can argue with. Reserve statistical learning for complex assets where no adequate physical model exists, and for combining evidence across several sources.

Frequently asked questions

Why do our analytics alerts get ignored by maintenance?

Almost always because too many of them were wrong, or because the alert did not say what to do. Credibility is spent quickly and rebuilt slowly. The remedies are to raise the threshold so that alerts are rare and meaningful, to route them to a named person with an expected response, and to close the loop by recording what was actually found. Feeding those findings back is what turns a noisy detector into something the shift team consults voluntarily.

How much healthy running do we need before a model is useful?

Enough to cover the operating conditions the machine genuinely experiences, including different products, loads and seasonal ambient conditions. A baseline collected during one product campaign will flag the next campaign as abnormal. There is no single figure, because it depends on how varied the duty is: a machine running one product continuously needs far less than one switching between many. Record the operating context alongside the signal so baselines can be built per condition rather than blended into an average.

Do we need machine learning to detect developing faults?

Often not. For rotating equipment, established vibration analysis relates specific frequency components to specific defects and produces a diagnosis rather than an anomaly score. Simple trending of temperature, current draw or efficiency catches a surprising amount. Statistical learning earns its place on complex assets with no adequate physical model, or where evidence from several sources needs combining. Starting with the engineering methods also builds the signal quality and baselines that any later model would have required anyway.