OPC UA (Open Platform Communications Unified Architecture) is an established standard for industrial communication. The standard has become firmly established in machine networking and automation in particular. But how does this standard fit into modern architectures such as the Unified Namespace (UNS)? In this article, we take a practical look at OPC UA in the Unified Namespace, clarify its strengths and weaknesses and show where it makes sense to use it – and where not.
What is OPC UA?
Open Platform Communications Unified Architecture (OPC UA) is a standardized communication protocol developed by the OPC Foundation. Since its introduction in 2006, it has been continuously expanded and now covers a wide range of industrial requirements. Communication is robust, manufacturer-independent and flexible. This is why OPC UA is often used to integrate various automation components in the ISA-95 model.
Structure of the OPC UA Specification
With over 1,200 pages, the OPC UA specification is extensive. It includes a wide range of sub-standards, each covering a specific aspect of industrial communication such as data access or security. This structure makes it clear that OPC UA is much more than a simple data transmission protocol. Instead, it serves as a comprehensive framework for industrial communication.
However, many parts of the specification are optional. This means developers can implement only the features that are relevant to their specific use case. Fully implementing the entire specification is extremely complex and rarely done in practice. That’s why it’s crucial to verify which parts are actually supported by an OPC server or client.
Client/Server Architecture
At its core, OPC UA is based on a client/server architecture. A client requests data from the server, which then responds. This direct communication is particularly suitable for scenarios in which low latency and high synchronization are important – for example in control and regulation processes. Many devices can act as client and server at the same time, which increases flexibility.
Implementation of OPC UA in Practice
In real industrial application, OPC UA servers are usually implemented directly on the machine controller or within an edge gateway.
- OPC UA server on the controller: Integration directly in the controller (e.g. PLC or HMI) enables fast, near-real-time provision of process data without additional hardware. However, this solution is often manufacturer-specific, offers limited configuration options and restricts the flexibility of data modeling.
- OPC UA server on a gateway: Alternatively, OPC UA servers are operated in dedicated gateways that are connected to the machine via industrial interfaces. This architecture offers more freedom in configuration, enables additional processing (e.g. mapping, filtering) and allows the combination with other protocols. However, this results in additional costs and integration effort.
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 limitation of the client/server model and was developed to address 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 via a message broker. This significantly reduces the communication effort and improves scalability and flexibility in large networks.
Data Formats and Transport Protocols in OPC UA Pub/Sub
OPC UA Pub/Sub distinguishes between two main variants of data transmission: UADP (Binary) via UDP and JSON via MQTT. UADP (Universal Architecture Datagram Protocol) is designed for use in real-time-critical OT environments and enables extremely low latencies – but without integrated acknowledgement of receipt or fault tolerance mechanisms. This variant requires a precisely coordinated multicast-capable network. JSON via MQTT, on the other hand, primarily addresses IT-related applications: It offers higher interoperability, flexible topic structures and reliable delivery through MQTT Quality-of-Service (QoS). This combination is ideal for SCADA, MES or cloud integration as part of a Unified Namespace.
Pub/Sub vs. Monitor: Understanding the Difference
A common misconception is the confusion between OPC UA Pub/Sub (defined in Part 14 of the specification) and the subscription feature within the traditional OPC UA Client/Server model. The latter is not true publish/subscribe communication. Instead, it relies on polling. Clients check for changes on the server at regular intervals using synchronous communication. This differs fundamentally from the event-driven, decoupled nature of OPC UA Pub/Sub, which plays a critical role in building scalable architectures like the Unified Namespace.
Security in OPC UA: Flexible but Error-Prone
Unlike many modern protocols, OPC UA does not enforce security by default. Communication can take place without encryption, authentication, or authorization. Whether data exchange is secure depends entirely on how well servers and clients are configured. Thereby, OPC UA offers a flexible security model – encryption methods, user authentication, and certificate handling can be combined as needed. This makes it suitable for a wide range of use cases. However, this flexibility is a double-edged sword. In practice, it often leads to misconfigurations and serious security vulnerabilities.
Security Gaps due to Complexity
OPC UA offers extensive security functions – including encryption, authentication and user rights management. In practice, however, certificate management poses a particular challenge. Many systems require trust stores to be set up manually, which can quickly become confusing and error-prone in larger installations. In addition, there are often compatibility issues between different OPC UA stacks, for example when supporting certain security policies or token types.
Three Levels of OPC UA Security
OPC UA pursues a holistic security approach that operates on three levels: user security, application security and transport security. Each level helps to protect data and communication against unauthorized access, manipulation and loss.
User Security
OPC UA offers multiple mechanisms to control and verify user access:
- User identity token: OPC UA supports different methods of user authentication for endpoints. This includes anonymous, username & password and certificate.
- Security modes: Communication endpoints can be configured with modes such as None, Sign, and Sign & Encrypt, defining how authentication, integrity, and confidentiality are handled.
- Security policies: These specify which cryptographic algorithms are used in each mode, ensuring consistent implementation of security requirements.
Application Security
Application-level security protects the integrity of the client-server connection itself:
- Multiple endpoints: Servers can expose multiple endpoints, each defined by a specific security mode, policy, and supported user identity types.
- Security modes: Just like at the user level, the modes None, Sign, and Sign & Encrypt determine how messages between client and server are protected.
- Security policies: Policies define the exact cryptographic algorithms used for each mode, ensuring that the selected level of protection is enforced consistently across applications.
Transport Security
Transport-level security ensures the safe transmission of messages across networks:
- Communication mode: OPC UA offers two communication modes – client/server and publisher/subscriber. Both make it possible to sign and encrypt messages to ensure authenticity and confidentiality.
- Security modes: Again, None, Sign, and Sign & Encrypt apply, defining how transport-level authentication, confidentiality, and integrity are achieved.
- Security policies: Again, the security policies define the cryptographic procedures for each security mode.
Advantages and Disadvantages of OPC UA
OPC UA is ideal for applications with complex communication requirements in OT. However, the practicality of the standard is limited due to the specifications that have evolved over decades and the resulting technical debt. The most important points are summarized below.
Advantages
- Highly complex data structures: The standard enables the transfer and management of highly complex data structures, including hierarchical structures. This is particularly useful in industrial systems where the data is often complex and hierarchically organized.
- Secure communication: If configured correctly, 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.
- 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.
- 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 and triggering actions.
Disadvantages
- Interoperability: Although the standard is aimed at interoperability, problems arise in reality. Due to the large number of optional specifications and alternative 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.
- Complexity: OPC UA is a powerful but complex protocol. Implementation and configuration can be very 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 below), as protocols such as MQTT fulfill the communication requirements of the higher levels (e.g. lightweight) much better.
- 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 via messaging systems.
OPC UA in the Unified Namespace (UNS): Role and Positioning
OPC UA is a proven standard for industrial communication at the production and control levels. It enables structured, secure, and vendor-independent data exchange between machines, PLCs, and local systems. However, OPC UA reaches its limits when scaling to higher-level IT systems or cloud platforms—especially in terms of flexibility, communication patterns, and horizontal scalability. Modern industrial architectures are therefore shifting toward lightweight, event-driven protocols like MQTT. These are better suited for large, distributed environments and are ideal for building loosely coupled system architectures. In combination with the Unified Namespace (UNS), MQTT has become the backbone for real-time, scalable industrial data exchange.
In this architecture, OPC UA does not serve as the central transport layer. Instead, it acts as a trusted and structured data source at the OT level. It delivers semantically rich information—such as sensor values, machine states, or alarms—that can be ingested and distributed in real time via MQTT. You can find out more about the differences between OPC UA and MQTT here.
What is the Unified Namespace (UNS)?
The Unified Namespace (UNS) is a central architectural concept for organizing industrial data. It creates a real-time, contextualized information space, typically built around an MQTT broker. In this structure, all relevant data – from shop floor signals to business processes – is organized in a unified, hierarchical topic tree. This approach creates a live digital twin of the production environment. All systems such as MES, ERP, analytics, or machines, can read from and publish to this namespace, enabling true data democratization. For more information on the UNS, please refer to this article.
OPC UA vs. MQTT: Typical Application Areas
OPC UA is designed for deterministic, structured communication in local OT networks. In the RAMI 4.0 model, it is typically deployed at the:
- Field Device Level (0)
- Control Level (1)
- Station/Work Center Level (2)
Here, OPC UA enables standardized communication between sensors, actuators, controllers, using a Client/Server model. For example, a PLC (as OPC UA client) requests data from a line controller (as server), processes it, and sends commands to connected robots or machines. In contrast, MQTT shines at the higher integration levels (RAMI 4.0 level Enterprise and above). It offers a lightweight, decoupled publish/subscribe model, ideal for bridging OT and IT systems.
As a result: Within a Unified Namespace, OPC UA is not replaced but complemented by MQTT. OPC UA continues to deliver structured and contextualized data from the field. That data is then forwarded – via MQTT – to consumers such as MES, ERP, or analytics platforms, ensuring scalability across the entire architecture.
Integration of OPC UA in the Unified Namespace (UNS)
OPC UA can be integrated into the Unified Namespace (UNS) using two primary approaches. Each has its own advantages depending on your system architecture, scalability needs, and interoperability requirements. You can find a step-by-step guide to both integration paths here.
Option 1: Direct Integration via OPC UA Pub/Sub
In this setup, OPC UA servers publish data directly to an MQTT or UDP broker using the Pub/Sub model. This eliminates the need for traditional Client/Server communication. Instead, data is distributed asynchronously across the network.
Pros:
- No additional middleware required
- Asynchronous communication directly from the OPC UA stack
- Less latency with native support
Cons:
- Low distribution and support from manufacturers
- Different implementations lead to interoperability problems
- No central data enrichment and mapping functionalities
Option 2: Integration via Gateways such as i-flow Edge
In this approach, gateways like i-flow Edge act as connectors between OPC UA servers and the MQTT-based UNS. The gateway handles data collection, transformation, semantic enrichment, and structured publishing into the Unified Namespace.
Pros:
- Standardized MQTT publishing independent of OPC UA implementation
- Central management of topic structure, QoS and payload formats
- Contextualization and enrichment of OPC UA data possible
Cons:
- Requires additional infrastructure
- Slightly higher latency due to polling mechanism and additional middleware
Both methods enable seamless integration of OPC UA in the Unified Namespace (UNS). However, using a gateway like i-flow offers clear benefits in terms of data standardization, governance, and long-term scalability. This is especially important in complex environments with multiple OPC UA sources and varying vendor implementations.
Conclusion: Targeted Use of OPC UA in the Unified Namespace
The protocol is robust, flexible, and widely supported at the machine and control level making it a reliable source of high-quality industrial data. However, when it comes to scalability, and higher level IT integration, OPC UA reaches its architectural limits. This is where the Unified Namespace (typically built on MQTT) provides a modern, decoupled communication layer. The real strength lies in combining both technologies: OPC UA delivers rich, contextual data from the edge, while MQTT enables scalable, event-driven distribution across the entire enterprise. Whether integrated directly via OPC UA Pub/Sub or indirectly through gateways like i-flow Edge, this hybrid approach enables a consistent, vendor-independent data flow across all levels of the industrial architecture.
For organizations striving for future-proof OT/IT integration, OPC UA in the Unified Namespace should not be seen as a mere option. It is a core building block of a modern, scalable, and interoperable industrial data infrastructure.
