OMAC Standards: Marketing ploy or value-adding?

With the price and scarcity of manufacturing labor, the future of manufacturing in America depends upon our ability to automate – Really Automate. Our ability to really automate depends upon making it simple to reliably automate and simple to reliably integrate our automation with our supply chains. Making it simple and reliable depends upon our adoption and use of standards like those under development by OMAC and the availability of a smaller but better educated workforce. Today I want to focus on standards.

A reader of this blog wrote me about the PackML guideline which is moving toward standard status. He said that he had heard from packaging machine builders that it was a marketing ploy and asked if I could get to the bottom of whether or not it was worth it.

To address that issue, I am going to rely on a strategy that my grandfather taught me. In life, there are two approaches to judging the merit of something: you can try to understand all of the details of the product or idea or you can try to understand and develop trust in the people behind the details. "Keith", he told me, "if you don't know your fur, know your furrier". So, rather than look at the fur, or the details of PackML, lets examine the furrier, or the people who are developing and advocating it and other OMAC initiatives.

End users provide the leadership in OMAC and approve the guidelines that are issued, but much of the actual work is supported by technology providers. The technology provider list includes the global whose-who in the industry: Siemens, Rockwell, Bosch-Rexroth, Elau, Beckoff, Phoenix, Yaskawa, … sorry to those I haven't mentioned. There are basically two camps among automation suppliers: those who want users to standardize on their brand and those who want users to standardize on adopted international standards which their brand supports. It's sort of like choosing between Apple's McIntosh or a PC. Choosing the MAC ties you closely to the Apple brand. Choosing the PC is really about choosing the standards that enable running multiple operating systems and hardware on a box that doesn't tie you to anybody's brand. Of course, even the MAC makes an attempt at supporting the de-facto Windows standard.

With these camps, it is sometimes arguable whether all of the technology providers want to move things forward or whether some want to see things delayed, but they are all at the table with an equal opportunity to contribute to the OMAC recommendations. Their common interest is that they want to sell automation products and services in the markets that OMAC end users represent. American packagers are a major and growing market for them, although if end users choose to buy foreign equipment and install it in foreign factories, the automation suppliers still win.

The folks that aren't adequately represented at the table and don't win if American manufacturers buy foreign equipment for factories either here or abroad, are the American packaging machinery manufacturers. Although all are encouraged to participate, and PMMI does send representatives to major meetings, not enough manufacturers with the nuts, bolts and wires experience are helping to develop these guidelines and standards.

A very compelling message to OEM's came out of the Packaging Automation Forum held late last month in Chicago. Just when many believed that the OMAC efforts had stalled and might in fact be dying, five of the eight end user companies that spoke, endorsed the OPW guidelines. I'm convinced that these were unrehearsed and uncoordinated remarks by leading packagers. One speaker set the expectation that OEM's use these standards whether they are called out in customer specifications or not. I believe that those few machinery builders that are active in OPW are using OMAC's documented body of knowledge to their competitive benefit, whether their customers are asking for it our not.

To further understand the OMAC end users, I would point out that many of the active OMAC participants represent hybrid manufacturing companies that have significant amounts of processing experience. Process industries are decades ahead of the packaging industry when it comes to integrated automation. One of the things that these sophisticated end users have learned is that standards are essential. With support from ISA, many standards have been developed to aid process automation and integration efforts. Like other standards that affect our lives each day, many of these ISA standards have become so widely adopted that your equipment includes them, whether specified or not. This is where OMAC end users want to get to with OMAC packaging standards.

OMAC's association with ISA through the Automation Federation was, in part, motivated by the desire to use ISA's well-developed standards process to move the OPW work from guidelines to international standards. Folks that helped to develop these standards for process industries are now active in helping to move them into the world of packaging.

If we focused on the fur instead of the furrier, we'd find that the OPW work isn't perfect. I have some concerns with version 3 of PackML, but I chose not to participate in the reviews, so I'm now choosing not to complain about the work completed by others who were more dedicated than I.

With regard to OPW guidelines in general and PackML in particular, I believe that the case is clear that our furrier is competent, well-motivated and trustworthy. Sure, he wants to see people using fur. That should be no surprise and doesn't represent a marketing ploy. Given the experience and motives of the folks who have worked so hard on these efforts, I believe that there is substantial value in this standards work for packagers and machinery builders alike. We should all be paying close attention, or better yet, participating.

TrackBack

Comments Keith, I am hearing a lot of buzz about the "PackML" standard for program tagging and naming for developing and open standard for packaging equipment. It would allow packaging equipment to be "plug and play." for integration. However, after discussing this with several packaging equipment OEMs, and integrators, they are telling me that there is now value added for the cost and that "PackML" is a marketing ploy. Also, for the amount work required to make equipment programs PackML compliant, there is really nothing gained. Can you get to the bottom of this? No one has been able to convince me that "PackML" is worth the effort, but it sounds really good. Thanks, Randy Posted by: Anonymous on June 21, 2007 Great insights! As an end user I am glad standardization is still alive in the packaging industry. With standards comparing equipment performance between OEM'S become much easier and useful. Posted by: Randall Meyer on June 25, 2007 I believe OMAC and Make2Pack are doing valuable work that needs to be done. Unfortunately, the simplicity and common terminology are still not there and this is going to create a problem. I think they are pushing too fast for acceptance and use in applications. The standards are still a work in progress and are still unfinished. Users who have time and can spare the expense will be the front runners, but those who have limited resourses need a simple finished package to open up and use easily. That will take time. Posted by: Paul Zepf on June 25, 2007 Hi Keith - Good seeing you in St. Louis. I am curious about your reaction to the COP meeting. This OMAC is definitley an uphill struggle. I was talking to Douglas last week and asking how that was going (they had changed to Elau) and much to my surprise they hadn't gotten very far in making the move. In fact they seemed behind where they were 2 years ago. AB is till the stronghold. I was out at Alex tech last week so I got to see their remote training - pretty neat! Nancy Posted by: Nancy Cobb on June 25, 2007 i am group chief engineer for SABMILLER plc and sponsor our positioning on Omac. We run a monthly telecon with group wide players on this issue and recently placed and order on KHS for our new pack lines for our columbian brewery, 120000 bph.each. commissioning is in about 4 months ,vendor tests held last week are what we wanted and today we discussed the performance acceptance criteria Rod Posted by: rod milne on June 26, 2007 Well, I said that since I didn't participate in the reviews, I wouldn't complain about the work. But, since one of the respondents to this post brought it up, let me say that I agree that the simplicity and common terminology are not there yet and may have taken a step backward in version 3 of PackML. The thing I liked best about earlier versions was that the states were words that an operator could relate to. The original states were traslated into 11 languages so that operators anywhere could share the same vocabularly. Posted by: Keith Campbell on June 26, 2007 I think the issue goes deeper than many of the discussions I have seen. Within most manufacturers you are dealing with two groups with different motivations- corporate and the plant. Corporate's motivation typically is to lower the up front cost (right/wrong/indifferent). The plant is the entity that carries the burden of the total installed cost. It is one thing to say that the technology platform doesn't matter as long as it integrates/communicates via OMAC guidelines (which means lower installed costs and faster startup- corporate loves this). It is another to talk about spare parts costs and training for plant level maintenance (which concerns the plants). These costs are not trivial. OMAC is only one step in the evolution- and in my opinion it is one that should be short lived. Not because it is a bad idea, not at all. But what we really need to get to is a point where I can generate a program in any IEC language development software and download it to any other platform to run. If I write a web application today it doesn't matter what development software I use. I can run it within any browser that supports HTML, Java, etc. Then the hardware is immaterial- Leveno, Dell, HP, whatever. Is this possible in automation? I personally don't think that the technology is mature enough to make this happen. Honestly, the best way to make this happen is to utilize PC's for control with programs written in a standard higher level language (e.g., C, C++, Java, etc.). Specific algorithms for control components such as servos could be implemented as ActiveX objects utilized by the programmer. But this is not typically an "open" and maintainable concept for the plants either. So do we take the responsibility for maintenance out of the hands of the end user? We don't expect people to work on their own cars, furnances, etc. We leave this up to the "experts" in that field. And I see some end users going in this direction with the absolute requirement for remote support. But this scares people because of poor experiences with OEM equipment ("We must have internal support because these machines always fail and we can't afford downtime"). We need to raise the bar on expectations of equipment and end users need to support this by actually buying the equipment their engineering departments are saying they want (OMAC end users are up front about not wanting to pay for OMAC implementation, but when push comes to shove and that purchasing manager has large input in the final decision, overriding the engineers, the reality is that low price wins because lowering capital expenditures is what drives that manager's incentive). Posted by: Gerald Dillon on July 23, 2007 Post a comment (If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.) Name: Email Address: URL: Remember personal info? Comments: (you may use HTML tags for style)