This article first appear in our sister publication http://www.foodprocessing.com
By Bob Sperber, Plant Operations Editor
The board of directors for Denmark-based dairy Arla Foods has spent a good deal of the spring deliberating ongoing consolidations that are bringing greater capacities to larger plants.
"To avoid empty plants a few years down the line, we have to react now," said executive vice president Jais Valeur, commenting in April on a small plant closing. "If we don't, production costs will be higher and the milk price paid to our owners will fall."
Another Arla executive has spent years improving the company's ability to adapt to changing economic, manufacturing and customer requirements. "As time goes on, we have found that we have to produce more orders and handle more and different kinds of product and packaging requirements for our customers," says Arne Svendsen, Arla's director of global manufacturing information technology.
"Customers like Starbucks or the Walmarts and Tescos will reject any product that does not deliver the right, consistent quality every time," he says. "And they want their deliveries when and where they want them. These are fair requirements and part of the supply chain game."
In food & beverage processing these days, flexibility wrestles with consistency at every turn. From meeting supply chain needs to modifying production lines to adapting recipes based on changing raw materials -- from fruit to cheese, in Arla's case – you gotta stay flexible. That can be especially difficult in a biological process, such as cheese-making. "We don't produce exactly the same thing every time as if we were building cars," says Svendsen. Even so, "tolerances for variation today are much more narrow than they were even a few years ago." His global team is applying data-driven systems to stabilize the vagaries of man, machine and Mother Nature herself.
And that's why, Svendsen says, "flexibility to us also means having a standard MES [manufacturing execution system] platform with a standard interface to SAP." Since 2002, a "One Arla" company initiative led the company to standardize on SAP (www.SAP.com) enterprise software. More recently, the company standardized its plant information systems on MES software from Wonderware (www.wonderware.com) — with installs at 35 plants of a total 65 in the last six years, with more to come.
Having a standard MES with standard modules for recipe-handing, quality management and data collection, among other functions, is "one of our strongest weapons in staying competitive," Svendsen says. Data coming up from the process lets the company access the data needed to get a "crystal clear picture of variability, yield and performance across every site," he says, using automated, aggregated overall equipment effectiveness readings in real time. The same data contribute to key performance indicators from the plant to the corporate office.
Estimated benefits of the SAP-Wonderware integration initiative include reduced work hours in daily operations; process and scheduling improvements through more responsive reporting; enhanced compliance to food safety requirements; reduced stoppages/downtime; and improved quality management.
Tech-wise, standardizing on a single MES platform serves as a layer of "data abstraction" above the machine control layer. That way, plants can gather data "no matter if they have Siemens, Rockwell or other vendors' controls installed," says Svendsen. So, for example, "a batch report looks the same whether it's a powder plant or a cheese plant or a milk plant. And that's probably where we get the most benefit."
From Microsoft to the Internet
For Arla and others who standardize on key vendors at various levels, current software allows a much greater level of off-the-shelf integration. Standards shared by Wonderware, SAP and most other leading automation and business system sellers have come in the wake of the personal computer revolution.
For decades, Microsoft's underlying technology has been the de facto standard for sharing data between plant software applications. Standards were based on Microsoft-based SQL server-type databases and other means of mapping data from point A to point B. For example, in the mid-1990s, Object Linking and Embedding for Process Control (OPC) eliminated the need for every software vendor to develop custom interfaces to every controller made, as well as other devices and software packages.
Vendors used to create vast collections of custom-programmed interfaces, which for some formed the basis for entire marketing campaigns. OPC eliminated those custom drivers when it provided a standard, object-oriented interface wrapper into which each vendor programmed device specifics.
The standard, from an OPC Foundation (www.opcfoundation.org) comprised of vendors as well as users, eliminated custom interfaces. This let all parties shift their focus from redundant programming chores to features that add value to manufacturing processes.
OPC has since proliferated into variants. OPC DA (for Data Access) provided a standard format to share data between applications in real time, eliminating custom-programmed drivers from the world of HMI/SCADA software packages. OPC AE (Alarm and Events), provided transactional, on-demand data transfers. Others specifically addressed historical data, batch data, server networks and more, including handling data formatted in XML, the language of the Internet.
OPC UA (Unified Architecture) is the latest and most ambitious effort. It began life in a 2008 first draft, and continues development to shed its Microsoft object-model underpinnings for the Internet standards of the World Wide WebConsortium, or W3C.
Modular machines, like Russian dolls
Advances in object-oriented software have sped automation system design, implementation, maintenance and adaptability. The key advance has come as a result of engineers breaking-down machine programming into smaller components or modules.
Modular automation "provides greater accessibility and visibility to what's going on within the machine," says David Chappell, principal of Complete Manufacturing Automation Associates, West Chester, Ohio and a former global head of batch automation for Procter & Gamble. When machines are seen as software objects built of smaller software components, he says, "users can react very quickly when they need to change something instead of starting from scratch and building a whole new automation system for something they've done before."
Consider how a machine is like a set of Russian dolls, matryoshkas: One big container opens to reveal a collection of progressively smaller ones. For example, a section of a packaging line isn't "that area over there," it's a segment of conveyor with a proximity sensor, optical sensor, motor, power supply, analog or digital input/output signals and so on.
Now consider that most equipment used in manufacturing is an off-the-shelf commodity. Aside from minor bits of customization, equipment from one application to the next — and one original equipment manufacturer (OEM) to the next — is often nearly identical.
A vessel is a vessel is a vessel, the inputs and outputs, valves and add-ons perform standard functions. A form/fill/seal machine? When broken-down into small enough components, it's largely a collection of commodity units (such as the bagger), sub-level equipment modules (bag feeder) and still more-granular control modules (such as the left feed roller's servo instructions).
As with machine functions, the logic and process control instructions inside control cabinets are likewise largely overlords of commodity programming. As with machine components, control programs can be – and have been – deconstructed into smaller, corresponding components. This is the basic mindset of modular automation.
Furthermore, leading automation vendors provide engineering software tools that represent these control programs, and collections of them, in a graphical environment. Users can create machine and process control programs by clicking and dragging objects together to create machines, and by connecting machine input and output "wires" to form lines. Doing so automatically connects the underlying automation program, which is hidden from sight unless changes are needed.
Many OEMs and other device-makers today provide objects for one control vendor's environment or another, and these can be stored in a library for future re-use, so the user doesn't have to reinvent the wheel. And as users create their own objects or collections of them, they, too, can be stored for future re-use. The parameters may change, but programming is greatly reduced.
While competing automation vendors' platforms are not fully compatible with all makes of controllers, existing and emerging standards are slowly but steadily advancing the cause of modular standards.
The language of manufacturing
To support the goal of modular automation and associated standards to support it, users and vendors — entire industry sectors — must first agree on a common language with which to describe the hierarchies, processes, machines and states of basic manufacturing processes. Common terminology in turn feeds the effort to create programming based on common terms.
Modular automation has advanced with industry-specific implementations of standards such as the ANSI/ISA 88 family of standards -- also known simply as "S88" by North American members of ISA, the International Society of Automation (www.isa.org). After more than 20 years and thousands of pages, the scope of S88 has broadened to accommodate virtually all modes of manufacturing from batch to discrete to continuous, and even including "non-stop batch."
Non-stop production is particularly relevant to high-volume food processors, who "tend to operate more and more in a continuous mode," says Dennis Brandl, president of BR&L Consulting (www.brlconsulting.com), Cary, N.C. Non-stop refers to "a continuous product flow through a facility, with no breaks in product flow even when products change."
"As companies move from batch to more continuous production flows, they strive to reduce intermediate inventories and speed changeovers, sometimes down to less than one minute," says Brandl, who coined the term "non-stop" and literally wrote the book on modular manufacturing automation: Design Patterns for Flexible Manufacturing.
In turn, proponents of S88 have spawned specific integration efforts based on the standard's terms, definitions, and hierarchical "state model," which is part flow chart, part organizational chart and ultimately the basis for software objects. BatchML and PackML are two prominent examples.
BatchML is an implementation of S88 using web-friendly XML documents called schemas. It originated with WBF, formerly the World Batch Forum, now the Organization for Production Technology (www.wbf.org).
PackML, from members of ISA, WBF and OMAC (www.omac.org), the Organization for Machine Automation and Control, is a "packaging machine language," using S88's framework for interfacing with packaging machines. It's not Internet technology-based, but includes "tags" to enable modular integration with other systems.
Quantifying the benefits
Modular, object-based reusable software objects enhance flexibility by reducing engineering efforts to help the manufacturer speed implementations and achieve faster time to market.
Chappell, who chairs Make2Pack (www.make2pack.com), a group promoting the efforts of WBF, OMAC and ISA, says Douglas Machine (www.douglas-machine.com), Alexandria, Minn., was so gung-ho on the idea of S-88-based modular objects, the company programmed its own before there was a complete PackML standard. Four years ago, Douglas announced its results at a packaging automation forum: "It reduced by 80 percent the amount of time, effort and cost it takes to deliver a new machine," recalls Chappell.
Similarly, one of Chappell's automation associates at P&G, Rob Aleska, notes that automation designs based on PackML have slashed control program writing from 20 weeks to three weeks when code was re-used for a second machine; and three weeks to 10 days upon repeated use.
The benefits and competitive advantages to OEMs include shorter machine development cycles and easier upgrades and addition of new features, because it's no longer necessary to reinvent the wheel by programming and re-programming mundane tasks for oft-used components. This enables the project team to focus on higher-level innovations that add value to the product.
The learning curve is easier, too, when OEMs and users are speaking a common language. Standardizing on a modular automation platform goes far to alleviate the pain of having a key engineer retire, taking years of experience and intellectual property with him or her.
The industry is far from united on standard, modular tools. Still, Brandl says, "Many large OEMs are making data from their control boxes much more visible now, but it's still on a machine-by-machine basis." This represents "the first phase of achieving the flexibility you need, where you can get everything you need out of key pieces of machinery, and you can start to improve your process."
The second phase, he adds, "occurs when you can tie all those machines together so you can determine how the machines are working together at the line level," which brings a higher level of optimization, for instance, using data for rapid debottlenecking.
Moving forward, S88-based XML schema are moving toward integration with other standards. One is the ANSI/ISA-95 family of standards for plant-to-enterprise interaction, such as the WBF-derived B2MML, a business-to-manufacturing XML implementation. And a new "106" standard is under way to add a bit more standard "glue" between the 88 and 95 models.
In addition to his membership on the PackML committee, Svendsen says Arla "uses a lot of B2MML. It's just an XML schema with a standard structure that lets me exchange a process order between SAP and my MES layer. And because it's standard, when I say 'B2MML' to another MES supplier, they know what we're talking about. It has been working out very well as a common language."
While vendors tend to dominate the making of automation standards, end users play an important role in development by their mere presence. In the development of XML schema, Arla has been joined by representatives from Kraft Foods, Nestlé, Frito-Lay, Mars/Masterfoods, brewers Coors, Miller and Martens, and others. Chappell's three decades at P&G saw him representing Folgers, Pringles, Jif and other brands.
As engineering, IT and business management leaders converge on common Internet standards for the systems they use, we can only guess whether they'll start to get along and really start to benefit from modular automation and a new level of manufacturing flexibility.