OPC UA – Application area and limits of the standard


The Open Platform Communications Unified Architecture (OPC UA) has established itself as the central communication standard in the industry. The standard has become indispensable, particularly in machine integration and connection. This article provides an insight into the strengths and weaknesses of OPC UA and shows the application area and limitations of the standard.


What is OPC UA?

Open Platform Communications Unified Architecture (OPC UA) is a collection of diverse specifications for the standardization of industrial communication. OPC UA was published in the fall of 2006 as the latest generation of the OPC Foundation specifications and has been continuously expanded since then. The uniform communication standard is used between several levels of the ISA95 model thanks to its advantages such as robustness and manufacturer independence.


A Wide Range of Specifications

The OPC UA standard consists of a variety of specifications, each of which describes a specific sub-function (e.g. for data access). Not all specifications have to be supported by OPC servers and clients. The comprehensive implementation of all specifications would actually be extremely time-consuming and resource-intensive, which is therefore not common practice. Rather, it is crucial to program only the relevant specifications depending on the application. For the connection of OPC servers and clients, it is important to know which specifications are actually implemented in the servers and clients.

Overview of OPC UA specifications


OPC UA – Area of Application in OT/IT Integration

OPC UA enables seamless communication between the production (Level 0), control (Level 1) and monitoring level (Level 2) during the operation and maintenance phase of an asset. The following figure illustrates the typical area of application of the standard in production based on the RAMI 4.0 model. With its features, OPC UA primarily aims to enable the seamless control of processes in a local network. An example of this is when a PLC (client) requests data from a central PLC or line controller (server), which then sends the processed data, such as commands (server), to a robot (client).

Application area OPC UA on the basis of RAMI 4.0


What is OPC UA Client/Server?

At its core, the standard is based on a client/server architecture. In this “one-to-one” topology, a client requests data from a server and the server responds with the requested data. While clients can interact with many servers simultaneously, servers can serve many clients. It is also common for a device to act as a client and a server at the same time. The client/server architecture is particularly suitable in automation scenarios in which direct synchronous communication (e.g. for closed-loop, command & control) between a few systems is required.

OPC UA Client Server Architecture


What is OPC UA Pub/Sub?

OPC UA Publisher/Subscriber (Pub/Sub), part 14 of the specification, was first published in 2017 as an addition to the original client/server-based communication model. Pub/Sub specifically addresses the scalability limitations of the client/server model and was developed to meet the growing need for efficient and lightweight communication mechanisms for IoT and cloud applications. In contrast to the synchronous request-response communication of the client/server model, Pub/Sub enables the asynchronous distribution of messages from one publisher to many subscribers. This reduces the communication effort and improves scalability and flexibility in large networks.


OPC UA Pub/Sub vs. OPC UA Monitor

There is often confusion between OPC UA Pub/Sub (part 14 of the specification) and the integrated subscription function in the OPC UA Client/Server model. This is a polling-based monitoring of variables in the OPC UA server. The client searches for changes on the server at defined intervals (synchronous communication) – not to be confused with the pub/sub architecture.


OPC UA and Security

In contrast to other protocols, the implementation of security measures in OPC UA is not necessarily required. This means that communication can also take place without security precautions. Ensuring secure data exchange using OPC UA depends on the correct configuration of servers and clients. Safety mechanisms can be flexibly combined, making OPC UA effective in different scenarios and safety-critical environments.

OPC UA security mechanisms

User security

OPC UA enables user security through the implementation of various security functions:

  1. User identity token: OPC UA supports different methods of user authentication for endpoints. This includes anonymous, username & password and certificate.
  2. Security modes: Various security modes such as “None”, “Sign” and “Sign & Encrypt” are available. These modes determine how authentication, confidentiality and integrity are integrated into the message exchange.
  3. Security guidelines: These define the cryptographic procedures for each security mode.


Application security

OPC UA enables application security through the following functions:

  1. Various endpoints: The server provides various endpoints as part of a secure client-server connection setup. Each endpoint is defined by security modes, security policies and supported user identity tokens.
  2. Security modes: The security modes determine the authentication, confidentiality and integrity in the exchange of messages between client and server. These include modes such as “None” (no security), “Sign” (signing) and “Sign & Encrypt” (signing and encryption).
  3. Guidelines for security measures: Security policies define the cryptographic procedures for each security mode. This defines the way in which the safety objectives are achieved in the specific safety mode.


Transportation security

OPC UA enables transport security through various mechanisms:

  1. Communication strategies: OPC UA offers two communication strategies – client/server and publisher/subscriber. Both make it possible to sign and encrypt messages to ensure authenticity and confidentiality.
  2. Security modes: OPC UA defines various security modes, including “None”, “Sign” and “Sign & Encrypt”. These modes determine how the messages are exchanged to ensure authentication, confidentiality and integrity.
  3. Security guidelines: The security guidelines define the cryptographic procedures for each security mode.


Advantages of OPC UA

OPC UA is ideal for applications with the following communication requirements:

  1. Highly complex data structures: The standard enables the transfer and management of highly complex data structures, including hierarchical data structures. This is particularly useful in industrial systems where the data is often complex and hierarchically organized.
  2. Secure communication: OPC UA offers a robust security layer that includes encryption and authentication. This ensures that data is transferred securely and that only authorized users and systems can access the information.
  3. Reliable and predictable communication: The standard ensures that communication between devices is reliable and predictable. This means that data can be transferred in real time without unexpected delays or losses.
  4. High-level services: OPC UA offers high-level services, including event notifications and complex method calls. This enables advanced functions such as sending notifications about status changes, triggering actions in remote devices and remote system maintenance.


OPC UA – Limits of the Standard

There are some disadvantages, particularly due to the specifications within the standard that have evolved over decades and the technical debt that has developed (“technical dept”):

  1. Interoperability: Although the standard is aimed at interoperability, problems arise in reality. Due to the large number of alternative specifications and implementations, different parts and versions of the standard are typically used in systems. Two systems are therefore only really interoperable with a great deal of luck.
  2. Complexity: OPC UA is a comprehensive and complex communication protocol. Implementation and configuration can be time-consuming, even if the vast majority of systems only use a small part of the standard. Due to this complexity, the use of OPC UA is often limited to levels 0-2 (see RAMI 4.0 above), as protocols such as MQTT fulfill the communication requirements of the higher levels (e.g. lightweight) much better.
  3. Overhead: Due to the comprehensive functionality and security features, the standard can generate an overhead in communication (in some cases over 95%). This is particularly evident in comparison to more lightweight protocols and has an impact on scalability. The standard has already responded to this problem with the addition of OPC UA Pub/Sub.


i-flow and OPC UA

In combination with OPC UA, the i-flow software offers considerable advantages in the factory, including:

  1. Interoperability: In practice, compatibility problems often arise because manufacturers from different areas and industries implement different parts of the OPC UA standard. Using i-flow, you can establish compatibility within the standard and with other technologies (e.g. MQTT).
  2. Data conversion: Not all systems in a factory use the standard. i-flow can convert data from non-OPC UA sources to the OPC UA protocol and vice versa. This ensures seamless integration of different systems.
  3. Edge analytics: Factories generate large volumes of data from numerous sources. i-flow enables the orchestration of data flows and automation functions to optimize data processing and analysis in edge and cloud environments.
  4. Data integration: The formatted data can then be forwarded in a consistent format to downstream business systems (e.g. ERP, MES) or databases.

Try it out now - free trial version

Experience the unlimited possibilities that i-flow offers by taking a test for yourself. 30 days free trial, on your systems.

Your question has not been answered? Make a non-binding inquiry now.

Our data policy applies.