A machine downtime record combines an interval defined by state transitions, its place in the production schedule and a confirmed reason. These facts do not all come from one sensor. Keep automatic detection separate from the operator’s explanation so the system can show what is known and what still needs review.
Define the interval
Which condition indicates that the machine stopped? A running bit, a counter that does not advance or a fault code may be useful, but each has limitations. A stationary counter may mean a stop, a long cycle or material waiting. Validate the interpretation against the actual process.
Start and end times must follow the same documented rules. Signal chatter can create many short stops. If filtering or interval merging is used, specify it consistently. Different filters on different screens can produce conflicting totals for the same shift.
A reason is not a timestamp
Record the event first. If the reason is unknown, leave it unknown until a suitable operator or maintenance process confirms it. Assigning a compulsory default reason to every event creates apparent completeness without dependable information.
| Field | Evidence source |
|---|---|
| Start and end | Verified state transitions |
| Planned or unplanned | Production calendar and definitions |
| Reason | Operator or maintenance confirmation |
| Correction | Authorised user and audit record |
Keep the reason dictionary short enough to use and specific enough to inform a decision. Overly broad codes reduce value, while hundreds of similar choices encourage inconsistency. Changes to the dictionary need a relationship to historical reports.
Illustrative event
Assume a machine enters waiting at 10:15 and resumes production at 10:27. The system initially records an unknown reason. An operator later confirms a material wait. Store the 12-minute interval and the later confirmation time separately; do not imply that the reason was known automatically at the start.
If communications were also lost, evaluate the certainty of the interval boundaries. Two isolated readings at those times do not establish every state in between. Without a dependable event buffer, the unsupported part of the period remains unknown.
Reprocessing and audit
Late events can change an interval’s boundary. Define whether reports are recalculated and how users see the update. A replayed event should retain its identity so it does not create another downtime period. Deduplication belongs in the processing model, not merely in a screen filter.
Correction rights should be role-based. Retain who changed a record, the previous value and the reason. Silently deleting original events to make a total look right makes later disagreement difficult to resolve. Preserve evidence while allowing justified corrections.
Acceptance checks
Test planned breaks, brief waiting, actual faults, missing data and stops that cross shift boundaries. Compare calculated totals with a deliberately prepared event timeline. Observe whether operators use reason codes consistently and can find unclassified events.
Reliable downtime tracking comes from explainable records and a practical confirmation process. A single attractive percentage cannot establish that the underlying intervals or reasons are correct.
Resolve an ambiguous interval explicitly
Suppose a machine stops reporting at 10:12 and the collector reconnects at 10:18 with a stopped state. The available observations alone do not prove that it stopped at 10:12. It may have continued running for part of the interval. Mark the six minutes as unknown unless a reliable event source or documented operator observation supplies further evidence. The latest observed state does not justify rewriting the entire gap.
If an operator later confirms a stop time, preserve the original gap and the added interpretation with its author and time. A distinction between automatically observed and manually confirmed information helps a reviewer understand the strength of the evidence. It also lets the application recalculate a report without making the earlier version inexplicable.
Treat overlapping reasons deliberately. A machine may wait for material while maintenance is also being performed. The reporting policy could assign one primary reason and retain supporting notes, or support a documented hierarchy. Simply counting both complete intervals may inflate total downtime. Agree on the method with the people who use the report and test examples where several conditions overlap.
Keep reason codes useful to operators
An initial code list should reflect decisions the team can make. Codes that are too broad provide little guidance, while a long catalogue of nearly identical options encourages inconsistent selection. Review the unclassified category regularly: it may reveal a missing code, insufficient evidence or a workflow that takes too long during production. Do not force an operator to invent a precise cause when it is not known.
A useful acceptance exercise follows one short stop, one planned break and one longer fault from source signals to the shift report. Check how the system handles boundaries at the start and end of the selected period. Test whether a stop spanning two shifts appears correctly in both without duplicating its complete duration. Document whether displayed times represent source events or polling detections.
Finally, define who resolves provisional intervals and when a reporting period is considered reviewed. A growing backlog of unknown reasons can undermine an otherwise reliable automatic collection system. Bring a few real classifications, sample signals and the current shift-review process to discovery. The aim is a timeline that helps the team explain stops, with uncertainty visible where the available evidence cannot establish an exact cause.