IEC TR 62541: OPC Unified Architecture — Part 1: Overview and Concepts

IEC TR 62541-1 provides the foundational overview and concepts for the OPC Unified Architecture (OPC UA), a platform-independent service-oriented architecture for industrial communication. Originally developed by the OPC Foundation and adopted as an IEC Technical Report, OPC UA addresses a fundamental challenge of modern industrial automation: the need for secure, reliable, and interoperable data exchange between devices, controllers, and enterprise systems across heterogeneous platforms. Unlike its predecessor OPC Classic (which relied on COM/DCOM technology from Microsoft), OPC UA is designed from the ground up for cross-platform deployment, supporting embedded devices, PLCs, DCS systems, SCADA, MES, ERP, and cloud platforms running Linux, Windows, VxWorks, or any real-time operating system.

OPC UA Address Space and Information Modelling

The OPC UA address space is the heart of the architecture. It exposes data as a network of nodes connected by references, forming a graph structure rather than a flat tag list. Each node has attributes (properties such as value, timestamp, quality) and is classified into one of eight standard node classes: Object, Variable, Method, ObjectType, VariableType, ReferenceType, DataType, and View. This object-oriented approach enables complex information models, such as describing a pump as an Object with Variables for speed and temperature, Methods for start and stop, and references connecting it to its motor drive, controller, and maintenance history.

The information modelling framework is based on three core concepts. Type definitions (ObjectTypes and VariableTypes) define the structure and behaviour of nodes, supporting inheritance hierarchies that enable manufacturers to extend standard types with domain-specific properties. Reference types define the semantics of relationships between nodes, with standard references including “HasComponent,” “HasProperty,” “HasSubtype,” and “Organizes,” while custom reference types can be defined for domain-specific relationships. Views provide filtered subsets of the address space, allowing different clients to see only the information relevant to their role — an operator sees process values, a maintenance engineer sees diagnostic data, and a production planner sees throughput statistics.

Communication Architecture and Security Model

OPC UA defines a service-oriented communication architecture with two primary communication patterns. The client-server pattern provides request-response communication where clients discover and interact with servers through a set of 37 standard services organised into service sets (Discovery, SecureChannel, Session, NodeManagement, Attribute, Method, Subscription, MonitoredItem, and Query services). The subscription mechanism is particularly important for industrial applications: once a client establishes a subscription for certain variables, the server automatically sends notifications (data change events, alarm conditions, or event notifications) when specified trigger conditions are met, eliminating the need for polling.

The publish-subscribe (PubSub) pattern, added in OPC UA Part 14, extends the architecture to support one-to-many and many-to-many communication scenarios essential for time-sensitive networking (TSN) and cloud connectivity. PubSub uses message-oriented middleware patterns (MQTT, AMQP, or UDP multicast) to decouple publishers and subscribers, enabling scalable data distribution without requiring every subscriber to establish a separate connection. This is particularly valuable for applications such as condition monitoring of thousands of sensors, where client-server connections would be impractical.

The OPC UA security model addresses authentication (using X.509 certificates or username/password), authorisation (role-based access control at the individual node level), integrity (message signing using asymmetric or symmetric cryptography), and confidentiality (message encryption). The security architecture supports three security modes: None (for non-critical data in protected networks), Sign (message integrity verification), and SignAndEncrypt (both integrity and confidentiality). Application Instance Certificates are the foundation of OPC UA security, establishing trust relationships between clients and servers through certificate exchange and validation against trusted certificate stores.

Engineering Design Insights for OPC UA Deployments

From an engineering perspective, successful OPC UA deployment requires several architectural decisions. The information model design is the most impactful decision: embarking on an OPC UA project without a well-designed information model leads to ad hoc tag structures that defeat the purpose of semantic interoperability. The recommended approach is to start with standardised companion specifications (such as OPC UA for Process Automation, OPC UA for Machine Tools, or OPC UA for PLCopen) and extend them as needed with domain-specific types, rather than creating a completely custom model from scratch.

Performance engineering is another critical consideration. The OPC UA binary protocol (UA Binary) is highly efficient, with typical message overhead of only 10-20 bytes per packet plus the data payload, and encoding/decoding throughput exceeding 1 million data changes per second on modern hardware. However, the choice of transport binding significantly affects performance: UA TCP provides the lowest latency for local networks, while HTTPS tunnelling through firewalls adds overhead. For time-critical applications, the PubSub over UDP TSN profile enables cycle times below 1 ms with jitter under 1 microsecond, meeting the requirements of motion control and drive synchronisation.

System integration considerations include the addressing and discovery infrastructure. OPC UA supports local discovery via mDNS (multicast DNS) on the local subnet and global discovery through Local Discovery Servers (LDS) and Global Discovery Servers (GDS). For large distributed systems, a hierarchical discovery architecture with regional LDS instances and a central GDS is recommended to manage the complexity of locating servers across network segments. The OPC UA specification also defines support for redundant servers (transparent failover), redundant clients (multi-client data collection), and hot standby configurations for high-availability applications.