This section defines Objects, Variables and Methods with NodeIds defined in this specification. Clients can directly use those NodeIds to access the instances, and use the functionality.

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.

The Method RemoveIODD removes an IODD from the server and is used by the IODDManagement Object (see 8.2).

The following rules for deleting IODDs apply:

• If the IODD is used (meaning there is an instance of the ObjectType in the AddressSpace of the Server) and the force flag is set to “False” the operation shall fail. Clients need to remove the usage of the IODD first before it can be deleted.
• If the IODD is used (meaning there is an instance of the ObjectType in the AddressSpace of the Server) and the force flag is set to “True” the operation shall succeed and remove all instances of the corresponding ObjectType in the AddressSpace.

Signature

RemoveIODD (

[in]NodeId IODD,

[in]Boolean Force,

[out]Int32 Status

);

Argument	Description
IODD	NodeId of the ObjectType representing an IODD description. The Node shall be referenced by the IODDs Object with an Organizes Reference.
Force	If “True”: Force the immediate deletion of instances of the ObjectType in the AddressSpace.
Status	Returns the status of the operation. 0: OK, operation successful -1: NodeId invalid for this operation – no NodeId of an IODD representation -2: IODD in use and cannot be deleted

Method Result Codes (defined in Call Service)

Result Code	Description
Bad_UserAccessDenied	See OPC 10000-4 for a general description.

The IOLinkMasterSet Object is referencing all Objects of IOLinkMasterType managed in the Server with an Organizes Reference (see Figure 9). It is formally defined in Table 46. The IOLinkMasterSet Object shall be referenced from the Objects Object defined in OPC 10000-5 with an Organizes Reference.

Since later versions of this specification might change the parent of this Object, Clients aware of this standardized Object shall not access it via its parent but directly via its standardized NodeId.

Table 46 – IOLinkMasterSet Definition

Attribute				Value
BrowseName				IOLinkMasterSet
References	NodeClass	BrowseName	TypeDefinition		Comment
HasTypeDefinition	ObjectType	FolderType			Defined in OPC 10000-5.