OPC UA as the Architecture for IT/OT Convergence

The challenge today is to how to best migrate the tightly-coupled factory floor architectures with the loosely coupled Web Services architecture of the IT world. 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 unavailable. Opportunities to improve maintenance procedures, reduce downtime, compare performance at various plants, lines, and cells across the enterprise are all lost. But there is a reliable, highly secure and reliable solution: OPC UA.

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 and the cloud. 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 such as efficiency gains from linking internal systems with important vendors and priority customers.

In the old days (ten years ago?), the production department was a 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 the 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 rather 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 must 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 (OT) and in what’s known as IT. This difference can be described as “loosely-coupled” systems vs “tightly-coupled” systems. These aren’t new concepts, but they haven’t been examined in the light of the current trend toward the integration of factory floor and Enterprise systems (aka IT/OT convergence where OT means Operational Technology).

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 what some of the folks at the trade organizations sponsoring these systems might have you believe.

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 and cloud communications. It’s often amusing to see the proponents of OT Technologies like EtherNet/IP and Profinet IO say that they can be used to exchange data with Enterprise and cloud 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 and cloud 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 are 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 IT and 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 nonexistent. 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 (Figure 1).