IEC 62453-309:2022

IEC 62453-309 ®
Edition 3.0 2022-09
REDLINE VERSION
INTERNATIONAL
STANDARD
colour
inside
Field device tool (FDT) interface specification –
Part 309: Communication profile integration – 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. With a subscription you will always
committee, …). It also gives information on projects, replaced have access to up to date content tailored to your needs.
and withdrawn publications.
Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished
The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published
containing more than 22 300 terminological entries in English
details all new publications released. Available online and
and French, with equivalent terms in 19 additional languages.
once a month by email.
Also known as the International Electrotechnical Vocabulary

(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc

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 62453-309 ®
Edition 3.0 2022-09
REDLINE VERSION
INTERNATIONAL
STANDARD
colour
inside
Field device tool (FDT) interface specification –
Part 309: Communication profile integration – IEC 61784 CPF 9
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 25.040.40; 35.100.05; 35.110 ISBN 978-2-8322-5665-7

– 2 – IEC 62453-309:2022 RLV  IEC 2022
CONTENTS
FOREWORD . 5
INTRODUCTION . 2
1 Scope . 8
2 Normative references . 8
3 Terms, definitions, symbols, abbreviated terms and conventions . 9
3.1 Terms and definitions. 9
3.2 Abbreviated terms . 9
3.3 Conventions . 9
3.3.1 Data type names and references to data types . 9
3.3.2 Vocabulary for requirements . 9
3.3.3 Use of UML . 9
4 Bus category . 10
5 Access to instance and device data . 11
5.1 General . 11
5.2 Process Channel objects provided by DTM . 11
5.3 DTM services to access instance and device data . 12
6 Protocol-specific behavior . 12
6.1 Overview . 12
6.2 Burst mode subscription. 12
6.3 Usage of device addressing information . 13
6.4 Extended Command Numbers . 14
6.5 Handling of communication failures and time-outs. 14
6.6 Handling of delayed responses . 15
6.7 Topologies with mixed HART protocols . 16
6.7.1 General . 16
6.7.2 Behavior of DTMs supporting ‘Extended_HART’ only . 16
6.7.3 Behavior of DTMs supporting ‘Extended_HART’ and ‘HART_Basic’ . 17
6.7.4 Behavior of DTMs that require ‘Extended_HART’ or ‘HART_Basic’ . 17
6.8 Nested communication with multiple gateways . 18
6.9 Communication- and network structures in WirelessHART . 19
6.9.1 General . 19
6.9.2 Network topology . 19
7 Protocol-specific usage of general data types . 23
8 Protocol-specific common data types . 24
9 Network management data types . 24
9.1 General . 24
9.2 Addressing modes . 24
9.3 Address information . 24
9.4 Additional address information for ‘Extended HART’ protocols . 24
10 Communication data types . 26
10.1 General . 26
10.2 Protocol-specific Addressing Information . 27
10.3 Datatype definitions . 27
11 Channel parameter data types . 32
12 Device identification . 34

12.1 Protocol-specific handling of data type STRING . 34
12.2 Address Range for Scan . 34
12.3 Support for Extended Manufacturer and Device Type Code . 35
12.4 Device type identification data types for protocol ‘HART_Basic’ . 35
12.5 Common device type identification data types for ‘Extended_HART’

protocols . 39
12.6 Topology scan data types . 43
12.7 Scan identification data types for protocol ‘HART_Basic’ . 44
12.8 Scan identification data types for ‘Extended_HART’ protocols . 46
12.9 Device type identification data types – provided by DTM . 48
Bibliography . 50

Figure 1 – Part 309 of the IEC 62453 series . 7
Figure 2 – Burst mode subscription . 13
Figure 3 – Handling of delayed responses (scenario 1) . 15
Figure 4 – Handling of delayed responses (scenario 2) . 16
Figure 5 – Behavior of DTMs supporting ‘Extended_HART’ and ‘HART_Basic’ . 17
Figure 6 – Behavior of DTMs requires ‘Extended_HART’ or ‘HART_Basic’ . 18
Figure 7 – Host connected to a WirelessHART gateway device . 20
Figure 8 – FDT Topology of a WirelessHART network . 21
Figure 9 – Host connected to HART FSK . 22
Figure 10 – FDT Topology when directly connected to a WirelessHART adapter device . 22

Table 1 – Protocol identifiers . 10
Table 2 – Definition of PhysicalLayer . 10
Table 3 – Protocol specific usage of general data types . 23
Table 4 – Relation of ProtocolId and supported features . 24
Table 5 – Simple address information data types . 25
Table 6 – Structured address information data types . 26
Table 7 – Simple communication data types . 28
Table 8 – Structured communication data types . 29
Table 9 – Simple channel parameter data types . 32
Table 10 – Structured channel parameter data types . 33
Table 11 – Address range for device identification . 35
Table 12 – Identification data types with protocol-specific mapping for protocol

‘HART_Basic’ . 36
Table 13 – Identification data types with semantics for protocol ‘HART_Basic’ . 38
Table 14 – Simple identification data types for protocol ‘HART_Basic’ with protocol
independent semantics . 39
Table 15 – Structured identification data types for protocol ‘HART_Basic’ with protocol
independent semantics . 39
Table 16 – Identification data types for ‘Extended_HART’ protocols with protocol-
specific mapping . 40
Table 17 – Identification data types for ‘Extended_HART’ protocols without protocol
independent semantics . 42

– 4 – IEC 62453-309:2022 RLV  IEC 2022
Table 18 – Simple identification data types for ‘Extended_HART’ protocols with
protocol independent semantics . 43
Table 19 – Structured identification data types for ‘Extended_HART’ protocols with

protocol independent semantics . 43
Table 20 – Structured device type identification data types . 44
Table 21 – Simple scan identification data types for protocol ‘HART_Basic’ . 44
Table 22 – Structured scan identification data types for protocol ‘HART_Basic’ . 45
Table 23 – Simple scan identification data types for ‘Extended_HART’ protocols . 46
Table 24 – Structured scan identification data types for ‘Extended_HART’ protocols. 47
Table 25 – Structured device type identification data types . 49

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

Part 309: Communication profile integration –
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) 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 IEC 62453-309:2016. 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 62453-309:2022 RLV  IEC 2022
IEC 62453-309 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 an International Standard.
This third edition cancels and replaces the second edition published in 2016. This edition
constitutes a technical revision.
This edition includes the following significant technical changes with respect to the previous
edition:
• corrections in regard to accessing information in the respective device and
• corrections in regard to describing support for different protocol versions.
The text of this International Standard is based on the following documents:
Draft Report on voting
65E/907/FDIS 65E/936/RVD
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 International Standard is English.
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.
Each part of the IEC 62453-3xy series is intended to be read in conjunction with IEC 62453‑2.
A list of all parts of the IEC 62453 series, 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,
• replaced by a revised edition, or
• amended.
IMPORTANT – The "colour inside" logo on the cover page of this document 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.

INTRODUCTION
This part of IEC 62453 is an interface specification for developers of FDT (Field Device Tool)
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 fieldbusses 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 DTM (Device Type Manager), 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 IEC 62453-309 is aligned in the structure of the IEC 62453 series.

Figure 1 – Part 309 of the IEC 62453 series

___________
FDT® is a trademark of products supplied by FDT Group AISBL. 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.

– 8 – IEC 62453-309:2022 RLV  IEC 2022
FIELD DEVICE TOOL (FDT) INTERFACE SPECIFICATION –

Part 309: Communication profile integration –
IEC 61784 CPF 9
1 Scope
Communication Profile Family 9 (commonly known as HART® ) defines communication profiles
based on IEC 61158-5-20 and IEC 61158-6-20. The basic profile CP 9/1 is defined in
IEC 61784-1.
This part of IEC 62453 provides information for integrating the HART® technology into the FDT
standard (IEC 62453-2).
This part of the IEC 62453 specifies communication and other services.
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 61158-5-20, Industrial communication networks – Fieldbus specifications – Part 5-20:
Application layer service definition – Type 20 elements
IEC 61158-6-20, Industrial communication networks – Fieldbus specifications – Part 6-20:
Application layer protocol specification – Type 20 elements
IEC 61784-1, Industrial communication networks – Profiles – Part 1: Fieldbus profiles
, Field device tool (FDT) interface specification – Part 1: Overview and
IEC 62453-1:–
guidance
IEC 62453-2:– , Field device tool (FDT) interface specification – Part 2: Concepts and detailed
description
___________
HART® and WirelessHART® are trade names of products supplied by HART Communication Foundation
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.
To be published concurrently with this standard. Under preparation. Respective stage at the time of publication:
IEC/CCDV 62453-1:2022 and IEC/RFDIS 62453-2:2022.

3 Terms, definitions, symbols, abbreviated terms and conventions
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 62453-1 and
IEC 62453-2, as well as the following apply.
ISO and IEC maintain terminology 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
burst mode
mode in which the field device generates response telegrams without request telegram from
the master
3.2 Abbreviated terms
For the purposes of this document, the abbreviations given in IEC 62453-1, IEC 62453-2, as
well as the following apply.
BACK Burst ACKnowledge
C8PSK Coherent 8-way Phase Shift Keying,
HART communication layer as defined in HCF_SPEC-60, Revision 1.0
DR delayed response
EDD Electronic Device Description
FSK Frequency Shift Keying,
HART communication layer as defined in HCF_SPEC-54, Revision 8.1
HART Highway Addressable Remote Transducer
3.3 Conventions
3.3.1 Data type names and references to data types
The conventions for naming and referencing of data types are explained in IEC 62453-2:–,
Clause A.1.
3.3.2 Vocabulary for requirements
The following expressions are used when specifying requirements:
Usage of “shall” or “mandatory” No exceptions allowed.
Usage of “should” or Strong recommendation. It may make sense in special
“recommended” exceptional cases to differ from the described
behaviour.
Usage of “can’ or “optional’ Function or behaviour may be provided, depending on
defined conditions.
3.3.3 Use of UML
Figures in this document are using UML notation as defined in IEC 62453-1:–, Annex A.

– 10 – IEC 62453-309:2022 RLV  IEC 2022
4 Bus category
IEC 61784 CPF 9 protocol is identified in the protocolId element of structured data type
'fdt:BusCategory' by the following unique identifiers (see Table 1):
Table 1 – Protocol identifiers
Identifier value ProtocolId Display String Description
036D1498-387B-11D4-86E1- HART_Basic ‘HART’ Support of IEC 61784 CPF 9 protocol
00E0987270B9 over FSK communication with basic
functionality (deprecated)
98503B8F-0FFB-4EB7-BB67- HART_FSK ‘HART FSK’ Support of HART protocol over FSK
F4D6BD16DB8D communication with complete
functionality
74D29D22-F752-40EF-A747- HART_Wireless ‘HART Wireless’ Support of WirelessHART protocol
ACA72C791155
58001A08-C178-4A59-A76B- HART_RS485 ‘HART RS485’ Support of HART protocol over RS485
9EF9111CB83D communication
EF708CB7-A2A1-42AF-890C- HART_Infrared ‘HART Infrared’ Support of HART protocol over Infrared
15CEB680CC12 communication
D122D172-F0C7-4B03-965B- HART_IP ‘HART IP’ Support of HART over IP protocol
512CD4C0871E
The ‘HART_Basic’ protocol is maintained for backward compatibility only (e.g. for interaction
with DTMs according to IEC 62453-309:2009). The other protocol identifiers provide a better
support for planning of network topologies and for establishment of connections between DTM
and respective device. For DTMs complying with this document, support for one of the other
protocols is mandatory.
Within this document, the other protocols (HART_FSK, HART_Wireless, HART_RS485,
HART_Infrared, HART_IP) are referenced as ‘Extended_HART’ protocols. (E.g. for definitions
that apply to all protocols except ‘HART_Basic’.)
Table 2 defines which PhysicalLayer can be used together with the BusCategory defined in
Table 1.
Table 2 – Definition of PhysicalLayer
PhysicalLayer Id value PhysicalLayer name value Description
BAB2091A-C0A7-4614-B9DE- HART FSK Physical Layer Support of HART FSK physical
FCC2709DCF5D layer
B9F1A250-AC94-4487-8F25-A8F3F8F89DC5 WirelessHART Physical Support of WirelessHART
Layer physical layer
036D1591-387B-11D4-86E1-00E0987270B9 HART RS-485 Physical Layer Support of HART devices
using RS-485 communication
AE4119EF-B9FD-429c-B244-134DB182296A HART Infrared Physical Support of HART devices
Layer using infrared communication
307dd808-c010-11db-90e7-0002b3ecdcbe 10BASET HART Ethernet based Physical
Layers
307dd809-c010-11db-90e7-0002b3ecdcbe 10BASETXHD
307dd80a-c010-11db-90e7-0002b3ecdcbe 10BASETXFD
307dd80b-c010-11db-90e7-0002b3ecdcbe 10BASEFLHD
307dd80c-c010-11db-90e7-0002b3ecdcbe 10BASEFLFD
307dd80d-c010-11db-90e7-0002b3ecdcbe 10BASEFXHD
307dd80e-c010-11db-90e7-0002b3ecdcbe 10BASEFXFD

PhysicalLayer Id value PhysicalLayer name value Description
307dd80f-c010-11db-90e7-0002b3ecdcbe 100BASETXHD
307dd810-c010-11db-90e7-0002b3ecdcbe 100BASETXFD
307dd811-c010-11db-90e7-0002b3ecdcbe 100BASEFXHD
307dd812-c010-11db-90e7-0002b3ecdcbe 100BASEFXFD
307dd813-c010-11db-90e7-0002b3ecdcbe 100BASELX10
307dd814-c010-11db-90e7-0002b3ecdcbe 100BASEPX10
307dd815-c010-11db-90e7-0002b3ecdcbe 1000BASEXHD
307dd816-c010-11db-90e7-0002b3ecdcbe 1000BASEXFD
307dd817-c010-11db-90e7-0002b3ecdcbe 1000BASELXHD
307dd818-c010-11db-90e7-0002b3ecdcbe 1000BASELXFD
307dd819-c010-11db-90e7-0002b3ecdcbe 1000BASESXHD
307dd81a-c010-11db-90e7-0002b3ecdcbe 1000BASESXFD
307dd81b-c010-11db-90e7-0002b3ecdcbe 1000BASETHD
307dd81c-c010-11db-90e7-0002b3ecdcbe 1000BASETFD
307dd81d-c010-11db-90e7-0002b3ecdcbe 10GigBASEFX

The significant information for topology planning is the BusCategory. The PhysicalLayer (which
is provided in the BusInformation data type) shall be used only for additional information.
The DataLinkLayer property is not applicable for HART and has to shall be set to null.
5 Access to instance and device data
5.1 General
The HART protocol has semantics defined that allow in a wide range the identification of device
variables and device parameters. Most of this semantic information is defined in the standard
EDD import libraries.
Clause 5 describes how the semantic information defined with the HART protocol shall be used
to export device data, instance data and process data.
5.2 Process Channel objects provided by DTM
The minimum set of provided data shall be the first four provided process related values (PV,
SV, …) – if available – modeled as channel references. The referenced channel shall include
ranges and scaling.
A HART device communicates the process data either via its analogue channels or via digital
information (e.g. by request or by burst mode). Analogue channels are always related to a
dynamic variable, as specified in [1] chapter 8 and therefore the description of an analogue
channel has to shall be accessed using the respective dynamic variable (e.g. the attributes of
dynamic variable PV always describe the first analogue channel).
___________
Figures in square brackets refer to the bibliography.

– 12 – IEC 62453-309:2022 RLV  IEC 2022
HART distinguishes between three methods to access digital signals:
1) Access to analogue 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 analogue value and the dynamic variables can be read without specific
device knowledge.
2) Indexed access to device variables (Command #33)
All device variable values and their units can be read using the related index device variable
code information in command #33. Up to four device variables can be read with one call of
command #33. It is up to the command initiator to identify the requested variable using the
related index information.
3) Indexed access to device variable classification and device variable status (Command #9)
Command #9 is an extension of provides more information than command #33. Beside of
the value and unit also a classification and the variable status can be determined. The status
information contains data quality, limit status, and device family status.
The command initiator determines by means of the HART specification which commands will
be used.
5.3 DTM services to access instance and device data
The services InstanceDataInformation and DeviceDataInformation shall provide access to at
least all parameters of the Universal and Common Practice commands (as far as the device
supports the function).
Furthermore, the Response Byte 0 and the Response Byte 1 for each command shall be
exposed.
The services InstanceDataInformation and DeviceDataInformation may also provide access to
device specific parameters (e.g. diagnostic information).
6 Protocol-specific behavior
6.1 Overview
There is only one protocol-specific sequence defined for IEC 61784 CPF 9: burst mode
subscription.
This sequence explains how the sequence “Device initiated data transfer”, defined in
IEC 62453-2, is applied in context of burst telegrams as defined by IEC 61784 CPF 9.
Additionally, Clause 6 provides information regarding:
• usage of device addressing information,
• support of extended command codes,
• handling of communication failures,
• handling of delayed responses, and
• management of physical topologies.
6.2 Burst mode subscription
A subscription to device-initiated data transfer can be requested by sending a transaction
request with SubscribeRequest content (see Figure 2). The Communication Channel may
detect if the device is already in burst mode.

NOTE In HART 5 this can be detected only when burst frames are received from the device. In HART 6 the burst
mode can be detected using command #105.
The Communication Channel answers to a SubscribeRequest with a SubscribeResponse
content. If burst frames are received, the device is in burst mode and burstModeDetected value
is set to TRUE. This means that Device DTM will start to receive burst messages via the
transaction response mechanism. In the case that no burst messages were received,
burstModeDetected value is set to FALSE. It is up to Device DTM to set device into burst mode.
Then Device DTM may call a transaction request with SubscribeRequest content again in order
to receive burst messages.
In order to unsubscribe, the Device DTM sends a transaction request with a
UnsubcribeRequest. The Communication Channel answers with a UnsubscribeResponse where
burstModeDetected value is set to FALSE. The Device DTM will not receive any more burst
information via the transaction response mechanism. The Communication Channel does not
switch off the burst mode in the device. The Device DTM may switch burst mode on or off by
using normal transaction requests (command #109). This is independent of the subscription.

NOTE BACK means Burst ACKnowledge.
Figure 2 – Burst mode subscription
6.3 Usage of device addressing information
HART is a connectionless master/slave protocol. Transaction requests are always addressed
using unique device address information (a 5 byte integer), the so called long address.
Device addressing in HART therefore is mainly focused to determine this long address.
There are currently three ways possible to determine the long address.
1) short address
The short address is a number between 0 and 63 (for HART version 5 only 0 to 15). In the
context of a direct connection to the device the short address is unique and allows to read
the long address using command #0.
2) short tag
With command #11 the long address information can be requested for a device with a
specific short tag. Such requests are especially used for installations with a huge amount of

– 14 – IEC 62453-309:2022 RLV  IEC 2022
connected HART devices. All HART multiplexer devices and other HART communication
structures have to shall support this command.
3) long tag
Since HART version 6 the long tag was introduced. The long tag can store more information.
For devices with HART version less than 6 instead of long tag, message is used. With
command 21 a similar method to determine the long address is possible. Command 21 is
usually supported by highly modular devices or Gateways.
HART Version 6 introduced the long tag, which at 32 characters has 24 more characters
than the short tag, and can thus provide for a larger number of device label options. For
devices with HART version less than 6 instead of long tag, message is used. With command
#21 the long address information can be requested for a device with a specific long tag.
Command #21 is usually supported by highly modular devices or gateways.
A Device DTM is responsible to provide and store all information that is used for resolving the
long address of a connected device. The support of the addressing methods depends on the
type of DTM:
• DTMs that only have ‘HART’ protocol defined as required protocol support the device
addressing using the short address only. This information is managed according to the
description in 9.3.
• DTMs that have at least one of the ‘Extended_HART’ protocols defined as required protocol
use the storage of the short tag for compatibility reason like described in 9.3, but also store
additionally required information as defined in 9.4.
It has therefore to maintain the data for all three address resolving methods. The DTM
responsible to connect to the communication hardware shall select the method and provide
means for a user to input the address information.
Besides the addressing topic, there are also different approaches for manufacturer and device
type identification depending on the supported version of HART. HART versions up to HART 6
use one byte values. HART versions starting from HART 7 (and newer) use a two byte value.
The two byte values are also stored in the data types described in 9.4.
A Communication DTM uses the addressing information provided by the Device DTM in order
to resolve the long address as described above.
6.4 Extended Command Numbers
The HART command number is defined as a one byte unsigned integer. When starting with the
specification of device family commands for HART, 6 HCF started to define extended command
number for better specification clarity. Extended command numbers are applied only for device
family commands defined by HART. Beginning with HART Version 6, an extended command
number format, using two bytes instead of one, was defined to allow for more than 255
command numbers. This format uses command number 31, which was previously reserved, to
indicate that the request is using the extended command number format.
According to the specification in [2] 8.1.2, extended commands are implemented with command
#31 by using the extended command number as first two bytes in the request and response
section.
In FDT, all commands with extended command numbers have to shall be implemented by the
Child DTM using command #31.
6.5 Handling of communication failures and time-outs
HART uses a device-specific handling of communication errors. The protocol defines a section
in the response frame that can carry communication failure information.

If, during execution of a communication request to a Communication Channel, a communication
error occurs on the HART physical layers (this also includes time-outs), no Abort message shall
be sent to the Child DTM, but the transaction request shall be responded with a set of data that
describes the communication error as defined in HART [1].
In case of such a communication failure, the Device DTM has the responsibility to perform the
error handling to recover from the communication failure.
Only in case of a connection-based communication break (e.g. Ethernet connection to a HART
modem), the Communication Channel shall send an Abort signal to the device DTM.
6.6 Handling of delayed responses
HART defines strict time constraints for responses to a request within a HART transaction. In
case a device is unable to fulfill the time constraints, it can initiate a delayed response (DR)
sequence. In order to support DR handling within nested communication, Subclause 6.6 defines
the handling within FDT.
The responsibility to handle the DR responses from the device is located at the DTM that
represents the device. The Communication DTM and Gateway DTMs (if used) have to shall
ensure that DR responses are communicated correctly to the respective DTM. An example for
such a delayed response handling is shown in Figure 3.

Figure 3 – Handling of delayed responses (scenario 1)
It is also possible that the two partners of a DR sequence are both devices. For example, a
gateway device (e.g. WirelessHART Gateway) might execute a delayed response sequence
with a child device (e.g. WirelessHART Adapter). In this case, the gateway device is responsible
to handle the DR of the child device. The delayed responses will not reach the respective Child
DTM. If the gateway device is unable to handle the DR directly, the gateway device itself could
send DRs to the Gateway DTM. In such a case, the DRs would have to be handled by the
respective Gateway DTM. Usually, the nested communication concept reflects the interaction
between the devices. In the case described here, this is not possible and the implementation
has to shall follow the sequence shown in Figure 4.

– 16 – IEC 62453-309:2022 RLV  IEC 2022

Figure 4 – Handling of delayed responses (scenario 2)
A DR sequence might take a long time that might disturb the usage of the FDT Frame
Application and that might block user interaction. There is no timeout time definition existing for
DR sequences and neither the DTM itself nor any other DTM in the nested communication chain
is capable to initiate a timeout that could recover the system. Timeout time in such a case is
application-dependent and shall be configurable by the user. When a DR sequence lasts an
unreasonable amount of time, it shall be an aim to involve the user. If a DR sequence is used
in a user interface, free environments then configurable timeout mechanisms shall be
implemented.
To handle DR responses with a reliable interoperability, the following rules have to shall be
fulfilled:
• The DTM of a device that might send DR responses has to shall handle the DR responses
of the device.
• DR responses that are not handled by other devices have to shall be propagated to the DTM
that represents the device that sends the responses.
• A DTM shall be aware that it will not receive DR responses from the device, when the DR
responses are handled by the parent device.
• A DTM that handles DR responses has to shall implement a user configurable timeout
management that must allow the user to set a timeout.
6.7 Topologies with mixed HART protocols
6.7.1 General
HART DTMs using ‘Extended_HART’ protocols may also support the ‘HART_Basic’ protocol, in
order to ensure compatibility with existing HART DTMs.
‘Extended_HART’ protocols were defined for better distinction between the different HART
communication types. Using ‘Extended_HART’ and ‘HART_Basic’ protocols at the same time
needs well defined processes to guarantee interoperability.
6.7.2 Behavior of DTMs supporting ‘Extended_HART’ only
The topology validation is performed by the Frame Application (reference). If the
Communication Channel receives a call to ValidateAddChild(), it has to shall verify whether the
given device type requires a suitable protocolId.

The behavior of such a DTM in a ValidateAddChild call is:
• If a match cannot be found, the ValidateAddChild() call shall be answered with FALSE.
• If a match was found, the ValidateAddChild() call shall be answered with TRUE. During the
call to OnAddChild(), the Parent DTM sets the activeProtolID in the Child DTM to the current
protocolId.
6.7.3 Behavior
...