There’s a lot of talk today about the integration of the “Enterprise” and the “Factory Floor.” I’ve enjoyed a lot of this discussion. Rockwell has a great picture of something they call the “Convergence Man.” It’s a guy split in two with a hardhat and factory smock on his right side and the more formal shirt and pants of an IT guy on his left side.

There’s also a bunch of new terms being thrown around like “Digital Factory” and “Integrated Intelligence.” But however you look at it, there’s more and more talk (and action) toward linking the factory floor with systems not directly involved in factory floor control. The Enterprise systems can be big and sophisticated like ERP and MES systems or they could be as simple as a recipe manager on your server that downloads 20 tags once a day.

No matter what you’re doing, there’s a key distinction between the systems on the factory floor and in the Enterprise that not many people understand. This difference is between what I call “loosely-coupled” systems and “tightly-coupled” systems. I don’t think these are new concepts but I’m not sure they’ve been examined in the light of the current trend toward the integration of factory floor and Enterprise systems.

I would argue that factory floor systems should 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 I/O systems, as much as the folks at the ODVA 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.

We could look at any of the factory floor protocols but let’s take EtherNet/IP as an example. EtherNet/IP has a very strictly defined communication model. A Scanner uses a very precise communications model in communicating with its Adapters. The Adapters are preconfigured, all data exchanged is predefined and nothing changes without human intervention. The Data exchanged is part of the Adapters predefined Object Model and the data is formatted in a way supported by both the Scanner and the Adapter.

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.

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-couple 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 how to best connect the tightly coupled factory floor architectures with the loosely coupled web services architecture of the Internet. Rockwell has its Factory Talk product line. The ODVA promotes EtherNet/IP. PI promotes Profinet IO.

Any of these can be made to work as I have described earlier but the EtherNet/IP and Profinet IO type protocols result in that dreaded brittleness that costs too much time and money over time. These approaches take massive amounts of human and computing resources to get anything done. And in the process we lose lots of important meta-data, we lose resolution and we create fragile systems that are nightmares to support.

And don’t even ask about the security holes they create. These systems were not designed to be highly secure.

These systems are a fragile house of cards; they need to be knocked down.

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? I’ve thought a lot about it and I think it’s OPC UA because UA can live in both the world of the factory floor and the Enterprise.

OPC UA is about reliably, security, 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.

It all starts with an Object. An Object that could be as simple as a single piece of data or as sophisticated as a process, a system or an entire plant.

It might be a combination of data values, meta-data and relationships. Take a Dual Loop Controller. The Dual Loop Controller object would relate variables for the setpoints and actual values for each loop. Those variables would reference other variables that contain meta-data like the temperature units, high and low setpoints and text descriptions. The Object might also make available subscriptions to get notifications on changes to the data values or the meta-data for that data value. A Client accessing that one object can get as little data as it wants (single data value) or an extremely rich set of information that describes that controller and its operation in great detail.

OPC UA is, like its factory floor cousins, composed of a Client and a Server. The Client device requests information. The Server device provides it. But as we see from the Loop Controller example, what the UA Server does is much more sophisticated than what an EtherNet/IP, Modbus TCP or Profinet IO Server does.

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.

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