Every plant that’s tried to roll out MES-driven OEE on a high-mix discrete line eventually hits the same wall. The dashboards look great in the demo. Then someone asks why the changeover time on line 3 doesn’t match what the operator logged, and the project stalls out in a swamp of reconciliation logic — timestamp fudging, downtime reason codes typed in after the fact, “Execute” states inferred from cycle counters because nobody ever defined what Execute actually means on that machine. The tooling isn’t the problem. The problem is that the machine was never built to tell you its own state in the first place, so you’re stuck reverse-engineering it from cycle counts and I/O bits after the fact.
PackML — the state model that grew out of ISA-88 batch control and got adopted by OMAC for packaging and discrete equipment — exists specifically to kill that reconciliation work. My position is simple: if you’re doing a serious OEE or changeover-automation initiative on high-mix equipment, the PackML state machine belongs in the PLC, not in MES. MES should consume state transitions as clean, timestamped facts. It should not be in the business of guessing what state the machine was in five minutes ago.
Why bolt-on OEE always breaks on high-mix lines
On a dedicated single-product line, you can fake OEE reasonably well with cycle counters and a handful of discrete fault bits, because the line does one thing and downtime is usually obvious. High-mix lines are a different animal. Changeovers are frequent, semi-manual, and full of ambiguous in-between conditions: is the machine “down” while an operator loads a new tool, or is that a planned changeover state? Is it Starved because upstream ran out of material, or Held because an interlock tripped? If your control logic doesn’t distinguish those cases explicitly, no amount of downstream MES logic can recover the distinction. You end up with analysts manually reclassifying downtime buckets weeks later, which defeats the entire point of real-time OEE.
PackML solves this by forcing you to define, in the PLC, a fixed vocabuary of states — Idle, Starved, Execute, Held, Suspended, Stopped, Aborted, Complete, and the transitional states between them — and to make every one of those states a real, addressable condition in logic, not a post-hoc label. Once the PLC is emitting accurate state transitions with timestamps, OEE math (availability from Execute time vs. total time, performance from Execute-time throughput, quality from good/reject counts tied to Execute) falls out almost mechanically. Downtime reason codes attach naturally to Held and Stopped states instead of getting typed into a popup screen by an operator trying to remember what happened an hour ago. Changeover timing becomes the delta between the last Complete/Idle of one product and the first Execute of the next, which is a real engineering answer instead of a spreadsheet estimate.
What actually has to happen in the PLC
The core of a proper PackML implementation is a state machine — implemented as a structured text case statement, an SFC, or a set of interlocked ladder rungs — that owns transitions explicitly. Each state needs entry conditions, exit conditions, and a guarantee that the machine can only be in one state at a time. That sounds obvious until you try to retrofit it onto legacy ladder logic where “running” is really six different overlapping conditions that nobody ever separated.
The practical work breaks into three buckets:
- State ownership in the PLC: a dedicated state variable (commonly an integer per the PackML state model, sometimes mirrored as individual booleans for legacy HMI compatibility) that every piece of logic reads and only the state machine writes. Discipline here matters more than the specific data type — the moment some other rung starts setting the state directly, you’ve broken the model.
- Mode and unit tags exposed to SCADA/MES: PackML defines standard tag structures (often implemented as UDTs or function blocks) for current state, current mode, unit state description, and reason codes. These need to be exposed over whatever your SCADA layer uses — OPC UA is the natural fit given PackML’s roots and the industry’s general drift toward it, though plenty of plants still bridge it through legacy OPC DA or vendor-specific protocols.
- Reason code mapping: PackML gives you the state, not the “why.” You still have to build a reason-code table — fault codes, changeover sub-steps, starvation causes — and tie it to the Held/Suspended/Stopped transitions. This is the part vendors’ libraries genuinely don’t do for you, and it’s where most of the real engineering hours go.
Where Siemens, Rockwell, and Beckhoff diverge
All three major platforms now ship something resembling native PackML support, but “native” is doing a lot of work in that sentence, and the differences matter for project planning.
Rockwell’s Studio 5000 ecosystem has the longest history here — PackML add-on instructions and the associated PlantPAx/CIP-based tag structures are relatively mature, and a lot of OEM packaging equipment already ships with some version of it, which is part of why PackML took off in packaging before it spread to discrete assembly. Siemens’ TIA Portal support tends to come through function block libraries that map cleanly onto the state model but expect you to do more of the mode-and-unit tag wiring yourself, particularly if you’re integrating with WinCC for visualization rather than a PackML-aware SCADA layer out of the box. Beckhoff’s TwinCAT approach, being IEC 61131-3 structured-text-first, gives you the most flexibility to implement the state machine exactly as specified but correspondingly less hand-holding — you’re often building the UDTs and OPC UA information model mapping yourself rather than dropping in a pre-built block.
None of the three eliminate the reason-code and changeover sub-state work. That layer is inherently plant- and product-specific, and it’s the part every vendor library leaves for you to hand-code, because it has to reflect your actual changeover procedure, not a generic packaging-line assumption.
The changeover payoff, specifically
Changeover automation is where this pays off hardest on high-mix lines, because changeover time is exactly the metric that bolt-on OEE systems get most wrong. If your state machine explicitly models the Suspended state (or a custom sub-state sequence within it) for tool changes, recipe loads, and line clearance, you get real, repeatable changeover timing without anyone touching a stopwatch. You also get a natural hook for SMED-style analysis — since each changeover sub-state has its own timestamp, you can see exactly which step of the changeover is eating time across shifts and operators, instead of one lump “changeover” bucket that hides the actual bottleneck.
The real cost is discipline, not software
None of this requires exotic technology. OPC UA, structured text, and vendor PackML libraries are all mature and well-documented at this point. What it requires is the discipline to define your state model before you write logic, and the willingness to treat state ownership as sacred in the PLC rather than convenient to bypass under deadline pressure. Plants that do this find their MES and OEE layers get dramatically simpler, because the hard part — knowing what the machine is actually doing, in real time, with no ambiguity — already happened where it should have happened all along: in the control system, not in a report generated three shifts later.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
