A bit of ancient history
OPC (now “classic”) had been around since the late 90s. OPC has severe limitations on how data can be modeled. It is strictly Windows-only due to being built on top of COM/DCOM, which is also the reason why it isn’t really “internet ready”. After some failed attempts to revamp the existing concept, OPC UA was started as a mostly clean slate approach (albeit with a migration story for existing applications). The first version of the new OPC standard, now called OPC UA, was released in 2006.
The start of Qt OPC UA
From our primary application domain (HMIs for industrial machines and devices), we saw increased interest in OPC UA around 2014. Jannis, who was back then with us as a student, picked OPC UA as a topic for his bachelor thesis at the beginning of 2015. Through this work, we saw the potential of having our Qt applications communicate with the underlying controllers in an standardized way and thought: “Wouldn’t it be great to have a Qt module for that?”.
The only thing that was clear in the beginning was that we wanted to focus on the client-side. It was also quite clear that we would not be able to develop (and maintain!) our own native OPC UA implementation. Therefore we decided to “wrap” an existing client implementation. We also did not want to commit to a single client implementation as there was no clearly superior C/C++ solution available as FOSS at that time. All available libraries were incomplete and somewhat limited. So we decided to have a pluggable backend concept. We started out with the first plugin based on FreeOpcUa (thanks for getting us started!). We also internally created two plugins based on commercial offerings. The commercial offerings were taken in because the FOSS solutions were too weak at this point and we wanted to create an API on the Qt-side that was somewhat “complete”. Also there was the idea that people might want to “wrap” their commercial stack to make it easy to integrate into a Qt application.
Feature-wise, we weren’t so sure what a Qt module would need to provide (we did not have deep experience with OPC UA back then). I remember that we struggled quite a lot to find an API structure that would be a good fit for a Qt HMI (trading off some performance, but not neglecting it completely). We were also not sure how important certain OPC UA services were (e.g. is it an issue that stack “X” did not implement the query service?).
Towards a Qt add-on
Early summer 2015 we also started to talk to The Qt Company about contributing the new module to the Qt project properly. All of this led
to the creation of a git repository on the Qt side and the initial commit on the 25th of September. This commit contained the squashed initial work done on the basysKom side (only the plugin for the FreeOpcUa stack). The state was still quite rough. We tried to have a combined C++ and QML API, we did not clearly separate the plugin backend from the user API, … Thanks to Alex Blasche for the initial review work and getting this mess sorted out!
Working towards a first release
Most of the heavy development happened between 2016 and 2018.
A problem we faced early on was that upstream FreeOpcUa development stalled and came to an end more or less directly after we picked it as “our” backend. This left us with only commercial OPC UA stacks going forward which wasn’t going to work for a FOSS project…
This was offset by an outside contribution which came out of the blue. Jochen Seemann uploaded the initial open62541 plugin to Gerrit and Maurice cleaned it up and brought it to the main branch in August 2017. This was a very important step as the open62541 project turned out to be a FOSS project with enough momentum and backing from academics and the industry to become a viable long term solution for all things OPC UA in the C/C++ ecosystem. Thanks to Jochen and Maurice for making it happen!
In December 2017 support for the Unified Automation plugin was added by The Qt Company. This became part of the Qt for Industrial Automation offering. The Qt Company also contributed a QML-API for the module in 2018. The C++ API also found its current form and shape during that time. We committed on the new open62541 backend and removed the FreeOpcUa support.
All of this activity culminated in a first Tech Preview release with Qt 5.11 (https://www.qt.io/blog/2018/05/16/opc-ua-support-qt-5-11).
Also during this time we, as basysKom, saw the interest in OPC UA taper off, which left us with quite some doubt about the need for the module in the first place… Fortunately we stuck with it, as the adoption/interest was just about to get started!
Qt 5
We did another Tech Preview (TP) with 5.12 before removing the TP-status for most of the C++ API with Qt 5.13 (2019). A big addition to 5.13 was the support for Secure Connections which had been a big blocker for real adoption of the Qt OPC UA module.
Apart from filling some holes in our API, a lot of work went into getting the module to work on most of the platform/compiler combinations supported by Qt. Having CI builds and testing for such a broad range of platforms really helped to mature the library. Thanks to Qt for making this happen!
During that time we also struggled a lot with the question of whether we should extend the module to also offer server side functionality. Finally we came to the conclusion that this would be a lot of work with no clear benefit given that open62541 was already a good solution for our server-side OPC UA projects.
Qt 6 and beyond
Qt OPC UA was part of the initial Qt6.0 release in 2020. A lot of work went into the CMake migration and the open62541 1.0 version upgrade. During that phase we also switched the support for the secure connections with our open62541 backend from mbedTLS to OpenSSL. The primary motivation was that OpenSSL was already in use elsewhere in Qt which simplified the integration and reduced the amount of crypto code to look after. This became possible due to open62541 gaining an OpenSSL integration.
The Qt 6 series mostly contained additional API and functionality (making it easier to decode custom data types, authentication via certificates, support for selecting locales for the client session, historical data, …).
In 2023 we removed the Unified Automation plugin which never fully made the transition to Qt 6. Since then, there is only the open62541 plugin. This also reflects how much the FOSS-side of OPC UA has matured since 2015. We are considering to remove the plugin mechanism altogether for Qt 7 (acknowledging that we are no longer “a Qt wrapper for OPC UA stacks” but a “Qt OPC UA client implementation based on open62541”).
In 2024 we marked the QML API as deprecated as it never really left its Tech Preview state and we were not aware of active use. It will most likely be removed in Qt7.
We are currently actively maintaining the library, keeping up with open62541 releases, OpenSSL releases and overall changes to the Qt project as well as the OPC UA ecosystem. Feature-wise we seem to have found our sweet spot – an easy to use OPC UA client which integrates well with the rest of the Qt APIs.
Are you a Qt OPC UA user? Feel free to drop us an email saying “hi”. We are always curious about how and where the project is used! Also let us know if you are missing something that would significantly improve the module.
