IEC TS 62453-53-90:2025

IEC TS 62453-53-90 ®
Edition 1.0 2025-04
TECHNICAL
SPECIFICATION
Field Device Tool (FDT) Interface Specification –
Part 53-90: Communication implementation for CLI and HTML – IEC 61784 CPF 9

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 Secretariat 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 IEC Products & Services Portal - products.iec.ch
The advanced search enables to find IEC publications by a Discover our powerful search engine and read freely all the
variety of criteria (reference number, text, technical publications previews, graphical symbols and the glossary.
committee, …). It also gives information on projects, replaced With a subscription you will always have access to up to date
and withdrawn publications. content tailored to your needs.

IEC Just Published - webstore.iec.ch/justpublished
Electropedia - www.electropedia.org
Stay up to date on all new IEC publications. Just Published
The world's leading online dictionary on electrotechnology,
details all new publications released. Available online and once
containing more than 22 500 terminological entries in English
a month by email.
and French, with equivalent terms in 25 additional languages.

Also known as the International Electrotechnical Vocabulary
IEC Customer Service Centre - webstore.iec.ch/csc
(IEV) online.
If you wish to give us your feedback on this publication or need

further assistance, please contact the Customer Service
Centre: sales@iec.ch.
IEC TS 62453-53-90 ®
Edition 1.0 2025-04
TECHNICAL
SPECIFICATION
Field Device Tool (FDT) Interface Specification –

Part 53-90: Communication implementation for CLI and HTML – IEC 61784 CPF 9

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 25.040.40; 35.100.05; 35.110 ISBN 978-2-8327-0284-0

– 2 – IEC TS 62453-53-90:2025 © IEC 2025
CONTENTS
FOREWORD . 5
INTRODUCTION . 7
1 Scope . 8
2 Normative references . 8
3 Terms, definitions, abbreviated terms, symbols, and conventions . 9
3.1 Terms, definitions abbreviated terms and symbols . 9
3.2 Conventions . 9
3.2.1 Datatype names and references to datatypes . 9
3.2.2 Use of UML . 9
4 Bus category . 9
5 Access to instance, device and process data . 10
5.1 General . 10
5.2 IO signals provided by DTM . 10
5.3 Data interfaces . 11
5.3.1 General . 11
5.3.2 Mapping HART datatypes to FDT datatypes . 11
5.3.3 SemanticInfo . 12
5.3.4 Data exposure using IDeviceData and IInstanceData interfaces . 13
6 Protocol specific behaviour . 18
6.1 Support of burst mode . 18
6.2 Device addressing . 19
6.3 Support of scanning . 19
6.4 Support of extended command numbers . 19
6.5 Support for handling of communication failures and time-outs . 19
6.6 Support for handling of delayed responses . 20
6.7 Buscategory HART_Basic . 20
6.8 Support for topologies with mixed HART protocols . 20
6.9 Support for nested communication structures with multiple gateways . 20
6.10 Support for topologies with WirelessHART . 20
6.11 Transparent gateways . 20
6.11.1 General . 20
6.11.2 Scenario 1 – Manual topology creation . 21
6.11.3 Scenario 2 – Topology scan and add . 21
7 Protocol specific usage of general datatypes . 21
8 Protocol specific common datatypes . 22
8.1 HartDeviceAddress datatype . 22
8.2 HartDeviceIpAddress datatype . 23
8.3 HartDeviceWirelessAddress datatype . 24
9 Network management datatypes . 25
10 Communication datatypes. 25
10.1 General . 25
10.2 HartConnectRequest datatype . 25
10.3 HartConnectResponse datatype . 26
10.4 HartLongAddress datatype . 27
10.5 HartDisconnectRequest datatype . 28
10.6 HartDisconnectResponse datatype . 28

10.7 HartTransactionRequest datatype . 29
10.8 HartTransactionResponse datatype . 29
10.9 HartStatus datatype . 30
10.10 HartAbortMessage datatype . 30
10.11 HartSubscribeRequest datatype . 31
10.12 HartSubscribeResponse datatype . 31
10.13 HartUnsubscribeRequest datatype . 32
10.14 HartUnsubscribeResponse datatype . 32
11 Datatypes for process data information . 33
11.1 General . 33
11.2 HartIOSignalInfo datatype . 33
12 Device identification . 34
12.1 General . 34
12.2 HartDeviceScanInfo datatype . 34
12.3 HartDeviceIdentInfo datatype . 38
12.4 Mapping of information source . 39
Bibliography . 41

Figure 1 – Relation of IEC TS 62453-53-90 to the IEC 62453 series . 7
Figure 2 – Structural information for device variables . 16
Figure 3 – Structural information for dynamic variables . 17
Figure 4 – Structural information for extended device status . 18
Figure 5 – Device-initiated data transfer with burst mode . 19
Figure 6 – Example with transparent adapters . 21
Figure 7 – HartDeviceAddress datatype . 22
Figure 8 – HartDeviceIpAddress datatype . 23
Figure 9 – HartDeviceWirelessAddress datatype . 24
Figure 10 – HartNetworkData datatype . 25
Figure 11 – HartConnectRequest datatype . 26
Figure 12 – HartConnectResponse datatype . 27
Figure 13 – HartDisconnectRequest datatype . 28
Figure 14 – HartDisconnectResponse datatype . 28
Figure 15 – HartTransactionRequest datatype . 29
Figure 16 – HartTransactionResponse datatype . 29
Figure 17 – HartAbortMessage datatype . 30
Figure 18 – HartSubscribeRequest datatype . 31
Figure 19 – HartSubscribeResponse datatype . 31
Figure 20 – HartUnsubscribeRequest datatype . 32
Figure 21 – HartUnsubscribeResponse datatype . 32
Figure 22 – HartIOSignalInfo datatype . 33
Figure 23 – HartDeviceScanInfo datatype . 34
Figure 24 – HartDeviceIdentInfo datatype . 38

Table 1 – Relation of BusCategories and supported features . 9
Table 2 – Output signal info within IOSignalInfo/HartIOSignalInfo . 11

– 4 – IEC TS 62453-53-90:2025 © IEC 2025
Table 3 – Mapping of basic datatypes . 11
Table 4 – SemanticInfo attributes description . 12
Table 5 – Basic Variables exported in IDeviceData and IInstanceData interfaces . 13
Table 6 – Basic Variables exported only in IDeviceData interface . 15
Table 7 – Protocol-specific usage of general datatypes . 21
Table 8 – HartDeviceAddress datatype . 22
Table 9 – HartDeviceIpAddress datatype . 23
Table 10 – HartDeviceWirelessAddress datatype . 24
Table 11 – HartNetworkData datatype . 25
Table 12 – HartConnectRequest datatype . 26
Table 13 – HartConnectResponse datatype . 27
Table 14 – HartLongAddress datatype . 27
Table 15 – HartDisconnectRequest datatype . 28
Table 16 – HartDisconnectResponse datatype . 28
Table 17 – HartTransactionRequest datatype . 29
Table 18 – HartTransactionResponse datatype . 30
Table 19 – HartStatus datatype . 30
Table 20 – HartAbortMessage datatype . 30
Table 21 – HartSubscribeRequest datatype . 31
Table 22 – HartSubscribeResponse datatype . 31
Table 23 – HartUnsubscribeRequest datatype . 32
Table 24 – HartUnsubscribeResponse datatype . 32
Table 25 – Usage of IOSignalInfo datatype . 33
Table 26 – HartIOSignalInfo datatype . 34
Table 27 – HartDeviceScanInfo datatype . 35
Table 28 – Protocol specific mapping of scan information . 36
Table 29 – HartDeviceIdentInfo datatype . 38
Table 30 – Protocol specific mapping of identity information . 39

INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
FIELD DEVICE TOOL (FDT) INTERFACE SPECIFICATION –

Part 53-90: Communication implementation for CLI and HTML –
IEC 61784 CPF 9
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) IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in
respect thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s), which
may be required to implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at https://patents.iec.ch. IEC
shall not be held responsible for identifying any or all such patent rights.
IEC TS 62453-53-90 has been prepared by subcommittee 65E: Devices and integration in
enterprise systems, of IEC technical committee 65: Industrial-process measurement, control
and automation. It is a Technical Specification.
The text of this Technical Specification is based on the following documents:
Draft Report on voting
65E/1111/DTS 65E/1162/RVDTS
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this Technical Specification is English.

– 6 – IEC TS 62453-53-90:2025 © IEC 2025
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available
at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are
described in greater detail at www.iec.ch/standardsdev/publications.
A list of all parts in the IEC 62453 series, published under the general title Field device tool
(FDT) interface specification, 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 webstore.iec.ch in the data related to the
specific document. At this date, the document will be
• reconfirmed,
• withdrawn, or
• revised.
INTRODUCTION
This part of IEC 62453 is an interface specification for developers of Field Device Tool (FDT)
components for function control and data access within a client/server architecture. The
specification is a result of an analysis and design process to develop standard interfaces to
facilitate the development of servers and clients by multiple vendors that need to interoperate
seamlessly.
With the integration of fieldbuses into control systems, there are a few other tasks which need
to be performed. In addition to fieldbus- and device-specific tools, there is a need to integrate
these tools into higher-level system-wide planning or engineering tools. In particular, for use in
extensive and heterogeneous control systems, typically in the area of the process industry, the
unambiguous definition of engineering interfaces that are easy to use for all those involved is
of great importance.
A device-specific software component, called Device Type Manager (DTM), is supplied by the
field device manufacturer with its device. The DTM is integrated into engineering tools via the
FDT interfaces defined in this specification. The approach to integration is in general open for
all kind of fieldbusses and thus meets the requirements for integrating different kinds of devices
into heterogeneous control systems.
Figure 1 shows how this part of the IEC 62453-53-xy series is aligned in the structure of the
IEC 62453 series.
Figure 1 – Relation of IEC TS 62453-53-90 to the IEC 62453 series

– 8 – IEC TS 62453-53-90:2025 © IEC 2025
FIELD DEVICE TOOL (FDT) INTERFACE SPECIFICATION –

Part 53-90: Communication implementation for CLI and HTML –
IEC 61784 CPF 9
1 Scope
This part of the IEC 62453-53-xy series, which is a Technical Specification, provides information
for integrating the HART® technology into the CLI-based implementation of FDT interface
specification (IEC TS 62453-43).
This document specifies implementation of communication and other services based on
IEC 62453-309.
This document neither contains the FDT specification nor modifies it.
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 61784 (all parts), Industrial communication networks – Profiles
IEC 62453-1, Field device tool (FDT) interface specification – Part 1: Overview and guidance
IEC 62453-2, Field device tool (FDT) interface specification – Part 2: Concepts and detailed
description
IEC TS 62453-43, Field device tool (FDT) interface specification – Part 41: Object model
integration profile – CLI and HTML
IEC 62453-309:2022, Field device tool (FDT) interface specification – Part 309: Communication
profile integration – IEC 61784 CPF 9
___________
HART® and WirelessHART® are trade names of products supplied by FieldComm Group. This information is
given for convenience of users of this document and does not constitute an endorsement by IEC of the product
named. Equivalent products may be used if they can be shown to lead to the same results.

3 Terms, definitions, abbreviated terms, symbols, and conventions
3.1 Terms, definitions abbreviated terms and symbols
For the purposes of this document, the terms, definitions, abbreviated terms and symbols given
in IEC 62453-1, IEC 62453-2, IEC 62453-43, and IEC 62453-309 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.2 Conventions
3.2.1 Datatype names and references to datatypes
The conventions for naming and referencing of datatypes are explained in IEC 62453-1.
3.2.2 Use of UML
Figures in this document are using UML notation as defined in IEC 62453-1.
4 Bus category
IEC 61784 CPF 9 protocol is identified in the attribute busCategory of the BusCategory element
by the identifiers, as specified in IEC 62453-309.
The addressing modes depend on the type of the used HART protocol. Also additional
addressing information might be necessary for some types of HART protocols. Table 1 shows
the dependency of usable addressing modes and additional address information in dependency
of the HART protocol in use.
Table 1 – Relation of BusCategories and supported features
BusCategory Supported Address Exposed Comment
Name Addressing Modes Datatype Data
HART_Basic ShortAddress HartDevice Not defined An IEC 62453-43 DTM shall use this
Address Id in addition to HART_FSK in order
to provide compatibility with FDT2
DTMs
Only single byte ManufacturerID and
DeviceTypeID are supported.
HART_FSK ShortAddress, As A DTM may use more than one of
described these Ids if the device supports
HART_RS485 ShortTag,
in 5.3 multiple physical connections for
example WirelessHART and FSK
LongTag
HART_Infrared
HART_Wireless HartDeviceWire
lessAddress
HART_IP HartDeviceIpAd
dress
IEC 62453-309 also defines which PhysicalLayer can be used together with the different
BusCategories.
The significant information for topology planning is the BusCategory. The PhysicalLayer (which
is provided in the BusInformation datatype) shall be used only for additional information.

– 10 – IEC TS 62453-53-90:2025 © IEC 2025
The DataLinkLayer property is not applicable for HART and shall be set to null.
5 Access to instance, device and process data
5.1 General
Used at interfaces:
• IInstanceData,
• IDeviceData, and
• IProcessData.
These interfaces shall provide access to at least all parameters defined in IEC 62453-309.
5.2 IO signals provided by DTM
A DTM shall provide IO signal information of the device using the IProcessData interface.
A HART device is connected to the process either via its analog channels or via digital
information (e.g. burst mode). Analog channels are always related to a dynamic variable, as
specified in [8] section 8, and therefore the description of an analog channel shall be accessed
using the respective dynamic variable (e.g. the attributes of dynamic variable PV always
describe the first analog channel).
HART distinguishes between three methods to access digital signals:
a) Access to analog value and assigned dynamic variables (Command #3)
IO signals can be assigned to one of the four dynamic variables PV, SV, TV, and QV. Using
the command #3 the analog value and the dynamic variables can be read without specific
device knowledge.
b) Indexed access to device variables (Command #33)
All device variable values and their units can be read using the related device variable code
information in command #33.
c) Indexed access to device variables classification and status (Command #9)
Command #9 is an extension of command #33. In addition to the value and unit, a
classification and the variable status can also be determined.
It is up to the command initiator to determine by means of the HART specification which
commands to be used.
To provide all information required to access the output signal information the DTM shall provide
the information shown in Table 2 within its HartIOSignalInfo.
___________
Numbers in square brackets refer to the Bibliography.

Table 2 – Output signal info within IOSignalInfo/HartIOSignalInfo
Attribute Description
Name Name of the IO signal
Range Reference to the variables providing range information
Unit Reference to an enumeration variable describing the unit information
DeviceVariableAssignment Constant enumeration value that can take following values
– unassigned: The IO signal is not assigned to dynamic variable and can only
be accessed using the indexed approach (reading device variables)
– PV: IO signal assigned to the PV dynamic variable
– SV: IO signal assigned to the SV dynamic variable
– TV: IO signal assigned to the TV dynamic variable
– QV: IO signal assigned to the QV dynamic variable
DeviceVariableCode Constant that specifies the device specific variable code.
Because of compatibility reasons to other FDT versions (e.g. IEC TR 62453-41),
this variable could be set to the value 252 that stands for “unknown”.

5.3 Data interfaces
5.3.1 General
Within HART, several command sets are defined. As part of the command set definition, HART
provides a precise naming convention that is documented within the sources of the standard
EDD libraries. The data provided by the access data interfaces should be named according to
the HART naming convention. For backward compatibility, the semantic IDs as defined in other
versions of FDT (e.g. IEC TR 62453-41) should also be provided by the DTM.
A DTM shall provide all device data that is related to the set of Universal Commands and should
provide all device data related to Common Practice Commands. If the device supports
additional command sets, like device family profiles, those data should also be exported using
the naming convention as defined in the HART EDD libraries and as shown in Figure 2 and
Figure 3.
5.3.2 Mapping HART datatypes to FDT datatypes
For a better usability of data provided by the data access interfaces IDeviceData and
IInstanceData, all data from the device shall be converted into datatypes that are common to
FDT. The mapping of basic datatypes is defined in Table 3.
Table 3 – Mapping of basic datatypes
HART datatype FDT datatype IEC datatype
Packed ASCII (see [8] 5.1.1) String STRING
ISO Latin-1 (see [8] 5.1.2) String STRING
Dates (see [8] 5.2) DateTime DATE_AND_TIME
Time (see [8] 5.3) ULong ULINT
(1/32 ms since midnight) (1/32 ms since midnight)
Single Precision Floating Point (see [8] 5.4) float REAL
Double Precision Floating Point (see [8] 5.4) double LREAL
1-4 Byte Unsigned Integer (see [8] 5.5) UInt UDINT
5-8 Byte Unsigned Integer (see [8] 5.5) ULong ULINT
1-4 Byte Signed Integer (see [8] 5.6) Int DINT

– 12 – IEC TS 62453-53-90:2025 © IEC 2025
HART datatype FDT datatype IEC datatype
5-8 Byte Signed Integer (see [8] 5.6) Long LINT
1-4 Byte Enumerated (see [8] 5.7.1) UInt UDINT
5-8 Byte Enumerated (see [8] 5. 7.1) ULong ULINT
1-4 Byte Bit Fields (see [8] 5.7.2) UInt UDINT
5-8 Byte Bit Fields (see [8] 5.7.2) ULong ULINT

The access to device specific data has been standardized using structures with the standard
EDD import libraries for HART. The structure uses ARRAY and COLLECTION constructs that
shall be reused when exposing data within FDT in IDeviceData and IInstanceData interfaces
with elements of type StructDataGroup.
When converting a COLLECTION into a StructDataGroup, the DataItems shall be identical to
the COLLECTION members with:
DataItem Name = COLLECTION member identifier
DataItem Label = COLLECTION member label
When converting an ARRAY into a StructDataGroup, the DataItem shall be identical to the
ARRAY element with:
DataItem Name = ARRAY element index as string
DataItem Label = ARRAY element label
An example for such a structure is presented in Figure 2 and Figure 3.
5.3.3 SemanticInfo
The SemanticInfo for HART protocol related parameters is directly related to the protocol
specification. The definition of the HART commands is the base for the parameter address
information which shall be used in the properties ParameterReadAddress,
ParameterWriteAddress and SemanticId of the SemanticInfo datatype.
The syntax of the parameter address information is as follows:
CMD[Q()]BBL
The [Q()] portion only is required to define request data.
For description of the attributes, see Table 4.
Table 4 – SemanticInfo attributes description
Attribute Datatype Description
decimal integer command number in the range of 0 to 255
hex-string request data bytes
decimal integer index of the start byte in the response data section (start index = 0)
decimal integer index of the start bit in the byte referenced by
decimal integer length of the value in bits

According to 6.4 commands with extended command number shall be described using
“CMD31Q…” wherein the first two byte of the request data section shall contain the extended
command number.
The property SemanticInfo.ApplicationDomain shall contain ‘FDT_HART’ for all parameters in
Table 5 and Table 6.
5.3.4 Data exposure using IDeviceData and IInstanceData interfaces
5.3.4.1 Export of basic device parameters
Using the HART datatype mapping rules introduced in 5.3.2 and 5.3.3 basic device parameters
defined within the Universal and Common Practice Command sets can be exported.
Basic parameters that are not accessed using index information in the request part should, for
compatibility reasons, provide additionally the SemanticInfo information specified in previous
versions of FDT. Variables are identified by their standard identifier in HART. In Table 5 all
variables are listed that shall be exported in the related data interfaces when supported by the
device. HART identifier shall be assigned to the property Data.Id. SemanticId shall be assigned
to the properties SemanticInfo.SemnaticId, SemanticInfo.ReadParameterAddress and
SemanticInfo.WriteParameterAddress.
Variables with identifiers starting with “PV.”, ”SV.”, ”TV.” and ”QV.” shall be seen as shortcuts
to variables that shall be available too using the structured exposure of device variables as
defined in 5.3.4.2.1.
Table 5 – Basic Variables exported in IDeviceData and IInstanceData interfaces
Identifier SemanticId Description
device_type CMD0B1B0L16 Expanded Device Type (see [5] Table 1, Device
Type Codes and [8], Section 6).
NOTE The information from CMD0 is also available
via IHardwareIdentification interface.
request_preambles CMD0B3B0L8 Minimum number of Preambles required for the
request message from the Master to the Slave. This
number includes the two preambles used in
asynchronous Physical Layers (along with the
Delimiter) to detect the start of message.
universal_revision CMD0B4B0L8 HART Protocol Major Revision Number implemented
by this device. For HART Revision 7, this value shall
be the number 7.
transmitter_revision CMD0B5B0L8 Device Revision Level (refer to [5])
software_revision CMD0B6B0L8 Software Revision Level of this device. Levels 254
and 255 are reserved.
hardware_revision CMD0B7B3L5 (Most Significant 5 Bits) Hardware Revision Level of
the electronics in this particular device. Does Not
Necessarily Trace Individual Component Changes.
Level 31 is Reserved.
physical_signaling_code CMD0B7B0L3 (Least Significant 3 Bits) Physical Signaling Code
(see [5] Table 10, Physical Signaling Codes)
device_flags CMD0B8B0L8 Flags (see [5] Table 11, Flag Assignments)
device_id CMD0B9B0L24 Device ID. This number shall be different for every
device manufactured with a given Device Type.
response_preambles CMD0B12B0L8 Minimum number of preambles to be sent with the
response message from the slave to the master.
max_num_device_variables CMD0B13B0L8 Maximum Number of Device Variables. This
indicates the last Device Variable code that a host
application should expect to be found in the field
device (e.g., when identifying the Device Variables
using Command #54).
config_change_counter CMD0B14B0L16 Configuration Change Counter
extended_fld_device_status CMD0B16B0L8 Extended Field Device Status (refer to [5] Table 17,
Extended Field Device Status)
– 14 – IEC TS 62453-53-90:2025 © IEC 2025
Identifier SemanticId Description
manufacturer_id CMD0B17B0L16 Manufacturer Identification Code (see [5] Table 8,
Manufacturer Identification Codes)
private_label_distributor CMD0B19B0L16 Private Label Distributor Code (see [5] Table 8,
Manufacturer Identification Codes)
device_profile CMD0B21B0L8 Device Profile (see [5] Table 57)
polling_address CMD7B0B0L8 Polling Address of Device (refer to [11])
loop_current_mode CMD7B1B0L8 Loop Current Mode (refer to [5] Table 16, Loop
Current Modes)
message CMD12B0B0L192 Message
tag CMD13B0B0L48 Tag
descriptor CMD13B6B0L96 Descriptor
date CMD13B18B0L24 Date Code
PV.SENSOR_SERIAL_NUMBER CMD14B0B0L24 Transducer Serial Number
PV.DIGITAL_UNITS CMD14B3B0L8 Transducer Limits and Minimum Span Units Code
(refer to [5])
PV.UPPER_SENSOR_LIMIT CMD14B4B0L32 Upper Transducer Limit
PV.LOWER_SENSOR_LIMIT CMD14B8B0L32 Lower Transducer Limit
PV.MINIMUM_SPAN CMD14B12B0L32 Minimum Span
PV.ALARM_CODE CMD15B0B0L8 PV Alarm Selection Code (see HCF Common
Table 6, Alarm Selection Codes). The Alarm
Selection Code indicates the action taken by the
device under error conditions. For transmitters, the
code indicates the action taken by the Loop Current.
For Actuators, the action taken by the positioner is
indicated.
PV.TRANSFER_FUNCTION CMD15B1B0L8 PV Transfer Function Code (see HCF Common
Table 3, Transfer Function Codes). The Transfer
Function Code shall return "0", Linear, if transfer
functions are not supported by the device.
PV.RANGE_UNITS CMD15B2B0L8 PV Upper and Lower Range Values Units Code
(refer to [5])
PV.UPPER_RANGE_VALUE CMD15B3B0L32 PV Upper Range Value
PV.LOWER_RANGE_VALUE CMD15B7B0L32 PV Lower Range Value
PV.DAMPING_VALUE CMD15B11B0L32 PV Damping Value (units of seconds)
write_protect CMD15B15B0L8 Write Protect Code (see [5] Table 7, Write Protect
Codes). The Write Protect Code must return "251",
None, when write protect is not implemented by a
device.
PV.ANALOG_CHANNEL_FLAGS CMD15B17B0L8 PV Analog Channel Flags (see [5] Table 26, Analog
Channel Flags)
final_assembly_number CMD16B0B0L24 Final Assembly Number
longTag CMD20B0B0L256 Long Tag
PV.DIGITAL_UNITS CMD1B0B0L8 Primary Variable Units (refer to [5])
SV.DIGITAL_UNITS CMD3B9B0L8 Secondary Variable Units Code (refer to [5])
TV.DIGITAL_UNITS CMD3B14B0L8 Tertiary Variable Units Code (refer to [5])
QV.DIGITAL_UNITS CMD3B19B0L8 Quaternary Variable Units Code (refer to [5])
Primary Variable Classification (see [5] Table 21,
PV.CLASSIFICATION CMD8B0B0L8
Device Variable Classification Codes)
SV.CLASSIFICATION CMD8B1B0L8 Secondary Variable Classification (see [5] Table 21,
Device Variable Classification Codes)
TV.CLASSIFICATION CMD8B2B0L8 Tertiary Variable Classification (see [5] Table 21,
Device Variable Classification Codes)

Identifier SemanticId Description
QV.CLASSIFICATION CMD8B3B0L8 Quaternary Variable Classification (see [5] Table 21,
Device Variable Classification Codes)
lock_device_status_code CMD76B0B0L8 Lock Status (see [5] Table 25, Lock Device Status)
last_clock_date, CMD90B7B0L24 Date clock last set
last_clock_time CMD90B10B0L32 Time clock last set
real_time_clock_flag CMD90B14B0L8 RTC Flags (see [5] Table 42)

Table 5 contains data that can also be read via other interfaces. In this case the DTM shall take
care about the consistency of the data, for example the variables which are related to CMD0
shall be identical to the HartDeviceScanInfo data, which can be read via the IHardwareScan
interface.
Table 6 lists all basic device variables that shall be exported only within IDeviceData interface
if supported by the device.
Table 6 – Basic Variables exported only in IDeviceData interface
Identifier SemanticId Description
device_status -/- Device status information transferred with each
(empty) reply. Due to the fact that device_status is
accessible by standard means in each transaction,
the semantic id is empty
PV.DIGITAL_VALUE CMD1B1B0L32 Primary Variable
PV.ANALOG_VALUE CMD2B0B0L32 Primary Variable Loop Current (units of milli
amperes)
PV.PERCENT_RANGE CMD2B4B0L32 Primary Variable Percent of Range (units of
percent)
PV.DIGITAL_VALUE CMD3B5B0L32 Primary Variable
SV.DIGITAL_VALUE CMD3B10B0L32 Secondary Variable
TV.DIGITAL_VALUE CMD3B15B0L32 Tertiary Variable
QV.DIGITAL_VALUE CMD3B20B0L32 Quaternary Variable
current_date CMD90B0B0L24 Current Date
current_time CMD90B3B0L32 Current Time of Day

5.3.4.2 Export of structural information
5.3.4.2.1 Device variables
In addition to the measurement values provided by dynamic variables, there exists information
in the device that is related to the dynamic variable (e.g. range information, linearization
functions). In HART several categories of such information are defined, and standardized
means are available that allow to document such relationships in a way that a client can access
and analyze the structure without device specific knowledge. This information shall be exported
in the IDeviceData and IInstanceData interfaces using StructDataGroup elements as mentioned
in 5.3.2.
The DTM shall expose information in the structure as shown in Figure 2 and Figure 3.

– 16 – IEC TS 62453-53-90:2025 © IEC 2025

Figure 2 – Structural information for device variables

Figure 3 – Structural information for dynamic variables
Future changes to the structure shall be similarly reflected.
5.3.4.2.2 Device specific status
HART supports two types of s
...