OPC UA – OPC Unified Architecture

The concept of OPC UA

The most fundamental difference to the original OPC standard is that the OPC server no longer has to be installed on the client side, as an additional driver, so to speak. Instead, the associated OPC server works in every OPC UA-capable end device.

OPC UA is:

• platform-independent:
  no longer tied to Microsoft operating systems
• Scalable:
  System extensions are possible without installing additional OPC servers.
• Internet-enabled:
  With TCP/IP as the basic protocol, OPC UA can be used across networks.
• Secure:
  OPC UA can be secured using its own security mechanisms or SSL/TLS if required

OPC UA – Transmission at network level

OPC UA works according to the client/server principle. In order to outsource the OPC server to the end device, standardized communication is required on the transmission path between the OPC client and server.

To ensure this, TCP/IP was chosen as the basic protocol and Ethernet as the physical standard.

OPC UA distinguishes between three transmission variants:

• HTTP
  Data is sent or requested via HTTP requests. Information is transmitted in SOAP or XML format.
  TCP server port is 80.
• HTTPS
  The same applies to HTTPS as to HTTP, but HTTPS is SSL/TLS-encrypted.
  TCP server port is 443.
• UA TCP Binary
  The binary variant dispenses with the overhead caused by the additional XML tags. Instead, there is a very lean protocol that regulates data exchange. This means that data exchange is significantly faster.
  TCP server port is 4840.

Even at the network level, OPC UA thus offers very flexible access options.

protocol and application level

What is also new is that OPC UA also allows complex data structures in addition to access to individual items. In addition, programs and functions can be called up via OPC UA on the end device itself.

The original standards OPC DA, EA, HDA and DX have been integrated into OPC UA as possible application options.

The OPC UA server

As already explained, the main feature of OPC UA is that the OPC server is part of the end device to be addressed. Even though OPC UA offers a wide variety of options, not every OPC server has to support the entire bandwidth. It is sufficient if the server masters the subset required for the application.

In the form of standardized type information, the OPC server summarizes which options and protocol variants it supports.

The OPC UA client

In contrast to the OPC UA server, the OPC UA client should support as many of the different variants as possible. This is the only way to ensure a high degree of compatibility with as many end devices as possible.

The OPC UA client can call up the type system information from the OPC UA server, which records which transmission methods, items, variables, objects, functions, etc. are available. This significantly simplifies the integration of new end devices and the associated configuration effort.

In addition to OPC UA, many clients also support the original OPC standard, so that mixed operation is also possible. There are also some providers of OPC UA gateways who integrate end devices that do not support OPC UA into OPC UA applications.

OPC UA Pub/Sub

In 2018, the OPC Foundation published a new release of the OPC UA standard. OPC UA Pub/Sub is fully compatible with OPC UA, but supports the publish/subscriber model in addition to classic client/server communication. To do this, OPC UA Pub/Sub uses the mechanisms of MQTT.

In end devices that use the Publish/Subscriber method of OPC UA, the OPC server has been expanded to include an MQTT client service. Even if the language is somewhat misleading, the term OPC server is retained.

OPC client and OPC server can both send data to a broker via publish and subscribe to data.

In this way, process data can be passed on to a large number of end points with little effort.

Another new feature of the OPC UA Pub/Sub release is that UDP is also permitted as the basic protocol. Since UDP is faster than TCP due to lower overhead and connectionless communication via datagrams, the use of UDP is particularly advantageous for applications that depend on short response times.

Possible use cases

With the original OPC applications, it was usually the case that an OPC client, as the central control system, monitored and, if necessary, also controlled the terminal devices involved. However, the control system itself was almost always accessible to the user via screen and keyboard.

In addition to this classic variant, OPC UA also supports the following communication models (without involving a control system):

• terminal to terminal
• terminal to database
• end device to cloud

This makes OPC UA significantly more flexible than classic OPC.