Why PackML expertise is hard to find
PackML looks straightforward on paper. The ISA-TR88 state model has a defined set of states, a defined set of transitions, and a clear set of rules about which states can transition to which. Any competent PLC programmer can read the specification and implement the state machine diagram.
The problem is that implementing the state diagram is about 10% of the work. The other 90% is everything that ISA-TR88 deliberately leaves to the implementer: how you structure the mode manager, how unit and machine modules interact, how you handle the relationship between the PackML states and the actual machine behaviour, how you propagate commands and statuses through a module hierarchy, and how you design the framework to be reusable across multiple machines and lines rather than hardcoded to one.
This is where most PackML implementations fall down. They implement the state transitions correctly but build everything else in a way that's so tightly coupled to one specific machine that the "framework" can't actually be reused. Or they build a beautiful generic framework that doesn't quite fit any real machine without significant modification. Getting the balance right - genuinely reusable architecture that's still practical to apply to specific machines - takes experience across multiple implementations, not just one.
What I do
New framework design
Ground-up PackML framework architecture designed for reuse across your machine range. State machine, mode manager, module hierarchy, command interface, and HMI integration - built as a library your team can deploy repeatedly.
Cross-platform translation
Taking an established PackML framework from one PLC platform and rebuilding it on another - preserving the architecture and behaviour while working with the strengths and constraints of the target platform.
Existing framework extension
Adding operating modes, bringing previously unused states into service, or linking individual units into a coordinated line - without breaking what's already running in production.
Retrofit and standardisation
Retrofitting PackML state management onto existing machines that currently use ad-hoc sequential logic. Bringing consistency to a mixed line where some machines are PackML-compliant and others aren't.
Cross-platform PackML
Each PLC platform has different strengths and constraints that affect how a PackML framework should be structured. A direct port from one platform to another usually produces something that works but doesn't take advantage of what the target platform does well - or worse, fights against its limitations. I design for each platform's idioms rather than imposing a one-size-fits-all architecture.
Siemens TIA Portal
S7-1500's object-oriented extensions (methods, properties, interfaces) enable clean module abstraction. The framework leverages UDTs for standardised status and command interfaces.
Rockwell Studio 5000
ControlLogix's AOI (Add-On Instruction) model provides encapsulation for PackML modules. UDTs define standardised command and status interfaces, keeping the framework consistent across your machine range.
Beckhoff TwinCAT
TwinCAT 3's full IEC 61131-3 OOP support (interfaces, inheritance, polymorphism) makes it the most natural platform for clean PackML architecture. Structured Text is the natural choice for state machine code, though ladder and other IEC languages are available where your team prefers them.
The architecture decisions that matter
The questions I focus on when designing a PackML framework aren't about the state machine itself - that's the easy part. They're about everything around it.
How does the mode manager interact with the state machine? Can you change modes while the machine is running, or only from Idle? How do you handle the transition between manual and automatic without losing track of where actuators are? These decisions define whether operators trust the system or fight against it.
How do you coordinate independent units across a line? Each unit runs its own state machine - the challenge is managing the dependencies between them so the line runs as a whole without tightly coupling units that should be independent.
How do you handle faults across units? Does a fault in one unit stop the entire line, or can the rest continue in a degraded mode? How does the HMI present the distinction between a machine-level fault and a line-level stop?
A good PackML framework feels invisible to the operator. They press Start and the machine runs. They don't need to understand ISA-TR88 - they just need the machine to behave consistently and predictably. If the operator has to think about the state machine, the implementation has failed.
What you get
You get a PackML framework designed for your specific machines and production environment, implemented on your target platform, with full documentation covering the architecture, module structure, state/mode behaviour, and interface specifications. The framework is built as a library - reusable across your machine range, not a one-off implementation tied to a single project.
I also provide the HMI design for PackML state and mode visualisation, HMI command interface, and alarm management integration. The HMI is designed around how your operators actually interact with the machine, not around the PackML state diagram.
If the project involves translating an existing framework to a new platform, I start by fully understanding the source implementation - its architecture, its design decisions, and its quirks - before designing the target implementation. The goal is to preserve the behaviour and intent of the original while building something that's native to the target platform.