The PackML state model is a standardized set of machine operating states, defined under the ISA-88 (also called ISA-TR88.00.02) framework, that gives every packaging and production machine the same vocabulary for what it is doing at any moment. Instead of one machine reporting "idle" while another reports "waiting" and a third reports "standby" for the same physical condition, PackML forces them all into an identical state map. That consistency is what turns messy, machine-specific status codes into clean, comparable downtime and OEE data across an entire line or plant. For any team chasing reliable overall equipment effectiveness numbers, this standardization is the quiet foundation everything else sits on.
OEE is only as trustworthy as the state data feeding it. Availability depends on knowing exactly when a machine was running versus stopped, and why. Performance depends on knowing the actual production time. When each machine vendor defines its own states, integrators end up hand-mapping dozens of proprietary status flags, and every mapping is a chance to misclassify a stop.
The classic failure looks like this: a filler counts a changeover as "downtime," while the capper next to it counts the same changeover as "not scheduled." Your line OEE now double-penalizes or under-penalizes the same event depending on which machine you believe. Root-cause work stalls because the numbers cannot be trusted, and a Pareto analysis of your top loss reasons becomes fiction. PackML removes that ambiguity by defining the states once, for every asset.
PackML defines a fixed set of states grouped by how they behave. The most useful way to think about them is in three buckets:
The power is in the transitions. Every machine follows the same state diagram, so "how did we get from Execute to Held" means the same thing on a labeler as it does on a palletizer. Downstream systems like SCADA and MES read one common tag structure instead of a custom map per machine.
States answer "what is the machine doing," and modes answer "under what regime." PackML defines at least three unit modes: Producing, Maintenance, and Manual. The same state (say, Execute) counts very differently depending on mode. Time in Execute under Producing mode is genuine production time. Time in Execute under Maintenance mode is a test cycle and must be excluded from OEE availability, or your numbers inflate.
This mode-plus-state pairing is what lets you separate planned proactive maintenance work from unplanned breakdowns automatically, feeding cleaner inputs into reliability metrics like MTBF and MTTR.
Consider a bottling line running an 8-hour shift (480 minutes). Planned breaks total 30 minutes, so scheduled time is 450 minutes. Before PackML, the line controller reported a single lumped "stopped" bucket of 90 minutes with no reliable reason split.
After standardizing on PackML states and modes, the same 90 minutes of non-production time resolves cleanly:
Run time in Execute under Producing mode is therefore 450 minus 60 minutes of real downtime (Held, Suspended, Stopped), which is 390 minutes. The 30-minute maintenance test no longer masquerades as either uptime or breakdown. Availability becomes 390 / 450, which is 86.7 percent. More importantly, the team can now see that 40 of the 60 lost minutes were caused by starvation and blockage, not the machine itself. That points directly at a flow constraint, a theory of constraints problem, rather than a maintenance one, and it stops the crew from tuning the wrong asset.
Because every machine speaks the same state language, aggregation becomes arithmetic instead of interpretation. A line-level view can sum time-in-state across all units and instantly show whether the line is starved, blocked, or genuinely down at its constraint. Reason codes attached to Stopped and Held states create a consistent taxonomy that a DMAIC improvement project can act on with confidence.
This is also where a well-run CMMS earns its keep: standardized states let a downtime event automatically raise a work order tagged with the correct asset, state, and reason, so nothing gets logged as a vague "machine problem." Clean state data plus disciplined work-order capture is what makes wrench time and maintenance backlog measurable rather than anecdotal.
PackML gives you the standardized state definitions; you still need a system that captures those states in real time and turns them into OEE, downtime reasons, and maintenance action. Fabrico is that real-time data foundation. It provides live OEE and production monitoring that reads standardized machine states and mode information, so availability, performance, and quality roll up consistently across every asset on the line.
For older or simpler equipment that has no PLC exposing PackML tags, Fabrico can apply computer vision on the machine to detect running versus stopped conditions, so those assets still contribute clean state data to the same plant-wide picture. When a stop is detected, Fabrico's field-ready CMMS handles the follow-through with work orders, asset records, preventive scheduling, and spare parts tracking. Fabrico is EU-built with EU data residency, which matters for teams that need their production and maintenance data to stay within Europe. You can explore both sides in the MES and OEE solution overview and the CMMS solution overview.
Not exactly. ISA-88 is the broader batch control standard, and PackML is an application of it, formalized in the ISA-TR88.00.02 technical report, that adapts the state model specifically for packaging and discrete machines. In everyday shop-floor language people use the terms together, but PackML is the concrete state and mode model most teams implement.
No, you can calculate OEE without it, but you will spend far more effort reconciling inconsistent machine states and defending your downtime categories. PackML makes availability and performance inputs unambiguous and comparable across assets, which is why it is strongly favored on multi-vendor lines. Without it, your reason-code taxonomy tends to drift machine by machine.
This is common. Legacy machines rarely expose PackML tags, so teams either retrofit the logic in the controller or use an external sensing method. Computer vision that detects running versus stopped states is one practical way to bring those assets into a single standardized state picture without rewiring the machine's original controls.
Ready to turn standardized machine states into OEE and downtime data you can actually trust? Book a Fabrico demo and see real-time state capture, OEE, and CMMS working together on your line.
Login
Blog