EN IEC 62541-8:2020

OPC Unified Architecture - Part 8: Data Access

IEC 62541-8:2020 is available as IEC 62541-8:2020 RLV which contains the International Standard and its Redline version, showing all changes of the technical content compared to the previous edition.IEC 62541-8:2020 is part of the overall OPC Unified Architecture (OPC UA) standard series and defines the information model associated with Data Access (DA). It particularly includes additional VariableTypes and complementary descriptions of the NodeClasses and Attributes needed for Data Access, additional Properties, and other information and behaviour. The complete address space model, including all NodeClasses and Attributes is specified in IEC 62541-3. The services to detect and access data are specified in IEC 62541-4. This third edition cancels and replaces the second edition published in 2015. This edition constitutes a technical revision. This edition includes the following significant technical changes with respect to the previous edition: a) added new VariableTypes for AnalogItems; b) added an Annex that specifies a recommended mapping of OPC UA Dataccess to OPC COM DataAccess; c) changed the ambiguous description of "Bad_NotConnected"; d) updated description for EUInformation to refer to latest revision of UNCEFACT units.

OPC Unified Architecture – Teil 8: Zugriff auf Automatisierungsdaten

Architecture unifiée OPC - Partie 8: Accès aux données

IEC 62541-8:2020 est disponible sous forme de IEC 62541-8:2020 RLV qui contient la Norme internationale et sa version Redline, illustrant les modifications du contenu technique depuis l'édition précédente.L'IEC 62541-8:2020 fait partie intégrante de la série de normes générales sur l'architecture unifiée OPC (OPC UA). Elle définit le modèle d'information associé à l'Accès aux données (DA). Elle spécifie notamment des VariableTypes supplémentaires et fournit des descriptions complémentaires concernant les NodeClasses et attributs nécessaires pour l'Accès aux données, ainsi que des propriétés supplémentaires et d'autres paramètres relatifs aux informations et au comportement. Le modèle d'espace d'adresses complet, comprenant toutes les NodeClasses et tous les Attributs, est spécifié dans l'IEC 62541-3. Les services de détection et d'accès aux données sont spécifiés dans l'IEC 62541-4. Cette troisième édition annule et remplace la deuxième édition parue en 2015. Cette édition constitue une révision technique. Cette édition inclut les modifications techniques majeures suivantes par rapport à l'édition précédente: a) ajout de nouveaux VariableTypes pour les AnalogItems; b) ajout d'une annexe qui spécifie le mapping recommandé entre OPC UA DataAccess et OPC COM DataAccess; c) modification de la description ambiguë de "Bad_NotConnected"; d) mise à jour de la description de EUInformation pour renvoyer à la dernière révision des unités CEFACT-ONU.

Enotna arhitektura OPC - 8. del: Dostop do podatkov (IEC 62541-8:2020)

General Information

• Status: Published
• Publication Date: 06-Aug-2020
• ICS: 25.040.40 - Industrial process measurement and control
• ICS: 35.100 - Open systems interconnection (OSI)
• ICS: 35.100.05 - Multilayer applications
• Technical Committee: CLC/TC 65X - Industrial-process measurement, control and automation
• Drafting Committee: IEC/SC 65E - IEC_SC_65E
• Current Stage: 6060 - Document made available - Publishing
• Start Date: 07-Aug-2020
• Completion Date: 07-Aug-2020
• Mandate: M/490 - Standardisation mandate to the European Standardisation Organisations (ESOs) to support European Smart Grid deployment
• Ref Project: SIST EN IEC 62541-8:2020 - OPC Unified Architecture - Part 8: Data Access (IEC 62541-8:2020)

Relations

• Replaces: EN 45510-2-9:2008 - Guide for procurement of power station equipment - Part 2-9: Electrical equipment - Cabling systems
• Effective Date: 07-Jun-2022
• Revised: prEN IEC 62541-8:2024 - OPC unified architecture - Part 8: Data access
• Effective Date: 31-Jan-2023
• Revised: EN 45510-2-9:2008 - Guide for procurement of power station equipment - Part 2-9: Electrical equipment - Cabling systems
• Effective Date: 10-Jul-2018

Overview

EN IEC 62541-8:2020 (IEC 62541-8:2020) is Part 8 of the OPC Unified Architecture (OPC UA) standard series and defines the information model for Data Access (DA). This third edition replaces the 2015 edition and is published as an RLV (Redline Version) showing technical changes. The document specifies additional VariableTypes, Properties, NodeClass and Attribute descriptions, and Data Access-specific behaviour used to represent and access real-time automation data in an OPC UA address space.

Key topics

• Data Access information model: Definitions of DataItems and their semantics and relationships to automation data.
• VariableTypes: New and extended types including DataItemType, AnalogItem (new VariableTypes added for AnalogItems), DiscreteItemType, ArrayItemType, Y/XY/N-Dimensional array types, ImageItem and CubeItem types.
• Attributes & Properties: DA-specific Attributes (e.g., Range, EUInformation) and Properties required to describe values, units, ranges and metadata.
• DataTypes: Structured types such as Range, EUInformation (updated to reference latest UNECE units), ComplexNumberType, AxisInformation, and XVType.
• Service usage & behavior: Guidance for DA-specific use of OPC UA services (see IEC 62541-4 for services), including PercentDeadband, Status/quality codes and operation-level result codes.
• Error and status mapping: Clarified and updated status semantics (e.g., clarified description of Bad_NotConnected) and tables for status/result code behavior.
• Interoperability Annex: Informative Annex specifying recommended mapping between OPC UA DataAccess and legacy OPC COM DataAccess (DA), including wrappers/proxies, data and error mapping, read/write and subscription guidance.

Applications and who uses it

This standard is essential for:

• Industrial automation vendors (PLC/RTU/HMI/SCADA manufacturers) implementing OPC UA servers or clients for real-time data.
• System integrators designing interoperable control and monitoring systems.
• IIoT and Industry 4.0 developers creating gateways, historians, and data pipelines that require standardized data semantics and units.
• Software vendors building OPC UA wrappers/proxies to bridge OPC COM DA and OPC UA. Practical uses include secure, interoperable access to sensor and process variables, modelling complex array/image data, mapping legacy OPC DA systems to OPC UA, and ensuring correct unit and range metadata for analytics and visualization.

Related standards

• IEC 62541-1 – Overview and concepts
• IEC 62541-3 – Address Space Model (complete AddressSpace model)
• IEC 62541-4 – Services (communication and discovery)
• IEC 62541-5 – Information Model (core types)
• UNECE Recommendation No. 20 (units of measure) - referenced for EUInformation

Keywords: OPC UA, OPC Unified Architecture, EN IEC 62541-8:2020, Data Access, AnalogItem, VariableTypes, EUInformation, address space, OPC COM DA mapping.

Standards Content (Sample)

SLOVENSKI STANDARD
01-december-2020
Nadomešča:
SIST EN 62541-8:2015
Enotna arhitektura OPC - 8. del: Dostop do podatkov (IEC 62541-8:2020)
OPC Unified Architecture - Part 8: Data Access (IEC 62541-8:2020)
OPC Unified Architecture - Teil 8: Zugriff auf Automatisierungsdaten (IEC 62541-8:2020)
Architecture unifiée OPC - Partie 8: Accès aux données (IEC 62541-8:2020)
Ta slovenski standard je istoveten z: EN IEC 62541-8:2020
ICS:
25.040.40 Merjenje in krmiljenje Industrial process
industrijskih postopkov measurement and control
35.240.50 Uporabniške rešitve IT v IT applications in industry
industriji
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN IEC 62541-8

NORME EUROPÉENNE
EUROPÄISCHE NORM
August 2020
ICS 35.100.05; 25.040.40 Supersedes EN 62541-8:2015 and all of its amendments
and corrigenda (if any)
English Version
OPC Unified Architecture - Part 8: Data Access
(IEC 62541-8:2020)
Architecture unifiée OPC - Partie 8: Accès aux données OPC Unified Architecture - Teil 8: Zugriff auf
(IEC 62541-8:2020) Automatisierungsdaten
(IEC 62541-8:2020)
This European Standard was approved by CENELEC on 2020-07-27. CENELEC members are bound to comply with the CEN/CENELEC
Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2020 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN IEC 62541-8:2020 E

European foreword
The text of document 65E/708/FDIS, future edition 3 of IEC 62541-8, prepared by SC 65E "Devices
and integration in enterprise systems" of IEC/TC 65 "Industrial-process measurement, control and
automation" was submitted to the IEC-CENELEC parallel vote and approved by CENELEC as
The following dates are fixed:
• latest date by which the document has to be implemented at national (dop) 2021-04-27
level by publication of an identical national standard or by endorsement
• latest date by which the national standards conflicting with the (dow) 2023-07-27
document have to be withdrawn
This document supersedes EN 62541-8:2015 and all of its amendments and corrigenda (if any).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a mandate given to CENELEC by the European Commission
and the European Free Trade Association.
Endorsement notice
The text of the International Standard IEC 62541-8:2020 was approved by CENELEC as a European
Standard without any modification.

Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments)
applies.
NOTE 1  Where an International Publication has been modified by common modifications, indicated by (mod), the relevant
EN/HD applies.
NOTE 2  Up-to-date information on the latest versions of the European Standards listed in this annex is available here:
www.cenelec.eu.
Publication Year Title EN/HD Year
IEC/TR 62541-1 - OPC unified architecture - Part 1: CLC/TR 62541-1 -
Overview and concepts
IEC 62541-3 - OPC Unified Architecture - Part 3: - -
Address Space Model
IEC 62541-4 - OPC Unified Architecture - Part 4: - -
Services
IEC 62541-5 - OPC Unified Architecture - Part 5: - -
Information Model
UNECE 20 - Codes for Units of Measure Used in - -
International Trade
IEC 62541-8 ®
Edition 3.0 2020-06
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
OPC unified architecture –
Part 8: Data access
Architecture unifiée OPC –
Partie 8: Accès aux données
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
INTERNATIONALE
ICS 25.040.40; 35.100.05 ISBN 978-2-8322-8464-3

– 2 – IEC 62541-8:2020 © IEC 2020
CONTENTS
FOREWORD . 5
1 Scope . 7
2 Normative references . 7
3 Terms, definitions and abbreviated terms . 7
3.1 Terms and definitions . 7
3.2 Abbreviated terms . 8
4 Concepts . 8
5 Model . 9
5.1 General . 9
5.2 SemanticsChanged . 10
5.3 Variable Types . 10
5.3.1 DataItemType . 10
5.3.2 AnalogItem VariableTypes . 11
5.3.3 DiscreteItemType . 14
5.3.4 ArrayItemType . 17
5.4 Address Space model . 23
5.5 Attributes of DataItems . 24
5.6 DataTypes . 25
5.6.1 Overview . 25
5.6.2 Range . 25
5.6.3 EUInformation . 25
5.6.4 ComplexNumberType . 27
5.6.5 DoubleComplexNumberType . 27
5.6.6 AxisInformation . 28
5.6.7 AxisScaleEnumeration . 28
5.6.8 XVType . 29
6 Data Access specific usage of Services . 29
6.1 General . 29
6.2 PercentDeadband . 29
6.3 Data Access status codes . 30
6.3.1 Overview . 30
6.3.2 Operation level result codes . 30
6.3.3 LimitBits . 32
Annex A (informative) OPC COM DA to UA mapping . 33
A.1 Overview. 33
A.2 Security considerations . 33
A.3 COM UA wrapper for OPC DA Server . 33
A.3.1 Information Model mapping . 33
A.3.2 Data and error mapping . 37
A.3.3 Read data . 40
A.3.4 Write Data . 41
A.3.5 Subscriptions . 42
A.4 COM UA proxy for DA Client . 42
A.4.1 Guidelines . 42
A.4.2 Information Model and Address Space mapping . 42
A.4.3 Data and error mapping . 46

IEC 62541-8:2020 © IEC 2020 – 3 –
A.4.4 Read data . 48
A.4.5 Write data . 49
A.4.6 Subscriptions . 49

Figure 1 – OPC DataItems are linked to automation data . 9
Figure 2 – DataItem VariableType hierarchy . 10
Figure 3 – Graphical view of a YArrayItem . 19
Figure 4 – Representation of DataItems in the AddressSpace . 24
Figure A.1 – Sample OPC UA Information Model for OPC DA . 34
Figure A.2 – OPC COM DA to OPC UA data and error mapping . 38
Figure A.3 – Status Code mapping. 39
Figure A.4 – Sample OPC DA mapping of OPC UA Information Model and Address
Space . 43
Figure A.5 – OPC UA to OPC DA data & error mapping . 46
Figure A.6 – OPC UA Status Code to OPC DA quality mapping . 48

Table 1 – DataItemType definition . 11
Table 2 – BaseAnalogType definition . 12
Table 3 – AnalogItemType definition . 13
Table 4 – AnalogUnitType definition . 13
Table 5 – AnalogUnitRangeType definition . 14
Table 6 – DiscreteItemType definition . 14
Table 7 – TwoStateDiscreteType definition . 15
Table 8 – MultiStateDiscreteType definition . 15
Table 9 – MultiStateValueDiscreteType definition . 16
Table 10 – ArrayItemType definition . 17
Table 11 – YArrayItemType definition . 18
Table 12 – YArrayItem item description. 20
Table 13 – XYArrayItemType definition . 20
Table 14 – ImageItemType definition . 21
Table 15 – CubeItemType definition . 22
Table 16 – NDimensionArrayItemType definition . 23
Table 17 – Range DataType structure . 25
Table 18 – Range definition . 25
Table 19 – EUInformation DataType structure . 25
Table 20 – EUInformation definition . 26
Table 21 – Examples from UNECE Recommendation N° 20 . 26
Table 22 – ComplexNumberType DataType structure . 27
Table 23 – ComplexNumberType definition . 27
Table 24 – DoubleComplexNumberType DataType structure . 27
Table 25 – DoubleComplexNumberType definition . 28
Table 26 – AxisInformation DataType structure . 28
Table 27 – AxisScaleEnumeration values. 28
Table 28 – AxisScaleEnumeration definition . 29

– 4 – IEC 62541-8:2020 © IEC 2020
Table 29 – XVType DataType structure . 29
Table 30 – XVType definition . 29
Table 31 – Operation level result codes for BAD data quality . 31
Table 32 – Operation level result codes for UNCERTAIN data quality . 31
Table 33 – Operation level result codes for GOOD data quality . 31
Table A.1 – OPC COM DA to OPC UA Properties mapping . 36
Table A.2 – DataTypes and mapping . 39
Table A.3 – Quality mapping . 40
Table A.4 – OPC DA Read error mapping . 41
Table A.5 – OPC DA Write error code mapping . 41
Table A.6 – DataTypes and Mapping . 47
Table A.7 – Quality mapping . 48
Table A.8 – OPC UA Read error mapping . 49
Table A.9 – OPC UA Write error code mapping . 49

IEC 62541-8:2020 © IEC 2020 – 5 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
OPC UNIFIED ARCHITECTURE –
Part 8: Data access
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC Publication(s)"). Their
preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with
may participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between
any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent
rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62541-8 has been prepared by subcommittee 65E: Devices and
integration in enterprise systems, of IEC technical committee 65: Industrial-process
measurement, control and automation.
This third edition cancels and replaces the second edition published in 2015. This edition
constitutes a technical revision.
This edition includes the following significant technical changes with respect to the previous
edition:
a) added new VariableTypes for AnalogItems;
b) added an Annex that specifies a recommended mapping of OPC UA Dataccess to OPC
COM DataAccess;
c) changed the ambiguous description of "Bad_NotConnected";
d) updated description for EUInformation to refer to latest revision of UNCEFACT units.

– 6 – IEC 62541-8:2020 © IEC 2020
The text of this International Standard is based on the following documents:
FDIS Report on voting
65E/708/FDIS 65E/726/RVD
Full information on the voting for the approval of this International Standard can be found in the
report on voting indicated in the above table.
This document has been drafted in accordance with the ISO/IEC Directives, Part 2.
Throughout this document and the other parts of the IEC 62541 series, certain document
conventions are used:
Italics are used to denote a defined term or definition that appears in the "Terms and definition"
clause in one of the parts of the IEC 62541 series.
Italics are also used to denote the name of a service input or output parameter or the name of
a structure or element of a structure that are usually defined in tables.
The italicized terms and names are, with a few exceptions, written in camel-case (the practice
of writing compound words or phrases in which the elements are joined without spaces, with
each element's initial letter capitalized within the compound). For example, the defined term is
AddressSpace instead of Address Space. This makes it easier to understand that there is a
single definition for AddressSpace, not separate definitions for Address and Space.
A list of all parts of the IEC 62541 series, published under the general title OPC Unified
Architecture, can be found on the IEC website.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related to
the specific document. At this date, the document will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct understanding
of its contents. Users should therefore print this document using a colour printer.

IEC 62541-8:2020 © IEC 2020 – 7 –
OPC UNIFIED ARCHITECTURE –
Part 8: Data access
1 Scope
This part of IEC 62541 is part of the overall OPC Unified Architecture (OPC UA) standard series
and defines the information model associated with Data Access (DA). It particularly includes
additional VariableTypes and complementary descriptions of the NodeClasses and Attributes
needed for Data Access, additional Properties, and other information and behaviour.
The complete address space model, including all NodeClasses and Attributes is specified in
IEC 62541-3. The services to detect and access data are specified in IEC 62541-4.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies.
For undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC TR 62541-1, OPC Unified Architecture – Part 1: Overview and Concepts
IEC 62541-3, OPC Unified Architecture – Part 3: Address Space Model
IEC 62541-4, OPC Unified Architecture – Part 4: Services
IEC 62541-5, OPC Unified Architecture – Part 5: Information Model
UN/CEFACT: UNECE Recommendation N° 20, Codes for Units of Measure Used in
International Trade, available at
https://www.unece.org/cefact/codesfortrade/codes_index.html
3 Terms, definitions and abbreviated terms
3.1 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-4 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1.1
DataItem
link to arbitrary, live automation data, that is, data that represents currently valid information
Note 1 to entry: Examples of such data are
• device data (such as temperature sensors),

– 8 – IEC 62541-8:2020 © IEC 2020
• calculated data,
• status information (open/closed, moving),
• dynamically changing system data (such as stock quotes),
• diagnostic data.
3.1.2
AnalogItem
DataItem that represents continuously variable physical quantities (e.g. length, temperature),
in contrast to the digital representation of data in discrete items
Note 1 to entry: Typical examples are the values provided by temperature sensors or pressure sensors. OPC UA
defines a specific VariableType to identify an AnalogItem. Properties describe the possible ranges of AnalogItems.
3.1.3
DiscreteItem
DataItem that represents data that may take on only a certain number of possible values (e.g.
OPENING, OPEN, CLOSING, CLOSED)
Note 1 to entry: Specific VariableTypes are used to identify DiscreteItems with two states or with multiple states.
Properties specify the string values for these states.
3.1.4
ArrayItem
DataItem that represents continuously variable physical quantities and where each individual
data point consists of multiple values represented by an array (e.g., the spectral response of a
digital filter)
Note 1 to entry: Typical examples are the data provided by analyser devices. Specific VariableTypes are used to
identify ArrayItem variants.
3.1.5
EngineeringUnits
units of measurement for AnalogItems that represent continuously variable physical quantities
(e.g. length, mass, time, temperature)
Note 1 to entry: This standard defines Properties to inform about the unit used for the DataItem value and about
the highest and lowest value likely to be obtained in normal operation.
3.2 Abbreviated terms
DA data access
EU engineering unit
UA Unified Architecture
4 Concepts
Data Access deals with the representation and use of automation data in Servers.
Automation data can be located inside the Server or on I/O cards directly connected to the
Server. It can also be located in sub-servers or on other devices such as controllers and
input/output modules, connected by serial links via field buses or other communication links.
OPC UA Data Access Servers provide one or more OPC UA Data Access Clients with
transparent access to their automation data.
The links to automation data instances are called DataItems. The categories of automation data
are provided is completely vendor-specific. Figure 1 illustrates how the AddressSpace of a
Server may consist of a broad range of different DataItems.

IEC 62541-8:2020 © IEC 2020 – 9 –

OPC UA Server
Root
AddressSpace
with data items
IEC
Figure 1 – OPC DataItems are linked to automation data
Clients may read or write DataItems, or monitor them for value changes. The Services needed
for these operations are specified in IEC 62541-4. Changes are defined as a change in status
(quality) or a change in value that exceeds a client-defined range called a Deadband. To detect
the value change, the difference between the current value and the last reported value is
compared to the Deadband.
5 Model
5.1 General
The DataAccess model extends the variable model by defining VariableTypes. The
DataItemType is the base type. ArrayItemType, BaseAnalogType and DiscreteItemType are
specializations. See Figure 2. Each of these VariableTypes can be further extended to form
domain- or server-specific DataItems.
Annex A specifies the recommended way for mapping the information received from OPC COM
Data Access (DA) Servers to the model in this document.

– 10 – IEC 62541-8:2020 © IEC 2020
BaseDataVariableType
Defined in
IEC 62541-5
Type
DataItemType
DiscreteItemType
ArrayItem
EUItemType
Type
AnalogItem
TwoStateDiscreteType
Type AnalogUnit
ItemType
MultiState MultiStateValue
DiscreteType DiscreteType
IEC
Figure 2 – DataItem VariableType hierarchy
5.2 SemanticsChanged
The StatusCode also contains an informational bit called SemanticsChanged.
Servers that implement Data Access shall set this Bit in notifications if certain Properties defined
in this standard change. The corresponding Properties are specified individually for each
VariableType.
Clients that use any of these Properties should re-read them before they process the data value.
5.3 Variable Types
5.3.1 DataItemType
This VariableType defines the general characteristics of a DataItem. All other DataItem Types
derive from it. The DataItemType derives from the BaseDataVariableType and therefore shares
the variable model as described in IEC 62541-3 and IEC 62541-5. It is formally defined
in Table 1.
IEC 62541-8:2020 © IEC 2020 – 11 –
Table 1 – DataItemType definition
Attribute Value
BrowseName DataItemType
IsAbstract False
ValueRank −2 (−2 = ‘Any’)
DataType BaseDataType
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Subtype of the BaseDataVariableType defined in IEC 62541-5; i.e the Properties of that type are inherited.
HasSubtype VariableType AnalogItemType Defined in 5.3.2
HasSubtype VariableType DiscreteItemType Defined in 5.3.3
HasSubtype VariableType ArrayItemType Defined in 5.3.4
HasProperty Variable Definition String PropertyType Optional
HasProperty Variable ValuePrecision Double PropertyType Optional

Definition is a vendor-specific, human-readable string that specifies how the value of this
DataItem is calculated. Definition is non-localized and will often contain an equation that can
be parsed by certain clients.
EXAMPLE: Definition::= "(TempA – 25) + TempB"
ValuePrecision specifies the maximum precision that the Server can maintain for the item based
on restrictions in the target environment.
ValuePrecision can be used for the following DataTypes:
• for Float and Double values it specifies the number of digits after the decimal place;
• for DateTime values it indicates the minimum time difference in nanoseconds. For example,
a ValuePrecision of 20 000 000 defines a precision of 20 ms.
The ValuePrecision Property is an approximation that is intended to provide guidance to a
Client. A Server is expected to silently round any value with more precision that it supports.
This implies that a Client may encounter cases where the value read back from a Server differs
from the value that it wrote to the Server. This difference shall be no more than the difference
suggested by this Property.
5.3.2 AnalogItem VariableTypes
5.3.2.1 General
The VariableTypes in this subclause define the characteristics of AnalogItems. The types have
identical semantics and Properties but with diverging ModellingRules for individual Properties.
The Properties are only described once – in 5.3.2.2. The descriptions apply to the Properties
for the other VariableTypes as well.
5.3.2.2 BaseAnalogType
This VariableType is the base type for analog items. All Properties are optional. Subtypes of
this base type will mandate some of the Properties. The BaseAnalogType derives from the
DataItemType. It is formally defined in Table 2.

– 12 – IEC 62541-8:2020 © IEC 2020
Table 2 – BaseAnalogType definition
Attribute Value
BrowseName BaseAnalogType
IsAbstract False
ValueRank −2 (−2 = ‘Any’)
DataType Number
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Subtype of the DataItemType defined in 5.3.1 i.e the Properties of that type are inherited.
HasSubtype VariableType AnalogItemType Defined in 5.3.2.3
HasSubtype VariableType AnalogUnitType Defined in 5.3.2.4
HasProperty Variable InstrumentRange Range PropertyType Optional
HasProperty Variable EURange Range PropertyType Optional
HasProperty Variable EngineeringUnits EUInformation PropertyType Optional

The following paragraphs describe the Properties of this VariableType. If the analog item’s
Value contains an array, the Properties shall apply to all elements in the array.
InstrumentRange defines the value range that can be returned by the instrument.
EXAMPLE 1 InstrumentRange::= {−9 999,9, 9 999,9}
Although defined as optional, it is strongly recommended for Servers to support this Property.
Without an InstrumentRange being provided, Clients will commonly assume the full range
according to the DataType.
The InstrumentRange Property may also be used to restrict a Built-in DataType such as Byte
or Int16) to a smaller range of values.
EXAMPLE 2
Uint4: InstrumentRange::= {0, 15}
Int6: InstrumentRange::= {−32, 31}
The Range Data Type is specified in 5.6.2.
EURange defines the value range likely to be obtained in normal operation. It is intended for
such use as automatically scaling a bar graph display.
Sensor or instrument failure or deactivation can result in a returned item value which is actually
outside of this range. Client software shall be prepared to deal with this possibility. Similarly a
Client may attempt to write a value that is outside of this range back to the server. The exact
behaviour (accept, reject, clamp, etc.) in this case is Server-dependent. However, in general
Servers shall be prepared to handle this.
EXAMPLE 3 EURange::= {−200,0, 1 400,0}
See also 6.2 for a special monitoring filter (PercentDeadband) which is based on the
engineering unit range.
NOTE 1 If EURange is not provided on an instance, the PercentDeadband filter cannot be used for that instance
(see 6.2).
EngineeringUnits specifies the units for the DataItem’s value (e.g., DEGC, hertz, seconds). The
EUInformation type is specified in 5.6.3.

IEC 62541-8:2020 © IEC 2020 – 13 –
It is important to note that understanding the units of a measurement value is essential for a
uniform system. In an open system in particular where Servers from different cultures might be
used, it is essential to know what the units of measurement are. Based on such knowledge,
values can be converted if necessary before being used. Therefore, although defined as
optional, support of the EngineeringUnits Property is strongly advised.
OPC UA recommends using the "Codes for Units of Measurement" (see UN/CEFACT: UNECE
Recommendation N° 20). The mapping to the EngineeringUnits Property is specified in 5.6.3.
NOTE 2 Examples for unit mixup: in 1999, the Mars Climate Orbiter crashed into the surface of Mars. The main
reason was a discrepancy over the units used. The navigation software expected data in newton second; the company
who built the orbiter provided data in pound-force seconds. Another, less expensive, disappointment occurs when
people used to British pints order a pint in the USA, only to be served what they consider a short measure.
The StatusCode SemanticsChanged bit shall be set if any of the EURange (could change the
behaviour of a Subscription if a PercentDeadband filter is used) or EngineeringUnits (could
create problems if the Client uses the value to perform calculations) Properties are changed
(see 5.2 for additional information).
5.3.2.3 AnalogItemType
This VariableType requires the EURange Property. The AnalogItemType derives from the
BaseAnalogType. It is formally defined in Table 3.
Table 3 – AnalogItemType definition
Attribute Value
BrowseName AnalogItemType
IsAbstract False
ValueRank −2 (−2 = ‘Any’)
DataType Number
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Subtype of the BaseAnalogType defined in 5.3.2.2, i.e the Properties of that type are inherited.
HasSubtype VariableType AnalogUnitRangeType Defined in 5.3.2.5
HasProperty Variable EURange Range PropertyType Mandatory

5.3.2.4 AnalogUnitType
This VariableType requires the EngineeringUnits Property. The AnalogUnitType derives from
the BaseAnalogType. It is formally defined in Table 4.
Table 4 – AnalogUnitType definition
Attribute Value
BrowseName AnalogUnitType
IsAbstract False
ValueRank −2 (−2 = ‘Any’)
DataType Number
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Subtype of the BaseAnalogType defined in 5.3.2.2, i.e the Properties of that type are inherited.
HasProperty Variable EngineeringUnits EUInformation PropertyType Mandatory

– 14 – IEC 62541-8:2020 © IEC 2020
5.3.2.5 AnalogUnitRangeType
The AnalogUnitRangeType derives from the AnalogItemType and additionaly requires the
EngineeringUnits Property. It is formally defined in Table 5.
Table 5 – AnalogUnitRangeType definition
Attribute Value
BrowseName AnalogUnitRangeType
IsAbstract False
ValueRank −2 (−2 = ‘Any’)
DataType Number
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Subtype of the AnalogItemType defined in 5.3.2.3, i.e the Properties of that type are inherited.
HasProperty Variable EngineeringUnits EUInformation PropertyType Mandatory

5.3.3 DiscreteItemType
5.3.3.1 General
This VariableType is an abstract type. That is, no instances of this type can exist. However, it
might be used in a filter when browsing or querying. The DiscreteItemType derives from the
DataItemType and therefore shares all of its characteristics. It is formally defined in Table 6.
Table 6 – DiscreteItemType definition
Attribute Value
BrowseName DiscreteItemType
IsAbstract True
ValueRank −2 (−2 = ‘Any’)
DataType BaseDataType
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Subtype of the DataItemType defined in 5.2; i.e the Properties of that type are inherited.
HasSubtype VariableType TwoStateDiscreteType Defined in 5.3.3.2
HasSubtype VariableType MultiStateDiscreteType Defined in 5.3.3.3
HasSubtype VariableType MultiStateValueDiscreteType Defined in 5.3.3.4

5.3.3.2 TwoStateDiscreteType
This VariableType defines the general characteristics of a DiscreteItem that can have two
states. The TwoStateDiscreteType derives from the DiscreteItemType. It is formally defined in
Table 7.
IEC 62541-8:2020 © IEC 2020 – 15 –
Table 7 – TwoStateDiscreteType definition
Attribute Value
BrowseName TwoStateDiscreteType
IsAbstract False
ValueRank −2 (−2 = ‘Any’)
DataType Boolean
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Subtype of the DiscreteItemType defined in 5.3.3; i.e the Properties of that type are inherited.
HasProperty Variable TrueState LocalizedText PropertyType Mandatory
HasProperty Variable FalseState LocalizedText PropertyType Mandatory

TrueState contains a string to be associated with this DataItem when it is TRUE. This is typically
used for a contact when it is in the closed (non-zero) state.
for example: "RUN", "CLOSE", "ENABLE", "SAFE", etc.
FalseState contains a string to be associated with this DataItem when it is FALSE. This is
typically used for a contact when it is in the open (zero) state.
for example: "STOP", "OPEN", "DISABLE", "UNSAFE", etc.
If the item contains an array, then the Properties will apply to all elements in the array.
The StatusCode SemanticsChanged bit shall be set if any of the FalseState or TrueState
(changes can cause misinterpretation by users or (scripting) programs) Properties are changed
(see 5.2 for additional information).
5.3.3.3 MultiStateDiscreteType
This VariableType defines the general characteristics of a DiscreteItem that can have more than
two states. The MultiStateDiscreteType derives from the DiscreteItemType. It is formally
defined in Table 8.
Table 8 – MultiStateDiscreteType definition
Attribute Value
BrowseName MultiStateDiscreteType
IsAbstract False
ValueRank −2 (−2 = ‘Any’)
DataType UInteger
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Subtype of the DiscreteItemType defined in 5.3.3; i.e the Properties of that type are inherited.
HasProperty Variable EnumStrings LocalizedText[] PropertyType Mandatory

EnumStrings is a string lookup table corresponding to sequential numeric values (0, 1, 2, etc.)

– 16 – IEC 62541-8:2020 © IEC 2020
Example:
"OPEN"
"CLOSE"
"IN TRANSIT" etc.
Here the string "OPEN" corresponds to 0, "CLOSE" to 1 and "IN TRANSIT" to 2.
Clients should be prepared to handle item values outside of the range of the list; and robust
servers should be prepared to handle writes of illegal values.
If the item contains an array, then this lookup table shall apply to all elements in the array.
NOTE The EnumStrings property is also used for Enumeration DataTypes (for the specification of this DataType,
see IEC 62541-3).
The StatusCode SemanticsChanged bit shall be set if the EnumStrings (changes can cause
misinterpretation by users or (scripting) programs) Property is changed (see 5.2 for additional
information).
5.3.3.4 MultiStateValueDiscreteType
This VariableType defines the general characteristics of a DiscreteItem that can have more than
two states and where the state values (the enumeration) does not consist of consecutive
numeric values (
...