CleanOpcUA.NodeSpace 2.0.0-alpha42

CleanOpcUA

Framework for stack independent OPC UA client development inspired by the clean architecture principles

The motivation behind CleanOpcUA

When writing OPC UA clients and reusable components I noticed some limitations of the current OPC UA stack implementations. With CleanOpcUA current client stacks can be enhanced for easier development of clients and for stack independent development of reusable components.

Additional focus on modelling

Modelling ist a strong part of UA but since the available stacks concentrate on communication, the libraries are coupled with communication and limited to that use case. This violates the core principles of Clean Architecture.
Why not using the OPC UA information models in the core of an application independently of the OPC UA communication of the infrastructure layer? Why not create tools for code generation of core models independent from the used OPC UA stack? On the infrastructure layer the communication still matches nicely since model and communication both speak the same language (same information model, same meta model).

Abstraction to allow stack independent component / client development

OPC UA defines many well thought information models. But components / libraries that are written against these standards are rare because there is not common representation of the information model for languages like C#. The OPC UA standard defines how the data is sent over the wire so that applications of different vendors can talk to each other. What is missing is a standard interface on the stack layer. Today methods and granularity differs, some implementations are synchronous, some asynchronous, some use result codes some others throw exceptions. This makes it hard to write a library for an information model that can be used with different stacks. OPC UA Client development often starts with the open source library of the OPC foundation and is later switched to a commercial stack because of support or licensing reasons. This often results in a rewrite of several parts of the application. Wouldn't it be good to have a small interface, that is usable by different stacks?

Abstraction to allow communication with other protocols

UA has a lean and well abstracted communication model. It is mapped to different protocols like UA binary or SOAP or REST. Why Not using it to access other communication interfaces like proprietary USB protocols or map to other protocols like fieldbus protocols?

Smaller interfaces for reuse with other protocols

The UA Services are grouped in service sets but most stacks just implement more or less all services. Why not creating separate interfaces for the service sets so that a communication interface can implement the subset that it needs. For some service sets it is possible to be built on top of a more primitive one. E.g build a subscription service over a read service by polling. Or build a historian with support for the history read service set over a subscription service set.

What ist CleanOpcUA?

• A Set of primitive interfaces for the service sets defines in the standard.
• Implementation of these interfaces for the stack of the OPC foundation (for others contact me directly).
• A component to read and write OPC UA data models as standard NodeSet Xml files.
• A Code generator usable for generating data model classes, markdown documentation, browse names, NodeIds...
• A stack independent implementation of the file access classes.

core concepts

• Works well with dependency injection containers like Microsoft.Extensions.DependencyInjection.
• To support central handling of communication issues, exceptions are commonly thrown for bad result codes.
• OPC UA service methods are as basic and close to the standard as possible.
• Higher level communication methods are realized as extension methods. As such they can be reused on all implementations of the basic methods.
• Separation of server management from communication (separate interfaces).
• Session (re)establishment on demand.
• Twin layer: TwinVariable and associated extension methods to browse, read, write, subscribe variables of the server.

Work in Progress

These components started as a library for a smart home project and meanwhile they are also used for some commercial industrial applications.

It will continuously be completed, improved and extended (not all parts are published yet - stay tuned).