PackML (Packaging Machine Language) is an industrial technical standard intended to make the control of packaging machines and packaging lines—in fact, any discrete machine process built using the language—easier to understand and program. PackML’s main goals are to let one machine communicate with another about its status to provide a coordinated flow of product on the line and bring to the user a common look and feel and operational consistency to machines that make up a packaging line.

The word “consistency” is key for another reason, says Mark Lewis, special projects team manager, Beckhoff Automation LLC. “PackML is a predefined strategy for software consistency. There are as many ways to program a machine as there are controls engineers. And engineers often neglect to provide documentation or even comment their code, which leaves people in the dark when adding machine modules to a line, troubleshooting or performing maintenance. Using PackML as the orchestration layer avoids that confusion.”

Think of it like building a house, says Lewis. You have specific building codes for framing—what size lumber you have to use, where, how far apart it’s placed, etc. That ensures the house is structurally sound, but it also means the teams doing finish work can install drywall, lighting, cabinets or anything else without having to first do an analysis of how it was framed. They know the studs are all “16 inches on center.”

In the same way, you always need mode and state control in the machine controller, adds Lewis. PackML provides that standard, but the benefit is that it’s tested, documented and accepted—not just in packaging but across many, many industries. At the end of the day, any standard, even an imperfect standard, allows operators and engineers to become familiar with how to deal with the machine on a level playing field.

To demonstrate a consistent look and feel in operation, one early PackML demonstration showed four packaging machines running in a line, each with a different brand programmable controller (PLC) and user interface (HMI). The HMI on each machine had a similar look and set of controls, but not only that, an operator from any machine in the line could call up the HMI/controls belonging to another machine, thus making it easier to make a change on a single machine without having to be physically present at that machine’s controls.

With the data about machine and line status passed on through PackML, key performance indicators are also available—such as OEE, uptime and downtime, etc. Data can also be passed along to maintenance so repairs can be scheduled rather than putting out fires.

Packaging machines grouped together
With many packaging lines set up to run concurrently, PackML makes it easy to access any particular line as a single machine or to check in on any one particular machine within that line.
Image courtesy of Imagemakers Inc.


Early History

The Organization for Machine Automation and Control (OMAC) was created in 1994 to provide machine builders a framework to standardize the communication between machines and improve manufacturing performance. By 2017 OMAC’s Packaging Workgroup began a period of dynamic evolution. Manufacturers such as Procter & Gamble, Nestlé, Arla Foods and Boeing drove the effort for wider international acceptance.

When the ISA88 batch specification was first developed, it did not include discrete automation and packaging equipment. Back in 2006, ISA’s SP88 committee established Part 5 of its batch standards to encompass manufacturing machinery, especially packaging machine standards. The Part 5 standard was to be called the “Modular Concepts for Automated Control Systems” and would define methods for developing a library of automation control components that could be supported by automation vendors for all types of manufacturing.

Dave Chappell of Procter & Gamble was appointed to serve as the Part 5 Working Group chair. “Our goal is to provide standard terminology, command and control functionality, a way to describe and identify each modular component, a method for exchanging component definitions and a method for intercommunications between components,” says Chappell.

By the end of 2015 the ISA 88 committee approved the document, ANSI/ISA-TR88.00.02-2015 Machine and Unit States: An implementation example of ANSI/ISA-88.00.01. Known as TR88 or PackML, it was developed by the OMAC Packaging Workgroup and specifies unit state models and operation modes for machine control and packaging line implementation. PackML also defines a set of data tags called “PackTags,” which serve to standardize internal machine automation and communication with other machines or systems. 

PackTags for machine communication
PackTags make it possible for packaging machines supporting PackML to communicate with one another and with databases, historians and MES applications. OPC UA now supports the PackML specification through its own freely available OPC 30050: PackML - Packaging Control specification.
Image courtesy of OMAC

In 2022, this document was further updated to clarify and improve the usability of the specification based on field feedback and usage reports. Major changes include a revised state model diagram, the removal of the “Remote” interface, the addition of PackTags that describe the machine configuration to a supervisory system, new examples for mode definitions and several other updates to the existing PackTag structures for functional improvement and clarity.

Finally, PackML was released in three versions with several implementations of version 2 in existence. The PackML version 2 implementation had the disadvantage of being memory intensive for PLC processors, containing unnecessary unused code as well as having an incomplete state/mode model for some machines. PackML version 3 corrected those disadvantages. It was superseded when it was harmonized with the S88 Part 5 efforts to become ISA-TR88.00.02.

Today, not only do PackTags serve to connect individual machine subassemblies together and machine-to-machine communications through OPC-UA, they also bring important information to the operator through an HMI, which can be used to troubleshoot a single machine, or if set up properly, an entire line.


PackML, the Conductor of a Machine or Several Machines in a Line

Keep in mind that PackML is the orchestration layer—the overarching machine architecture, says Beckhoff’s Lewis. It’s important to remember that many machine plug-and-play considerations actually fall into the machine layer, like fieldbus selection, a vendor’s system openness or controller capabilities.

“PackML doesn’t drive cylinders, valves or motors, and it doesn’t care what kind of temperature controller, heater bar or counter you use,” says Lewis. “Those things are either on or off, moving or not moving. PackML looks at the whole section, really without regard for what the components doing the physical job actually are. The [PackML] standard handles the sequencing, timing, enabling and disabling. It answers how to solve common errors. And since there’s now one pragma, OPC UA, to expose all the PackML tags, you have more flexibility in how you build your HMI and connect to different cells. All of that makes engineering go faster.”

“By removing the hardware from the software, we can now simulate the hardware that’s missing, just by talking through the existing interfaces,” adds Lewis. "Using our EtherCAT library and software like MATLAB/Simulink, we can create a sort of digital twin for machines and production lines. That simplifies implementation as well.”

But, with PackML, can you add a new machine in a line—like plugging in a USB stick—and expect it to work? Wouldn’t that simplify configurations?

“If you add a new PackML-based machine module in a line and all the machines upstream and downstream use PackML, then all the tags should work,” says Lewis. “So yes, that simplifies things. But also, no: The standard is not necessarily meant to create that level of interoperability. It’s achievable, but that’s not really PackML’s job.”


Why use PackML?

PackML is an industry standard, applicable to all types of converting and packaging machines, that provides benefits for end users:

  • More robust and reliable software
  • Easier to troubleshoot, reduced mean-time-to-repair
  • Faster startups
  • Operational consistency
  • Reusable training
  • Consistent tools to track and manage machine performance
  • Effective use of limited engineering resources
  • Reduced costs

Benefits for OEMs include:

  • Faster development time
  • Greater reapplication of software from machine to machine
  • Shorter debug times and more robust programming
  • Control platform independence
  • Fewer end-user custom software requests
  • Less training for both the OEM and end users
  • Allows for greater focus on innovation and machine capability
  • Still allows intellectual property to be maintained 
  • Great customer selling point! 

     Source: OMAC


Flexibility of PackML: Good or Bad?

It’s important to note that while there are standard defined PackTags, machine builders and system integrators or engineering houses often fine-tune tags to meet the needs of a particular machine, plant or project in general. So, while the basic standardization is a boon to setting up a communicative system, however, the ability to make adjustments can reverse the intended purpose of PackML, especially if there is poor or no documentation.

PackML is flexible, says Kyle VanDruten, E Tech Group software engineer in a 2021 paper.1 “You can make it as simple or as complex as you want it to be. A simple example would be when you’re implementing PackML and you disable states. Let’s say you want basic start/stop functionality. You can make it so that the only states you’re concerned with are Idle, Stop, Abort, Execute. When we disable a state, it takes it off the display.”

VanDruten went on to show a more complex situation: a robot cell that performs multiple functions with multiple robots. “You’re focused on multiple aspects: safety air valves, safety integration, general machine state, multiple machine states. We have a robot that works on different machines to confirm what they’re doing. We then start up different pieces of individual equipment in different sequences. You can implement different sequences in different states.”

According to Technical Sales Engineer David Cohen, Allpax Products LLC has been using PackML for more than 10 years. The supplier offers best-in-class retort room automation equipment, including retorts, loaders, unloaders, shuttle cars, laners, conveyors, pressureless combiners and more. These systems utilize PLC controllers, vision systems, servo drives, VFDs, HMIs and more.

ConfecPRO modular confectionery machine
Winkler und Dünnebier Süßwarenmaschinen’s (WDS) ConfecPRO modular confectionery machine with PackML communications fills up to 25 molds for chocolate and other products, handles an hourly output of up to three tons and features Bosch Rexroth drives and motion control. The many connectivity options of Rexroth’s control system ctrlX CORE as an edge device range from vertical interfaces in accordance with the Weihenstephan Standards (WS) or PackML (Packaging Machine Language) to direct data access via ERP and MES systems and horizontal communication on the basis of OPC UA and WS Sweets, the new library in the Weihenstephan Standards.
Image courtesy of WDS

“PackML is an industrial machine language standard that defines a specific manner in which automated machines communicate and report their current states,” says Cohen. “PackML has made it more consistent across manufacturers to organize machine communications and equipment statuses. While it is easy to customize, sometimes this means the communication tags used are no longer specific to the data being communicated, which reduces readability. The other problem we find with PackML is while there is a standard, every plant has their own tweaks, which requires adjustments specific to the customer.”

In spite of issues caused by “novel programming,” Lewis says that PackML significantly streamlines planning and implementation of equipment. Most of that is technical. But another major piece is how it affects finding and training new talent.

“Engineers aren’t interchangeable commodities,” says Lewis. “You can’t grab a few off the street, throw them at a problem and expect they’ll be instantly effective. That’s really the biggest benefit of leveraging the TR88 standard: It shortens your engineers’ time to effectiveness.”

“But if all your machines’ code is written the same way, and you can troubleshoot them the same way, now your engineer can work on anything on your plant floor, right? They might not know the exact machine, but they’ll know exactly where to look for the problem based on how you troubleshoot PackML,” adds Lewis.


PackML States

PackML allows a machine to transition from one state to another. There are two types of states: “Acting” and “Wait.” Acting states define when the machine is processing an activity and require a transition command to move to the next state. Wait states indicate that the machine has achieved a defined set or condition, which are typically determined by the end user. Wait states require a specific command to move to the next state.

PackML defines 17 states common to all machines, and they describe what the machine is doing at any given time. These states include: Stopped (wait), Starting (acting), Idle (wait), Suspending (acting), Suspended (wait), Unsuspending (acting), Execute (acting), Stopping (acting), Aborting (acting), Aborted (wait), Holding (acting), Held (wait), Unholding (acting), Completing (acting), Complete (wait), Resetting (acting) and Clearing (acting).”

17 PackML machine states
PackML defines 17 states common to all machines. States must be aligned as demonstrated here. Only the active state (e.g., Execute) should be highlighted. Unavailable states (i.e., those not supported by the current mode) will be visible but displayed with a “greyed-out” effect. The new features of the 2021 state-model should be displayed, including: (a) boundary box on the Execute-Suspended group transitioning to Holding, (b) bounding box around the Held-Execute-Suspended group transitioning to Completing, (c) a state named Completed replacing Complete, and (d) a grouped transition to Execute.
Image courtesy of OMAC

A machine mode is a set of allowed states for a given process, such as production, cleaning, calibration, bypass, etc. For example, in the production mode, all actuators and processes are used to make products or perform operations. Calibration doesn’t move products through, but tests the operation of the machine so an operator or technician can make measurements. Maintenance doesn’t produce product, but may allow the machine to broken down for easy access to make repairs. Bypass mode moves products through a machine without operating on the machine. [2]

Transitions between states can be programmed to be fast or slow as needed, according to VanDruten. Delays can be implemented in certain phases, and motion is important when changing states. When slowing the machine down, all components need to be stopped in a completing state—not just stopping right away as products need to clear the machine.


PackML Eases Frozen Meal Manufacturing Integration

Spiroflow Automation recently undertook the task of supervisory control on a frozen meal production line based in the U.S. The challenge? A mix of legacy equipment with newer additions—with the goal of fostering effective communication and supply control over the entire line.

Approximately half of the pre-existing equipment was retained while introducing new modules to optimize the manufacturing process. The transformative step was integrating the PackML communication standard across all equipment PLC (programmable logic controllers) processors.

The outcomes of the integration project led to significant tangible benefits. First, the new system architecture streamlined communication, cutting the number of discrete networks in half, from four to two. This reduction was more than just a simplification; it translated into a substantial $70,000-plus savings in networking hardware costs for the client.

Additionally, Spiroflow’s collaboration with equipment suppliers ensured that the PackML layer was seamlessly integrated into their PLC programs. This holistic approach culminated in an almost vertical control system commissioning.

What benefits were derived from the project?

Rapid changeovers with SMED (single-minute exchange of die): Before the PackML integration the changeover time stood at an average of 1.5 hours. Post-integration, this was slashed to 0.5 hours or even less.

Instant equipment diagnosis: The central status board allowed for instantaneous equipment problem diagnostics, to minimize downtime.

Real-time insights with OEE dashboards: With the real-time operating equipment efficiency dashboard, monitoring and optimizing equipment performance became straightforward.

Prepared for the future – MES (manufacturing execution systems) ready: Spiroflow ensured that both data and code were primed for synchronization between various management systems, encompassing recipe management, inventory management, equipment utilization and a process data historian.

The results Spiroflow Automation achieved for this frozen meal manufacturing line exemplify its commitment to innovative solutions that deliver real-world benefits. Leveraging industry standards such as PackML enables machine builders like Spiroflow to enhance operational efficiencies, while also driving cost savings and preparing manufacturing units for future growth and integration.


Making Implementation Easier: OPC-UA and PackML

As one integrator suggested some years ago, it would be nice if PackML would act like a USB—the “glue” that helps connect different manufacturers’ brand equipment together. While PackML is a set of common protocols that live in PLC platforms, unless there’s a standard method to transmit that PackML data between PLCs and PLCs, HMIs and manufacturing execution systems, that data does no one any good when locked up in PLC memories.

Enter OPC UA and Ethernet, which most PLC manufacturers have signed onto. OPC UA has its roots in the OLE model from Windows, which let applications and computers talk to one another. Today, the OPC Foundation has extended its reach to PackML, and OPC UA is free to use without licensing fees—so major PLC vendors such as Rockwell, Siemens and Omron (to name a few) provide OPC UA functionality with their PLCs. Voila! No longer is PackML data locked away in a machine.

OPC UA provides secure communications between machines and devices such that all equipment is authenticated and that users of PackTags are authorized (i.e., valid permission to access those tags). OPC UA provides the common encoding so PackML tags can be properly encoded and decoded. Thus, OPC UA provides the foundation for simplifying the integration of a PackML machine with other machines, controllers, HMIs, enterprise systems and cloud services. OPC UA is secure, open and reliable for moving data between enterprise systems and controls, monitoring devices and sensors. No more proprietary machines, state machines, proprietary binary tags, unique security systems and networking systems using a mix of protocols.

While we now have a good communications medium, there is still the issue with the way engineers implement PackML—as we already said. “While the standard can provide some conformity, every piece of equipment is different, and each plant has its own standards in implementing PackML,” says Allpax’s Cohen. “PackML is a good guideline to follow, but I do not believe it is a one shoe fits all like USB.”

Minebea Intec’s Blue HMI
Minebea Intec’s “Blue HMI” user interface for checkweighers can be expanded to include the OPC UA PackML specification 30050 (Companion Specification PackML according to OMAC).
Image courtesy of Minebea Intec


PackML’s Future

There’s no question that machines supporting PackML have won favor with machine builders and end users. “Customers can now open any piece of equipment and understand machine statuses, faults and communication without having to decode each manufacturers logic design,” says Cohen. “Disparate brand machines can and do work together well with this standard.”

It’s likely that AI will factor into PackML’s future—but not necessarily directly. “Remember, the ML in PackML stands for Packaging Machine Language, not machine learning,” says Lewis. “So, we don’t see any compelling use cases that intertwine PackML directly with AI/ML today.”

While the role of AI/ML probably won’t be directly involved with PackML programming, the benefit for applying AI/ML will be in the “bigger picture.” Machine builders like Allpax are already taking advantage of AI. “PackML identifies machine states and faults,” adds Cohen. “Allpax uses AI to monitor these states and faults, create baselines to equipment performance and notify plants when equipment is operating abnormally and reducing efficiencies. PackML can be expanded to do the same, but I believe some integration will still be needed.”

PackML and OPC UA can deliver the data you need to compute OEE scores and at the same time, with the help of AI/ML, predictive maintenance (PdM) programs can benefit from this collected machine data in a big way—letting manufacturers define a maintenance program that works with fewer interruptions to production.



References/Resources

[1] “PackML for Beginners,” Kyle VanDruten, E Tech Group, March 15, 2021

[2] “Implementing PackML in the Engineering and Technology Curriculum,” Dr. Maged Mikhail, Purdue University Northwest, The Future of Engineering Education, 2024 Annual Conference & Exposition, American Society for Engineering Education, 2024

“PackML Implementation Guide: Part 6: PackML HMIs - User Interfaces, Stacklights, and Push-Button Controls,” Version 2.0; Patrick Toohey; OMAC; www.omac.org

“OPC 30050: PackML - Packaging Control,” OPC UA Web Site, Released 1.01, 2020-11-11; PackML - Packaging Control (opcfoundation.org)

How suppliers are creating better machine control systems,” FE, Sept. 2016