The IODDManagement Object is used to manage IODDs. It contains Methods to load IODDs into the server and to remove IODDs. An example of an AddressSpace containing the IODDManagement Object and several IODD-based ObjectTypes is shown in Figure 26.

Figure 26 – Example AddressSpace containing the IODDManagement Object

The IODDManagement Object is formally defined in Table 45. The IODDManagement Object shall be referenced from the Objects Object defined in OPC 10000-5 with an Organizes Reference.

Table 45 – IODDManagement Definition

Attribute				Value
BrowseName				IODDManagement
References	NodeClass	BrowseName	TypeDefinition		Comment
HasTypeDefinition	ObjectType	FolderType			Defined in OPC 10000-5.
HasComponent	Method	RemoveIODD			Defined in 8.3
HasComponent	Object	TransferIODD	TemporaryFileTransferType		Defined in OPC 10000-5.
Organizes	Object	IODDs	FolderType

The TransferIODD Object is used for a temporary file transfer (see OPC 10000-5 for details on the TemporaryFileTransferType). It is used to load new IODDs into the server, and, optionally, to read IODDs managed in the server.

The IODD provided by a vendor can consist of several files, providing the main XML-based file as well as optionally language files and images referenced in the main file (see IODD Specification). For loading and reading IODDs those files shall always be zipped into one file, representing the full IODD information of the device.

To load an IODD into the server, a new temporary file shall be created using the GenerateFileForWrite Method (defined in OPC 10000-5 as part of the TemporaryFileTransferType). The generateOptions argument of the Method shall be left as BaseDataType, meaning the Client shall pass a Null for that argument. After the file is written to the server, the Client shall call the CloseAndCommit Method (defined OPC 10000-5). Depending on the server implementation, the result of the operation is either directly returned in the Method call or via a state machine (see OPC 10000-5 for details).

The following rules for loading IODDs apply:

• Servers shall reject IODDs they cannot interpret (e.g. using an unsupported version or invalid XML).
• Server may reject an IODD if the checksum is invalid (see IODD Specification for details).
• If the IODD to be loaded is already managed in the server (same DeviceID and VendorID).
• The server may reject the loading operation if the IODD is used (there is an Instance of the ObjectType in the AddressSpace).
• If the server loads the IODD it shall remove the previous version of the IODD (meaning removing the ObjectType) and assign potential Instances to the new ObjectType). In that case, the NodeIds of the Instances, including all Instances derived from InstanceDeclarations, shall not change.
• If the server cannot manage the IODD due to limited resources it shall reject the loading.

Rejecting an IODD after calling the CloseAndCommit Method means that either the CloseAndCommit call directly returns a bad code or the returned completionStateMachine ends in the Error State (see OPC 10000-5 for details).

Note that the successful loading of an IODD typically leads to creating a corresponding ObjectType in this server. This is the recommended behaviour. However, it is allowed that servers do not create such an ObjectType before the ObjectType is used (e.g. by connecting a corresponding IO-Link Device to the IO-Link Master) due to limited resources of the server.

The server may also provide the capability to read an IODD managed by the server. In this case, the GenerateFileForRead Method (defined OPC 10000-5 as part of the TemporaryFileTransferType) is used to create a temporary file. This Method is mandatory on the TemporaryFileTransferType. If the server does not support reading an IODD the Executable Attribute of the Method shall be set to “False”. The generateOptions argument of the GenerateFileForRead Method shall be set to NodeId. The Client shall provide the NodeId of the ObjectType representing the IODD to create a temporary file for that IODD. Depending on the server implementation, the result of the operation is either directly returned in the Method call or via a state machine (see OPC 10000-5 for details). If the server supports this operation, a zipped file like for loading an IODD is returned.

The IODDs Object is used to group all ObjectTypes representing IODDs managed in the server. It shall reference all those ObjectTypes directly with an Organizes Reference.