Packaging World:
Would you say the emphasis at OMAC has changed?
Bryan Griffin:
One of the things that we’re trying to do is educate people that it’s not just about packaging. “PackML” was a phrase that was coined in the early days of the work we were doing in defining a state model and the information transfer between machines. It stood for “Packaging Machine Language,” and it came about because that’s what our target was at the time: packaging. But as we’ve matured the technology we’ve realized that it’s not just for packaging, it’s really any discrete automation. We’re using it in robotics, in converting, and in printing as well as in packaging. Unfortunately—or fortunately—the name PackML stuck and has gained momentum. It’s a brand name people recognize, so we’re certainly keeping it. But what you’ll see mostly going forward is TR88 with PackML in the background a bit, because TR88 is the official document. It’s part of the ISA S88 standard, it’s technical report 88.00.02. If you go to look for the actual specification on the ISA web site, that’s how you’ll find it listed.
Has membership in OMAC changed much?
Traditionally there have been two sides to OMAC. There’s the packaging side, which is now morphing more into discrete manufacturing in general as opposed to only packaging. And then there’s the machine tool side, which would include Ford, John Deere, Boeing, and so on, where the focus was more on how to connect machine tools to each other and how to move from CAD drawings straight through to production through improved CAM functionality for each individual machine. The idea is to just connect straight through from drawing to part. On the discrete manufacturing side, Corning is the one leading the charge in taking PackML out of its packaging-only status and into other things in the manufacturing environment. Specifically, they’re working on robotic cells for the manufacture of their products.
We frequently hear from OEMs that going to PackML comes at an unacceptable cost and that there isn’t really a marketplace out there clamoring for it anyway. Thoughts?
There’s a couple of answers to that. Yes, there is an initial cost because you’re rewriting software. It’s like going from the old basic programming to object oriented programming with C++. What we’re finding though is that the companies that jump in with two feet find that that initial cost is very minute in comparison with the benefits they get. Look at Mettler Toledo or the Pro Mach group of companies and you’ll see that they’re doing it now for their own benefit, not even for their customers all that much. PackML is how they do their programming because it’s more modular, more controllable, easier to link their machines together, easier to take the infeed unit from a machine and transport it to another machine rather than rewriting all of that code because it was not based on a state model but was rather the spaghetti code that some of us grew up with long ago.
Are you seeing signs of hope that the TR88 standard is being embraced more widely?
I know that when I went to interpack in 2011 and looked around for machines with PackML in them I didn’t find many. Three years later in 2014 I saw interpack exhibitors advertising OMAC and PackML as distinct machine benefits. And often enough it was a machine builder who wasn’t even an OMAC member. That’s worth noting, because having people use the standard is much more important than having people become members of the standards board. Also meaningful is that we’ve been contacted by two other standards bodies in the last couple of weeks, one in materials handling and the other in robotics, asking for help in developing PackML templates for their software solutions.
I remember hearing a lot about templates and other tools designed to make implementation of TR88 easier. Any update on such things?
There’s a PackTags configurator that was developed by Carl Bostom at Bosch Rexroth that has been given to the industry free to use. It’s a Java application where you go in and you use radio buttons and drop-down lists to select and configure the PackTags for your application. It then dumps all that information out in XML form so that you can import it right into any controller, no matter who it’s from. All your tags are put together, they’re already defined, so you can pull it into your HMI and they’re defined. Another template worth mentioning is the one defined by P&G, which has just been updated. It’s version eleven now, and it’s available on the OMAC web site. This template is used for configuring a Pack ML project, including the modes of operation, applicable states, and tag requirements. And we at Nestlé have put together our own HMI template with input from P&G, Mettler Toledo, and several others. Basically a framework for how to build an HMI, it deals with mostly the navigation so that operators encounter consistent navigation when they go from machine to machine. We’re not telling the machine builders what specifically needs to be in that HMI, that’s up to them; it’s their machine. What we’re saying is that the navigation bar at the bottom should have the same names, the buttons should be in the same position, the information across the top about the recipes and all of these sorts of things should be the same so the operator doesn’t have to re-learn navigation every time.
Some time back there was a concern on the part of packaging machinery OEMs that by adhering to TR88 they’d be giving away intellectual property. Where does this stand today?
The reality is that when I purchase a set of machines and need to make a line configuration with them today and they’re not TR88-based, I have to hire a systems integrator who goes to each one of those machine builders and says “Give me your code because to make your machine work with all of the other machines in the line I have to know everything about your code and how it works so I can integrate it.” It’s in those circumstances that intellectual property is being exposed. But with TR88, where you’ve got to define the state model and modes of operation and you have PackTags that are packets of the information about what’s happening in the machine, the integrator no longer needs to get into the guts of the machine. He simply needs to know what state you’re in and what mode you’re operating in and look at the PackTags that give all the permissives, the speeds, all of these sort of things, so he can just plug the machines together and they run. This frees up our integrators to focus on providing higher-level functions, things like better MES, better diagnostics, and better dashboards for operators. That’s what we want from them in the first place. We don’t want to pay integrators to get into bits and bytes of machines.
Do I also understand correctly that TR88 can actually decrease the amount of time it takes an OEM to build a machine?
Yes. The statistics we’re seeing now from a couple of machine builders show that where an OEM might have spent four hours to load code into a machine it now takes four minutes. Because it’s like object-oriented programming. You pull an object that you’ve already built, already tested, already put into another program and just put it to use. You don’t have to retest it because you already know what it’s going to do.
Are you reaching out to other organizations that can be mentioned?
OpX Leadership Network is one organization we are working with, yes. We’re looking at improving the way machines are specified from both the end user’s standpoint and the machine builder’s standpoint. Right now as an end user we can write long specs that we hand to a machine builder and he spends thousands of dollars just reading through the spec trying to understand what it is we want. On the other side, what they hand us is a document that doesn’t give us any specifics on safety or hygienic quality or other things that we need to know about. It’s a disconnect. So what we’re looking at is called PackSpec. A total specification for purchasing a machine, it has an end user part and an OEM part. It goes through all the different criteria you need to purchase a machine. It’s not an automation document. Yes, the automation side is covered in there as well—state model, modes of operation, and so on. But it also talks about machine speeds, safety, hygienic design, footprint, loads, and all sorts of things in a consistent manner. So when the end user looks at it, he understands what the OEM is saying, and when the OEM looks at it, he understands what the end user needs. Because it’s the same format every time. We’ve had version one out for about two years now. We’re working on a version two that has a better interface. And once that is drafted, we plan to give it to OpX Leadership Network so that they can publish it as one of their documents along with all their others, like TCO, OEE, Worker Engagement, and Hygienic Machine Design for low-moisture foods. So it will be one document in a library of documents that end users and OEMs can use to speak the same language when specifying machine requirements. It should reduce the amount of time and frustration currently experienced as a machine goes through the purchase process.
