Machine Data Without Context Is Noise: Downtime Reasons, State Models and Data Quality
DBR77 Team · Published
Machine data becomes useful when every signal is translated into a state everyone agrees on and every stop carries a reason. Without a machine state model and downtime reason codes, a signal that says "stopped" cannot tell you whether the line waited for material, changed over or broke down.
Why a raw signal is not information
A PLC bit or a current sensor only tells you whether the machine is cycling. A planned cleaning, a jam and an empty infeed look identical in the raw data.
Without context, the biggest bar on the downtime Pareto is "unknown", which gives nobody anything to act on.
On one corrugated-packaging line, capturing the reason in two seconds at the moment of the stop took "unknown" off the Pareto and, together with live machine status and alerts with owners, helped cut average response time to a stop from 24 to 9 minutes.
A simple machine state model
A state model is a short, fixed list of states that every machine can be in, with one definition for each. Industry standards go further: the OMAC PackML model, adopted by ISA as TR88.00.02, gives machines consistent states across manufacturers. For monitoring a brownfield line, seven states are usually enough.
| State | Definition | How it is detected | Counts against OEE? |
|---|---|---|---|
| Running | Producing at or near the ideal rate | Cycle or count signal increases | No, but slow cycles are a Performance loss |
| Idle (minor stop) | Short stop resolved by the operator | No cycle for longer than a few cycle times, under the reason threshold | Yes, Performance |
| Unplanned stop | Breakdown, jam or fault above the threshold | No cycle beyond the threshold, no planned event active | Yes, Availability |
| Changeover | Switching to the next product or format | Operator starts it on the tablet or the order changes | Yes, Availability |
| Planned stop | Cleaning, planned maintenance, inspection during scheduled time | Selected by the operator from planned reasons, or from the schedule | Yes, Availability |
| Starved / blocked | Machine ready, but no input from upstream or no space downstream | Buffer sensors or PLC flags, or reason selected | Yes, Availability, tagged as an external cause |
| Not scheduled | No production planned: breaks, no shift, no orders | Shift calendar | No, excluded from planned production time |
The OEE column follows Vorne's definitions: planned production time excludes only time with no intention to produce, and the six big losses treat setups as availability loss and minor stops as performance loss. Some plants exclude planned maintenance, and either choice works if it is applied everywhere.
How to design downtime reason codes operators will use
A state shows that the machine stopped, and the reason says why. A good reason list is short enough to use in two seconds and specific enough to act on.
- 10 to 15 reasons per machine type. Longer lists end with "other". A press and a palletizer need different lists.
- Operator language. Use words like "film tear" and "glue nozzle blocked"; cost-center codes copied from the ERP do not work at the machine.
- Two levels at most. A category (mechanical, material, quality, organization) and a specific reason.
- A clear threshold. Vorne gives an example policy: any stop longer than two minutes gets a reason. Shorter stops are counted as minor stops.
- Capture at the stop. The operator picks the reason on a tablet at the machine while the cause is still obvious. The operator app is built for this.
Review the list monthly. If "other" grows above a few percent of downtime, operators are telling you a reason is missing.
See states and reasons on a live line
In a 30-minute online demo we show how DBR77 IIoT turns machine signals into states, captures reasons at the stop and builds a Pareto you can act on.
Keeping definitions consistent across shifts
Data loses value fastest when shifts use different words for the same event. The night shift logs a jam as "mechanical", the morning shift as "material". After a month, one large problem shows up on the Pareto as two half-sized ones.
Write the state model and the reason list down, with one sentence of definition per item. Train every shift on the same version. Change definitions only on a fixed date, and record the change, so that trends before and after are still comparable.
The same applies at plant level. One aim of ISA-95 is a common terminology for production and business systems. For a single plant, the practical version is one dictionary that every shift and system uses. The modules page shows how states, reasons and alerts fit together in DBR77 IIoT.
Data quality checks before you scale
Before you copy a line's setup to the next five lines, check that the data is right. Errors that are small on one line multiply across a plant.
- Missing states. Add up all states per shift. If they do not cover the full shift time, a signal is dropping out or a state is undefined.
- Wrong ideal cycle times. Vorne notes that performance above 100% usually means the ideal cycle time is set too high. Check every product, not only the main one.
- Clock drift. If edge devices, PLCs and servers disagree on the time, stops land in the wrong shift and response times are wrong. Synchronize them, for example with NTP.
- "Unknown" and "other". Track their share of downtime weekly. A rising share means a reason list or a habit needs fixing.
For which signals to collect in the first place, see what data to collect from machines.
Where context pays off
With clean states and reasons, live OEE can be trusted because it is calculated from agreed events, and a shift handover can be built from the data.
For manual stations without any machine signal, a camera can supply the state. The IRIS Vision AI layer detects cycles and presence without wiring into the machine.
FAQ
What is a machine state model?
A fixed list of states a machine can be in, such as running, idle, unplanned stop and changeover, each with one definition and one detection rule. It turns raw signals into events you can compare across machines and shifts.
How many downtime reason codes should a machine have?
Usually 10 to 15 per machine type, in the language operators use. Longer lists push people to "other". Review the list monthly and add a reason only when a real gap appears.
Do planned stops count against OEE?
In Vorne's definition, yes. Only time with no intention to produce, such as breaks, is excluded from planned production time. Changeovers, cleaning and planned maintenance still reduce availability.
What should we check before scaling to more lines?
Check that states cover the full shift time, that ideal cycle times are correct for every product, that all clocks are synchronized and that "unknown" is a small share of downtime.
Conclusion
A practical first step is the missing-states check on one line: add up the states for one shift and see whether they cover the full shift time, then look at how much downtime sits under "unknown" and "other". Those two numbers show whether the state model or the reason list needs work before you copy the setup to the next line.
Turn your machine signals into decisions
Book a 30-minute demo to see the state model, reason capture and live Pareto in DBR77 IIoT, and how they would fit your lines.
Sources
- Vorne, The Six Big Losses, 2026
- Vorne, Calculating OEE, 2026
- OMAC, PackML, 2026
- ISA, ISA-95 standard, 2026
- IETF, RFC 5905: Network Time Protocol Version 4, 2010
- DBR77 IIoT pilot data, corrugated-packaging line (client anonymous), 2026