C++ Based OPC UA Client/Server SDK
OPC UA Subscription Concept

In contrast to permanently reading information (polling), OPC UA provides a more elegant functionality, a so called Subscription. A UA Client can subscribe to a selection of Nodes of interest and let the server monitor these items. Only in case of changes, e.g. to their values, the server notifies the client about such changes. This mechanism reduces the amount of transferred data immensely. Besides the reduction of bandwidth this mechanism introduces further advantages and is the recommended mechanism to “read” information from a UA Server.

A client can subscribe to different types of information provided by an OPC UA server. The purpose of a Subscription is to group these sources of information, called Monitored Items, together, forming a piece of information called a Notification.

The following figure shows the services which are involved when a client subscribes to data changes and events.

A Subscription consists of at least one Monitored Item, has to be created within the context of a Session and can be transferred to another Session. To create a Session, a Secure Channel between the Client and the Server has to be established.

Context necessary to subscribe to data changes and Events

There are three different types of “changes” a Client can subscribe to when adding Monitored Items to the Subscription:

  • subscribe to data changes of Variable Values (Value attribute of a Variable),
  • subscribe to Events of Objects (EventNotifier attribute of an Object & EventFilter Set),
  • and subscribe to aggregated Values, which are calculated in client-defined time intervals, based on current Variable Values.

The settings available for Monitored Items and the Subscription are shown in the following figure.

Settings for Subscription and Monitored Items

The sampling interval defines, individually for each Monitored Item in the subscription, a time interval. This is the rate at which the server checks the data source for changes. The Sampling can be set much faster than the notification to the Client, in which case the Server may queue the samples and publish the complete queue (see below). The server will revise the fastest possible sampling interval and by this “protect” the data source from extensive load that may be caused by the sampling itself. In the case of Aggregate Monitored Items the Sampling Interval denotes the interval for which the aggregates are calculated.

Filters contain several criteria to to distinguish which data changes or events should be reported and which should be blocked. In the case of Aggregate Monitored Items it also contains the Raw Data Sampling Interval which defines the rate at which values are sampled from the data source.

A UA server may support queuing of data samples or events. The queue size, i.e. the maximum number of values which can be queued, can be configured for each monitored item. When the data gets delivered to the Client (Publish) the queue gets emptied. Each queue has a discard policy (e.g. discard oldest) in case an overflow occurs.

By setting the monitoring mode, the data sampling and reporting can be enabled or disabled.

There are two settings which affect the Subscription itself. After each Publishing Interval notifications collected in the queues are delivered to the client in a Notification Message (Publish Response). The Client must insure that the server has received enough Publish Tokens (Publish Requests), so that whenever the Publish Interval elapsed and a notification is ready to send, the server uses such a token and sends the data within a Publish Response. In case that there is nothing to report (e.g. no values have changed) the server will send a KeepAlive notification to the Client, which is an empty Publish, to indicate that the server is still alive. The sending of the Notification Message can be enabled or disabled by changing the Publish Enabled setting.

The next chapter describes Discovery and Security Configuration.