5.3 OPC UA Servers
5.3.1 General
The OPC UA Server architecture models the Server endpoint of client/server interactions. Figure 4 illustrates the major elements of the Server and how they relate to each other.
5.3.2 Real objects
Real objects are physical or software objects that are accessible by the Server application or that it maintains internally. Examples include physical devices (e.g. sensors, actuators, motors) and diagnostics counters.
5.3.3 Server application
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.
5.3.4 OPC UA AddressSpace
5.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.
5.3.4.2 AddressSpace organization
OPC 10000-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.
OPC 10000-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.
5.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.
5.3.4.4 Support for information models
The OPC UA AddressSpace supports Information Models. This support is provided through:
Node References that allow Objects in the AddressSpace to be related to each other.
ObjectType Nodes that provide semantic information for real Objects (type definitions).
ObjectType Nodes to support subclassing of type definitions.
Data type definitions exposed in the AddressSpace that allow industry specific data types to be used.
Industry groups can define how their specific information models are to be represented in Server AddressSpace.
5.3.5 Subscription entities
5.3.5.1 MonitoredItems
MonitoredItems are entities in the Server created by the Client that monitor AddressSpace Nodes and, indirectly, 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.
5.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.
5.3.6 OPC UA Service interface
5.3.6.1 General
The Services defined for OPC UA are described in clause 6, and specified in OPC 10000-4.
5.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.
5.3.6.3 Subscription Services
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.
5.3.7 Server to Server interactions
Server to Server interactions in the ClientServer 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:
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 5),
are chained in a layered architecture of Servers to provide:
aggregation of data from lower-layer Servers,
higher-layer data constructs to Clients, and
concentrator interfaces to Clients for single points of access to multiple underlying Servers.
Figure 5 illustrates 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 6 extends the previous example and illustrates the chaining of Servers together for vertical access to data in an enterprise.
