OPC UA as the bridge to the enterprise

  • August 31, 2015
  • Real Time Automation, Inc.
  • Real Time Automation, Inc.
  • Feature

By John Rinaldi, Real Time Automation

If you’ve paid any attention at all to factory automation over the last few years, you’ve noticed the ever-increasing emphasis on connecting the factory floor to the Enterprise. There are many good reasons for this. Some of them are internal: efficiency, productivity, higher quality, and the like. Others are driven by external requirements.

In the old days (ten years ago?), the production department was a completely separate entity from the rest of the corporation. There was little to no electronic data transfer between the production machines and the company’s business systems. Production was a black box. Labor and raw materials went in one end, and finished product came out the other end. Most of the communication was carried out using paper: paper production reports, paper inventory levels, paper raw material usage, paper quality reports, etc.

Today, the aim is for instantaneous closed-loop communication. As units of product are consumed in the field, that information gets reported back to the machine that made it. The production machine checks its raw material inventory levels and on-hand finished product and schedules more production. It automatically transmits orders for any raw materials it needs from supplier machines. All automatic. All without human intervention.

That’s the plan anyway. In practice, it’s pretty hard to get there. We don’t have the luxury of ripping out all the production machines and replacing them with new, fully integrated machines with high-speed communication mechanisms. Instead, we have to do piecemeal implementations: upgrading and replacing systems one by one as time and funds allow. It’s a marathon, not a sprint, to the goal of fully automated systems.

The distinction that many people miss is that there’s a key distinction between the systems on the factory floor and in the Enterprise. This is the difference between what is called “loosely-coupled” systems and “tightly-coupled” systems. These aren’t new concepts, but I don’t think they’ve been examined in the light of the current trend toward the integration of factory floor and Enterprise systems.

Factory floor systems can be labeled tightly-coupled. Systems that use Profibus, Profinet IO, DeviceNet, EtherNet/IP, or any Modbus version have a very strict architecture. These are really just I/O producers and consumers, despite that the folks at the ODVA (Open Device Vendor Association) and PI (Profinet International) would have you believe otherwise.

Let’s look at the main characteristics of these Tightly Coupled systems:

  • A Strictly Defined Communication Model – The communication between these systems is inflexible, tightly regulated, and as deterministic as the communication platforms allow.
  • A Strictly Defined Data Model – The data (really I/O for most of these systems) model is predefined, limited and inflexible.
  • ·Strictly Defined Data Types – The data types transported by these systems are limited, predefined and supported by both sides. There is no ability to send data in an open and universal format.

Tightly-coupled systems provide much needed, well-defined functionality in a highly specific domain. Expanding operation to other domains or trying to provide more general operation is difficult. Making more generic data and functionality available requires significant programming resources that results in a very inflexible interface.

And that’s why tightly coupled systems are wrong for Enterprise communications. That is why I continue to be amused by the proponents of EtherNet/IP and Profinet IO as ways to exchange data with Enterprise systems. Can they be made to work for a specific application? Yes. But to get there requires a whole lot of effort and results in a difficult-to-maintain, inflexible system that is extremely fragile.

Loosely-coupled systems, on the other hand, provide exactly the right kind of interface for Enterprise communications. Loosely-coupled systems decouple the platform from the data, the data from the data model, and provide a much more dynamic mechanism for moving data.

Loosely-coupled systems have these kinds of characteristics:

  • A Widely Used, Standards-Based Transport Layer – Messages are transported in loosely-coupled systems with open, widely-implemented, highly flexible transports layers: TCP and HTTP.
  • An Open, Platform Independent Data Encoding – Data is encoded using an open standard data encoding like eXtensible Markup Language (XML) that can be processed by any computer platform.
  • A Highly Extensible Operating Interface – The interface between loosely-coupled systems is flexible and extensible. SOAP (Simple Object Access Protocol) is the main interface, and it provides a highly flexible mechanism for messaging between loosely-coupled systems.

Essentially, what I’ve described here is Web Services. Web Services is the backbone of everything we do on the Internet. It is extensible, flexible, platform independent – all required for the ever-expanding Internet.

The challenge is to how to best migrate the tightly-coupled factory floor architectures with the loosely coupled Web Services architecture of the Internet. Right now, because of the discontinuity between the factory floor and the Enterprise, opportunities to mine the factory floor for quality data, interrogate and build databases of maintenance data, feed dashboard reporting systems, gather historical data and feed enterprise analytic systems are lost. Opportunities to improve maintenance procedures, reduce downtime, compare performance at various plants, lines and cells across the enterprise are all lost.

The solution? It’s OPC UA. OPC UA can live in both the world of the factory floor and the Enterprise.

OPC UA is about reliably, securely and most of all, easily, modeling “Objects” and making those Objects available around the plant floor, to Enterprise applications and throughout the corporation. The idea behind it is infinitely broader than anything most of us have ever thought about before.

An OPC UA Server models data, information, processes and systems as Objects and presents those Objects to Clients in ways that are useful to vastly different types of Client applications. And better yet, the UA Server provides sophisticated services that the Client can use, like the Discovery Service.

UA is the future and the perfect technology to bridge the chasm between loosely and tightly-coupled systems.

John Rinaldi is Chief Strategist, Business Development Manager and CEO of Real Time Automation (RTA) in Brookfield, WI. John is a recognized expert in industrial networks and the author of five books, three on Industrial Networking.  


Learn More

Did you enjoy this great article?

Check out our free e-newsletters to read more great articles..