Track downtime precisely enough to prevent the next loss.

Define downtime before measuring it

Agree on the production boundary: planned production time, scheduled breaks, changeovers, cleaning, planned maintenance, no-demand periods, and the threshold that distinguishes a stop from a slow cycle. Keep these categories separate so Availability, utilization, and calendar loss are not mixed.

Use one event model across assets: start time, end time, asset, detected state, production order, product, shift, duration, initial reason, confirmed cause, responder, and effect. Never force operators to choose a root cause while the line is still down.

• Detected state: what the control system observed
• Reason: the best current operational classification
• Confirmed cause: evidence after investigation
• Impact: lost good output, constraint time, service, quality, or safety exposure

Capture events at the right resolution

Controller states and counters can capture short events that manual logs miss, but automated data still needs context. Debounce chattering signals, reconcile overlapping states, handle communications gaps, and preserve raw events. A one-minute threshold may simplify reporting while hiding hundreds of repeated 20-second jams.

Allow operators to add context with a short, controlled workflow. Use a small reason hierarchy, an “unknown—investigate” option, and notes only when they add evidence. Measure code completeness and later corrections; do not reward a high coding rate if people are guessing.

Separate where the loss appeared from where it started

In connected lines, a station may be idle because it is failed, starved, blocked, waiting for quality release, or following a schedule rule. Align upstream and downstream state changes, buffer levels, counts, and order transitions to reconstruct the sequence.

Report equipment downtime and system-output impact as different measures. A long stop on a non-constraint with buffer protection can lose no shipments, while repeated microstops on the constraint can remove saleable output immediately.

Turn a Pareto chart into an investigation queue

A Pareto is a starting point. Slice by asset, product, shift, operating state, duration band, recurrence, and constraint status. Combine total duration, event count, mean time to respond, mean time to repair, and lost output. A broad “mechanical” category is not actionable.

Select a recurring, consequential pattern and build a synchronized timeline. Compare affected and unaffected runs, review alarms and process conditions, observe the work, and test causal candidates. Keep containment, cause, corrective action, and verification as separate fields.

1. Detect

   Capture the state change and preserve raw evidence.

2. Classify

   Record a useful reason without pretending it is proven.

3. Contextualize

   Add order, product, asset state, buffer, and constraint context.

4. Investigate

   Test recurring high-impact patterns for mechanism and cause.

5. Verify

   Confirm recurrence and system impact after the intervention.

Use prediction only after the tracking foundation works

Predictive maintenance needs confirmed fault labels, reliable sensor history, and a clear intervention window. If stop codes are inconsistent and repair outcomes are missing, an advanced model learns administrative noise.

Start with tracking and response discipline, then add anomaly detection or failure prediction where signals provide useful lead time. Evaluate false alarms, missed failures, response feasibility, and production impact together.