What OEE actually needs from a machine

An OEE figure gets calculated somewhere downstream, and by the time anyone argues about it the argument is usually about the calculation. On a plant floor the harder question comes earlier. A machine has to report a specific set of signals before any of that arithmetic is possible, and most of the pain in a real deployment lands here, on a machine that reports three of them and not the fourth.

The production counters

Counters are the backbone. Each one answers a different question about the same units of production, and the questions stop being separable the moment one is missing.

The reject count is worth dwelling on, because it is the one most often skipped and the one that costs the most. Suppose a machine was expected to produce a certain quantity over a shift and the good units came up short. With In Count and Out Count alone, that shortfall is ambiguous. The machine may have run slowly for six hours. It may have run perfectly and produced a pile of bad parts. Those look the same in the data and they are nothing alike on the floor: one is a maintenance conversation, the other is a process conversation. A reject count is what splits them.

Cycle Time Actual against Cycle Time Target

Both are recorded in seconds. Actual is what the machine took between units. Target is what it was supposed to take.

Cycle Time Actual on its own is a line that wanders. It tells you the machine got slower on Tuesday, but not whether Tuesday was bad, because nothing on the page says what good looks like for that asset. Cycle Time Target is the reference that turns the wandering line into a statement. Without a target cycle time there is no performance baseline, and performance questions get answered by whoever has been at the plant longest.

Counts and cycle time also answer different questions, which is why both are collected. Counts tell you how many units came out. Cycle time tells you how the machine behaved between them. An asset can hit its count for the shift and still have run slowly for most of it, caught up in a burst at the end, and only the cycle time shows that.

Equipment State

Equipment State is an enumeration: Running, Idle, Stopped, Faulted.

State is what makes a gap in production readable. An hour with no output is not one thing. The machine may have been idle waiting on upstream work, stopped deliberately, or faulted. Without state, all three arrive as the same absence, and the only honest thing to say about that hour is that nothing came out of it.

State also decides where the boundaries of a run sit, which matters well beyond an OEE figure. The automatic run lifecycle behind digital process records is driven entirely by asset state, with no operator action anywhere in it. A machine that does not publish a trustworthy state does not just weaken a percentage, it stops the record from starting and stopping in the right places.

Mode

Mode is a separate enumeration: Auto, Manual, Setup, CIP.

Mode is where a plant most often ends up arguing with its own numbers. A machine in Setup is not underperforming, it is being set up. A machine in CIP is being cleaned, and a clean is a required part of the process in food and beverage, not a loss to be explained. Without Mode, a sanitation cycle arrives as unexplained downtime, somebody goes looking for a fault that was never there, and the plant learns to distrust the report.

State and Mode are separate signals because they are answering separate questions. State says whether the asset is moving. Mode says what kind of work it is doing while it moves.

The mandatory minimum

The mandatory minimum stated in the data specification is In Counts, Out Counts, Reject Counts, and State, with State carrying at least Running, Idle and Faulted.

Be careful with what that implies. The specification tables carry no mandatory-versus-optional column, so everything beyond that minimum is optional by omission rather than documented as optional. Those are not the same thing. Target Count, cycle times and Mode are not marked required anywhere, and a deployment that treats them as skippable will still produce numbers. It will just produce numbers nobody can act on.

The context that tells you what to do about a loss

Counters and states tell you that something went wrong. The context signals collected alongside them are what let anyone do something about it.

Reason Code

A downtime stop with no reason attached is a gap on a chart. With a reason code it becomes a category that can be counted across a month and ranked. The code usually comes from the HMI or the MES, entered by whoever was standing there.

Job or Order ID

Attaches production and loss to the work that was running, so a bad shift can be traced to a specific order rather than a date.

Product Code or SKU

Some products are harder on a machine than others. Without the code, a product that always runs slow looks like a machine that intermittently runs slow.

Shift or Operator ID

Distinguishes a pattern that follows the machine from one that follows the schedule.

Start and Stop Events

Boolean events marking the transitions, which is what lets a duration be calculated rather than inferred from the gaps between samples.

Agreeing the model for a machine type

None of this arrives by default. A filler, a packer and a saw all report different things under different names, and the mapping between what a machine publishes and what the platform expects is agreed per machine type during implementation. There is no published catalogue of machine-type models to read ahead of time, and any vendor who hands you one before looking at your floor is describing their assumptions rather than your equipment.

What you can do ahead of time is walk the line with this list and mark, asset by asset, which of these signals already exists in the controller and which does not. That walk is the difference between a scoping conversation grounded in your equipment and one grounded in hope.

Keep reading