Downtime reason codes turn machine-state observations into explanations that production teams can act on. The taxonomy must be small enough to use consistently and specific enough to distinguish different losses. Define the timing and ownership rules as carefully as the code labels.
Design the requirement before the configuration
Separate the detected machine state from the attributed reason. A stopped bit does not identify whether the cause is a fault, lack of material, changeover, or scheduled inactivity. Decide how short stops, overlapping causes, planned time, and operator corrections are handled. Preserve the original event timeline and the audit trail of reclassification. Use the same definitions across shifts before comparing lines or sites.
Worked scenario
In an illustrative ten-minute stoppage, material starvation occupies the first six minutes and a machine fault the next four. Assigning the entire event to whichever reason was entered last hides the change. Choose an explicit splitting or primary-cause policy and apply it consistently. The correct approach depends on the decisions the report is intended to support.
What to verify
| Check | Evidence to record |
|---|---|
| Detection | Start/end rules, source quality, and minimum event duration |
| Attribution | Reason hierarchy, ownership, and unknown-state handling |
| Correction | Who may edit, required context, and preserved audit trail |
| Review | Unknown share, recurrent causes, and actions with owners |
Acceptance and handover
Pilot the codes with operators and compare automatic event timing with observed production. Review frequently selected generic codes and unresolved events. Do not force a guessed reason merely to complete a report; an explicit unknown can reveal a measurement or workflow problem that needs attention.
Continue the engineering work
Use the related technical library for deeper background, or follow an ASP project guide to plan the implementation sequence.
Primary references and further reading
Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.