This post was authored by John Rinaldi, president of Real Time Automation. Real Time Automation provides hardware and software systems that deliver data from the factory floor, from building systems or from remote devices to controllers and enterprise systems.

There is a lot of talk about the integration of the “enterprise” and the “factory floor.” I have enjoyed a lot of this discussion. One vendor has a great picture of something they call the “convergence man.” It is 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 are also new terms being thrown around like digital factory and integrated intelligence. However you look at it, there is 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 enterprise resource planning (ERP) and manufacturing execution systems (MES), or they could be as simple as a recipe manager on your server that downloads 20 tags once a day.

No matter what you are doing, there is a key distinction between the systems on the factory floor and in the enterprise that many people do not understand. This difference is what I term “loosely coupled” and “tightly coupled” systems. I do not believe these are new concepts, but I also do not think they have 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 strict architecture. These are really I/O systems as much as the folks at the trade associations would have you believe otherwise.

Let’s look at the main characteristics of these tightly coupled systems:

  • A Strictly Defined Communication Model. The communications between these systems are 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 for bounded applications, limited, and inflexible.
  • Strictly Defined Data Types. The data types transported by these systems are limited, predefined, and supported at both ends of the network. 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 strictly defined communication model. A scanner uses a 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 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 an inflexible interface.

And that is why tightly coupled systems are wrong for enterprise communications. I continue to be amused by the proponents of the industrial network protocols as a means 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, loosely coupled systems 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:

  • Widely-used, Standards-based Transport Layer. Messages are transported in loosely coupled systems with open, widely implemented, highly flexible transport layers, including TCP and HTTP.
  • 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.
  • Highly Extensible Operating Interface. The interface between loosely coupled systems is flexible and extensible. Simple Object Access Protocol, or SOAP, is the main interface, and it provides a highly flexible mechanism for messaging between loosely coupled systems.

Essentially, this 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. Many automation vendors have their own proprietary software, messaging, and data models and in addition industrial network trade associations promote transporting this information over their industrial network protocols.

Any of these can be made to work as I have described earlier, but the industrial automation control 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 do not 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.

Due to the discontinuity between the factory floor and the enterprise, the 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 plant, line, and cell performance at various plants across the enterprise are also lost.

What is the solution? After much thought, I believe it is OPC Unified Architecture (UA), because UA can live in 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.

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, for instance, 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, like its factory floor cousins, is composed of a client and a server. The client device requests information. The server device provides it. As we see from the loop controller example, what the UA server does is much more sophisticated than what an industrial network protocol can accomplish.

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 UA is the future and the perfect technology to bridge the chasm between loosely and tightly coupled systems.

About the Author
John Rinaldi is president of Real Time Automation in Pewaukee, Wisc. Real Time Automation provides hardware and software systems that deliver data from the factory floor, from building systems or from remote devices to controllers and enterprise systems. Rinaldi has a BS EE and MS in Computer Science. With 30 years of Industrial, Building Automation, and SCADA experience, Rinaldi understands the unique challenges of data collection in these environments.

Connect with John

A version of this article also was published at InTech magazine

Pin It on Pinterest