Errata exists for this version of the document.
Each MonitoredItem created by the Client is assigned a sampling interval that is either inherited from the publishing interval of the Subscription or that is defined specifically to override that rate. A negative number indicates that the default sampling interval defined by the publishing interval of the Subscription is requested. The sampling interval indicates the fastest rate at which the Server should sample its underlying source for data changes.
A Client shall define a sampling interval of 0 if it subscribes for Events.
The assigned sampling interval defines a “best effort” cyclic rate that the Server uses to sample the item from its source. “Best effort” in this context means that the Server does 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 Server deals with the sampling rate and how often it actually polls its data source internally is a Server implementation detail. However, the time between values returned to the Client shall be greater or equal to the sampling interval.
The Client may also specify 0 for the sampling interval, which indicates that the Server should use the fastest practical rate. It is expected that Servers will support only a limited set of sampling intervals to optimize their operation. If the exact interval requested by the Client is not supported by the Server, then the Server assigns to the MonitoredItem the most appropriate interval as determined by the Server. It returns this assigned interval to the Client. The Server Capabilities Object defined in OPC 10000-5 identifies the sampling intervals supported by the Server.
The Server may 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 Client may 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 MonitoredItems is 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 Server provides access to a decoupled system and therefore has no knowledge of the data update logic. In this case, even though the OPC UA Server samples 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 Attribute defined in OPC 10000-3. If the Server specifies a value for the MinimumSamplingInterval Attribute it shall always return a revisedSamplingInterval that is equal or higher than the MinimumSamplingInterval if the Client subscribes to the Value Attribute.
Clients should also be aware that the sampling by the OPC UA Server and the update cycle of the underlying system are usually not synchronised. This can cause additional delays in change detection, as illustrated in Figure 16.
