3.2 Ab reviations ADI Analy er Device Integration CP Commu ication Proces or hardware mod le CPU Central Proces in Unit of a De ic DI Device Integration he s ort name f or this stan ar
Terms and definitions
For the purposes of this document, the terms and definitions given in IEC TR 62541 -1 , IEC 62541 -3, and IEC 62541 -8 as well as the following apply
3.1 1 block functional Parameter grouping entity
Note 1 to entry: It could map to a function block (see IEC 62769 (all parts), Field Device Integration (FDI)
) or to the resource parameters of the device itself
3.1 2 blockMode mode of operation (target mode, permitted modes, actual mode, and normal mode) for a Block
Note 1 to entry: Further details about Block modes are defined by standard organisations
Communication Profile fixed set of mapping rules to allow unambiguous interoperability between Devices or Applications, respectively
Note 1 to entry: Examples of such profiles are the “Wireless communication network and communication profiles for WirelessHART” in IEC 62591 and the Protocol Mappings for OPC UA in IEC 62541 -6
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
Note 1 to entry: See IEC 61 499-1
Note 2 to entry: Devices provide sensing, actuating, communication, and/or control functionality Examples include transmitters, valve controllers, drives, motor controllers, PLCs, and communication gateways
Server that manages integration of multiple Devices in an automation system
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
Note 1 to entry: See IEC 61 784
Note 2 to entry: Designates the communication bus used by a Device
3.1 9 parameter variable of the Device that can be used for configuration, monitoring or control purposes
Note 1 to entry: In the information model it is synonymous to an OPC UA DataVariable
3.1 1 0 network means used to communicate with one specific protocol
Abbreviations 1 0
CP Communication Processor (hardware module)
CPU Central Processing Unit (of a Device)
DI Device Integration (the short name for this standard)
XML Extensible Mark-up Language
Used data types 1 0
Table 1 describes the DataTypes that are used throughout this document
Table 1 – DataTypes defined in IEC 62541 -3
Parameter Type Argument Boolean Duration LocalizedText String Int32
OPC UA 1 0
OPC standards primarily facilitate online data exchange between devices and HMI or SCADA systems through Data Access functionality In this context, an OPC Server supplies device data, which is then utilized by an OPC Client integrated within the HMI or SCADA system OPC DA enables users to navigate hierarchical namespaces containing data items, as well as to read, write, and monitor these items for any data changes However, classic OPC standards rely on Microsoft COM/DCOM technology, limiting their use to Windows PC-based automation systems.
OPC UA combines the essential features of traditional OPC standards such as OPC DA, A&E, and HDA, while establishing platform-independent communication methods It also offers generic, extensible, and object-oriented modeling capabilities for the information that a system aims to present.
The OPC UA network communication framework offers various mechanisms tailored for specific use cases The latest version introduces an optimized binary protocol designed for high-performance intranet communication and Web Services, with the flexibility to incorporate new protocols in the future Key features such as security, access control, and reliability are inherently integrated into the transport mechanisms, ensuring robust performance across diverse platforms.
UA Servers and Clients can be directly integrated into devices and controllers
The OPC UA Information Model standardizes how Servers present Objects to Clients, where Objects consist of other Objects, Variables, and Methods Additionally, OPC UA facilitates the expression of relationships between these Objects.
The AddressSpace of an OPC UA Server encompasses the collection of Objects and associated information accessible to Clients Within this framework, the components of the OPC UA Object Model are depicted as Nodes, each characterized by specific Attributes.
IEC 62541-1:2015 outlines the structure of AddressSpace components in OPC UA, which includes eight Node classes: Object, Variable, Method, ObjectType, VariableType, DataType, ReferenceType, and View Each Node class is characterized by a specific set of attributes, facilitating interconnected references within the system.
This standard makes use of almost all OPC UA NodeClasses
Objects represent real-world entities like devices and communication networks, as well as software entities such as blocks Each object is linked to a specific ObjectType, which defines its characteristics and functionalities.
Variables are used to represent values Two categories of Variables are defined, Properties and DataVariables
Properties are characteristics defined by the server for Objects, DataVariables, and other Nodes They cannot have their own Properties For instance, examples of Properties for Objects include the device serial number and the block tag.
DataVariables encapsulate the contents of an Object and can include component DataVariables This functionality is commonly utilized by Servers to reveal individual elements within arrays and structures The standard employs DataVariables to represent the Parameters associated with both Blocks and Devices.
Conventions used in this document 1 1
Conventions for Node descriptions 1 1
Node definitions are specified using tables (see Table 2)
Attribute name Attribute value If it is an optional Attribute that is not set “ “ will be used
References NodeClass BrowseName DataType TypeDefinition ModellingRule
ReferenceType name NodeClass of the TargetNode
BrowseName of the target Node If the Reference is to be instantiated by the server, then the value of the target Node’s BrowseName is “ “
Attributes of the referenced Node, only applicable for Variables and Objects Referenced
ModellingRule of the referenced Object
NOTE Notes referencing footnotes of the table content
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 designated solely for Variables, where “[]” denotes a single-dimensional array, and for multi-dimensional arrays, the notation is repeated for each dimension (e.g., [2][3] for a two-dimensional array) For all arrays, the ArrayDimensions can be set to null or omitted If the value can be Any or ScalarOrOneDimension, it is represented as “{}”, resulting in either “{Any}” or “{ScalarOrOneDimension}”.
“{ScalarOrOneDimension}” The ValueRank is set to the corresponding value (see IEC 62541 -3) and the ArrayDimensions is set to null or is omitted In Table 3 examples are given
Int32 Int32 -1 omitted or NULL A scalar Int32
The article discusses various types of Int32 arrays in programming A single-dimensional Int32 array can be represented as Int32[] with an unspecified size, denoted as {0} For a two-dimensional Int32 array, it is represented as Int32[][], also with unknown sizes for both dimensions, indicated as {0,0} Additionally, an Int32 array with a fixed size of 3 for the first dimension and an unknown size for the second dimension is represented as Int32[3][].
Int32[5][3] Int32 2 {5,3} Two-dimensional array of Int32 with a size of 5 for the first dimension and a size of 3 for the second dimension
The Int32{Any} type represents an Int32 value that may be either omitted or NULL, indicating uncertainty about whether it is a scalar or an array with any number of dimensions In contrast, the Int32{ScalarOrOneDimension} type specifically denotes an Int32 that is either a scalar or a single-dimensional array, which can also be omitted or NULL.
• The TypeDefinition is specified for Objects and Variables
• The TypeDefinition column specifies a NodeId of a TypeDefinitionNode, i.e the specified Node points with a HasTypeDefinition Reference to the corresponding TypeDefinitionNode The symbolic name of the NodeId is used in the table
The ModellingRule for the referenced component is indicated by its symbolic name in the ModellingRule column In the AddressSpace, the Node utilizes a HasModellingRule Reference to link to the appropriate ModellingRule Object.
If the NodeId of a DataType is provided, the symbolic name of the Node representing the DataType shall be used
If no components are provided, the DataType, TypeDefinition and ModellingRule columns may be omitted and only a Comment column is introduced to point to the Node definition
Nodes can have complex components that may include other components The TypeDefinition, NodeClass, DataType, and ModellingRule can be derived from type definitions, with symbolic names created as outlined in section 4.2.2.1 Consequently, these containing components are not explicitly stated but are instead implicitly defined by the type definitions.
NodeIds and BrowseNames 1 2
The NodeIds of all Nodes described in this document are only symbolic names Annex A defines the actual NodeIds
Each Node's symbolic name in this document is referred to as its BrowseName If a Node is part of another Node, its symbolic name is formed by combining the BrowseName of the parent Node, a period, and its own BrowseName.
In this context, "part of" indicates that the entire entity possesses a HasProperty or HasComponent reference to its component Additionally, all Nodes that are not associated with another Node have a distinct name within this document, ensuring the symbolic name remains unique.
The standard's namespace is outlined in Annex A, with the NamespaceIndex for all NodeIds and BrowseNames being specific to each server This index is determined by the location of the namespace URI within the server's namespace table.
The BrowseNames for all Nodes outlined in this standard are detailed in the corresponding tables The NamespaceIndex for these BrowseNames is specific to each server and is determined by the position of the namespace URI within the server's namespace table.
General 1 3
Figure 1 illustrates the primary ObjectTypes within the base Device model and their interconnections This diagram is not exhaustive; it selectively includes a limited number of components and relationships to provide a general overview of the overall structure.
This drawing illustrates the ObjectTypes defined in this standard, along with elements from other standards that clarify certain modeling choices The upper grey box represents the core OPC UA ObjectTypes, which serve as the foundation for the TopologyElementType and ProtocolType The second-level grey box highlights the primary ObjectTypes introduced by this standard, with their components depicted in an abstract manner within the overall diagram.
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 It
BaseObject Type OPC UA Part 5
FF or PROFIBlock Device
The DeviceType ObjectType defines a general type for any Device, which can include Parameters, Methods, subdevices, and Blocks Blocks serve to organize the functionality of a Device, with specific types determined by various field communication foundations.
A ProtocolType ObjectType represents a specific communication/FieldBus protocol implemented by a certain TopologyElement Examples are FFBusType, HARTBusType, or PROFIBUS/PROFINETType
The ConfigurableObjectType serves as a versatile tool for creating modular topology units Instances of this type can be integrated into the head object of a modular unit when necessary For instance, Modular Devices utilize this ObjectType to effectively organize their Modules, while Block-oriented Devices leverage it to structure and present their Blocks.
TopologyElementType 1 4
The ObjectType outlines the essential information components for configurable elements within a device topology, introducing key elements such as ParameterSet, MethodSet, and FunctionalGroups The TopologyElementType is visually represented in Figure 2 and is formally detailed in Table 4.
Figure 2 – Components of the TopologyElementType
In a topology, elements can possess Parameters and Methods, which are organized into two distinct Objects: "ParameterSet" for Parameters and "MethodSet" for Methods, both maintained as flat lists FunctionalGroups serve to structure these Parameters and Methods in alignment with the TopologyElement's organization, allowing for the same Parameter or Method to be referenced across multiple FunctionalGroups Additionally, each group may include an optional user interface to enhance the represented functionality, as detailed in section 5.3.
• Rule for all Methods organised in FunctionalGroups:
Since Methods are components of the MethodSet Object, Clients have to specify the NodeId of the MethodSet instance in the ObjectId argument of the Call Service
Parameters in OPC UA are represented by DataVariable nodes, which can be instances of BaseDataVariableType as specified in IEC 62541-5, or any sub-type established by OPC UA or other standard organizations Common VariableTypes, including DataItemType, AnalogItemType, and DiscreteItemTypes, are outlined in IEC 62541-8 The term "Parameter" is used generically in this standard, encompassing all VariableTypes.
The TopologyElement ObjectType is formally defined in Table 4
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Subtype of the BaseObjectType defined in IEC 62541 -5
HasSubtype ObjectType DeviceType Defined in 5.3
HasSubtype ObjectType BlockType Defined in 5.1 0
HasComponent Object ParameterSet BaseObjectType Optional
HasComponent Object MethodSet BaseObjectType Optional
HasComponent Object FunctionalGroupType OptionalPlaceHolder
HasComponent Object Identification FunctionalGroupType Optional
HasComponent Object Lock LockingServicesType Optional
The TopologyElementType is an abstract class, meaning it cannot be instantiated directly Instead, instances will be created from its sub-types In this context, the term TopologyElement refers to any ObjectType that is derived from the TopologyElementType.
The ParameterSet collects all references to Parameters available to the Client and is essential when Parameters are present for a TopologyElement The formal definition of the "ParameterSet" Object can be found in Table 5.
References NodeClass BrowseName TypeDefinition ModellingRule
HasComponent Variable BaseDataVariableType MandatoryPlaceholder
MethodSet gathers the references to all Methods that are exposed to the Client The
“MethodSet” Object is formally defined in Table 6
References NodeClass BrowseName TypeDefinition ModellingRule
TopologyElements can contain multiple FunctionalGroups to effectively organize Parameters and Methods Notably, a specific FunctionalGroup named Identification is designated for organizing Parameters related to the identification of the TopologyElement.
In addition to the elements described in 5.2, TopologyElements may also support LockingServices (defined in 8.3.3).
FunctionalGroupType 1 6
The OPC UA FolderType sub-type is designed to organize Parameters and Methods from the complete ParameterSet and MethodSet based on their application, such as maintenance and diagnosis It can reference a Property of the associated TopologyElement and may include a user interface element Notably, the same Property, Parameter, or Method can be referenced by multiple FunctionalGroups.
Figure 3 shows the FunctionalGroupType components It is formally defined in Table 7
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Subtype of the FolderType defined in IEC 62541 -5
HasComponent Object FunctionalGroupType OptionalPlaceHolder Organizes Variable BaseDataType BaseDataVariableType OptionalPlaceHolder
HasComponent Variable UIElement BaseDataType UIElementType Optional
Organizes References are applicable only at the instance level, not at the type level The Server can choose to hide or reveal specific elements based on the current state of the TopologyElement.
FunctionalGroups or (part of) their References If a FunctionalGroup may be hidden on an instance the TypeDefinition shall use an appropriate ModellingRule like “Optional”
The Description Attribute is used to describe the intended purpose of the FunctionalGroup
UIElement is the user interface element for this FunctionalGroup See 5.5 for the definition of UIElements
The examples in Figure 4 and Figure 5 illustrate the use of FunctionalGroups:
Figure 4 – Analyser Device use for FunctionalGroups (UA Companion ADI)
Figure 5 – PLCopen use for FunctionalGroups (UA Companion PLCopen)
Identification FunctionalGroup 1 8
The parameters used to identify a TopologyElement are organized within a FunctionalGroup known as Identification Clients can utilize these parameters to locate specific elements or identify discrepancies between configuration data and the currently connected element An example of the Identification FunctionalGroup is illustrated in Figure 6.
NOTE Standardization bodies are expected to define the I dentification contents for specific bus protocols
Figure 6 – Example of an Identification FunctionalGroup
UIElement Type 1 9
Servers can present UIElements that create user interfaces within their FunctionalGroup container Clients have the ability to load and display these user interfaces on their side The structure of FunctionalGroups forms a hierarchical tree of user interface elements.
The UIElementType serves as an abstract filter for navigating a FunctionalGroup, with only its sub-types applicable for instances This standard does not define any concrete UIElements, but the Field Device Integration (FDI) as outlined in IEC 62769 specifies two concrete sub-types.
• UIDs (UI Descriptions), descriptive user interface elements, and
• UIPs (UI Plug-Ins), programmed user interface elements
The UIElementType is specified in Table 8
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Subtype of BaseVariableType defined in IEC 62541 -5
The Value attribute of the UIElement contains the user interface element Sub-types have to define the DataType (e.g XmlElement or ByteString)
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Inherit the Properties of the TopologyElementType defined in 5.2
HasProperty Variable SerialNumber String PropertyType Mandatory
HasProperty Variable RevisionCounter Int32 PropertyType Mandatory
HasProperty Variable Manufacturer LocalizedText PropertyType Mandatory
HasProperty Variable Model LocalizedText PropertyType Mandatory
HasProperty Variable DeviceManual String PropertyType Mandatory
HasProperty Variable DeviceRevision String PropertyType Mandatory
HasProperty Variable SoftwareRevision String PropertyType Mandatory
HasProperty Variable HardwareRevision String PropertyType Mandatory
HasProperty Variable DeviceClass String PropertyType Optional
HasComponent Variable DeviceHealth DeviceHealth BaseDataVariableType Optional
HasComponent Object DeviceTypeImage FolderType Optional
HasComponent Object Documentation FolderType Optional
HasComponent Object ProtocolSupport FolderType Optional
HasComponent Object ImageSet FolderType Optional
HasComponent Object ConnectionPointType OptionalPlaceHolder
The DeviceType ObjectType is an abstract entity, meaning that it cannot have direct instances Instead, instances will be created from its sub-types In this context, the term "Device" broadly refers to any instance derived from the DeviceType.
Devices may have Parameters, Methods, and FunctionalGroups as defined for the TopologyElementType
The Properties outlined offer Clients a method to access common Device information, but they do not replace the information found in the Device's ParameterSet and/or FunctionalGroups It is important to note that this standard only makes the following assumptions regarding semantics, and standard organizations may provide additional specifications on the content.
While most properties are essential for all DeviceType instances, certain devices may not support some of these properties In such cases, vendors are required to provide default values.
• Properties with DataType String: empty string
• Properties with DataType LocalizedText: empty text field
The SerialNumber Property serves as a unique identifier assigned by the device manufacturer, typically stamped on the device's exterior This number is essential for traceability and warranty claims.
The RevisionCounter Property is an incremental counter indicating the number of times the static data within the Device has been modified
The Manufacturer Property provides the name of the company that manufactured the Device The Model Property provides the model name of the Device
The DeviceManual Property allows specifying an address of the user manual for the Device It may be a pathname in the file system or a URL (Web address)
The DeviceRevision Property provides the overall revision level of the Device
The SoftwareRevision Property provides the revision level of the software/firmware of the Device
The HardwareRevision Property provides the revision level of the hardware of the Device
The DeviceClass Property defines the domain or purpose of a Device, with examples including “ProgrammableController,” “RemoteIO,” and “TemperatureSensor.” While this standard does not specify DeviceClass names, more specific standards that incorporate DeviceType, such as IEC 62769, UA Companion PLCopen, and UA Companion ADI, are expected to establish these classifications.
The Description attribute of the Device Object offers essential information for identifying, managing, locating, and explaining the device as defined by the user Additionally, other organizations may define extra semantics for the contents of these Properties.
Parameters such as ManufacturerId, ModelId, and SubModelId, which serve as numeric identifiers for the company and its models, are not listed as Properties Instead, these identifiers will be incorporated into the Identification FunctionalGroup as outlined in section 5.4.
The DeviceHealth indicates the status of a device as defined by NAMUR Recommendation NE1 07 Clients can read or monitor this Variable to determine the device condition
The DeviceHealth DataType is an enumeration that defines the device condition Its values are defined in Table 1 0
NORMAL_0 The device functions normally
FAILURE_1 Malfunction of the device or any of its peripherals Typically caused device-internal or is process related
CHECK_FUNCTION_2 Functional checks are currently performed Examples: change of configuration, local operation, substitute value entered
"Off-spec" refers to a device functioning beyond its designated parameters, such as measurement or temperature limits, or indicating internal discrepancies from expected values due to internal issues or process characteristics.
MAINTENANCE_REQUIRED_4 Although the output signal is valid, the wear reserve is nearly exhausted or a function will soon be restricted due to operational conditions e.g build-up of deposits
ConnectionPoints (see 6.3) represent the interface (interface card) of a Device to a Network
A Device can have multiple ConnectionPoints if it supports multiple protocols and/or multiple Communication Profiles
Each DeviceType can include additional data such as images, documents, or protocol-specific information, which are organized into separate folders This information is represented by read-only Variables, allowing retrieval by accessing their values All instances of a DeviceType share the same Variable Node, ensuring that reading the Variable returns a consistent value across instances.
Figure 8 illustrates how the additional data is integrated into a DeviceType
Figure 8 – Integration of support information within a DeviceType
Clients need to be aware that the contents that these Variables represent may be large Reading large values with a single Read operation may not be possible due to configured
According to IEC 62541-1:2015, the default maximum size for an array of bytes in either the Client or Server stack is 1 megabyte It is advisable for Clients to utilize the IndexRange in the OPC UA Read Service to read these Variables in one-megabyte chunks Clients have the flexibility to either begin without an index and switch to using an IndexRange only after encountering an error, or to consistently employ an IndexRange from the start.
The different types of support information are specified in 5.7.2 to 5.7.5
Pictures of a Device can be exposed as Variables organised in the DeviceTypeImage folder There may be multiple images of different resolutions Each image is a separate Variable The
“DeviceTypeImage” Folder is formally defined in Table 1 1
References NodeClass BrowseName TypeDefinition DataType ModellingRule
HasTypeDefinition ObjectType FolderType (defined in IEC 62541 -5)
HasComponent Variable BaseDataVariableType Image MandatoryPlaceholder
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 IEC 62541 -3)
The Documentation folder contains Variables that represent documents related to a Device, typically including a product manual that may consist of several individual documents The formal definition of the "Documentation" folder is provided in Table 1.
References NodeClass BrowseName TypeDefinition DataType ModellingRule
HasTypeDefinition ObjectType FolderType (defined in IEC 62541 -5)
HasComponent Variable BaseDataVariableType ByteString MandatoryPlaceholder
All documents are transmitted as a ByteString, with each Variable's BrowseName reflecting the filename and its extension, which helps identify the document type Common extensions include ".pdf" and ".txt".
The ProtocolSupport folder contains protocol support files for a device, organized as Variables that represent different types of information defined by a protocol, such as GSD or CFF files This folder is formally outlined in Table 1.
References NodeClass BrowseName TypeDefinition DataType ModellingRule