OPC UA Complex Data Extension
You have just read some data from your OPC UA server, from a node that is supposed to contain useful, structured information. But all that you got is a seemingly undecipherable array of bytes, in a form of an extension object. What has happened?
Well, you have met a custom data type (UDT), defined using OPC UA Complex Data. The encoded data indeed contains the requested information. But you need to decode it, using information contained in a type dictionary within the server. Or, when you are writing such data into the server, you need to encode it, according precisely to the rules. And you need to navigate the information model in order to put together all the pieces necessary to look up the type dictionary and the specific definition inside it.
And there is no support for that in the stack and SDK from OPC Foundation.... What to do now?
Let QuickOPC Take Care Of It
Retrieving the metadata from the server's information model, interpreting the data type dictionaries, and decoding and encoding data according to data type descriptions is quite complicated. QuickOPC can do it for you, with the help of the OPC UA Complex Data extension, transparently. With the OPC UA Complex Data extension, you do not have to deal with binary blobs; instead, you work with meaningful structures that represent the data types and the data itself logically.
Moreover, the OPC UA Complex Data extension does not require you to perform OPC operations any differently when complex data is involved. You use the same objects and methods as with the regular data. The only difference is in the data that is being passed to or from the component. Have a look at the OPC UA Complex Data reading example to see how simple it is. No more cryptic extension objects to deal with!
For detailed information about how this all works, including internal details, refer to the OPC UA Complex Data Extension chapter in QuickOPC User's Guide and Reference.
Some Background Information
In OPC UA, servers can stick to the standard types defined in the OPC UA specifications, or they can define their own types (UDT-s). The "non-standard" data types can be completely server-specific, or can conform to some industry standard. Usage of these data types is commonly referred to as OPC UA complex data. With complex data, it is possible that the data type is not even know at compile time; instead, it can be discovered, constructed or processed during runtime, without prior knowledge of it.
Use of OPC UA complex data poses a new range of interoperability problems. When the server uses some new data type, how can the client know what the data type it is, and how is the data encoded? The data is basically a binary blob that is transferred as a block between the server and the client, and who knows what it means? In some cases, the client can be hard-coded with upfront knowledge of what this binary blob of data (called extension object) contains and how it is encoded. But that is only when the client can be written with specific knowledge about the server it connects to, and even then decoding of the data might be a tedious programming task. Thanksfully, OPC UA specifications provide ways for servers to describe the data types and their encoding to the clients, using information that can reside in the server itself, using so-called data type dictionaries. Clients can then extract the data type descriptions from these dictionaries, and be written in a generic way that adjusts to the data types that exist in the server.
Useful links: Documentation / Knowledge Base
Footnote & required disclosure: QuickOPC (including its Options) is a software development kit (SDK) for development of OPC clients and subscribers. Installing QuickOPC or its Options does not change system settings.