IEC 62541-8:2020

IEC 62541-8 ®
Edition 3.0 2020-06
REDLINE VERSION
INTERNATIONAL
STANDARD
colour
inside
OPC unified architecture –
Part 8: Data access
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - webstore.iec.ch/advsearchform Electropedia - www.electropedia.org
The advanced search enables to find IEC publications by a The world's leading online dictionary on electrotechnology,
variety of criteria (reference number, text, technical containing more than 22 000 terminological entries in English
committee,…). It also gives information on projects, replaced and French, with equivalent terms in 16 additional languages.
and withdrawn publications. Also known as the International Electrotechnical Vocabulary

(IEV) online.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Glossary - std.iec.ch/glossary
details all new publications released. Available online and 67 000 electrotechnical terminology entries in English and
once a month by email. French extracted from the Terms and Definitions clause of
IEC publications issued since 2002. Some entries have been
IEC Customer Service Centre - webstore.iec.ch/csc collected from earlier publications of IEC TC 37, 77, 86 and
If you wish to give us your feedback on this publication or CISPR.

need further assistance, please contact the Customer Service

Centre: sales@iec.ch.
IEC 62541-8 ®
Edition 3.0 2020-06
REDLINE VERSION
INTERNATIONAL
STANDARD
colour
inside
OPC unified architecture –
Part 8: Data access
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 25.040.40; 35.100.05 ISBN 978-2-8322-8572-5

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

A.4.4 Read data . 49
A.4.5 Write data . 50
A.4.6 Subscriptions . 50

Figure 1 – OPC DataItems are linked to automation data . 10
Figure 2 – DataItem VariableType hierarchy . 11
Figure 3 – Graphical view of a YArrayItem . 20
Figure 4 – Representation of DataItems in the AddressSpace . 25
Figure A.1 – Sample OPC UA Information Model for OPC DA . 35
Figure A.2 – OPC COM DA to OPC UA data and error mapping . 39
Figure A.3 – Status Code mapping. 40
Figure A.4 – Sample OPC DA mapping of OPC UA Information Model and Address
Space . 44
Figure A.5 – OPC UA to OPC DA data & error mapping . 47
Figure A.6 – OPC UA Status Code to OPC DA quality mapping . 49

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

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

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.
This redline version of the official IEC Standard allows the user to identify the changes
made to the previous edition. A vertical bar appears in the margin wherever a change has
been made. Additions are in green text, deletions are in strikethrough red text.

– 6 – IEC 62541-8:2020 RLV © IEC 2020
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.
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.

– 8 – IEC 62541-8:2020 RLV © IEC 2020
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),

• 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 and symbols
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 might may consist of a broad range of different DataItems.

– 10 – IEC 62541-8:2020 RLV © IEC 2020

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, AnalogItemType BaseAnalogType and
DiscreteItemType (and its TwoState and MultiState subtypes) 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.

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.
– 12 – IEC 62541-8:2020 RLV © IEC 2020
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
This VariableType defines the general characteristics of an AnalogItem. All other AnalogItem
Types derive from it. The AnalogItemType derives from the DataItemType. It is formally defined
in Table 2.
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.

Table 2 – AnalogItemType BaseAnalogType definition
Attribute Value
BrowseName AnalogItemType 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 MandatoryOptional
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 must 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.

– 14 – IEC 62541-8:2020 RLV © IEC 2020
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

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
– 16 – IEC 62541-8:2020 RLV © IEC 2020
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.)

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 (may have gaps) or where the enumeration is not zero-based. The
MultiStateValueDiscreteType derives from the DiscreteItemType. It is formally defined
in Table 9.
Table 9 – MultiStateValueDiscreteType definition
Attribute Value
BrowseName MultiStateValueDiscreteType
IsAbstract False
ValueRank Scalar
DataType Number
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 EnumValues See IEC 62541-3 Mandatory
HasProperty Variable ValueAsText See IEC 62541-3 Mandatory

EnumValues is an array of EnumValueType. Each entry of the array represents one
enumeration value with its integer notation, a human-readable representation, and help
information. This represents enumerations with integers that are not zero-based or have gaps
(e.g. 1, 2, 4, 8, 16). See IEC 62541-3 for the definition of this type. MultiStateValueDiscrete
Variables expose the current integer notation in their Value Attribute. Clients will often read the
EnumValues Property in advance and cache it to lookup a name or help whenever they receive
the numeric representation.
MultiStateValueDiscrete Variables can have any numeric Data Type; this includes signed and
unsigned integers from 8 to 64 Bit length.
Only DataTypes that can be represented with EnumValues are allowed for Variables of
MultiStateValueDiscreteType. These are:
• signed integers up to 64 bits in length;
• unsigned integers up to 63 bits in length.

– 18 – IEC 62541-8:2020 RLV © IEC 2020
The numeric representation of the current enumeration value is provided via the Value Attribute
of the MultiStateValueDiscrete Variable. The ValueAsText Property provides the localized text
representation of the enumeration value. It can be used by Clients only interested in displaying
the text to subscribe to the Property instead of the Value Attribute.
5.3.4 ArrayItemType
5.3.4.1 General
This abstract VariableType defines the general characteristics of an ArrayItem. Values are
exposed in an array, but the content of the array represents a single entity like an image. Other
DataItems might contain arrays that represent for example several values of several
temperature sensors of a boiler.
ArrayItemType or its subtype shall only be used when the Title and AxisScaleType Properties
can be filled with reasonable values. If this is not the case DataItemType and subtypes like
AnalogItemType, which also support arrays, shall be used. The ArrayItemType is formally
defined in Table 10.
Table 10 – ArrayItemType definition
Attribute Value
BrowseName ArrayItemType
IsAbstract True
ValueRank 0 (0 = OneOrMoreDimensions)
DataType BaseDataType
References NodeClass BrowseName DataType TypeDefinition ModellingRu
...