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. 

2 Responses

  1. Setting up Open62541 to load the Companion Spec Model is simple enough.
    The fun and clever part is getting the data to the OPC UA Server.

    Just finished an Open62541 server, based on a companion spec which talks directly to the PLC. This is a fully dynamic server where it builds the nodes dependant of the PLC data structure.
    Really fun and challenging project.

    • If you have a CS that is conservative in its use of OPC UA features, you can expect easy sailing. Things can get more interesting if the models and/or datatypes get more complex. On the modelling side we recently fixed a bug related to Interfaces, on the datatypes side we resolved a number of issues related to nested structures, unions and optional fields – all related to companion specs (already released ones, or still in development)

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

Frank Meerkötter
Qt OPC UA updates

The Qt OPC UA module has been ported to CMake and will be part of Qt 6 right from the first release.
In addition to numerous bug fixes and improved test coverage, the open62541 plugin has been updated to open62541 v1.1 and uses OpenSSL for security support, thus removing the dependency on mbedTLS.

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 »