Actions
Suggestions for Enhancing OPC UA Security Features
Hi, I have a couple of questions. We are currently working on our own UA Stack implementation (verifying it using the UA-Nodeset repo) and there are some things we need to wrap our mind around:
1. The UA-Nodeset repo contains the Binary Schema for Data Types (the .bsd file) but that file is called “obsolete” … why? What is the alternative Schema which can be used for de-/encoding purposes?
2. Is the concept of inheritance supported within that schema? Annex E in part 5 explains the “OPC Binary Type Description System”, e.g. the format for the schema. So far I couldn’t find anything about this in there.
3. In the .bsd schema file it appears that there is a “BaseType” and “SourceType” attribute but for de-/encoding purposes they seem to be unimportant. What is the intention behind BaseTypes and SourceTypes (if not inheritance)?
Regards,
Sascha
The UANodeSet schema now provides all information needed by encoders/decodes.
See the DataTypeDefinition element which appears in each UADataType element.
The DataTypeDefinition has also been added as an Attribute for DataType nodes in 1.04.
The BSD required that inherited fields be copied into each subtype. The BaseType was FYI.
Thanks for your quick response!
So, I guess the files we should look for are the NodeSet2 files? Which one of those contains all DataTypes? My guess is that “Opc.Ua.NodeSet2.Services.xml” contains everything.
I think for de/-encoding purposes it is assumed that all built-in data types from part 6 (the UADataTypes which have a HasSubType of “BaseDataType”) can be decoded without further knowledge? I am asking about this because the “obsolete” .bsd file defined a format which was based on base types (and not built-in types). Example: The UADataType “NodeId” (which is a built-in type) which has a dedicated Scheme in the obsolete .bsd file but not anymore in the “Opc.Ua.NodeSet2.Services.xml”.
Can you clarify this?
Opc.Ua.NodeSet2.Services.xml includes all of the types needed for services which do not appear in the address space as DataType Nodes.
BuiltIn types are “built in” meaning decoders need implicit knowledge on how to handle.
Thanks 🙂
I have some follow-up questions:
1. The ‘DataTypeDefinition’ in the Opc.Ua.NodeSet2.Services.xml is barely used even though you mentioned that it appears in each ‘UADataType’. To my understanding this is only needed for custom Enumerations and custom Structures which are not predefined in the Opc.Ua.NodeSet2.Services.xml. Is that correct? If yes, then I guess this is not something to care about in the beginning anyway.
2. Did the Variants disappear?
Example from the .bsd file:
<opc:StructuredType Name=”KeyValuePair” BaseType=”ua:ExtensionObject”>
<opc:Field Name=”Key” TypeName=”ua:QualifiedName” />
<opc:Field Name=”Value” TypeName=”ua:Variant” />
</opc:StructuredType>
But the corresponding element from the Opc.Ua.NodeSet2.Services.xml is this:
<UADataType NodeId=”i=14533″ BrowseName=”KeyValuePair”>
<DisplayName>KeyValuePair</DisplayName>
<References>
<Reference ReferenceType=”HasSubtype” IsForward=”false”>i=22</Reference>
</References>
<Definition Name=”KeyValuePair”>
<Field Name=”Key” DataType=”i=20″ />
<Field Name=”Value” />
</Definition>
</UADataType>
Are fields without a DataType considered to be a Variant?
Sensible default values are set in the schema:
https://github.com/OPCFoundati…..odeSet.xsd
Check there to learn what to do when no value is present.
Devices in use: Phone (5), Desktop (28)
Usage