KB Controls is reader-supported. When you buy through links on our site, we may earn an affiliate commission. Read more in our disclaimer
A Step by Step Guide for OEMs
In the last few months, I’ve written a lot about the value of software standardization for machine builders and OEMs.
I’ve also written about PackML, a software programming methodology developed and maintained by OMAC and the ISA.
Using PackML, machine builders and OEMs can standardize their automation software architectures by following an industry standard. This helps to reduce their costs while adding more value to their machines.
In 2015, Arla Foods worked with its OEMs to make their machines PackML compliant. After implementing PackML, the OEMs were able to reduce their commissioning time by 50% and reduce the integration costs of each machine by a factor of 4.
But it can be difficult to get started with the PackML and Make2Pack specifications. There are a lot of documents to read and a lot of new concepts to understand. To help you get started, I’ve put together this guide.
In this guide, I’ll take you through the 6 essential steps for planning a PackML compliant machine. Those 6 steps are:
The output of the machine planning is a Software Design Specification that can be used as the basis for programming the machine. Used in combination with a company-wide engineering guide, this software design specification will help you to program machines more quickly and consistently.
“How will the machine be decomposed into it’s physical and functional elements?”
The ISA S88.00.05 standard, also known as Make2Pack, provides a standardized way to decompose a machine into it’s physical and functional elements. This decomposition is consistent with the ISA Physical Hierarchy model.
Most OEMs will focus on the bottom three layers of the hierarchy. These layers are:
Based on this decomposition, we define the structure of the control program. A well-structured control program based on the decomposition of the machine provides better reusability of code, easier program navigation, and easier debugging for the technicians who maintain the machine.
Let’s take the example of a machine that applies two labels to a bottle. This machine could be broken down as follows:
In a PackML Planning Workbook, this decomposition would be represented as follows:
“What modes does the machine support? What states are supported in each mode?”
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.
The PackML State Model consists of 17 pre-defined states and pre-defined transitions between those states.
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.
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.
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:
“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.
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.
“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.
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.
“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.
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:
“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.
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.
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.
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:
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.
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.
PLC Programming from Scratch is designed to teach you everything you need to know to be an effective PLC programmer. Using practical examples, this course teaches you how to program PLCs using the most popular IEC 61131-3 programming languages including Ladder Diagram, Structured Text, and Function Block Diagram in a free development environment.
Part 3 of Software Standardization for OEMs
Part 2 of Software Standardization for OEMs