When it comes to the future of automation, the development of IIoT networks, and smart factories, connectivity plays a key role. Large network structures in which individual nodes are connected and exchange data with each other are increasingly replacing rigid, hierarchical automation pyramids with dividing layers.
In order to realize this intelligent networking, the devices must be IIoT-capable. They must therefore meet certain requirements, such as standardization, scalability, compatibility with IT and OT systems, and the ability to interoperate. It is also very important that they guarantee secure communication.
Various tcp-based communication protocols—including MQTT, OPC UA, AMQP, and REST API—enable smart communication all the way to the cloud. In our multi-part series of blog articles, you can find out more about the characteristic features of these IIoT communication protocols and in which use cases they are particularly suitable. The second part of this article series focuses on OPC UA.

What is OPC UA and how does it work?

OPC Unified Architecture (OPC UA) is a platform-independent, service-based architecture. A successor to Classic OPC, the aim of OPC UA was to eliminate the drawbacks of Classic OPC, especially its dependencies on Microsoft and COM/DCOM. The OPC Foundation, the same organization that developed Classic OPC, is also responsible for the development and management of OPC UA. The first specification release took place in 2008 and was IEC-certified (IEC 62541). OPC UA, referred to as an architecture rather than a communication protocol, delivers a complete ecosystem for implementations. This ecosystem is so flexible that OPC UA will be able to bind and use new technologies within the existing system as future technologies emerge. For example, OPC UA pub/sub was released in 2018 (until which OPC UA was primarily dependent on request/response). A great deal of attention is currently being paid to TSN (Time-Sensitive Network) standards, which enable deterministic timing behavior. This motivation to optimize processes in terms of the time they take is implemented through the continuous efforts of the OPC Foundation in various technical and marketing activities. One essential aspect of OPC UA is that there are no device description files. Each device has all the information it needs and is not dependent on external files for communication, identification, or data access.

But that’s not even the most fascinating part of it. The most important aspects that OPC UA offers to industry are data modeling, information models, and the activity of consortia, such as technical working groups, which are working on the cross-industry harmonization and communication of all devices. The basic elements of OPC UA data modeling are the nodes and references. Each data unit is called a node and all nodes connect through references. There are various types of nodes and references. For example, a node can have the type Object, Variable, Method, ObjectType, or DataType. The references also have types, but are combined at a higher level into hierarchical and non-hierarchical groups. The nodes and references are within an address range and all nodes can be accessed through “node IDs”. The node ID corresponds to an address where the appropriate node (data information) exists.

Information Models

The information models are building blocks for the OPC UA application. They provide standard node definitions that enable better harmonization between devices. There are several information models. The OPC Foundation defines basic models, such as Data Access (DA), Historical Data Access (HDA), Alarms and Conditions, and Programs, that provide information about what functions an OPC UA application supports. DA is the standard access to process and parameter data. HDA adds functions for storing multiple measurements from the same node for statistical purposes. Alarms and Conditions make it possible to send events in case of emergency notifications, and Programs allow simple state machines to be defined.

The scalability of OPC UA makes it possible to implement only the data access information model that is particularly useful for devices with a limited amount of memory and computing power. In addition to these four information models, the OPC Foundation has created another model called the Device Integration (DI) information model, which forms the basis for numerous other information models of technical working groups such as FDI, PLCopen, AutoID or OPC UA for IO-Link. These information models make a significant contribution to device harmonization because they implement the same information on the same access points (NodeIds). This means that it is very easy to replace one device with another, even if it is from another vendor.

OPC UA pub/sub:

The pub/sub extension in OPC UA has its own message format, i.e. NetworkMessage, and uses different communication protocols than the client/server implementation. It uses MQTT, AMQP, OPC UA UDP, and OPC UA Ethernet. What is particularly appealing is that these four protocols are located on three different TCP/IP model layers—the network layer, transport layer, and application layer.

Figure 1 juxtaposes the two patterns “Request/Response” and “Pub/Sub”. The OPC UA application contains both an OPC UA server and an MQTT client and communicates with two parallel TCP connections. It either publishes data to the MQTT broker or receives a request from the OPC UA client. The application cannot be prevented from communicating with them in parallel. This requires only two TCP connections. The advantage is that the data is stored only once, but is transmitted on two separate channels.

Interoperability of OPC UA

OPC UA has many syntactic and semantic interoperability features. Syntactically, all devices use the same types and services for communication. They also use information models, all stored in the same format—in a nodeset file. The nodeset file contains a collection of all nodes and references defined in addition to the basic modeling rules in OPC UA, and delivers the data defined in an information model in machine-readable format. The nodeset files deliver both syntactic and semantic interoperability. From a syntactic point of view, these files have the same structure and can be parsed from any OPC UA application. From a semantic point of view, many working groups are working to harmonize the names of their parameter and process data, their method availability, their events, etc., so that different devices resemble each other and behave similarly. One example is the AutoID information model, which aims to unify all identification devices such as RFID readers and bar code readers. In addition, they may have vendor-specific individual parameters, but should build on a common foundation. This simplifies the implementation of the OPC UA client, because no link is required for individual bespoke versions. In short, OPC UA is capable of machine-machine interactions. By using visualization tools to represent the information model, it is also interoperable from person to machine.

Real-time Behavior of OPC UA

After expanding into the pub/sub world, OPC UA had opportunities to compete in real-time. With its request/response pattern, it could hardly have kept pace with MQTT and AMQP.

Security of OPC UA

OPC UA follows the Web Service Security Specifications for its WS Secure Conversation and creates a binary variant for the TCP binary path called UA Secure Conversation. In addition, it provides security mechanisms such as user name/password, X.509 certificates and tokens issued, as well as message-auditing capabilities to log changes by clients, tracking the value updated and time of change.

Implementation of OPC UA

The only protocol that can be extended (due to its many functions) is OPC UA. In addition to standard security scaling, which only means turning off security (and is not recommended for OPC UA or other protocols), OPC UA can be scaled in at least two ways. Selecting a suitable OPC UA profile for small, embedded devices (Nano Embedded Device Server Profile) will limit the number of TCP connections to one. Additionally, the application can be restricted to basic information models such as Data Access (DA).

Effort required:
OPC UA is also complex in terms of its concept, especially when it comes to building a complete information model. We therefore recommend that you use existing information models that match the use case. From a protocol and security perspective, we also recommend that you use and build on an existing library.

Application of OPC UA

OPC UA is particularly suitable for applications where shared data needs to be standardized and harmonized, where devices need to be easily interchangeable using the same information models, where events, alarms and historical data are useful, and even where a mix of request/response and pub/sub communication is used. No wonder OPC UA has been installed in millions of machines and factories worldwide, from the logistics industry to the automotive industry and chemical industry, etc.