PackML Essentials

An Introduction to PackML for Industrial OEMs

Standardization

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;

  • Easy integration of machinery into a line thanks to well-defined vertical and horizontal interfaces,
  • Easy requirement specifications, based on functionality and not hardware platforms,
  • Reduced cost of ownership of machinery thanks to reduced training through consistent operator interfaces for operation and maintenance.

In this article, we will explore the most important components of PackML including;

  • States (PackML State Model)
  • Modes
  • Standard Interface (PackTags)
  • Modularization (Make2Pack)
  • Alarms and Events

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

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;

  • Support for user-defined machine modes (for example, automatic and manual modes),
  • A set of standardized tags (PackTags) that describe the condition of a machine in a standardized format,
  • A set of hooks for exchange of OEE (Overall Equipment Effectiveness), RCA (Root Cause Analysis), and recipe data with higher-level systems,
  • A modular program architecture built around Equipment Modules and Control Modules.

Basically, PackML provides a complete software framework which you can use to program machines in a standardized way.

PackML Machine States

The State Machine Model

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

PackML State Machine Model

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:

  • Acting states
  • Waiting states

Acting States

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

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 State Transitions

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:

  • The machine receiving a control command from an operator action, a higher-level system or, another external source
  • The logic in an acting state completes normally and the machine transitions to the next waiting state
  • A PackML Event triggers the machine to transition to a pre-defined state, for example, Stopping, Aborting, Suspending, Holding

PackML Modes

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.

Mode Behaviour

PackML State Mapping for different 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.

Mode Transitions

PackML Mode Transition States

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.

PackML Standard Interface (PackTags)

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:

  • Command tags are used to control the machine.
  • Status tags are used to read the status of the machine.
  • Administration tags are used to collect data from the machine

Tag Implementation

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.

Minimum PackTags

PackML Modularity Concept (Make2Pack)

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:

The Unit Level (UN)

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.

The Equipment Module (EM) Level

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.

The Controls Module (CM) Level

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.

Communication Between Levels

The communication between the hierarchical levels of a machine is also standardized and modularized.

Commands

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.

Statuses

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.

Event Structure

PackML defines a standard structure for messages. This standard structure includes support for;

  • A unique event ID (for integration with higher-level systems)
  • A severity (to indicate what state transitions are required)
  • A message (for multi-language messages on an HMI)

Conclusion

In this article, we learned the most important concepts of the PackML software programming methodology, including:

  • State management
  • Mode management
  • Interface management (PackTags)
  • Machine Modularization
  • Communication between hierarchical layers

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.

KB Controls

We help OEMs to get the most out of their engineering teams using systems, standards and automation.

See how you can reduce costs and increase quality by working with us:

Learn More

Learn Something New Every Week

Get informative, insightful content delivered to your inbox every week

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form

Keep Reading

Learn how to optimize your team's performance

Optimize Your Team's Performance

As teams grow, they become chaotic. Different team members have different needs, knowledge is tribal, and everyone has their own ideas about best practices and processes.

How can you get everyone to follow the same playbook and ensure that best practices are being used?

Learn how to reduce your engineering effort

Reduce Your Engineering Effort

End users are becoming more sophisticated. They expect increasingly complex machines delivered faster and with less mistakes.

How can your team meet and exceed the demands of your customers?

Learn how to reduce your engineering effort

Automate the Boring Stuff

Your most expensive resource is under-utilized. Engineers waste countless hours on projects doing repetitive, low-value add tasks.

Learn how to automate the boring stuff to reduce your costs and reclaim your team's time.