PackML was written for packaging machines. That’s not a knock — it’s the whole point of ISA-TR88.00.02. It gave the packaging industry a common vocabulary for machine states, a standard tag set (PackTags), and a way for a case packer from one OEM to talk to a labeler from another without a controls engineer reinventing the handshake every time. It worked well enough that it stopped being a packaging thing.
Walk the floor at any automation trade show now and you’ll find PackML state machines wired into filling stations, robotic palletizers, weld cells, and general assembly equipment that never touches a package. Rockwell’s Studio 5000 add-on instructions, Siemens’ TIA Portal libraries, and Beckhoff’s TwinCAT tooling all ship PackML state machine blocks as either the default or a one-click option on new controller projects. PLCOpen’s function block specifications made the pattern portable across vendors, which means an OEM building a machine for a discrete, non-packaging line can hand you PackML state behavior essentially for free — it’s already in the firmware.
That’s the actual news here, and it changes the calculus for anyone speccing a new line in the next buying cycle. The question is no longer “should we adopt PackML.” It’s “our OEM already gave us PackML — do we run with it, trim it, or fight it.”
What PackML actually gives you
Strip away the acronym and PackML is three things: a defined set of states (17 in the full model — Idle, Starting, Execute, Completing, Held, Stopping, Aborting, and so on, plus the transitional states between them), a set of standard modes (Production, Maintenance, Manual), and a standard data structure for exposing status, counts, and faults to a line controller or MES. The value isn’t the states themselves — most controls engineers could sketch a reasonable state machine from scratch. The value is that it’s the same state machine across machines from different builders, which means your line integration layer, your MES connector, and your operator HMI conventions can all be written once and reused.
That reuse is where the real time savings live: in mode changes, in fault recovery, and in the MES handshake — not in the state diagram itself.
Mode changes
PackML’s mode structure (Production, Maintenance, Manual, and optionally Manual-with-interlocks-bypassed) gives you a standard way to ask “is this machine allowed to run product right now, and under what supervision.” When every machine on a line answers that question the same way, your line controller’s mode-broadcast logic stops needing per-machine exception handling.
Fault recovery
The Held/Aborting/Stopping distinction is genuinely useful outside packaging. A robotic cell that can distinguish “operator paused for a changeover” (Held) from “safety fault, full stop and re-home required” (Aborting) gives your MES and your OEE calculation much cleaner data than a machine that just reports “not running.” This is one of the strongest arguments for adoption even on equipment PackML was never designed for.
Line-to-MES handshakes
If your MES or line-level SCADA already speaks PackTags — and most modern MES integration layers do, because packaging drove that standardization first — every additional machine that natively exposes PackML state is one less custom driver, one less mapping table, one less thing that breaks when a controls engineer leaves.
Where it stops paying for itself
The 17-state model assumes a certain machine shape: discrete batches of product moving through a bounded cycle, with clear start/stop/changeover semantics. A lot of packaging equipment fits that shape naturally. A lot of non-packaging discrete equipment doesn’t, and forcing the fit creates work rather than removing it.
Continuous or semi-continuous processes are the clearest mismatch. A filling line with a genuinely continuous fill head, or a coating process with no natural “Execute” boundary, ends up with an engineer inventing artificial completion events just to satisfy the state machine’s expectation of a cycle. That’s translation logic you didn’t have before, invented to serve a model that doesn’t describe what the machine is actually doing.
Complex robotic cells are the second mismatch. A robot running twelve different part programs with independent tool-change logic, vision-guided retries, and asynchronous multi-axis recovery sequences doesn’t map cleanly onto a single linear state progression. You can force it — vendors will hand you the AOI or function block and tell you it works — but you’ll often find yourself building a shadow state machine inside “Execute” to track what the robot is actually doing, which defeats the purpose of adopting a standard in the first place.
The tell is simple: if you’re spending more engineering time writing logic to translate your machine’s real behavior into PackML states than you would have spent writing your own state machine and a clean MES interface, you’ve force-fit the standard. The standard was supposed to remove translation layers, not add one.
A mapping exercise worth running before you commit
Before adopting PackML as the default on a new non-packaging line, take the OEM’s proposed state diagram and run your actual production scenarios against it on paper:
- Normal cycle: Does Idle → Starting → Execute → Completing → Idle actually describe one unit of work on this machine, or are you inventing a “unit of work” that doesn’t exist in the real process?
- Changeover: Does Held cleanly capture what happens when an operator swaps tooling, or does your changeover involve sub-states (partial teardown, partial rebuild) that Held can’t distinguish?
- Fault and recovery: Map your three most common real faults. Do they land cleanly in Aborting/Stopping, or does your recovery sequence need information the standard states don’t carry?
- Manual intervention: Does Manual mode match how your maintenance techs actually jog and test the equipment, or will they route around the state machine entirely because it’s more friction than it’s worth?
- MES handoff: Does your MES or line controller already consume PackTags natively? If yes, that’s the single strongest argument for adoption regardless of how well the states fit the machine — the integration savings on the MES side can outweigh an imperfect fit on the machine side.
If the exercise produces a clean mapping with maybe one or two states you’ll rarely use, adopt it — you’re getting the vendor tooling, the MES integration path, and a common language for your controls team essentially for free. If it produces a page of asterisks and workarounds, don’t force it just because it shipped in the firmware by default. Write a purpose-built state machine, expose it through OPC UA with a sane information model, and spend your integration budget on the MES connector instead of on making a robotic cell pretend to be a case packer.
The standardization push from Rockwell, Siemens, and Beckhoff is real and it’s going to keep pushing PackML further into general discrete automation because the tooling makes it the path of least resistance for OEMs. That’s a good enough reason to evaluate it seriously on every new line spec. It’s not a good enough reason to skip the mapping exercise.
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.
