6 Systems concepts

6.1 Overview

The OPC UA systems architecture models OPC UA 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.

OPC UA Clients and Servers are described in the clauses that follow. Figure 3 illustrates the architecture that includes a combined Server and Client.

6.2 OPC UA Clients

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

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

Note that the “OPC UA Client API” is an internal interface that isolates the Client application code from an OPC UA Communication Stack. The OPC UA Communication Stack converts OPC UA 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 OPC UA Client API.

6.3 OPC UA Servers

6.3.1 General

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

6.3.2 Real objects

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

6.3.3 OPC UA Server application

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

6.3.4 OPC UA AddressSpace

6.3.4.1 AddressSpace Nodes

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.

6.3.4.2 AddressSpace organization

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.

6.3.4.3 AddressSpace Views

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.

6.3.4.4 Support for information models

The OPC UA AddressSpace supports information models. This support is provided through: a) Node References that allow Objects in the AddressSpace to be related to each other. b) ObjectType Nodes that provide semantic information for real Objects (type definitions). c) ObjectType Nodes to support subclassing of type definitions. d) Data type definitions exposed in the AddressSpace that allow industry specific data types to be used. e) OPC UA companion standards that permit industry groups to define how their specific information models are to be represented in OPC UA Server AddressSpace.

6.3.5 Publisher/subscriber entities

6.3.5.1 MonitoredItems

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.

6.3.5.2 Subscriptions

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.

6.3.6 OPC UA Service Interface

6.3.6.1 General

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

6.3.6.2 Request/response Services

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.

6.3.6.3 Publisher Services

Publisher Services are Services 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.

6.3.7 Server to Server interactions

Server to Server interactions are interactions in which one Server acts as a Client of another Server. Server to Server interactions allow for the development of servers that: f) 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), g) are chained in a layered architecture of Servers to provide: 1) aggregation of data from lower-layer Servers, 2) higher-layer data constructs to Clients, and 3) concentrator interfaces to Clients for single points of access to multiple underlying Servers. Figure 6 illustrates interactions between Servers.

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

6.4 Redundancy

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.