Log In
Home
07/09/2019
Offline
Hi,
working on the View service set we encountered some sort of oddity: using a ReadRequest for the NodeClass attribute of a node doesn't yield something related to the NodeClass enumeration in the ReadResponse but just an integer (refering to the correct element in the enumeration). See the following pictures from a wireshark trace (using python-opcua, you get the same results using e.g. open62541):
ReadRequest (element in NodesToRead)
[3]: ReadValueId
NodeId: NodeId
.... 0000 = EncodingMask: Two byte encoded Numeric (0x0)
Identifier Numeric: 84
AttributeId: NodeClass (0x00000002)
IndexRange: [OpcUa Null String]
DataEncoding: QualifiedName
Id: 0
Name: [OpcUa Null String]
ReadResponse (element in Results)
[3]: DataValue
EncodingMask: 0x03, has value, has statuscode
Value: Variant
Variant Type: Int32 (0x06)
Int32: 1
StatusCode: 0x00000000 [Good]
What is the rationale behind that? Is that really the way enumerations (like NodeClass) are "encoded" into variants? I find that hard to believe.
Regards,
Sascha
05/30/2017
Offline
Enumerations are represented on the wire as Int32 values.
Int32 values are more efficient and allow the actual strings to be localized. There is no benefit in transmitting a local invariant string that would then require some mapping to the localized version. An index into an array of localized strings makes more sense.
Anyone who programs in languages like C/C++/C#/Java should have no issue with the idea that Enumeration are numeric values.
07/09/2019
Offline
I think I didn't make my point clear: the issue is not about enumerations being encoded as Int32 values, it is more about the absence of any hint what this Int32 is about and where it belongs to. I would expect that a decoder on client side would be able to return what the result is actually about (the '1' represents 'object' from the NodeClass node). Instead the service logic now has to resolve that integer value from the NodeClass node and also has to remember somewhere what it was actually requesting (e.g. keep state about this) so the response actually makes sense. For the whole chain of requests/responses up to session activation the de-/encoder is perfectly suited (as expected) for localizing encoded enumerations into strings (because you know the NodeId/Schema) and now suddenly the service logic must be responsible for that?
What I would have expected is something like a variant containing an extension object (with NodeId 257 for NodeClass) which again contains the enumeration value encoded as Int32. I know an extension object is not allowed to contain enumerations but this way the de-/encoder knows what to do with it.
I hope that clarifies what the question is about ...
05/30/2017
Offline
The philosophy of UA is the encoding on the wire specifies what is needed to decode and nothing more. Metadata that does not affect the structure on the wire comes from the AddressSpace. For example, the Duration DataType specifies a number of milliseconds but on the wire it is Double. To correctly handle data applications need to correlate the metadata with the values read. The handling of enumerations is consistent with that philosophy.
07/09/2019
Offline
Ok thanks, that clears things a little bit up. However, I think the whole spec regarding enumerations is way to much inspired by C and OOP languages where you have native support for enumerations and those being handled internally as integers with some compile time integration so the programmer does not have to care about the numbers behind enumerations at all. Erlang and other languages (mostly FP) do not have such a support. For a protocol that strives to be language agnostic this is somewhat suprising even though not such a big deal to take care of.
05/30/2017
Offline
That is why the XML Schema for OPC UA: https://opcfoundation.org/UA/s......Types.xsd
explicitly adds numbers into the names:
<xs:simpleType name="NodeClass">
<xs:restriction base="xs:string">
<xs:enumeration value="Unspecified_0"/>
<xs:enumeration value="Object_1"/>
<xs:enumeration value="Variable_2"/>
<xs:enumeration value="Method_4"/>
<xs:enumeration value="ObjectType_8"/>
<xs:enumeration value="VariableType_16"/>
<xs:enumeration value="ReferenceType_32"/>
<xs:enumeration value="DataType_64"/>
<xs:enumeration value="View_128"/>
</xs:restriction>
</xs:simpleType>
1 Guest(s)
Usage Policy