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.