Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Where to find string notation of a node in the OpcUa reference
December 17, 2021
11:23, EET
Avatar
rocket science
Member
Members
Forum Posts: 52
Member Since:
March 16, 2017
sp_UserOfflineSmall Offline

Hi,
I wonder where I can find the string notation of a node in the OpcUa reference.
With string notation I mean ‘ns=3;s=abcde’ or ‘ns=4;i=12345’
I know this page https://reference.opcfoundation.org/v104/Core/docs/Part3/8.2.3/ but it doesn’t say anyting about the format.

In which part of the reference it is specified that the format of the string representation is ns=;=someValue

Thanks!

December 17, 2021
16:27, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 726
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Hi,

This is a … somewhat complicated topic.

Like, the actual “format” unless I forget is only the “XML encoding” of NodeId, thus “defined” in https://reference.opcfoundation.org/Core/docs/Part6/5.3.1/#5.3.1.10.

BUT! I would personally say it would be better to say “there is no such format, as no NodeId should ever be referred by the namespace index, but instead by the namespace uri”. The index is basically just an optimization in the binary (numbers are shorter in binary vs. the uri) and xml/json (uri takes more space in plaintxt format). Once it leaves that context it should be the uri, never the index. But pretty much everyone (we including) has used that format in UIs etc. and we have also failed this in the SDK by having APIs that use NodeId (but no-one could maybe have seen this 10-15 years ago).

Anyway, this is why most of the newer SDK APIs such as PubSub instead refer things instead via “UaNodeId” (so basically an “upgraded NodeId”), which uses the “uri form” via UaNamespace objects (that we weak-intern and thus can be reference-equals-compared in pretty same time as an index would be).

Though it should be noted that an index-based representation is maybe… nicer and shorter in UIs, but there is the danger that the mapping to the actual namespaceuri if forgotten (the indexes can freely change between sessions and restarts, there are no guarantees about them). So it is sort of a “known problem” of OPC UA in my mind. We have had some ideas about some “shorthand aliases” that could maybe be displayed instead of an index (e.g. “di” for the DI companion spec), but no actual implementation yet.

January 11, 2022
11:12, EET
Avatar
rocket science
Member
Members
Forum Posts: 52
Member Since:
March 16, 2017
sp_UserOfflineSmall Offline

Hi, thanks for the information where to find it in the reference – I was really searching for hours but could find it 😉

Bjarne Boström said
…BUT! I would personally say it would be better to say “there is no such format, as no NodeId should ever be referred by the namespace index, but instead by the namespace uri”….

yes, I know. But we have one particular OpcUa Server where the manufacturer had the idea to provide two namespaces with same namespace name on different indexes (and provide in each namespace a node with the same identifier) – so it is impossible to get to the correct node with using only the uri because the uri is the same for both nodes. The manufacturer will not change this, but he guarantees that his namespace indexes will not change between session and/or restarts.

January 11, 2022
11:58, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 726
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

So just to be sure, you mean the NamespaceArray would have the same entry more than once? Then that server is not a valid OPC UA server and must be fixed.

I guess you should ask the OPC Foundation for “proof” that the NamespaceUris must be unique. Best would be if the spec would have it somewhere to be easily linked, but I have not found any like direct statement.

It can be inferred by combining multiple points, but not sure if that is .. enough.

For example, https://reference.opcfoundation.org/Core/docs/Part3/8.2.2/

“The namespace is a URI that identifies the naming authority responsible for assigning the identifier element of the NodeId. Naming authorities include the local Server, the underlying system, standards bodies and consortia. It is expected that most Nodes will use the URI of the Server or of the underlying system.

Using a namespace URI allows multiple OPC UA Servers attached to the same underlying system to use the same identifier to identify the same Object. This enables Clients that connect to those Servers to recognise Objects that they have in common.


Plus then the notes that an index form is used only as an encoding optimization.

“Namespace URIs, like Server names, are identified by numeric values in OPC UA Services to permit more efficient transfer and processing (e.g. table lookups). The numeric values used to identify namespaces correspond to the index into the NamespaceArray. “

It would not be possible to do the mapping in reverse (as one should always search which index to use per the uri, if they are not unique this cannot be done => they must be unique).

Combined with https://reference.opcfoundation.org/v105/Core/docs/Part4/7.30/ and the “remote references” possibility (please do not use them unless you have to, but servers here to prove a point).
” nodeId ExpandedNodeId NodeId of the TargetNode as assigned by the Server identified by the Server index. The ExpandedNodeId type is defined in 7.16.If the serverIndex indicates that the TargetNode is a remote Node, then the nodeId shall contain the absolute namespace URI. If the TargetNode is a local Node the nodeId shall contain the namespace index.”
IF the uris would not have to be unique, that would not work => they must be unique (as the NamespaceArray order can change at will e.g. on a server restart, a reference to other server would not “know” which index would have the uri at a given time, it must use the uri form of ExpandedNodeId, henceworth the uri is the defining part of uniqueness. Since this would be translated to an index for by a client that is connected to the both servers, it must be able to do unique ExpandedNodeId -> NodeId conversion, and that can only happen if there is an unique uri -> index mapping.

January 11, 2022
13:58, EET
Avatar
rocket science
Member
Members
Forum Posts: 52
Member Since:
March 16, 2017
sp_UserOfflineSmall Offline

Yes, same namespace uri at different indexes as described in my other topic (https://forum.prosysopc.com/forum/opc-ua/duplicate-namespace-name-in-namespace-table/)

The manufacturer says that it is not directly forbidden by the spec, so they are doing it. I told them that this does not go conform with the spec, but they say it is conform with the spec … weird…

Nevertheless to get data we are now using NodeId.parseNodeId(“ns=1;s=xyz”) and NodeId.parseNodeId(“ns=2;s=xyz”) to get the data from the nodes in the two namespaces with the same name.
There namespace array looks something like:
ns=0: http://www.opcfoundation
ns=1: Data
ns=2: Data

We know that it does not go conform with the spec, but as the manufacturer is not going to change it and does not accept that they are not spec conform I’m really hoping that sooner or later they will get troubles with their interpretation of the specification.

I guess you should ask the OPC Foundation for “proof” that the NamespaceUris must be unique. Best would be if the spec would have it somewhere to be easily linked, but I have not found any like direct statement.

I’ll take that into consideration….

January 12, 2022
18:02, EET
Avatar
Jouni Aro
Moderator
Moderators
Forum Posts: 918
Member Since:
December 21, 2011
sp_UserOfflineSmall Offline

This was discussed yesterday at the OPC Foundation UA Working Group, and the consensus was that all entries in the NamespaceTable should be unique.

The following sentence at https://reference.opcfoundation.org/Core/docs/Part3/8.2.2/ defines the uniqueness in practice:

“Namespace URIs, like Server names, are identified by numeric values in OPC UA Services to permit more efficient transfer and processing (e.g. table lookups). The numeric values used to identify namespaces correspond to the index into the NamespaceArray. “

January 13, 2022
13:13, EET
Avatar
rocket science
Member
Members
Forum Posts: 52
Member Since:
March 16, 2017
sp_UserOfflineSmall Offline

Thanks,

I also just got information from the OpcFoundation that the entries in the namespace table should be unique.

They will also add an explicit statement to the specification as well as a CTT test will be added.

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 267

Currently Online:
22 Guest(s)

Currently Browsing this Page:
5 Guest(s)

Top Posters:

hbrackel: 113

pramanj: 86

ibrahim: 74

kapsl: 57

rocket science: 52

gjevremovic: 49

Xavier: 42

fred: 41

TimK: 41

Fransua33: 39

Member Stats:

Guest Posters: 0

Members: 1743

Moderators: 17

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1206

Posts: 5137

Newest Members:

LimaomoT, eulaallcot, brain7955241817, barbaravillalobo, widallet, erminovski, etsuko73u61420, donnyblaxland, DonaldHAp, kelvin6887

Moderators: Jouni Aro: 918, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne Boström: 726, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 24, Teppo Uimonen: 21, Markus Johansson: 36, Niklas Nurminen: 0, Matti Siponen: 163, Lusetti: 0

Administrators: admin: 1