As shown in the previous section, composition can be used to combine the ObjectTypes defined by various specifications describing aspects of a device in order to combine the information in one OPC UA application. This can lead, as shown in the example in Figure C.2, to the usage of several instances of the DeviceType to represent one device. In order to avoid this, it is recommended that companion specifications do not directly derive from the DeviceType but instead derive from the TopologyElementType or other subtypes of the TopologyElementType (but not the DeviceType). This allows an OPC UA application to represent the device by one instance of the DeviceType and compose potentially several other aspects without the need to use the DeviceType again.

The DeviceType defines several Properties identifying the device as mandatory. By the above described approach, the Properties do not need to be repeated several times as needed in the example in Figure C.2. Here, the mandatory SerialNumber is a Property of MyDevice, FDTView, and AutoIdView. However, companion specification can still define some of those Properties on their ObjectTypes, either optional in order to allow the usage of their ObjectTypes without an additional Object (for example if only one companion specification is supported by the OPC UA application) or mandatory, if a specific access-path to the information shall be exposed. For example, the SerialNumber accessed by a specific protocol might be different than the SerialNumber managed directly by the DeviceVendor. Whereas Profibus or IO-Link represent the SerialNumber as a String, the HART protocol uses three Bytes. So, if a companion specification should expose the SerialNumber accessed via HART, it can add it as mandatory Property to its ObjectType. To conclude, it is recommended that companion specification provide the Properties of the DeviceType by implementing the IVendorNameplateType, which adds all the Properties optionally to the ObjectType. If desired, they can make some of those Properties mandatory to force that a specific access path is used (e.g. via a specific protocol).

In order to easily identify the components representing different views on the device, it is recommended to use the AddIn concept to define a standardized BrowseName for the Object (DefaultInstanceBrowseName Property). In the example in Figure C.2 that would mean that FdtDeviceType would have defined a DefaultInstanceBrowseName “FDTView”, and thus OPC UA Clients can easily find the FDT specific data of the device by looking for an Instance called “FDTView”, for example by using the TranslateBrowsePathsToNodeIds Service.