OPC Experts Interviews: Companion Specifications

OPC Experts Interviews: Companion Specifications
OPC Experts Interviews: Companion Specifications

Learn from an interview with Karl Deiretsbacher of the OPC Foundation about Companion Specifications; the different types of Companion Specifications that exist; what Joint Working Groups are; and how the OPC Foundation guides the development and maintenance of Companion Specifications.

Karl, please introduce yourself to our readers and tell us a bit about yourself and your involvement with OPC technology and the OPC Foundation.

Deiretsbacher: Sure, my name is Karl Deiretsbacher. I am the Technical Director for the OPC Foundation, and Chair of the Technical Advisory Council. My involvement with OPC technology began in 1995, and, for more than 20 years, I have been part of the core OPC Specification teams. I am still active as editor of several parts of the standard.

The OPC Foundation closely cooperates with organizations and associations from various branches. What role do Companion Specifications play with regard to these co-operations?

Deiretsbacher: In short, with OPC UA, we define the mechanisms for "HOW" to move data; however, the knowledge of "WHAT" type of data is needed, for specific application domains, exists in numerous other organizations or branches; these are the organizations with whom we want to cooperate.

A companion specification formally defines a branch-specific information model and assures that implementations, from a variety of vendors, all look and behave the same. By combining the UA communication infrastructure with domain specific data, the end user is assured robust and secure data exchange, at a semantic level, between products of different vendors.

The OPC Experts Interviews is a series of discussions taking a deep dive into open platform communications and related technology. International experts discuss OPC and OPC UA, protocol binding, security, the new Field Level Communications group, projects and experiences, and more. Automation.com is the exclusive publisher of these interviews. Visit us frequently to read the latest interviews.

Which OPC UA features can be used for Companion Specifications?

Deiretsbacher: The first, and most important feature, is the OPC UA address space model. You can think of it as a language to design object-oriented information. We call it address space model because all information elements–also called meta information–are available in the server address space and can be discovered and used by clients. In other words, quite similar to the definition of a library in object-oriented programming, an information model defines object types with variables and methods which can be sub-typed and instantiated. In addition, these types can be semantically enriched by using specific reference types to other nodes.

But, the OPC UA standard not only provides the language to design object-oriented information, it also includes a basic information model with widely applicable object types, variable types, reference types, and data types.

So, in summary, each companion specification uses the address space model to extend the OPC UA base types with custom, branch-specific types.

Can you please describe for our readers what an information model looks like?

Deiretsbacher: Like in object-oriented programming, all standard types and instances have to be defined with their attributes, components, methods, and their relationships. We have formal tables that are used in the documents, but, in addition, a machine-readable version has to be provided. It is an XML document that conforms to the information model XML schema, the so-called NodeSets. There are several tools on the market that allow the creation and processing of such NodeSets. For instance, tool kit vendors provide code generators for their development kits that use NodeSets as source.

Who can develop a Companion Specification? Is that a privilege for OPC Foundation employees or members? Or can anyone interested start one up?

Deiretsbacher: Anyone is permitted to develop companion specifications. The OPC UA standard is a public standard and can be downloaded from the OPC Foundation website. No membership is required, only registration.

The OPC Foundation differentiates between types of Companion Specifications. Can you please explain?

Deiretsbacher: The differences arise from the way the OPC Foundation gets involved. We differentiate the various companion specification types as either Internal, Joint or External.

An internal companion specification is developed by an OPC Foundation working group. No other organization is involved.

The opposite extreme is an external companion specification that is developed without OPC Foundation involvement.

Joint development is considered to be the most important type. Here, the OPC Foundation and another organization (or perhaps a few organizations), sign an agreement for certain work items. The members of all involved organizations are invited to participate. We call this a joint working group. The work-results will carry the logos of the participating organizations and will be published on the OPC Foundation website. The OPC Foundation further supports such joint initiatives with marketing efforts.

It seems that Joint Working Groups are the most common way to develop Companion Specifications. Can you tell us more about them? How do they get initiated?

Deiretsbacher: Yes, it is true that most active working groups are joint working groups. As already mentioned, OPC UA is an infrastructure to exchange complex information models. There are many organizations actively developing and maintaining models for specific branches. And with the increasing popularity of the OPC UA standard, we constantly receive enquiries to collaborate. So, when we get an inquiry, we check to see whether such a collaboration might be useful for both organizations.

OPC Foundation and the collaborating organizations sign the so-called "Multi-Org-Agreement" (MOCA) including a charter document where purpose, goals and roadmap are detailed. Once approved by the OPC Control Board, a kickoff date is scheduled, where the new joint working group is officially launched. Both organizations then invite their member experts to participate in this new joint work.

And how do the Joint Working Groups operate?

Deiretsbacher: The mode in which working groups operate is quite similar across most organizations and in most areas throughout the world. OPC Foundation, based on their successes and experience with working groups, suggests some key points to include as part of the charter.

Number one, a group needs to have a chairperson that is responsible for the operation, along with one or more editors that develop the specification. Number two, the group will hold regular web meetings (Biweekly is quite common). Additionally, meetings should be recorded for traceability and for those group members who were unable to attend. Face-to-face meetings are also common, but with less frequency. Number three, the chairperson participates in the OPC UA harmonization group. This ensures that there is exchange between OPC UA experts and other working groups. Number four, when finished, the companion specification will be submitted to the OPC Foundation for review and approval.

So, how many Joint Working Groups exist? Where can I find out more about them and their work?

Deiretsbacher: At the end of 2019 we had about forty groups in different stages of development. Some of them had just started, while others have completed a specification release and are in a so-called maintenance mode. Over the last few years, we’ve installed about five to ten new working groups each year. An overview of these working groups, with a short description of their charter and other details, can be viewed on the OPC Foundation website.

I assume that commonalities exist amongst the Joint Working Groups. For example, it’s perhaps likely that more than one Joint Working Group may need a data type for, let’s say, GPS coordinates. How is something like that handled?

Deiretsbacher: There are different opportunities. First of all, the core specification already provides several widely acceptable and applicable models for individual types. Examples are, the file type; the folder; a state machine model; and a device model. But, OPC UA also specifies a number of variables and alarm types that are common among many industries. In that context, I wish to mention the Online Reference, which is an online version of both the OPC UA Standard and the Companion Specifications. It allows for easy and powerful searches across all information models. From within the search dialog, enter the term for which you are searching. If your topic exists, you will get a list of page links that define and describe the requested feature.

The second opportunity is the harmonization working group that I already mentioned. Here you can explain and discuss your needs and check for similar, existing solutions.

You mentioned that models defined in Companion Specifications are governed by namespace, but what if I want to use models from different companion specifications in a single implementation?

Deiretsbacher: Actually, this is a fundamental issue which had to be addressed right from the beginning. Implementations will often use multiple namespaces. For instance, a server that implements PLCopen needs the namespace for the OPC UA core standard, the UA for devices namespace, and the PLCopen namespace. In implementations you will find that the identifier for nodes in the address space includes an ID for the suitable namespace so that it can be easily identified.

When a companion specification has been completed, what are the next steps?

Deiretsbacher: When finished, the companion specification will be submitted to OPC Foundation bodies for review and approval. The OPC Foundation established a formal release process, which is used for both internal specifications and for joint specifications. As part of this process, all members are granted a ninety-day period wherein they can submit comments and opt-out claims according to the OPC Foundation’s intellectual property policy. When the comments have been resolved, the specification will be published on the OPC Foundation website and integrated into the Online Reference.

Is there any activity or development you wish to mention, or perhaps a final thought that you would like to share with our readers?

Deiretsbacher: Let me reiterate that the combined efforts of the OPC Foundation and various branch-specific organizations is unique and has enormous potential. I am convinced that it will be a key driver for the ongoing industrial revolution.

On a final note, I very much wish and hope that this article, not only explains, but also motivates other groups.

About The Author


Michael Clark as the Director of OPC Foundation North America and a spokesperson for the Foundation throughout the region. With over 30 years of experience, Clark is internationally recognized in the process automation sector for his expertise in Industrial Control System (ICS) fieldbus protocols and for his contributions to the Open Process Automation Standard (OPAS) since its inception.

 


Did you enjoy this great article?

Check out our free e-newsletters to read more great articles..

Subscribe