Hi,

This is a complex topic. I do skip some details in this answer.

I do assume here you mean about the current SDK 4.x and not something historical. Though, I must say that some of the documentation is lacking and a bit outdated.

SDK 1.x didn’t support custom complex types. 2.x supported (only) via Codegen, in 3.x we added dynamic ways that do not need Codegen and now in 4.x basically the intention (and most of the reality and common use-cases) is that Codegen is just basically syntactic sugar and optional. You can see this in action if you use https://www.prosysopc.com/products/opc-ua-browser/ (that is made using 4.x), it should be able to visualize most Structures in the Attributes view. Assuming it can visualize it, any Client made with the SDK should as well. If not, let us know.

The core OPC UA namespace “http://opcfoundation.org/UA/” is special and already generated by us within the SDK as it internally heavily relies on it. Or technically it is generated from a special NodeSet that contains both the core namespace and “OPC UA service descriptors” (that are also work the same way as Structures).

There are 2 parts to custom Structures: one is that the SDK must be able to encode/decode them and second is that you as a user must have API to use them.

By default UaClient during connect will read/browse the Types part of the server, one of the reasons is that it fetches the metadata of custom structures (skipping other reasons here). There are nowadays multiple ways in OPC UA to represent them. Historically there were so called “DataTypeDictionaries”, but the modern way is via (1.04 added this) DataTypeDefinition. If SDK cannot resolve everything via DataTypeDefinition it will look the dictionaries (but they cannot represent new 1.04 features such as multidimensional fields).

Thus, if you Read a node that had a Structure Value, you should receive DataValue->Variant->Structure instance. If not and you received an ExtensionObject instead, it means SDK wasn’t able to decode it (or that you have set the UaClient not to read the types).

If you have a com.prosysopc.ua.stack.builtintypes.Structure at hand, you can call .specification() on it to get a StructureSpecification and then .getFields() to get the Structure fields, then you can interact on the Structure with generic set/get taking in the fields (FieldSpecification or the name).

If you do not have the structure at hand and just wish to write one, assuming you have connected to the server, you should be able to find the StructureSpecification via (UaClient) client.getEncoderContext().getStructureSpecification(UaNodeId). Then you can call toStructureBuilder and built the Structure via the Structure.Builder. If you wonder why there is a Builder, I hope some distant day in the future we can make Structures immutable and preferably where possible they should be treated as such now if given to SDK (e.g. as a node value), even though they technically are not for historical reasons.

It is not possible to simulate this with the free version of Simulation Server, but technically speaking you kinda cannot even with the Pro version (you can temporarily set a value, but we cannot persist structure values yet, will be added at some point in the future). However, the SDK samples sampleconsoleserver does have 2 custom Structure types defined in code, see com.prosysopc.ua.samples.server.MyNodeManager.createCustomStructure() and com.prosysopc.ua.samples.server.MyNodeManager.createCustomStructureWithCustomStructureField(). That also shows a bit of using the StructureSpecification and making the instances of those structures.

Since this is quite long now I’ll stop here, but let us know if you have more questions or some part of the above was unclear.