How to Plan a PackML Compliant Machine
By: Ken Bourke
Tags: Plc, Automation, Software Development, Packml, Industrial

In a PackML Planning Workbook, this decomposition would be represented as follows:

PackML Planning Workbook — Decomposition Section

2. Modes and States

“What modes does the machine support? What states are supported in each mode?”

Modes

PackML allows users to define an unlimited number of user-defined modes. Although it’s possible to define an unlimited number of modes, most OEMs will want to keep it simple. The most common and useful modes are described in the PackML specification. These 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.

For each mode that you define for the machine, you must define what subset of the PackML State Model will be supported by that mode.

States

The PackML State Model consists of 17 pre-defined states and pre-defined transitions between those states.

The PackML State Model

It is not allowed to add user-defined states to the state model. It is also not required to use every state in the state model, however, there are a minimum number of states which must be used.

For example, in Maintenance Mode, where the machine runs independently of other systems, it is possible to disable the Holding, Held, Unholding and Suspending, Suspended, Unsuspending branches of the state model.

Mode Transition States

Officially, the user is free to define the Mode Transition States for a machine. These are the states in which the machine is allowed to change mode.

The most common Mode Transition States are Idle, Stopped, and Aborted. These states are preferred since the machine is in a stable position in each of these states.

In my PackML Planning Worksheet, I don’t leave room to customize the Mode Transition States since using the states mentioned above is considered a PackML best practice.

Example

Each mode has its own subset of states from the PackML State Model. Therefore in this step, we have to determine what modes are supported by the machine and what states the machine supports in each mode.

In a PackML Planning Workbook, this mode/state decomposition would be represented as follows:

PackML Planning Workbook — Modes/States Section

3. Actions

“What does each Control Module do in each state, in each mode?”

In this step, we define what each Control Module is doing in each state, in each mode. The documentation created here will translate directly into PLC code.

When defining the actions, remember that states drive outputs. The logic for the Control Module should be executed according to the state. When read aloud, the action definition should follow the structure “In State X and Mode Y then Z”. For example, “In State Resetting and Mode Production then home the axis”.

As well as thinking about tasks, you should also define when each Control Module will set the State Complete bit to drive the state transitions of the machine and when each Control Module will accept recipe/setpoint updates.

Most OEMs will want to define company-wide best practices for actions related to Control Modules that are used very often. For example, if you have a servo axis, you should have a common, company-wide definition for when the axis is homed, reset, enabled, and geared to a master that is used for all machines.

Example

In my PackML Planning workbook, I have defined the actions for the Control Module, CM06 — Upper Conveyor in the Producing Mode.

Since the Producing Mode supports all 17 PackML States, I have defined the actions of the Control Module in each state.

You should notice how easily these descriptions can be translated into PLC code.

PackML Planning Workbook — Actions Section

4. Interface

“What PackTags are used for control and data acquisition?”

In this step, you define what PackTags will be used in the machine program for control and data acquisition.

The PackML Specification defines a minimum set of tags for a PackML compliant machine along with a set of optional tags that can be used for machine control and data acquisition.

If required, an OEM is allowed to add additional PackTags to this sheet to deliver additional information or control to the end-user.

Example

In my PackML Planning Workbook, I have included the minimum set of PackTags that is required for my machine to be PackML compliant.

If I wanted to use additional PackTags, I would refer to the complete list of available tags in the PackML Specification.

If the end-user wanted to collect additional information from the machine, we would work together to add the required tags to the interface sheet.

PackML Planning Workbook — Interface Section

5. Events and Setpoints

Events

“What events can occur in the machine? ”

In this step, we define the events and event categories that can occur in the machine. Events can be alarms, warnings, and status events. The category of the event defines the state changes that occur when an event is activated.

Example

Alarms, warning, and status events are freely defined by the user. Each event has a category, also known as a severity.

Therefore, it makes sense to start planning events by defining the categories of events for a machine. The categories are listed in a table on the PackML Planning worksheet.

Below the event category, each possible alarm is listed with several pieces of information:

A unique event ID (for data acquisition systems)

The category of the event (what state changes are required when this event occurs)

The event message (to be displayed on the HMI/SCADA)

The event cause (what happens in the machine to cause this event?)

The event source (where does the event originate from in the machine?)

Setpoints

“What setpoints can be set by an operator or external system?”

In this step, we define the setpoints that can be configured by an operator or an external system. The setpoints which are accessible to an operator should be meaningful parameters with meaningful units.

For example, it does not make sense to allow the operator to configure the speed of individual conveyors in units of RPM.

An operator is not concerned with the speed of the belts but with the capacity of the machine. The setpoint that the operator can set is the speed of the whole machine expressed in Parts Per Minute.

Example

Setpoints are freely defined by the user. The setpoints that are available to the operator and external systems are listed in the Setpoints section of the PackML Planning Worksheet.

Each setpoint has a logical name, unit, and a defined upper and lower limit.

PackML Planning Workbook — Setpoints Section

6. Program the Machine

The output of this exercise and the PackML Planning Worksheet is a detailed Software Design Specification. This SDS defines exactly how the program should be structured and what has to be programmed in each software module.

This SDS can be reviewed internally to ensure that the software design is solid, complies with company standards and all aspects of the customer requirements are met.

The SDS can also be reviewed with the customer to explain how the machine will function before any software has been developed or hardware assembled. Later, the SDS can be used as an input for operator training, troubleshooting and maintenance, and the machine’s Operator and Maintenance Manual.

Using the SDS, a controls engineer can now easily program the machine in a structured way.

What’s Next?

As you start to plan and develop your automation software in a more structured way, you will notice your automation software increase in quality and consistency. As a consequence, the engineering, commissioning, and testing hours involved in executing a project decrease dramatically.

Over time, you will begin to notice that many aspects of your automation software is, or at least can be, re-used. This includes code modules for Control Modules and Equipment Modules as well as the HMI screens and documentation behind those modules.

At this time, you can choose to formalize your reusable modules in a software library that’s version controlled and tested. This helps to reduce effort and increase quality even more.

Once you are working with standardized processes and standardized software, it starts to make sense to automate parts of the process. Why should an expensive controls engineer waste their time on repetitive tasks like:

Creating the program structure

Calling and parameterizing software blocks

Creating HMI screens

Placing and tagging objects on HMI screens

Copy-pasting document sections

However, the skillset of systematizing processes, standardizing software, and automating processes are very different from the skillset used to design and build machines.

It’s a skillset that we at KB Controls have developed over many years and work closely with clients to implement. If you want a partner to help you with your systematization, standardization, or automation journey, then get in touch with us — our automation consultants are eager to help.

Conclusion

PackML is an internationally recognized programming methodology. When combined with Make2Pack, PackML provides OEMs with a uniform way to structure their automation software and program their machines.

You can plan a PackML compliant machine in 6 simple steps. The output of this planning is a detailed Software Design Spec that can be used to program the machine, prepare training documents, and speak to your customer about how the machine will work at an early stage of the project.

At KB Controls, we use a PackML Planning Workbook. Feel free to contact us directly if you would like a copy of this workbook.

Implementing PackML is only the first step in a long journey to more efficient engineering. Once you have standardized your machine planning process and your software architecture, you can start to think about standardizing more aspects of your software.

Once you are working with standard software, you can begin to think about automating your processes to further reduce the engineering effort.

By systematizing, standardizing, and automating your automation software, you can reduce costs, increase profits, and create or maintain a competitive advantage for your company.

Frankly, it’s a no-brainer.