A rotating equipment PHM pilot: from signals to maintenance decisions

01

Choose one failure mode and asset group

Choose a pump, fan or compressor group with usable history, an observable mechanism and an actionable response. State which equipment is out of scope. Do not promise to predict every failure when sensors observe only some mechanisms.

02

Design the data chain

Map asset IDs, historian tags, sampling rates, operating states, work history, inspections and failure events. Align timestamps and log gaps, sensor changes, shutdowns and operating modes. A valid startup signal can look anomalous if a model was trained only on steady-state operation.

03

Measure events and actionability

Separate training and validation by time and, where possible, by asset. Report false alarms per asset-month, lead time before an event, detected-event rate and engineer verification effort. One aggregate accuracy score does not show whether maintenance can use the alert.

04

Define the path of an alert

Each alert needs evidence: trend, operating context, suspected mechanism and confidence. An owner verifies it, records a disposition, creates a work request or work order when appropriate, and feeds inspection findings back to the system. Do not turn every anomaly into a work order automatically.

05

Set scaling criteria

Scale only with a baseline, manageable alert volume, a closed feedback loop and measurable value such as avoided downtime, fewer unnecessary checks or faster diagnosis. If failures are too rare for evaluation, report that limitation rather than extrapolating ROI.

06

Establish a baseline and define failure events

Agree on what counts as a failure event before choosing an algorithm: a trip, loss of function, emergency intervention, or finding during overhaul. A work order usually records repair time, not the start of degradation; using it directly as a label can distort lead time. A reliability engineer should review an event register linking asset ID, failure mode, symptom, detection time, action, and verified outcome.

Baseline unplanned downtime, detection and response time, routine inspection effort, intervention cost, and existing alerts. Separate planned shutdowns, startups, load changes, and sensor faults. With too few failures, the pilot may assess anomaly quality and the triage workflow, but it cannot credibly estimate recall or event-based ROI.

07

Build an auditable pipeline

Vibration, temperature, pressure, and current data need operating-state context. One threshold across all loads commonly produces false alarms. Preserve tag mappings, units, sampling, filtering, gap handling, and feature versions. Mark sensor replacement and calibration so a measurement change is not mistaken for equipment degradation.

Split training and validation by time, and check for leakage when windows from one event appear in both sets. Evaluate by asset and operating mode; a strong average can hide a troublesome group. Case review should show the engineer the trend around the alert, operating conditions, relevant work orders, and why the model flagged the signal.

08

Turn alerts into accountable decisions

A practical triage can distinguish data or sensor checks, intensified monitoring, and engineering review for a work request. Each level needs a response time, owner, and minimum evidence. Capture a disposition such as true concern, process transient, sensor issue, known condition, or unresolved. This matters more than another dashboard because it creates feedback labels for improvement.

Base go/no-go on operating capacity: alerts per asset-month, triage effort, useful lead time, share of alerts with disposition, effect on maintenance planning, and unproven limits. If events are too rare for a financial claim, report observed evidence and propose an extension with explicit conditions. Do not extrapolate one machine to a fleet with different duty cycles and data quality.

09

Illustrative example: an alert on a standby pump

Suppose the pilot monitors a duty/standby pump group. Vibration rises after a mode change. The pipeline marks operating state and sensor status; the engineer finds that the change is confined to startup and does not immediately create a work order. After several cycles, the pattern persists into steady operation and bearing temperature rises. The alert is escalated and an engineer raises a work request to check lubrication and alignment. The inspection finds an actionable condition; its date and operating context return to the event register. The pilot report records alert workload, verification time, useful lead time, and inconclusive cases. One event is not evidence of fleet-wide predictive accuracy.