Qt OPC UA

QtOpcUa as a wrapper

The current design of QtOpcUa assumes that it is a thin wrapper around an existing OPC-UA (client-)stack.

Negative consequences

• Open-Source stacks: There is as of today no (nearly) feature complete C/C++ open source stack with a suitable license.
• Closed-Source stacks: There are a number of feature complete stacks written in C/C++ but integration requires the cooperation of the respective vendor. This touches on topics such as
  • availability is limited to certain platforms
  • the stacks embed (static) copies of third parties such as libxml or openssl. This can clash with Qt third-parties (openssl is a known case).
  • vendors might not be too cooperative as it makes their stack replaceable.
• One needs to create and maintain a CI-setup for 'x' different stacks
• One needs to learn the client side API of 'x' different stacks to create the necessary backends.
• Certain stacks only provide a synchronous API which creates a burden for the Qt-side (which needs to provide an asynchronous API)
• The qt io/networking abstraction is bypassed.

Positive consequences

• A lot of heavy lifting has already been done as the existing stacks implement all the complicated things and we just provide a wrapper (unclear if there is actually so much complicated stuff on the client-side).

QtOpcUa as a standalone implementation of (client-side) OpcUa

Assumption: most of the complicated stuff is on the server side. It might be a workable approach to re-implement the client-side of OPC-UA from scratch. A lot of projects use a code-generator to translate the XMl-based protocol/interface description published by the opcuafoundation into code to provide protocol primitives (enums/structs) as well as serialization and deserialization. One could take an existing generator and modify it to generate Qtish code.

Negative consequences

• More actually knowledge of the inner workings of OPC-UA are needed.
• The crypto transport might be a lot of work (it is not actually SSL/TLS but close). Open-Source projects typically don't implement it.

Positive consequences

• Much less CI hassle
• All Qt plattforms are automatically supported
• Better integrated with the rest of Qt (other modules like networking, ssl or the eventloop).
• Full control over the API. It can be done asynchronous without threading constructs and other workarounds.
• No reliance on the goodwill of commercial vendors.

API limitations

• Events: the current API does not allow to specify select or where clauses. Select-clauses are used to select fields to be contained in the event notification. The where-clauses are used to filter which events should be notified.