Hello,

First of all, monitoring all Variables on a Server’s AddressSpace for changes sounds like a very bad idea. Depending on the Server, there can hundreds or even thousands of Variables. Monitoring them all would put quite a heavy load the Server and possibly on the Client as well.

And if you do not know the structure of the PLC beforehand, what would be the significance of the received data changes? There is no guarantee that the NodeIds, BrowseNames or DisplayNames on the Server would give enough semantic meaning to the Variables you monitor, so understanding the structure of the PLC might be required to interpret the received data changes. And if you know the structure of the PLC, you don’t have to traverse the entire AddressSpace for Variables and you can just monitor those that represent important information.

That being said, recursive browsing with browse methods of AddressSpace class, such as browse(NodeId nodeId), is the only way of traversing the entire AddressSpace. Since OPC UA doesn’t have a strict parent-child hierarchy for Nodes, it is possible to reach a Node with multiple BrowsePaths so you have to keep track of Nodes that have already been processed to avoid processing them more than once.

Hello,

If the Server generates them, you could monitor the Server’s Server Object for ModelChangeEvents. Those Events are generated when Nodes or References are added or deleted and also when DataType Attributes of Variables change. Handling ModelChangeEvents would make it easier for your Client to react to changes in the Server’s AddressSpace. However, Servers are not required to generate ModelChangeEvents so you might not be able to rely on them.

For more information on ModelChangeEvents and how they express the changes using ModelChangeStructureDataType, see https://reference.opcfoundation.org/v105/Core/docs/Part3/#9.32 https://reference.opcfoundation.org/Core/docs/Part5/6.4.32/ and https://reference.opcfoundation.org/Core/docs/Part5/12.16/

If the Server doesn’t generate ModelChangeEvents, there isn’t any way to detect changes in the AddressSpace except by periodically browsing it from root to leaves to check for changes.

You can create MonitoredItems for other Attributes in addition to the typical Value Attribute. If you think that the Descriptions of Variables could change, you can create MonitoredItems to monitor changes in the Description Attributes of Variable Nodes. You could also monitor DataType Attributes if the Server doesn’t generate ModelChangeEvents and you think those could change too.

If a Variable Node on the Server corresponding to a MonitoredItem is deleted, the Server is expected to send a Notification for that MonitoredItem with StatusCode Bad_NodeIdUnknown to indicate that the Variable has been deleted. For more information, see https://reference.opcfoundation.org/Core/docs/Part4/5.12.1/#5.12.1.6

A change in the DataType Attribute of a Variable Node won’t affect a MonitoredItem monitoring the Value Attribute of the same Variable. You would keep receiving Notifications for new Values of the Variable, though their DataType would be different than before. As mentioned before, if you expect this to happen, you can monitor the DataType Attributes of Variable Nodes as well.