Table of Contents
OPC UA open62541

Implementing OPC UA Companion Specifications with open62541

OPC UA open62541

open62541 is an independent open source implementation of OPC UA.
Companion specifications complement OPC UA with the goal of fostering interoperability. This article will provide an overview about implementing a Companion Specification with open62541.

What is OPC UA and what is a Companion Specification?

OPC UA is an important enabler for the Industry 4.0 story by providing the framework to build interoperable data exchange between machines and applications of all kinds. But just using OPC UA as a communication protocol will not result in something highly interoperable.

Therefore, the OPC UA foundation as well as various industry associations such as the VDMA are defining so-called Companion Specifications.

These additional documents use the data modeling capabilities of OPC UA to define a common vocabulary for a given industry sector. Recent examples include UA CS for Weighing Technology or UA CS Part 1 for Machine Vision.

In short: OPC UA defines how to communicate, the Companion Specifications define what to communicate. For interoperability both need to be defined.

How do Companion Specifications come to life?

Typically, established organisations will reach out to members to gauge if there is a wider interest to establish a working group. Companies participating should reflect a wide spectrum of an industry so that the resulting body of work is widely applicable within a certain industry.

Next, working groups of domain experts will define use-cases and establish a common vocabulary for these. These specific steps are not in focus of this article. If you are interested though, the VDMA has published the VDMA-Einheitsblatt 40 000 describing How to write an OPC UA Companion Specification.

The OPC connect newsletter is also an interesting source of information to get a heads-up on upcoming working groups.

What is open62541?

open62541 is an open source implementation of OPC UA written in highly portable C.
It implements an ever growing subset of OPC UA. The project has started in an academic context, but has meanwhile attracted a large community of commercial users as well.

Development happens as a github project. The project provides an API to build servers and clients. A major milestone was an official certification of an example server based on the 1.0 release with an OPC UA test laboratory in 2019. open62541 is a very active project with a lot of momentum. 2020 saw the release of 1.1, 1.2 will be released soon. Various parties are using the open62541 stack to implement OPC UA Companion Specifications.

How to implement a Companion Specification with open62541?

This question is highly dependent on the Specific Companion specification at hand – there is a wide range in complexity between the different specifications. In general, we should differentiate between an already released official Companion Specification and one that is still in definition. For the first case we “just” need to handle the cards that have been dealt, while the second case is more iterative.
In both cases, a first step is to get hold of the XML model of the Companion Specification itself (as well as the models it potentially depends on) and to run it through the open62541 model compiler. This tool generates open62541-specific C-code (data types, object types, interface types, object instances with well known node ids, …) for a given input model. You find its documentation here. If this works, one can use the resulting code to bring up objects instances of the model in a first custom server.

Another early step to perform is to check the Profiles required by a given Companion Specification. OPC UA is using a concept of Facets and Profiles to bundle OPC UA features into testable subsets. A given product is not expected to implement the whole of OPC UA but rather a set of given profiles.

Here is an example of the profiles defined (and required) by UA CS for Robotics. The required profiles need to be checked against the features available with open62541. You can find the details about the certified Facets and Profiles here.

Note that this list does not reflect what is available with the 1.1 or 1.2 releases, but rather provides a starting point what is available.

The second case is an implementation that happens parallel to the development of the Companion Specification itself.

It is highly recommended not to define a Companion Specification purely on a theoretical basis. A Companion Specification will go through numerous draft iterations. It is important to start with a first implementation in parallel after the draft specifications have reached a certain stability. The primary goal is to provide implementation feedback to the group working on the specification and to collect feedback from domain experts and other stakeholders. But this also ensures that potential issues in the open62541 stack are discovered early and are being dealt with.

Implementing an OPC UA Companion Specification can seem a bit daunting at first – especially if there is no background with OPC UA at all – but it doesn’t have to. In both cases after an initial analysis, one would start with the basic profiles of a given CS and work its way up to the more complex ones (if desired).

basysKom is an active contributor and a commercial support partner to the open62541 project. We are offering coaching, training and development services for OPC UA and open62541. We have supported customers from different industries with the implementation of Companion Specifications. Get in contact to talk about your project. 

Leave a Reply

Your email address will not be published. Required fields are marked *

Frank Meerkötter

Frank Meerkötter

Frank Meerkoetter is the Development Lead for basysKom GmbH, where he is consulting customers on industrial and embedded applications, often in combination with Qt. He is responsible for the technical consulting, system- and software-architecture within basysKom. He is the maintainer of Qt OPC UA and a contributor to the Qt project. He has a strong background in Embedded Linux, systems programming, distributed systems and application development. He holds a Master of Computer Science from the University of Applied Sciences in Darmstadt.
Share on facebook
Share on twitter
Share on linkedin
Share on reddit
Share on xing
Share on email
Share on stumbleupon
Share on whatsapp
Share on pocket

Read more

Jannis Völker
Support for PEM in the open62541 OpenSSL plugin

basysKom recently extended this plugin to also accept PEM-based input. PEM is a file format used for certificates and keys which is specified by an RFC and is a preferred format for a lot of open source software. The pull request has been merged and our contribution is available from the 1.1 branch (and will also hit the master branch soon).

Read More »
Jannis Völker
Connect OPC UA with open62541 to MS Azure IoT Hub

The open62541 OPC UA stack with its Pub-Sub extension now supports MQTT over TLS as well as MQTT-brokers requiring a login (contributed by basysKom). This allows the direct communication between open62541 and the Azure IoT Hub and therefore highly simplifies the connection of OPC UA based IoT Devices to the cloud.

Read More »
OPC UA open62541
Frank Meerkötter
Qt OPC UA: Logging improvements in Qt 6.1

So far programs using Qt OPC UA with the open62541 back-end produced quite a bit of chatter on stdout originating from the open62541 stack itself. Unfortunately there was no simple way to get rid of these low-level logs. We now provide a way to control this behavior.

Read More »