Clientsdefine MonitoredItemsto subscribe to data and Events. Each MonitoredItemidentifies the item to be monitored and the Subscriptionto use to send Notifications. The item to be monitored may be any Node Attribute.
Notificationsare data structures that describe the occurrence of data changes and Events. They are packaged into NotificationMessagesfor transfer to the Client. The Subscriptionperiodically sends NotificationMessagesat a user-specified publishinginterval, and the cycle during which these messages are sent is called a publishingcycle.
Four primary parameters are defined for MonitoredItemsthat tell the Serverhow the item is to be sampled, evaluated and reported. These parameters are the sampling interval, the monitoring mode, the filter and the queue parameter. Figure 15illustrates these concepts.
Attributes, other than the Value Attribute, are only monitored for a change in value. The filter is not used for these Attributes. Any change in value for these Attributescauses a Notificationto be generated.
The Value Attributeis used when monitoring Variables. Variablevalues are monitored for a change in value or a change in their status. The filters defined in this document (see 7.22.2) and in OPC 10000-8are used to determine if the value change is large enough to cause a Notificationto be generated for the Variable.
Objectsand views can be used to monitor Events. Eventsare only available from Nodeswhere the SubscribeToEventsbit of theEventNotifier Attributeis set. The filter defined in this document (see 7.22.3) is used to determine if an Eventreceived from the Nodeis sent to the Client. The filter also allows selecting fields of the EventTypethat will be contained in the Eventsuch as EventId, EventType, SourceNode, Timeand Description.
Each MonitoredItemcreated by the Clientis assigned a sampling interval that is either inherited from the publishing interval of the Subscriptionor that is defined specifically to override that rate. A negative number indicates that the default sampling interval defined by the publishing interval of the Subscriptionis requested. The sampling interval indicates the fastest rate at which the Servershould sample its underlying source for data changes.
The assigned sampling interval defines a “best effort” cyclic rate that the Serveruses to sample the item from its source. “Best effort” in this context means that the Serverdoes its best to sample at this rate. Sampling at rates faster than this rate is acceptable, but not necessary to meet the needs of the Client. How the Serverdeals with the sampling rate and how often it actually polls its data source internally is a Serverimplementation detail. However, the time between values returned to the Clientshall be greater or equal to the sampling interval.
The Clientmay also specify 0 for the sampling interval, which indicates that the Servershould use the fastest practical rate. It is expected that Serverswill support only a limited set of sampling intervals to optimize their operation. If the exact interval requested by the Clientis not supported by the Server, then the Serverassigns to the MonitoredItemthe most appropriate interval as determined by the Server. It returns this assigned interval to the Client. The ServerCapabilities Objectdefined in OPC 10000-5identifies the minimum sampling interval supported by the Server. The optional MinimumSamplingInterval Attributedefined in OPC 10000-3identifies the minimum sampling interval supported for a Variable. If a Server uses a fixed set of sampling intervals, the intervals can be exposed using the SamplingIntervalDiagnosticsArrayin the ServerDiagnostics Objectdefined in OPC 10000-5.
The Servermay support data that is collected based on a sampling model or generated based on an exception-based model. The fastest supported sampling interval may be equal to 0, which indicates that the data item is exception-based rather than being sampled at some period. An exception-based model means that the underlying system does not require sampling and reports data changes.
The Clientmay use the revised sampling interval values as a hint for setting the publishing interval as well as the keep-alive count of a Subscription. If, for example, the smallest revised sampling interval of the MonitoredItemsis 5 seconds, then the time before a keep-alive is sent should be longer than 5 seconds.
Note that, in many cases, the OPC UA Serverprovides access to a decoupled system and therefore has no knowledge of the data update logic. In this case, even though the OPC UA Serversamples at the negotiated rate, the data might be updated by the underlying system at a much slower rate. In this case, changes can only be detected at this slower rate.
If the behaviour by which the underlying system updates the item is known, it will be available via the MinimumSamplingInterval Attributedefined in OPC 10000-3. If the Serverspecifies a value for the MinimumSamplingInterval Attributeit shall always return a revisedSamplingIntervalthat is equal or higher than the MinimumSamplingIntervalif the Clientsubscribes to the Value Attribute.
Clientsshould also be aware that the sampling by the OPC UA Serverand the update cycle of the underlying system are usually not synchronized. This can cause additional delays in change detection, as illustrated in Figure 16.
The monitoring mode parameter is used to enable and disable the sampling of a MonitoredItem, and also to provide for independently enabling and disabling the reporting of Notifications. This capability allows a MonitoredItemto be configured to sample, sample and report, or neither. Disabling sampling does not change the values of any of the other MonitoredItemparameter, such as its sampling interval.
When a MonitoredItemis enabled (i.e. when the MonitoringModeis changed from DISABLEDto SAMPLINGor REPORTING) or it is created in the enabled state, the Servershall report the first sample as soon as possible and the time of this sample becomes the starting point for the next sampling interval.
Each time a MonitoredItemis sampled, the Serverevaluates the sample using the filter defined for the MonitoredItem. The filter parameter defines the criteria that the Serveruses to determine if a Notificationshould be generated for the sample. The type of filter is dependent on the type of the item that is being monitored. For example, the DataChangeFilter and the AggregateFilterare used when monitoring Variable Valuesand the EventFilteris used when monitoring Events. Sampling and evaluation, including the use of filters, are described in this document. Additional filters may be defined in other parts of OPC 10000.
If the sample passes the filter criteria, a Notificationis generated and queued for transfer by the Subscription. The size of the queue is defined when the MonitoredItemis created. When the queue is full and a new Notificationis received, the Servereither discards the oldest Notificationand queues the new one, or it replaces the last value added to the queue with the new one. The MonitoredItemis configured for one of these discard policies when the MonitoredItemis created. If a Notification is discarded for a DataValueand the size of the queue is larger than one, then the Overflowbit (flag) in the InfoBitsportion of the DataValue statusCodeis set. If discardOldestis TRUE, the oldest value gets deleted from the queue and the next value in the queue gets the flag set. If discardOldestis FALSE, the last value added to the queue gets replaced with the new value. The new value gets the flag set to indicate the lost values in the next NotificationMessage. Figure 17illustrates the queue overflow handling.
If the queue size is one, the queue becomes a buffer that always contains the newest Notification. In this case, if the sampling interval of the MonitoredItemis faster than the publishing interval of the Subscription, the MonitoredItemwill be over sampling and the Clientwill always receive the most up-to-date value. The discard policy is ignored if the queue size is one.
On the other hand, the Clientmay want to subscribe to a continuous stream of Notificationswithout any gaps, but does not want them reported at the sampling interval. In this case, the MonitoredItemwould be created with a queue size large enough to hold all Notificationsgenerated between two consecutive publishing cycles. Then, at each publishing cycle, the Subscriptionwould send all Notificationsqueued for the MonitoredItemto the Client. The Servershall return Notificationsfor any particular item in the same order they are in the queue.
The Servermay be sampling at a faster rate than the sampling interval to support other Clients; the Clientshould only expect values at the negotiated sampling interval. The Servermay deliver fewer values than dictated by the sampling interval, based on the filter and implementation constraints. If a DataChangeFilteris configured for a MonitoredItem, it is always applied to the newest value in the queue compared to the current sample.
Queuing of data may result in unexpected behaviour when using a Deadbandfilter and the number of encountered changes is larger than the number of values that can be maintained. The new first value in the queue may not exceed the Deadbandlimit of the previous value sent to the Client.
The queue size is the maximum value supported by the Serverwhen monitoring Events. In this case, the Serveris responsible for the Eventbuffer. If Eventsare lost, an Eventof the type EventQueueOverflowEventTypeis placed in the queue. This Event is generated when the first Event is discarded on a MonitoredItem subscribing for Events. It is put into the Queue of the MonitoredItem in addition to the size of the Queue defined for this MonitoredItem without discarding any other Event. If discardOldestis set to TRUE it is put at the beginning of the queue and is never discarded, otherwise at the end. An aggregating Servershall not pass on such an Event. It shall be handled like other connection error scenarios using the SystemStatusChangeEventTypewith the ServerState COMMUNICATION_FAULT.
For any fatal error during event processing like out of memory situations, the Servershould queue an SystemStatusChangeEventTypeevent with the ServerState COMMUNICATION_FAULTand the source set to the Server Object. If there are no resources available at the time the error happens, the Servershould flag an error internally until there are resources to further process Events for theMonitoredItem.
The MonitoredItems Serviceallows the addition of items that are reported only when some other item (the triggering item) triggers. This is done by creating links between the triggered items and the items to report. The monitoring mode of the items to report is set to sampling-only so that it will sample and queue Notificationswithout reporting them. Figure 18illustrates this concept.
The following triggering behaviours are specified.
- If the monitoring mode of the triggering item is SAMPLING, then it is not reported when the triggering item triggers the items to report.
- If the monitoring mode of the triggering item is REPORTING, then itis reported when the triggering item triggers the items to report.
- If the monitoring mode of the triggering item is DISABLED, then the triggering item does not trigger the items to report.
- If the monitoring mode of the item to report is SAMPLING, then itis reported when the triggering item triggers the items to report.
- If the monitoring mode of the item to report is REPORTING, this effectively causes the triggering item to be ignored. All notifications of the items to report are sent after the publishing interval expires.
- If the monitoring mode of the item to report isDISABLED, then there will be no sampling of the item to report and therefore no notifications to report.
- The first trigger shall occur when the first notification is queued for the triggering item after the creation of the link.
Clientscreate and delete triggering links between a triggering item and a set of items to report. If the MonitoredItemthat represents an item to report is deleted before its associated triggering link is deleted, the triggering link is also deleted, but the triggering item is otherwise unaffected.
Deletion of a MonitoredItemshould not be confused with the removal of the Attributethat it monitors. If the Nodethat contains the Attributebeing monitored is deleted, the MonitoredItemgenerates a Notificationwith a StatusCode Bad_NodeIdUnknownthat indicates the deletion, but the MonitoredItemis not deleted.