Predictive Maintenance: What Data Do You Actually Need?

Predictive maintenance promises to estimate when equipment will fail so that maintenance can be planned. In practice, many projects stall not because algorithms are lacking but because the data cannot support the goal. Failures are rare, labels are inconsistent, sensors were installed for control rather than diagnosis and operating conditions change. Before choosing a model, a team should ask what decision the prediction will drive, what lead time is useful and what evidence is available that failure precursors exist in the data.

A project may aim to detect anomalies (something is unusual), diagnose faults (what is wrong), predict remaining useful life (when will it fail) or schedule maintenance (what to do and when). Each needs different data. Anomaly detection can use only normal data, but cannot say what the anomaly is. Fault diagnosis needs labelled examples of each fault. Remaining-useful-life prediction needs run-to-failure histories or a validated degradation model.

Defining the target clearly, including the cost of false alarms and missed detections, determines the data requirements and the success criteria.

Vibration, temperature, current, pressure, flow, acoustic emission, oil analysis and operating parameters are common signals. The sampling rate must be high enough to capture the phenomenon: bearing faults need much higher rates than thermal trends. Sensor placement, mounting and calibration affect signal quality. Metadata such as load, speed, ambient temperature and maintenance history are essential to interpret changes.

Signals recorded only as averages or with heavy compression may hide the information needed.

There is no universal number. What counts is the number of independent failure events and the variety of operating conditions, not the number of rows. A million sensor readings from one machine over a month, with no failures, contain little information about failure. Multiple machines, multiple failures of each mode and several operating regimes give a firmer basis.

When failures are rare, alternatives include physics-based degradation models, accelerated tests, transfer from similar machines and simulated faults, each with caveats about realism.

Maintenance logs often record when work was done, not when the failure began, and descriptions are free text with inconsistent terminology. Time stamps may be wrong. Label noise limits achievable accuracy. A pragmatic step is to improve record keeping before modelling: standard failure codes, exact times, parts replaced and condition at inspection.

Cleaning labels with domain experts is often the most valuable task in a project.

Check for missing intervals, sensor drift, stuck values, unit changes and clock errors. Align signals from different systems in time. Separate operating states, since a signal that changes with load may be mistaken for degradation. Document every transformation. Keep raw data unchanged.

Fit preprocessing steps such as scaling on training data only to avoid leakage.

Validate on machines or periods not used in training, because a model that learns the identity of a machine will look good on random splits and fail on new ones. Measure lead time, false-alarm rate and missed detections, not just accuracy. Compare against simple baselines such as thresholds on a key signal or a physics-based indicator.

Report results with uncertainty and show examples of both successes and failures.

Data access across control, maintenance and quality systems is often the practical obstacle. Agree on data ownership, retention, security and a way to feed model outputs back to maintenance staff. A model that no one acts on has no value. Involve maintainers early to define alerts that fit their workflow.

Plan how the model will be monitored and updated when equipment or operations change.

Is the decision defined? Are failure modes and costs known? Are there enough independent failure events for the chosen target? Are the sensors adequate and calibrated? Are labels reliable? Are operating conditions recorded? Is there a validation plan that separates machines or periods? Is there a baseline? Is there a path to action?

If several answers are no, the best investment may be data collection and record-keeping rather than modelling.

We support research studies of condition monitoring and prognostics with data audit, feature engineering, model development, validation and manuscript writing, as described on the AI and data science and condition monitoring service pages. We do not provide production deployment or guarantees of prediction performance.

Threshold and rule-based methods need domain knowledge and a baseline of normal behaviour. Statistical process control needs stable reference periods. Supervised classifiers need labelled examples of each condition. Regression for remaining useful life needs run-to-failure trajectories with a measure of health. Unsupervised and semi-supervised anomaly detectors need representative normal data across operating conditions. Physics-based models need parameters and geometry plus a few measurements for calibration.

Hybrid approaches combine physics and data and can work when failures are rare, provided the physics is credible. The more complex the model, the more important it is to match it to the data you really have.

For rotating machinery, features include root-mean-square vibration, kurtosis, spectral peaks at characteristic fault frequencies and order-tracked amplitudes. For thermal assets, features include temperature gradients, rates of change and residuals from a model of expected temperature. For electrical assets, current signatures and power quality indicators are used. Features should be physically interpretable where possible and tested for stability across operating states.

Automatic feature learning from raw signals with neural networks can work but requires larger datasets and careful validation.

Loads, speeds, temperatures and products change, and signal levels change with them. Without accounting for this, a model flags normal variation as anomalies or misses real faults. Approaches include conditioning features on operating variables, training separate models per regime, normalising signals by load and including operating variables as inputs.

Record operating conditions with the sensor data; they are as important as the sensors themselves.

The value of predictive maintenance depends on the cost of unplanned failure, the cost of unnecessary maintenance, the achievable lead time and the reliability of alerts. A model with many false alarms erodes trust. A simple cost model, even rough, helps set thresholds and judge whether the project is worthwhile.

Research papers should state what operational assumptions were made and avoid claiming cost savings that were not measured.

Where failure affects safety, predictions should support, not replace, established inspection regimes. Document the intended use and the limits of the model. Avoid statements that suggest the model guarantees safety. Involve safety engineers in defining alerts and responses.

Our research support does not provide safety certification.

Can we start with only a few months of data? Yes, for exploration and baselines, but not for claims about failure prediction unless failures occurred in that period. Do we need high-frequency sensors? It depends on the failure modes; check the physics. Can deep learning compensate for a lack of failures? Not reliably. Can we use data from similar machines? Sometimes, with careful treatment of differences, and with validation on the target machine.

How do we know when the model is ready? When it beats simple baselines on held-out machines or periods with an acceptable false-alarm rate and lead time, and when maintainers trust and act on the output.

Predictive maintenance succeeds when the decision, the target, the signals, the labels and the validation are aligned. Invest first in data quality, records and a baseline; add model complexity only where it helps. Be honest about what the data can support, and plan how outputs will reach the people who must act.

Keep a data dictionary listing each signal, unit, sensor type, location and sampling rate; a change log for sensors, firmware and maintenance; and a record of operating modes. These records are cheap to maintain and invaluable when a model behaves unexpectedly. They also allow another team to reuse the data.

Audit your existing data against the checklist above, write a one-page problem statement and decide whether to collect more data first. Contact us through the contact page if you want an independent view of feasibility.