The Interfaces defined in the OPC UA FX Information Model can be added to an existing specification model to extend the model for providing the required UA FX functionality.

The illustrated model does not create a separate FunctionalEntity and Asset since the existing model did not differentiate between the asset part and the logical functionality. The resulting extended companion specification is illustrated in Figure B.3. In the illustration, the additions to the existing companion specification model have a background colour added to help visualize the additions.

Figure B.3 – Extending type definition with Interfaces

The new model includes the ITagNameplate Interface (defined in OPC 10000-100) that is required by OPC UA FX. It also includes the IAssetRevision Interface defined in this document. These two Interfaces, coupled with the already included IVendorNameplate Interface, fulfil the requirements for the asset model. The existing model already defines input/output/configuration data that would be required for a FunctionalEntity, but it does not include the communication aspect of a FunctionalEntity, so the IFunctionalEntity Interface was added to the model. The InputData, OutputData and ConfigurationData folders provided by the Interface were updated to include references to the already defined (existing) Variables in the MyCompanionSpec model.

The OPC UA FX specification provides a required instance model. This model would not be part of the companion specification model. The companion specification, in this case, also provides a required instance model. The figure illustrates this resulting instance model. This instance model would contain the instance as described in the companion specification, but it would also require the AutomationComponent instance that is required by UA FX. This AutomationComponent instance would just reference the existing MyModelInstance from both the Assets Folder and the FunctionalEntities Folder.

It is important to understand that this is just an illustration of one possible use of Interface in an existing type model. Interfaces could be added to separate objects if the companion specification separates functionality from assets.

When to use:

• When it is important to extend an existing companion specification or vendor-specific specification with OPC UA FX and claim support for OPC UA FX. This type of update will allow the companion or vendor-specific specification to stay backwards compatible while publishing an Information Model that includes OPC UA FX. It does require a new version/release of the specification.
• Adding an Interface to an existing type is also useful when the existing type already contains some of the required information (i.e., may already have one of the required Interfaces or is based on a type that might already include the required information (i.e., DeviceType from OPC 10000-100)

OPC UA allows an Interface to be applied to type objects or to instances. The OPC UA FX Information Model can be included via Interfaces into an instance of an existing Information Model. This type of update is illustrated in Figure B.4Figure 4.

Figure B.4 – Extending an instance with Interfaces

This set of extensions is very similar to what is described in Annex B.3.2.1, but the Interfaces are applied to the instance instead of the type. The instance will include each of the Interfaces. Furthermore, the references are added to provide the mapping to the existing Variables.

When to use:

• Extending instances with Interfaces is used when an Information Model is already instantiated, and the type definition cannot be extended. Usually, this is instance-specific, and it is difficult to be reused. It can be used in a device or application that wants to utilize an existing Information Model with OPC UA FX but does not plan on creating many instances of this Object. An example could be a device that ships with a single instance of this Object. It does not require any update to a companion or vendor specification.