OPC-UA: the Flow of Data

In our previous article, we introduced OPC-UA (Open Platform Communication — Unified Architecture), a platform-independent, machine-to-machine communications architecture. In that article, we took a deep dive into the core of OPC-UA: its information model. The information model takes an object-oriented approach to structuring complex data to allow communication of that data between different machines.

In this article, we will be examining the more functional parts of the OPC-UA specification — the models and services it offers and how the OPC-UA data is communicated.

Many of the models within the OPC-UA specification build upon OPC Classic, with OPC-UA essentially supplanting this. Each model contains a number of services that the OPC-UA clients and servers can invoke to perform various functions. A few of the key models defined by OPC-UA, along with some of the functionalities they offer are:

Data Access — Data Access was the original OPC Classic specification, and contains services concerned with locating OPC-UA devices on a network, browsing OPC-UA address spaces, reading and writing of data, and monitoring for changes of nodes.

Alarms and Conditions — based on the original OPC Alarms & Events specification, the following capabilities are provided: receiving and responding to alarms, receiving and filtering audit events.

Historical Access — based on the original OPC Historical Data Access specification, functionality for reading, updating, and subscribing to historical data, as well as events, is provided.

To communicate data between machines, the machines need to agree on a communication protocol: a ruleset which defines how data is structured and how it is converted into digital signals to allow for the end-to-end transfer of the data.

The OPC-UA specification allows for two different kinds of communication: the client-server model and the publish-subscribe model. Each model offers different communication protocols to fit the use case.

Firstly, we will take a look at the client-server model — a communication model which is ubiquitous in the IT industry and one that will likely be familiar. The client-server model is the preferable method of communication when asynchronous communication of large amounts of data is required.

Firstly, we will define the client and the server. The OPC-UA client is the side of OPC-UA communication that initiates the communication session. OPC-UA clients are capable of searching out and discovering OPC-UA servers through various services. They can configure the servers to deliver specific pieces of data when and how they want it.

The OPC-UA server is the side that holds the data and provides it to the client. OPC-UA servers are scalable: devices as small as sensors with only a few data points, to large machines with thousands of data points can all be their own OPC-UA server.

Additionally, a machine can also act as an aggregator by hosting both an OPC-UA server and its own OPC-UA client. Its client can connect to all of the OPC-UA servers hosted by each individual device in the system and share the same data on its own server, meaning that any users only have to connect to this single server to access data from throughout the system.

To establish a client-server connection, numerous messages are exchanged between the client and the server. Firstly, a Hello message is sent from the client to the server, and the server responds with an acknowledgement message. After this, the client sends a request to open a secure channel, before receiving a response from the server. Then, the client can create a communication session with the server.

Once the communication is set up, the client can invoke the Browse services to establish which nodes are within the address space of the server, and the Read and Write services to read and write data to these nodes.

All of the services involved in client-server communication are independent of the transport protocol used. Three kinds of protocol bindings can be used with the client-server model of OPC-UA:

1. UA TCP (Transmission Control Protocol): information is binary encoded and transported over UA TCP.
2. Hybrid: information is binary encoded and transported over TLS
3. Websocket: information is JSON encoded and transported over TLS.

The first protocol binding uses TCP, perhaps the most common communications protocol of the Internet protocols suite. It is a connection/session-based protocol that establishes a low-level communication channel between a client and a server. This protocol mostly negotiates buffer sizes so that both the client and server understand the byte limitations of each other. As a communications channel is set up between the client and the server, there is acknowledgement of every message.

The other two protocol bindings both use TLS transport — this means that communication can occur over HTTPS or other protocols which can use TLS.

It can be seen above that two different kinds of encoding are used in the OPC-UA specification. Encoding is the process of mapping the OPC-UA request/response data in a defined way to convert it into a stream of bytes that can be transmitted as digital signals.

The first two protocol bindings use binary encoding. With binary encoding, the data is mapped into a series of compact binary data representations, following the IEEE binary encoding standard. These representations are compact and use fewer bytes than most encoding schemes to make data transmission more efficient.

The third protocol binding uses JSON (JavaScript Object Notation) encoding. JSON is format for structuring/transmitting data that prioritises human readability.

The second form of data access offered by OPC-UA follows the publish-subscribe model. This model differs to the client-server model in that consumers of data do not have to send requests to receive data. Instead, data consumers subscribe to be notified of changes to subsets of data, and only if they are subscribed to that specific subset of data do they receive an update. Publish-subscribe is the preferable communication method when synchronous communication of a small amount of fixed data is required.

Once a session has been created in a similar way to the client-server communications, the client can invoke the Create Subscription service to create a subscription, followed by the Browse service to browse the available nodes of the server’s address space. Once the client knows which nodes it wishes to subscribe to, it invokes the CreateMonitoredItem service for each node. The client forms a Publish request which adds these monitored nodes to a Publish token queue. The server is now aware of all of the nodes that the client wishes to be informed about if the values change. When the value of a monitored node changes, the server forms a Publish response and sends this to the client.

Again, multiple protocol bindings exist, each with its own primary use case:

1. UADP: binary-encoded message running over UDP (User Datagram Protocol)
2. JSON over MQTT, typically used in the cloud
3. UADP over TSN, used for field-level communication, UA binary, UDP based

The first protocol binding uses UDP — this is a key communication protocol of the Internet protocol suite, used often instead of TCP when a connectionless form of transmission is preferred — the publisher does not require any acknowledgement of the subscribers receiving the data. Its low overhead makes it suitable for the multi-cast nature of the publish-subscribe model.

Interestingly, the second protocol binding for publish-subscribe communication uses MQTT, which is often considered to be a rival communications architecture when discussing the future of Industry 4.0 communication. However, whilst OPC-UA is designed more as a way of structuring data, MQTT is more focused on transmission of data. This protocol binding is generally used for cloud-level communications.

The third protocol binding, UADP over TSN (Time-Sensitive Networking) offers a real-time communication solution over OPC-UA. This final protocol binding is used when determinism is required — i.e. a guarantee that a communications message will arrive at the target within a given timeframe. As such, it is generally used for field-level communications.

The publish-subscribe model differs dependent on the protocol binding chosen. For the one-to-many and deterministic use cases, UADP will be used, and communication occurs directly between the publisher and the subscriber. However, for cloud-level communication using MQTT, communication occurs over an intermediary, known as a broker.

In this article we examined the options for transmitting our OPC-UA structured data through a variety of communication protocols either using client-server communication or publish-subscribe.

In the automation industry, encoding and communication protocols are only half of the story when it comes to data transmission. As we enter an increasingly connected world, more and more priority is placed on how we can protect this data from prying eyes. In the next article, we will explore how OPC-UA tackles data security with its secure-by-design approach.