Log In
Home
03/19/2019
Offline
Hello,
how does a OPC UA client know, that a namespace listed in the Server NamespaceArray is ready to use (all mandatory type/instance nodes are present in the information model)?
I can't find anything about that in the specification.
Best regards,
Thomas
05/30/2017
Offline
Servers are not required to expose Types that are not used.
So supporting a CS Namespace does not mean that all types in the CS Namespace are guaranteed to be there.
If a Type is used then the Server is expected to use it properly so if an instance exist you can assume it is 'ready to be used'.
03/19/2019
Offline
So a OPC UA client has to try to browse for an instance in the address space until the nodes get created by the OPC UA Server?
In our case a possible solution would for example be, that the OPC UA Client listens to a GeneralModelChanged Event on the Namespace 0 Server-Object and waits until the CS Namespace is present in the NamespaceArray. Because then the client can be sure that the instance nodes were created by the OPC UA Server. Is this a viable way to go?
05/30/2017
Offline
No. The type nodes need to exist even if a client has not actually browsed an instance.
Types can be omitted only if the server knows that instances it has will never reference it.
If the server does not know it needs to have the the type.
03/19/2019
Offline
Our Server creates all the type and instance nodes for this special CS Namespace, this is not my question.
But before our Server SDK creates types (and/or instances) nodes, the Namespace URI is added to the NamespaceArray (NS 0) and creating the nodes may take some time. The Client sees this Namespace URI in the NamespaceArray and starts to browse/read/... nodes from this namespace, which are not created yet.
And I think it's correct that our Server SDK adds the Namespace URI to the NamespaceArray before it creates nodes because otherwise the Namespace-Index would be invalid.
And then this would be necessary:
Thomas said
So a OPC UA client has to try to browse for an instance in the address space until the nodes get created by the OPC UA Server?
Or maybe I don't get your answer?
Can you maybe link to some specifications/docs?
Thanks!
05/30/2017
Offline
I don't quite get the issue.
A server has to add a NamespaceUri to the NamespaceArray before it returns any reference to that NamespaceIndex.
An entry in the NamespaceArray does NOT imply compliance with CS. It just means something in the address space might reference that URI. It is wrong for a client to assume that an entry in the NamespaceArray automatically implies that certain types/instances must be present.
If fact it is legal for a server that has been reconfigured to keep a reference to URI in its NamespaceArray to avoid changing indexes for other URIs even if there are no references in the address space to that URI.
03/19/2019
Offline
Randy Armstrong said
An entry in the NamespaceArray does NOT imply compliance with CS. It just means something in the address space might reference that URI. It is wrong for a client to assume that an entry in the NamespaceArray automatically implies that certain types/instances must be present.
Thanks for clarification, this is exactly what I assumed for the server-side. 
So how would you implement the client-side?
As mentioned above I had 2 approaches:
- try to browse until the nodes are present (poll)
- or in our special CS Namespace a possible solution would be to: (event)
Thomas said
In our case a possible solution would for example be, that the OPC UA Client listens to a GeneralModelChanged Event on the Namespace 0 Server-Object and waits until the CS Namespace is present in the NamespaceArray. Because then the client can be sure that the instance nodes were created by the OPC UA Server. Is this a viable way to go?
(because we have a GeneralModelChanged in our CS Namespace)
- ... other solutions?
Do you have better approaches for the client-side implementation?
05/30/2017
Offline
The GeneralModelChanged is not produced when the Value of a Variable changes. Clients are expected to subscribe.
Clients should not be using the NamespaceArray as a signal. Clients only use it when they have some other reason to request Nodes from the Server. In your case, you need to produce an event that indicates that the loading is done. GeneralModelChanged is specific to a Node so it will not do what you want.
I suggest the ProgressEventType:
https://reference.opcfoundatio.....35#Table56
The client waits until Progress=100.
03/19/2019
Offline
Thanks, nice suggestion.
To sum it up you would send this Progress Event to all active clients with following data, when the server finished loading?:
SourceNode = null-NodeId // because no Client initiated the Server to build the namespace - this is default behavior of a server
SourceName = "MyCSCustomName"
Context = null-NodeId // not needed
Progress = 100 // finished
05/30/2017
Offline
All namespaces should have a NamespaceMetadata Object.
https://reference.opcfoundatio.....ocs/6.3.13
Add Server => HasEventSource => NamespaceMetadata
Add NamespaceMetadata => GeneratesEvent => ProgressEventType
ProgressEventType: SourceNode/SourceName = NamespaceMetadata
03/19/2019
Offline
Thank you for clarification.
I'm going to bring this up in the Euromap/VDMA organisation as well, maybe other clients out there already faced a similar issue?
I think this topic is a quite important base functionality which is currently missing in the OPC UA specification. Do you think this too? In the future maybe the specification can be extended or an amendment for this could be created? Can you please discuss this internally in the foundation?
One last additional question: How would this work for Server/Client implementations which are not supporting Events?
Maybe the NamespaceMetadata-Type can be extended with a (optional) Ready/Progress-Property? But this would then be again a chicken-and-egg problem because how does the client know that the NamespaceMedatadata information model has finished loading/creating nodes and is ready to use.
Maybe an overall status (like the ServerStatus; maybe this could also be extended) for the Server would be also interesting for clients.
05/30/2017
Offline
You should add a mantis issue against Part 3:
https://mantis.opcfoundation.o.....default=no
There are a number of edge cases that need to be considered. Not supporting events is just one.
03/19/2019
Offline
Thomas Steiner said
Done!https://mantis.opcfoundation.o.....hp?id=8570
UPDATE: This won't be fixed by the Standard!
Reason: Nodes in the UA Address Space are dynamic - a Client can never be sure if a Namespace is fully loaded (all Nodes are present)
The standard committee suggested to use the Server State (e.g, NO_CONFIGURATION_2 or SUSPENDED_3) to indicate that.
1 Guest(s)
Usage Policy