How OPC UA Creates Interoperability and Gives Data Context

A complementary tool Another reason for the growing popularity of OPC UA is its position in the control hierarchy. “OPC UA is located above fieldbus systems and is thus fieldbus neutral,” notes Trask. “It’s considered to be a binding element between fieldbus technologies and is therefore supported by all the major fieldbus organizations.”

The OPC Foundation does not view OPC UA as a technology competing with other industrial communication methods. “You can’t compare OPC UA to a fieldbus or something like MQTT (message queuing telemetry transport),” says Trask. “It has a different focus—it’s more of a tool to organize an architecture.”

For this reason, Emerson’s Fayad thinks that OPC UA will continue to gain momentum. “Other protocols have their specific uses and needs,” he explains, “but they don’t have the end-to-end applicability of OPC UA. Foundation Fieldbus, along with other industrial protocols, can be great to connect field devices and automation equipment in the plant. However, it lacks the ability to connect with cloud solutions. And IT protocols like MQTT lack the ability to scale all the way down to field devices.”

OPC UA can bridge this gap through its publish/ subscribe specifications. These specifications (added in 2018) are an example of how OPC UA provides the flexibility to adapt to networking trends while maintaining the interoperability its known for, according to Daymon Thompson, U.S. software product manager at Beckhoff Automation. “OPC publish/subscribe offers great new topology options,” he says. “One of those is the ability to transport OPC data over the MQTT protocol.” Using a message broker, rather than a client/server architecture, this simplifies the transmission of OPC traffic to web-based applications and cloud services and mitigates the potential for interruption of field device operations.

“In the early days of IIoT, engineers often wondered whether they should use OPC or MQTT as the transport,” recalls Thompson. “This really isn’t the question, at least not any longer. OPC gives the necessary namespace and unified-type system that case communications don’t provide.”

Besides supporting MQTT, OPC UA’s publish/ subscribe also allows the transmission of data via UDP (user datagram protocol), a communications protocol often used for low-latency connections between internet applications.

OPC UA origins
The story of OPC UA begins in 1996, before the days of unified architecture—back when OPC was still the acronym for OLE (object linking and embedding) for process control. At that time, OPC defined an interface that allowed automation devices using PLC-specific protocols, such as Modbus and Profibus, to share information with humanmachine interfaces (HMIs) and supervisory control and data acquisition (SCADA) systems.

The interface permitted the exchange of data formatted in common formats: current data access (OPC DA), alarm and event messaging (OPC AE), and history data access (OPC HDA). “There were other specifications more for niches, but these three were the most widely adopted,” says Tom Burke, director of global standards at the CCLink Partner Association and former president of the OPC Foundation. Today, these specifications are known collectively as OPC Classic.

Before the OPC Classic formats came on the scene, automation vendors had to develop custom drivers to establish communications between their controllers and other devices. “Vendors also had the additional costs of updating and supporting their drivers,” recalls David Boeldt, product manager for controls at Bosch Rexroth. When OPC DA 2.0 came along, however, it eliminated this expense by providing a standard interface between the controls and HMIs.

Unfortunately, OPC DA and the other OPC Classic formats were wedded to Microsoft technology. Besides OLE, the underlying technologies included component object model (COM) and distributed component object model (DCOM). Not only was configuring and managing DCOM difficult, but OPC was primarily suited to Windows- based platforms. “This limited OPC’s adoption,” notes Burke.

By the early 2000s, the technological landscape had changed. Automation vendors were incorporating Ethernet communications into their products. Burke adds, “Embedded computing platforms became prevalent, as did new operating systems.” Hence, the need for interoperability intensified further.

In response, the OPC Foundation developed its unified architecture and released OPC UA in 2008. “The shift from OPC’s original OLE-based technology to the unified architecture was monumental,” observes Thompson at Beckhoff Automation. “It allowed OPC technology to break free from the large constraints of the original OPC.”

This result was a platform-independent, service- oriented architecture that puts the functionality of the OPC Classic specifications into a scalable and extensible framework. “OPC UA works with multiple operating systems, supports the configuration of complex data structures, and provides for advancements in security,” says Bosch Rexroth’s Boeldt.

The unified architecture had two important technical ramifications. First, it switched OPC from being a tag-based system to being a modelbased system. “Instead of looking at device tags, UA looks at an information model,” explains Clark at the OPC Foundation. “So, you’re getting not only a value from a device, but also the metadata that accompanies that value.”

The second ramification is that security was included from the very beginning, rather than added as an afterthought. In addition to encrypting data, OPC UA has two levels of authentication. The first is user authentication, which takes place at the application level. “There, the server can verify the identity of each client that is trying to communicate—ensuring that unapproved devices or users cannot establish a connection,” explains Garret Schmidt, senior product manager for communications interfaces at Phoenix Contact. Once a secure connection is established, the applications themselves are then authenticated to permit them to exchange data.

From sensors to the cloud
OPC UA reached another milestone in its life in 2018, when the OPC Foundation launched its Field Level Communications (FLC) initiative. Here, the goal is to extend UPC UA into the fi eld level by developing the OPC UA framework for Field eXchange (OPC UA FX). The result will be a uniform backbone for transmitting information from sensors to the cloud using an MQTT broker.

The OPC Foundation released the first of the necessary FLC-related specifications in late 2020. This initial release focuses on controller-to- controller communications to exchange process data and configuration data using OPC UA client/server and publish/subscribe extensions in combination with peer-to-peer connections and basic diagnostics. Not only do these initial specifications permit the building of prototypes, they also lay the foundation for the development of specification enhancements for controller-to-device and device-to-device use cases.

The working groups at OPC Foundation are tackling such technical issues as determinism, motion, instruments, and functional safety. One of these groups is also collaborating with the Mechanical Engineering Industry Association in Europe to develop an OPC UA information model for communications for robotics. Another collaborative effort underway since May 2020 is OPC’s Motion Working Group. This group has been working with ODVA and Sercos International on an architecture and common information model for motion devices such as controllers, drives, encoders, and power supplies. “This new motion technology will be initially published as OPC UA Motion, with subsequent updates to the Sercos technology and ODVA’s CIP (common industrial protocol) Motion technology for EtherNet/ IP,” says Dr. Al Beydoun, president and executive director of ODVA (a global trade and standard development organization whose members are industrial automation device suppliers).

The work ODVA is currently focusing on with the OPC Foundation is the CIP Motion companion specification, which will map CIP objects to the appropriate OPC UA information models and profiles, and vice-versa. Once developed, the specification will be used to reduce the effort necessary to extract data and the proper context and semantics (i.e., meaning) from CIP devices for trend analyses in higher-level systems.

Preserving the past
Companion specifications for mapping existing protocols like CIP Motion not only build in flexibility and interoperability, but also clear a path for modernization without replacing existing automation.

There are good reasons for continuing to use existing protocols and interfaces with OPC UA. “For example, some applications require very high, deterministic performance,” says Burke. He points to Mitsubishi Electric’s CC-Link IE TSN (time-sensitive networking) as an example of a protocol that suits such applications yet communicates using the OPC UA interface. “Layered solutions can still access information from these control networks with OPC UA for analytics,” he adds.

Another example is Profinet. A companion specification for this protocol describes a standardized OPC UA object model that allows Profinet devices—made by a variety of manufacturers— to transfer data to higher-level systems. “Standardization makes information collection significantly easier, regardless of the device manufacturer,” says Michael Bowne, executive director of PI North America.

The companion specification allows users to exploit the complementary relationship that exists between Profinet and OPC UA to streamline the transformation of data into information. “Each protocol is purpose-built for a particular task—one that each performs well,” says Bowne.

The symbiotic relationship between OPC UA and existing protocols can be seen in its relationship with Profinet. For example, Profinet offers the precision and determinism necessary to transfer bits and bytes of data quickly and reliably among controllers and devices. Meanwhile, OPC UA contributes machine-readable information models, built-in security, flexible architectures, and rich semantics necessary for moving contextualized information to and from higher-level systems to support industry’s digital transformation.