PackML

Where it sits in the stack

PackML is not built on Machinery: it is a direct mapping of the ISA-88 TR88 interface that packaging PLCs have implemented for years, which is both its strength and its limitation. Machines on a modern line often expose both, PackML for state and counts and Machinery for identification. Weihenstephan is structurally a PackML-lineage model for brewing and beverage. The nodeset has been unchanged since 1.01 in October 2020, and PACKML is a registered server capability code, so you can detect it before browsing.

The types that matter

Using it on a real machine

1. Detect PackML before browsingRead the ServerCapabilities codes and look for PACKML, then check NamespaceArray for http://opcfoundation.org/UA/PackML/. This takes thirty seconds and tells you whether the line is a semantic integration or a tag-scraping job.
2. Subscribe to state and mode togetherMonitor CurrentState on the machine state machine and the current mode. Held and Suspended are the two states that carry the most OEE meaning, and both are meaningless without mode.
3. Read the Admin object once per shiftAdmin holds accumulated time per state and counts per product. Reading it at shift boundaries gives you an OEE dataset that the machine has already computed, which is far cheaper than reconstructing durations from samples.
4. Take counts from PackMLCountDataTypeUse the produced and defective counts rather than edge-detecting a photocell. Store the raw counter values so a job reset is visible, because Admin counters are typically cleared per job or shift.
5. Reconcile Admin against your own accumulationAccumulate state durations yourself from the transition events as well, and compare with Admin. A persistent divergence usually exposes a lost connection window or a counter reset you were not told about.

What it gives you for OEE

PackML lines are the easiest OEE wins in manufacturing, and the reason is the Admin object: the machine already maintains accumulated time in each of the 17 states, accumulated time per mode, and counts per product, which is essentially a pre-built OEE dataset. Availability falls out of the state machine, and it is unusually good because the states encode the cause structure: Held versus Suspended is the standard distinction between the machine's own problem and an upstream or downstream problem, which is exactly the blocked-versus-starved split most plants pay consultants to reconstruct. Performance comes from PackMLCountDataType against machine speed and Execute time. Quality comes free, because the count structure carries produced and defective separately rather than leaving you to infer scrap. The gaps are the usual ones: no planned production time or shift calendar, and reason codes only as far as the alarm identifiers the vendor chose, since PackML alarms are not a standardised class taxonomy the way MachineTool condition classes are.

Gotchas

• The nodeset is frozen at 1.01 (2020-10-08). That is stability rather than neglect, but it means PackML has none of the newer Machinery conveniences and will not grow to cover them.
• Most PackML machines implement the state machine in the PLC and expose it as raw tags, not as the OPC UA types. A line that is PackML in the ISA-88 sense may still be a tag-mapping job in OPC UA.
• The 17 state names are standard; vendor behaviour within them is not. Which conditions push a machine into Held rather than Suspended, and whether Completing is used at all, vary by builder. Validate against the machine, not the standard.
• Admin counters are cumulative and are reset on job or shift boundaries, sometimes silently. Always persist the raw value alongside your computed delta so a reset is distinguishable from a production burst.

Last verified 7 September 2026 against OPC UA 1.05.07. Version and publication date read from the released nodeset. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.