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 28 and Figure 29 illustrate an example configuration and the configured topology as it will appear in the Server AddressSpace (details left out).

Figure 28 – Example of an automation system

The PC in Figure 28 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 29 – Example of a Device topology

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

Entry points assure common behaviour across different implementations:

• DeviceTopology: Starting node for the topology configuration. See 7.2.
• DeviceSet: See 5.9.
• NetworkSet: See 6.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 organise 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

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 30.

Figure 30 – 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 30. 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 8.2.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 organises 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 31. Its representation in the AddressSpace is specified in Table 43.

Figure 31 – 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.