It defines how a packaging machine reports its state and mode, and the PackTags it exposes. The control logic inside the machine stays OEM-specific, so PackML is an interface convention rather than a program you install.
When every machine on the line uses the same state model and the same tag structure, the line controller and OEE system read all of them the same way, and downtime can be attributed to the machine that actually caused it.
New machines can be specified to include PackML. Conforming existing machines needs OEM involvement or an integration shim. The standard builds into a line as machines are replaced or upgraded, not in a single project.
Packaging line integration has historically been a custom engineering exercise on every site. Each OEM machine reports its state differently and uses different tag names for the same data, so every connection to the line controller or production reporting system is built and tested from scratch. The filler reports a fault one way, the case packer another, and the palletiser a third.
PackML exists to reduce that work. It provides a common state model, a set of operating modes and a standard tag interface that let machines from different vendors expose their status the same way. Metromotion Controls is a control systems integrator based in Mount Waverley that delivers packaging line integration and OEE reporting across Melbourne, Victoria and Australia. Agreeing the PackML interface up front, before the line controller and reporting work begins, gives engineering and operations a shared definition of how each machine reports what it is doing.
PackML is a machine interface standard, not a production management system. It defines how machines expose their state, mode and data; OEE reporting, line coordination and alarm management are built on top of it. This post supports our systems integration work and connects to PLC, SCADA and HMI programming, the packaging industry and FMCG manufacturing.
PackML began as a set of guidelines from the OMAC (Organization for Machine Automation and Control) Packaging Workgroup, a vendor-neutral group of OEMs, end users and integrators. The ISA published those guidelines as technical report ISA-TR88.00.02, most recently revised in 2022, which documents the PackML state model, the operating modes and the PackTags data structures. OMAC, an independent organisation, maintains the implementation guidance.
The TR88 numbering places PackML within the ISA-88 family. ISA-88, adopted internationally as IEC 61512, defines batch control at the process level. PackML applies the same structured thinking, defined states, defined transitions and a defined data interface, at the packaging machine level.
It is worth being precise about what is standardised. PackML standardises three things: the state model (the named states and the allowed transitions between them), the mode model (the operating modes a machine runs in), and PackTags (the named data structures a machine exposes). It does not standardise the internal control logic. Two PackML-conformant fillers from different OEMs can have completely different internal programs and still present the same external interface.
The core of PackML is a defined set of machine states and the allowed transitions between them. Every machine that implements PackML reports its current state using these definitions, regardless of which OEM built it. The model pairs transient acting states, the -ing states such as Starting, Holding and Aborting that a machine passes through while a sequence runs, with the stable wait states they lead to, such as Idle, Held, Stopped and Aborted. Execute is the producing state.
| State | Definition |
|---|---|
| Stopped | Powered and stationary, awaiting reset |
| Resetting | Moving from Stopped to Idle |
| Idle | Ready, awaiting a start command |
| Starting | Running the startup sequence |
| Execute | Producing, the only producing state |
| Holding | Pausing on an operator command or internal condition |
| Held | Paused by an operator or internal condition |
| Unholding | Resuming from Held to Execute |
| Suspending | Pausing on external process conditions |
| Suspended | Paused because external conditions prevent production, such as starvation or a blockage |
| Unsuspending | Resuming from Suspended to Execute |
| Completing | Finishing the production run in a controlled way |
| Complete | Run finished, awaiting reset |
| Stopping | Running the controlled stop sequence |
| Aborting | Running the abort sequence, typically on a fault or emergency stop |
| Aborted | Safe state after an abort, requires clear and reset |
| Clearing | Returning from Aborted to Stopped |
The transitions are defined as well: a machine cannot move from Stopped to Execute without passing through Resetting, Idle and Starting. That consistency is what lets a line integration system treat every PackML machine the same way: Execute means producing, Suspended means waiting on external conditions, and Held means paused by an operator or the machine's own condition.
The distinction between Held and Suspended matters for line coordination and for OEE. Suspended is for external process conditions: the machine is starved because an upstream machine has stopped feeding it, or blocked because a downstream accumulator has backed up. Held is for operator-initiated or internal machine conditions: a pause for an adjustment, or a condition at the machine itself that needs intervention before production can continue. Keeping the two separate lets the OEE system attribute lost time to the machine that actually caused it rather than the machine that happened to stop, which is the single most common source of misleading downtime data on packaging lines.
A mode is the operating context the state machine runs in, and the same states behave differently depending on the mode. The standard names three base modes: Production for normal operation as part of the line, Maintenance for single-machine fault finding and adjustment, and Manual for direct operator control of individual actuators during setup or jam clearance. Sites commonly add modes such as clean, dry-cycle or changeover. Standardising modes lets the OEE and line systems know which time counts as production and which is excluded as planned maintenance or setup, and the mode tag is how the reporting system knows the difference.
PackTags is the standard data interface. It defines named tag structures grouped by purpose, so the line controller and reporting system read the same names on every machine instead of chasing a different tag path per OEM.
The administration tags are where OEE accuracy is won or lost. Because the counters have the same structure on every machine, the quality and performance components of OEE need no bespoke configuration per machine, and the per-state time counters give the availability component straight from the tag interface rather than from inference.
Numbers here are illustrative, used to show how the model behaves on a typical machine rather than to describe any specific Metromotion Controls project.
Consider a rotary filler on an FMCG beverage line, between an upstream depalletiser and rinser and a downstream capper and labeller. At shift start the filler moves from Stopped through Resetting to Idle, then on the start command through Starting to Execute, where it produces and its counters run. When the downstream capper jams, the filler is blocked by a condition outside itself, so it goes to Suspending then Suspended: it has stopped, but the cause is the capper, and an OEE system reading the state attributes that lost time to the capper. When the capper clears, the filler moves through Unsuspending back to Execute without operator involvement. When the filler pauses for its own reasons, an operator adjustment or an internal condition, it goes to Holding then Held, and that lost time belongs to the filler. On a fault or emergency stop it passes through Aborting to Aborted, then needs a clear and reset before it can run again.
Suppose a shift records the filler in Execute for 6.5 hours, Suspended for 40 minutes across repeated capper jams, Held for 15 minutes for its own nozzle adjustments, and Stopped for the planned breaks. The Suspended versus Held split tells the line team the bottleneck this shift was the capper, not the filler. Without the distinction, both losses would look like filler downtime, and the improvement effort would be aimed at the wrong machine.
Overall Equipment Effectiveness multiplies availability, performance and quality, and PackML feeds all three from a consistent source, which is the practical reason most sites adopt it. Availability comes from time in Execute against the planned production time, with the mode tag excluding maintenance and setup. Performance comes from the produced count against the ideal rate for the time in Execute. Quality comes from the defective count against the produced count. All three use the standard counters rather than per-machine logic, so the figures are comparable across the line. The limits of OEE as a single metric are worth understanding before a site over-invests in chasing a number, which we cover in the limitations of OEE in Australian manufacturing.
Beyond reporting, PackML supports coordinated control of the whole line. The line controller reads state and mode through the status PackTags and issues commands through the command tags, so the line starts, stops and recovers as a unit. On a clean start the controller brings machines up from downstream to upstream, so the capper and labeller are ready before the filler reaches Execute, avoiding product with nowhere to go. On a fault, it can suspend the upstream machines when a downstream machine aborts, then resume them cleanly once the condition clears, because every machine answers the same commands. This coordination logic lives in the line controller and the PLC, SCADA and HMI layer rather than inside any single machine.
Specifying and integrating PackML adds engineering effort, so it is worth being honest about where it returns that effort and where it does not.
| Situation | PackML value |
|---|---|
| Multi-OEM line with several machines from different vendors | High. Common state, mode and tag interface removes per-machine integration and makes OEE comparable. |
| Site standardising OEE and downtime reporting across lines | High. Consistent counters and per-state timers feed reporting without bespoke mapping. |
| New line build or major equipment replacement | High. PackML can be specified as a purchase requirement at lowest cost. |
| Coordinated line start, stop and recovery required | High. Defined states give the line controller a clean coordination interface. |
| Standalone machine, or a stable single-OEM line already reporting cleanly | Low. The benefit is mostly future-proofing for the next machine. |
Where none of those apply, the full PackML interface usually costs more than it returns, and the decision should follow the plant's requirements rather than the standard for its own sake.
There are four routes to bringing PackML to equipment, in roughly increasing order of cost and completeness.
On brownfield Australian packaging sites, full conformance across an existing line is a multi-year programme as machines are upgraded or replaced, not a single project. Start with the most critical machine, typically the primary filler or the line bottleneck. This connects to automation upgrades and the staged thinking we cover for legacy PLC migration in Australia.
Most of the difficulty with PackML comes from a handful of recurring errors rather than from the standard itself:
A final caution on scope: PackML standardises the interface, not the behaviour built on it. What the line does when a machine enters Suspended or Aborted is a line control design decision, and conformant machines from different OEMs can still carry implementation differences that need resolving during integration and validation.
Australian FMCG, food and beverage, and dairy packaging lines tend to be mixed-vendor and progressively upgraded rather than replaced wholesale, which is exactly the environment where PackML returns the most. A typical line carries six to twelve machines from different OEMs, each a potential source of downtime, and attributing lost production to the correct machine is the difference between fixing the real bottleneck and chasing the wrong one.
Because equipment is replaced incrementally, the most practical lever is the purchase specification, as above: each conformant machine drops into the existing OEE and line-coordination framework as configuration rather than custom development. Inconsistent machine interfaces are a root cause of the reporting problems we describe in plant data silos in Australian manufacturing, and sites running upstream batch processes can pair PackML with ISA-88 batch control for the same structured thinking across both halves of the plant. The right next step is usually a review of how the current line reports state and counts production, and where a standard interface would return the most.
Tommy Kim writes for Metromotion Controls, a Melbourne control systems integrator delivering PLC, SCADA, controls integration and commissioning for food, beverage, dairy and FMCG manufacturers across Australia.
PLC logic, SCADA architecture, HMI upgrades, fault finding and historian integration for production sites.
OEE dashboards, downtime tracking, plant historian and manufacturing analytics from validated plant signals.
Packaging line control, PackML-aligned states, changeovers, inspection and OEE data capture.
Line integration, OEE data and controls upgrades for high-volume manufacturing sites.
How CIP automation cuts trade waste and chemical cost with endpoint-driven phases, protects chemical tanks, verifies coverage and records audit evidence.
Key point
Endpoint-driven phases cut cost without weakening the clean
Published 9 May 2026
When Ignition fits an Australian food and beverage site: Perspective vs Vision, architecture and redundancy, OT security, and buying Ignition locally.
Key point
Platform fit comes before platform capability
Published 9 May 2026
Choosing a PLC platform for an Australian plant comes down to a few practical considerations: native communications protocols, local spares, the right model in the range, local integrator support, and what your own team is comfortable using.
Key point
The platform has to fit your plant, not win on paper
Published 3 June 2026
Map out scope, delivery approach and what to have ready before the first conversation. Answer a few questions and Metromotion Controls returns a tailored scoping brief on screen.