A Device Integration Host is a Server that manages integration of multiple Devices in an automation system and provides Clients with access to information about Devices regardless of where the information is stored, for example, in the Device itself or in a data store. The Device communication is internal to the host and may be based on field-specific protocols.

The Information Model specifies the entities that can be accessed in a Device Integration Host. This standard does not define how these elements are instantiated. The host may use network scanning services, the OPC UA Node Management Services or proprietary configuration tools.

One of the main tasks of the Information Model is to reflect the topology of the automation system. Therefore it represents the Devices of the automation system as well as the connecting communication networks including their properties, relationships, and the operations that can be performed on them.

Figure 25 and Figure 26 illustrate an example configuration and the configured topology as it will appear in the Server AddressSpace (details left out).

Figure 25 – Example of an automation system

The PC in Figure 25 represents the Server (the Device Integration Host). The Server communicates with Devices connected to Network “A” via native communication, and it communicates with Devices connected to Network “B” via nested communication.

Figure 26 – Example of a Device topology

Coloured boxes are used to recognize the various types of information.

Entry points assure common behavior across different implementations:

• DeviceTopology: Starting node for the topology configuration. See 6.2.
• DeviceSet: See 4.9.
• NetworkSet: See 5.6.

The Device Topology reflects the communication topology of the Devices. It includes Devices and the Networks. The entry point DeviceTopology is the starting point within the AddressSpace and is used to organize the communication Devices for the top level Networks that provide access to all instances that constitute the Device Topology ((sub-)networks, devices and communication elements).

The DeviceTopology node is formally defined in Table 42.

Table 42 – DeviceTopology definition

Attribute	Value
BrowseName	DeviceTopology
References	NodeClass	BrowseName	DataType	TypeDefinition
OrganizedBy by the Objects Folder defined in OPC 10000-5
HasTypeDefinition	ObjectType	BaseObjectType	Defined in OPC 10000-5.
HasProperty	Variable	OnlineAccess	Boolean	PropertyType
Conformance Units
DI DeviceTopology

OnlineAccess provides a hint of whether the Server is currently able to communicate to Devices in the topology. “False” means that no communication is available.

Management of the Device Topology is a configuration task, i.e., the elements in the topology (Devices, Networks, and Connection Points) are usually configured “offline” and – at a later time – will be validated against their physical representative in a real network.

To support explicit access to either the online or the offline information, each element may be represented by two instances that are schematically identical, i.e., there exist component Objects, FunctionalGroups, and so on. A Reference connects online and offline representations and allows to navigate between them.

This is illustrated in Figure 27.

Figure 27 – Online component for access to Device data

If Online/Offline is supported, the main (leading) instance represents the offline information. Its HasTypeDefinition Reference points to the concrete configured or identified ObjectType. All Parameters of this instance represent offline data points and reading or writing them will typically result in configuration database access. Properties will also represent offline information.

A Device can be engineered through the offline instance without online access.

The online data for a topology element are kept in an associated Object with the BrowseName Online as illustrated in Figure 27. The Online Object is referenced via an IsOnline Reference. It is always of the same ObjectType as the offline instance.

The online Parameter Nodes reflect values in a physical element (typically a Device), i.e., reading or writing to a Parameter value will then result in a communication request to this element. When elements are not connected, reading or writing to the online Parameter will return a proper status code (Bad_NotConnected).

The transfer of information (Parameters) between offline nodes and the physical device in correct order is supported through TransferToDevice, TransferFromDevice together with FetchTransferResultData. These Methods are exposed by means of an AddIn instance of TransferServicesType described in 6.4.2.

Both offline and online are created and driven by the same ObjectType. According to their usability, certain components (Parameters, Methods, and FunctionalGroups) may exist only in either the online or the offline element.

A Parameter in the offline ParameterSet and its corresponding counterpart in the online ParameterSet shall have the same BrowseName. Their NodeIds need to be different, though, since this is the identifier passed by the Client in read/write requests.

The Identification FunctionalGroup organizes Parameters that help identify a topology element. Clients can compare the values of these Parameters in the online and the offline instance to detect mismatches between the configuration data and the currently connected element.

The IsOnline ReferenceType is a concrete ReferenceType used to bind the offline representation of a Device to the online representation. The source and target Node of References of this type shall be an instance of the same subtype of a ComponentType. Each Device shall be the source of at most one Reference of type IsOnline.

The IsOnline ReferenceType is illustrated in Figure 28. Its representation in the AddressSpace is specified in Table 43.

Figure 28 – Type hierarchy for IsOnline Reference

Table 43 – IsOnline ReferenceType

Attributes	Value
BrowseName	IsOnline
InverseName	OnlineOf
Symmetric	False
IsAbstract	False
References	NodeClass	BrowseName	Comment
Subtype of Aggregates ReferenceType defined in OPC 10000-5.
Conformance Units
DI Offline

The "Online-offline data transfer" is based on the AddIn model specified in OPC 10001-7.

The transfer of information (Parameters) between offline nodes and the physical device is supported through OPC UA Methods. These Methods are built on device specific knowledge and functionality.

The transfer is usually terminated if an error occurs for any of the Parameters. No automatic retry will be conducted by the Server. However, whenever possible after a failure, the Server should bring the Device back into a functional state. The Client has to retry by calling the transfer Method again.

The transfer may involve thousands of Parameters so that it can take a long time (up to minutes), and with a result that may be too large for a single response. Therefore, the initiation of the transfer and the collection of result data are performed with separate Methods.

The Device shall have been locked by the Client prior to invoking these Methods (see 7).

The TransferServicesType provides the Methods needed to transfer data to and from the online Device. Figure 29 shows the TransferServicesType definition. It is formally defined in Table 44.

Figure 29 – TransferServicesType

Table 44 – TransferServicesType definition

Attribute	Value
BrowseName	TransferServicesType
IsAbstract	False
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
Subtype of the BaseObjectType defined in OPC 10000-5
HasComponent	Method	TransferToDevice			Mandatory
HasComponent	Method	TransferFromDevice			Mandatory
HasComponent	Method	FetchTransferResultData			Mandatory
Conformance Units
DI Offline

The StatusCode Bad_MethodInvalid shall be returned from the Call Service for Objects where locking is not supported. Bad_UserAccessDenied shall be returned if the Client User does not have the permission to call the Methods.

The support of TransferServices for an Object is declared by aggregating an instance of the TransferServicesType as illustrated in Figure 30.

Figure 30 – TransferServices

This Object is used as container for the TransferServices Methods and shall have the BrowseName Transfer. HasComponent is used to reference from a Device to its “TransferServices” Object.

The TransferServiceType and each instance may share the same Methods.

TransferToDevice initiates the transfer of offline configured data (Parameters) to the physical device. This Method has no input arguments. Which Parameters are transferred is based on Server-internal knowledge.

The Server shall ensure integrity of the data before starting the transfer. Once the transfer has been started successfully, the Method returns immediately with InitTransferStatus = 0. Any status information regarding the transfer itself has to be collected using the FetchTransferResultData Method.

The Server will reset any cached value for Nodes in the online instance representing Parameters affected by the transfer. That way the cache will be re-populated from the Device next time they are requested.

The signature of this Method is specified below. Table 45 and Table 46 specify the arguments and AddressSpace representation, respectively.

Signature

TransferToDevice(

[out] Int32 TransferID,

[out] Int32 InitTransferStatus);

Table 45 – TransferToDevice Method arguments

Argument	Description
TransferID	Transfer Identifier. This ID has to be used when calling FetchTransferResultData.
InitTransferStatus	Specifies if the transfer has been initiated. 0 – OK -1 – E_NotLocked – the Device is not locked by the calling Client -2 – E_NotOnline – the Device is not online / cannot be accessed

Table 46 – TransferToDevice Method AddressSpace definition

Attribute	Value
BrowseName	TransferToDevice
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
HasProperty	Variable	OutputArguments	Argument[]	PropertyType	Mandatory

TransferFromDevice initiates the transfer of values from the physical device to corresponding Parameters in the offline representation of the Device. This Method has no input arguments. Which Parameters are transferred is based on Server-internal knowledge.

Once the transfer has been started successfully, the Method returns immediately with InitTransferStatus = 0. Any status information regarding the transfer itself has to be collected using the FetchTransferResultData Method.

The signature of this Method is specified below. Table 47 and Table 48 specify the arguments and AddressSpace representation, respectively.

Signature

TransferFromDevice(

[out] Int32 TransferID,

[out] Int32 InitTransferStatus);

Table 47 – TransferFromDevice Method arguments

Argument	Description
TransferID	Transfer Identifier. This ID has to be used when calling FetchTransferResultData.
InitTransferStatus	Specifies if the transfer has been initiated. 0 – OK -1 – E_NotLocked – the Device is not locked by the calling Client -2 – E_NotOnline – the Device is not online / cannot be accessed

Table 48 – TransferFromDevice Method AddressSpace definition

Attribute	Value
BrowseName	TransferFromDevice
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
HasProperty	Variable	OutputArguments	Argument[]	PropertyType	Mandatory

The TransferToDevice and TransferFromDevice Methods execute asynchronously after sending a response to the Client. Execution status and execution results are collected during execution and can be retrieved using the FetchTransferResultData Method. The TransferID is used as identifier to retrieve the data.

The Client is assumed to fetch the result data in a timely manner. However, because of the asynchronous execution and the possibility of data loss due to transmission errors to the Client, the Server shall wait some time (some minutes) before deleting data that have not been acknowledged. This should be even beyond Session termination, i.e. Clients that have to re-establish a Session after an error may try to retrieve missing result data.

Result data will be deleted with each new transfer request for the same Device.

FetchTransferResultData is used to request the execution status and a set of result data. If called before the transfer is finished it will return only partial data. The amount of data returned may be further limited if it would be too large. “Too large” in this context means that the Server is not able to return a larger response or that the number of results to return exceeds the maximum number of results that was specified by the Client when calling this Method.

Each result returned to the Client is assigned a sequence number. The Client acknowledges that it received the result by passing the sequence number in the new call to this Method. The Server can delete the acknowledged result and will return the next result set with a new sequence number.

Clients shall not call the Method before the previous one returned. If it returns with an error (e.g. Bad_Timeout), the Client can call the FetchTransferResultData with a sequence number 0. In this case the Server will resend the last result set.

The Server will return Bad_NothingToDo in the Method-specific StatusCode of the Call Service if the transfer is finished and no further result data are available.

The signature of this Method is specified below. Table 49 and Table 50 specify the arguments and AddressSpace representation, respectively.

Signature

FetchTransferResultData(

[in] Int32 TransferID,

[in] Int32 SequenceNumber,

[in] Int32 MaxParameterResultsToReturn,

[in] Boolean OmitGoodResults,

[out] FetchResultType FetchResultData);

Table 49 – FetchTransferResultData Method arguments

Argument	Description
TransferID	Transfer Identifier returned from TransferToDevice or TransferFromDevice.
SequenceNumber	The sequence number being acknowledged. The Server may delete the result set with this sequence number. “0” is used in the first call after initialising a transfer and also if the previous call of FetchTransferResultData failed.
MaxParameterResultsToReturn	The number of Parameters in TransferResult.ParameterDefs that the Client wants the Server to return in the response. The Server is allowed to further limit the response, but shall not exceed this limit. A value of 0 indicates that the Client is imposing no limitation.
OmitGoodResults	If TRUE, the Server will omit data for Parameters which have been correctly transferred. Note that this causes all good results to be released.
FetchResultData	Two subtypes are possible: TransferResultError Type is returned if the transfer failed completely TransferResultData Type is returned if the transfer was performed. Status information is returned for each transferred Parameter.

Table 50 – FetchTransferResultData Method AddressSpace definition

Attribute	Value
BrowseName	FetchTransferResultData
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
HasProperty	Variable	InputArguments	Argument[]	PropertyType	Mandatory
HasProperty	Variable	OutputArguments	Argument[]	PropertyType	Mandatory

The FetchResultDataType is an abstract type. It is the base DataType for concrete result types of the FetchTransferResultData. Its elements are defined in Table 51.

Table 51 – FetchResultDataType structure

Attribute		Value
BrowseName		FetchResultDataType
IsAbstract		True
Subtype of Structure defined in OPC 10000-3
References	NodeClass		BrowseName	DataType
HasSubtype	DataType		TransferResultErrorDataType	Defined in Table 52.
HasSubtype	DataType		TransferResultDataDataType	Defined in Table 53.

The TransferResultErrorDataType is a subtype of the FetchResultDataType and represents an error result. It is defined in Table 52.

Table 52 – TransferResultError DataType structure

Name	Type	Description
TransferResultError DataType	Structure	This structure is returned in case of errors. No result data are returned. Further calls with the same TransferID are not possible.
status	Int32	-1 – Invalid TransferID: The Id is unknown. Possible reason: all results have been fetched or the result may have been deleted. -2 – Transfer aborted: The transfer operation was aborted; no results exist. -3 – DeviceError: An error in the device or the communication to the Device occurred. “diagnostics” may contain device- or protocol-specific error information. -4 – UnknownFailure: The transfer failed. “diagnostics” may contain Device- or Protocol-specific error information.
diagnostics	DiagnosticInfo	Diagnostic information. This parameter is empty if diagnostics information was not requested in the request header or if no diagnostic information was encountered in processing of the request. The DiagnosticInfo type is defined in OPC 10000-4.

The TransferResultData DataType is a subtype of the FetchResultDataType and includes parameter-results from the transfer operation. It is defined in Table 53.

Table 53 – TransferResultData DataType structure

Name	Type	Description
TransferResultData DataType	Structure	A set of results from the transfer operation.
sequenceNumber	Int32	The sequence number of this result set.
endOfResults	Boolean	TRUE – all result data have been fetched. Additional FetchTransferResultData calls with the same TransferID will return a FetchTransferError with status=InvalidTransferID. FALSE – further result data shall be expected.
parameterDefs	ParameterResult DataType []	Specific value for each Parameter that has been transferred. If OmitGoodResults is TRUE, parameterDefs will only contain Parameters which have not been transferred correctly.
NodePath	QualifiedName[]	List of BrowseNames that represent the relative path from the Device Object to the Parameter following hierarchical references. The Client may use these names for TranslateBrowsePathsToNodeIds to retrieve the Parameter NodeId for the online or the offline representation.
statusCode	StatusCode	OPC UA StatusCode as defined in OPC 10000-4 and in OPC 10000-8.
diagnostics	DiagnosticInfo	Diagnostic information. This parameter is empty if diagnostics information was not requested in the request header or if no diagnostic information was encountered in processing of the request. The DiagnosticInfo type is defined in OPC 10000-4.