Hi Mark,

As a start, can you explain do you mean 1) how to access SessionDiagnosticArray or 2) how to detect address space changes dynamically in a more general setting?

For the case 1: If you want to collect the data from SessionDiagnosticArray (i=3707), you can just subscribe to the value attribute of that node.

In general case, subscribing to the SessionDiagnosticArray node may not make that much sense, because it contains for example PublishCount variable which will change all of the time if you subscribe to this node. Fortunately for this case, the Simulation Server does not update the PublishCount etc. variables so you can succesfully subscribe to the SessionDiagnosticArray in Simulatioin Server.

Less fortunately, it seems that there’s a bug where old sessions are not cleared correctly from the SessionDiagnosticArray value. I marked this into our issue tracker and this will be handled in the future.

As for the case 2: if you want to detect address space changes dynamically, you can perhaps use the ModelChange events of the OPC UA specification. However, implementing these is server application specific and the ModelChange events are not supposed to be used for example with the SessionDiagnostic nodes.

Hello Mark,

Just to go through the basic concept: the idea is that you have the value as an array in the node i=3707 and then you have components of the same array value available as values of subnodes. The idea behind the subnodes (referenced with HasComponent) is that you can easily read just part of the larger structure if you are not interested in the whole array.

Another example of this same approach is the ServerStatus node (i=2256).

So, I’m not completely sure what you mean by “subscribing to i=3707 won’t work because of either too many false positives or differences in server based implementations”.

I understand that there’s a bug in the current Simulation Server, but more generally speaking the diagnostics nodes are specified in the OPC UA specification and all server implementations should work similarly.

You are correct when saying ” the processing for this isn’t incredibly efficient”. My point is that you should not be doing the pattern “walk through all the references… and place the data from those objects … in my array”. The most efficient solution is to simply read the value attribute of node i=3707. This is one single OPC UA service call.

And yes, the node i=3707 is unique. Or more formally, unique in the namespace index 0.

But maybe the problem is that I don’t fully understand what you plan to do with the diagnostic information. So, if you can explain more about the purpose of the diagnostic information I’m happy to hear.