When I first heard about PackML, I understood it as a set of states and concepts to model how machines present themselves and behave, and thus, helping different machines from diverse OEMs to easily integrate and work together as a single line.

Digital Maturity in the Packaging Industry Benchmarking Report: Download it now for free!

But as I started to dive deeper into it, I can now say that PackML is much more than a definition for communication between machines and software.

PackML Interface State Model – Source: OMAC

What is PackML?

So what is PackML then?

PackML is short for Packaging Machine Language and it is an industry-standard for the control and monitoring of packaging machines as an area of OT – Operational Technology and industrial automation. From the 3 main categories that comprise the Manufacturing Automation Industry: Continuous, Batch, and Discrete control, PackML focuses on the last 2 and although it was primarily created for the packaging industry, its definition is valid for any discrete process. 

It was created by OMAC  Organization for Machine Automation and Control in conjunction with the International Society of Automation (ISA). Both entities were working on separate definitions until it was merged in 2008. 

Although it dates from over 10 years ago, it is still under development but some parts of the specification are pretty mature.

So, in short, PackML aims to provide a standard “look and feel”, a common way to operate and understand packaging machines by providing a standard set of machine modes and states, Overall Equipment Effectiveness (OEE), Root Cause Analysis (RCA) in the form of alarms and events recipe schemes to be used by SCADA, MES and IIoT platforms. So not only machines can “understand” each other, as an experienced operator can expect to quickly understand different machines, not only in their internal mechanism but also on how to operate it by its HMI, with standard presentation and set of commands and states.

What is it used for and how it should be used?

According to OMAC, PackML brings the following benefits for end-users:

• Easy integration
• Reduction of integration cost, not only on implementation and commissioning but also on the specification
• Same view on units from the supervisory system
• Less risk and uncertainty in commercial contracts
• Reliable data

For OEMs, OMAC points the following list of benefits on adopting PackML, which indicates why machine builders should aim to migrate to a full PackML Unit:

• Standardization of interface, not end user-specific
• Less risk and less uncertainty in commercial contracts
• Reduced FAT (Factory Acceptance Test) and SAT (Site Acceptance Test)

So, as previously mentioned, it can be used for:

1. Organize the data model of a plant, clarifying what is a line, what is a machine, control equipment, etc.
2. Organize the data model of a machine unit behavior, and thus to help companies on quickly understanding what to expect from each machine
3. Provide a standard set of tags to be used by other machines and software, allowing for reduction of cost and time on deployments and integrations
4. Provide information such as faults to help operators and engineers to understand the root cause of problems
5. Present a standard way to calculate OEE and consequently have more meaningful comparisons and insights
6. Provide a flexible recipe schema
7. Improve operator efficiency by presenting a standard way to operate machines

Ideally, it should be used on all machines of a packaging line, with a proper HMI for each machine and another HMI for the entire line view. Machines should exchange messages about their state and mode and make this information also available for software systems like SCADA, MES, and IIoT platforms.

A connected line with PackML and OPC-UA. Source: OMAC

Misconceptions about PackML

1. Industrial protocol. PackML is not an industrial protocol, nor defines one. It adopts OPC-UA and provides a minimum set of tags
2. Association/institution – PackML is maintained by an association called OMAC
3. Regulation/law – it is not mandatory
4. Limited to packaging – it can be used on any discrete process
5. For the entire line (yet) – current documents define the modes and states for a machine unit
6. A software product
7. A proprietary standard

How is it structured?

ISA 88 Physical Model mapped to packing equipment – Source: OMAC

PackML follows the ISA 88 Physical model to represent the plant model. ISA 88 starts with the Enterprise level. Enterprise has sites and a site is organized by areas. Each area has one or more process cells, which in the case is a production line. PackML starts the definitions for this level (line).

A line or process cell is the entire set of equipment needed to execute a single recipe from start to finish of a production order or job. It is a set of machine units.

A machine unit is a machine or a set of machines responsible for part of the production process. It can have only one production order/job per time. Usually, auxiliary machines or machines that are not so relevant to the process are grouped together with a bigger machine, composing a machine unit.

Machine Unit – Source: OMAC

Machine units have control modules. It can be one control module for the entire unit or one for each sub-part. A control module is frequently a PLC, Programmable Logic Computer, that is connected to a set of sensors, actuators, or even other PLCs.

And finally, we get to the most interesting part of PackML: the PackML State Model.

PackML defines a set of states that are possible for a machine unit during any given moment. States are classified as acting or stable. Example: if a start command is received, the goal is to have the machine in the Execute state. But before reaching the Execute State, the machine has to go through a transient state called Starting. 

PackML State Model Syntax – Source: OMAC

When the machine is normally running a job, it is expected to be on the Execute state. If any external problem blocks the machine, it goes to the Suspended state. If the machine has an internal condition that causes it to stop, it goes to a Held state. Depending on the machine speed, these transitions can happen extremely fast. Other machine units and software that are expected to read the current state of a given machine have to use an efficient network industrial protocol that cannot rely merely on simple polling at a given frequency. A protocol that works reporting data by exception is much more efficient and this is the case of OPC UA.

The interface state model defines not only how a machine unit behaves, but also serves as a standard for a machine unit HMI. With the same visual set of states and commands, operators can easily understand the current situation of any machine on the line, even when they are from different OEMs, using different PLCs with different HMI devices and software.

The difference between Held and the Suspended States when in Production Mode – Source: OMAC

How does it fit with OPC UA?

OPC UA is an industrial protocol created to help the interconnection between machines and systems. It is not a proprietary protocol, meaning that it is not closed to be used by a single vendor and unlike legacy industrial protocols, it carries many technological advantages such as:

1. Report by Exception (RBE). Working with the Publisher Subscriber model, or PubSub, devices or software connect to a PLC and subscribe to their desired information. Instead of polling a PLC, they receive this information any time it changes
2. It is self-descriptive with meta-data, which means, every tag comes with its own identification instead of only a numeric key address and value
3. It provides a timestamp, signal quality and a hierarchy of the database. If you are used to a protocol such as Modbus and you know that address 1 sends you Temperature A, with OPC UA you can expect to receive Temperature self-describing itself with its name and location/categorization according to the ISA 88 model. And the timestamp is more precise as you don’t stamp it in the client. You receive this information from the PLC. If the PLC is connected to another PLC that is offline, you will also know that the current value you read is the last known value and not reliable.
4. Finally, OPC UA also allows for the machines and software to communicate using a secure encrypted connection

Despite all these advantages, it is needed to be clear that OPC UA is the transport way for the data. It does not define what data is supposed to be transmitted, which is how PackML connects to it. With a defined set of commands and states, PackML defines a minimum list of tags with their respective names. Any PackML compliant machine unit must provide this minimum set of tags via OPC UA, no matter what is the brand of their machine unit controller.

Table: Minimum list of PackTags – Source: OMAC PackML Unit Machine Implementation Guide-V1-00

How can it be implemented?

The implementation of PackML is a strategic management decision. The whole process of absorbing the standardization consumes time and human resources and the results will require some time to appear. A single project with PackML tends to be more expensive as it will usually be something new for the OEM and packaging company. The resource invested might not pay off for a single machine unit, but as more machines are implemented with PackML, the costs tend to go lower to the point that PackML starts providing savings on a macro implementation plan. And the benefits appear when an entire line is adopting this common standard. Metrics can be compared, machines work more efficiently and other IIoT projects, such as collecting data to support a machine learning algorithm, become much more simple as the data collection interface is known and the same for all machines.