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?
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
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)