OPC UA with Flutter – Two Years Later

OPC UA is a platform independent standard for data modeling and communication that plays a major role in the horizontal and vertical integration of industrial automation systems. It is also a popular choice for connecting industrial controllers (PLCs) and entire machines with HMIs. Having an OPC UA client available is an important building block for popularizing Flutter for machine control applications.

Two years have passed since we at basysKom first attempted to use the open62541 OPC UA implementation in Flutter which resulted in a blog post describing our experience and the difficulties we encountered (for context have a quick look at the old post). Now it was time to have a fresh look into the matter to see if any of the blockers have been resolved.

Using open62541 directly via ffigen

The original blog post focused on the implementation of a C++ class providing a small, application specific subset of open62541's functionality to Flutter because it became clear quickly that using the library directly via ffigen wouldn't work.

The main blocker was that the open62541 code base makes heavy use of static inline functions in headers which was not supported by ffigen.

The Inline Problem

Static inline functions are still not supported by ffigen but starting with the upcoming 1.4 release of open62541, there will be a new CMake parameter named UA_ENABLE_INLINABLE_EXPORT which causes all static inline functions to be included into the the library. This solves the problem and ffigen is able to generate bindings for all functions in the open62541 library.

Threads and Callbacks

The next issue is not a blocker per se, but something to keep in mind. Due to the threading model of Dart, there can only be one thread per isolate. This demands that callbacks in the Dart code that are invoked from the native C side must not come from a different thread (e. g. worker thread) or the Dart VM will be terminated with an error

Due to this limitation, the only way to use the asynchronous, callback based API of open62541 would be calling UA_Client_run_iterate() periodically from a timer in the Dart code to ensure that callbacks are invoked from the right thread. As this function is blocking, it will be necessary to experiment with the timeout parameter in order not to block the Dart isolate too long.

Structs and Bitfields

After having sorted out the issues mentioned above, everything looked good until we noticed ffigen spitting errors regarding the code generation for structs

The root issue here is the lack of support for bitfields in the Dart FFI which in turn prevents ffigen from supporting them. The behavior of ffigen in such a case is to generate an empty class because just skipping the bitfield members is not an option due to alignment issues.

The UA_DiagnosticInfo struct contains bitfield members and is present in the header of all OPC UA response types sent by an OPC UA server to a client.

Functions using these types as return or parameter type will also be skipped during generation. This unfortunately means that we have yet again found a blocker.

Conclusion

Two years later, it is still not practical to use open62541 directly in Flutter. While it is now possible to establish and maintain a connection to an OPC UA server using the bindings generated by ffigen, most of the API to interact with the server is missing or not usable. Developers wishing to utilize open62541 in their Flutter applications should resort to creating a custom library exposing the necessary functionality as described in our initial blog post until the Dart FFI and ffigen have been updated to deal with bitfield members in structs.