OPC UA Companion Specifications (OPC UA CS)

Overview: What are OPC UA Companion Specifications


The OPC Foundation’s Open Platform Communications Unified Architecture (OPC UA) standard is fast becoming the interoperability standard of choice for enterprise wide OT data interoperability. A trend accelerated by the popular Industrial Internet of Things (IIoT) and Industrie4.0 (I4.0) trends. 

If you are new to OPC UA or are only familiar with the first generation OPC Classic standard – take the time now to learn as much as you can about what OPC UA has to offer because OPC UA changes the interconnectivity and interoperability paradigm.

Among its many strengths, one of the key OPC UA characteristics is its support for seamless extendibility of object-oriented Information Models via Companion Specifications. Beyond facilitating a codified method for expressing information models, Companion Specifications provide a common method for standards bodies and specialized industry groups to collaborate on specific information models, to harmonize them with others groups doing similar things, and for the OPC Foundation to catalog all these information models (encoded in Companion Specifications) so a ‘United Nations of Information Models” can be formed.

OPC UA Information Models

Building on top of straight data connectivity is the ability for entities to share rich contextual data. Expressing that context is what Information modeling (IM) focuses on.  Information Modeling defines the relationships between the various data types and values associated within system(s).  Expressed as information models, these relationships can be simple or quite complex.

Stand-out OPC UA Information Modeling features:

  1. Creation of Information Models

The information modeling capabilities within the OPC UA are robust enough to make OPC UA an ideal choice for defining everything from simple contextual data (like engineering units and maximum/minimum ranges generated by a sensor or device) to large, complex relationships that include instantiations of complex object types involving data structures, methods, and state machines.  

These powerful OPC UA Information Modeling capabilities make OPC UA an excellent mechanism for system integrators, engineers, and software developers to use to define and implement custom information models for their specific products or projects.

  1. Discovery of Information Models

OPC UA Clients can dynamically discover the information models an OPC UA Server has in its. This means that they can map out the OPC UA server’s information models and address space at the time they connect. This means that an OPC UA client can keep all the semantic relationships an OPC UA server exposes intact even if the OPC UA Client was not written with prior knowledge of the information models a given OPC UA server uses.

  1. Dynamic Information Model Change Notifications: building on the power of enabling OPC UA Clients to discover the OPC UA server information models they connect to, OPC UA also includes OPC UA servers notifications to OPC UA clients about changes to their address space via Events. This ensures OPC UA clients:
    1. are aware of configuration changes when they happen on the OPC UA server side
    2. changes can be recorded for audit purposes

  2. Standardization of Information Models via Companion Specifications:

The OPC Foundation standardized how individual OPC UA information models are defined and packaged. This allows people to define and document their information model specifics and to use a standardized XML file (nodeset file) to make the information model usable by OPC UA servers and OPC UA clients.  

Note: End users need OPC UA products like Beeond UMX Pro or Matrikon Dispatch to be able to work with and modify Information Models found within a given Companion Specification nodeset file and to be able to map real world data sources to that model respectively.  

  1. Reuse of Companion Specifications & Harmonization:

Once an OPC UA companion specification runs through the OPC Foundation OPC UA Companion Specification release process (as defined by the OPC Foundation) (https://opcfoundation.org/about/opc-technologies/opc-ua/ua-companion-specifications/) the Companion Specification is published so it can be used worldwide by developers and end-users.

a. Reuse of Companion Specifications: The ability to share and use common OPC UA companion specifications by system integrators and vendors is what made it possible to start building a global collection of key Companion Specifications. These are focused on specific topics, industries, applications, etc. By making Companion Specifications readily available to everyone, the following additional benefits can be realized:

i. Reuse: Vendors can simply adopt an existing companion standard for a given application instead of having to come up with their own standard (often re-inventing the wheel).

ii. Simplified Integration: Re-use of existing companion specifications simplifies future integration efforts and reduces costs because the more vendors, engineers, and system integrators use common information models, the higher the chance for those systems to be interoperable out of the box.

Note: Custom information models reduce ease of integration because when multiple custom information models are used, additional effort is needed to map between each of them to know how one information model relates another (if this is even possible since, one model may include semantic information that the other lacks or factors differently).  This inter-information model work is either done via manual mapping or must be embedded in application logic.

b. Harmonization of Companion Specifications: more of an OPC Foundation vision & goal than an ‘OPC UA feature’. Harmonization may be one of the most important future shaping outcomes of globally adopting OPC UA information modeling via companion specifications.


Beyond building a large, ad-hoc repository of companion specifications, the OPC Foundation works pro-actively with various standards bodies to help them develop proper OPC UA companion specifications and helps facilitate cross standards body collaboration from around the world as they work on translating their existing information models into OPC UA . companion specifications. The goal is to develop common specifications that are used world-wide and are:

  1. 3rd Party Standards bodies are increasingly translating their information models into OPC UA based ones not only because OPC UA is widely adopted but also because they can take advantage of all the other modern features OPC UA offers beyond information modeling (as mentioned above).
  2. 3rd Party standards bodies are increasingly translating their information models into OPC UA based ones because this lets their members tap into the rapidly growing global OPC UA market space and
  3. A key benefit of moving to OPC UA CSs based IMs for 3rd party standards bodies is that they can then focus on expressing/refining their domain focused semantic information without having to worry about ever-changing security standards, use of new transports, etc.

What types of information do Companion Specifications represent?

An OPC UA Companion Specification expresses an information model using the OPC UA object modeling language.  Seeing how both people and applications need to work with the IM in question, a complete Companion Specification consists of a few pieces of collateral.

The Information Model (IM) that is described in two formats:

  • Human Audience: Readable documentation (PDF)
  • Applications: Machine readable xml file called the Nodeset file
  • The name “Nodeset” is used because the cornerstone of OPC UA Information Modeling is the definition of nodes and the relationships between them.


Detailed information about what makes up the OPC UA Information Modeling language can be found in the OPC UA Specification ( ____ File Referene___). From a high level perspective, interesting aspects about OPC UA Information Modeling  include:

  • OPC UA Information Models are Object Oriented: objects were used to allowing for the creation of custom complex data types built on top of base OPC UA types with the addition of methods.
    • Base Types: After over twenty years of use in industry, OPC UA defines a comprehensive list of base types out of the box.
    • Custom Types: Where the complex data types really shine is when contextual (semantic) data about a system needs to be defined and then re-used on site, across a product line, or across a fleet of plants. With Object Oriented information modeling, OPC UA makes both the definition of hierarchical models possible and makes short work of dynamically creating and manipulating multiple instances of the objects as needed.
    • Methods: OPC UA information models enable OPC UA Servers to expose functions that OPC UA Clients can discover and call. Beyond exposing semantic data, this allows OPC UA Clients to interact with OPC UA servers on a functional level on top of the traditional reading and writing of data values.
    • State Machines: OPC UA information models can include state machines allowing similar inputs to have different outputs.


How are Companion Specifications used by an OPC UA Client or OPC UA Server?

OPC UA servers can utilize information models defined in companion specifications dynamically by reading in nodeset files or have the information models built-in them during development.  When OPC UA Clients connect to such OPC UA servers, they can discover the information models dynamically.

Can an OPC UA Client not using a companion specification communicate with an OPC UA Server that uses a Companion Specification?

- Yes: base OPC UA types are used as base type “building blocks” for more complex types. This is best illustrated by a simplified diagram like this:


Types of OPC UA Information Models and who creates them?


  • Vendor Specific OPC UA Information Models and External Companion Specifications (Custom): Created by system integrators/end-user engineers/vendors/standards bodies: 

Companies: Companion Specifications provide a convenient method for companies and integrators capture the information models they want to use throughout the enterprise. The information models the company creates are generally not intended to be used by other companies. While the companion specification makes it possible to create the information model for the company, the companion specification does not have to go through the OPC Foundation before it can be published and used.

System Integrators: as in the company example, system integrators often must tie multiple control automation components to build up a complete control system. Creating an in-house companion specifications that captures the information model the system uses gives the system integrators a convenient way to reuse the information model independent of the underlying components which, may change based on the specifications and price requirements of each customer. Here again, the system integrators may not want to publish a full-blown standard for use by the public.


  • Companion Specifications (Internal OPC Foundation, Joint, and External): standards bodies, and vendors working in specific industries may come together to create companion specifications that help standardize how information is modeled on specific topics are used by broader segments of industry.

While custom companion information models have their place for limited applications, the next level up in moving entire industries towards interoperability comes when companies and/or standards bodies create companion specification that meet the requirements of the OPC Foundation (see link for Companion Specifications). Companion specifications are available for everyone to use.  The more people adopt a Companion Specification, the higher the chance that their products/solutions will work with other systems based on same Companion Specification.  Examples of such companion specifications exist across all industry types – from Oil and Gas (MDIS) to the packaging industry (PackML) and pharmaceuticals (….)


  • Harmonized (Future): global focused standards bodies

At the peak of contributing to the creation of global interoperability are companion specifications that are defined through collaboration between international organizations focused on the same topic.  The advantage such harmonized OPC UA based information models have over those created by a single organization is that they influence a much broader range of components or solutions from around the world. This is good for vendors that adopt them because the vendors’ products’ data will be understood by the maximum number of 3rd party applications based on the same companion specification.  Unlike custom information models, harmonized companion specifications unify and simplify the control automation information modeling landscape because they maximize the chances that multi-vendor components use the same, well defined, semantics.

Anatomy of a Companion Specification (or What is in a Companion Specification?)

Companion Specifications document the Information Model via a human-readable document and a the OPC UA Server readable nodeset file (XML) .

Best way to work with the information model stored in a Companion Specification is via modeling tool like UMX Pro which, lets you do things like:

  • Modify the information model
  • Add instantiations of the various information model objects the Companion specification defines so the objects are created by an OPC UA server that reads in the nodeset file.
  • For developers: Auto generate C++ source code and make files for direct use in projects based on the Matrikon FLEX OPC UA SDK

Who uses Companion Specifications?

  • Developers writing
    • OPC UA Servers
    • OPC UA Clients
  • System Integrators
    • Building internally standardized data models reflecting the systems they repeatedly build and commission.
  • End-Users
    • Read in companion specs and mapping existing data sources to them
    • Auto-discovering information models build into products

How to get started with using Companion Specifications?

How you work with a Companion Specification will depend on the work you do.

Software Developers: to build in support for one or more companion specifications directly into your OPC UA Server:

  • The Beeond UMX Pro modeling tool makes it easy for you to: review and manipulate the information model a companion specification defines and to choose what objects you want the nodeset file to instantiate upon loading. In addition, you can also generate production ready (C++) source code with click of a button. At the time of this writing, output form UMX Pro natively supports the Matirkon FLEX OPC UA SDK.



  • Review available Companion Specification documentation if it is available
  • Review the overall information model implemented in a companion specification via UMX Pro.
  • Add or remove instances defined in the Companion Specification nodeset file so when the nodset file is read in by an applications capable of dynamically loading nodeset files, the application will create those instances for you. Note: a given OPC UA server needs to have the functionality for reading in nodeset files built into it for this to work. One notable platform designed for this purpose is Matrikon® FLEX Dispatch™.

Examples of CSs

  • OpenPLC
  • VDW umati
  • MDIS
  • PackML
  • MTConnect
  • VDW Robotic Vision
  • VDW Robotics