Every plant that has standardized on PackML for OEE reporting eventually hits the same wall: the state machine that makes perfect sense for a case packer or labeler starts falling apart the moment you add a servo-driven pick-and-place axis, a robot, or a multi-axis motion controller into the same cell. PackML says the machine is Executing. The PLCopen motion function block says axis 3 is in ErrorStop because of a following-error fault that hasn’t propagated up yet. The OPC UA server, built against a companion spec that was implemented by a different vendor’s engineering team than the one that wrote the PackML logic, is reporting a third thing entirely. Now your MES has three sources of truth for one machine, and none of them agree.
This isn’t a hypothetical edge case anymore. OPC UA’s PackML companion specification and the PLCopen motion control function block library have both gotten real adoption momentum as plants push to collapse SCADA, MES, and edge analytics onto a single namespace instead of three separate polling schemes. That convergence is good — it’s the right direction. But it’s also exposing a mapping problem that the specs themselves don’t solve for you, because PackML, PLCopen, and OPC UA were written by different working groups, for different layers of the automation stack, at different times, with no obligation to line up cleanly.
Why these three models don’t nest inside each other
PackML (ISA-TR88.00.02, built on the ISA-88 state model) describes machine-level operational intent: is the equipment idle, running, held, suspended, aborting, or stopped. It’s a supervisory abstraction. It doesn’t know or care what an individual servo axis is doing — it assumes someone below it will translate axis- and device-level conditions into one of ten states and eight modes.
PLCopen motion control (Part 1 and Part 4 of the function block specification) lives one layer down. It defines axis states — Standstill, Homing, Discrete Motion, Continuous Motion, Synchronized Motion, Stopping, ErrorStop — that describe the servo drive and motion kernel, not the machine’s production intent. An axis can sit in ErrorStop because of a minor tuning fault while the rest of the machine is perfectly capable of continuing in a degraded mode. PackML has no native concept of “one axis faulted, sixteen didn’t.”
OPC UA companion specifications — Machinery, PackML, PLCopen — are information models, not state machines in their own right. They give you a standardized set of nodes and semantics for exposing whatever state machine lives underneath, but the companion spec doesn’t force a single vendor implementation to map axis states to PackML states the same way another vendor’s does. That’s the actual friction point: not that the standards conflict on paper, but that implementers fill the gaps differently.
Where Siemens, Rockwell, and Beckhoff diverge in practice
None of the major platforms are “wrong” here — they’re making legitimate engineering choices that don’t happen to match each other. Siemens environments built around TIA Portal and SIMOTION tend to expose axis diagnostics through vendor-specific technology objects, and the mapping into a PackML state model is typically hand-coded in the PLC application rather than handled automatically by the runtime. Rockwell’s Logix motion instructions integrate tightly with Studio 5000’s Add-On Instruction pattern, and plants that adopt Rockwell’s own PackML-oriented AOIs get a reasonably opinionated default mapping — but it’s still an opinion, and it changes behavior if you mix in third-party servo drives that don’t follow the same fault-code conventions. Beckhoff’s TwinCAT, with its native PLCopen motion libraries and OPC UA server stack, gives you clean axis-level state exposure through its own information model, but the translation up to PackML states is still something the machine builder has to author explicitly — it isn’t a solved problem out of the box.
The practical consequence: two machines from two different OEMs, both claiming PackML compliance and both exposing OPC UA PackML companion spec nodes, can report semantically different things during the exact same physical condition. One vendor calls a recoverable servo fault a transition to Held; another calls the identical condition Aborted. Both are defensible reads of the spec. Neither is wrong. Your MES doesn’t care whose interpretation is more elegant — it just needs consistency it can trust.
A mapping approach that actually holds up
The fix isn’t waiting for the standards bodies to harmonize this — treat that as unlikely to happen cleanly, because the specs serve genuinely different layers of the stack. The fix is deciding, at the integration layer, which model is authoritative for which kind of event, and writing explicit translation logic instead of assuming it falls out of the companion spec for free.
- Let PackML own production intent, not equipment health. PackML’s job is to tell MES whether the line is making product, not to diagnose why it isn’t. Resist the urge to encode every fault subtype as a distinct PackML state.
- Let PLCopen motion states own axis-level fault detail, and roll them up deliberately. Decide explicitly: does an axis ErrorStop map to PackML Held (recoverable, operator-clearable) or Aborted (requires a full stop-and-restart sequence)? Write that mapping table down and put it in the machine’s functional spec, not just in ladder logic buried in a subroutine.
- Treat the OPC UA information model as a transport, not a translator. Don’t assume the PackML companion spec nodes will auto-populate correctly just because the PLC vendor’s OPC UA server claims compliance. Verify what condition actually triggers each state transition in the node set, machine by machine.
- Standardize your reason codes independently of state names. PackML’s StateCurrent plus a well-designed UnitModeCurrent/reason-code pairing gets you further than trying to force more granularity into the state enumeration itself.
- Test state transitions under partial-fault conditions, not just clean start/stop. Most mapping gaps surface when one axis of many faults, or when a device goes into a warning state that isn’t a hard stop. Build your commissioning test plan around those in-between conditions specifically.
What this means for the engineer writing the logic
If you’re the one authoring the PLC-side state logic, the honest takeaway is that PackML compliance and OPC UA companion spec compliance are necessary but not sufficient. Compliance gets you a standard vocabulary. It doesn’t get you a standard meaning. That meaning has to be engineered, machine by machine, with a documented mapping table that a controls engineer, an MES integrator, and a plant reliability engineer can all read and agree on — before the line ships, not after MES starts showing OEE numbers that don’t match what the operators saw on the floor.
The plants getting this right aren’t the ones with the newest OPC UA server firmware. They’re the ones that made someone own the mapping document, tested it against real fault scenarios during commissioning, and treated “PackML compliant” as a starting point for integration work rather than a finish line.
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.
