Eighty-plus pages are not unheard of. And while local codes do add their own arbitrary requirements, these well-intentioned attempts to create internal standards are becoming obsolete as international standards and regulations are increasingly harmonized.
It’s also difficult for specifications created decades ago to fit the level of innovation in the package design, material, machinery and controls spaces today. Some CPG companies have discovered that the specs that had served them well for years have become a hindrance to innovation. And so, they’ve put their specs on a strict diet of functionality and recognized industry standards.
It’s all about business imperatives, enabling technologies and standards
This guide is all about connecting business imperatives with enabling technologies and the standards that future-proof those investments. In these pages you’ll find actual specification language you can copy and paste and modify to fit your company’s or your site’s needs.
You’ll also see the trends that are promising to make packaging operations more efficient, safe, productive and accessible to the people who use and maintain them.
The past decade’s advances in packaging machinery came largely from mechatronic designs that traded away inflexible and fixed mechanical motion for more flexible and programmable servo motion, intermittent motion for the higher speeds and reduced noise and vibration of continuous motion, and dedicated motion for robotic flexibility. These are still highly relevant machine attributes that not all builders have adopted, or adopted to the fullest potential.
But what’s driving the next big wave in productivity?
Look to mainstream technologies for the answers: aircraft, cars, telephones, appliances,
the Internet.
In short, we are making all of these everyday devices easy to access, use and service. We’re making them capable of self-learning and anticipating our needs. Smart airplanes virtually take off and land themselves. Cars have video cameras to see where our rear view mirrors can’t. Phones have integrated our previously state-of-the-art but separate email, GPS and Web functions into one device. We can program our home appliances from these phones. And of course, everything is connected to the Internet, from the cloud to…you guessed it…the packaging machine.
In a word: convergence
In recent years, we’ve seen the motion controller converge with the PLC, then with the touchscreen HMI. Robotic kinematics were integrated into general motion control and the device network merged onto the motion network. Integrated (and open) safety systems can run over that same network and plug into the same hardware backplanes.
At the same time, we’ve watched the hardware converge into a single platform alongside the software integration. When it comes to specifying the control system for a packaging machine, it is getting harder to justify an argument for a premium priced standalone PLC with special modules for motion, a separate HMI panel incapable of doing much else, and a PC for handling things like production data acquisition, vision and serialization systems, and possibly interactive work instructions for operators and troubleshooters.
Different automation cultures, divergent perspectives
In North America, the automation industry has learned to avoid the term ‘PC-based control’ – because too many engineering managers lived through Windows NT and CE, with hard real-time operating systems that relied on watchdog timers and schemes to interrupt Windows. This led to an abject fear of the ‘blue screen of death.’ There were claims by soft logic suppliers that cheap ‘whitebox’ PCs from Walmart could substitute for industrial PCs. And of course at the time we didn’t have massive Flash solid state drives, and many spinning disk drives failed on the factory floor.
While the allure of PC-based control in the mid-1990’s was well-founded, the immature software and hardware of the early days were not sufficiently robust for industrial applications, causing many machine builders and packagers to rethink switching.
In Europe, they never feared ‘PC based control.’ In fact, they embraced the relevant force driving their advances – a combination of Moore’s Law and recognition that control applications like logic and motion should not be dependent on hardware configurations. They are in fact software functionalities that happen to run on hardware.
The same holds true today for safety networks, which are really protocol extensions running on the application layers of the various flavors of industrial Ethernet. Once you think in terms of software, you free yourself of increasingly irrelevant and limiting classifications like PLC and PAC. What you really need is the appropriate control hardware to run the software that delivers the desired functionality.
See the coming convergence?
Once you gain the benefit of Moore’s Law you catch a ride on the incredible, ongoing rise in processing power and the simultaneous drop in processor cost that high volume, mainstream computing markets have created. That’s exceptionally true today with mobile computing and device markets that have led to powerful multicore processors and economical, compact processors that run cooler, consume less energy and withstand vibration and ambient temperature extremes.
The formula includes a proven real-time operating system that is totally separated from and has absolute priority over Windows. This requirement has been clear and deliverable for over 15 years, driven by mission critical computing applications in the medical, energy, telecom and aerospace industries. Much of PC-based control’s bad rap came from using a real-time operating system that interrupted the hardware abstraction layer (HAL) of Windows™ instead of running Windows in the background.
What’s been harder to achieve until more recent advances in processing and memory power is the complete integration of control functions into a single software development environment, a single program and a single processor, independent of hardware targets and therefore scalable, using the international automation programming standards called out in IEC 61131-3 (www.plcopen.org).
Convergence between control and management functionalities
But this still isn’t the full meaning of the convergence. For that, we need to cross over to the Windows™ side of the processor. Depending on the criticality, it could be a relatively pedestrian Pentium® M or it could be a powerful dual or even quad core processor. It doesn’t really matter, because all are readily available and affordable. What matters is the ability to run Windows, usually embedded, or Linux, for the new breed of management software applications that increasingly need to work alongside control.
This is where packagers plan to unlock the next round of game-changing improvements to productivity. We’re already seeing it. True, the state of servo technology continues to advance with recent breakthroughs from automation suppliers, such as distributed servo motor/drives, safe motion and safe robotic control. But packagers now have the chance to realistically marry control with factory management systems.
So, all the productivity enhancing applications that typically run on a standalone PC – production scheduling, recipe management, OEE, training videos, data historians and the like – can run on the PC portion of the machine control. They can be called up as needed by a condition in the control program to assist plant floor personnel. And they will do it with immediacy, in addition to periodic uploads to a data historian for offline analysis and future corrective action.
Technology providers have come so far in control – especially motion – that they’re really good at synchronizing sub-millisecond activities. Now it’s time to catch up on the non-realtime side of the equation, which is how people manage our processes.
Convergence between previously siloed functions
Automation strategists are also recognizing that each new software functionality improves more than just its own intended application. For example, a safer machine has more uptime, so its OEE numbers will be better. Better OEE means a machine that is more energy efficient because it’s running at steady state rather than stopping and starting. Energy efficiency and making good product make for sustainability. Making less scrap also means better quality. And so on, the bottom line being improved profitability.
And so it goes. This convergence has the potential to increase productivity of the whole beyond the individual applications. And software convergence can certainly enable many aspects of lean manufacturing initiatives.
New applications are driving adoption
As slowly as technology adoption appears to move in industrial control versus IT or consumer markets, the need to do so is accelerating. And indeed, many in the packaging automation community see developments such as PackML, OPC, MES and OEE leading the way.
Serialization is the next big thing, first in pharma and eventually wherever traceability is an issue, as in ‘farm-to-fork’ food safety. This involves unique man- and machine-readable codes for each package. That requires interfacing the packaging machinery control system to the coders and banks of vision cameras to confirm the coding. The data and vision processing intensity calls for powerful industrial PCs and networks capable of high speed, deterministic operation.
Another is on-screen help systems. Today, too many work instructions still take the form of PDF files of instruction manuals, when they really should be interactive – using video and/or animation – and walk the operator or maintenance tech through the solution step by step. Moreover, troubleshooting steps should come up automatically, triggered by a bit in the control program when a fault occurs. This calls for not only a Windows environment, but communication between the Windows and real-time worlds on the same processor.
This immediacy means faster resolution and consistent troubleshooting, with less need for escalation and off-line training, faster escalation to the appropriate level if needed, and consistent procedures. Recording incidents along with their remedies will yield important information for root cause analysis and for preventive maintenance tools to avoid incidents from reoccurring in the future.
The unified platform arises
It now becomes possible to envision a single, unified platform that:
• does all we’ve discussed in terms of control
• with easy access to data inside the processor by non-realtime factory management applications running on Windows, Linux or another mainstream operating system
• serves data up to screens on the HMI panel as well as any other interface device authorized to access the information
• is based on international standards, not proprietary or one-off interfaces, so that it becomes control platform independent and – importantly – consistent worldwide
From a practical standpoint, these developments effectively provide a viable alternative to single-vendor control specifications. A number of international standards and best practices that support this alternative approach are encapsulated in what is known as the OMAC Packaging Guidelines (see Chapter 2). Nestlé is embracing this philosophy by adopting these guidelines and asking its preferred automation suppliers to as well.
As a result, some packagers are migrating to a standards-based functional specification with preferred, compliant vendors. This new freedom of choice can increase the number of options—and capabilities—available to machine builders.
How to turn a trend into a standard
What will such a universal specification look like? Quite likely it will look like PackSpec, a new initiative of the OMAC Packaging Workgroup. According to the PackSpec committee’s September 27, 2011 report to the OMAC Packaging Workgroup, the specification could deliver the following benefits:
• A streamlined quoting process – based on performance, functionality and footprint)
• Quicker machine development and building
• More accurate and effective FAT – including Installation Qualification, Operational Qualification (IQ/OQ) (PackConnect) and Manufacturing Execution System (MES) (PackML)
• Easier factory integration
• Machines designed to be deployed world wide
• An accurate document set to support the machine into the distant future
The same push for a standard is taking place in networked safety. Recognizing that safety is really a protocol extension running on the application layer of the various flavors of Ethernet, it becomes clear that there’s no reason for a second ‘fieldbus wars’ with each vendor developing its own safety protocol to run on proprietary networks.
That’s the premise of openSAFETY, and in turn, the PackSafety committee’s charter. It is significant that Nestlé has also come out in favor of an open safety protocol such as openSAFETY and is chairing the PackSafety initiative in OMAC.
The end game
Beyond the all-important implementation roadmap, the real end-game is to push productivity to the next level. That’s what convergence is all about. It leverages what were isolated technologies, now converged on a single platform that plant personnel can quickly access, understand and respond to. And to make it all work, it takes standards.
This requires that manufacturers change their specifications to reflect the new reality, because machine builders need a clear requirement in order to justify investment in newer technologies.
For starters, this playbook’s objective is to give you a guide to developing specifications today based on both existing and emerging standards, with a healthy dose of best practices. And wherever possible, we’ve included sample specification language that you can use today.
In the long run, the way to make change happen is to become active in users groups such as OMAC and relevant machinery associations such as AMT and PMMI, to help develop the standards and to drive adoption.
To wait for somebody else to make it happen is to sacrifice first mover advantage. And once that time is lost, it can never be regained.
Liked this article? Download the entire playbook here.
