This specification is used as base for many other companion specifications like
- OPC UA for IEC61131-3
- OPC UA Information Model for FDT Technology
- OPC UA for IO-Link.
Those companion specifications define different aspects of devices, for example
- some specific functionality (like the scan operation of a RFID reader in the AutoId spec),
- the view of the device accessed by a specific protocol (like IO-Link),
- or the configuration capabilities of a device as defined in a vendor-specific device package (like FDI or FDT).
When an OPC UA application wants to combine those different aspects of one device in its address space, there are potential problems as shown in Figure C.1. The example shows the application of the AutoId specification as well as the FDT specification for the same device. For simplicity, only the base ObjectTypes are shown. In reality, there has to be a subtype of the abstract FdtDeviceType and there would be very likely a vendor-specific subtype of the RfidReaderDeviceType.
As shown in the figure, there are actually two Objects of different ObjectTypes representing different aspects of the same device in the real world.
In order to avoid multiple-inheritance, which is not further defined in OPC UA, it is not possible to directly combine both ObjectTypes into one ObjectType containing all aspects of the device. And an Object cannot be defined by two ObjectTypes. Therefore, in order to expose the information, that both Objects actually represent different aspects of the same device, composition should be used as shown in Figure C.2.
In this case, the device is represented by an Object “MyDevice” where the vendor of the OPC UA Application can provide its specific knowledge of the device. In addition, the Object has two components called FDTView and AutoIdView in the figure, containing the information as defined in the corresponding companion specifications.