OPC UA - OPC Unified Architecture

The OPC UA concept

The most fundamental difference from 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 any OPC-UA capable terminal device.

OPC UA is:

• Platform-neutral:
  No longer tied to Microsoft operating systems
  
  
• Scalable:
  System expansions are possible without installing additional OPC servers.
  
  
• Internet-capable
  Using TCP/IP as the basic protocol means OPC UA can be used across networks.
  
  
• Secure:
  OPC UA can if needed be secured using your own security mechanisms or SSL/TLS.

OPC UA - Transmission on the network level

OPC UA works on the client/server principle. To remote the OPC server out to the terminal device, standardized communication is required on the transmission path between OPC client and server.

To accomplish this TCP/IP was selected as the basic protocol and Ethernet as the physical standard.

OPC UA distinguishes between three transmission variants:

• HTTP
  HTTP requests are used to send and request data. Information is sent SOAP resp. XML formatted.
  TCP server port is 80.
  
  
• HTTPS
  The same applies to HTTPS, except that HTTPS is SSL/TLS encrypted.
  The TCP server port is 443.
  
  
• UA TCP Binary
  The binary variant eliminates the overhead resulting from the additional XML tags. Instead there is a very lean protocol which regulates data exchange. This makes data exchange much faster.
  TCP server port is 4840.

Even on the network level you can see the highly flexible access possibilities of OPC UA.

Protocol and application level

Also new is that OPC UA permits not only access to individual items but also to complex data structures. In addition OPC UA can be used to invoke programs and functions on the terminal device.

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

THe OPC UA server

The main feature of OPC UA is, as already explained, that the OPC server is a component of the destination terminal device. Even though OPC UA offers a great variety of possibilities, not every OPC server has to support the entire bandwidth. It’s enough if the server can handle whatever portion is needed for the application.

The OPC server summarizes which possibilities and protocol variants it supports in the form of standardized type information.

The OPC UA client

In contrast to the OPC UA server, the OPC UA client should be able to support as many of the different variants as possible. Only then can a high degree of compatibility with the greatest possible number of terminal devices be achieved.

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

Many clients support both OPC UA and the original OPC standard, so that mixed operation is possible. There are also some suppliers of OPC UA gateways who integrate terminal devices which do not inherently 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 both the traditional client/server communication and the publish/subscriber model. OPC-UA-Pub/Sub does this by using the mechanisms from MQTT.

In terminal devices which use the publish/subscriber procedure of OPC UA, the OPC server has an added MQTT client service. Even though it is somewhat misleading, the designation OPC server is retained.

OPC client and OPC server can send data to a broker via Publish as well as subscribe to data using Subscribe.

Now process data can be passed to a variety of terminal points with little effort.

Also new in the OPC-UA-Pub/Sub release is the ability to use UDP as a base protocol. Since UDP is faster than TCP due to the lower overhead and the connectionless communication using datagrams, using UDP is especially advantageous for applications which rely on short response times.

Possible application cases

In the original OPC applications it was usually the case that an OPC client as central control system monitored and when needed controlled the respective terminal devices. But the control system itself was almost always accessible to the user via monitor and keyboard.

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

• Terminal device to terminal device
• Terminal device to database
• Terminal device to cloud

This makes OPC UA much more flexible than traditional OPC.