Modeling approaches are shown below that describe how the powertrain information model can be integrated into an existing instance or type information model.

There are different approaches, which have their advantages depending on the use case.

  1. Modular enhancement of existing type model

Use case: An existing companion specification or manufacturer-specific type model is to be extended in a new version to include powertrain-specific modules.

  1. Modular enhancement of existing instance model

Use case: An existing instance model which is already available via an OPC UA server is to be extended by powertrain specific modules.

  1. Enhancement with whole asset type

Use case: An existing type or instance model is to be extended by the complete powertrain specific asset definition.

  1. Parallel powertrain model with SameEntityAs-Reference

Use case: Parallel to an existing instance model, the powertrain-specific information model is represented on another hierarchy level. Both submodels are referenced to each other.

Modular enhancement of existing type model

image025.jpg

Figure C-1 – Modular Enhancement of Existing Type Model

Use Case:

An existing companion specification or manufacturer-specific type model is to be extended in a new version to include powertrain-specific modules.

For this purpose, a type definition of the existing specification can be derived again. This is enriched with the necessary interfaces and objects of the PtAssetType or a sub-type, e.g. PtAssetMotorType. For this the references HasInterface or HasAddIn are used in general. To reference specific InstanceDeclarations of asset attributes the HasPtAttributes reference can be used.

The DefaultBrowsenames of the InstanceDeclarations (e.g. PtCommonAssetAttributesTypes or asset-specific AttributesTypes) are defined in this specification. This is to signal to a client the corresponding representation of a powertrain asset according to this specification e.g. a motor.

Modular enhancement of existing instance model

image026.jpg

Figure C-2 – Modular Enhancement of Existing instance Model

Use Case:

An existing instance model which is already available via an OPC UA server is to be extended by powertrain specific modules.

As for the use case from C.1, an existing object instance can be enriched with the necessary interfaces and objects of the PtAssetType or a sub-type, e.g. PtAssetMotorType.

Enhancement with whole asset type

image027.jpg

Figure C-3 – Enhancement with Whole Asset Type

Use Case:

An existing type or instance model is to be extended by the complete powertrain specific asset definition.

In contrast to the use cases from C.1 and C.2, the complete powertrain asset definition is to be transferred to an existing model. Instead of taking over the individual Interfaces and AddIns, a new instance of the PtAssetType or a sub-type e.g. PtAssetMotorType is attached with a HasAddIn reference.

As in the previous use cases, the DefaultBrowsename of the PtAssetType definitions is also defined in this specification.

An advantage with this approach is the existence of an instance of a powertrain defined asset type, e.g. PtAssetMotorType. This gives the client confidence that it is an asset defined in this specification.

A disadvantage can be the additional hierarchy level in contrast to the approaches from C.1 and C.2.

In Figure C-3 - Enhancement with whole asset type only the enhancement on instance level is shown. Of course, this enhancement can also be done on type level.

Parallel Powertrain Model

image028.jpg

Figure C-4 – Parallel Powertrain Model with SameEntityAs-Reference

Use Case:

Parallel to an existing instance model, the powertrain specific information model is represented on another hierarchy level.

In contrast to the use case from C.3, an independent submodel is created here according to this powertrain specification. Thus, it is expected that instances of the PtAssetType are on a completely different and independent hierarchy level to existing asset objects from other specifications. Also, the Browsenames of the instances may be quite different here.

To signal to a client that two different nodes in the AddressSpace represent the same entity in the real world, the RepresentsSameEntity reference between these nodes can be used. This is defined in OPC 10000-23.

___________