Predictive Maintenance: From Failure Mode to Work Order

Predictive maintenance should start with a failure mode, not an algorithm. The useful question is not “Can we collect vibration?” but “Which degradation mechanism matters, what observable evidence precedes it, and what action can maintenance take?” ISO 17359 describes general procedures for establishing a machine condition-monitoring program; that program boundary is important. A signal can support a decision, but it cannot establish when a failure will occur.

Start with the decision

Choose one asset, one failure mode, and one owner. For a motor-driven pump, examples might include bearing damage, misalignment, cavitation, or seal degradation. Each has different evidence and consequences. Record the operating context, inspection method, decision lead time, and required response before selecting sensors.

Keep inspections and existing safety protections. Condition monitoring supplements operator rounds, preventive tasks, alarms, interlocks, and protective trips; it does not replace them. If the monitored evidence is missing or unreliable, the safe output is “unknown,” not “healthy.”

Preserve sensor and sample provenance

A measurement without context is difficult to compare or audit. Store the asset and sensor identifiers, sensor location and orientation, engineering unit, sampling rate, window length, timestamp and clock source, acquisition firmware, calibration state, and operating regime. For derived features, retain the transformation version and enough raw data to reproduce a disputed result.

Load, speed, recipe, ambient conditions, and maintenance state can change a signal without indicating damage. Separate these regimes or include them in the analysis. Track gaps, clipped values, clock jumps, sensor replacement, and changes in mounting. Those events belong beside the measurement, not in somebody’s memory.

Establish a baseline, then inspect the trend

Build the baseline from known acceptable operation across the regimes that matter. Document its date range and exclusions. A single universal “normal” value can hide a load-dependent change; a short baseline can mistake an early fault for normality.

Trend stable features over comparable windows. Use robust summaries where occasional spikes are expected, and display the raw context around an alert. A rising trend may justify inspection, but it is evidence to investigate rather than a diagnosis by itself. The U.S. Department of Energy’s O&M guide frames predictive maintenance around detecting the onset of degradation before significant deterioration and stresses proper application, training, monitoring, and repair.

Treat labels as maintenance records, not ground truth

Labels usually come from inspections, work orders, replaced parts, or confirmed failures. They are delayed and incomplete. “Bearing replaced” does not prove that every preceding sample represented bearing damage, and “no work order” does not prove healthy operation.

Define label rules with time boundaries: which samples are pre-failure, post-repair, normal, or uncertain? Preserve the evidence and reviewer. NIST notes that maintenance work orders capture health status, faults, failures, repairs, and solutions; closing that loop makes them useful for evaluation. Do not silently convert ambiguous records into clean classes.

Prevent leakage by splitting evaluation data by time and, where relevant, by asset. Randomly mixing overlapping windows from the same event can put nearly identical samples in training and test sets. Features created after repair, work-order closure, or failure confirmation must not be used to predict the earlier decision.

Prefer a threshold until a model earns its place

A documented threshold with persistence and hysteresis is often enough. It is inspectable, inexpensive to operate, and easy to roll back. Compare it with the current maintenance rule before adding a model. Use a model only when interactions among regimes and signals produce a measurable improvement on untouched, time-ordered data.

Evaluate decisions, not just scores. Precision answers: of the alerts raised, how many were confirmed? Recall answers: of the confirmed target events, how many were alerted in time? Neither is sufficient alone. Assign the cost of a false alarm, a missed event, inspection labor, disruption, and late detection with operations and maintenance. Select a threshold from that policy; do not declare one metric universally optimal.

Close the operational loop

Every alert needs an asset, timestamp, evidence window, applicable failure mode, severity, and recommended inspection. Route it into the work-order process. Require closure codes for confirmed fault, no fault found, another cause, sensor problem, deferred work, and evidence unavailable. Review repeated false alarms rather than training users to ignore them.

Monitor alert volume, precision and recall where confirmed labels exist, missing-data rate, feature distributions, regime mix, and sensor health. Drift can come from wear, seasonal operation, a new product, maintenance, firmware, or sensor replacement. Drift is a review trigger, not automatic proof that retraining is correct.

Version the data contract, threshold or model, and decision logic. Deploy changes in shadow mode first when practical. Keep the previous version available, define rollback criteria such as unstable alert volume or broken provenance, and record who approved activation. During rollback, preserve raw evidence and continue established inspections and protections.

A deterministic threshold fixture

Use a synthetic fixture to verify logic, never as evidence of field performance: samples [2.0, 2.2, 2.4, 3.1, 3.4], threshold 3.0, persistence 2. The expected alert is at sample 5 because samples 4 and 5 are both above the threshold. No randomness, learned parameters, asset claim, or field-performance claim is involved.