Every packaging line RFP for the last decade has had a line item that says “PackML compliant.” Almost none of the machines that ship actually implement the PackML state model as a real, enforced state machine. What they implement is a status word that mimics the state names — Idle, Starting, Execute, Completing — sitting next to a tag list that an integrator mapped after the fact so the SCADA screen would show the right words. The state machine itself, the thing that’s supposed to reject illegal transitions and force a machine through Aborting before it can reach Stopped, often doesn’t exist in the PLC logic at all. It’s cosmetic.
That gap has been tolerable for years because most PackML deployments were single-vendor or single-line, and everyone quietly agreed to paper over the seams. It’s less tolerable now. OPC UA FX and the maturing companion specification work — including the formalized PackML information model that vendors are finally building into 2025 and 2026 releases of TIA Portal, Studio 5000, and TwinCAT — mean plants are wiring multi-vendor lines where a line controller from one supplier has to read real state and mode data off cells from two or three others, over OPC UA, without a human translating in the middle. When that data exchange is model-based instead of screen-based, a cosmetic state machine gets found out immediately.
What the OPC UA PackML Companion Spec Actually Buys You
The OPC UA PackML companion specification gives you a standardized information model: an object type for the state machine itself (aligned with the ISA-88/PackML states — Idle, Starting, Execute, Completing, Complete, Held, Suspended, Stopping, Stopped, Aborting, Aborted, and the transitional states between them), variables for current mode, active recipe or unit-level parameters, and standardized methods for commanding transitions. Instead of every vendor inventing its own tag naming convention and forcing the SCADA integrator to build a custom mapping table per machine, a client can browse the address space, find the PackML state machine object by its standardized NodeId structure, and subscribe to state changes the same way regardless of whether the PLC is a Siemens, Rockwell, or Beckhoff platform underneath.
That’s the theoretical payoff, and it’s real — when the underlying PLC logic actually implements PackML as a state machine rather than exposing it as decoration. The companion spec standardizes the interface. It does not, and cannot, force the controls engineer writing ladder logic or structured text to build a state machine that correctly gates transitions. That part is still on you.
Where Integrators Quietly Give Up
The PackML implementations that survive to commissioning and the ones that get quietly abandoned mid-project tend to fail in the same three places.
State machine drift between PLC and SCADA
The PLC’s internal state and the state the SCADA client believes the machine is in diverge, usually because someone implemented “PackML tags” as free-standing integers written by convenience logic rather than outputs of an actual state machine. A machine can sit in Execute on the HMI while the PLC’s real control logic has already dropped into a fault-holding pattern that was never modeled as Held or Aborting. The OPC UA layer will happily report whatever the tag says; it has no way to know the tag is lying. The fix isn’t an OPC UA fix — it’s discipline in the PLC: one authoritative state variable, written only by the state machine logic itself, with every other routine reading it and never writing it.
Manual/Auto mode confusion
PackML defines mode as orthogonal to state — a machine can be in Manual, Semi-Auto, or Automatic mode while independently sitting in any of the ten-plus states. In practice, a lot of PLC code conflates the two, treating “Manual mode” as a shortcut that bypasses state transition logic entirely so a technician can jog an axis. That’s usually fine in isolation. It becomes a real problem the moment a line controller upstream is making sequencing decisions based on OPC UA state data and doesn’t know the cell quietly left Automatic mode ten minutes ago. The companion spec exposes a mode variable specifically so this doesn’t have to be inferred — but only if the PLC logic actually updates it honestly when an operator turns the selector switch, instead of leaving it hard-coded or stale.
Incomplete E-Stop and Abort recovery paths
This is the one that causes real safety and throughput headaches. PackML’s Aborting/Aborted/Clearing/Stopped sequence exists precisely so a machine coming out of an emergency stop or a critical fault has a deterministic, auditable path back to Idle — not a silent reset that skips straight from Aborted to Execute because someone wired a “resume” button directly into a coil. When integrators run short on schedule, this recovery path is the first thing that gets shortcut, because it’s the least visible during a demo and the machine “basically works” without it. It’s also the exact scenario that causes confusion during actual line-stop events, when operators and maintenance techs are staring at an HMI that claims Stopped while the PLC has already re-armed something it shouldn’t have.
A Validation Checklist Before It Goes Into a Multi-Vendor Line
Before you accept a cell as PackML-compliant and put it on a line where other vendors’ controllers will consume its OPC UA state data, verify these directly against the running PLC — not against the vendor’s documentation:
- Force every illegal state transition manually (for example, commanding Execute directly from Stopped) and confirm the PLC logic rejects it rather than the HMI simply not offering the button.
- Confirm there is exactly one authoritative state variable in the PLC, written only by state machine logic, and trace every place in the code that reads or writes it.
- Toggle the Manual/Auto selector mid-cycle and confirm the OPC UA mode variable updates immediately and accurately, independent of state.
- Trigger an E-Stop mid-Execute and walk the full Aborting → Aborted → Clearing → Stopped → Resetting → Idle path manually, confirming no step can be skipped by an operator shortcut or a maintenance override.
- Browse the OPC UA address space with a generic client and confirm the PackML object type, NodeIds, and method calls match the companion specification structure — not a vendor-proprietary lookalike.
- Kill communications between the cell and the line controller mid-cycle and confirm the cell’s local state machine continues behaving correctly, rather than depending on the OPC UA link to function.
- Have a second integrator’s system — ideally on a different PLC platform — subscribe to the state data and confirm it interprets transitions correctly with zero custom mapping code.
None of this is exotic. It’s the same rigor any competent controls engineer already applies to safety logic. The reason PackML gets treated as a checkbox instead is that, until recently, nothing downstream actually depended on it being real. Multi-vendor OPC UA integration removes that cover. If your line controller is going to make sequencing and diagnostic decisions based on a neighboring cell’s reported PackML state, that state had better be true — and the only way to know it’s true is to have gone in and broken it on purpose before someone else’s equipment has to trust it.
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.
