1 Scope

This part of the OPC UA specification is an extension of the overall OPC Unified Architecture specification series and defines the information model associated with Devices. This specification describes three models which build upon each other as follows:

The (base) Device Model is intended to provide a unified view of devices and their hardware and software parts irrespective of the underlying device protocols.

The Device Communication Model adds Network and Connection information elements so that communication topologies can be created.

The Device Integration Host Model finally adds additional elements and rules required for host systems to manage integration for a complete system. It enables reflecting the topology of the automation system with the devices as well as the connecting communication networks.

This document also defines AddIns that can be used for the models in this document but also for models in other specifications. They are:

Locking model – a generic AddIn to control concurrent access,

Software update model – an AddIn to manage software in a Device.

2 Normative references

The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments and errata) applies.

3 Terms, definitions, abbreviated terms, and conventions

3.1 Terms and definitions

For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-3, and OPC 10000-8 as well as the following apply.

3.1.1 Block

functional Parameter grouping entity

3.1.2 BlockMode

mode of operation (target mode, permitted modes, actual mode, and normal mode) for a Block

3.1.3 Communication Profile

fixed set of mapping rules to allow unambiguous interoperability between Devices or Applications, respectively

3.1.4 Connection Point

logical representation of the interface between a Device and a Network

3.1.5 Device

independent physical entity capable of performing one or more specified functions in a particular context and delimited by its interfaces

3.1.6 Device Integration Host

Server that manages integration of multiple Devices in an automation system

3.1.7 Device Topology

arrangement of Networks and Devices that constitute a communication topology

3.1.8 Fieldbus

communication system based on serial data transfer and used in industrial automation or process control applications

3.1.9 Parameter

variable of the Device that can be used for configuration, monitoring or control purposes

3.1.10 Network

means used to communicate with one specific protocol

3.1.11 Direct-Loading

update method where the original software is overwritten during the transfer

3.1.12 Cached-Loading

update method where the new software is stored in a separate area

3.1.13 File System based Loading

update method based on an accessible directory structure and a separate install method

3.1.14 Software Package

single file that contains the data for the software update in a device specific format

3.1.15 Software Update Client

update client that can be used for Devices of several vendors

3.1.16 Current Version

version information of the software that is currently installed

3.1.17 Pending Version

version information for a Software Package that was transferred before and is ready to be installed

3.1.18 Fallback Version

version information about an alternatively installable software that is located on the Server

3.2 Abbreviated terms

3.3 Conventions used in this document

3.3.1 Conventions for Node descriptions

3.3.1.1 Node definitions

Node definitions are specified using tables (see Table 2).

Attributes are defined by providing the Attribute name and a value, or a description of the value.

References are defined by providing the ReferenceType name, the BrowseName of the TargetNode and its NodeClass.

• If the TargetNode is a component of the Node being defined in the table the Attributes of the composed Node are defined in the same row of the table.

• The DataType is only specified for Variables; “[<number>]” indicates a single-dimensional array, for multi-dimensional arrays the expression is repeated for each dimension (e.g. [2][3] for a two-dimensional array). For all arrays the ArrayDimensions is set as identified by <number> values. If no <number> is set, the corresponding dimension is set to 0, indicating an unknown size. If no number is provided at all the ArrayDimensions can be omitted. If no brackets are provided, it identifies a scalar DataType and the ValueRank is set to the corresponding value (see OPC 10000-3). In addition, ArrayDimensions is set to null or is omitted. If it can be Any or ScalarOrOneDimension, the value is put into “{<value>}”, so either “{Any}” or “{ScalarOrOneDimension}” and the ValueRank is set to the corresponding value (see OPC 10000-3) and the ArrayDimensions is set to null or is omitted. Examples are given in Table 1.

• The TypeDefinition is specified for Objects and Variables.

• The TypeDefinition column specifies a symbolic name for a NodeId, i.e. the specified Node points with a HasTypeDefinition Reference to the corresponding Node.

• The ModellingRule of the referenced component is provided by specifying the symbolic name of the rule in the ModellingRule column. In the AddressSpace, the Node shall use a HasModellingRule Reference to point to the corresponding ModellingRule Object.

If the NodeId of a DataType is provided, the symbolic name of the Node representing the DataType shall be used.

Note that if a symbolic name of a different namespace is used, it is prefixed by the NamespaceIndex (see 3.3.2.2).

Nodes of all other NodeClasses cannot be defined in the same table; therefore, only the used ReferenceType, their NodeClass and their BrowseName are specified. A reference to another part of this document points to their definition.

Table 2 illustrates the table. If no components are provided, the DataType, TypeDefinition and Other columns can be omitted and only a Comment column is introduced to point to the Node definition.

Components of Nodes can be complex that is containing components by themselves. The TypeDefinition, NodeClass and DataType can be derived from the type definitions, and the symbolic name can be created as defined in 3.3.3.1. Therefore, those containing components are not explicitly specified; they are implicitly specified by the type definitions.

The Other column defines additional characteristics of the Node. Examples of characteristics that can appear in this column are show in Table 3.

If multiple characteristics are defined, they are separated by commas. The name or the short name can be used.

Each Node defined in this specification has ConformanceUnits defined in 11 that require the Node to be in the AddressSpace. If a Server supports a ConformanceUnit, it shall expose the Nodes related to the ConformanceUnit in its AddressSpace. If two Nodes are exposed, all References between the Nodes defined in this specification shall be exposed as well.

The relations between Nodes and ConformanceUnits are defined at the end of the tables defining Nodes, one row per ConformanceUnit. The ConformanceUnit is reflected with a Category element in the UANodeSet file (see OPC 10000-6).

The Nodes defined in a table are not only the Node defined on top level, for example an ObjectType, but also the Nodes that are referenced, as long as they are not defined in other tables. For example, the ObjectType TopologyElementType defines its InstanceDeclarations in the same table, so the InstanceDeclarations are also bound to the ConformanceUnits defined for the table. The table even indirectly defines additional InstanceDeclarations as components of the top-level InstanceDeclarations, that are not directly visible in the table. The TypeDefinitions and DataTypes used in the InstanceDeclarations, and the ReferenceTypes are defined in their individual tables and not in the table itself, therefore they are not bound to the ConformanceUnits of the table.

3.3.1.2 Additional References

To provide information about additional References, the format as shown in Table 4 is used.

References can be to any other Node.

3.3.1.3 Additional sub-components

To provide information about sub-components, the format as shown in Table 5 is used.

3.3.1.4 Additional Attribute values

The type definition table provides columns to specify the values for required Node Attributes for InstanceDeclarations. To provide information about additional Attributes, the format as shown in Table 6 is used.

There can be multiple columns to define more than one Attribute.

3.3.2 NodeIds and BrowseNames

3.3.2.1 NodeIds

The NodeIds of all Nodes described in this standard are only symbolic names. Annex A defines the actual NodeIds.

The symbolic name of each Node defined in this document is its BrowseName, or, when it is part of another Node, the BrowseName of the other Node, a “.”, and the BrowseName of itself. In this case “part of” means that the whole has a HasProperty or HasComponent Reference to its part. Since all Nodes not being part of another Node have a unique name in this document, the symbolic name is unique.

The NamespaceUri for all NodeIds defined in this document is defined in Annex A. The NamespaceIndex for this NamespaceUri is vendor-specific and depends on the position of the NamespaceUri in the server namespace table.

Note that this document not only defines concrete Nodes, but also requires that some Nodes shall be generated, for example one for each Session running on the Server. The NodeIds of those Nodes are Server-specific, including the namespace. But the NamespaceIndex of those Nodes cannot be the NamespaceIndex used for the Nodes defined in this document, because they are not defined by this document but generated by the Server.

3.3.2.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this document is specified in the tables defining the Nodes. The NamespaceUri for all BrowseNames defined in this document is defined in Annex A.

For InstanceDeclarations of NodeClass Object and Variable that are placeholders (OptionalPlaceholder and MandatoryPlaceholder ModellingRule), the BrowseName and the DisplayName are enclosed in angle brackets (<>) as recommended in OPC 10000-3. If the BrowseName is not defined by this document, a namespace index prefix is added to the BrowseName (e.g., prefix '0' leading to ‘0:EngineeringUnits’ or prefix '2' leading to ‘2:DeviceRevision’). This is typically necessary if a Property of another specification is overwritten or used in the OPC UA types defined in this document. Clause 12.2 provides a list of namespaces and their indexes as used in this document.

3.3.3 Common Attributes

3.3.3.1 General

The Attributes of Nodes, their DataTypes and descriptions are defined in OPC 10000-3. Attributes not marked as optional are mandatory and shall be provided by a Server. The following tables define if the Attribute value is defined by this document or if it is server-specific.

For all Nodes specified in this document, the Attributes named in Table 7 shall be set as specified in the table.

3.3.3.2 Objects

For all Objects specified in this document, the Attributes named in Table 8 shall be set as specified in the Table 8. The definitions for the Attributes can be found in OPC 10000-3.

3.3.3.3 Variables

For all Variables specified in this document, the Attributes named in Table 9 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.3.3.4 VariableTypes

For all VariableTypes specified in this document, the Attributes named in Table 10 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.3.3.5 Methods

For all Methods specified in this document, the Attributes named in Table 11 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

4 Device model

4.1 General

Figure 1 depicts the main ObjectTypes of the base device model and their relationship. The drawing is not intended to be complete. For the sake of simplicity only a few components and relations were captured to give a rough idea of the overall structure.

The boxes in this drawing show the ObjectTypes used in this specification as well as some elements from other specifications that help understand some modelling decisions. The upper grey box shows the OPC UA core ObjectTypes from which the TopologyElementType is derived. The grey box in the second level shows the main ObjectTypes that the device model introduces. The components of those ObjectTypes are illustrated only in an abstract way in this overall picture.

The grey box in the third level shows real-world examples as they will be used in products and plants. In general, such subtypes are defined by other organizations.

The TopologyElementType is the base ObjectType for elements in a device topology. Its most essential aspect is the functional grouping concept.

The ComponentType ObjectType provides a generic definition for a Device or parts of a Device where parts include mechanics and/or software. DeviceType is commonly used to represent field Devices.

Modular Devices are introduced to support subdevices and Block Devices to support Blocks. Blocks are typically used by field communication foundations as means to organize the functionality within a Device. Specific types of Blocks will therefore be specified by these foundations.

The ConfigurableObjectType is used as a general means to create modular topology units. If required an instance of this type will be added to the head object of the modular unit. Modular Devices, for example, will use this ObjectType to organize their modules. Block-oriented Devices use it to expose and organize their Blocks.

4.2 Usage guidelines

Annex C describes guidelines for the usage of the device model as base for creating companion specifications as well as guidelines on how to combine different aspects of the same device – defined in different companion specifications – in one OPC UA application.

4.3 TopologyElementType

This ObjectType defines a generic model for elements in a device or component topology. Among others, it introduces FunctionalGroups, ParameterSet, and MethodSet. Figure 2 shows the TopologyElementType. It is formally defined in Table 12.

The TopologyElementType is abstract. There will be no instances of a TopologyElementType itself, but there will be instances of subtypes of this type. In this specification, the term TopologyElement generically refers to an instance of any ObjectType derived from the TopologyElementType.

FunctionalGroups are an essential aspect introduced by the TopologyElementType. FunctionalGroups are used to structure Nodes like Properties, Parameters and Methods according to their application such as configuration, diagnostics, asset management, condition monitoring and others.

FunctionalGroups are specified in 4.4.

A FunctionalGroup called Identification can be used to organize identification information of this TopologyElement (see 4.4.2). Identification information typically includes the Properties defined by the VendorNameplate or TagNameplate Interfaces and additional application specific information.

TopologyElements can also support LockingServices (defined in 7).

Clients shall use the LockingServices if they require to make a set of changes (for example, several Write operations and Method invocations) and where a consistent state is available only after all of these changes have been performed. The main purpose of locking a TopologyElement is avoiding concurrent modifications.

The lock applies to the complete TopologyElement (including all components such as Blocks or modules). Servers can expose a Lock Object on a component TopologyElement to allow independent locking of components, if no lock is applied to the top-level TopologyElement.

If the Online/Offline model is supported (see 6.3), the lock always applies to both the online and the offline version.

ParameterSet and MethodSet are defined as standard containers for systems that have a flat list of Parameters or Methods with unique names. In such cases, the Parameters are components of the “ParameterSet” as a flat list of Parameters. The Methods are kept the same way in the “MethodSet”.

The MethodSet is only available if it includes at least one Method.

The components of the TopologyElementType have additional references as defined in Table 13.

4.4 FunctionalGroupType

4.4.1 Model

This subtype of the OPC UA FolderType is used to structure Nodes like Properties, Parameters and Methods according to their application (e.g. maintenance, diagnostics, condition monitoring). Organizes References should be used when the elements are components in other parts of the TopologyElement that the FunctionalGroup belongs to. This includes Properties, Variables, and Methods of the TopologyElement or in Objects that are components of the TopologyElement either directly or via a subcomponent. The same Property, Parameter or Method can be useful in different application scenarios and therefore referenced from more than one FunctionalGroup.

FunctionalGroups can be nested.

FunctionalGroups can directly be instantiated. In this case, the BrowseName of a FunctionalGroup should indicate its purpose. A list of well-known BrowseNames is in 4.4.2.

Figure 3 shows the FunctionalGroupType components. It is formally defined in Table 14.

All BrowseNames for Nodes referenced by a FunctionalGroup with an Organizes Reference shall be unique.

The Organizes References can be present only at the instance, not the type. Depending on the current state of the TopologyElement the Server can decide to hide or unhide certain FunctionalGroups or (part of) their References. If a FunctionalGroup can be hidden on an instance the TypeDefinition shall use an appropriate ModellingRule like “Optional”.

If desirable, Nodes can be also children of FunctionalGroups. If such Nodes are defined, it is recommended to define a subtype of the FunctionalGroupType.

UIElement is the user interface element for this FunctionalGroup. See 4.4.3 for the definition of UIElements.

Examples in Annex B.1 illustrate the use of FunctionalGroups.

4.4.2 Well-Known FunctionalGroup BrowseNames

Table 15 includes a list of FunctionalGroups with name and purpose. If Servers expose a FunctionalGroup that corresponds to the described purpose, they should use the well-known BrowseName with the Namespace of this specification.

4.4.3 UIElement Type

Servers can expose UIElements providing user interfaces in the context of their FunctionalGroup container. Clients can load such a user interface and display it on the Client side. The hierarchy of FunctionalGroups represents the tree of user interface elements.

The UIElementType is abstract and is mainly used as filter when browsing a FunctionalGroup. Only subtypes can be used for instances. No concrete UIElements are defined in this specification. FDI (Field Device Integration, see IEC 62769) specifies two concrete subtypes

• UIDs (UI Descriptions), descriptive user interface elements, and

• UIPs (UI Plug-Ins), programmed user interface elements.

The UIElementType is specified in Table 16.

The Value attribute of the UIElement contains the user interface element. Subtypes have to define the DataType (e.g., XmlElement or ByteString).

4.5 Interfaces

4.5.1 Overview

This clause describes Interfaces with specific functionality that can be applied to multiple types at arbitrary positions in the type hierarchy.

Interfaces are defined in OPC 10000-3.

Figure 4 shows the Interfaces described in this specification.

4.5.2 VendorNameplate Interface

IVendorNameplateType includes Properties that are commonly used to describe a TopologyElement from a manufacturer point of view. They can be used as part of the identification. The Values of these Properties are typically provided by the component vendor.

The VendorNameplate Interface is illustrated in Figure 5 and formally defined in Table 17.

Product type specific Properties:

Manufacturer provides the name of the company that manufactured the item this Interface is applied to. ManufacturerUri provides a unique identifier for this company. This identifier should be a fully qualified domain name; however, it can be a GUID or similar construct that ensures global uniqueness.

Model provides the name of the product.

ProductCode provides a unique combination of numbers and letters used to identify the product. It can be the order information displayed on type shields or in ERP systems.

HardwareRevision provides the revision level of the hardware. SemanticVersionString (a sub-type of String defined in OPC 10000-5) can be used when using the Semantic Versioning format.

SoftwareRevision provides the version or revision level of the software component, the software/firmware of a hardware component, or the software/firmware of the Device. SemanticVersionString (a sub-type of String defined in OPC 10000-5) can be used when using the Semantic Versioning format.

DeviceRevision provides the overall revision level of a hardware component or the Device. As an example, this Property can be used in ERP systems together with the ProductCode Property. SemanticVersionString (a sub-type of String defined in OPC 10000-5) can be used when using the Semantic Versioning format.

DeviceManual allows specifying an address of the user manual. It can be a pathname in the file system or a URL (Web address).

DeviceClass indicates in which domain or for what purpose a certain item for which the Interface is applied is used. Examples are “ProgrammableController”, “RemoteIO”, and “TemperatureSensor”. This standard does not predefine any DeviceClass names. Companion standards that utilize this Interface (device models) will likely introduce such classifications.

Product instance specific Properties:

SerialNumber is a unique production number provided by the manufacturer. This is often stamped on the outside of a physical component and can be used for traceability and warranty purposes.

ProductInstanceUri is a globally unique resource identifier provided by the manufacturer. This is often stamped on the outside of a physical component and can be used for traceability and warranty purposes. The maximum length is 255 characters. If used as QR code, 80 characters is a reasonable size. The recommended syntax of the ProductInstanceUri is: <ManufacturerUri>/<any string> where <any string> is unique among all instances using the same ManufacturerUri.

Examples: “some-company.com/5ff40f78-9210-494f-8206-c2c082f0609c”, “some-company.com/snr-16273849” or “some-company.com/model-xyz/snr-16273849”.

RevisionCounter is an incremental counter indicating the number of times the configuration data has been modified. An example would be a temperature sensor where the change of the unit would increment the RevisionCounter but a change of the measurement value would not affect the RevisionCounter.

SoftwareReleaseDate defines the date when the software is released. If the version information is about patches, this should be the date of the latest patch. It is additional information for the user.

PatchIdentifiers identify the list of patches that are applied to a software version. The format and semantics of the strings are vendor-specific. The order of the strings shall not be relevant.

Companion specifications can specify additional semantics for the contents of these Properties.

Table 18 specifies the mapping of these Properties to the International Registration Data Identifiers (IRDI) defined in ISO/IEC 11179-6. They should be used if a Server wants to expose a dictionary reference as defined in OPC 10000-19.

4.5.3 TagNameplate Interface

ITagNameplateType includes Properties that are commonly used to describe a TopologyElement from a user point of view.

The TagNameplate Interface is illustrated in Figure 6 and formally defined in Table 19.

AssetId is a user writable alphanumeric character sequence uniquely identifying a component. The ID is provided by the integrator or user of the device. It contains typically an identifier in a branch, use case or user specific naming scheme. This could be for example a reference to an electric scheme.

ComponentName is a user writable name provided by the integrator or user of the component.

Table 20 specifies the mapping of these Properties to the International Registration Data Identifiers (IRDI) defined in ISO/IEC 11179-6. They should be used if a Server wants to expose a dictionary reference as defined in OPC 10000-19.

4.5.4 DeviceHealth Interface

The DeviceHealth Interface includes Properties and Alarms that are commonly used to expose the health status of a Device. It is illustrated in Figure 7 and formally defined in Table 21.

DeviceHealth indicates the status as defined by NAMUR Recommendation NE107. Clients can read or monitor this Variable to determine the device condition.

The DeviceHealthEnumeration DataType is an enumeration that defines the device condition. Its values are defined in Table 22. Its representation in the AddressSpace is defined in Table 23.

DeviceHealthAlarms shall be used for instances of the DeviceHealth Alarm Types specified in 4.12 and any other subtypes of DeviceHealthDiagnosticAlarmType.

It is recommended to use the DeviceHealthAlarms folder also for Alarm instances that relate to the health condition of the Device and are not subtypes of DeviceHealthDiagnosticAlarmType

4.5.5 OperationCounter Interface

The IOperationCounterType defines counters for the duration of operation. It is formally defined in Table 24.

PowerOnDuration is the duration the Device has been powered. The main purpose is to determine the time in which degradation of the Device occurred. The details, when the time is counted, is implementation-specific. Companion specifications can define specific rules. Typically, when the Device has supply voltage and the main CPU is running, the time is counted. This can include any kind of sleep mode, but cannot include pure Wake on LAN. This value shall only increase during the lifetime of the Device and shall not be reset when the Device is restarted. The PowerOnDuration is provided as Duration, i.e., in milliseconds or even fractions of a millisecond. However, the Server is not expected to update the value in such a high frequency, but possibly once a minute or once an hour, depending on the application.

OperationDuration is the duration the Device has been powered and performing an activity. This counter is intended for Devices where a distinction is made between switched on and in operation. For example, a drive can be powered on but not operating. It is not intended for Devices always performing an activity like sensors always measuring data. This value shall only increase during the lifetime of the Device and shall not be reset when the Device is restarted. The OperationDuration is provided as Duration, i.e., in milliseconds or even fractions of a millisecond. However, the Server is not expected to update the value in such a high frequency, but possibly once a minute or once an hour, depending on the application.

OperationCycleCounter is counting the times the Device switches from not performing an activity to performing an activity. For example, each time a valve starts moving, is counted. This value shall only increase during the lifetime of the Device and shall not be reset when the Device is restarted.

The child Nodes of the IOperationCounterType have additional Attribute values defined in Table 25.

Table 26 – OperationCounter Mapping to IRDIs specifies the mapping of these Properties to the International Registration Data Identifiers (IRDI) defined in ISO/IEC 11179-6. They should be used if a Server wants to expose a dictionary reference as defined in OPC 10000-19.

4.5.6 SupportInfo Interface

The SupportInfo Interface defines a number of additional data that a commonly exposed for Devices and their components. These include mainly images, documents, or protocol-specific data. The various types of information are organized into different folders. Each information element is represented by a read-only Variable. The information can be retrieved by reading the Variable value.

Figure 8 Illustrates the SupportInfo Interface. It is formally defined in Table 27.

Clients should be aware that the contents that these Variables represent can be large. Reading large values with a single Read operation can be impossible due to configured limits in either the Client or the Server stack. The default maximum size for an array of bytes is 1 MiB. It is recommended that Clients use the IndexRange in the OPC UA Read Service (see OPC 10000-4) to read these Variables in chunks, for example, one-megabyte chunks. It is up to the Client whether it starts without an index and repeats with an IndexRange only after an error or whether it always uses an IndexRange.

The components of the ISupportInfoType have additional references as defined in Table 28.

Pictures can be exposed as Variables organized in the DeviceTypeImage folder. There can be multiple images of different resolutions. Each image is a separate Variable.

All images are transferred as a ByteString. The DataType of the Variable specifies the image format. OPC UA defines BMP, GIF, JPG and PNG (see OPC 10000-3).

Documents in many cases will represent a product manual. They can be exposed as Variables or as FileType instances. Files are useful in particular for large documents.

Documents as Variables are represented as a ByteString and organized in the Documentation folder. The BrowseName of each Node will consist of the filename including the extension that can be used to identify the document type. Typical extensions are “.pdf” or “.txt”.

Documents as FileType instances are organized in the DocumentationFiles folder. They are retrieved from the Server by using the FileType Methods. It is recommended to use the MimeType Property to specify the media type of the file based on RFC 2046.

Protocol support files are exposed as Variables organized in the ProtocolSupport folder. They can represent various types of information as defined by a protocol. For example a GSD file.

All protocol support files are transferred as a ByteString. The BrowseName of each Variable shall consist of the complete filename including the extension that can be used to identify the type of information.

Images that are used within UIElements are exposed as separate Variables rather than embedding them in the element. All image Variables will be aggregated by the ImageSet folder. The UIElement shall specify an image by its name that is also the BrowseName of the image Variable. Clients can cache images so they don't have to be transferred more than once.

The DataType of the Variable specifies the image format. OPC UA defines BMP, GIF, JPG and PNG (see OPC 10000-3).

4.5.7 AssetLocationIndication Interface

The asset location indication Interface provides a method for making a device emit visual signals (e.g., blinking LEDs) or audible signals (e.g., sounds) to facilitate its physical identification among other assets.

IAssetLocationIndicationType can be implemented by any object that represents a physical device and that is able to indicate its position by blinking and / or making a sound.

The minimal implementation supports turning a default indication on and off for a specified duration. Optionally a device can declare its supported indication types (audible, visual) and let the client select the used indication types (one or more).

The Interface is formally defined in Table 29.

The read only Property IsIndicating is true when the indication is currently active.

The optional UsedIndicationType can be written to set the indication types that shall be used when StartLocationIndication is called.

4.5.7.1 StartLocationIndication Method

The StartLocationIndication Method is used to start the indication. As a result to this call the IsIndicating property is set to true.

The signature of this Method is specified below. Table 30 and Table 31 specify the Arguments and AddressSpace representation, respectively.

Signature

	StartLocationIndication(
	  [in] 0:Duration			  IndicationDuration);

Method Result Codes (defined in Call Service)

4.5.7.2 StopLocationIndication Method

The StopLocationIndication Method is used to stop the indication. As a result to this call, the IsIndicating property is set to false. This method also can be called when the indication is already stopped (e.g., because the specified IndicationDuration is over).

The signature of this Method is specified below.

Signature

	StopLocationIndication();

4.5.8 LocationIndicationType OptionSet

This DataType is used together with the IAssetLocationIndication Interface. It defines flags for the type of location indication. The OptionSet is defined in Table 32. Its representation in the AddressSpace is defined in Table 33.

4.6 ComponentType

Compared to DeviceType the ComponentType is more universal. It includes the same components but does not mandate any Properties. This makes it usable for representation of a Device or parts of a Device. Parts include both mechanical and software parts.

The ComponentType applies the VendorNameplate and the TagNameplate Interface. Figure 9 Illustrates the ComponentType. It is formally defined in Table 34.

The ComponentType is abstract. DeviceType and SoftwareType are subtypes of ComponentType. There will be no instances of a ComponentType itself, only of concrete subtypes.

IVendorNameplateType and its members are described in 4.5.2.

ITagNameplateType and its members are described in 4.5.3.

4.7 DeviceType

This ObjectType can be used to define the structure of a Device. Figure 10 shows the DeviceType. It is formally defined in Table 35.

DeviceType is a subtype of ComponentType which means it inherits all InstanceDeclarations.

The DeviceType ObjectType is abstract. There will be no instances of a DeviceType itself, only of concrete subtypes.

ConnectionPoints (see 5.4) represent the interface (interface card) of a DeviceType instance to a Network. Multiple ConnectionPoints can exist if multiple protocols and/or multiple Communication Profiles are supported.

The Interfaces and their members are described in 4.5. Some of the Properties inherited from the ComponentType are declared mandatory for backward compatibility.

Although mandatory, some of the Properties are not supported for certain types of Devices. In this case vendors shall provide the following defaults:

Clients can ignore the Properties when they have these defaults.

When Properties are not supported, Servers should initialize the corresponding Property declaration on the DeviceType with the default value. Relevant Browse Service requests can then return a Reference to this Property on the type definition. That way, no extra Nodes are required.

4.8 SoftwareType

This ObjectType can be used for software modules of a Device or a part of a Device. SoftwareType is a concrete subtype of ComponentType and can be used directly.

Figure 11 Illustrates the SoftwareType. It is formally defined in Table 36.

SoftwareType is a subtype of ComponentType which means it inherits all InstanceDeclarations.

The Properties Manufacturer, Model, and SoftwareRevision inherited from ComponentType are declared mandatory for SoftwareType instances.

4.9 DeviceSet entry point

The DeviceSet Object is the starting point to locate Devices. It shall either directly or indirectly reference all instances of a subtype of ComponentType with a Hierarchical Reference. For complex Devices that are composed of various components that are also Devices, only the root instance shall be referenced from the DeviceSet Object. The components of such complex Devices shall be locatable by following Hierarchical References from the root instance. An example is the Modular Device defined in 9.4 and also illustrated in Figure 12.

Examples:

UA Server represents a monolithic or modular Device: DeviceSet only contains one instance

UA Server represents a host system that has access to a number of Devices that it manages: DeviceSet contains several instances that the host provides access to.

UA Server represents a gateway Device that acts as representative for Devices that it has access to: DeviceSet contains the gateway Device instance and instances for the Devices that it represents.

UA Server represents a robotic system consisting of mechanics and controls. DeviceSet only contains the instance for the root of the robotic system. The mechanics and controls are represented by ComponentType instances which are organized as sub-components of the root instance.

Figure 12 shows the AddressSpace organisation with this standard entry point and examples.

The DeviceSet Node is formally defined in Table 37.

4.10 DeviceFeatures entry point

The DeviceFeatures Object can be used to organize other functional entities that are related to the Devices referenced by the DeviceSet. Companion specifications can standardize such instances and their BrowseNames. Figure 13 shows the AddressSpace organisation with this standard entry point.

The DeviceFeatures Node is formally defined in Table 38.

4.11 BlockType

This ObjectType defines the structure of a Block Object. Figure 14 depicts the BlockType hierarchy. It is formally defined in Table 39.

FFBlockType and PROFIBlockType are examples. They are not further defined in this specification. It is expected that industry groups will standardize general purpose BlockTypes.

BlockType is a subtype of TopologyElementType and inherits the elements for Parameters, Methods and FunctionalGroups.

The BlockType is abstract. There will be no instances of a BlockType itself, but there will be instances of subtypes of this Type. In this specification, the term Block generically refers to an instance of any subtype of the BlockType.

The RevisionCounter is an incremental counter indicating the number of times the static data within the Block has been modified. A value of -1 indicates that no revision information is available.

The following Properties refer to the BlockMode (e.g., “Manual”, “Out of Service”).

The ActualMode Property reflects the current mode of operation.

The PermittedMode defines the modes of operation that are allowed for the Block based on application requirements.

The NormalMode is the mode the Block should be set to during normal operating conditions. Depending on the Block configuration, multiple modes can exist.

The TargetMode indicates the mode of operation that is desired for the Block. Depending on the Block configuration, multiple modes can exist.

4.12 DeviceHealth Alarm Types

4.12.1 General

The DeviceHealth Property defined in 4.5.4 provides a basic way to expose the health state of a device based on NAMUR NE 107.

This section defines AlarmTypes that can be used to indicate an abnormal device condition together with diagnostic information text as defined by NAMUR NE 107 as well as additional manufacturer specific information.

Figure 15 informally describes the AlarmTypes for DeviceHealth.

4.12.2 DeviceHealthDiagnosticAlarmType

The DeviceHealthDiagnosticAlarmType is a specialization of the InstrumentDiagnosticAlarmType intended to represent abnormal device conditions as defined by NAMUR NE 107. This type can be used in filters for monitored items. Only subtypes of this type will be used in actual implementations. The Alarm becomes active when the device condition is abnormal. It is formally defined in Table 40.

Conditions of subtypes of DeviceHealthDiagnosticAlarmType become active when the device enters the corresponding abnormal state.

The Message field in the Event notification shall be used for additional information associated with the health status (e.g. the possible cause of the abnormal state and suggested actions to return to normal).

A Device can be in more than one abnormal state at a time in which case multiple Conditions will be active.

4.12.3 FailureAlarmType

The FailureAlarmType is formally defined in Table 41. For description of the FAILURE state see Table 22.

4.12.4 CheckFunctionAlarmType

The CheckFunctionAlarmType is formally defined in Table 42. For description of the CHECK_FUNCTION state see Table 22.

4.12.5 OffSpecAlarmType

The OffSpecAlarmType is formally defined in Table 43. For description of the OFF_SPEC state see Table 22.

4.12.6 MaintenanceRequiredAlarmType

The MaintenanceRequiredAlarmType is formally defined in Table 44. For description of the MAINTENANCE_REQUIRED state see Table 22.

5 Device communication model

5.1 General

Clause 5 introduces References, the ProtocolType, and basic TopologyElementTypes for creating a communication topology. The types for this model are illustrated in Figure 16.

A ProtocolType ObjectType represents a specific communication protocol (e.g., FieldBus) implemented by a certain TopologyElement. Examples are shown in Figure 18.

The ConnectionPointType represents the logical interface of a Device to a Network.

A Network is the logical representation of wired and wireless technologies.

Figure 17 provides an overall example.

5.2 ProtocolType

The ProtocolType ObjectType and its subtypes are used to specify a specific communication (e.g., FieldBus) protocol that is supported by a Device (respectively by its ConnectionPoint) or Network. The BrowseName of each instance of a ProtocolType shall define the Communication Profile (see Figure 18).

Figure 18 shows the ProtocolType including some specific types and instances that represent Communication Profiles of that type. It is formally defined in Table 45.

5.3 Network

A Network is the logical representation of wired and wireless technologies and represents the communication means for Devices that are connected to it. A Network instance is qualified by its Communication Profile components.

Figure 19 shows the type hierarchy and the NetworkType components. It is formally defined in Table 46.

The <ProfileIdentifier> specifies the Protocol and Communication Profile that this Network is used for.

Clients shall use the LockingServices if they possibly make a set of changes (for example, several Write operations and Method invocations) and where a consistent state is available only after all of these changes have been performed. The main purpose of locking a Network is avoiding concurrent topology changes.

The lock on a Network applies to the Network, all connected TopologyElements and their components. If any of the connected TopologyElements provides access to a sub-ordinate Network (like a gateway), the sub-ordinate Network and its connected TopologyElements are locked as well.

If InitLock is requested for a Network, it will be rejected if any of the Devices connected to this Network or any sub-ordinate Network including their connected Devices is already locked.

If the Online/Offline model is supported (see 6.3), the lock always applies to both the online and the offline version.

5.4 ConnectionPoint

This ObjectType represents the logical interface of a Device to a Network. A specific subtype shall be defined for each protocol. Figure 20 shows the ConnectionPointType including some specific types.

A Device can have more than one such interface to the same or to different Networks. Different interfaces usually exist for different protocols. Figure 21 shows the ConnectionPointType components. It is formally defined in Table 47.

ConnectionPoints are components of a Device, represented by a subtype of ComponentType. To allow navigation from a Network to the connected Devices, the ConnectionPoints shall have the inverse Reference (ComponentOf) to the Device.

ConnectionPoints have Properties and other components that they inherit from the TopologyElementType.

The NetworkAddress FunctionalGroup includes all Parameters to specify the protocol-specific address information of the connected Device. These Parameters can be components of the NetworkAddress FunctionalGroup, of the ParameterSet, or another Object.

<ProfileIdentifier> identifies the Communication Profile that this ConnectionPoint supports. ProtocolType and Communication Profile are defined in 5.2. It implies that this ConnectionPoint can be used to connect Networks and Devices of the same Communication Profile.

ConnectionPoints are between a Network and a Device. The location in the topology is configured by means of the ConnectsTo ReferenceType. Figure 22 illustrates some usage models.

5.5 ConnectsTo and ConnectsToParent ReferenceTypes

The ConnectsTo ReferenceType is a concrete ReferenceType used to indicate that source and target Node have a topological connection. It is NonHierarchical and symmetric, because this is natural for this Reference. The ConnectsTo Reference exists between a Network and the connected Devices (or their ConnectionPoint, respectively). Browsing a Network returns the connected Devices; browsing from a Device, one can follow the ConnectsTo Reference from the Device’s ConnectionPoint to the Network.

The ConnectsToParent ReferenceType is a concrete ReferenceType used to define the parent (i.e. the communication Device) of a Network. It is a subtype of the ConnectsTo ReferenceType.

The two ReferenceTypes are illustrated in Figure 23.

The representation in the AddressSpace is specified in Table 48 and Table 49.

Figure 24 illustrates how this Reference can be used to express topological relationships and parental relationships. In this example two Devices are connected; the module DPcomm is the communication Device for the Network.

5.6 NetworkSet Object

All Networks shall be components of the NetworkSet Object.

The NetworkSet Node is formally defined in Table 50.

6 Device integration host model

6.1 General

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 can 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 can 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).

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.

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.

6.2 DeviceTopology Object

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

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.

6.3 Online/Offline

6.3.1 General

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

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) can 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 shall 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.

6.3.2 IsOnline ReferenceType

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

6.4 Offline-Online data transfer

6.4.1 Definition

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

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 can involve thousands of Parameters so that it can take a long time (up to minutes), and with a result that can 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).

6.4.2 TransferServices Type

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

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.

6.4.3 TransferServices Object

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

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 can share the same Methods.

6.4.4 TransferToDevice Method

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 54 and Table 55 specify the arguments and AddressSpace representation, respectively.

Signature

	TransferToDevice(
	
	  [out] 0:Int32                TransferID,
	  [out] 0:Int32                InitTransferStatus);

6.4.5 TransferFromDevice Method

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 56 and Table 57 specify the arguments and AddressSpace representation, respectively.

Signature

	TransferFromDevice(
	
	  [out] 0:Int32                TransferID,
	  [out] 0:Int32                InitTransferStatus);

6.4.6 FetchTransferResultData Method

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 can 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 can 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 58 and Table 59 specify the arguments and AddressSpace representation, respectively.

Signature

	FetchTransferResultData(
	  [in]  0:Int32                 TransferID,
	  [in]  0:Int32                 SequenceNumber,
	  [in]  0:Int32                 MaxParameterResultsToReturn,
	  [in]  Boolean               OmitGoodResults,
	  [out] FetchResultType       FetchResultData);

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

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

Its representation in the AddressSpace is defined in Table 62.

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

Its representation in the AddressSpace is defined in Table 64.

7 Locking model

7.1 Overview

The following Locking feature is based on the AddIn model specified in OPC 10000-3.

Locking is the means to avoid concurrent modifications to an Object by restricting access to the entity (often a Client but could also be an internal process) that initiated the lock. LockingServices are typically used to make a set of changes (for example, several Write operations and Method invocations) and where a consistent state is available only after all of these changes have been performed.

The context of the lock is specific to the ObjectType where it is applied to (subsequently named "lock-owner"). These specifics are to be described as part of this lock-owner ObjectType. See for example the section on lock in the TopologyElement (clause 4.3) and the Network (clause 5.3).

By default, a lock allows other Applications to view (navigate/read) the locked element. However, Servers can choose to implement an exclusive locking where other Applications have no access at all (e.g. in cases where even read operations require certain settings to Variables).

7.2 LockingServices Type