Log In
Home
The OPC UA nodeset XML schema validates nodeset XML files, which are used for:
(a) advertising sector-specific or proprietary nodeset definitions to third parties (third party clients can self-configure to browse and read that nodeset in a server); and optionally
(b) configuring proprietary nodesets during a vendor’s server “build” process. The build may be “dynamic” in that a generic server can self-configure from any* nodeset XML file at startup time (* given that a compatible mechanism is created for exchanging “live” data with the server application), or “static” in that a schema compiler generates source code for inclusion in the server’s codebase.
Any client using a schema-compliant nodeset XML file should have the a-priori knowledge to navigate to any node in the server’s nodeset without having to browse.
The OPC UA nodeset XML schema can be found at: https://github.com/OPCFoundati…..ter/Schema
05/30/2017
Offline
No disagreement with what you said.
I would add: NodeSets are used to publish normative definitions associated with the UA specification and associated Companion Specifications.
Next one:
Extension object
An object contains “complex data” (structures other than arrays) appearing in either:
(a) a nodeset; or
(b) an invocation or response parameter to a method
Where the structure definition is known a-priori (e.g. from a nodeset XML file), a client can parse any binary instance immediately. Otherwise the server must provide a structure definition in a standard format for use by the client’s parser
05/30/2017
Offline
An ExtensionObject is a wrapper for subtypes of Structure that includes type and length information that allows it a receiver to deal with a DataType it does not recognize.
As of 1.04 the contents of the DataType are specified with the DataTypeDefinition Attribute (basically an ordered list of name-value pairs that can be encoded into any format).
When a client reads of Variable with a DataType of Structure then it gets a Structure encoded using the default encoding for transport. i.e. if using binary the client gets a binary encoded value. if using JSON it gets an JSON encoded value.
A client may explicitly specify the DataEncoding in the Read which means it can be get JSON encoded structures while using UA binary for the connection.
The NodeSet simply specifies the information that goes into the DataTypeDefinition Attribute.
Ah ha. That is clearer. The server sends the requested data, whether or not the client can understand it. If the client wants to understand it, it must (a) have a-priori knowledge, or (b) refer to the structure definition in the nodeset. Interesting that the Foundation adopted JSON – my understanding is that it cannot unambiguously encode and decode arbitrary data – so the decoding obviously has to (or at least should) use hints from the nodeset in order to to get the right answer. But actually, I suppose that is no worse than binary encoding.
05/30/2017
Offline
Part 6 defines a JSON encoding that is consistent with UA encoding rules. It is called UA JSON and it eliminates any ambiguities. Part 6 also defines a non-reversible JSON encoding which allows UA applications to construct JSON object that look prettier and can be handled off to a generic data analysis platforms that handle JSON but know nothing about UA.
1 Guest(s)
Usage Policy