The OPC UA data exchange

The easiest way to exchange data between an OPC UA client and a server is to use read and write services. The read and write services are optimized to transfer a bunch of data rather than single piece of data or a few values. They allow us to read and write either values ​​or attributes of nodes. The read service has the following parameters:

• maxAge: This is the maximum time taken for the values to be returned. It is specified by the client. It forces the server to access the device (for example, a sensor) if the copy in its cache is older than the maxAge parameter configured by the client. If maxAge is set to zero, the server must supply the current value by always reading it directly from the device.
• Type of timestamps: In OPC UA, two timestamps are defined, the source timestamp and the server timestamp. The source timestamp is the timestamp that comes from the device, while the server timestamp is the timestamp that comes from the OS where the OPC UA server is running.
• List of nodes and attributes: The list of nodes and attributes are as follows:
  • NodeId
  • AttributeId for instance value
  • DataEncoding: This allows the client to choose the appropriate data encoding and the default values are XML, UA binary

The parameters of the write services are the following:

• List of nodes, attributes, and values: The list of nodes, attributes and their values are as follows:
  • NodeId
  • AttributeId
  • Value to write
  • Source timestamp: Null if not set
  • Timestamp server: Null if not set

A client can create one or more subscriptions for each session. For each subscription, the client can create monitored items, which are related to the real items. Each monitored item can create a notification, which can either be linked to the changes of the values of the attributes or variables selected by the client, or it can be connected to when events occur. Each monitored item continuously produces notifications either until the subscription is cancelled, or the monitored items are deleted. Clients can use subscriptions to receive updates on a regular basis.

The following diagram represents the relationships between sessions, subscriptions, and monitored items:

The subscription collects and groups all notifications related to it on a regular basis. All notifications thus grouped are inserted in a NotificationMessage to be sent to the client. Monitored items cannot exist if a subscription is not created by the client within a session; the client must create a subscription before the monitored item can be defined. A subscription has several parameters. The main ones are as follows:

• PublishingInterval: This defines the time interval used by the server to create a NotificationMessage for the given subscription.
• PublishingEnabled: This is a Boolean value that enables the forwarding of the NotificationMessage to the client.

In addition, each subscription manages the following:

• A keep-alive counter that counts the number of publishing intervals that have elapsed with no notifications sent to the client
• A lifetime counter that counts the consecutive number of publishing intervals that have elapsed with no actions carried out by the client
• A queue of the NotificationMessage sent and not acknowledged by the client

A subscription allows us to create an automatic mechanism to write messages to be sent to the client, called NotificationMessage. These contain the values ​​produced by the monitored items that are created for that subscription. Monitored items are defined within a subscription to monitor server items. These can be one of the following:

• Attributes: Any attribute of any node can be associated with a monitored item. Attributes are only monitored to indicate when their value changes. A value change produces a notification.
• Variable: The value attribute of the nodes belonging to a NodeClass variable can be associated with a monitored item. The value attribute of a variable is monitored to check for changes in its value or status under specific conditions. If the conditions are met, the related change triggers a notification by the monitored item.
• Objects and view: The nodes belonging to the node class's object and view can be associated with a monitored item. These are monitored about the occurrence of a particular event.

For every change of attribute, value, or status, or for each event monitored by the monitored item, a notification is produced. Several notifications are packaged by the subscription within a NotificationMessage at time intervals according to the publishing interval.

All monitored items have some common settings. The most important of these is SamplingInterval. This defines the frequency in milliseconds at which the server samples the items with which the monitored item is associated. The default value of the sampling interval is the same as the publishing interval of the related subscription. A client must set the sampling interval to zero if the subscription is related to events. If the client specifies a sampling interval that is not supported by the server, the server assigns the most appropriate range to the monitored item. The sampling performed by the OPC UA server and the scan cycle used to get the data from the underlying device are usually not synchronized. This can cause delays in detecting changes.