Companies Make the Case for PackML as Industry Standard

PackML, or Packaging Machine Language, defines a common approach for programming and machine states for automated packaging machines. The standard has been around for years but now, with the strong backing of Procter & Gamble and other large consumer goods packagers, a growing number of packaging machinery OEMs are making a push to support the standard.

At the heart of the initiative is the desire for a universal method of collecting production information to measure the operational effectiveness of complete packaging lines. And there are other potential benefits as well, including a common look and feel between machines and improved troubleshooting.

There are also complications that have kept the standard from gaining traction until now - primarily the complexity of the standard itself and reluctance of OEMs to adopt a new programming approach.

Strong end-user support in 2008 helped PackML gain some initial momentum. It was adopted as part of the ISA88 industry standard in August 2008 and, using the principles laid out in ISA88, the OMAC group set a course based to strengthen support for the standard and endorse modular programming concepts.

Rockwell Automation also made additions to its Power Programming environment, and Version 4 now fully embraces the ISA88 modularity concepts and leverages the workings of OMAC. The OMAC PackML guidelines, which are now published in ISA-TR88.00.02, provide the broadly recognized machine state model and standardized data model (PackTags). The models provide a common set of terminologies and structures that significantly reduce the customization, time and cost associated with integration of machines with manufacturer's information systems.

In 2009, Procter & Gamble developed a PackML Implementation Guide to aid software developers in achieving a clean and efficient implementation of PackML. This guide includes software and help files for implementation on Rockwell's ControlLogix platform, and offers a simplified version of the cumbersome 125-page PackML standards document. The OMAC Packaging Workgroup (OPW) adopted the guide and is encouraging technology providers to develop example software that follows it. A copy of the guide is available for download on the OMAC website.

Moving Toward Implementation

"PackML is very simple and provides common naming conventions for the states of a machine whether you are running, stopping or stopped. It defines the terms, so that no matter whose machine and control system is being used, it is the same and allows the user to do 'apples-to-apples' comparisons," says John Kowal, market development manager for B&R Industrial Automation and a member of both the OMAC board and PMMI. "It's a simple concept, but implementing it broadly is the next step."

Kowal says that PackML offers standardized machine states and modes, an automatic
and manual mode to jog a machine on start-up, plus tag naming conventions called PackTags.

"That means the data that you are looking for inside the machine will be the same tag name regardless of the control system or machine builder," he says. "So you can imagine how, for any kind of data acquisition, with OEE being just one, it is much easier to do use PackML than looking at different systems and how they defined a particular data point. If you are doing OEE, you are collecting data on uptime and downtime, and know whether you are making a good product or a bad product. It is a lot easier to do this when all the machines are speaking the same language."

Kowal says a group of OEM packaging machine builders, including Pearson Packaging Systems, Pro Mach Inc. and ADCO Mfg. are committed to communicating the business benefits of PackML. If implementations are ready, the idea is to explain why end-users should specify it and how it can help achieve a higher level of connectivity and continuity of data.

"The trend is toward having more business-level analyses of machines, and making it easier to implement them across an entire packaging facility," says Kowal. OEE has been a focus in manufacturing for a long time, so this should be of interest to operations and general management. I think the main reason people don't implement advantageous new initiatives such as this is because, when they see something new, they first see the potential risk involved if it doesn't catch on fast enough or causes some other problem."

Click here for a larger version

OEM Support

Pearson Packaging made a corporate decision to support the PackML standard in 2007.

"We went down this route early with PackML largely because of the benefits we saw," says Michael Senske, president and CEO at Pearson. "We first became interested in it because we were hearing from many large consumer packaged goods OEMs that they wanted standard approaches to controls, electrical engineering, HMIs and programming. These companies are a big part of our customer base.

"On our core product lines, such as case erectors, case packers, case sealers, palletizers, bag inserters and uncuffers, we decided to adopt the PackML standard across our entire product line. It's now part of the main offering on our machines."

Senske says the number one benefit that PackML provides, in his view, is a standard approach to programming. The main benefit to the customer from standard programming comes when they receive multiple pieces of machinery from an OEM. With standard programming, there is consistency among the pieces which makes for easier troubleshooting. As a result, the machine's look and feel is very similar from a controls perspective, and tried and true code is reused over and over.

According to Pete Lawton, a senior applications engineer for Pearson, the company also adopted the Allen-Bradley Logix platform at about the same time as a standard.

"There was a slight increase in our bill of materials and our unit cost went up a little bit at the same time. But we felt that our ability to reuse code, to standardize code and pull code libraries would benefit us greatly," says Lawton. "We thought that ease of troubleshooting equipment would probably outweigh, from an operations perspective, the rise in the bill of materials. We felt that we were going to save money on the back end by investing a little more up front and, generally speaking, I would say that has definitely been the case."

Lawton says the transition to moving to PackML was more a change in the thought process of developing machines than actually the need to write additional code. "Because all the vendors involved have PackML code written, it's a matter of understanding the programming and identifying where the hooks should be into the logic for starts, stops and faults," he says.

"Once we had that figured out, all we had to do was modify the code based on how we write standard code. We have a standard for ourselves now. Any time we have a new machine that requires PackML, we can pull that out and pull that code we used in the past that was non-PackML and then drop it in and update the logic. So while the upfront thought process took some time, it really saves us time going forward."

Another OEM, Pro Mach, one of the largest packaging machinery companies in North America, has been watching the developments with Make2Pack and PackML. They feel that now is the time to get behind it.

"Even if our end user customers weren't demanding it from us, it makes sense for us," says Jack Aguero, vice president of marketing and business development at Pro Mach Inc. "You can imagine with all these different products that we make, if we could have a language that sat above our proprietary software and monitored the status of our machinery in our customer's plant, there would be a big benefit. For example, if we had a service technician from one of our divisions in that plant, he could monitor how machines from other divisions in that customer plant were performing for us - that would be a big benefit for us regardless of customer interest in it."

Pro Mach has appointed one of its lead engineers to be the champion of PackML within Pro Mach. Different divisions of the company, including Axon, Ossid and Brenton are preparing to show PackML implementations at the upcoming Pack Expo.

"We have momentum, but it's still a very complex story when you look at PackML," says Aguero. "You still have to make business decisions as to whether this is the appropriate thing for certain products but perhaps not for other lower cost, commodity products."

Aguero contends the benefit for end users ties back to OEE and trying to leverage all the value possible out of the machinery purchased for plant floor use.

"To me, it seems like the right thing to do,  which is why we are moving forward with it. I'm pleased that many of the major control suppliers are creating or have templates to help us implement PackML, and I see that there is momentum here and we're going to be continuing to advocate for it and implement it."

On the engineering side, Pro Mach see advantages with easier support of machines in the field and the ability to reuse code. Despite many clear ease of use benefits, OEMs made it clear that there is a definite learning curve in implementing the PackML software. But the OEMs are in agreement that the long-range benefits outweigh the complications of the front-end learning curve.

"In terms of our business model, it's going to help with service and support of machines over the long run," says Mike Grinager, vice president of technology for Brenton. "Because we will be running a basic software platform that's homogenous, as opposed to unique programming for different machines in the field, it will be a little easier for us to diagnose problems and resolve problems remotely or by our service technicians in the field."

Grinager believes it will be particularly exciting when Brenton gets to the point of reworking some of its suction cup machines. The company will then be able to take the programming it is developing now for use in those machines and change some of the application logic, while leaving most of the equipment modules the same. The result will be a film unwind equipment module, for example, that works exactly the same on all Brenton equipment. Though there will still be differences on how to reset a fault on machines, it will be possible to standardize those types of operations across every machine.

"I think the move to PackML will really decrease development time," Grinager says. "There is a transition period necessary to understand the software details and the impacts on how machine software has been implemented in the past. But we have a commitment to move to PackML, and are now working through the details of moving to it fully."

Preparing for the Next Level

Among end users, the promise of PackML goes beyond a standardized way to program machines, and is tied to the larger goal of quantifying machine effectiveness.

"My pipe dream is for PackML to do for packaging machines what USB has done for personal computers, so we can have plug-and-play packaging equipment," says Jeff Russell, TPM coach for controls and automation at Pepsi Americas Beverages Group. "If we have 10 different brands of vendors on one line, we want to be able to plug them all in through Ethernet and the line controls integrator can already have the code pre-written when we start up the line," says Russell. "And if everything works as PackML is advertised to work, we should be able to hit the start button and start making product. I say it's a pipe dream because we are nowhere near that capability yet, and I don't think anyone is."

This dream remains a goal for Russell, as he sees its potential reality in PackML's data acquisition and handshaking abilities between machines. This capability, if coding processes are strictly followed, will permit all your HMI screens to look the same and the PLC logic for controlling the machine to all look the same as well.

"However, to achieve what I am ultimately after - push button integration of machines - it doesn't matter if the machine is programmed to operate under PackML," says Russell. "I need interlocks and the MES layer data tags to be standardized. It all has to do with OEE data collection. I need to know on every piece of machinery what state the machine is in, and I don't necessarily need the 17 PackML states. I just need to know if it is running, stopped, faulted, blocked or starved. My goal is to benchmark machines against each other and view the entire process, including data collection and get the data up to the MES reporting layer."