This clause defines how ObjectTypes shall be generated based on IODDs. For each IODD managed by the Server, the Server shall have an ObjectType as subtype of the IOLinkIODDDeviceType (see section 7.2).

The IsAbstract Attribute of the generated ObjectType shall be set to “False”.

The BrowseName Attribute of the generated ObjectType shall be mapped to the IODD DeviceIdentity/DeviceName element using the default language. The DisplayName should use the localization provided by the DeviceName.

The optional Description Attribute is vendor-specific and might be omitted.

Each NodeId that is used to describe the generated ObjectTypes shall use the Namespace “http://opcfoundation.org/UA/IOLink/IODD” and the identifierType String. The String of the NodeId of the ObjectType shall be composed of the VendorId, the DeviceId (in DeviceIdentity) and the version of the IODD (in DocumentInfo) using the format: “<VendorId>|<DeviceId>|<version>” like “888|67335|V1.1”. The InstanceDeclarations use this prefix followed by the BrowsePath. Variables and Methods, which might have several BrowsePaths use the BrowsePath coming from ParameterSet respectively MethodSet, Objects representing menus use the first BrowsePath that is defined in the IODD. The format is: “<ObjectTypeNodeId>||<BrowseName>[:<BrowseName>]”. The BrowseName only contains the String part, not the NamespaceIndex. An example is “888|67335|V1.1||ParameterSet:V_LifeTimeYears” as string-part of the NodeId of a Variable.

Defining the NodeIds of ObjectTypes based on IODDs is necessary so that OPC UA Clients accessing different OPC UA Servers implementing this specification and using the same IODDs can identify that they actually deal with the same types.

The BrowseNames used when generating ObjectTypes and their InstanceDeclarations shall use the Namespace “http://opcfoundation.org/UA/IOLink/IODD”.

In general, on the instance all rules defined on the IOLinkIODDDeviceType or its supertypes shall apply. When a new ObjectType is created, some InstanceDeclarations of the supertype are overridden in order to provide information from the IODD like VendorId.

• The VendorID shall be filled with the IODD DeviceIdentity/@vendorId.
• The DeviceID shall be filled with the IODD DeviceIdentity/@deviceId.
• The Manufacturer shall be filled with the IODD DeviceIdentity/@vendorName.
• The VendorText shall be filled with the IODD DeviceIdentity/VendorText, taking the default language.
• The DeviceClass shall be filled with the IODD DeviceIdentity/DeviceFamily.

For each menu of the IODD UserInterface/MenuCollection that is referenced directly or indirectly form the IODD UserInterface/ObserverRoleMenuSet, the IODD UserInterface/MaintenanceRoleMenuSet or the IODD UserInterface/SpecialistRoleMenuSet, an Object of ObjectType FunctionalGroupType is created.

The BrowseName of the Object shall be the Id of the IODD Menu. The DisplayName shall be the Name of the IODD Menu. Localization should be considered. The optional Description Attribute is vendor-specific and might be omitted.

For each IdentificationMenu reference (UIMenuSimpleRefT) from the IODD UserInterface/ObserverRoleMenuSet, the IODD UserInterface/MaintenanceRoleMenuSet and the IODD UserInterface/SpecialistRoleMenuSet a HasIdentificationMenu Reference shall be created from the corresponding Object defined in section 7.2. The referenced Object shall have the ModellingRule Mandatory.

For each ParameterMenu reference (UIMenuSimpleRefT) from the IODD UserInterface/ObserverRoleMenuSet, the IODD UserInterface/MaintenanceRoleMenuSet and the IODD UserInterface/SpecialistRoleMenuSet a HasParameterMenu Reference shall be created from the corresponding Object defined in section 7.2. The referenced Object shall have the ModellingRule Mandatory.

For each ObservationMenu reference (UIMenuSimpleRefT) from the IODD UserInterface/ObserverRoleMenuSet, the IODD UserInterface/MaintenanceRoleMenuSet and the IODD UserInterface/SpecialistRoleMenuSet a HasObservationMenu Reference shall be created from the corresponding Object defined in section 7.2. The referenced Object shall have the ModellingRule Mandatory.

For each DiagnosisMenu reference (UIMenuSimpleRefT) from the IODD UserInterface/ObserverRoleMenuSet, the IODD UserInterface/MaintenanceRoleMenuSet and the IODD UserInterface/SpecialistRoleMenuSet an HasDiagnosisMenu Reference shall be created from the corresponding Object defined in section 7.2. The referenced Object shall have the ModellingRule Mandatory.

In Figure 13 an example of how to map IODD menus is shown. On the left, an excerpt of an IODD is shown, and on the right, the OPC UA representation.

Figure 13 – Example on how to map IODD Menus from UserInterface

For each IODD Menu that has been added all MenuRefs shall reference the corresponding Objects with an Organizes Reference. If at least one IODD UIMenuRef does not provide an IODD MenuRef/Condition element, the ModellingRule shall be Mandatory, otherwise it shall be Optional.

In Figure 14 another example of how to map IODD menus is shown. On the left, an excerpt of an IODD is shown, and on the right, the OPC UA representation. In this example, IODD Menus contain other IODD Menus.

Figure 14 – Example on how to map IODD Menus containing IODD Menus

For each IODD Variable defined in the IODD an OPC UA Variable is created that is referenced from the ParameterSet with a HasComponent Reference. The ModellingRule shall be Mandatory for each of those Variables.

Each Object representing a menu referencing the Variable via a VariableRef not defining a Button shall reference the Variable with an Organizes Reference.

Each Object representing a menu referencing the Variable via a RecordItemRef not defining a Button shall reference the corresponding Sub-Variable with an Organizes Reference.

The BrowseName of the Variable shall be the Id of IODD Variable and the DisplayName the Name of the IODD Variable. Localization should be considered. The Description Attribute shall be the Description of IODD Variable. Localization should be considered.

The VariableType, DataType, ValueRank and ArrayDimensions are set according to section 12 depending on the Datatype or DatatypeRef. In addition, the VariableRef or RecordItemRef defines some characteristics that need to be considered.

• If at least one VariableRef contains a unitCode the Variable shall have the Property EngineeringUnits. If more than one VariableRef references the IODD Variable and all VariableRefs contain the unitCode, the EngineeringUnits shall have the ModellingRule Mandatory, otherwise the ModellingRule Optional. The value of EngineeringUnits is vendor-specific because several VariableRefs might define different unitCodes. It might be omitted on the InstanceDeclaration.
• If at least one VariableRef contains a displayFormat the Variable shall have the Property DisplayFormat (see section 13.6). If all VariableRefs contain the displayFormat, the DisplayFormat shall have the ModellingRule Mandatory, otherwise the ModellingRule Optional. The value of DisplayFormat is vendor-specific. It might be omitted on the InstanceDeclaration.

The same rules apply for the sub-variables referenced based on the RecordItemRefs.

The accessRightRestriction is ignored on the ObjectType and only considered on the instances.

In Figure 15 an example is shown of how to map IODD Variables referenced from an IODD Menu to OPC UA.

Figure 15 – Example on how to map Variables

In Figure 16 another example is shown. In this example, the VariableRefs to the same IODD Variable contain different information.

Figure 16 – Example on how to map Variables with different VariableRefs

In Figure 17 an example on how to map RecordItemRefs is shown.

Figure 17 – Example on how to map Variables with RecordItemRefs

VariableRefs and RecordItemRefs can define Buttons. Those IODD Buttons are mapped to OPC UA Methods.

For each Button-defining VariableRef or RecordItemRef from an IODD Menu that is used in the mapping (see section 7.3.5) an OPC UA Method is created, that is referenced with a HasComponent Reference from the MethodSet Object.

In case several VariableRefs or RecordItemRefs have the same characteristics (Description, ActionStartedMessage, buttonValue, and in case of RecordItemRefs same subindex), only one Method is created.

The Objects representing the IODD Menus shall reference the corresponding Methods with Organizes References.

If at least one Object representing an IODD Menu referencing the Method has the ModellingRule Mandatory the Method shall have the ModellingRule Mandatory, otherwise Optional.

The BrowseName of the Method shall be the Id of the IODD Variable combined with the buttonValue. The format is “<Id>|<buttonValue>”. In the unlikely case that the IODD Variable is referenced several times as Button with the same buttonValue but different other characteristics (Description and ActionStartedMessage), the additional Methods have a BrowseName postfixed by a number using the format “<Id>|<buttonValue>_<n>” where “n” is the occurrence in the order of the IODD, starting with a 2 for the second occurrence.

The DisplayName shall be the Description of the IODD Button, if a Description is provided. Localization should be considered. If no Description is provided, the DisplayName should be the BrowseName. The optional Description Attribute is vendor-specific and might be omitted.

The Methods shall not have input- or output-arguments. If the optional ActionStartedMessage of the IODD Button is provided, there shall be a Property with BrowseName “ActionStartedMessage” and the DataType String, providing the ActionStartedMessage of the IODD Button.

Note: The way a button is modelled inside an IODD VariableRef element changed from IODD Specification Version 1.0.1 to Version 1.1. The information modelled in IODD Specification Version 1.1 in the elements Description and ActionStartedMessage is not provided in IODD Specification Version 1.0.1.

The server-internal implementation of the Method shall implement the IODD Button according to the IODD Specification.

An example on how to map IODD Buttons to OPC UA Methods is shown in Figure 18.

Figure 18 – Example on how to map IODD Buttons to OPC UA Methods

The StdVariableRefs (standard variable references) reference to standardized information, that is already defined in the IOLinkDeviceType. In Table 21, an overview of the mapping is given.

Table 21 – Mapping of StdVariableRefs to IOLinkDeviceType Instance Declarations

StdVariableRef	InstanceDeclaration
V_SystemCommand	MethodSet/SystemCommand
V_DeviceAccessLocks	DeviceAccessLocks
V_VendorName	Manufacturer
V_VendorText	VendorText
V_ProductName	Model
V_ProductID	ProductID
V_ProductText	ProductText
V_SerialNumber	SerialNumber
V_HardwareRevision	DeviceRevision
V_FirmwareRevision	SoftwareRevision
V_ApplicationSpecificTag (V_ApplicationSpecificName for IODDs based on IODD Specification 1.01)	ParameterSet/ApplicationSpecificTag
V_ErrorCount	ParameterSet/ErrorCount
V_DeviceStatus (not defined in IODD Specification 1.01)	ParameterSet/DeviceHealth
V_DetailedDeviceStatus (not defined in IODD Specification 1.01)	ParameterSet/DetailedDeviceStatus
V_ProcessDataInput (V_ProcessDataIn for IODDs based on IODD Specification 1.01)	ParameterSet/ProcessDataInput
V_ProcessDataOutput (V_PrcoessDataOut for IODDs based on IODD Specification 1.01)	ParameterSet/ProcessDataOutput
V_OffsetTime	ParameterSet/OffsetTime

The StdRecordItemRefs (standard record item references) reference to standardized information, that is already defined in the IOLinkDeviceType. In Table 22, an overview of the mapping is given.

Table 22 – Mapping of StdRecordItemRefs to IOLinkDeviceType Instance Declarations

StdRecordItemRef		InstanceDeclaration
V_DirectParameters_1	STD_TN_MasterCycleTime	-
V_DirectParameters_1	STD_TN_MinCycleTime	MinCycleTime
V_DirectParameters_1	STD_TN_M-SequenceCapability	-
V_DirectParameters_1	STD_TN_RevisionID	RevisionID
V_DirectParameters_1	STD_TN_ProcessDataIn	ParameterSet/ProcessDataInput/ProcessDataLength
V_DirectParameters_1	STD_TN_ProcessDataOut	ParameterSet/ProcessDataOutput/ProcessDataLength
V_DirectParameters_1	STD_TN_VendorID1	VendorID
V_DirectParameters_1	STD_TN_VendorID2	VendorID
V_DirectParameters_1	STD_TN_DeviceID1	DeviceID
V_DirectParameters_1	STD_TN_DeviceID2	DeviceID
V_DirectParameters_1	STD_TN_DeviceID3	DeviceID
V_DirectParameters_1	STD_TN_SystemCommand	-
V_DirectParameters_2	STD_TN_DeviceSpecific_1	-
V_DirectParameters_2	STD_TN_DeviceSpecific_2	-
V_DirectParameters_2	STD_TN_DeviceSpecific_3	-
V_DirectParameters_2	STD_TN_DeviceSpecific_4	-
V_DirectParameters_2	STD_TN_DeviceSpecific_5	-
V_DirectParameters_2	STD_TN_DeviceSpecific_6	-
V_DirectParameters_2	STD_TN_DeviceSpecific_7	-
V_DirectParameters_2	STD_TN_DeviceSpecific_8	-
V_DirectParameters_2	STD_TN_DeviceSpecific_9	-
V_DirectParameters_2	STD_TN_DeviceSpecific_10	-
V_DirectParameters_2	STD_TN_DeviceSpecific_11	-
V_DirectParameters_2	STD_TN_DeviceSpecific_12	-
V_DirectParameters_2	STD_TN_DeviceSpecific_13	-
V_DirectParameters_2	STD_TN_DeviceSpecific_14	-
V_DirectParameters_2	STD_TN_DeviceSpecific_15	-
V_DirectParameters_2	STD_TN_DeviceSpecific_16	-

In both cases, the following rule applies.

If there is an InstanceDeclaration on the IOLinkDeviceType:

• If the StdVariableRef or StdRecordItemRef is not defining a Button and the InstanceDeclaration is a Variable, the InstanceDeclaration shall be overridden in the new created type and referenced from all Objects representing IODD Menus having such a reference. If a default value is defined, the OPC UA Server shall use this as Value of the Variable, if several different default values are defined, the first one defined in the IODD shall be used. Other characteristics defined on the StdVariableRef of StdRecordItemRef are ignored.

For VendorID and DeviceID there are two resp. three StdRecordItemRefs used. In the mapping, whenever an IODD Menu references at least one of them, the whole Variable (VendorID or DeviceID) is referenced.

• If the StdVariableRef or StdRecordItemRef is defining a Button, the rules defined in 7.3.7 apply.

If there is no InstanceDeclaration on the IOLinkDeviceType defined, the same rules as for VariableRef and RecordItemRef defined in 7.3.6 and 7.3.7 apply.

Note that for V_SystemCommand the mapping described in this section applies, although there is a representation in the IOLinkDeviceType (SystemCommand Method), because the IODD provides useful new information about the supported system commands.

The ProcessDataCollection gives an interpretation of the input and / or output process data.

For each entry of the collection (IODD ProcessData) having an IODD ProcessDataOut of type ProcessDataItemT, for each IODD ProcessDataOut, a new sub-variable of the OPC UA Variable ProcessDataOutput is created, having the BrowseName composed of the ProcessData id and the ProcessDataItem id (“<ProcessData id>|<ProcessDataItem id>”). If the ProcessData has a Condition, the Variable becomes optional, otherwise mandatory. In order to add a sub-variable to the ProcessDataOutput Variable defined on the IOLinkDeviceType, the ProcessDataOutput Variable needs to be overridden on the new created IODD-based subtype.

For each entry of the collection (IODD ProcessData) having a ProcessDataIn of type ProcessDataItemT, for each ProcessDataIn, a new sub-variable of ProcessDataInput is created, having the BrowseName composed of the ProcessData id and the ProcessDataItem id (“<ProcessData id>|<ProcessDataItem id>”). If the ProcessData has a Condition, the Variable becomes optional, otherwise mandatory. In order to add a sub-variable to the ProcessDataInput Variable defined on the IOLinkDeviceType, the ProcessDataInput Variable needs to be overridden on the new created IODD-based subtype.

In both cases the DisplayName shall be the Name element of the ProcessDataItem. Localization should be considered. The DataType is chosen for the Datatype element or DatatypeRef element according to section 12.

The ProcessDataRefCollection can provide additional characteristics for the created Variables, like unitCode and displayFormat. Note that the optional ProcessDataRefCollection and its child elements are not supported by IODD Specification Version 1.0.1.

If the ProcessDataRef contains a unitCode the Variable shall have the Property EngineeringUnits as mandatory. The value shall be as defined in the ProcessDataRef (see Annex C).

If the ProcessDataRef contains a displayFormat the Variable shall have the Property DisplayFormat (see 13.6) as mandatory. The value shall be as defined in the ProcessDataRef.

In Figure 19 an example is shown on how to map an IODD ProcessDataCollection.

Figure 19 – Example on how to map IODD ProcessDataCollection

In case the DirectParameterOverlay is defined in the IODD, the mapping shall be the same as for Variables with respect to the DataType (RecordT). The BrowseName shall be “DirectParameterPage2”, and the DisplayName the same for locale “en” and might provide translations. A vendor-specific Description might be provided.

In different places of the IODD default values can be defined.

• The DirectParameterOverlay can define default values for the individual entries
• The StdVariableRef can define default values
• The Variable can define default values
• The RecordItemInfo and StdRecordItemRef can define default values

In all cases the default value shall be provided as value of the corresponding Variables on the ObjectType. In case of StdVariableRefs the Variables are already defined in the supertype and need to be overridden on the IODD-based type in order to provide the default value.

An example on how to map DefaultValues is shown in Figure 20.

Figure 20 – Example on how to map Default Values

All entries of the DeviceVariantCollection are mapped to instances of DeviceVariantType according to section 7.7. The Objects are referenced from the DeviceVariants Object with a HasComponent Reference.

The first entry of the DeviceVariantCollection is also mapped to the DeviceVariant Object.

In Figure 21 an example is given.

Figure 21 – Example on how to map DeviceVariantCollection

Information about Events (Notification) is not mapped to additional EventTypes, but the IOLinkIODDDeviceEventType is used.

When an IO-Link Device sends a Notification, and the server manages the IODD for the IO-Link Device, an Event of the IOLinkIODDDeviceEventType is generated according to the EventType definition.

Information about Alarms (Warning and Error) is not mapped to additional EventTypes, but the IOLinkIODDDeviceAlarmType is used. If the OPC UA server supports Alarm Objects represented in the AddressSpace, the server may provide the Alarms Object on the ObjectType and provide all possible Alarms as Objects based on the IODD.

When an IO-Link Device sends a Warning or Error, and the server manages the IODD for the IO-Link Device, an Event of the IOLinkIODDDeviceAlarmType is generated according to the EventType definition.