IEC 62453-309:2016

IEC 62453-309 ®
Edition 2.0 2016-06
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Field device tool (FDT) interface specification –
Part 309: Communication profile integration – IEC 61784 CPF 9

Spécification des interfaces des outils des dispositifs de terrain (FDT) –
Partie 309: Intégration des profils de communication – CPF 9 de l'IEC 61784

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.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite
ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie
et les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
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 corrigenda or an amendment might have been published.

IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing 20 000 terms and definitions in
Technical Specifications, Technical Reports and other English and French, with equivalent terms in 15 additional
documents. Available for PC, Mac OS, Android Tablets and languages. Also known as the International Electrotechnical
iPad. Vocabulary (IEV) online.

IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a 65 000 electrotechnical terminology entries in English and
variety of criteria (reference number, text, technical French extracted from the Terms and Definitions clause of
committee,…). It also gives information on projects, replaced IEC publications issued since 2002. Some entries have been
and withdrawn publications. collected from earlier publications of IEC TC 37, 77, 86 and

CISPR.
IEC Just Published - webstore.iec.ch/justpublished

Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: csc@iec.ch.
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.

Catalogue IEC - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
Application autonome pour consulter tous les renseignements
Le premier dictionnaire en ligne de termes électroniques et
bibliographiques sur les Normes internationales,
électriques. Il contient 20 000 termes et définitions en anglais
Spécifications techniques, Rapports techniques et autres
et en français, ainsi que les termes équivalents dans 15
documents de l'IEC. Disponible pour PC, Mac OS, tablettes
langues additionnelles. Egalement appelé Vocabulaire
Android et iPad.
Electrotechnique International (IEV) en ligne.

Recherche de publications IEC - www.iec.ch/searchpub
Glossaire IEC - std.iec.ch/glossary
La recherche avancée permet de trouver des publications IEC 65 000 entrées terminologiques électrotechniques, en anglais
en utilisant différents critères (numéro de référence, texte, et en français, extraites des articles Termes et Définitions des
comité d’études,…). Elle donne aussi des informations sur les publications IEC parues depuis 2002. Plus certaines entrées
projets et les publications remplacées ou retirées. antérieures extraites des publications des CE 37, 77, 86 et

CISPR de l'IEC.
IEC Just Published - webstore.iec.ch/justpublished

Service Clients - webstore.iec.ch/csc
Restez informé sur les nouvelles publications IEC. Just
Published détaille les nouvelles publications parues. Si vous désirez nous donner des commentaires sur cette
Disponible en ligne et aussi une fois par mois par email. publication ou si vous avez des questions contactez-nous:
csc@iec.ch.
IEC 62453-309 ®
Edition 2.0 2016-06
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Field device tool (FDT) interface specification –

Part 309: Communication profile integration – IEC 61784 CPF 9

Spécification des interfaces des outils des dispositifs de terrain (FDT) –

Partie 309: Intégration des profils de communication – CPF 9 de l'IEC 61784

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
INTERNATIONALE
ICS 25.040.40; 35.100.05; 35.110 ISBN 978-2-8322-3464-8

– 2 – IEC 62453-309:2016  IEC 2016
CONTENTS
FOREWORD . 5
INTRODUCTION . 7
1 Scope . 8
2 Normative references. 8
3 Terms, definitions, symbols, abbreviated terms and conventions. 8
3.1 Terms and definitions . 8
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 . 9
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 . 14
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’ . 16
6.7.4 Behavior of DTMs that requires ‘Extended_HART’ or ‘HART’ . 17
6.8 Nested communication with multiple gateways . 18
6.9 Communication- and network structures in WirelessHART . 18
6.9.1 General . 18
6.9.2 Network topology . 19
7 Protocol-specific usage of general data types . 21
8 Protocol-specific common data types . 22
9 Network management data types . 22
9.1 General . 22
9.2 Addressing modes . 22
9.3 Address information . 23
9.4 Additional address information for ‘Extended HART’ protocols . 23
10 Communication data types . 25
10.1 General . 25
10.2 Protocol-specific Addressing Information . 26
10.3 Datatype definitions . 26
11 Channel parameter data types . 30
12 Device identification . 33

12.1 Protocol-specific handling of data type STRING . 33
12.2 Address Range for Scan . 33
12.3 Support for Extended Manufacturer and Device Type Code . 33
12.4 Device type identification data types for protocol ‘HART’ . 33
12.5 Common device type identification data types for ‘Extended_HART’
protocols . 37
12.6 Topology scan data types . 42
12.7 Scan identification data types for protocol ‘HART’ . 43
12.8 Scan identification data types for ‘Extended_HART’ protocols . 45
12.9 Device type identification data types – provided by DTM . 47
Bibliography . 49

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

Table 1 – Protocol identifiers . 9
Table 2 – Definition of PhysicalLayer . 10
Table 3 – Protocol specific usage of general data types . 22
Table 4 – Relation of ProtocolId and supported features . 23
Table 5 – Simple address information data types . 24
Table 6 – Structured address information data types . 25
Table 7 – Simple communication data types . 26
Table 8 – Structured communication data types . 28
Table 9 – Simple channel parameter data types . 31
Table 10 – Structured channel parameter data types . 31
Table 11 – Address range for device identification . 33
Table 12 – Identification data types with protocol-specific mapping for protocol ‘HART’ . 34
Table 13 – Identification data types with semantics for protocol ‘HART’ . 36
Table 14 – Simple identification data types for protocol ‘HART’ with protocol
independent semantics . 37
Table 15 – Structured identification data types for protocol ‘HART’ with protocol
independent semantics . 37
Table 16 – Identification data types for ‘Extended_HART’ protocols with protocol-
specific mapping . 38
Table 17 – Identification data types for ‘Extended_HART’ protocols without protocol
independent semantics . 41
Table 18 – Simple identification data types for ‘Extended_HART’ protocols with
protocol independent semantics . 42

– 4 – IEC 62453-309:2016  IEC 2016
Table 19 – Structured identification data types for ‘Extended_HART’ protocols with
protocol independent semantics . 42
Table 20 – Structured device type identification data types . 43
Table 21 – Simple scan identification data types for protocol ‘HART’ . 43
Table 22 – Structured scan identification data types for protocol ‘HART’ . 43
Table 23 – Simple scan identification data types for ‘Extended_HART’ protocols . 45
Table 24 – Structured scan identification data types for ‘Extended_HART’ protocols . 45
Table 25 – Structured device type identification data types . 47

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.
International Standard 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.
This second edition cancels and replaces the first edition published in 2009, and constitutes a
technical revision. The main changes are provided in order to provide improved support for
updates of the HART protocol (see 6.7 and the updated datatypes in Clauses 9, 10, and 12)
and to support introduction of the technology according to IEC 62453-42 [1] (see Clause 4).
Each part of the IEC 62453-3xy series is intended to be read in conjunction with IEC 62453-2.

– 6 – IEC 62453-309:2016  IEC 2016
The text of this standard is based on the following documents:
CDV Report on voting
65E/336/CDV 65E/395A/RVC
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 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 publication will remain unchanged until
the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data
related to the specific publication. At this date, the publication 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.
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.
Part 309
Communication
profile integration -
IEC 61784 CPF 9
IEC
Figure 1 – Part 309 of the IEC 62453 series

– 8 – IEC 62453-309:2016  IEC 2016
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 standard neither contains the FDT specification nor modifies it.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. 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
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
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.
—————————
HART ® is the trade name of the product supplied by HART Communication Foundation. 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.

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
“recommended” special 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.
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 ‘HART’ Support of IEC 61784 CPF 9
00E0987270B9 protocol
98503B8F-0FFB-4EB7-BB67- HART_FSK ‘HART FSK’ Support of HART protocol over
F4D6BD16DB8D FSK communication
74D29D22-F752-40EF-A747- HART_Wireless ‘HART Wireless’ Support of WirelessHART protocol
ACA72C791155
– 10 – IEC 62453-309:2016  IEC 2016
Identifier value ProtocolId Display String Description
58001A08-C178-4A59-A76B- HART_RS485 ‘HART RS485’ Support of HART protocol over
9EF9111CB83D RS485 communication
EF708CB7-A2A1-42AF-890C- HART_Infrared ‘HART Infrared’ Support of HART protocol over
15CEB680CC12 Infrared communication
D122D172-F0C7-4B03-965B- HART_IP ‘HART IP’ Support of HART over IP protocol
512CD4C0871E
The ‘HART’ protocol is maintained for backward compatibility only (e.g. for interaction with
DTMs according to IEC 62453-309 Ed.1.0). 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’.)
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 using
Layer 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
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

PhysicalLayer Id value PhysicalLayer name value Description
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 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 – are 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. burst mode). Analogue channels are always related to a dynamic variable, as
specified in [3] chapter 8 and therefore the description of an analogue channel has to be
accessed using the respective dynamic variable (e.g. the attributes of dynamic variable PV
always describe the first analogue channel).
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
information in command #3. 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 variables classification and status (Command #9)
Command #9 is an extension of 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.
—————————
Figures in square brackets refer to the bibliography.

– 12 – IEC 62453-309:2016  IEC 2016
5.3 DTM services to access instance and device data
The services InstanceDataInformation and DeviceDataInformation shall provide access to at
least to 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.

Device DTM Communication Channel Device
TransactionRequest()
Subscribe request for device
initialized transaction mode
Communication
[*] BACK response
Channel detects
Get information about active
burst frames
OnTransactionResponse()
burst mode
(subscription mode ’on’
[*] BACK response
Receives burst frames via
[*] OnTransactionResponse
transaction responses
without requests
TransactionRequest()
Unsubscribe request and
Device remains
response about concluded
in burst mode
device initialized transaction
mode
OnTransactionResponse()
IEC
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 3 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 tag. Such requests are especially used for installations with a huge amount of
connected HART devices. All HART multiplexer devices and other HART
communication structures have to 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.
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.
– 14 – IEC 62453-309:2016  IEC 2016
• 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.
Besides of 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.
According to the specification in [3] 7.2.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 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 [3].
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 ensure
that DR responses are communicated correctly to the respective DTM. An example for such a
delayed response handling is shown in Figure 3.

Child Device Gateway Device Gateway DTM Child DTM
Initiate
Communication
loop repeat until DR sequence is finished

Request

Request
Response (DR)
Response

(DR)
Gateway DTM unwraps
original DR response and
No special DR handling is implemented in
sends it to Child DTM
Gateway Device. Response contains wrapped

DR response from Child Device.
IEC
Figure 3 – Handling of Delayed Reponses (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 follow the sequence shown in Figure 4.
Child Device Gateway Device Gateway DTM Child DTM
Initiate
Communication

loop repeat until DR sequence is finished
Request
Request
Response (DR)
Response (DR)
(DR)

IEC
Figure 4 – Handling of Delayed Reponses (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
Communication Infrastructure
Communication Infrastructure
System Boundary
S
...