Supporting BrowseName with a different NamespaceIndex

[Rory___]

I am trying to connect a prexisting OPC UA client to an OPC UA server, but the server is doing some seemingly non-compliant things to do with the Namespace ID of the Browsename attribute for nodes.

The server has a different BrowseName Namespace index for each and every tag item on the server.
All of the tags are still in Namespace 1, but the BrowseName namesespace is different. This causes the TranslateBrowsePathToNodeIds() to fail to find each node as the client assumes that the browse name namespace will be the same.

https://reference.opcfoundation.org/DI/v102/docs/11#_Ref533069622
Here it says that
"Servers may often choose to use the same namespace for the NodeId and the BrowseName. However, if they want to provide a standard Property, its BrowseName shall have the namespace of the standards body although the namespace of the NodeId reflects something else, for example the EngineeringUnits Property. All NodeIds of Nodes not defined in this specification shall not use the standard namespaces."
But i am not entirely sure what this means.

Additionally on the server, the only references in each tag point to the BaseDataVariableType and there are no additional namespaces in the Namespace table other than the 2 namespaces:

http://opcfoundation.org/UA/
urn:unconfigured:application

So does anyone have any advice for the most correct way for the client to subscribe to these tags or find out which namespace to connect to from the clients side?

[Support Team]

Hi,

this indeed sounds like a badly implemented server (at least not compliant). As you correctly point out, the Browsename in theory can live in a different namespace (in most cases would be in same), however on client-side you can not "guess" it when attempting for the Translate. Furthermore having all process values in NS1 also is not good praxis, because the NS1 is "reserved" for server nodes (e.g. like the server-status, server-diagnostic, etc.), and its NS1 URI must be "unique". Having all nodes pointing to BaseDataType also seems odd, probably not using the type system at all.

The best approach would be to contact the server manufacturer and repair the server-side implementation. From your error description, the server implementation seems to be based on open source "Open62541", but being used totally wrong and incomplete.

However you can not fix all such issues on the client-side.