There are three main approaches for applying OPC UA FX to existing Information Models.

• Creating a new model based on the OPC UA FX Information Model (see B.2).
• Extending an existing OPC UA Information Model with OPC UA FX (see B.3). This can be accomplished in several manners:
• By a simple mapping
• By using Interfaces (see B.3.2)
• By using AddIns (see B.3.3)
• Defining a parallel OPC UA FX model and linking it to an existing OPC UA Information Model (see B.3.4).

The three approaches can be used in combination, in that the asset model might use the first approach, and a FunctionalEntity might use the second or third approach or any combination.

This approach uses the OPC UA FX model type definitions as a starting point for the creation of a sub-model, as illustrated in Figure B.1. Objects can be derived from OPC UA FX base ObjectTypes to create new ObjectTypes.

Figure B.1 – New Subtype model based on OPC UA FX model

The sub-types might define a fixed set of optional items like in MyAssetType, which fixed optional IVendorNameplateType variables (i.e., making them mandatory). It may define a fixed structure of Connectors or a structure for the given Asset. Creating sub-types might also define fixed Variable(s) that all instances would contain, such as the ConfigurationData in MyFunctionalEntityType. It may define fixed ControlGroups or a fixed group of SubFunctionalEntities. Then, all instances of these types would include the provided structures, extensions, or other functionality. These sub-types might also contain Objects, Variables, or Methods that have no bearing on the OPC UA FX model.

When to use this approach:

• Creating an Information Model for a new companion specification, where all instances of the new model are expected to provide the described functionality. OPC UA FX facets like Motion and IO may provide their own derived types.
• Creating an Information Model for a new vendor-specific specification. This is especially true for asset models, where a vendor would want to represent the hardware that they sell.
• Creating a customer/application-specific Information Model. This would typically be related to functional models that would want to be standardized for use between multiple devices.

There are different ways of extending an existing UA model without losing backward compatibility. The existing model might be defined in a companion specification (or vendor specification), and the specification could be extended to include OPC UA FX as part of its model. These additions could be accomplished using Interfaces or via AddIns; examples of both are provided.

Figure B.2 illustrates the original model defined in the example specification. The illustration shows a model that uses an Interface from OPC 10000-100, but this would not be required. It is included to help illustrate a model that might already include some functionality used by OPC UA FX. The illustration also shows an instance of the type defined by the model and a folder structure for that instance that is part of the example specification model.

Figure B.2 – Base Information Model for examples

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.

Figure B.5 illustrates the base model used for illustrating AddIns. This base model is similar to the base model for Interface but removed the IVendorNameplateType.

Figure B.5 – Base Information Model for examples

AddIns are used to attach OPC UA FX Information Model-specific content to an existing OPC UA Information Model. This is possible on the type definition level or the instance level. Only the type definition level is illustrated. The instance level would be identical, just applied to an instance instead of a type.

Extending the type definition with AddIns is done by adding the Reference HasAddIn to the FunctionalEntityType and FxAssetType. During instantiation, this leads to the creation of a new MyFunction instance and a new MyAsset instance, which are bound with these references to the OPC UA instance of the existing Information Model. This type of update is illustrated in Figure B.6Figure 4.

When to use:

• When it is important to include OPC UA FX functionality in an existing Information Model and the model does not include any of the functionality defined in UA FX [for example, any of the FxAssetType interfaces – IVendorNameplateType, ITagNameplateType]. An AddIn also allows the function to be placed as a separate object, which might be easier to profile as included or omitted.

Figure B.6 – Extending type with Addin

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.

The examples provided in this annex are only some of the possible ways the OPC UA FX Information Model can be integrated into an existing model or used in conjunction with a new or existing model. The selection of which techniques are used should depend on other factors, such as:

• Does the model already exist and have adoption? If yes, is backward compatibility essential?
• Is it possible to extend the original Information Model (i.e. generate a new revision of the companion specification)?
• Does the existing model contain an asset model?
• Does it contain a functional model?
• Does it contain nested sub-models?

This is just a partial list of questions that a developer might want to consider when investigating options for adding UAFX to an existing specification/controller/application.

The certification program will be able to certify any of the options to help assure interoperability and compatibility.