Hi,

Preferably that should never be done in my opinion even if the specification technically would allow it. Clients need to be specifically aware of that and even so could possibly cause data loss of any values that are of the “previous version” of the Structure type.

IF you have Structure types that would change their fields all the time and you only need to read these from a client, consider using an array of KeyValuePair Structures as the field of the Structure (or directly as the value) as “extensionfields”.

The binary encoding for the Structures (ExtensionObject) does only include the NodeId for the Encoding Id of the DataType, there is no practical version information. After that it is each field sequentially in their binary forms (as defined by the specification part 6). It is important to note that it is just the values of the fields in order, the ExtensionObject does not contain any other metadata than just the NodeId.

Clients will read either DataTypeDictionaries or in OPC UA version 1.04 possibly DataTypeDefinitions in order to obtain information how to decode that binary blob (keyed on the encoding nodeid). Once they are aware of that they can decode the ExtensionObject to a Structure.

If any modifications would be made for the type, clients would need to detect that and re-read the metadata. However at this point any old values cannot no longer be decoded (unless the clients will keep track of all old versions of the metadata and try them all until the ExtensionObject decoded and also have not missed any update as only the latest metadata information is available from the server).

For custom Structure types that are codegenerated and used via the generated classes in the SDK no modifications cannot be done (outside of runtime class bytecode manipulations).

In the SDK for non-codegenerated Structures the metadata is held in StructureSpecification objects and class DynamicStructure is used to represent any custom Structure. DynamicStructures are created from a StructureSpecification thus fields cannot be added/removed/modified to it as that would break the binary encoding. However you can create a new StructureSpecification that has the same encodings ids and thus could replace an existing type. It should be noted that this scenario is not tested in practice (and probably not many clients can handle that anyway..).

Additionally the StructureSpecification must be added to the UaServer.getEncoderContext().addStructureSpecification(…). in order to update the DataTypeDefinition Attribute value for the type. After this is done you need to ensure no DynamicStructure that are made with the old version is available to a client in any way (e.g. Value Attribute).

Additionally if the type was originally loaded from a NodeSet2 file and modified 2 things should be noted. 1) Any other place where that NodeSet was used now has the “wrong” encoding thus this shouldn’t be done in these cases 2) If the NodeSet contains a DataTypeDictionary (if it was made with a proper tool e.g. UaModeler it most likely contains one), you will need to edit that as well, since that is how pre UA 1.04 clients will try to read the metadata. How to do so is outside the scope of normal support, but the dictionary nodes are in Root/DataTypes/OPC Binary/* and each is a serialized XML documend as per OPC UA Specification 1.04 Part 5 Annex E “OPC Binary Type Description System”.