Predictive Maintenance — Use Case Template & Data Checklist

Purpose and scope

This template helps operations, maintenance, and analytics teams turn sensor and inspection data into validated predictive maintenance workflows that are practical to operate, safe to act upon, and aligned with work planning. Use the sections below to capture requirements, data needs, validation criteria, deployment safety gates, and operational handover steps.

1) Business impact statement & decision supported

Concise statement that ties the predictive signal to an operational decision and measurable outcome.

• Asset / system: (e.g., Boiler B-12, Pump P-7)
• Decision to be supported: (e.g., schedule bearing replacement within X days; run an inspection within 48 hours)
• Why this matters: (impact on safety, uptime, cost, product quality, regulatory risk)
• Target outcome / KPI(s): (e.g., reduce unplanned failures by 40%; reduce false work orders by 50%; MTTR improvement of Y hours)
• Business constraints: (lead time for spare parts, planned downtime windows, shift handoffs)

2) Required sensors & signals (selection checklist)

List candidate signals and justify their inclusion. Prefer simple, actionable signals first.

• Primary signals: (e.g., vibration - RMS, envelope, bearing temperature, motor current, oil particle counts)
• Supporting signals: (e.g., process throughput, pressure differentials, ambient temperature)
• Sample rate / resolution: (Hz, samples per minute)
• Required sensor placement: (bearing housing, motor terminal, pipeline upstream)
• Connectivity / telemetry path: (edge device, PLC tag, wireless gateway)
• Minimum historical span: (e.g., 12 months, or N failure examples)

Quick sensor-risk checklist

• Is the signal available continuously or intermittently?
• Is time synchronization guaranteed across signals?
• Are units and calibration documented?
• Is there a single source-of-truth for timestamps and asset ID?

3) Data quality checks

Define automated and manual checks required before training or live inference.

• Completeness: acceptable % missing per day/shift (e.g., <5%)
• Continuity: max allowed gap length (e.g., <10 minutes for vibration)
• Range & plausibility: min/max thresholds, known safe ranges
• Timestamp integrity: monotonic increase, correct timezone
• Label alignment checks: verify event timestamps align to asset identity
• Metadata: asset IDs, firmware versions, sensor serial numbers

4) Labeling strategy & lead-time expectations

Describe how failure or degradation labels are created and the operationally meaningful lead time.

• Label sources: failure records, planned maintenance logs, inspection notes, expert annotations
• Label definition: precise rule (e.g., 'bearing failure' = replacement within 7 days due to detected wear or seize)
• Labeling method: (automated heuristics, manual review, hybrid)
• Positive window: how far in advance an index time counts as a positive (e.g., events within 30 days prior)
• Negative sampling: choose representative healthy periods, avoid look-ahead bias
• Lead time target: operationally actionable window (e.g., 48–168 hours) and rationale
• Uncertainty labeling: allow a 'probable' or 'unknown' label for ambiguous cases

5) Model evaluation metrics & acceptance criteria

Define explicit, operational metrics and minimum performance required to consider deployment.

• Primary metrics: precision at operating threshold, recall (sensitivity) for failures within lead time
• Secondary metrics: false alarm rate (FAR) per asset-month, detection lag, AUC-ROC, calibration of predicted probability
• Baseline comparison: current rule-based method or human inspection performance
• Minimum acceptable performance: e.g., precision ≥ 0.70 at recall ≥ 0.60 and FAR < 0.05 alerts/asset-month
• Robustness checks: cross-site validation, time-based holdout tests, sensitivity to missing data
• Explainability needs: required feature attributions or signal visualizations for frontline review

6) Deployment safety & operational gates

Ensure alerts are actionable, safe, and supervised by humans.

• Operational severity levels: informational, investigate, action required — map to work order types
• Human-in-the-loop policy: require technician confirmation before scheduling invasive maintenance
• Alert throttling & suppression: debounce intervals, burst suppression, maintenance windows
• Default actions: recommended inspection checklist, data collection to confirm prediction
• Rollback criteria: how to disable or adjust model if false alarm rate exceeds threshold
• Monitoring post-deployment: daily alert volume, precision estimate, operator feedback loop

7) Handover & escalation procedures

Operationalize who does what when an alert occurs.

• Alert recipients: roles (technician, shift lead, reliability engineer)
• First response steps: local inspection, quick diagnostic checks, evidence capture (photos, vibration capture)
• Escalation criteria: severity thresholds, repeat alerts within timeframe
• Work order mapping: standard codes to CMMS, priority levels, estimated labor hours
• Feedback capture: simple post-action form: Was prediction correct? (Yes/No/Partially) Notes.

8) Integration & change management checklist

• Plan for CMMS integration or manual work order steps
• Document required training for technicians and planners
• Define SLA for response and verification
• Plan phased rollout: shadow mode → supervised alerts → autonomous recommendations
• Prepare runbooks and inspection checklists aligned to alerts

9) Monitoring, drift detection & retraining plan

• Track key operational metrics: alerts/day, precision estimate, false alarm events logged
• Implement drift alarms on input distributions and label rates
• Specify retraining cadence or trigger conditions (data volume, performance drop)
• Maintain versioned model artifacts and changelog

10) Data governance, privacy & compliance

• Authoritative data sources and owners
• Retention policy for raw sensor and labeled data
• Access controls for sensitive metadata or operational secrets
• Audit trail requirements for alerts and decisions

11) Minimum dataset & schema suggestions

At minimum, capture and version these fields for each time series record and event label:

• asset_id, sensor_type, sensor_id, timestamp, value, unit
• ingest_timestamp, data_quality_flags, firmware_version
• failure_event_id, label_type (failure/inspection/repair), label_timestamp, root_cause

12) Example use case (illustrative)

Asset: Centrifugal pump P-7. Decision: Flag high-confidence bearing degradation alerts allowing a planned bearing replacement within 72–120 hours (enough time to procure spares and schedule a technician). Primary signals: shaft vibration envelope, bearing temperature. Label source: maintenance logs where bearings were replaced and root cause confirmed. Minimum acceptable performance: precision ≥ 0.75 and false alarm rate < 0.04 alerts/asset-month in 3-month shadow test.

13) Template checklist for readiness review

1. Business impact statement completed and approved
2. Required sensors are installed and producing expected data
3. Historical labeled examples are available and validated
4. Data quality checks are implemented and passing
5. Model evaluation criteria and baseline defined
6. Human-in-the-loop and escalation procedures documented
7. CMMS/work-order integration plan exists
8. Shadow mode test plan and metrics are defined
9. Monitoring and retraining plan defined

14) Quick copyable runbook skeleton (for an alert)

When an alert is generated:

1. Technician inspects asset within X hours and records findings.
2. If visual/measurement evidence confirms degradation, create work order code W-XX and schedule within allowable window.
3. If evidence is inconclusive, collect follow-up measurements and mark prediction as 'inconclusive' for feedback to model team.
4. Log final disposition in the feedback form. This feedback will feed labeling for next retrain.

15) Notes, assumptions & open risks

Capture any domain assumptions, limitations in historical data, single-point-of-failure risks, or organizational readiness gaps.