Automatic downtime detection starts the clock the moment a machine stops: a PLC execution bit drops, a current transformer sees load fall below a setpoint, or a cycle pulse pauses for longer than the configured threshold, and the event is timestamped to the second without an operator touching anything [S2].
Reason capture is the harder half. Most platforms propose a reason from machine context (alarm code, tag value, last program) and ask the operator to confirm or override on a tablet, with reason-code taxonomies kept to two levels at the moment of stop and a third root-cause level filled in during post-event review [S1][S2]. Plants that have moved from paper logs to this signal-plus-confirm pattern report unplanned downtime reductions of 20 to 50% inside six months, with the largest gains on previously invisible micro-stops under five minutes [S3].
Five Signal Sources, and What Each One Actually Measures
A stop is only meaningful if the chosen signal represents productive activity, which is why vendors expose at least five detection paths and let plants mix them across a fleet [S2].
Controller or PLC data is the cleanest source when exposed, because execution state, machine mode, alarms, and part counts are already in the controller's vocabulary; the work is mapping each tag to a state definition (producing, idle, setup, stopped, unavailable data) and agreeing on what each alarm means [S2]. Digital output or cycle pulses are a reliable fallback on older equipment: a run signal or completed cycle from a PLC output carries less ambiguity than inferring state from current, but the integrator has to verify pulse width, counter-reset behavior, and units-per-cycle before the count is trustworthy [S2].
Current sensing with a clip-on CT or split-core transformer is the common retrofit path for legacy machines that expose nothing digital, but the validation list is long: standby loads, auxiliary motors, setup activity, heater currents, and state thresholds all have to be characterized before the system can tell a changeover from a fault [S2]. Vibration or other external sensing picks up a physical signature of activity and is useful where electrical signals are misleading, though sensor location, background vibration, and calibration drift each add failure modes [S2]. Manual or hybrid input stays in the mix for events no signal can detect (a material shortage, a quality hold), and the integration question is response burden and how recorded events reconcile with automatically detected ones [S2].
Why 40-Code Laminate Cards Die on the Floor
Reason-code failure on the plant floor almost always traces back to taxonomy design, not operator discipline, and three patterns repeat across packaging, plastics, metals, and food plants [S1].
Too many codes is the first killer: a list of 50 reason codes looks thorough in a conference room, but an operator next to a stopped machine does not scroll through five screens, so they pick the first close match and move on [S1]. Codes that do not match operator language are the second: maintenance calls a fault "hydraulic pressure loss," the operator calls it "the press won't clamp," and the unfamiliar term gets skipped [S1]. The third is the missing feedback loop: operators enter data and nothing visible happens, no fix, no acknowledgment, no trend shared at the next shift meeting, so the message they get back is that the data does not matter [S1].
The downstream symptom is consistent and measurable. Within two weeks of rolling out a long code list, 80% of entries cluster on "other" or "mechanical issue," and the dataset loses the resolution needed for Pareto analysis; the team quietly returns to tribal knowledge at shift change [S1]. Manual paper entry compounds the problem with a documented 1% to 8% error rate before counting forgotten events, and micro-stops under five minutes rarely make it onto an end-of-shift log at all, even though they can stack to several hours per week [S1]. The fix is a system, not a discipline talk: a shorter list, words the crew actually uses, and a visible loop where entered data leads to a fix or at least a posted trend.
Designing a Reason-Code Taxonomy Operators Will Use
The pattern that works in practice is a three-level taxonomy where the operator touches only the first two at the moment of stop, and the third level (true root cause) is added later by maintenance or continuous-improvement staff [S1][S4].
Level 1 is a broad category such as Mechanical, Electrical, Material, Staffing, or Changeover; Level 2 is a functional subcategory like Motor failure, Sensor fault, or Raw material shortage; Level 3 is the specific root cause (bearing wear, misalignment, supplier delay) filled in during post-incident review [S1]. The operator's job is two taps at the machine, which is the interaction budget a real stop allows, and the dataset still carries enough resolution for Pareto and root-cause work downstream [S1][S4].
Build the list from the floor up, not from the conference room down. A two-week pilot where operators and maintenance technicians write downtime reasons in their own words on a simple form, followed by a collaborative clustering into categories, produces a vocabulary that matches the language on the floor and measurably improves adoption [S1]. One vendor's Operations App keeps detected downtime events visible to operators for up to 9 hours to match shift patterns without overwhelming the queue, allows free-text comments but locks start and end timestamps, and lets the operator split a single stop into multiple segments if the cause changed mid-event [S4]. Reasons can be fixed (always available) or dynamic, conditioned on sensor inputs, so the same operator screen surfaces different options for a temperature trip than for a missing-material stop [S4].
Signal + Reason: How Auto-Proposed Causes Get Validated
Automatic detection and automatic cause identification are different problems, and conflating them is where most rollouts quietly break [S2][S9].
A signal proves production stopped; it does not prove why. A tag might show an alarm that looks like a tooling fault while the underlying cause is a material shortage, and the investigation surfaces a different root cause than the one the tag suggested [S2]. Best practice is to keep three fields separate: the observed signal (raw state), the assigned reason (operator-confirmed), and the confirmed cause (post-event root cause), and to require that any auto-proposed reason show the evidence behind it so the operator can correct it [S2]. Unconfirmed events should remain visible on dashboards rather than be silently coerced into a code, because a growing pile of "unknown" minutes is a useful signal that the reason workflow or the underlying data feed is broken [S2].
PLC-based detection paired with AI reason coding has become the common 2026 architecture, with the PLC side handling the deterministic stop/start logic and the model side proposing a reason from a combination of alarm code, last program, tag history, and shift context [S9]. The validation layer still matters: a Downtime Reason Manager view shows which events are confirmed, which were left blank, and which need review, and supports splitting, editing, and correction before the data feeds a Pareto or a loss report [S4]. For context on how the same telemetry stack feeds adjacent industrial analytics, see the pressure transmitter reference, since many current-sensing retrofits use the same split-core CTs and 4-20 mA conditioning chain.
Stop Rules, Schedules, and Where the Detection Logic Lives
Detection is configured, not installed, and the configuration choices decide whether the resulting dataset is usable or just a bigger pile of events [S2][S6].
The first decision is what counts as "producing" for each machine class. For a CNC, spindle rotation may include warmup or setup activity that should not count as productive run time, and for molding a completed shot may include startup rejects that distort the count [S2]. A common state set is producing, idle or waiting, setup, stopped, and unavailable data, with each state defined against observable behavior rather than inferred from a single tag [S2]. The second decision is how events align with the production schedule: stops are recorded against the time the equipment was intended to produce, and off-shift periods stay visible for utilization analysis without being auto-classified as downtime [S2].
Stop rules, the thresholds that turn a quiet line into a flagged event, are where the real engineering lives. A 30-second threshold catches micro-stops but floods the queue with material-feed blips; a 5-minute threshold calms the queue but loses the very events that often explain weekly output drift [S1][S6]. The tradeoff is usually handled with two thresholds, a short-stop bucket for sub-five-minute events that feed a separate micro-stop Pareto, and a full event for anything longer that triggers operator reason capture [S1][S4]. Plants that tune stop rules against a known shift of paper-logged events, comparing auto-detected durations to the hand-logged ones, typically converge on usable thresholds within one or two production weeks [S6]. For plants also instrumenting tank levels and flow on the same line, the same telemetry path is covered in the flow meter and automatic level references.
Validation, Pareto, and the Loop That Keeps the Data Honest
Detection without validation is a faster way to be wrong, so the workflow that survives contact with production always includes a reason-assignment review layer and a Pareto loop that operators can see [S4][S5].
The review layer splits events into confirmed, unconfirmed, and needs-review buckets, with the ability to edit descriptions, split a single long stop into multiple segments when the cause changed, and bulk-validate routine categories so engineering time is spent on the ambiguous events rather than the obvious ones [S4]. Reports then convert the cleaned dataset into a Pareto by cause, by shift, and by duration-versus-count, with a filter to include or exclude short stops so the same view supports both daily-floor triage and monthly CI review [S4].
The loop back to the floor is what keeps the data honest. Real-time alerts, by email or SMS, are configured against thresholds for the failure modes a given line actually sees (equipment fault, process slow-back, interruption, quality hold), and the same alert feed can trigger an instant report so the right people see the event while context is still fresh [S5]. For plants that want to tie stop events back to the actuator or valve that caused them, the industrial valve reference covers the spec side; for the broader question of where AR overlays on the line speed up or get in the way of the same diagnostics workflow, see Does AR Actually Speed Up Complex Assembly. The next signal worth tracking is whether the unknown-reason bucket on a given line trends down over two production weeks after a taxonomy change, because that number, more than any vendor's reported ROI, tells you the reason workflow is finally closing its own loop.