PLC code standards and PackML. Writing code that survives the next engineer.

Why packaging needed its own standard.

Have you ever opened the PLC code for an OEM packaging machine and discovered the state machine was nothing like the last one?

The packaging industry has a structural integration problem. A typical end-of-line on an Australian beverage plant might include a filler from one OEM, a labeller from a second, a case packer from a third, and a palletiser from a fourth. Each OEM ships with its own PLC platform, its own state model, its own HMI conventions, and its own tag database. Integrating them onto one line — with one operator, one OEE system, and one MES — was historically a custom project every time.

PackML exists to remove that custom work. The standard, started by OMAC in the early 2000s and harmonised into ANSI/ISA-TR88.00.02 by 2008 (current revision 2015), defines a common machine state model, a common set of operating modes, and a common tag structure (PackTags) so that a PackML-compliant machine looks and behaves the same way regardless of OEM or controls platform.

The 17-state model.

The PackML state model defines seventeen machine states that, between them, cover the full lifecycle of an operating machine. Every PackML-compliant machine moves between the same states using the same transitions.

The states.

Grouped by what they do rather than alphabetically:

• Idle states: STOPPED, IDLE, COMPLETE. Quiescent conditions where the machine is not actively producing.
• Transition states: RESETTING, STARTING, COMPLETING, STOPPING, CLEARING. Moving between idle and producing.
• Producing state: EXECUTE. The state in which the machine is actually making product.
• Pause states: HOLDING, HELD, UNHOLDING. Temporary cessation, typically operator-initiated.
• Internal-fault pause: SUSPENDING, SUSPENDED, UNSUSPENDING. Internally-triggered pauses, typically waiting for an upstream or downstream condition.
• Abort states: ABORTING, ABORTED. Fault conditions requiring intervention.

Why this matters operationally.

The same operator works across multiple machines on the same line. With seventeen well-defined states, the difference between a HELD machine and a SUSPENDED machine is the same on every machine on the line. The operator does not have to learn the wrapper's idiosyncratic "paused for change" mode versus the case packer's "stopped — operator" mode. The MES reads the same state tags from every machine and computes line-level OEE without per-machine adapters.

The same logic applies to the OEM. A machine builder writing to the PackML state model produces code that integrates anywhere, with any controls platform that the customer has standardised on. The cost is the discipline to follow the model, including transitions that are awkward for the specific machine. The benefit is one code base for every customer.

Operating modes.

States describe what the machine is doing. Modes describe how it is being operated. The PackML standard defines three primary modes and permits customer extensions.

AUTOMATIC.

The machine runs as part of an integrated line under MES coordination. Operator intervention is minimal; the machine takes commands from the line MES (production order, recipe, target rate) and reports back state and counts. This is the production-shift default for most modern packaging machines.

SEMI-AUTOMATIC.

The machine runs independently of line coordination, typically with operator-set parameters at the local HMI. Used for trials, qualification runs, or production where the line is not fully integrated.

MAINTENANCE / MANUAL.

The machine permits direct operator control of individual axes, valves, or modules. Used for setup, troubleshooting, and cleaning. Some implementations split this into a MAINTENANCE mode (engineer access) and a MANUAL mode (operator setup). The standard permits extension.

Customer extensions.

The standard explicitly permits customer-defined modes for site-specific needs: a SANITATION mode for food and beverage with elevated hygiene-zone interlocks, a CHANGEOVER mode that walks the operator through a tool change, a CIP mode tied to the plant CIP cycle. Extension is encouraged; ad hoc invention of modes outside the framework is discouraged.

PackTags — the integration story.

PackML defines three categories of standardised tags that the machine publishes upward to the MES or line controller.

Command tags.

Tags written downward by the MES to instruct the machine: machine command (state transitions), unit mode (mode changes), production parameters (target rate, batch size, recipe), and material identifiers. The MES asserts a command; the machine acknowledges by transitioning state or accepting the parameter.

Status tags.

Tags written upward by the machine to report state, mode, current production count, current rate, and the alarms currently active. The MES reads these tags continuously. OEE counters, line dashboards, and shift handover reports are all built on status-tag data.

Admin tags.

Configuration tags that change less often: machine ID, line position, machine type, parameter limits, alarm dictionaries. Admin tags are the ones that take care during initial commissioning and rarely need changing thereafter.

The benefit of standardised PackTags is that an MES integration team writes the same mapping once and applies it across every PackML-compliant machine on the line. A new machine arriving from a new OEM plugs into the existing MES integration. Without PackML, every new machine requires a tag-mapping project; with PackML, the project is hours rather than weeks.

PackML and ISA-88 together.

PackML and ISA-88 cover different territory and complement each other.

ISA-88 — batch and procedural composition.

The procedural model (recipe → unit procedure → operation → phase) and the physical model (site → area → cell → unit → equipment module → control module). The standard governs how recipes compose batches and how equipment is organised. Best suited to process plants with batch logic and recipe-driven products. (See the ISA-88 article for the deeper treatment.)

PackML — machine state and tag standardisation.

The state model and the PackTags. Governs how individual machines on a packaging line communicate state and accept commands. Best suited to discrete packaging machines that need to integrate with each other and with MES.

Together on a packaging-integrated plant.

The ISA-88 batch model handles the recipe and the procedural composition; the PackML machine model handles the state and integration of each individual machine running a unit procedure or operation. The two standards reference each other (ANSI/ISA-TR88.00.02 harmonises PackML with ISA-88 Part 5), and plants that adopt both at once tend to find the conversation easier than plants that adopt one at a time.

Writing to a published standard.

PackML is the right answer for packaging machines that need to integrate with a PackML-aware line. It is not the right answer for every project. On bespoke lines, on process plants, and on standalone machines, a project-specific programming-standards document does the same job.

The Pac Technologies position on programming standards is published on the programming service page: "We write code to be read — by the next engineer, by an auditor, by us in five years. Structured text where it belongs, ladder where it makes the line easier to maintain, and tag names that match the P&ID." The practical mechanism that turns this from a slogan into a discipline:

• A programming standards document, project-specific, signed off before code is written. Naming conventions, code structure, error-handling patterns, HMI design rules, alarm philosophy. Disagreements are resolved in the document, not in the code review.
• An equipment-module library specific to the project, version-controlled. The same library is used across the project; updates flow back to the library and forward to subsequent projects with the customer's approval.
• A state model adopted up front. PackML when the line warrants it. Project-specific simplified state model when it does not. Either is acceptable; no model is not.
• An HMI design standard. Colour conventions, alarm presentation, navigation hierarchy, operator-action confirmation patterns. Operator confusion at 2 a.m. is what an HMI standard prevents.
• A handover pack that an engineer who has never seen the project can use. Source code, build instructions, runbooks, login credentials, drawings, the standards document itself.

Code written to a published standard, against a documented library, with a handover pack that contains the build instructions, is code the customer can maintain after the integrator leaves. That is the entire point of the standards conversation. PackML is one way to get there for packaging machines. A custom programming standard is the other way, used everywhere else.

Common questions.

Sources and further reading.

Standards body and industry references for the PackML claims above. Retrieved 18 May 2026.

• OMAC. PackML. omac.org
• ISA. ANSI/ISA-TR88.00.02-2015 — Machine and Unit States: An Implementation Example of ISA-88. isa.org
• OPC Foundation. PackML Companion Specification. reference.opcfoundation.org

This article sits under Pac Technologies' programming service. For the batch-control standard PackML harmonises with, see the ISA-88 article. For the OEE layer that consumes PackML state changes, see the OEE & SCADA article.