A device might implement both a companion specification Information Model as well as the OPC UA FX Information Model. In this case, no new type would be required, just instances of the two independent models. This is illustrated in Figure B.7. In the illustration, an AutomationComponent was created and populated with a FunctionalEntity as well as an instance of FxAssetType. The FunctionalEntity organizes in its InputData, OutputData, and ConfigurationData Variables, which are components of the MyModelInstance (derived from the MyCompanionSpecType).

Figure B.7 – Parallel use of OPC UA FX and existing UA models

Another variance would be defining separate Variables in the FunctionalEntity, where the underlying device just references the same memory location for its value, as a Variable being a component of the MyModelInstance. This variance is advantageous if the OPC UA FX model has a sub-model where Variables have a different name but the same content, e.g., speed (OPC UA FX sub-model) and velocity (existing UA model). In the OPC UA AddressSpace, the Variables will be treated as different Variables, but the back end of the implementation ensures that they have the same content.

When to use:

• When the existing model/companion specification cannot be updated or modified. This implementation could also be done by a third party that layers OPC UA FX on top of an existing application.