Hi,

In a general scenario it is not possible to avoid decoding the values (to a point) in OPC UA.

It would be technically possible to implement the decoding as such that you would get both the encoded and decoded values (after decoding), however the current architecture of the Java Stack (on top of which our SDK is built) does not make that possible.

Technical explanation below:

All Attribute Reads are done using the Read Service call. Client send ReadRequest, which contains an array of NodeId/Attribute combinations and then the server responds with ReadResponse.

I skip some of the details, however eventually the client has the ReadResponse as a byte array

ReadResponse contains:
* ResponseHeader
* Array of results
* Array of diagnostics

The encoding rules for Service requests/responses are the same as for Structures, each field is encoded in order to the stream, therefore the first bytes belong to the ResponseHeader. After that is the 2 arrays. Arrays are encoded as Int32 and after that each element in sequence.

The ResponseHeader (see spec 1.03 Part 4 section 7.29) size is not constant (if diagnostics are off it might be, however that does not help much here), therefore it must be decoded in order to know where the array of results begin. After that we can read how many DataValues are encoded. However as with the ResponseHeader, the encoded size of the DataValue is not constant, as it depends of the encoded value. Therefore the general problem here is that it is impossible to say which bytes belong to which DataValue without decoding them in order to know where the next one begins.

The DataValue.Value field (Variant) size depends on the value (type, array dimensions), unless it is a Structure (i.e. ExtensionObject), the size of the value is not part of the encoding. Most built-in-types have also masks that define which fields are present and such the entire value pretty much has to be decoded to determine the size.

After a DataValue has been decoded it should technically be possible to persist the raw value as the begin and end index for the original byte array for the entire request is now known. However the current stack implementation takes the entire request byte array as a queue and pops individual parts away. It would require some redesigns.

Additionally there are a few catches here that should be mentioned: Many of the encoded values do contain server-specific parts, namely the NamespaceIndexies, these are part of NodeIds and QualifiedNames, which makes the encoded values only valid if they were used for a server that has the same exact NamespaceTable as the one from which they are read. Also the encoded value is not the complete information. For example Enumerations are encoded as Int32. Therefore without the actual DataType Attribute value together with the EnumStrings Property of the DataType node, it is not possible to say which enum value it was. The same is with every subtype of some non-structure Built-in-Type, e.g. the Image subtypes are ByteStrings when encoded, therefore without the information model of the node it is not possible to know which image subtype it was.

– Bjarne

P.S. If only one attribute would be read at a time, then the decoding could be technically skipped (if diagnostics are off) as would be possible to know the exact position of that in the byte array. However at least in your case this would make the reading order of magnitude slower.