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

image006.png

Figure 5– 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.

Part 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.

Part 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:

  1. Node Referencesthat allow Objectsin the AddressSpaceto 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 AddressSpacethat 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.

MonitoredItemsare entities in the Servercreated by the Clientthat monitor AddressSpace Nodes and 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 Clause 6.4, and specified in Part 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 6),
  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 6illustrates interactions between Servers.

image007.png

Figure 6– 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 7extends the previous example and illustrates the chaining of Serverstogether for vertical access to data in an enterprise.

image008.png

Figure 7– Chained Server example