06/14/2019
Hi all,
I’ve to read data from an OpcUa server where the nodes have the same identifier and are located in different namespaces but the namespaces have the same uri .... sounds weird .... but here are the details...
The NamespaceTable looks like this:
[0] https://opcfoundation.org/UA/
[1] urn:Data
[2] urn:Data
The nodes to read are:
ns=1;s=TheNode
ns=2;s=TheNode
As I heared, the index should never be used to specify the node, instead the namespace uri shall be used.
In this case with this server, both nodes which are at different namespace index have the same namespace uri which means that if I specificy the node by uri I'm not able to distinguish between the two nodes ...
The first node has the identifier s=TheNode in namespace uri 'urn:Data' and the second node has also the identifier s=TheNode in the namespace uri 'urn:Data'
I wonder if such a namespace table matches the opc ua specification or not.
In the specification I could not find any part which really declares that each namespace uri in the namespace table has to be unique.
By reading the following parts ... https://reference.opcfoundation.org/Core/docs/Part3/8.2.2/ and https://reference.opcfoundation.org/v105/Core/docs/Part4/7.30/ it can be inferred that the uri has to be unique because otherwise it would be impossible to find the index by having the uri, but there isn't any direct statement in the specification that it has to be unique.
So the big question is ... does not unique namespace uri's go conform with the OpcUa specification?
Thanks
05/30/2017
The NamespaceIndex is an alias for a URI within the context of a Session.
One URI shall have exactly one entry in the Server's NamespaceArray.
A NamespaceUri is a URI that conforms to RFC 3986
https://reference.opcfoundatio.....Part3/3.2/
If any NodeIds or BrowseNames are persisted for use in a future Session then the URI shall be saved and used to look up the current NamespaceIndex when a new Session is established.
NamespaceIndexes assigned by a Server shall not change while any Session is active.
Even though these rules may not be explicitly stated they should be obvious from the description on how Clients are expected to use saved URIs to look up the current NamespaceIndex and that multiple NamespaceIndexes for the same URI make no sense because it would create ambiguities and IOP issues.
See:
https://reference.opcfoundatio.....rt3/5.2.2/
https://reference.opcfoundatio.....rt5/6.3.1/
An explicit statement will be added to specification as well as a CTT test will be added.
06/14/2019
Thanks for clarification and adding an explicit statement in future specifications.
Another question on this....
The NamespaceTable looks like this:
[0] https://opcfoundation.org/UA/
[1] urn:Data
[2] urn:Data
In https://reference.opcfoundation.org/Core/docs/Part5/6.3.1/ it is written that....
Index 0 is reserved for the OPC UA namespace, and index 1 is reserved for the local Server.
Does this mean, that the namespace table of this specific server is not only incorrect because of the duplicate namespace uri?
Shouldn't there be a namespace index 1 with something like urn:own-hostname:OPCUA:ServerXy
- so like this?
[0] https://opcfoundation.org/UA/
[1] urn:own-hostname:OPCUA:ServerXY
[2] urn:Data
....
05/30/2017
Namespace Index 1 is the ApplicationUri which is embedded in the Certificates and returned in FindServers/GetEndpoints.
The index 0 of the ServerArray and index 1 of the NamespaceArray shall be the same value.
I see another explicit statement is needed in the specification.
05/30/2017
The rules for XML NodeSets files are different from the behavior expected for the NamespaceArray Variable in the Server AddressSpace.
The only requirement for NodeSets is index 0 be the UA namespace and that is forced because the UA namespace URI is not included in the namespace table and assumed to be 0. Other indexes can be assigned to any namespace.
The expectation is a server loading a NodeSets would translate the indexes to match its NamespaceArray.
1 Guest(s)