Errata exists for this version of the document.
This Service is used to create and add one or more MonitoredItems to a Subscription. A MonitoredItem is deleted automatically by the Server when the Subscription is deleted. Deleting a MonitoredItem causes its entire set of triggered item links to be deleted, but has no effect on the MonitoredItems referenced by the triggered items.
Calling the CreateMonitoredItems Service repetitively to add a small number of MonitoredItems each time may adversely affect the performance of the Server. Instead, Clients should add a complete set of MonitoredItems to a Subscription whenever possible.
When a MonitoredItem is added, the Server performs initialization processing for it. The initialization processing is defined by the Notification type of the item being monitored. Notification types are specified in this standard and in the Access Type Specification parts of this series of standards, such as OPC 10000-8. See OPC 10000-1 for a description of the Access Type Parts.
When a user adds a monitored item that the user is denied read access to, the add operation for the item shall succeed and the bad status Bad_NotReadable or Bad_UserAccessDenied shall be returned in the Publish response. This is the same behaviour for the case where the access rights are changed after the call to CreateMonitoredItems. If the access rights change to read rights, the Server shall start sending data for the MonitoredItem. The same procedure shall be applied for an IndexRange that does not deliver data for the current value but could deliver data in the future.
Monitored Nodes can be removed from the AddressSpace after the creation of a MonitoredItem. This does not affect the validity of the MonitoredItem but a Bad_NodeIdUnknown shall be returned in the Publish response. It is possible that the MonitoredItem becomes valid again if the Node is added again to the AddressSpace and the MonitoredItem still exists.
If a NodeId is known to be valid by a Server but the corresponding Node Attributes are currently not available, the Server may allow the creation of a MonitoredItem and return an appropriate Bad StatusCode in the Publish response.
The return diagnostic info setting in the request header of the CreateMonitoredItems or the last ModifyMonitoredItems Service is applied to the Monitored Items and is used as the diagnostic information settings when sending Notifications in the Publish response.
Illegal request values for parameters that can be revised do not generate errors. Instead the Server will choose default values and indicate them in the corresponding revised parameter.
It is strongly recommended by OPC UA that a Client reuses a Subscription after a short network interruption by activating the existing Session on a new SecureChannel as described in 6.7. If a Client called CreateMonitoredItems during the network interruption and the call succeeded in the Server but did not return to the Client, then the Client does not know if the call succeeded. The Client may receive data changes for these monitored items but is not able to remove them since it does not know the Server handle for each monitored item. There is also no way for the Client to detect if the create succeeded. To delete and recreate the Subscription is also not an option since there may be several monitored items operating normally that should not be interrupted. To resolve this situation, the Server Object provides a Method GetMonitoredItems that returns the list of server and client handles for the monitored items in a Subscription. This Method is defined in OPC 10000-5. The Server shall verify that the Method is called within the Session context of the Session that owns the Subscription.