The OPC UA Serverarchitecture models the Serverendpoint of client/server interactions. Figure 4illustrates the major elements of the Serverand how they relate to each other.


Figure 4– OPC UA Server architecture

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

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

The AddressSpaceis modelled as a set of Nodes accessible by Clientsusing OPC UA Services(interfaces and methods). Nodes in the AddressSpaceare used to represent real objects, their definitions and their Referencesto each other.

OPC 10000-3contains the details of the meta model “building blocks” used to create an AddressSpaceout of interconnected Nodesin a consistent manner. Serversare free to organize their Nodes within the AddressSpaceas they choose. The use of Referencesbetween Nodes permits Serversto organize the AddressSpaceinto hierarchies, a full mesh network of Nodes, or any possible mix.

OPC 10000-5defines OPC UA Nodesand Referencesand their expected organization in the AddressSpace. Some Profileswill not require that all of the UA Nodesbe implemented.

A Viewis a subset of the AddressSpace. Viewsare used to restrict the Nodes that the Servermakes visible to the Client, thus restricting the size of the AddressSpacefor the Servicerequests submitted by the Client. The default Viewis the entire AddressSpace. Serversmay optionally define other Views.Viewshide some of the Nodes or Referencesin the AddressSpace. Viewsare visible via the AddressSpaceand Clientsare able to browse Viewsto determine their structure. Viewsare often hierarchies, which are easier for Clientsto navigate and represent in a tree.

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

MonitoredItemsare entities in the Servercreated by the Clientthat monitor AddressSpace Nodes and, indirectly, their real-world counterparts. When they detect a data change or an event/alarm occurrence, they generate a Notificationthat is transferred to the Clientby a Subscription.

A Subscriptionis an endpoint in the Serverthat publishes Notificationsto Clients. Clientscontrol the rate at which publishing occurs by sending Publish Messages.

The Servicesdefined for OPC UA are described in 7, and specified in OPC 10000-4.

Request/response Servicesare Servicesinvoked by the Clientthrough the OPC UA ServiceInterface to perform a specific task on one or more Nodes in the AddressSpaceand to return a response.

The Publish Serviceis invoked through the OPC UA ServiceInterface for the purpose of periodically sending Notificationsto Clients. Notifications include Events, Alarms, data changes and Programoutputs.

Serverto Serverinteractions in the Client Servermodel are interactions in which one Serveracts as a Clientof another Server. Serverto Serverinteractions 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 Serversthat are used for maintaining system wide type definitions (see Figure 5),
  2. are chained in a layered architecture of Serversto provide:
  3. aggregation of data from lower-layer Servers,
  4. higher-layer data constructs to Clients, and
  5. concentrator interfaces to Clientsfor single points of access to multiple underlying Servers.

Figure 5illustrates interactions between Servers.


Figure 5– Peer-to-peer interactions between Servers

Similar peer-to-peer interactions can also be accomplished using the OPC UA PubSubmodel where each peer Applicationis both a Publisherand a Subscriber.

Figure 6extends the previous example and illustrates the chaining of Serverstogether for vertical access to data in an enterprise.


Figure 6– Chained Server example