Key takeaways
- Select detectable failure modes, not every critical asset.
- Time alignment and operating context matter as much as sensor volume.
- False alerts consume maintenance capacity and belong in the business case.
- Read-only integration and human review are sensible early production boundaries.
Begin with the maintenance decision
Name the asset, failure mode, user, required lead time and available intervention. Predicting a failure that cannot be detected early enough or cannot be acted on does not create useful value.
Audit five evidence groups
- Asset context: - hierarchy, criticality, manufacturer, configuration and operating duty
- Maintenance history: - work orders, failure codes, findings, parts and completion notes
- Condition evidence: - vibration, current, temperature, pressure, flow, oil or other relevant signals
- Operating regime: - load, speed, product, recipe, ambient conditions, starts and stops
- Outcome labels: - confirmed failure mode, false alarm, inspection result and intervention outcome
Timestamps, units, tag meaning and equipment identifiers must align across sources. A large historian export is not useful if it cannot be tied to a specific asset state and maintenance outcome.
Choose the learning approach from the evidence
Supervised failure prediction needs representative examples of the target failure and comparable non-failure operation. If those labels are sparse or inconsistent, anomaly detection, condition thresholds or expert-designed features may be more appropriate. A hybrid can be better than claiming a universal failure forecast.
Build the evaluation around operations
Measure whether the system surfaces the right event with enough lead time for inspection or intervention. Track missed events, false alerts, alert clusters, review time and maintenance outcomes by asset and operating regime. Calibrate thresholds to the team's capacity and risk.
Integrate carefully
Start with read-only historian and maintenance data. During a pilot, route recommendations to a review queue before creating work. Production write-back to a CMMS or ERP should have an approved schema, ownership, duplicate handling and rollback. Product names describe possible contexts, not guaranteed connectors.
Include the operating cost
The business case includes sensing, data engineering, edge or cloud infrastructure, model evaluation, integration, user review, maintenance and updates. Compare that cost with the failure modes the system can plausibly detect not with total plant downtime.
Define stop conditions
Stop or redesign when the target failures are absent, labels cannot be trusted, operating regimes are unstable, interventions are not possible, or false alerts exceed the team's capacity. A disciplined stop protects the next use case.
