OPC UA strange things

OPC UA has a lot of surprising things. In this article, we will try to list some of them.

NodeID types

It is impossible to reuse code for parsing Node IDs for JSON and UADP.

JSON NodeID types:

  • Numeric - 0

  • String - 1

  • Guid - 2

  • ByteString - 3

UADP NodeID types:

  • TwoByte - 0

  • FourByte - 1

  • Numeric - 2

  • String - 3

  • Guid - 4

  • ByteString - 5

  • OPC UA encodings JSON and UADP have different NodeID formats and type enums. There can be a little hack: UADPNodeIDType = JsonIDType + 2 can work. But it is useless, unwanted logic.

  • Numeric types can be inferred from the range of a number. For example, if a number is in the range of 0-255, it is a TwoByte NodeID. If a number is in the range of 0-65535, it is a FourByte NodeID. If a number is in the range of 0-4294967295, it is a Numeric NodeID. The problem is that some systems can force the use of, for example, Numeric types instead of TwoByte. In this case, it is impossible to infer the NodeID type from a number.

Namespace Index not constant

The namespace index is not constant in general. Every server can load several companion specifications from XML files (Nodeset2.xml). If two servers control the same kind of machines but load XML in different order, you will get the same address space hierarchy but NodeIDs will have different NamespaceIndex.

It is unclear how to handle this situation. The only way is to use ExpandedNodeID with NamespaceURI. But I haven’t seen any server that uses NamespaceURI in general; they use NamespaceIndexes.

The second problem: The address space of a server contains two predefined namespaces: NS0 with index 0, and local namespace with index 1. Usually XML files do not use NamespaceURI for NodeIDs but use NamespaceIndex. Namespace indexes in files start from 1, NodeIDs are in string representation. Because of this, loading any XML file requires fixing NodeIDs: parse, change namespace, and save back.