A production line followed a calendar-based maintenance schedule. Some interventions happened too early, consuming parts and labour on healthy equipment. Others happened too late, after an unplanned stop had already interrupted production. Maintenance engineers often knew which assets "felt" unreliable, but that knowledge lived in individuals and was not part of any repeatable process.
The maintenance decision
Every week, the maintenance team had to decide which assets to inspect, which parts to order and where to spend limited technician hours. The useful output was not a failure probability in isolation. It was an ordered list of assets with enough lead time to act, the signals behind each alert, and a clear connection to the work-order process. An alert that arrives two hours before failure is a different product from one that arrives two weeks before.
What the plant had
- Telemetry: vibration, temperature, pressure, current draw and cycle counts at one-minute intervals.
- Maintenance records: work orders, replaced components, inspection notes and planned shutdowns.
- Failure events: stoppage logs and root-cause notes, used to build outcome labels.
- Production context: shift pattern, load level, product mix and asset criticality.
Sensor data was high-frequency; failures were rare. Maintenance logs were inconsistent in wording and sometimes recorded a repair without a clear cause. A significant part of the work was reconciling these sources into one asset-and-time view before any model could be trusted.
The traps we designed around
- Perfect monitoring of unimportant assets. Data availability is not business value. Equipment was ranked by the cost of an hour of downtime, and low-criticality assets were left on a simpler schedule.
- An alert without a horizon. "Risk is high" does not tell a planner whether to act today or next month. The prediction horizon was chosen around repair lead time and maintenance capacity.
- Failures recorded as ambiguous repairs. Work orders sometimes replaced a component without stating why. Those records were treated as weak labels rather than as clean outcomes.
- Alert fatigue. A model tuned only for recall produces a queue nobody uses. Thresholds were set against technician capacity and reviewed with the team after the first weeks.
How the alerts are built
- Start with asset criticality. Equipment was ranked by the cost of an hour of downtime, not by how much data it produced.
- Define failure and the useful horizon. For each critical asset, we agreed what counted as a failure and how far ahead an alert had to arrive to change the maintenance plan.
- Engineer time-window features. Rolling statistics, trends, volatility, operating-hour counters and time since last service gave the model a view of degradation rather than a single reading.
- Combine supervised prediction with anomaly detection. Where labelled failures existed, a classification model estimated risk. Where they did not, anomaly detection established a baseline from normal operating conditions.
- Tune for the real cost of mistakes. A missed failure and a false alarm have different consequences. Thresholds were set against maintenance capacity and the cost of an unplanned stop, then reviewed with the team for alert volume.
- Connect alerts to work orders. Output landed in the maintenance dashboard and work-order process, with contributing sensor signals shown so an engineer could verify the alert before acting.
What this changes
- The schedule became risk-informed. Calendar-based maintenance remained for stable assets; critical equipment moved to inspection based on condition and evidence.
- Engineers could prioritise with reasons. Each alert carried the signals that drove it, so an inspection could start from a hypothesis rather than a hunch.
- Leadership could see where maintenance capacity went. Asset status, alert history and downtime trends became one view instead of separate spreadsheets.
- Feedback became part of the system. Whether an alert led to a real intervention was recorded, giving the model a way to improve rather than drift.
What we delivered
- An asset health score and ranked alert list for critical equipment.
- Time-to-failure estimates with the signals driving each alert.
- A maintenance dashboard showing asset status, alert history and downtime trends.
- An operating playbook covering alert review, escalation and feedback capture.
- A monitoring plan for sensor outages, model drift and alert performance.
Where this applies
This fits manufacturers, utilities and operators with instrumented critical assets and a maintenance team that can act on a weekly list. The minimum inputs are asset identifiers, high-frequency sensor history, work-order records and a credible failure definition. The first deliverable is usually the asset-criticality ranking and the failure-label audit — because predictive maintenance fails more often from unclear labels and unused alerts than from the wrong algorithm.
This is an illustrative case study built on an anonymized dataset; it does not report results from a specific client engagement. Predictive maintenance depends heavily on data quality and on the maintenance team's willingness to act on alerts; both were treated as part of the work, not as prerequisites.
