SOA: Building an industrial operating system
Service-oriented architectures impact how engineers build workflows and make PLC, DCS, and HMI connections.
By Frank O Smith for Control Engineering
Though its use has become fairly ubiquitous behind the scenes, service oriented architecture (SOA) is by no means a pre-ordained technology. Its continued proliferation, however, does mirror-and coincide with-the steady evolutionary crawl of critical information up from the plant floor, linking single cell-like devices into ever-larger functional networked components. The ongoing progression of standards, from the fieldbus level to OPC, to ISA 88/95 and Open O&M, among others, has engineered a standards stack that SOA is leveraging to alter the hierarchical DNA of plant enterprises.
Properly architected, an SOA platform enables an extremely intelligent, user-friendly interface for quickly mapping connections from the equipment layer upwards. This promises to have significant impact on how control engineers build workflows and connect devices to PLCs, DCSs, and HMIs. What's gained in the process of doing this is a higher-order system's intelligence for seamless coordination and collaboration from the shop floor to the corner office.
Decoding the software Tower of Babel
The full vision of SOA is by no means yet realized, with much structural and cultural work yet to be done. Though a simple term and concept, it's still messy in the details and fraught with potential for confusion and lingering turf battles. But make no mistake: it holds much promise.
"SOA is probably one of the simplest concepts-with the most definitions," says Marc Leroux, marketing manager for ABB's Collaborative Production Management solution. Ironically, addressing the confusion created by the Tower of Babel of differing manufacturing, departmental, and IT system terms-often for the same entity-is one of the chief aims of SOA and the standards necessary to support it. SOA depends heavily upon the successful adoption of sections within standards like ISA 88 and ISA 95 that aim to provide clarity for naming conventions.
Fundamental to achieving common terminology is working at the appropriate level of higher-level abstraction that enables‘normalization' of terms to provide accepted, common definitions-definitions that finely balance generic coverage (e.g., ‘flow meter') with useful specificity when coupled with a tag identifier (e.g., ‘flow meter 127'). Within SOA, normalization embraces descriptive terminology for everythingin an enterprise architecture, including resources (equipment, material, workers), processes (workflows), and software tasks (interfaces, security, alarms, applications, reports).
David Chappell was head of global automation services for a Fortune 500 CPG firm for nearly 30 years, and devoted significant effort to normalization of terms and tasks. He said it was a challenge to get plant production people to simplify the notion that they had 10,000 different manufacturing methods, or steps."When you take them apart, you really only have 20 to 50 methods, even for a very complex business." Once you make the move to modularized work process and resource object services, "this greatly reduces the monumental effort of struggling to change" production equipment and control systems every time new products are launched. "You're able to be very efficient in putting them back together to make new products," he says.
Greg Milligener, product general manager for GE Fanuc Intelligent Platforms, describes SOA fundamentally as "an architectural concept for how to develop software." In this regard, it is less something packaged that you buy and more a medium you work in. It requires you have the necessary and appropriate infrastructure tools in place to enable the engineering of integration and dynamic workflows to support adaptive services-based applications. The key objective: to be able to ever fine-tune and holistically adapt and optimize operations toward achieving changing market requirements and evolving strategic objectives.
Normalization of terms is the cornerstone to building a comprehensive model of the plant. And the plant model is one of the key pillars of an enterprise SOA platform. Classically, normalized descriptors also contain functional attributes associated with them, creating self-contained building blocks, or software elements, for assembling larger composite applications. In the SOA universe, all are considered‘services'-hence service-oriented architecture.
Normalized terms, the plant model, and the entire array of modular software services are among the basic elements contained in a central repository or database. A workflow orchestration tool-itself a composite application-is used to create process workflows that bring information regarding all the elements contained in the repository together with specific execution functions, which are also composed as services. Workflow orchestration tools support drag-and-drop of object services to build graphically displayed workflows.
The software programs to power the workflows reside within the objects, such that workflow construction and modification is fluid and easy: snap in place, commit to runtime, and you're done. Because they're managed within a central repository, every instance of the service across the network is easily maintained and upgraded. Collectively combined and harnessed, these object services are what drive the functions within control systems, HMIs, MES, LIMs, and ERP systems. (True to our evolutionary model, these will one day be conceived less as boundaried systems the way we currently use the term and more as libraries of service objects.)
Benefits of an integrated operational system
With a common set of consistent definitions, transactions and work processes, the task of mapping them all together to create a seamlessly integrated operational system is exponentially simpler-even if referencing elements in numerous, disparate systems that one typically finds in a plant. Though effort to normalize terms and build a comprehensive plant model and other critical repository elements requires significant front-end commitment, the payback over time is huge.
The most prominent benefits include:
• opening of traditionally disparate functional systems for freer sharing of data without costly point-to-point integration;
• endless reuse of services without engineering-intense effort;
• extremely adaptive configuration and reconfiguration of production and business operations that can be engineered rapidly at minimal cost;
• rapid prototyping, gap discovery, and correction of configured process workflows;
• highly role-based customized, contextualized presentation of information;
• easy replication of best practices from line to line, plant to plant;
• extensive leveraging of current asset investment through dynamic adaptive control of system functions encapsulated as services; and
• refocusing of control engineering talent on plant optimization and performance.
"Getting plant people to think in modular, multi-layered concepts is challenging," says David Chappell, chief technology officer of Complete Manufacturing Automation Associates, a West Chester, Ohio-based consultancy. "But if you can break down and modularize functions, you can reorganize them when needed and you can get tremendous reuse, rather than starting from scratch with a blank sheet every time."
Creating an industrial operating system
Peter Martin, vice president of strategic ventures for Invensys, says the job of designing an SOA platform is complex, but "if you do it correctly, you make it much simpler and easier for control, process, and automation engineering to do their job." Martin led the initiative to create ArchestrA, the Invensys/Wonderware SOA-enabled platform. Complex as it is, done properly, "it serves the purpose of becoming an industrial operating system that provides the same types of multi-tasking services of a modern computer operating system. It can manage a whole network of management services built up from a common name space, providing an architecture where hundreds of shop floor computers and applications of different vintages from different vendors put in place over 30 years have connectivity and interoperability and work like one computer. It's the breadth of interconnectivity built in that defines the usefulness of the architecture, that enables it not only to work with products from a single vendor's line of products, but all products.
"Because you have a common name space and connection services, you don't have to make calls into those systems. You don't need to worry about whose system it is. You don't have to set up the communications. You just need to know the tag ID (flow meter 127, for example). Object management services are built in."
If‘flow meter 127' is a new element in the plant, for example, a control engineer could easily add it to the class of flow meters in the repository that share common functions. And then, using a graphical workflow tool, insert it into a process workflow in the plant floor model. The SOA-enabled platform manages the device connection services to take care of all the technical details of integrating it into actual plant operations.
"This is very powerful. It provides huge productivity gains," says Martin. "It frees control engineers to focus on more advanced things, like plant optimization and performance."
Frank O Smith is a contributing writer to Control Engineering North America.