OPC-UA Tags break on Server with changing NamespaceArray indexes

@Kevin.Herron I have an OPC-UA server that aggregates multiple OPC-UA servers into a single address space. This server generates the NamespaceArray on boot based on which server it connects to first. This means that for each reboot of the aggregating OPC-UA server, the Indexes associated with each Server’s nodes may swap around.

When the namespace indexes change, this breaks Ignition’s tags subscribed to the nodes, as the namespace index appears fixed from the time the tag was created.

Other software like UA Expert is tolerant of the namespace index changing, as they are following the OPC-UA spec 1.03 Part 5 section 6.3.1:

NamespaceArray defines an array of namespace URIs. This Variable is also referred as
namespace table. The indexes into the namespace table are referred to as NamespaceIndexes.
NamespaceIndexes are used in NodeIds in OPC UA Services, rather than the longer
namespace URI. Index 0 is reserved for the OPC UA namespace, and index 1 is reserved for
the local Server. Clients may read the entire namespace table or they may read individual
entries in the namespace table. The Server shall not modify or delete entries of the namespace
table while any client has an open session to the Server, because clients may cache the
namespace table. A Server may add entries to the namespace table even if clients are
connected to the Server. It is recommended that Servers not change the indexes of the
namespace table but only add entries, because the client may cache NodeIds using the indexes.

Nevertheless, it might not always be possible for Servers to avoid changing indexes in the namespace table. Clients that cache NamespaceIndexes of NodeIds should always check when starting a session to verify that the cached NamespaceIndexes have not changed.

Sorry, we definitely do not have a solution for this.

There’s another part of the spec that explicitly says NodeIds shall not change, even on reboot:

Part 3, Section 5.2.2:

A Server shall persist the NodeId of a Node, that is, it shall not generate new NodeIds when rebooting.

I’m not sure we can ever fix this in a backwards-compatible manner. It would require that the OPC Item Path either change to represent an ExpandedNodeId, which can optionally reference a namespace URI instead of index, or that it be broken into two parts (URI and identifier).

Now that I’ve said this, I’m thinking this could actually be the path forward… I’ve gotta think about it more. Existing OPC Item Paths would just remain relatively indexed and you would optionally be able to explicitly use a namespace URI instead of index. The drag n’ drop behavior would probably have to change to use the namespace URI to be safe, and then all the functionality to translate URIs to indices on client connect would have to be considered as well…

Thanks Kevin for the consideration. Seems like an unfortunate lack of consistency within the OPC-UA spec itself: how can the namespace index be allowed to change (Part 5 section 6.3.1), but the nodeid be restricted to not change, which is made up of a namespace index (Part 3 section 5.2.2)?

Yes, it’s definitely an inconsistency.

@321liftoff would you be able to test a beta OPC UA module with a fix for this?

Sure. Let me know how to get it. Thanks!

I’m having the same issue here. Has anyone found a work-around to the problem ?

@Michiel.demiddelaer this was addressed starting in 8.1.0.