Machine Design #49: Downtime Data — How to Record It So Data Leads to Improvement
Many factories have a downtime dashboard, but the data does not always lead to a better machine. One station calls a blocked condition “downtime,” another calls it “starved,” an operator closes an alarm before entering a reason, and a maintenance report records the repair time without the recovery phase.
Before choosing an OEE chart or Pareto, define the system:
Boundary → state → event → reason → cause → action → evidence → design feedback.
1. Define the boundary before the KPI
State whether the unit is a station, machine, cell, line, area, or site. Define included equipment, upstream and downstream responsibility, planned stops, setup, breaks, utilities, quality holds, waiting, and maintenance. A KPI cannot be compared when one team measures a station and another measures the whole line.
2. State, event, reason, cause, and action are different
State
What the equipment is doing now: running, idle, blocked, starved, faulted, setup, maintenance, paused, or waiting for permission.
Event
A time-bounded transition into or out of a state.
Reason
The selected classification for why the event occurred, such as sensor, material, changeover, utility, quality, or upstream.
Cause
The verified mechanism behind the reason. A sensor alarm is not necessarily the cause.
Action
What someone did: reset, clean, adjust, replace, wait, escalate, or change the design.
Keeping these fields separate prevents a dashboard label from pretending to be a root-cause record.
3. One downtime event can contain several clocks
Record detection time, operator acknowledgment, diagnosis start, repair start, repair end, verification, restart request, first good part, and production release. The total event may be long while active repair is short.
These phases support better actions: reduce search time, improve access, stock a part, fix a diagnostic, or change a recovery sequence.
4. Start and end need rules
Define whether downtime starts at loss of output, fault state, timeout, operator stop, or threshold duration. Define whether it ends at reset, motion, first cycle, first good part, or accepted production. Use a consistent clock and handle overlapping events explicitly.
Do not hide short events by deleting them. Classify them as microstops or noise using a stated rule.
5. Reason-code taxonomy should have layers
A useful hierarchy can include domain, mechanism, component, phase, and verified cause. For example:
| Level | Example |
|---|
| Domain | Equipment |
| Mechanism | Position confirmation |
| Component | Proximity sensor |
| Phase | Recovery |
| Verified cause | Cable fatigue at bend |
Use a code for what is known now and allow later RCA to refine the cause. Do not force operators to guess a technical root cause at 3 a.m.
6. An alarm is not a downtime reason
An alarm is a machine message. It may be caused by material, a missed handshake, a guard opening, a power dip, or an incorrect parameter. Map alarms to states and reason candidates, but retain the raw alarm and the human or engineering classification.
7. Blocked, starved, and line attribution
Blocked means a station cannot pass output because downstream is unavailable. Starved means it cannot work because upstream has no input. Neither automatically means the station design failed. Record the responsible boundary and the line impact separately.
When a line stops, allocate the event to the constraint or the initiating cause using an agreed rule. Otherwise every station will claim the same lost time.
8. Microstops need their own treatment
Very short stops may be too frequent for manual entry but large enough to reduce throughput. Capture them automatically where practical, define a threshold, group repeats, and distinguish sensor chatter, part presentation, timing, and operator intervention.
Do not add microstops to the long-stop Pareto without labeling the difference in detection and data quality.
9. Data-quality gates before the dashboard
Timestamp
Check clock source, timezone, resolution, drift, and sequence.
Completeness
Check missing states, events, reasons, phases, and operator records.
Uniqueness
Prevent duplicate events after retries, reconnects, or manual edits.
Consistency
Reject impossible overlaps, negative durations, and state transitions that the machine cannot perform.
Referential integrity
Link event, asset, recipe, shift, reason code, and change record to valid identities.
Human-entered data
Show who entered or changed a reason, when, and whether it was selected under pressure. A reason entered after recovery may be less reliable than a raw signal.
10. KPI comparisons need the same denominator
Define planned production time, availability window, good output, total output, ideal cycle, quality loss, planned stops, and excluded conditions. A percentage is meaningless if one team includes breaks and another excludes them.
Keep the raw event table so a KPI can be recalculated when definitions change. Record version of the metric and baseline.
11. Pareto needs several views
View downtime by total minutes, event count, mean duration, median duration, repeat rate, recovery phase, asset, product, shift, and verified cause. A rare long event and a frequent microstop need different design actions.
Do not let a high count of easy-to-log operator reasons hide a low-frequency safety or quality risk.
12. Correlation is not root cause
A stop may correlate with a shift, model, temperature, or operator, but the correlation does not prove the mechanism. Use downtime data to generate hypotheses, then preserve evidence and run RCA.
13. From downtime data to design action
Translate a pattern into a testable action: improve sensor mounting, add a diagnostic, change a recovery prompt, redesign access, qualify a spare, alter a state machine, or change an interface timeout. Define expected effect, owner, verification, and review window.
An action without a measurement plan is a suggestion. A metric without an action owner is observation only.
14. Hypothetical example: a part-feed station
The station has many 1–3 second stops and a few long jams. Raw data shows a repeated “sensor” alarm during a material lot, but the long stops occur after operators open the guard to clear a jam. Separate microstop chatter, material presentation, physical jam, guard recovery, and restart verification.
The design response may include a feed guide, a contamination check, debounce, a clearer jam state, access improvement, and a first-good-part confirmation. Each action needs evidence and a post-change comparison.
15. Minimum event schema
Capture event ID, asset, boundary, start and end, state, reason, cause status, phase, recipe, product, shift, operator role, alarm, source, data-quality status, action, change reference, and verification result. Keep raw and interpreted fields so later RCA can revisit the event.
16. Implementation checklist
- [ ] Boundary, asset, state, and planned-stop rules are explicit.
- [ ] Event start/end and clock source are defined.
- [ ] Reason, cause, and action are separate fields.
- [ ] Taxonomy supports unknown and later RCA refinement.
- [ ] Alarm, blocked, starved, and microstop rules are clear.
- [ ] Timestamp, completeness, uniqueness, consistency, and referential checks run before dashboards.
- [ ] KPI denominators and versions are documented.
- [ ] Pareto views include duration, frequency, phase, asset, product, and shift.
- [ ] Data patterns create owned, measurable design actions.
- [ ] Effectiveness review feeds the baseline and maintenance process.
Conclusion
Downtime data becomes engineering data only when the machine boundary, states, events, reasons, causes, actions, and evidence have distinct meanings. Define the clocks, protect data quality, compare equal denominators, and turn patterns into actions that can be verified.
The goal is not a prettier dashboard. It is a machine whose next design improvement can be explained by trustworthy evidence.
References
- ISO 22400-2:2014 — Key performance indicators for manufacturing operations management: https://www.iso.org/standard/54497.html
- ISO 9001:2015 — Quality management systems: https://www.iso.org/standard/62085.html
View all MINATA technical articles