Potentially vendor-specific (Siemens S7-1500) OpcUa server structure question about Codec/UDT registration

[peterfranciscook]

// (milo 0.6.16)
artifacts = [
        "org.eclipse.milo:sdk-client:0.6.16",
        "org.eclipse.milo:stack-core:0.6.16",
        "org.eclipse.milo:stack-client:0.6.16",
    ],

NOTE: @kevinherron mentioned in this thread that DataTypeTreeSessionInitializer is deprecated in milo 1.x, so this may be a milo 0.6.X quirk (but I suspect its more of Siemens OpcUa server configuration behavior).

Observation 1: after connecting a milo client to my PLC/OpcUa server and inspecting the DataTypeTree

client.connect().thenAccept(connectedClient -> {
    connectedClient.getSession().thenAccept(session -> {
        var oTree = session.getAttribute(DataTypeTreeSessionInitializer.SESSION_ATTRIBUTE_KEY);
        if (oTree instanceof DataTypeTree tree) {
            tree.getTree().traverse(Logger::debug);
        }
    });
});

... I notice anything that is a UDT defined in the Siemens project has 2 entries in the DataTypeTree

i.e. (for one UDT at random)

DEBUG: DataType{browseName=QualifiedName{name=PumpUDT, namespaceIndex=3}, nodeId=NodeId{ns=3, id=DT_"PumpUDT"}, binaryEncodingId=NodeId{ns=3, id=TE_"PumpUDT"}, xmlEncodingId=null}
DEBUG: DataType{browseName=QualifiedName{name=PumpUDT, namespaceIndex=4}, nodeId=NodeId{ns=4, id=2}, binaryEncodingId=NodeId{ns=4, id=3}, xmlEncodingId=null}

Browsing these nodes yields similar-looking results despite the different identifiers:

DEBUG: encodings for NodeId{ns=3, id=DT_"PumpUDT"}: [ReferenceDescription(referenceTypeId=NodeId{ns=0, id=38}, isForward=true,  nodeId=ExpandedNodeId{ns=3, id=TE_"PumpUDT", serverIndex=0}, browseName=QualifiedName{name=Default Binary, namespaceIndex=0}, displayName=LocalizedText{text=Default Binary, locale=null}, nodeClass=Object,   typeDefinition=ExpandedNodeId{ns=0, id=76, serverIndex=0})]
DEBUG: encodings for NodeId{ns=3, id=TE_"PumpUDT"}: [ReferenceDescription(referenceTypeId=NodeId{ns=0, id=38}, isForward=false, nodeId=ExpandedNodeId{ns=3, id=DT_"PumpUDT", serverIndex=0}, browseName=QualifiedName{name=PumpUDT, namespaceIndex=3},        displayName=LocalizedText{text=PumpUDT, locale=null},        nodeClass=DataType, typeDefinition=ExpandedNodeId{ns=0, id=0, serverIndex=0})]

DEBUG: encodings for NodeId{ns=4, id=2}:            [ReferenceDescription(referenceTypeId=NodeId{ns=0, id=38}, isForward=true,  nodeId=ExpandedNodeId{ns=4, id=3, serverIndex=0},            browseName=QualifiedName{name=Default Binary, namespaceIndex=0}, displayName=LocalizedText{text=Default Binary, locale=null}, nodeClass=Object,   typeDefinition=ExpandedNodeId{ns=0, id=76, serverIndex=0})]
DEBUG: encodings for NodeId{ns=4, id=3}:            [ReferenceDescription(referenceTypeId=NodeId{ns=0, id=38}, isForward=false, nodeId=ExpandedNodeId{ns=4, id=2, serverIndex=0},            browseName=QualifiedName{name=PumpUDT, namespaceIndex=4},        displayName=LocalizedText{text=PumpUDT, locale=null},        nodeClass=DataType, typeDefinition=ExpandedNodeId{ns=0, id=0, serverIndex=0})]

Observation 2: Only the numeric IDs actually work for encoding/decoding ExtensionObject (using the string ID fails). When I inspect a UaVariableNode for that UDT type, it points to the numeric NodeId when I call getDataType() rather than the NodeId with a friendlier name.

I can work with this - I'm successfully decoding streams (subscriptions) of UDTs in my app, but this behavior has always irked me.

Questions:

1. Is this "issue" specific to the way Siemens configures their PLC OpcUa server, or is it perhaps an artifact of the OpcUa API/spec/interface itself?
2. Apart from brittle hacks matching them on the common attribute of browseName (e.g. building a Map<NodeId, NodeId> to map the friendlier name to the numeric one, or an O(n^2) loop to update refs), is there a way to coerce milo or Siemens TIA Portal to link (on the VariableNodes themselves) one identifier versus the other?

Some more context - I have a codegen tool to write my UDT codec classes. Whenever the hardware team I work with updates the Siemens project, it shuffles the (numeric, but not String!) type and binary encoding ids of the UDTs (even if a particular UDT itself is unchanged), so I have to regenerate/recompile the UDT codec classes in order for the TYPE_ID and BINARY_ENCODING_ID fields to be usable. It only takes a few seconds to run, but I don't love checking in ~200 changed files to git every time this happens... Life would be slightly simpler along this axis of complexity if I could coerce Siemens or Milo to map to the String identifier rather than the numeric one.

Even more context - I do also have a startup service that validates Codec type id and binary encoding ids vs what is actually present on the server, and will have my app use the server's binary encoding ids if there is a mismatch, so its not entirely dependent on accurate TYPE_ID and BINARY_ENCODING_ID from the Codec classes themselves. Still, its a hassle.

[kevinherron]

I wonder if maybe your PLC has multiple "Server Interfaces" defined and the UDTs are defined in each explicitly, or get defined in each implicitly, etc...

I don't really know enough about how the Siemens OPC UA server works to answer any of this confidently.

[kevinherron]

Actually if I'm remembering this right, the NodeIds that are String-based are probably from UDTs defined the standard "SIMATIC" interface, and the numeric ones are from UDTs defined in a custom Server Interface.

[peterfranciscook]

Is the "Server Interfaces" node what milo looks for when it generates the DataTypeTree?

[kevinherron]

No, generating the DataTypeTree is done by recursively browsing the standard BaseDataType Node (i=24).

Server Interfaces are a Siemens specific thing. It's what they call their feature that lets you create custom namespaces in their server.

[kevinherron]

You could probably connect UaExpert to this same PLC, go browse DataTypes -> BaseDataType -> Structure ...

and find all these datatypes you're talking about.