I've built a lot of PackML frameworks. New ones from scratch, translations from one PLC platform to another, extensions to existing implementations. I'm a strong advocate for PackML when it's the right fit. But I've also seen it applied to machines and processes where it adds complexity without adding value, and where a simpler state machine would have served the application better.
The question isn't whether PackML is a good standard - it is. The question is whether your specific application benefits from adopting it, and whether the cost of implementing it properly is justified by the consistency and interoperability you get in return. That calculation isn't always obvious, and I've found that the people most enthusiastic about mandating PackML are often the people furthest from the PLC code.
What PackML actually gives you
ISA-TR88.00.02 defines a standardised state model for packaging and processing machinery. It gives you a common language for describing what a machine is doing at any point in time: is it Idle, is it Running, is it Held, is it in a Stopping sequence? It defines which transitions between states are permitted, and it provides a framework for organising operating modes (Production, Maintenance, Manual, etc.) that govern what the machine does in each state.
The real value isn't the state diagram itself - any competent engineer can design a state machine. The value is standardisation. When every machine on a line uses the same state model, operators learn one behavioural pattern rather than a different one for every machine. MES and SCADA systems can interface with every machine the same way. A new engineer can open any machine's code and immediately understand the top-level structure because it follows the same pattern they've seen before.
This is genuinely powerful on a multi-machine packaging line where consistency between machines matters, where you need to coordinate machine states for line management, or where you're reporting PackML status tags (state, mode, current speeds, ideal speeds, counts) upstream for OEE calculation.
When it's the right choice
PackML can be the right choice when any of the following apply:
- You're building or standardising a line of multiple machines that need to coordinate.
- Your end customer or site standard requires it - many large FMCG companies now mandate PackML compliance on new machinery.
- You have or intend to have an MES or OEE system consuming standardised status data.
- You're building a reusable framework that will be deployed across multiple machines or machine types, where the upfront investment in architecture pays back over time.
In these scenarios, the structure PackML imposes pays for itself. The standardised interfaces make integration faster, the consistent state model makes operator training simpler, and the architectural discipline it imposes on the control code pays dividends in long-term maintainability.
PackML also works well when you're translating an existing framework to a new platform. If a customer has a working PackML implementation on Rockwell and needs the same framework on Siemens for a new machine, the standard provides a shared reference point that both implementations can be verified against. I've done several of these cross-platform translations, and having ISA-TR88 as the behavioural specification makes the target implementation much more rigorous than a "make it work like the other one" brief.
When it's the wrong answer
PackML is designed for discrete and packaging machinery with identifiable cycles: infeed, process, outfeed, repeat. It maps well to machines that have a clear running state where product is being processed, and where the concepts of hold, suspend, and abort have distinct operational meanings.
It maps badly to continuous processes where the concept of a "cycle" doesn't apply in a meaningful way. It's overkill for simple conveyors and transfer systems that have two meaningful states - running and not running - and where the full PackML state model adds eight states the machine will never visit.
I've seen PackML mandated for every piece of equipment on a site, including standalone conveyor sections and turntables. The result is a beautifully standardised line on paper, but with significant debugging, documentation, and commissioning overhead on equipment that didn't need it. The standardisation argument breaks down when the cost of applying it to simple equipment outweighs the benefit of consistency.
If you're implementing PackML on a machine that will only ever use Idle, Starting, Execute, Stopping, and Stopped - and you're spending days or weeks implementing the other twelve states to comply with a standard - something has gone wrong with the decision to use PackML on that machine.
The framework trap
There's a particular failure mode I see with PackML that's worth mentioning explicitly: the over-engineered framework. An integrator or internal team builds an elaborate PackML framework with every conceivable configuration option, multiple inheritance layers, parameterised module templates, and a mode manager that supports modes nobody has asked for. The framework is technically impressive and architecturally elegant. It's also more complexity than the application requires, which means anyone maintaining it has to understand the full framework just to make simple changes.
This happens because the framework becomes the project. The original goal - consistent machine state management - gets lost in the pursuit of a perfectly generic solution. The engineers spend more time designing the framework than they spend on the actual machine application code, and the result is a system where troubleshooting a simple sensor fault requires tracing through four layers of abstraction.
The best PackML frameworks I've built and worked with are the ones that are slightly less clever than they could be. They use clear, readable code rather than elegant abstractions. They implement the states and modes the machine actually needs rather than every possible combination. They're designed so that a maintenance engineer who's never seen PackML before can follow the logic with the ISA-TR88 state diagram open on their phone. Pragmatism beats purity every time.
The simpler alternative
For machines and processes where PackML isn't warranted, I build purpose-designed state machines that borrow the good ideas from PackML without the full standard's overhead. The principles are the same: explicit states defined as ENUMs, transitions evaluated in a single location, clear entry/exit actions, and a clean separation between the state machine and the application logic it orchestrates.
The difference is that the state model is designed for the specific machine rather than conforming to a generic template. If the machine has five operational states, it has five states - not seventeen with twelve that are never used. If it doesn't need a mode manager because it only operates in one mode, there's no mode manager. The result is code that's simpler to commission, simpler to debug, and simpler for your maintenance team to support.
This approach also makes it easier to retrofit PackML later if requirements change. A well-structured custom state machine can be mapped onto the PackML state model more cleanly than ad-hoc sequential logic, because the fundamental discipline of explicit state management is already in place. You're adding the standardised state model on top of good architecture, rather than trying to impose both PackML and basic state machine discipline simultaneously.
Making the decision
If PackML isn't driven by your requirements, you probably want a clean custom state machine designed for your specific application. You'll get to commissioning faster, your maintenance team will find it easier to support, and you won't have spent weeks implementing a standard that adds no value to that particular machine.
And if you're not sure whether PackML is the right fit for your application, I'm happy to have that conversation. Getting this decision right at the start of a project is far cheaper than discovering the wrong choice six months in.