Errata exists for this version of the document.

The OPC UA systems architecture models Clients and Servers as interacting partners. Each system may contain multiple Clients and Servers. Each Client may interact concurrently with one or more Servers, and each Server may interact concurrently with one or more Clients. An application may combine Server and Client components to allow interaction with other Servers and Clients as described in 6.3.7.

Clients and Servers are described in the sub-clauses 6.2 and 6.3. Figure 3 illustrates the architecture that includes a combined Server and Client.

Figure 3 – OPC UA System architecture

The OPC UA Client architecture models the Client endpoint of client/server interactions. Figure 4 illustrates the major elements of a typical Client and how they relate to each other.

Figure 4 – OPC UA Client architecture

The Client Application is the code that implements the function of the Client. It uses the Client API to send and receive OPC UA Service requests and responses to the Server. The Services defined for OPC UA are described in Clause 6.4, and specified in Part 4.

Note that the “Client API” is an internal interface that isolates the Client application code from an OPC UA Communication Stack. The OPC UA Communication Stack converts Client API calls into Messages and sends them through the underlying communications entity to the Server at the request of the Client application. The OPC UA Communication Stack also receives response and NotificationMessages from the underlying communications entity and delivers them to the Client application through the Client API.

The OPC UA Server architecture models the Server endpoint of client/server interactions. Figure 5 illustrates the major elements of the Server and how they relate to each other.

Figure 5 – OPC UA Server architecture

Real objects are physical or software objects that are accessible by the Server application or that it maintains internally. Examples include physical devices and diagnostics counters.

The Server application is the code that implements the function of the Server. It uses the Server API to send and receive OPC UA Messages from Clients. Note that the “Server API” is an internal interface that isolates the Server application code from an OPC UA Communication Stack.

The AddressSpace is modelled as a set of Nodes accessible by Clients using OPC UA Services (interfaces and methods). Nodes in the AddressSpace are used to represent real objects, their definitions and their References to each other.

Part 3 contains the details of the meta model “building blocks” used to create an AddressSpace out of interconnected Nodes in a consistent manner. Servers are free to organize their Nodes within the AddressSpace as they choose. The use of References between Nodes permits Servers to organize the AddressSpace into hierarchies, a full mesh network of Nodes, or any possible mix.

Part 5 defines OPC UA Nodes and References and their expected organization in the AddressSpace. Some Profiles will not require that all of the UA Nodes be implemented.

A View is a subset of the AddressSpace. Views are used to restrict the Nodes that the Server makes visible to the Client, thus restricting the size of the AddressSpace for the Service requests submitted by the Client. The default View is the entire AddressSpace. Servers may optionally define other Views. Views hide some of the Nodes or References in the AddressSpace. Views are visible via the AddressSpace and Clients are able to browse Views to determine their structure. Views are often hierarchies, which are easier for Clients to navigate and represent in a tree.

The OPC UA AddressSpace supports information models. This support is provided through:

1. Node References that allow Objects in the AddressSpace to be related to each other.
2. ObjectType Nodes that provide semantic information for real Objects (type definitions).
3. ObjectType Nodes to support subclassing of type definitions.
4. Data type definitions exposed in the AddressSpace that allow industry specific data types to be used.
5. OPC UA companion standards that permit industry groups to define how their specific information models are to be represented in Server AddressSpace.

MonitoredItems are entities in the Server created by the Client that monitor AddressSpace Nodes and their real-world counterparts. When they detect a data change or an event/alarm occurrence, they generate a Notification that is transferred to the Client by a Subscription.

A Subscription is an endpoint in the Server that publishes Notifications to Clients. Clients control the rate at which publishing occurs by sending Publish Messages.

The Services defined for OPC UA are described in Clause 6.4, and specified in Part 4.

Request/response Services are Services invoked by the Client through the OPC UA Service Interface to perform a specific task on one or more Nodes in the AddressSpace and to return a response.

The Publish Service is invoked through the OPC UA Service Interface for the purpose of periodically sending Notifications to Clients. Notifications include Events, Alarms, data changes and Program outputs.

Server to Server interactions in the Client Server model are interactions in which one Server acts as a Client of another Server. Server to Server interactions allow for the development of servers that:

1. exchange information with each other on a peer-to-peer basis, this could include redundancy or remote Servers that are used for maintaining system wide type definitions (see Figure 6),
2. are chained in a layered architecture of Servers to provide:
3. aggregation of data from lower-layer Servers,
4. higher-layer data constructs to Clients, and
5. concentrator interfaces to Clients for single points of access to multiple underlying Servers.

Figure 6 illustrates interactions between Servers.

Figure 6 – Peer-to-peer interactions between Servers

Similar peer-to-peer interactions can also be accomplished using the OPC UA PubSub model where each peer Application is both a Publisher and a Subscriber.

Figure 7 extends the previous example and illustrates the chaining of Servers together for vertical access to data in an enterprise.

Figure 7 – Chained Server example

OPC UA provides the data structures and services by which Redundancy may be achieved in a standardized manner. Redundancy may be used for high availability, fault tolerance and load balancing. Part 4 formally defines Client, Server and Network Redundancy. Only some Profiles Part 7 will require redundancy support, but not the base Profile.

Required client and server behaviours are associated with two distinct modes of Server Redundancy, transparent and non-transparent. The Client and Server responsibilities when using either transparent or non-transparent redundancy are defined in Part 4.

Servers that support non-transparent redundancy can also support client controlled load balancing. The health of a Server including its ability to Service requests is collectively defined as ServiceLevel. See Part 5 for a formal definition of ServiceLevel. Part 4 defines four distinct ServiceLevel sub-ranges and example usage.

With PubSub,  OPC UA Applications do not directly exchange requests and responses. Instead, Publishers send messages to a Message Oriented Middleware, without knowledge of what, if any, Subscribers there may be. Similarly, Subscribers express interest in specific types of data, and process messages that contain this data, without knowledge of what Publishers there are.

Message Oriented Middleware is software or hardware infrastructure supporting sending and receiving messages between distributed systems. It depends on the Message Oriented Middleware how this distribution is implemented.

To cover a large number of use cases, OPC UA PubSub supports two largely different Message Oriented Middleware variants. These are:

• A broker-less form, where the Message Oriented Middleware is the network infrastructure that is able to route datagram-based messages. Subscribers and Publishers use datagram protocols like UDP multicast.
• A broker-based form, where the Message Oriented Middleware is a Broker. Subscribers and Publishers use standard messaging protocols like AMQP or MQTT to communicate with the Broker. All messages are published to specific queues (e.g. topics, nodes) that the Broker exposes and Subscribers can listen to these queues. The Broker may translate messages from the formal messaging protocol of the Publisher to the formal messaging protocol of the Subscriber.

PubSub is used to communicate messages between different system components without these components having to know each other’s identity.

A Publisher is pre-configured with what data to send. There is no connection establishment between Publisher and Subscriber.

The knowledge about who Subscribers are and the forwarding of published data to the Subscribers is off-loaded to the Message Oriented Middleware. The Publisher does not know or even care if there is one or many Subscribers. Effort and resource requirements for the Publisher are predictable and do not depend on the number of Subscribers.

Part 14 describes the details of the OPC UA PubSub model.

PubSub and Client Server are both based on the OPC UA Information Model. PubSub therefore can easily be integrated into Servers and Clients. Quite typically, a Publisher will be an Server (the owner of information) and a Subscriber is often a Client. Above all, the PubSub Information Model for configuration promotes the configuration of Publishers and Subscribers using the OPC UA Client Server model. Figure 8 depicts a single OPC UA Application that acts as both a Server and a Publisher.

Figure 8 – Integrated Client Server and PubSub models

Nevertheless, the PubSub communication does not require such a role dependency. I.e., Clients can be Publishers and Servers can be Subscribers. In fact, there is no necessity for Publishers or Subscribers to be either a Server or a Client to participate in PubSub communications.