OPC UA NodeId, namespace index and ExpandedNodeId

Structure

A NodeId identifies one node in one server. It has two parts:

• NamespaceIndex (UInt16) — position of the namespace URI in the server's NamespaceArray;
• Identifier of one of four types:

String format

OPC 10000-6 defines the text form:

ns=<namespaceIndex>;<type>=<value>
ns=3;s=Motor1.Speed
i=85                       (namespace 0: the ns= part is omitted)

NodeIds in namespace 0 (http://opcfoundation.org/UA/) use only the identifier form, e.g. i=85 for the Objects folder, i=2258 for the server's current time.

Namespace index vs namespace URI

The index is local to a server and may change when the server is reconfigured, when a project is downloaded again or when the order of namespaces changes. A client that stores ns=4;s=Motor1.Speed permanently can break silently. Robust clients store the namespace URI and resolve the index after connecting by reading Server.NamespaceArray (i=2255).

ExpandedNodeId

ExpandedNodeId adds the information needed outside the server's own index table:

nsu=http://example.com/plant/;s=Motor1.Speed      (namespace URI instead of index)
svr=1;nsu=http://example.com/plant/;s=Motor1.Speed (node in another server, ServerIndex 1)

Reserved characters in URIs are percent-encoded; a ; inside a URI is written as %3B. ServerIndex 0 means the local server.

Why a NodeId does not resolve

• Copying a NodeId from one PLC project to another: the index differs.
• Writing ns=2;i=Motor1 — a string identifier needs s=.
• Adding quotation marks around Siemens tag names: the browse path in TIA uses "DB"."Tag", the NodeId string is usually ns=3;s="DB"."Tag" including the quotes — always copy from a browsing client rather than typing.