An Introduction to PackML for Industrial OEMs
PackML (short for PACKaging Machine Language) is a programming standard developed by OMAC (the Organization for Machine Automation and Control) and the ISA (the International Society of Automation) in the early 2000s.
The primary objective of PackML is to create a consistent “look and feel” and operational consistency for all of the machines that make up a packaging line.
This objective is mainly driven by large end-users who buy machinery from different vendors. These end-users expect all of the machinery they purchase to have the same usability, diagnostics, and standardized access to the machine data.
Since it’s inception, PackML has become a popular framework for machine control. PackML is no longer specific to packaging machinery and OEMs around the world are using PackML to program many different types of machines.
The appeal of PackML is that it delivers on several business objectives of end-users including;
In this article, we will explore the most important components of PackML including;
By the end of the article, you will understand these core concepts and be able to implement them in your machines.
By implementing PackML concepts in your machines, you can increase the quality of your automation software and add value to your machines by making them easy to integrate into production or packaging lines.
PackML is a programming methodology that is organized around a state transition diagram. The PackML specification defines 17 states and the transitions from one state to another.
As well as defining these states and transitions, PackML provides;
Basically, PackML provides a complete software framework which you can use to program machines in a standardized way.
A State Machine is a control model built around fixed operating states for a piece of equipment. As well as having well-defined states, there are defined transitions from one state to another.
A machine can only be in one state at a time.
The benefit of using a state machine control model is that operators can easily understand what a machine is currently doing. They can also understand what needs to be done to move the machine into a more productive state.
For example, if a machine is in the PackML State “Suspended”, then the machine is not able to produce because it is blocked or starved. The operator must solve the issue upstream or downstream of the machine to get the machine producing again.
The other benefit of a state machine is that it simplifies the control program.
Each function that the machine can perform is assigned to a state or a set of states. That function can only be executed when the machine is in one of those identified states.
For example, a machine may have a homing procedure for its axes. This homing procedure should only execute when the machine is in it’s “Resetting” state.
The PackML State Machine model contains 17 pre-defined machine states.
Not all states have to be used in every machine, however, there is a minimum number of states which must be used. These are Idle, Execute, Stopped, and Aborted.
In each state, logic can be executed until a state transition occurs.
Each state falls into one of two categories:
An Acting State is a state where the machine is performing some transient action.
The names of acting states end in “ing” to show that there is an action occurring while the machine is in this state. Some examples including Resetting, Starting, Clearing, Stopping, Aborting, Suspending, Unsuspending, Holding, Unholding, and Aborting.
Typically, the machine finishes its functions in an Acting State and automatically transitions to the next Waiting State.
Waiting States are stable situations for the machine such as Stopped, Complete, Idle, Held, Suspended, and Aborted.
The machine remains in the current Wait State until it receives a command to move onto the next state.
PackML has clearly defined transitions between states. No state transitions that are not shown on the state diagram are allowed.
A state transition can be triggered in several ways. These include:
In PackML, a machine mode is an ordered subset of the PackML states. A PackML mode is used to define the machine’s operational mode.
A machine can have an unlimited number of modes.
Some common and useful modes are described in the PackML specification. Where possible, I strongly recommend that you implement these modes. The default PackML modes include:
Production Mode, where the machine executes normal production logic in response to commands coming from external systems or the machine operator.
Maintenance Mode, where authorized personnel can run the machine independently of other systems. This mode is used for troubleshooting, machine trials, or testing operational improvements
Manual Mode, where authorized personnel can directly control single machine modules. This mode is used for commissioning single components and fault diagnosis.
Other modes can be added by the user as required. Additional modes may include machine cleanout or product change modes.
In each mode, a different subset of the 17 PackML States can be used.
For example, in Production Mode, a machine may use all 17 PackML States.
In Maintenance Mode (where the machine is to run independently of other systems), the Holding, Held, Unholding, Suspending, Suspended, and Unsuspending states may not be used. These states are typically used to respond to stoppages in a line and they are not required when the machine is running independently of other equipment on the line.
The logic executed in each state can be different depending on the mode of the machine.
For example, in Production Mode, the execute state will mean that the machine is executing its task automatically.
In Manual Mode, the Execute State will mean that the machine is waiting for or performing an operator command such as jogging.
A machine is only allowed to transition from one mode to another when it is in specific states.
The states in which a machine is allowed to change mode are called mode transition states and are freely defined by the user. Typically, mode transition states are states where the machine is in a stable condition such as Idle or Stopped.
A mode to mode transition always occurs within the same state. For example, if a machine is in the Idle State in Production Mode and a transition to Manual Mode is requested, then the machine will be in the Idle State in Manual Mode.
Production and packaging lines are typically made up of individual machines coming from different vendors. A lack of consistency in the automation software from different vendors makes it difficult to integrate these machines into a line horizontally and vertically.
To combat this issue, PackML has a defined set of tags, called PackTags, which are used to interact with a machine. PackTags are grouped based on the function of the tags. The following groups are defined:
The PackML standard defines the PackTags that can be used in machines.
Many of these tags are optional, but there is a minimum set of tags that must be implemented in the machine.
As well as the minimum set of tags and optional tags defined by PackML, machine vendors are free to add additional tags to suit their requirements.
The complete list of PackTags is available in the ISA 88.00.02–2015 document. The table below shows the minimum tags to be implemented in a PackML compliant machine.
PackML compliant machines fit into the overall ISA S88 physical hierarchy.
OEMs and machine vendors are mainly concerned with the bottom three levels of the hierarchy, which is modified slightly to suit discrete machines.
Part 5 of the ISA 88 Part 5, also known as Make2Pack, defines a standard way to decompose machines into physical and function elements according to the ISA S88 Physical Hierarchy.
According to the Make2Pack specification, a machine can be broken down into several hierarchical levels. These levels are:
This hierarchical level represents the whole machine.
The Unit Level contains the PackML State Machine and is responsible for collecting status information from lower-level modules to determine the overall state of the machine.
The Unit Level is the main interface for the control of the entire machine.
An equipment module is a logical group of physical components that function together to perform a single task.
An example of an equipment module might be a single conveyor in a palletizing cell machine.
The Equipment Module is responsible for monitoring the status and controlling all of the Control Modules beneath it.
A Control Module is the smallest element in a machine. Typically, a Control Module in software interacts with a single physical element in the machine.
An example of a control module might be a photoelectric sensor or a drive in a conveyor.
The control module is responsible for monitoring the status of a physical device and controlling that device based on the current machine state and mode.
If required, the Control Module is responsible for requesting a change of state, for example, if its task is complete or an error occurs.
Most of the logic for controlling a machine is written inside the Control Modules.
The communication between the hierarchical levels of a machine is also standardized and modularized.
Commands received from a higher-level system (such as a line controller) are distributed down through the various layers — from the UN to the EMs, and from the EMs to the CMs.
Status messages and alarms move up through the hierarchical layers.
A CM may create an alarm that is passed up to the EM. The EM summarizes all of the messages coming from its CMs and passed the summation up to the UN.
The UN summarizes the alarms and updates the state of the machine if required. This summarized state data may be passed up to a line controller if one is available and displayed on an HMI to inform the machine operator.
PackML defines a standard structure for messages. This standard structure includes support for;
In this article, we learned the most important concepts of the PackML software programming methodology, including:
The PackML framework provides a powerful way for OEMs to standardize its software structure.
Not only does this provide benefit for the OEM through reduced engineering effort and easier service/support, but it benefits the end-user too since machines are easier to integrate into their production lines and with higher-level systems.
By creating a win-win situation, you can decrease the cost of your machines while increasing the value, thus growing your profit margins and increasing your competitiveness in the market.
If you haven’t already, I strongly advise that you exploring PackML as a way to standardize your automation software. Even if you don’t follow the specification to the letter, the concepts may help you to create improve the quality and understandability of your automation software. You can learn more about the value of software standardization on our standardization page.
When you’re ready to take the next step in your standardization journey, our automation consultants at KB Controls are here to help plan, implement, and maintain your automation software standards.
Don’t forget — you can contact us today for a free consultation call to discuss the value of software standardization for your business.
Part 2 of Software Standardization for OEMs
Part 1 of Software Standardization for OEMs