This informative Annex describes guidelines for the usage of this specification as base for creating companion specifications as well as guidelines on how to combine different companion specifications based on this specification describing different aspects of the same device in one OPC UA application.
This specification is used as base for many other companion specifications like
- OPC UA for IEC61131-3
- OPC UA Information Model for FDT Technology
- AutoId
- 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.
Figure C.1 – Example of applying two companion specifications based on OPC UA for Devices
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.
Figure C.2 – Using composition to compose one device representation defined by two companion specifications
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.
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.
When supporting several companion specifications in one OPC UA application it is recommended to use the composition approach as described in section C.1. To expose the possibilities further, the example is extended as shown in Figure C.3. Again, subtypes for the concrete type of device are not considered for simplicity. The IOLinkDeviceType is already not derived from DeviceType but TopologyElementType. As the FDT and AutoID specifications derive from DeviceType, the device is represented by several instances of the DeviceType.
Figure C.3 – Example of applying several companion specifications (I)
In order to limit the usage of DeviceType instances, an alternative approach is shown in Figure C.4. Here, the RfidReaderDeviceType is used as main Object to represent the device, and the objects defined by the other companion specifications are composed.
Figure C.4 – Example of applying several companion specifications (II)
It is recommended to use one of the two approaches described above.
Deploying several Information Models based on this specification on the same device may lead to the situation, that the same Variable (e.g. the Property SerialNumber) for the same device is used in several places.
When the Property is the same, and the value of the Property is the same, it is recommended to avoid, that the value is managed in the Server in two different places (see Figure C.5, left). One solution is, that the two Variables reference the same internal memory managing the value (see Figure C.5, middle). Another solution is, that the Variable is only managed once in the Server, just referenced from different places (see Figure C.5, right). The solution using the same Node is the most optimized one in terms of memory consumption.
Figure C.5 – Options how to manage the same Variable
In the previous sections it was shown how to use this specification when you want to use at least the TopologyElementType, providing you the capabilities to manage Parameters and Methods via ParameterSet and MethodSet and FunctionalGroups.
If the companion specification only wants to reuse other aspects of this specification, defined in the Interfaces in 4.5 or the AddIns "Locking" in 7 or Software update in 8, the companion specification does not need to derive from the ObjectTypes defined in this specification. Instead of, it can just implement the Interfaces or use the AddIns in their ObjectTypes and build an ObjectType-Hierarchy independent of this specification.
In Figure C.5, an example is given. The companion specification defines an ObjectType hierarchy, and uses the AddIns in the appropriate places (Lock and Transfer). The Interfaces can either be implemented by the ObjectTypes directly (Figure C.5), or by a sub-component in order to group the functionality (Figure C.7). In the second approach, the RootType does not implement the IVendorNameplate directly, but uses a component (Identification) implementing the Interface. Here, the FunctionalGroupType and the predefined name Identification is used. The B_Type extends the Identification and also implements the ITagNameplateType.
Figure C.6 – Example on how to use AddIns and Interface
The advantage of the first approach is, that the content of the Interface is directly at the ObjectType, whereas the advantage of the second approach is, that the content of the Interface is grouped in the sub-component. When the content of the Interface and the additional content of the ObjectType and its expected subtypes is rather small, the first approach is recommended. If the content of the Interface or the additional content of the ObjectType or its subtypes is rather large, the additional grouping Object is recommended, as it does not provide a flat list of sub-components, but groups them accordingly and thus makes it easier to use.
Figure C.7 – Example on how to use Interface with additional Object
Bibliography
IEC 61784: Industrial Communication Networks - Profiles
IEC 61499-1 ed2.0: Function Blocks – Part 1: Architecture
IEC 61131, IEC standard for Programmable Logic Controllers (PLCs)
ISO/IEC 11179-6 Information technology - Metadata registries (MDR) - Part 6: Registration