It is recommended to use existing Companion Specifications for vendors as well as when defining new Companion Specifications in order to increase interoperability on the information model level.

The Online Reference (https://reference.opcfoundation.org/) can help identifying if Companion Specifications exist that either address specific domains or provide general concepts that can be reused.

There are Companion Specifications addressing specific domains like robots, vision systems, machine tools, injection-moulding machines, but also more generic Companion Specifications that are already designed to be the base for more specific Companion Specifications.

In addition to the base specification this includes:

• OPC 10000-100 Devices: General model how to manage any kind of device (field device, PLC, machine, etc.). This includes mechanisms for device identification, health status, parameter handling, modular devices, firmware update, backup and restore, locking, online and offline handling and device support information.
• OPC 10000-110 Asset Management Basics: Addresses base concepts for asset management use cases for any assets including identification, discovery, skills / capabilities, requirements, version information, health status including tracking, log of maintenance, localization, structure, and classification of assets, already using the devices specification as base.
• OPC 10000-200 Industrial Automation: Building blocks for industrial automation including a model for stacklights, statistical data and calibration target management.
• OPC 10031-4 ISA-95 Job Control: Contains a model to manage jobs.
• OPC 30050 PackML: Is per se a domain specific information model for the packaging industry but contains a rather generic state machine based on ISA-88 that is already reused in several other Companion Specifications.
• OPC 40001-1 Machinery – Basic Building Blocks: Contains basic building blocks addressing different use cases for machinery including the identification of machines and its components, discovering machines and their components and monitoring machine states.

Those specifications are typically built using some kind of building blocks, so that it can be picked which concepts to use, and it is not an all-or-nothing approach. How to use the concrete part of the Companion Specification of course depends on the concrete model. More recent specifications rather use interfaces and AddIns (see OPC 10000-3) to simplify the reuse. The Devices specification is one of the first Companion Specifications and also the one reused the most. It started with an approach requiring inheritance and contains an annex describing how to best use this as a composition approach in order to avoid problems with multiple inheritance.

When using an existing Companion Specification often questions pop up about what will happen if the Companion Specification is changing. The good news is, that based on the rules in section 3 the backward compatibility is given and therefore no real harm can happen.

What might happen, is, that the used Companion Specification is adding helpful features by creating subtypes. If the model using the Companion Specification has also created subtypes of the same type, it is not easily possible to use the new features as well.

Therefore, it is recommended, rather to use composition than subtyping when using concepts of another Companion Specification, if possible. An example, illustrating this, is given in Figure 9 and Figure 10.

In Figure 9, subtyping is used. The “ReusedType” has a feature 1, and in another model a subtype “MyObjectType” is created. When, in a new version of the Companion Specification, the “ReusedType” is extended by a subtype “ReusedSubType” adding a mandatory feature 2, “MyObjectType” is still derived from “ReusedType” and cannot use the new feature.

Figure 9 – Reusing extended Companion Specifications by inheritance

In Figure 10, composition is used. The “ReusedType” is added as component to “MyObjectType”. This allows, that any instance of “MyObjectType” can use the new created “ReusedSubType” and therefore the new feature 2, even without changing the model. Not shown in the figure, it is of course also possible (but not required) to create a subtype of “MyObjectType” changing the component to “ReusedSubType” and thereby requiring feature 2.

Note that composition does not always work perfectly, for example when the “ReusedType” is used in other places of the Companion Specification and the “my feature 1” of the new model should be made available at that place as well. In this case, the composition would require inverse browsing to the instance of “MyObjectType”.

Figure 10 – Reusing extended Companion Specifications by composition