In 2005, Automation World’s sister publication, Packaging World, sat down with corporate engineers from Procter & Gamble Co., the Cincinnati-based consumer products giant, to discuss the state of the Make2Pack (ISA SP88 part 5 committee) and PackML (ISA TR88.05) effort, two major standards activities in this area. A follow-up meeting was held recently at P&G corporate engineering headquarters to assess how much progress has been made—and how much work remains. Automation World caught up with Bob MacDonald, associate director, Corporate Engineering, Power, Control & Information Systems, Modeling Simulation & Analysis; Rob Aleksa, Corporate Engineering machine control section head, and vice chairman of the OMAC Users Group (for Open Modular Architecture Control); Pat Dollard, Corporate Engineering process control section head; Mike Lamping, Corporate Engineering machine control technology leader and ISA TR88.05 leader; and Dave Chappell, a P&G retiree who is chief technology officer at Complete Manufacturing Automation Associates, and chair of the ISA88.5 committee.
Automation World: What’s changed since your June 2005 conversation with Packaging World about ISA 88.5, known as Make2Pack, and ISA TR88.05, known as PackML?
Rob Aleksa: At that point in time, we looked at both Make2Pack and PackML as movements into the standards arena for machine systems. PackML was much further along at that time and it still is even today. So a lot of the context that we talked about were improvements to PackML to make it even more capable and move it to an industry standard. Make2Pack, which provides common definitions for the entire machine system structure, was in early development.
Dave Chappell: Actually, the original initiative, Make2Pack, was a WBF-sponsored working group effort between OMAC and WBF (the organization formerly known as World Batch Forum). We explored whether some of the WBF S88 standards could be of value to the machine systems area. Were there things in common between the process and machine industry? And Rob is the one that facilitated that joining. We reached the conclusion that there was an immense amount of synergy that could be realized from the two groups working together, and that’s when the ISA (the Instrumentation, Systems and Automation Society), through the SP88 committee, sponsored the part 5 work group, which is to develop modular automation in the control environment.
AW: There have been some changes to PackML since 2005. What effect has that had?
Chappell: PackML v2 was the version that existed when we did the first interview. Mike Lamping led the effort to create the next set of enhancements in PackML version 3. Mike has also led an effort to create the ISA technical report on how to apply the version 3 PackML guidelines and how they relate to ISA88. The technical report [ISA TR88.05] is out for review and vote. This activity is different than the part 5 standard (Make2Pack). The part 5 standard is expected to go out for final vote in 2008. The target date right now coincides with the WBF European conference, which is in mid-November 2008. So these are two separate efforts that are going on.
AW: What about the upgrade of PackML to version 3?
Chappell: There are some important changes that came in version 3 that are going to eliminate some of the barriers people might have had with PackML version 2. There was a period of time when we considered whether or not PackML should be rolled into the overall Make2Pack effort. A lot of the same people were involved in both efforts. The question was, should we combine it? In the end, we decided not to combine the two efforts. We didn’t want to slow down the PackML version 3 rollout. In the end, version 3 corrects a lot of the original early issues. It looks very good, people are using it and it’s been very successful. So now, we need to take the next step, which is getting PackML to be an official industry standard.
Robert MacDonald: Version 3 is an enhancement over version 2. It adds multi-modes and additional states. That’s really what version 3 was all about.
Mike Lamping: It continues to expand on the standard nomenclature, which drove more alignment with folks. Since the PackML team also included folks on the Make2Pack part 5 activity, we tried to incorporate similar nomenclature and definitions from part 5 in version 3. So it kind of worked out real well. These things should sing and play well together, because they’re all based on a common denominator: ISA88 part 1.
Chappell: It took us two years to resolve the term usage differences between the Make2Pack and PackML that were using the same terms, but for different things. To be honest with you, we still have some opportunities to improve our understanding of the vernacular we could use. I think if you look at ISA88 anywhere in the world, the language is the same to all batch folks. People know what it means; they understand exactly what you’re talking about and how it’s supposed to work. We’re moving in that direction now in packaging.
Lamping: And that’s exactly where we want to be in the packaging world. It’s that same kind of maturity level, where we can talk to different industries, different packaging industries, different discrete manufacturers, different control members and basically all be saying the same kinds of things.
AW: Is this effort specific to packaging machinery, or is it general enough to apply to all machines that a P&G might buy?
Aleksa: The idea for a standard machine language originated from a packaging perspective. A lot of the end-users had significant large packaging operations, so the moniker of packaging was applied to PackML and PackTags. We continue to have it in our vernacular. But from a P&G perspective, we were always planning to use this in other machine areas such as converting and discrete equipment systems.
Lamping: The technical report is written that way as well. The report isn’t addressed to packaging; it’s actually addressed to discrete machines vs. batch. The benefits are the same either way. And that was part of what I talked about as the barrier of acceptance. If it applied to a much broader set of industries, or a much broader set of users, you’re going to get much broader use, there’s going to be more adoption in the industry, it’s going to gain some more momentum, more machine builders are going to use it and more technology providers are going to use it. It will build on itself.
AW: In addition to machine standards, what is the status of linking process and packaging with the enterprise?
Chappell: Some of the other work that’s going on, such as the ISA95 and the B2MML (Business-to-Manufacturing Markup Language) efforts, have significant synergy with part 5. They’re all working together so that we will eventually have this concept of corporate enterprise data flow. As recipes and other information become available, it has a standard way of flowing down through ERP (enterprise resource planning) to MES (manufacturing execution system) to the batch units, actual machines and discrete units that are executing them. It’s going to become seamless. That’s part of the work that Mike led in version 3. We’ve identified a method to interface the MES environment to achieve a common link.
AW: What’s the status of adoption at P&G so far?
Aleksa: We had some initial presentations of PackML version 2 to our business units in 2005, and some very early consideration on projects. In fact, during the previous interview, we had one project that was in the early stages of PackML application. However, there were concerns about the absence of a number of the modes and machine-state flexibility. So internal effort was expended to use as much as we could of the existing PackML, and customize new modes while creating state flexibility. So the negative to PackML version 2 was that it wasn’t complete. It was the right direction, but not quite there. So other than making our internal folks more aware of PackML, we didn’t drive to make it pervasive across P&G. That’s why we put a concerted effort on version 3. We knew we wanted to correct those issues. So with PackML version 3 complete, we are now really making the hard press. We have met with all our business units and leadership. All have agreed this is the right direction. So we’ll be phasing it in. We have one business unit that has already adopted it across its entire GBU (general business unit). They are in the process of rolling it out. We have other GBUs who are applying it on a case-by-case basis, moving toward a broader adoption in their GBUs. Further, we have some GBUs who already have good standards, so they’re waiting for the right re-platforming opportunity to adopt it. The bottom line is, we’re committed as a leadership group.
MacDonald: And we’re including it in our OEM (original equipment manufacturer) software specifications. It’s a pretty easy sell for most people. A lot of the benefits that you’re going to get out of it are pretty obvious.
Pat Dollard: On the process side, we’ve had a lot of success with ISA SP88. One of the things that we’re seeing is a lot of integrators who are using the common language across the world. The one effort that we’ve got going on right now is actually kind of a renewal, which I think is along the lines of the goals of Make2Pack. This is driving standardization down into the code. It’s taking advantage of what the newer controllers have got in terms of different languages. Really using the right language for the right function.
MacDonald: I guess another good point of what Pat just said is our use of system integrators. We’ve got a set of system integrators we use globally. By having them know and understand these industry standards, they can easily do work in any one of our businesses. We can leverage that. That gets us faster, less expensive, and better engineering.
Dollard: And they can actually back each other up.
MacDonald: We actually had an integrator from Mexico fly to North Africa to help fix a problem, because the integrator there wasn’t available at the time.
AW: Some people think that standards get in the way of innovation. What’s your take?
Aleksa: Over the years, I’ve heard OEMs have a harder time adopting some of these software standards, as it may take away some of their intellectual property (IP). In general, I can say that P&G is looking for reliable and robust machines. We’re also looking for machines that have some key innovations from an electromechanical perspective. This type of innovation would really make a difference in our manufacturing.
Lamping: It’s how the software relates to the process. This is where the IP and the value really is. The value is in the operational process of the machine.
MacDonald: We may develop software algorithms or other things internally that we view as highly proprietary. By having this common structure in the machines that we get from OEMs, we can very easily insert our software without having to teach it to the vendor.
Chappell: Brenton Smith, of Aagard (The Aagard Group, a packaging machinery OEM), says that the real value from OEMs is in the mechanical aspects of what they make their machine do. The software that the operator uses to interface with the machine is not value added for him.
Aleksa: A lot of the mechanical power transmission is now being executed in software. Motion control has really come a long way. The ability to do motion profiling in software creates the possibility of doing things you couldn’t do before. This blending of mechanical and controls together, sometimes called mechatronics, is where we see OEMs should be leveraging and creating unique, more robust machine designs.
Lamping: When people talk about standards taking away some of the competitive advantage, I tend to look at it the other way around. I say it actually enables more competitive advantage, enabling higher levels of automation. It allows vendors to be different in terms of diagnostics, prognostics and quality assurance.
MacDonald: And that’s true for us internally, not just for OEMs. We invested a lot of time in industry standards. I have to keep asking myself if it is worthwhile. Some people look at it and say, “Well, you’re taking all this great knowledge you’ve got, you’re building it into the industry and that’s helping your competitors. How is that advantageous to P&G?” Well, the answer is, we’re not focusing on this more base mundane stuff. We can have our limited resources keep working on the higher-level innovation, because all the base stuff is dealt with. And I believe that that will give us a competitive edge.
Chappell: And I think one of the things that Skip [Holmes, previous associate director, Corporate Engineering, Power, Control & Information Systems, Modeling Simulation & Analysis,] believed in is first adopters of the right standards get the biggest benefit. Staying involved, being aware, moving these things forward, so you can select the best ones. There’s a value there.
AW: So in the end, what’s the big value to adopting standards for machines?
Aleksa: We’re a big company. We have lots of products. We have lots of machines, and in the end, we have lots of software. But just like everybody else, we have limited resources. So there is a little bit less of the “not-invented-here” [attitude]. We want to drive the standards because it makes perfect business sense. So here comes a standard that promotes good software methods and standards, rather than inventing our own. It makes a lot of sense to drive standardization, not only across a particular business unit, but across the company as well. Our resources do move from one business to another business unit. So an industry standard makes a lot of sense. We don’t have to maintain and support the software method because the industry is doing that.
MacDonald: A lot of our growth in the future is in developing markets. So we’ve got a less-experienced workforce there. We can really leverage these standards to get people up to speed quickly. They can get good results in a shorter period of time than more experienced people in the past would have been able to do in a longer period of time. That’s critically important for us. Where we have used it, we’ve seen faster start-ups, we’ve seen more reliable operation, we get more reliable software code. The code’s not nearly as complex. It’s easier to troubleshoot, so when you do have problems, you’re up faster.
