Exactly 40 years ago, the Modicon Corporation birthed Modbus, and the manufacturing world has never been the same. For the first few decades, manufacturers battled with competing physical layers standards and wiring schemes like RS232, RS485, Token Ring, Arcnet and others. For most of those decades, it was never certain which standard might ultimately win, so some manufacturers adopted ARCNET, some preferred Token Ring (IBM’s favorite), and others stayed with good old Modbus. Everyone fought the battle of integrating different physical layer standards in their plant; melding RS485 Modbus over there, with a little ARCNET over here, and some Token Ring and other now obscure standard. It was costly and laborious.

The New Puzzle: Standardized Software Interfaces

Now that we’ve adopted Ethernet, that hardware battle is over. But now there’s a new battleground where manufacturers are bleeding time and money; software interfaces. Manufacturers face a complex jigsaw puzzle of software standards used by devices and applications that are largely incompatible and difficult to cohesively assemble. Some software systems provide Application Programming Interfaces (APIs), some custom and some not. Many application developers love Web Services, especially HTTP with a Restful interface.  Some devices provide I/O Network interfaces (EtherNet/IP, PROFINET IO, Modbus TCP). And, of course, there are those out there who will only give up their obsolete OPC drivers when it’s pulled from their cold, dead hands.

This mish-mash of interfaces means that even though everything is largely on Ethernet, nothing meshes together easily. What often happens is that people who need the data create secondary, parallel applications and systems – often undocumented and unsupported – to work around what’s in place. More time lost, more information lost, costs rising – it’s a nightmare.

One Way to Solve the Puzzle: Web Services

One of the more popular mechanisms to interface applications is Web Services. It’s sometimes helpful to think of Web Services as merely some kind of API wrapped in HTTP. HTTP is the low-level communication service that supports much of what we do every day on the Internet. HTTP provides the basic service functionality (Get and Put) that moves generic data between two Internet systems without knowing anything at all about what it is moving.

A very popular architecture style to use with HTTP is RESTful. RESTful is a stateless mechanism for accessing resources at a destination node using the basic GET and PUT services of HTTP. It is stateless and completely generic, built for performance, reliability and the ability to access the kinds of information found on the Internet; XML and JSON objects.

An Alternative: OPC Unified Architecture (OPC UA)

Another way to standardize application interfaces is OPC UA, the successor to OPC (Open Process Control). It provides more open transports, better security, and a more complete information model than the original OPC (OPC Classic). UA provides a very flexible and adaptable mechanism for moving data between the kinds of controls, monitoring devices and sensors that interact with real -world data and enterprise type systems.

OPC UA is an open architecture, standard way for applications, controllers, sensors and other devices to interact. Data in an OPC UA device is discoverable. A client device can browse another OPC UA device to learn what data is available, its name, format and properties (meta-data characteristics). Once data required by an application is identified, it can be read, written or scheduled for transfer at some chosen frequency.

UA uses scalable platforms, multiple security models, multiple transport layers and a sophisticated information model to allow the smallest dedicated controller to freely interact with complex, high -end server applications. UA can communicate anything from simple downtime status to massive amounts of highly complex plant-wide information.

The Information Model is the foundation of OPC UA. An Information Model is nothing more than a logical representation applied to a physical process. An OPC UA Information Model can represent something as tiny as a screw, a component of a process like a pump, or something as complex and large as an entire filling machine. The Information Model is simply a structure that defines the component, devoid of any information on how process variables or meta-data within that structure are accessed.

Figure 1 is the Information Model for a curing oven. It details all the significant components of the oven and the information that is available. It details the logical structure of the data, its data types and the characteristics of each variable (properties in OPC UA terminology). Other than the structure implied by the way the information is related, there is no detail on how the data is stored or how it is accessed. In OPC UA, those mechanisms are distinct and separate from how the information is modeled.

Click Image to Enlarge

Figure1 - Sample Information Model for a Curing Oven

RESTful or OPC UA?

A prevalent question among manufacturing developers is “What’s the advantage of OPC UA over a RESTful interface?” That question usually comes from developers, and it’s easy to see why they ask it. A RESTful interface is straightforward, simple, fast and fun to develop. Integrating a standard like OPC UA, an open source package, or somebody’s toolkit just isn’t as appealing. Who wants to eat spinach when they can have ice cream?

RESTful’s weakness is that data is usually transferred as XML and JSON files devoid of type data and meta-data. There is no standardized mechanism for a client to obtain data schemas describing these files, access common services (Start Pump, Execute Recipe…etc.) or schedule data file transfers. RESTful is simple and straightforward at the expense of functionality.

Unlike RESTful, OPC UA provides more robust transports, encodings, security mechanisms, services and information modeling capabilities. OPC UA provides a more complete device data model and data values that, unlike ASCII files transferred by RESTful architectures, retain their original data type, precision and accuracy. 

The manufacturing floor is a much more structured and more permanent environment than the Internet, and doesn’t need the simplicity and quick, easy implementation that RESTful provides. The manufacturing floor needs consistent, standard mechanisms for accessing devices, describing data and its meta-data characteristics, and moving that data securely and reliably. OPC UA provides that in a more standard way than RESTful. 

RESTful is perfect for the Internet where applications come and go, requirements frequently change, and nothing lasts 20, 30 or even 40 years like Modbus. OPC UA is the right choice for valuable manufacturing applications that need superior data modeling, precise data representations, an extensive services infrastructure, and flexibility over the long term. 

For more information on OPC UA, a good place to begin is the book, OPC UA – Unified Architecture: The Everyman’s Guide to the Most Important Information Technology in Industrial Automation . You can get it at no charge by visiting https://www.rtautomation.com/rtafreegift/ . Just use “112” as the publication code.

ABOUT THE AUTHOR

John Rinaldi is Chief Strategist and Director of WOW! for Real Time Automation (RTA) in Pewaukee WI. With a focus on simplicity, support, expert consulting and tailoring for specific customer applications, RTA is meeting customer needs in applications worldwide. John is not only a recognized expert in industrial networks and an automation strategist but a speaker, blogger, the author of more than 100 articles on industrial networking, and six books including Industrial Ethernet,  OPC UA: The Basics , Modbus ,  OPC UA - The Everyman's Guide and ETHERNET/IP .

John Rinaldi

Real Time Automation

http://www.rtaautomation.com/contact-us/

https://www.linkedin.com/in/johnsrinaldi