PackML and the ISA-TR88 Machine State Model Architecture

Walk a packaging line built by five different OEMs and you will meet five different definitions of the word “running.” One filler reports a bit called InProduction. The case packer next to it exposes Auto_Run. The palletizer three metres downstream calls the same condition MachineActive, and its idea of “stopped” quietly includes a paused-for-changeover state that the line’s OEE report counts as downtime. The PackML machine state model exists to end this. It gives every machine on the line one shared vocabulary of states, one set of commands to move between them, and one naming convention for the tags that carry the data. Standardize the state, and everything downstream — OEE math, MES integration, line coordination, and the telemetry a digital twin consumes — inherits that consistency for free.

This is not a new idea in 2026, but it is a newly urgent one. The pressure to compute plant-wide OEE, feed a unified namespace, and stand up digital twins has turned a “nice to have” interoperability standard into structural plumbing.

What this covers: the ISA-TR88 state machine and its exact states and commands, how operating modes overlay it, the three PackTags categories, and the reference architecture that turns all of it into standardized OEE, MES/SCADA integration, and clean digital-twin telemetry — plus the gotchas that bite real implementations.

Context and Background

PackML — Packaging Machine Language — is a guideline published by OMAC, the Organization for Machine Automation and Control, and adopted into the ISA technical report ISA-TR88.00.02. That numbering is deliberate: it plants PackML firmly in the ISA-88 (IEC 61512) batch-control family, borrowing the procedural-state thinking that governs batch reactors and repurposing it for discrete and continuous packaging machinery. Where ISA-88 gives you phases and procedures for a batch, PackML gives you a machine-level state engine that any PLC can run.

The standard is deliberately narrow in what it mandates and broad in what it enables. It specifies a state model, a set of operating modes, and a tag-naming dictionary called PackTags. It does not dictate your control hardware, your HMI vendor, or your network. In practice PackML lives on PLCs — Rockwell, Siemens, Beckhoff, B&R and others ship or support PackML implementations, often as reusable Add-On Instructions (AOIs), function blocks, or PLCopen-style libraries that drop the state engine into a project. The standard is championed jointly by machine builders who want a repeatable software template and by consumer-packaged-goods (CPG) end users — the Nestlés, P&Gs and Unilevers of the world — who buy machines from dozens of OEMs and refuse to integrate each one bespoke.

The alternative to PackML is the world described in the opening paragraph: every machine an integration project, every OEE dashboard a custom mapping exercise, every line-control handshake reinvented. Compare that with how ISA-95 and ISA-99 structure the enterprise-to-control stack — PackML is the missing bottom rung, the piece that makes the machine layer legible to everything ISA-95 sits above it. For the official source of the model itself, OMAC publishes the PackML Unit/Machine Implementation Guide, which remains the canonical reference for the state names and tag definitions discussed below.

The ISA-TR88 State Machine as Reference Architecture

At the core of PackML is a finite state machine that every conformant machine implements identically. The genius is not the individual states — it is that all machines share the same states, so a line controller, an MES, or a twin can reason about any machine without knowing its make. If a machine is in Execute, it is producing. If it is Held, an operator or upstream condition paused it deliberately. If it is Aborted, something went wrong hard. That semantic contract is the entire value proposition.

The state model divides into two kinds of states. Acting states are transient — the machine is doing something and will move on automatically when the action completes. Wait states are stable — the machine sits there until a command or condition moves it. Acting states are Starting, Execute, Completing, Suspending, Unsuspending, Holding, Unholding, Stopping, Aborting, Clearing, and Resetting. Wait states are Idle, Suspended, Held, Complete, Stopped, and Aborted. Execute is the one acting state that is also, in effect, a dwell: the machine stays in Execute producing product until told otherwise, which is why it behaves like the operational home base.

Figure 1: The PackML / ISA-TR88 state model rendered as a transition flowchart. Idle starts the machine into production through Starting and Execute; Hold, Stop and Abort provide progressively more forceful exits, and Reset returns the machine to Idle.

Figure 1 simplifies the full seventeen-state model to its backbone so it stays legible: the normal production path (Idle → Starting → Execute → Completing → Complete → Reset → Idle) plus the three exit ramps that matter most operationally. Holding and Held capture a controlled, recoverable pause; Stopping and Stopped a commanded halt; Aborting and Aborted an emergency-grade shutdown. The Suspending/Suspended pair (omitted from the figure for node budget) is the low-level cousin of Hold, driven by external material conditions rather than operator intent. Every real implementation carries all of them.

Commands drive transitions, conditions do not

The state machine is moved by a small, fixed command set: Start, Stop, Hold, Unhold, Suspend, Unsuspend, Reset, Abort, and Clear. These are the only levers. A command is a request to enter an acting state; the machine then transitions through the acting state to the next wait state on its own. Start moves Idle to Starting to Execute. Hold moves Execute to Holding to Held. Reset moves a terminal wait state (Complete, Stopped) back toward Idle via Resetting. Clear is special — it moves Aborted to Stopped through Clearing, the mandatory decontamination step after a hard fault before you are allowed to reset and restart.

The discipline here is that behaviour is command-driven and uniform. An MES that issues a Stop command knows exactly what will happen on a Bosch machine and a Krones machine alike, because the transition table is the standard. This is what makes the state model the backbone of consistent behaviour — not the states as labels, but the guaranteed transitions between them.

Hold, Suspend, Stop and Abort are not synonyms

The four “exit” mechanisms exist because they mean genuinely different things, and conflating them is the single most common source of bad OEE data. Hold is a deliberate, operator- or logic-initiated pause you expect to recover from — a planned changeover, a manual intervention. Suspend is an automatic pause triggered by an external process condition, classically starvation (no infeed) or blockage (downstream full); the machine suspends itself and un-suspends when the condition clears, with no operator action. Stop is a commanded, orderly halt to a defined stopped state. Abort is the fault-driven emergency path — a guard door open, an E-stop, a critical servo fault — that bypasses orderly completion and demands a Clear before recovery.

Getting these right matters because availability loss from a Suspend (line-induced, arguably not this machine’s fault) is a categorically different downtime reason than a Hold (planned) or an Abort (a genuine fault). A machine that dumps all four into a single “not running” bit throws away the exact information OEE and root-cause analysis need most.

Why one shared engine beats seventeen good ones

A machine builder could design an excellent bespoke state model. The problem is that excellence does not compose. Two excellent-but-different models on the same line still require a translation layer between them, and that layer is where integration cost and bugs accumulate. PackML’s value is that it is the same everywhere — mediocre uniformity beats brilliant divergence the moment you have more than one machine and anything that needs to read across them. The state model is an interoperability contract first and a control-engineering artifact second.

PackTags, Modes, and the Integration Data Model

The state machine defines behaviour; PackTags define the data interface that exposes and controls it. PackTags is a standardized dictionary of tag names, structures, and data types, organized into three categories by direction and purpose. Get the tag structure right and a machine becomes genuinely plug-and-play: an MES or SCADA system that already speaks PackTags can connect a new machine by binding to known names, not by reverse-engineering a vendor’s private tag database.

A 40-word answer for the impatient: PackTags are PackML’s standardized tag set in three groups — Command (control written to the machine), Status (state and live data read from the machine), and Administration (accumulated counters, downtime reasons, alarms, and OEE inputs). They turn a proprietary machine into a machine that any compliant system can read and drive.

Figure 2: PackTags data flow. Command tags carry control intent from the MES and HMI into the machine’s state machine; Status tags stream live state and production data back; Admin tags accumulate counters, downtime reasons, and alarms that feed OEE.

The three PackTags categories

Command tags flow into the machine — from an HMI, a line controller, or an MES. They carry the command set (the same Start/Stop/Hold family that drives the state machine), the mode selection, parameter set-points, and material or product-change data. Command.CntrlCmd carries the numeric command, Command.CmdChangeRequest handles the handshake, Command.UnitMode selects the operating mode. Because the write interface is standardized, a line-coordination controller can sequence a dozen machines from different OEMs with identical logic.

Status tags flow out of the machine and represent its live condition: the current state (Status.StateCurrent), the current mode, the current machine speed, the current product, and equipment-interface signals for material handshakes. Status is how the world knows a machine is in Execute versus Held, and at what rate. It is real-time, non-accumulating — a snapshot, refreshed every scan.

Administration tags are the accumulators and the analytical goldmine. Admin carries counters (produced, defective, consumed), the stop-reason and alarm history with codes and timestamps, accumulated time-in-state, and the raw material for OEE. Admin.ProdConsumedCount, Admin.ProdProcessedCount, Admin.StopReason, and Admin.PackMLStat (accumulated state times) are where availability, performance, and quality ultimately come from. Where Status tells you now, Admin tells you the shift.

The state-time model deserves emphasis. PackML accumulates elapsed time per state in an indexed structure — conceptually a timer per state in the model — so time-in-Execute, time-in-Held, and time-in-Suspended are first-class, queryable quantities rather than something a downstream system reconstructs by watching StateCurrent transitions. Cumulative-since-reset semantics mean an OEE engine can sample at any cadence and still compute exact interval deltas. That is precisely what makes low-frequency polling and store-and-forward over MQTT viable without losing availability accuracy — a subtle but decisive property when the machine sits behind an intermittent edge link.

The naming convention is the interoperability

PackTags names follow a structured, dotted convention — category, then a descriptive path, e.g. Status.CurMachSpeed or Admin.StopReason[n].ID. The convention is not decoration; it is the plug-and-play mechanism. When every machine calls its accumulated defective count the same thing, a quality system binds once and works across the fleet. The naming convention effectively publishes a machine’s data contract in advance, so integration becomes configuration rather than development. This is precisely the property that makes downstream automation — OEE engines, MES connectors, twin ingest — writeable once and reusable everywhere.

Modes overlay the state model, they do not replace it

PackML defines standard operating modes — Production, Maintenance, and Manual — and allows user-defined modes on top. A mode is orthogonal to the state machine: the same states and commands exist within every mode, but their meaning and permissions differ. In Production mode, Execute means producing sellable product and the counters count. In Maintenance mode, a technician can step a machine through the same states for testing without polluting production counters or OEE. In Manual mode, individual actuators can be jogged, typically outside the normal automatic sequencing.

The two-axis design — mode on one axis, state on the other — is what keeps the model both rigorous and flexible. You get a fixed, analyzable state machine and a controlled way to express “the same machine, different intent.” User-defined modes (a validation mode for a pharma line, a dry-cycle mode for commissioning) extend the vocabulary without breaking the core. The rule that keeps it clean: modes change what a state means and who may command it, never which states exist or how they connect.

From State Model to OEE, MES, and the Digital Twin

The architectural payoff of PackML is that a single, standardized data model feeds three of the most valuable systems in a modern plant — OEE analytics, MES/ERP vertical integration, and the digital twin — without a bespoke adapter for each machine. This section walks the data path from a machine’s state engine up through the enterprise and across into a twin.

Standardized OEE falls out of the model almost for free

Overall Equipment Effectiveness is the product of three factors — Availability, Performance, and Quality — and each maps directly onto PackML data. Availability comes from time-in-state: Execute time versus the down states (Held, Suspended, Stopped, Aborted), read straight from Admin.PackMLStat accumulated state timers. Performance comes from actual throughput (Admin.ProdProcessedCount over time) against the machine’s rated or ideal speed exposed in Status. Quality comes from good versus defective counts in the Admin counters. Because these tags mean the same thing on every machine, the OEE calculation is written once and applied fleet-wide.

A worked example makes the leverage concrete (numbers illustrative, not measured). Take a filler on a 480-minute shift with 30 minutes of planned changeover logged as Held, 20 minutes of Suspend from an upstream jam, and 10 minutes of Aborted fault recovery. Availability is Execute time over planned production time — 420 of 480 minutes, or 87.5% — and because Held, Suspended, and Aborted arrive as distinct state timers, the 60 minutes of loss is already split into planned, line-induced, and fault buckets with no extra instrumentation. Say the machine produced 210,000 units against a rated 550 units per minute over those 420 minutes (231,000 ideal): Performance is 90.9%. With 208,000 good units against 210,000 produced, Quality is 99.0%. Multiply the three and OEE is 78.7%. Every input came from standardized state timers and Admin counters, so the identical formula runs on the case packer and palletizer beside it — and the loss attribution is comparable across all three because the state semantics are shared.

Figure 3: Machine-to-MES/OEE reference integration. Machine state and Admin PackTags flow through an edge gateway to a process historian and the ISA-95 MES layer; the OEE engine consumes both to drive a line dashboard, while the MES exchanges schedule and order data with ERP.

Figure 3 shows why this matters at line scale. The edge gateway subscribes to the same PackTags on every machine, timestamps and buffers them, and forwards state-time and counter data to a historian and to the MES. The OEE engine does not need to know that machine 3 is a Sidel and machine 7 is a GEA; it reads standardized Availability inputs (state times), Performance inputs (counts and speeds), and Quality inputs (good/defect counts) with one schema. The single most valuable consequence is that stop-reason codes — carried in Admin.StopReason — attach downtime to a cause automatically, so the OEE dashboard shows not just that availability dropped but why, in a taxonomy that is consistent across the whole line.

MES and SCADA integration is ISA-95 vertical integration made concrete

PackTags are the physical realization of the level-2-to-level-3 boundary in the ISA-95 model. The MES issues production orders and product changeovers as Command tags, receives live state and counts as Status tags, and pulls accumulated performance and genealogy inputs from Admin tags. Because the interface is standardized, the MES connector is built against PackTags once, not against each machine. This is the same layering discussed in our digital-twin-driven MES reference architecture — PackML supplies the clean, semantically consistent machine feed that a well-designed MES assumes but that unstandardized machines rarely provide.

The integration is bidirectional and disciplined. Downward, the MES writes recipe parameters and mode selection through Command tags with a change-request handshake so parameters land atomically. Upward, the MES reads production genealogy — what was made, how much, how many rejects, and against which order — from Status and Admin. The handshake convention (Command.CmdChangeRequest acknowledged by the machine) prevents the classic race where a set-point is read mid-update. That reliability is why line-level coordination across multi-OEM machines becomes tractable at all.

Line coordination and faster commissioning

Because all machines expose the same commands and states, a line controller can sequence start-up, coordinate holds during upstream blockage, and orchestrate graceful shutdown using identical logic per machine. Suspend semantics are the workhorse here: when a downstream machine backs up, upstream machines suspend on the standard condition and un-suspend when flow resumes, all without custom interlock code per pairing. PackML also standardizes an equipment-interface layer — a defined set of tags for the material handshake between adjacent machines (product available, ready to receive, blocked). Because that handshake is standardized alongside the state model, the classic starve-and-block interlock between an upstream and downstream machine can be wired generically rather than as a bespoke pair-by-pair mapping, which is exactly where a large share of legacy line-integration hours historically disappeared. Commissioning benefits just as directly — an integrator who has wired one PackML machine has effectively wired them all, because the tag contract and state behaviour are known before the machine arrives. Time-to-integration collapses from a per-machine project to a per-machine configuration.

Clean telemetry is what a digital twin actually needs

A digital twin is only as trustworthy as its input semantics. Feed a twin seventeen different “running” bits and it models noise. Feed it PackML state and PackTags and it inherits a ready-made ontology: states map to twin state properties, commands map to twin methods/commands, Admin counters map to twin telemetry and cumulative properties, and stop reasons map to twin events. The mapping is close to one-to-one, which is rare and enormously valuable. The digital twin stops being an integration project and becomes a subscription to an already-structured stream. Concretely, in a DTDL-style twin the PackML StateCurrent becomes a Property, CurMachSpeed a Telemetry stream, the Admin counters cumulative Properties, and each StopReason entry a Telemetry event carrying a code and timestamp — a mapping shallow enough to generate from the tag table rather than hand-author per machine. That auto-generation is the difference between a twin you maintain and a twin that maintains itself as machines are added.

Figure 4: Digital-twin and unified-namespace mapping. PackML state and PackTags are semantically mapped onto an OPC UA information model and MQTT Sparkplug payloads, published to a UNS broker, and consumed by a digital twin that drives predictive analytics and line simulation.

Figure 4 shows the two dominant transport paths in 2026. On the OPC UA side, PackML maps naturally onto an information model — indeed OMAC and the OPC Foundation have pursued a PackML/OPC UA companion-style alignment so that states and PackTags surface as browsable, typed nodes with semantic identity rather than opaque registers. On the MQTT Sparkplug side, PackTags map onto Sparkplug metric names published from an edge node into a unified namespace (UNS), where the machine’s state and counters become discoverable topics any subscriber can consume. Either way, the twin, the analytics engine, and a line simulation all read the same semantically consistent stream. The state model is the schema; the UNS or OPC UA server is the delivery. This is the cleanest on-ramp to a twin that industrial data offers, and it is why PackML keeps showing up in modular-automation conversations alongside the Module Type Package approach to modular process automation, which pursues the same “standardize the interface, compose freely” philosophy one layer up.

Trade-offs, Gotchas, and What Goes Wrong

PackML standardizes structure, not the semantics of every value, and most real-world pain lives in that gap. The single biggest disappointment teams hit is discovering that “PackML compliant” is a spectrum, not a checkbox.

Partial and inconsistent vendor implementations. Many machines implement the state model but expose only a subset of PackTags, or implement the tags with vendor-specific quirks in structure, array sizing, or data types. A machine may claim PackML conformance yet omit the very Admin tags your OEE engine needs, or populate StopReason with a private code list. Always audit the actual tag table against the standard before assuming plug-and-play; budget for a per-vendor conformance check.

State-model misuse. The most damaging anti-pattern is collapsing distinct exits — using Stop where Hold or Suspend is correct, or never using Suspend at all so that starvation downtime is miscategorized. Another is treating Execute as a catch-all and stuffing sub-states into custom bits instead of using modes. Misuse does not break the machine; it silently corrupts every downstream analytic that trusts the state, which is worse because it looks fine.

Mapping legacy machines. Older equipment with no PackML support needs a wrapper — a translation layer in the PLC or edge gateway that infers PackML states from legacy signals. This is doable but lossy: inferred states are only as good as the source signals, and the Admin counters often have to be reconstructed. A wrapper buys interoperability at the cost of fidelity, and that trade should be explicit.

Mode/state edge cases. Transitions during a mode change, behaviour of counters across a Production-to-Maintenance switch, and recovery paths after Abort in a non-Production mode are all under-specified in practice and vary by implementation. These edges are exactly where line-coordination logic and OEE both get surprised, so test them deliberately.

PackTags bloat and semantic gaps. Exposing every possible tag creates a wide, noisy interface that is expensive to poll and hard to maintain; expose what integration actually needs. And remember the load-bearing caveat: PackML gives you a standard slot for a stop reason, but two plants — or two machines — can still put incompatible meanings in that slot. Reason-code and product-code taxonomies must be governed as a separate data-standardization effort. PackML is necessary for clean telemetry; it is not sufficient.

Practical Recommendations

Treat PackML as a procurement and data-governance decision, not just a controls choice. The machines you buy determine the data you get, so the leverage is at the specification stage.

Start by writing PackML conformance into your machine specifications explicitly — name the required states, the required PackTags (especially the Admin set that feeds OEE), the transport (OPC UA and/or Sparkplug), and a factory acceptance test that verifies the tag table against ISA-TR88.00.02. Do not accept “PackML compliant” without an enumerated tag list. Second, standardize your stop-reason and product-code taxonomies centrally and require machines to use them, because the standard will not do this for you. Third, build the OEE and MES connectors once against the standard PackTags and reuse them; resist per-machine forks. Fourth, decide the transport-to-UNS mapping early so state and tags land in your unified namespace with stable, governed topic names. Finally, for legacy machines, budget a wrapper and be honest in the OEE report about which numbers are inferred versus measured.

A short checklist to operationalize this:

Spec: require ISA-TR88 state model + enumerated PackTags (Command/Status/Admin) in every RFQ.
Verify: FAT tests each state transition and reads back every required Admin counter.
Govern: central stop-reason and product-code dictionaries, enforced across OEMs.
Integrate once: one PackTags-based OEE/MES connector, reused fleet-wide.
Map deliberately: fixed OPC UA information model and/or Sparkplug topic namespace into the UNS.
Wrap honestly: legacy machines get an inference layer, and inferred metrics are labelled as such.

Done well, the state model becomes the quiet foundation that makes plant-wide OEE truthful, MES integration repeatable, and a digital twin something you subscribe to rather than build from scratch.

Frequently Asked Questions

What is the PackML machine state model in one sentence?

It is a standardized finite state machine — adopted as ISA-TR88.00.02 from OMAC — that defines a common set of machine states (like Idle, Execute, Held, Stopped, Aborted) and the commands that transition between them, so that every packaging or discrete machine on a line behaves and reports consistently regardless of who built it. That shared behaviour is what lets OEE engines, MES systems, and digital twins read across a multi-vendor line with a single data contract instead of a bespoke integration per machine.

How many states does the ISA-TR88 state model have?

Seventeen. There are eleven acting (transient) states — Starting, Execute, Completing, Suspending, Unsuspending, Holding, Unholding, Stopping, Aborting, Clearing, Resetting — and six wait (stable) states — Idle, Suspended, Held, Complete, Stopped, Aborted. Acting states complete automatically and move the machine on; wait states hold until a command or condition acts. The full set is moved by a fixed command set: Start, Stop, Hold, Unhold, Suspend, Unsuspend, Reset, Abort, and Clear.

What are PackTags and what are the three categories?

PackTags are PackML’s standardized tag dictionary — a fixed naming convention and structure for the data that crosses a machine boundary. There are three categories: Command tags (control written into the machine, including the command set, mode, and parameters), Status tags (live read-out of current state, mode, speed, and product), and Administration (Admin) tags (accumulated counters, stop reasons, alarms, and the inputs to OEE). The standard names make integration a binding exercise rather than a reverse-engineering one.

How does PackML relate to ISA-88 and ISA-95?

PackML descends from ISA-88 (IEC 61512), the batch-control standard, borrowing its procedural-state thinking — hence the ISA-TR88 numbering. It sits below ISA-95: PackTags are the concrete, standardized interface at the level-2-to-level-3 boundary, carrying commands down from and status/genealogy up to the MES. In short, ISA-88 is the intellectual parent, and ISA-95 is the enterprise framework whose machine-layer interface PackML makes real and repeatable.

Does PackML give me OEE automatically?

Almost. OEE’s three factors map directly onto PackML data — Availability from accumulated time-in-state, Performance from throughput counts against rated speed, and Quality from good-versus-defect counters, all in standardized Admin tags. Because those tags mean the same thing on every conformant machine, you write the OEE calculation once and apply it fleet-wide. The one thing PackML will not standardize for you is the meaning of stop-reason and product codes, so you still have to govern those taxonomies centrally for the numbers to be comparable across machines.

How does PackML feed a digital twin or unified namespace?

The mapping is nearly one-to-one: PackML states become twin state properties, commands become twin methods, Admin counters become twin telemetry, and stop reasons become twin events. Transport is typically OPC UA — where PackML surfaces as a browsable, typed information model — or MQTT Sparkplug, where PackTags become metric names published from an edge node into a unified namespace. Either way the twin subscribes to an already-structured, semantically consistent stream instead of being built from raw, ambiguous registers.

PackML and the ISA-TR88 Machine State Model Architecture (2026)