Trends in packaging automation

Design engineers don’t need a crystal ball to see the future of packaging automation. They can simply heed commentary from Dr. Bryan Griffen, Nestle’s global automation and electrical engineering manager.

Griffen also serves as an OMAC board member and chair of the OMAC Packaging Workgroup (OPW). Driven by end user requirements in the global consumer packaged goods industry, new OPW initiatives will impact electrical specifications, networked safety, HMI design, and integration with controls, packaging line integration and even such seemingly straightforward aspects as stack lights.

The growth challenge now facing consumer packaged goods focuses on emerging markets where automation infrastructure and labor pools can be nonexistent. Even in developed markets, the skills gap calls for de-skilling of operation and front-line maintenance. Add to this a broad range of packaging machinery suppliers compared to the internal development of batch manufacturing processes, and it becomes impractical to take a deep dive into each packaging machine’s control code.

Increased throughput, uptime, energy efficiency, and changeover flexibility are always priorities. However, finding unexplored opportunities to increase performance is difficult. Much of the next wave of productivity enhancements will come from information that can be accessed from the HMI and across the entire packaging line.

With notable exceptions, packaging machine suppliers have long concentrated on their individual machines. Through a combination of acquisition and some organic growth, more machine builders are also offering turnkey solutions or some level of integration services. Enabling packaging machine designers to solve these productivity challenges is a new trend in automation standards being led by OMAC member companies like Nestle.

Standardized HMI template

At a recent industry forum, Griffen shared some eye-opening statistics. The company has roughly 200,000 HMIs in operation around the world being used by 70,000 employees. Screens from a typical packaging line’s 13 HMIs are all completely different and require some familiarity to use.

Next Griffen showed a simple template that consistently puts a toolbar at the top of the screen, plus a series of start, stop, and restart command buttons on the right-hand side, and additional active alarms and event messages along the bottom. In this way, a common look and feel can be established with the machine builders’ existing graphical interfaces unchanged in the middle.

As of this writing, Nestle’s initial HMI specification has been completed, internal validation is underway, and pilot applications are being executed. The next steps are to integrate with the OMAC PackSpec initiatives and include the HMI specification in the general user requirement specification (URS) for packaging equipment sold to Nestle, described later in this article.

Likewise, the OMAC Packaging Workgroup has also discussed setting some standards for the meaning of stack light colors, sequencing, and order. Consider that even colorblind drivers have no problems with stoplights because they are always red, yellow, and green from top to bottom. Drivers know that a yellow light means prepare to stop (except in Germany where it can also mean prepare to go). A blinking red light (accompanied by a stop sign) at an intersection means stop-and-go, while a blinking yellow means caution.

In contrast, try reading section 10.3, Indicator Lights and Displays, in EN 60204-1, Safety of Machinery, Electrical Equipment of Machines, Part 1, General Requirements. It’s vague at best.

HMI-based maintenance capability

Worldwide, there are simply too many machine builders using too many different control platforms for plant maintenance personnel to effectively delve into the code. This has long been a rationale for standardizing on one controls supplier. However, such an approach fails when buying advanced European machinery, when a company grows through acquisition and inherits somebody else’s internal standard, and when the specified control vendor actually requires different software environments for its low, mid-range, high-end, and legacy controllers.

Many machine builders are eager to optimize their designs by selecting the control platform best suited to their cost and performance equation. And they do not, in fact, want their customers changing their code. The big question is, why do maintenance people need to alter the OEM’s code in the first place? Typical reasons include troubleshooting, changing timers, interfacing to conveyors, and adding a stack light or an infeed.

Nestle contends that end user interventions should be handled from the HMI, with no compromise in the machine builder’s code. This idea requires a change in HMI development practices to anticipate these tasks, but it would benefit just about everybody.

In this way, one of the last hindrances to open architecture automation is removed. Fewer proprietary skills are required to maintain and operate machinery. What’s more, so many processor and software advances have taken place in recent years that keeping code inside a maintenance technician’s comfort zone can seriously impair a machine’s performance potential.

For many years, the importance of reliable operation has made the packaging floor electrician a gatekeeper of sorts. Now, however, the reliability goal can benefit more from modern diagnostic technologies than the ability to read and analyze ladder logic.

For machine builders, there is yet another bottom-line impact. Why do maintenance personnel change the operating parameters of a machine? Changes are made for many reasons—perhaps to increase the seal bar dwell time, because bags aren’t sealing properly, for example. Too often, this only masks the real problem, which could range from inconsistent film to a faulty temperature sensor or heater. Using more heat might only further damage the system, leading to more extensive repairs, not to mention preventable warranty costs.

While plant maintenance personnel may at first feel as if they are losing control over the troubleshooting process, they’ll soon experience fewer calls at 3 a.m., more time to focus on preventive maintenance initiatives, and more money in their paychecks if eligible for profit sharing or other performance-based incentives. Of course, it would also be nice if the HMI incorporates the PackML state model and modes.

Tapping into the network

Sadly, there is no universal device bus or industrial Ethernet. This played out in the 1990s, when regionally dominant suppliers created de facto standards in their respective markets. The situation was as if Apple and Microsoft controlled Internet access instead of true standards such as HTML.

As a result, a large number of controls suppliers now support all major flavors of industrial Ethernet, whereas others recognize only their own protocols. The irony of this situation is that the latter make it artificially difficult to communicate over a third-party network, while the former can readily communicate in a multi-vendor environment regardless of the network.

Nestle recently developed a packaging simulation line with its four preferred packaging automation suppliers, B&R Industrial Automation, Rockwell Automation, Schneider Electric, and Siemens. The demonstration simulates product pick-and-place onto a conveyor, case erecting and conveying, case packing and closing, and wrapping of multiple cases.

One of Nestle’s goals in developing its demonstration unit was to establish communications between disparate control platforms. For purposes of the demonstration, a neutral Weihenstephan structure over Ethernet TCP/IP was used. The simulation proved the use of OMAC PackML and communication of multiple control platforms over the same network and protocol, without the need for a line PLC to coordinate the equipment.

This speaks to the need for packaging line owners to ultimately demand greater interoperability of industrial networks, if not for individual machine controls, then for machine-to-machine and machine-to-management systems communications. For communications that do not require determinism, TCP/IP and OPC suffice. For line control networks to synchronize production flow and better balance the line, and for new applications such as networked safety, there must be a better way.

Leveraging safety for productivity

Safety is a topic worthy of an entire article itself, as safe operations are more productive on many levels. However, today’s networked safety systems do much more—providing additional diagnostic capability, safe motion, and robotic capabilities. They can link the operations of machinery within a line together, to allow not only controlled shutdowns, but also zoning so that upstream and downstream processes may continue. These options don’t really exist with hardwired safety PLCs and safety circuits, so this is the rationale for OPW’s new PackSafety committee.

Now add to the safety-for-productivity discussion the implications of the new U.S. FDA Food Safety Modernization Act (FSMA). A broader range of food and beverage packaging systems, including secondary packaging where there is no direct food contact, will face more stringent sanitation requirements. Contamination, especially by pathogens or allergens, is of primary concern. Consequently, machine areas that could harbor these contaminants must be disassembled and cleaned. Machinery can be designed for disassembly, but in day-to-day operations, the question becomes verification.

This is an area where control systems can provide solutions, such as interlocks that require scanning of a bar code on a component that must be disassembled to reveal the code. As another example, RFID scanners on the HMI could require authorized supervisors to swipe their ID tags to approve the machine to return to service after cleaning.

uURS -- universal user requirements specification

A universal user requirements specification (uURS) is the goal of OMAC Packaging Workgroup’s PackSpec committee. Hints of what to expect can be found in Nestle’s new general URS initiatives. As part of the general URS, the corporate controls group completed a streamlined electrical specification in September 2011 that is currently in use for all new machine specifications and is used as a checklist during factory acceptance testing. The electrical specification includes labeling, grounding and shielding, wiring, buttons and alarms management, and documentation. Nestle has identified eight URS modules: Procurement, line integration, equipment, safety/health/environment, hygienic, general design, quality, and electrical and automation, all supported by checklists.

There is great interest on the part of packagers, machine builders, and automation suppliers to simplify the typical URS from 80 or more pages to 10 or fewer, leveraging today’s standards and technologies. Local and national electrical and fire safety codes will still exist, but the days of specifying individual components have become counterproductive. Given the age of many existing documents, users are specifying the industrial equivalent of 486 processors, Windows 95 software, and 56-K modems.

Such specifications are often at least partially bypassed by requesting exceptions to accommodate up-to-date technologies. Yet machine builders complain that the specifications remain burdensome. The specs often arrive as an afterthought, with hours of reading required and no time to implement changes on the machinery.

There was a time, going on 20 years ago, when international standards did not allow for the level of integration and connectivity now desired, because the technologies did not exist. Specifications from this era are simply no longer relevant.

Simplified motion programming

In control programming, the IEC 61131-3 standard—also referred to as PLCopen for the organization responsible for conformance testing, training, application development, and promoting the standard Ñ has quietly emerged over the years as the accepted global standard. The IEC standard’s combination of different programming languages, including North America’s favorite Ladder Diagram, plays well with Function Blocks that encapsulate complex tasks to simplify programming and allow reuse of code.

This is not new, but the power of this standard, which is endorsed by the PackSoft committee (and currently chaired by the managing director of PLCopen), means that more and more sophisticated Function Blocks are being developed all the time. This programming approach is entirely compatible with the concept of HMI templates and accessing user-serviceable elements of the control system from the HMI. It’s also consistent with recipe-based control systems in which preprogrammed recipes are selected from the HMI, and where parameters can be adjusted to run different sizes, flavors, and shapes of products—all without altering the program.

Even for the programmer, coordinated motions that used to require extensive code, cam tables, and several Function Blocks are possible with two or three very sophisticated Function Blocks that are parameterized rather than programmed. Such differentiation within a standardized programming environment was always the vision of the framers of IEC 61131. It allows machine builders and users a common look and feel across vendors, while also allowing those vendors to compete for business based on added value.

For more information, visit omac.org or contact the author at [email protected].