Hi,

It is a bit more complex/experimental system, codegen way is much more preferred in general if possible. Assuming you got the ExtensionObject as the value from the read calls (if it was not possible to decode an ExtensionObject to a Structure, you should get the raw ExtensionObject):

It is important that the same TypeDictionary object is used in multiple calls. On the first decode call it will read the DataTypeDictionary nodes of the server. This might take a long while (it is quite many service calls due to how it works), but the result is cached in the given TypeDictionary object. Note that this relies entirely on the server to produce correct data in the nodes.

The resulted object is a DynamicStructure instance. It has a StructureSpecification (.getSpecification()) and a List of FieldSpecification (.getFields()). You can get/set values to it by field name or the given field specification.

P.S. 3.1.8 made some improvements https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_Java_SDK_Release_Notes.html#version-3-1-8.

P.S.2. Generally speaking, once an UA model is published, the Structures within should never change. Doing so will break binary compatibility with all previous versions of the model. Assuming you control all the servers and clients dealing with this model, it is not an issue.

Hi,

That method will try it’s best to decode the given ExtensionObject. You call it once per ExtensionObject you which to decode. On the first decode call it will read the DataTypeDictionaries of the server, and this call may take long (see the end of this post). The result of reading those will be cached.

The decoding has been successful, if you will get the DynamicStructure object out of that call, otherwise you will get DecodingException as indicated by the method signature. If the call does not return, it is still processing it (the “take long” above can be minutes, depending on e.g. latency to the server). If either happens, let us know and hopefully we can make it better.

If the server is an UA 1.04 server and supports the new “DataTypeDefinition” Attribute defined in 1.04, this entire process could be skipped, as the DataTypeDefinition is the superior way. In practice the DataTypeDictionary system can be considered deprecated in 1.04, to quote the spec 1.04 Part 5 Annex D (for the DataTypeDictionary):

“This annex defines a way to provide encoding information for custom DataTypes. In previous
releases of t he specification this approach was defined in Part 3. In Part 3 a simplified approach
is now defined having a DataTypeDefinition Attribute on the DataType Node. The approach
using DataTypeDictionaries is provided for backwards compatibility and in case some specific
requirements cannot be fulfilled with the simplified approach. It is recommended to only use the
approach using the DataTypeDefinition Attribute.”

Our SDK as of 3.x supports only UA 1.03, and therefore cannot use that approach (assuming even the server would support it). We are currently working on SDK 4.x which will then support UA 1.04. 3.0.0 was released less than a year ago, it took longer than expected, but there we decided that we need some support for decoding unknown Structures, so the result of that is the TypeDictionary class. Most likely we will enchance the system to prefer the new Attribute in 4.x where possible.

Using the DataTypeDictionary approach you cannot simply “Read DataType”. The entire process goes like:

0.0. First call to decode; TypeDictionary will init itself.
1.1. Get all targets of HasComponent References under the OPCBinarySchema_TypeSystem (i=93 in standard namespace, the node is “Types/DataTypes/OPC Binary”).
1.2. If the given target is of a known namespace and codegen has been run for it and resulted classes are registered to the SDK, skip the rest for that target.
2.1. Read each target (they are DataTypeDictionaryType’s) Value Attribute. It is a ByteString containg an UTF-8 encoded XML document that adheres to the OPC Binary Type Description System, defined in 1.04 Part 5 Annex E. Basically it is a complex and completely parallel system to the normal binary encoding rules of OPC UA, as defined in the Part 6, but the resulted data is usually the same. Our SDK makes the assumption that the data actually is always the same, i.e. it is possible to decode/encode the data as per normal Structure encoding rules that are defined in Part 6, as the SDK “links” the dictionary system (unknown parts,”Names”) and the normal system (known parts, “NodeIds”).
2.2. Resolve each XML document obtained in 2.1. separate Enumeration and Structure datas.
3.1. Enumerations. We need to link a “Dictionary” Enum and a real Enumeration. The only way to do this with the dictionaries is in practice to guess the type per the names in the AddressSpace (BrowseNames) vs the Dictionary “Names” (Dictionaries do not use NodeIds, at all).
3.2. To resolve step 3.1, we in practice has to Browse all Enumeration types in the server.
4.1. Structures. To obtain the “linking mapping”, we need to browse the “chain” DataType node of the Structure DictionaryNode defining that Structure, so that we know which Dictionary “Name” means which NodeId. This information is provided as such that we Browse the Components of the dictionary node, these have reverse reference to a “Default Binary” node, which then has reverse reference to the DataType node. This has to be done for every Structure defined in the dictionary.
5.1. Making real StructureSpecifications. Given that Structures can refer to other Structures, Enumerations and other types, we have to read ALL dictionaries (since the dictionary Structures refer the types via XML namespaces, and this info is only present in the document itself).

If the DataTypeDefinition could be used instead, it would be simply another Attribute in the DataType node, and it would contain the information about what fields that Structure has and we could basically go directly to step 5.1., as that definition uses the NodeIds. It is possible that the .NET example you mentioned does this.

P.S. Generally we are aware that this could be a lot better. We might need to do some architectural changes before we can get to a point where “normal” and “unknown” Structures would behave exactly the same.

Hi,

At least that is the 1.04 standard model, so it is a possibility (the model by itself does not tell it). The practical way is to use latest version (1.5.0) of UaExpert (https://www.unified-automation.com/products/development-tools/uaexpert.html), navigate to the DataType node of the custom Structure (under Root/Types/DataTypes/BaseDataType/Structure/your_type), and see if the Attributes widget displays something else than BadAttributeIdInvalid for the DataTypeDefinition Attribute. If it does, then it supports it (at least for that type, but generally I would assume for every Structure).

Hi,

In some 4.x version of the SDK, given that DataTypeDefinition value is a Structure by itself (and those types are defined in the standard 1.04 model). Hopefully in 4.0.0, but no guarantees. No exact date when that would be released either.

Hi,

We are now talking about something that in the typical scope of OPC UA is considered bleeding edge or brand new, something that has existed a fraction of the time the technology has existed. For example (I checked that) this is not something that is currently supported in our S7 device here at the office. So probably this is something that is just done in latest firmware to those devices (same with the UaExpert).

We and Unified Automation are different companies, that do “cross-resell” eachothers products.

Basically the Java SDK documentation is what is found in the ‘tutorial’ folder of the SDK package + the codegen manual in the ‘codegen’ folder and the javadocs in the ‘javadoc’ folder. The sample applications SampleConsoleClient/Server demonstrates the use of the basic features. For the UaModeler part (that is Unified’s tool) you can output the model as the NodeSet2 XML and use that in our codegen. Note however that it might be easier to just export the model from TIA portal and tweak those parts that might not work with our codegen.

And generally yes, we want to support this new feature. We just need to support 1.04 by itself first in order to do that. The fact that such large player (Siemens) is supporting this will increase the priority of us making support of the feature (but generally we are choosing from a very large pool of stuff to do/support, due to the nature of OPC UA, of course we would like to support everything right now, but that in reality is not possible).

P.S. If you go the TypeDictionary way (based on another case) you have to call setTreatOpcStringAsOpcCharArray(true) for the TypeDictionary before the first decode. 1.04 + 1.03 errata introduced a somewhat breaking change and S7 appears to use the newer definition of opc:String in the context of the dictionaries.

Hi,

Generally I recommend trying and not speculating.

You must use a configuration file (the model file is not a configuration file) as explained in the manual. Please see the manual and the sample configuration files (for the command line version) in the commandline/configexamples.

Then you will most likely run into one of the possible problems (explained previously by Heikki) with the model, unless Siemens has fixed those. First is that the models previously at least missed SymbolicName entries for ones having BrowseNames containing characters that cannot be used in code. Codegen of the SDK 3.1.8 workarounds this to some extent. The second is that the NodeSet2 models utilizes a “NamespaceTable” concept for mapping number to a String to avoid repeating namespaceuris. This is the same logic in general of UA that the NodeIds have index that points to the NamespaceArray of the server.

The model files typically only contain uris needed by the model, however the siemens model did contain all of them, including the one which is typically “1” in the server. Codegen needs all the models the model uses/depends on in order to work at the moment. But there is no model for this “1” namespace, as it in practice only contains dynamically generated nodes (this is a bit complex to explain, please let me know if this is not enough). Therefore you will need to either, edit the file so that it makes sense if you remove the first entry in the NamespaceUris XML block so that the namespace indexies match, or alternatively use a “dummy” entry of an namespace not used by the model, but one that is valid, so that the indexies stay the same.

Additionally, please note (as explained in the manual), that the codegen will work on most 1.03 models as the SDK uses/support 1.03. Therefore if the model uses types or features that are only introduced in 1.04, it might not work. Please let us know if there are problems.

Hi,

I guess it is not that clear then, should be improved in the future..

I previously mentioned (in some of the above posts) that this is one of the problems with the models exported from TIA portal, and that the codegen within 3.1.8 does some workarounds for this (see Codegen part of https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_Java_SDK_Release_Notes.html#version-3-1-8), is this the output of the 3.1.8 codegen? (I would be assuming it is the output of 3.1.6, per your initial post). Alternatively the proper fix (for TIA Portal) would be to include SymbolicName entries for each BrowseName within the model that contains names that are suitable as variable names in code. The SymbolicName is defined in the 1.04 Part 6 Annex F.
“SymbolicName … String … A symbolic name for the Node that can be used as a class/field name in
auto generated code. It should only be specified if the BrowseName cannot
be used for this purpose.
This field does not appear in the AddressSpace and is intended for use by
design tools. Only letters, digits or the underscore (‘_’) are permitted”