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.
