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 on the line reports its state differently, uses different tag names for the same data, and needs a bespoke interface before the line controller or production reporting system can understand what it is doing. The filler reports a fault one way, the case packer another, and the palletiser a third, so every connection is built and tested from scratch.
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. What happens with that data, such as OEE reporting, line coordination, scheduling and alarm management, requires additional systems and configuration. This post supports our systems integration work and connects to PLC, SCADA and HMI programming and the packaging industry.
PackML began as a set of guidelines from the OMAC (Organisation for Machine Automation and Control) Packaging Workgroup, a vendor-neutral group of OEMs, end users and integrators. Those guidelines were formalised by the ISA and published as the technical report ISA-TR88.00.02, which documents the PackML state model, the operating modes and the PackTags data structures.
The TR88 numbering places PackML within the ISA-88 family. ISA-88, adopted internationally by the IEC 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. The OMAC Packaging Workgroup is hosted under the ISA, which is why the standard, the technical report and the maintaining group all sit in the same standards ecosystem.
It is worth being precise about what is and is not 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 state, mode and tag 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 is often drawn as a state machine, with three command-driven "acting" states (Starting, Stopping, Aborting) that the machine passes through, and stable "wait" states (Idle, Stopped, Aborted) that it rests in.
| State | Definition |
|---|---|
| Stopped | Machine is powered and stationary, awaiting a reset or start command |
| Resetting | Executing the reset sequence to move from Stopped to Idle |
| Idle | Ready and waiting for a start command, all preconditions met |
| Starting | Executing the startup sequence, not yet at production rate |
| Execute | Producing at normal rate, the only true producing state |
| Holding | Executing the hold sequence in response to an upstream or downstream event |
| Held | Paused in a stable, safe condition awaiting the condition to resolve |
| Unholding | Executing the sequence to resume from Held back to Execute |
| Suspending | Executing the suspend sequence for an internal machine condition |
| Suspended | Paused on an internal condition, such as a low-level material feed |
| Unsuspending | Resuming from Suspended back to Execute |
| Completing | Finishing the production run in a controlled way |
| Complete | Run finished, awaiting reset |
| Stopping | Executing the controlled stop sequence |
| Aborting | Executing the abort sequence, typically on a fault or emergency stop |
| Aborted | Safe stopped state after an abort, requires clear and reset |
| Clearing | Executing the clear sequence to return from Aborted to Stopped |
The transitions are defined as well. A machine cannot move from Execute directly to Aborted without passing through Aborting, and it 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: the line controller knows that an Execute state means producing, a Held state means waiting on a neighbour, and a Suspended state means waiting on the machine's own materials.
The distinction between Held and Suspended matters for line coordination and for OEE. Held is for conditions caused by other machines, such as a downstream accumulator that has backed up or an upstream machine that has stopped feeding. Suspended is for conditions internal to the machine, such as a label roll running low. 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.
Alongside the state model, PackML defines machine modes. A mode is the operating context the state machine runs in, and the same states behave differently depending on the mode. The three base modes named in the standard are a starting point that sites extend.
| Mode | Purpose |
|---|---|
| Production | Normal operation. Counters accumulate, the machine runs as part of the line. |
| Maintenance | Single-machine operation for fault finding and adjustment, usually at reduced speed, often without counting toward production figures. |
| Manual | Direct operator control of individual actuators and axes, used for setup, threading material or clearing a jam. |
Sites commonly add further modes such as clean, dry-cycle or changeover. The value of standardising modes is that the OEE and line systems know which time should count as production and which should be excluded as planned maintenance or setup. A machine running in Maintenance mode that is not part of the scheduled production window should not damage the availability figure, and the mode tag is how the reporting system knows to exclude it.
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 PackTags defines produced, defective and processed counters with the same structure on every machine, the quality and performance components of OEE can be calculated without bespoke configuration per machine. The per-state time counters mean the availability component, and the breakdown of why a machine was not producing, comes straight from the tag interface rather than from inference.
Numbers and transitions 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, sitting between an upstream depalletiser and rinser and a downstream capper and labeller. Walking the filler through a shift shows how the states and modes carry meaning the line controller and OEE system can both rely on.
[Stopped]
| reset command
v
[Resetting] --> [Idle]
| start command
v
[Starting] --> [Execute] <-- producing, counters running
| \
downstream capper backs up | \ label roll on the capper runs low
(Held) | \ (this filler is starved downstream)
v v
[Holding] [Suspending] (rarely both; shown for contrast)
| |
v v
[Held] [Suspended]
| |
capper clears, line ready | | material replenished
v v
[Unholding] [Unsuspending]
\ /
\ /
v v
[Execute] <-- resumes producing
|
end-of-run or fault |
+------------------+ +------------------+
| controlled stop | | e-stop / fault
v | v
[Stopping] --> [Stopped] [Aborting] --> [Aborted]
|
clear + reset
v
[Clearing] --> [Stopped]The behaviour to read from this is that the filler only counts production time while it is in Execute. When the downstream capper backs up, the filler goes to Holding then Held: it has stopped, but the cause is downstream, so an OEE system reading the state correctly attributes that lost time to the capper, not the filler. When the filler's own material feed runs low it goes to Suspending then Suspended, and that lost time belongs to the filler.
For example, suppose a typical shift records the filler in Execute for 6.5 hours, Held for 40 minutes (downstream capper jams), Suspended for 15 minutes (its own change of bulk product), and Stopped for the remaining planned breaks. Availability is calculated from the producing time against the planned production time, and the Held versus Suspended split tells the line team that the bottleneck this shift was the capper, not the filler. Without the state distinction, both losses would look like "filler downtime", and the improvement effort would be aimed at the wrong machine. A wrapper or flow-wrapper follows the same model, with Held driven by the upstream product feed and Suspended driven by its own film splice or low film roll.
Overall Equipment Effectiveness multiplies availability, performance and quality. PackML feeds all three from a consistent source, which is the practical reason most sites adopt it.
Crucially, because Held and Suspended are distinct states, downtime analysis can separate losses a machine caused from losses imposed on it by a neighbour. On a multi-OEM line that distinction is what makes the OEE number trustworthy enough to act on. The limits of OEE as a single metric, and the ways it can mislead even when the data is clean, 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. A line controller can read the state and mode of every machine through the status PackTags and issue commands through the command tags, so the line starts, stops and recovers as a unit rather than as a collection of independent machines.
A practical pattern is line start and stop sequencing. On a clean start the line controller brings machines up from downstream to upstream, so the capper and labeller are running and ready before the filler reaches Execute, which avoids producing product with nowhere to go. On a fault, the controller can hold the upstream machines when a downstream machine aborts, preventing a pile-up of unprocessed product. Because every machine exposes Held as a defined state, the controller has a clean way to pause a neighbour without aborting it, and a clean way to resume once the condition clears. This is the kind of coordination logic that 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. |
| Single machine, no line, no OEE reporting | Low. A standalone machine gains little from a line integration standard. |
| Stable single-OEM line already integrated and reporting cleanly | Low to moderate. The benefit is mostly future-proofing for the next machine. |
The honest test is whether the line has multiple vendors, an OEE or reporting requirement, or a need for coordinated control. Where none of those apply, the full PackML interface usually adds more than it returns, and the decision should follow the plant's actual 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.
The practical reality on brownfield Australian packaging sites is that full PackML conformance across an existing line is a multi-year programme as machines are upgraded or replaced, not a single project. Starting with the most critical machine, typically the primary filler or the line bottleneck, and specifying PackML on all future purchases builds the standard into the line over time. This connects directly to automation upgrades and the staged migration 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.
PackML standardises the machine interface. It does not:
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, including depalletisers, rinsers, fillers, cappers, labellers, case packers and palletisers, and each can be a source of downtime. Attributing lost production to the correct machine is the difference between fixing the real bottleneck and chasing the wrong one.
For Australian sites the most practical lever is the purchase specification. Because equipment is replaced incrementally, naming ISA-TR88.00.02 conformance, with the required states, modes and PackTags, in every new machine specification builds the standard into the line at the lowest possible cost. The benefit accumulates: each new conformant machine drops into the existing OEE and line-coordination framework as configuration rather than custom development. This is closely related to the data-consistency problems we describe in plant data silos in Australian manufacturing, where inconsistent machine interfaces are a root cause of unreliable plant-wide reporting. Sites that also run upstream batch processes can pair PackML on the packaging line with ISA-88 batch control on the process side, using the same structured state-and-interface thinking across both halves of the plant.
PackML provides the common language that makes packaging line integration, line coordination and OEE reporting significantly more manageable on multi-OEM lines. Its value accumulates as more machines on the line become conformant, and the clean separation of Held from Suspended is what makes the resulting OEE data trustworthy enough to act on. For Australian FMCG, food and beverage, and dairy packaging sites building new lines or replacing ageing equipment, naming ISA-TR88.00.02 conformance in OEM specifications is one of the most practical steps toward consistent, reliable line data. 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.
PackML (Packaging Machine Language) is an automation standard developed by the OMAC Packaging Workgroup. It defines a common state model for packaging machines, a set of operating modes, and a standard tag interface called PackTags. It was published by the ISA as the technical report ISA-TR88.00.02, which places it within the ISA-88 family of batch and machine control standards. PackML gives machines from different OEMs a common language for reporting status to line control systems and production reporting platforms.
ISA-TR88.00.02 is the ISA technical report that documents PackML. It defines the PackML state model, the unit and machine modes, and the PackTags data structures. Because it sits under the ISA-88 (TR88) numbering, PackML is formally part of the same standards family that covers batch control, applied at the packaging machine level rather than the process batch level. The OMAC Packaging Workgroup maintains the underlying guidelines and the report standardises them.
PackML can be implemented on any modern PLC platform, including Rockwell Allen-Bradley, Siemens, Omron, Beckhoff and others. The standard defines the interface, not the implementation. Most major OEMs offer PackML-conformant templates, and Rockwell and Siemens both publish PackML implementation libraries that integrators use as a starting point. The state model and PackTags are the portable part; the underlying ladder, structured text or function block logic remains vendor-specific.
OEE depends on knowing when a machine was producing, when it was stopped, and why. PackML's state model gives every machine a consistent definition of producing time (the Execute state), planned and unplanned stops, and held conditions caused by upstream or downstream machines. Because the states and the produced, defective and rejected counters use the same PackTags on every machine, the OEE system can calculate availability, performance and quality without bespoke mapping per machine, and downtime can be attributed to the true root-cause machine rather than the one that happened to stop.
No. PackML and the broader ISA-88 batch models address different levels. ISA-88 defines how batch procedures and recipes are structured at the process level. PackML defines how an individual packaging machine reports state, mode and interface data at the machine level. They coexist, and on a plant that both makes and packs product they are often used together, with batch control upstream and PackML-coordinated machines downstream on the packaging line.
Sometimes, with effort. New machines can be specified to ship PackML-conformant. For existing machines the options are an OEM upgrade to the machine PLC program, an integration shim in the line controller or a gateway that maps existing signals to PackTags, or a full PLC rewrite during a major upgrade. The integration shim avoids OEM involvement but needs detailed knowledge of the existing machine logic. On most brownfield Australian sites full conformance across a line is a multi-year programme as equipment is replaced.
PLC logic, SCADA architecture, HMI standards, alarming and historian integration for manufacturing 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 availability, performance and quality are actually calculated, and why source-of-truth machine data matters.
A practical guide to ISA-88 batch control covering the procedural model, equipment mapping and traceability.
A practical ISA-88 batch control guide for Australian food and beverage manufacturers, covering when you need it, the physical, procedural and recipe models, phase states, FSANZ traceability, platform choice and brownfield migration.
Key point
ISA-88 gives batch control a consistent structure
Published 9 May 2026
CIP is one of the largest controllable cost centres in a food or beverage plant. This article covers the four areas where CIP automation investment pays back: cycle optimisation for trade waste and chemical cost, digital audit records, queueing for equipment availability, and coverage verification to prevent silent failures.
Key point
CIP is one of the largest controllable cost centres in a food plant
Published 9 May 2026
A practical Ignition SCADA guide for Australian food and beverage manufacturers, written from an integrator's delivery experience: when Ignition is and is not the right fit, Perspective vs Vision, architecture, CIP and batch, OT security, and buying and supporting Ignition in Australia.
Key point
Platform fit comes before platform capability
Published 9 May 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.