(英文) HART数据链路层规范 SPEC 081 PDF

HART Communication Foundation Document Number: HCF_SPEC-81
HART -SMART Communication Protocol: Data Link Layer Specification
Table of Contents
1. INTRODUCTION AND OVERVIEW.............................................................................................5
1.1 Scope....................................................................................................................................5
1.2 Organization.........................................................................................................................5
1.3 Functional Requirements......................................................................................................5
1.3.1 Application Environment......................................................................................5
1.3.2 Device Types........................................................................................................6
1.4 References............................................................................................................................6
2. SERVICE AND PROTOCOL SPECIFICATIONS..........................................................................7
2.1 Protocol Model....................................................................................................................7
2.2 Frame Formats.....................................................................................................................8
2.2.1 Preambles..............................................................................................................9
2.2.2 Addressing.............................................................................................................9
2.2.3 Error Detection Coding.......................................................................................12
2.2.4 Master to Slave or Burst-Mode Device Frames.................................................13
2.2.5 Slave to Master Frames.......................................................................................14
2.2.6 Burst-Mode Device to Master Frames...............................................................15
2.3 HART Protocol Services....................................................................................................16
2.3.1 Model for Service Specifications.........................................................................16
2.3.2 User Interface Primitives.....................................................................................17
2.3.3 Management Interface Primitives........................................................................23
2.3.4 Physical Layer Interface Primitives....................................................................26
2.4 HART Protocol Specification............................................................................................28
2.4.1 Model for Protocol Specifications......................................................................28
2.4.2 Primitive Receive and Transmit Machines:.........................................................29
2.4.3 Slave / Burst-Mode Protocol Machine................................................................31
2.4.4 Master Protocol Machine...................................................................................32
2.4.5 Arbitration and Time-out Constants...................................................................36
APPENDIX A: REVISION HISTORY...............................................................................................40
Revision 7.1. 27 November, 1996 Page: 3 of 41

Figures
Figure 1 HART Protocol Model...........................................................................................................8
Figure 2 HART Frame Format..............................................................................................................9
Figure 3 Long Frame Address.............................................................................................................10
Figure 4 Short Frame Address.............................................................................................................12
Figure 5 HART Error Detection Scheme............................................................................................12
Figure 6 The Delimiter Character........................................................................................................14
Figure 7 Model for Protocol Service Specifications............................................................................17
Figure 8 Transmit Service Sequence....................................................................................................19
Figure 9 Transfer Service Sequence.....................................................................................................21
Figure 10 Cyclic Service Sequence......................................................................................................23
Figure 11 Remote/ Local Management Sequence................................................................................24
Figure 12 Physical Layer Primitive Sequences....................................................................................26
Figure 13 Finite State Machine Model................................................................................................29
Figure 14 RCV_MSG Receive State Machine....................................................................................30
Figure 15 XMIT_MSG Transmit State Machine...............................................................................31
Figure 16 Slave/ Burst-Mode Device State Machine..........................................................................32
Figure 17 Master State Machine.........................................................................................................35
Figure 18 The Timer Model................................................................................................................37
Figure 19 RT2 Timing.........................................................................................................................38
Figure 20 RT1 Timing.........................................................................................................................39

1. INTRODUCTION AND OVERVIEW

This specification defines the Data Link Layer protocol to be used by devices claiming conformance
to the HART specification. It describes the communication protocol in an implementation
independent form so that it may be translated for any processor and any implementation language.
1.1 Scope
This document describes the rules used by HART products to communicate digital information over
a physical link. It describes the services made available to devices using the protocol and the services
that must be provided to an implementation of this protocol specification by underlying protocol
layers.
1.2 Organization
This specification is organized so as to provide an overview of functional requirements addressed by
the protocols, followed by a layer by layer description of protocol interfaces and functionality
following the philosophy behind the ISO/OSI model.
1.3 Functional Requirements

This section outlines those communication requirements between devices that are addressed by the
protocol specification.
1.3.1 Application Environment

The protocol is intended to provide a reliable, transaction oriented communication path to and from
slave devices such as field instruments, for digital data transfer. Communications is over twisted pair
that may be simultaneously carrying 4-20mA signaling. The protocol will correct for errors due to
noise on the communication links by using error detecting information and an Automatic Repeat
Request (ARQ) protocol to request the re-transmission of data blocks that may be corrupted by line
noise or other disturbances.
If poll (short form) addresses are used, up to 15 slave devices may be multi-dropped on a single
communication link (see Section 2.2.2.2). If unique (long form) addresses are used, the number of
multi-dropped devices is essentially unlimited, and is determined based on the applications required
rate of scan of the devices on the communication link (see Section 2.2.2.1).
The protocol will also arbitrate access to the field instrument between secondary master devices such
as a handheld terminal and primary master devices such as a control system. The protocol gives
equal access to the communication channel to both kinds of masters when they are being
simultaneously used. The protocol will not arbitrate between two secondary or two primary
masters trying to talk on the same link.
To support the regular transfer of information from slave device to master device, the protocol
supports a mode of operation in which slave devices periodically broadcast information onto the
communication link. A slave device is said to be in "burst mode" when it is providing a synchronous

cyclic broadcasting of data, without continuous polling by a master device. No matter how many
slave devices are on a communication link, only one may be in burst mode.
Information transfer between devices on the communication link is through a defined message format.
The entire message is protected by a single parity check product code (sometimes also known as
vertical and longitudinal parity checking). Message framing is through a combination of a start of
frame delimiter and a message length field.
The protocol provides services for device identification, segmented data transfer, and communication
configuration. Other HART protocol documents cover the interpretation of data transferred by this
protocol between various slave devices and the primary or secondary masters.
1.3.2 Device Types

The communications protocol recognizes three distinct device types among entities capable of using
this protocol. The most general and basic type is the slave device. This is a device which accepts or
provides a digital message carrying measurement or other data, but only when specifically requested,
i.e. this device always functions as a slave in a master/slave relationship.
The second device type recognized by the protocol is the burst mode device. This is a device which
provides a digital response carrying measurement or other data, at regular intervals, without the data
being specifically requested, i.e. this device normally functions as an independently broadcasting
device. A burst mode device is defined to be a slave mode device with burst mode capability (hence
the use of the word "mode" in describing the device type). When such a mode is enabled, the device
is said to "be in burst mode".
The third device type recognized by the protocol is a master device. A master device is responsible
for initiating, controlling and terminating transactions with a slave device or a burst mode device. A
distinction is made between master devices into primary master devices and secondary master
devices in order to allow the simultaneous use of two master devices on a HART communication
link. The same protocol rules are followed by a primary master device and a secondary master
device except for customizing time-outs that differentiate between them.
1.4 References
This Specification refers to the following documents that are part of the HART Communications
Specification set:
1. HART-SMART Communications Protocol, FSK Physical Layer Specification.

HCF_SPEC-53. HART Communication Foundation.
2. HART-SMART Communications Protocol, Command Summary Specification.

3. HART-SMART Communications Protocol, Universal Command Specification.


4. HART-SMART Communications Protocol, Common Practice Command

Specification. HCF_SPEC-151. HART Communication Foundation.
5. HART-SMART Communications Protocol, Appendix 1 - Command Specific

Response Code Definitions. HCF_SPEC-307. HART Communication Foundation.
In addition, the documents:
Data Link Layer Slave, Structured Analysis. HCF_LIT-8. HART Communication

Foundation.
Data Link Layer Master, Structured Analysis. HCF_LIT-9. HART Communication

Foundation.
HART Slave Library Software Design. HCF_LIT-11. HART Communication

Foundation.
are generally accepted reference Data Link Layer implementations. However, at this point in time,
they have not been approved as a substitute for the HART specifications.
2. SERVICE AND PROTOCOL SPECIFICATIONS

The first parts (2.1-2.3) of this section define the services provided to the user by the protocol and
the interface between the user and the protocol implementation. They define what information must
be supplied to the protocol for it to successfully transmit or receive data. They also specify in what
order this data must be supplied and when responses can be expected. The last section (2.4)
provides a detailed description of the protocol itself.
2.1 Protocol Model

Figure 1 is a conceptual model of a HART protocol implementation. It is intended as a frame of
reference rather than as a description of an actual implementation. The purpose is to show the
relationships between the various services, interfaces, and protocol components that are described in
detail in later sections. As can be seen from the figure, the model distinguishes between five
components. Two of these, the user/protocol interface and the protocol/physical layer interface are
descriptions of services that are provided to or required from adjacent protocol "layers". The other
three components make up the protocol specification itself. This is broken up in terms of three
corresponding state machines. The receive and transmit machines describe handling of message
transmission and reception, while the main state machine uses invocations of these to implement the
rest of the protocol.
The interface between the various components of the protocol is specified in terms of service
primitives. The specification of a service consists of two parts, the first of which is a description of
the primitive. This is a pseudo higher level language module / procedure definition describing

parameters used by the service. The second is a sequence diagram which shows the order of events
at the interface.
Protocol specifications themselves are formulated in terms of a state transition diagram. This
notation allows an unambiguous description of the action of the protocol. An outline of this
protocol description technique is provided later.
User
Protocols
User/HART
Interface
HART
LINK LAYER
PROTOCOL
Rx Tx
FSM FSM
HART/Physical
Interface
Physical
Layer
Figure 1 HART Protocol Model
2.2 Frame Formats

All data transferred between entities involved in the protocol is transferred in the form of frames. A
frame is an encapsulation of user data in control and addressing information. Protocol
implementations shall not make any interpretation of user data (labeled as "data" in Figure 2). This
means that frame recognition is disabled from the beginning of the user data field until the frame is
complete as determined by a (correct) byte-count or by the physical layer signaling the end of a
message (e.g. through absence of carrier detect).
A frame is delimited by the combination of characters called preambles, a unique "start of frame"
character (Delimiter) which identifies the frame's beginning, and by a Byte Count field which
determines where the frame ends. The source and destination of data within a frame is determined by
Address fields. The interface between the protocol and the user is through a Command field which
identifies to the protocol whether this is a protocol command or a user command and a Response
Code field which conveys the result of a protocol transaction back to the user. User data, if any is
transferred in the Data field.
All portions of the frame, including the delimiter shall be protected by a combination of odd parity
on each byte transmitted and a trailing Check Byte field.

All fields in a frame are an integral number of bytes in length and all bytes of a frame must be
transmitted in a single contiguous stream (i.e., there should be no more than a single bit time gap
between consecutive characters). Figure 2 shows the frame formats used by HART devices.
Preamble Delimiter Address Command Byte [Data] Check

Count Byte
Master to Slave Frame
Slave to Master Frame

Preamble Delimiter Address Command Byte Response [Data] Check
Count Code Byte
Figure 2 HART Frame Format
2.2.1 Preambles
All frames transmitted by master, slave or burst mode devices are preceded by a specified number of
hexadecimal "FF" characters. These characters are called the preamble to the frame. They are
required in some physical layer protocol implementations to train/ synchronize the receiver.
Note: Many preambles may be received prior to the delimiter. However, two consecutive preambles
followed by a leading delimiter shall define the start of a frame for the FSK physical layer.
While preambles are primarily a physical layer requirement, the data link layer provides management
service support for specifying and determining the number of preambles required by an
implementation. For the FSK physical layer, HART devices should never transmit less than 5
preambles. This allows the sufficient time for asserting a carrier, training the modem circuit and for
the listening device to begin receiving the message. HART devices are recommended to send no more
than 20 preambles.
A slave device should default to transmitting 5 preambles. If Common Practice Command 59 is

supported then the master device may set the number of preambles transmitted by the slave as
needed. When the master device identifies a slave device (for example by using Universal Command
0 or 11) the slave device shall indicate the minimum number of preambles required to be transmitted
by the master.
2.2.2 Addressing
The protocol uses source and destination addresses in each frame. For both long and short frame
addresses, the high order bit of the address field indicates the master associated with this frame. A
primary master uses the value "1" for this bit, a secondary master uses the value "0". Slave devices
must echo back this field unchanged. The next bit indicates whether the slave device is in burst
mode. The slave devices must set this bit to a "1" to indicate that the device is in burst mode or to a
"0" if the device is not in burst mode. Master devices must set this bit to "0" in requests to slaves.
The protocol supports: long frame addresses and short frame addresses. The use of short form
addresses or long frame addresses in a message is indicated by the delimiter (see Figure 6).

Byte 0 Byte 4
Device
Type Device Identifier
6 Least Significant Bits of

Manufacturer ID
1=Slave in Burst Mode
1=Primary Master
0=Secondary Master
Figure 3 Long Frame Address
2.2.2.1 Long Frame Addresses

Except for Command 0, all HART frames consist of a 5 byte address based on the slave device's
unique identifier (see Figure 3). A unique identifier is associated with each slave device or field
instrument manufactured. The protocol normally uses the lower 38 bits of the unique identifier to
address data link layer requests to slave devices on the link. As a result, the long frame address must
consist of:
The master address and the burst mode bit as described above in Section 2.2.2:
Addressing.
The least significant 6 bits of the Manufacturer ID. The valid Manufacturer ID can be
found in Common Tables 8: Company (Manufacturer) Identification Codes.
A 1 byte Device Type Code. This code is allocated and controlled by the
manufacturer. Since only the lower 6 bits of the Manufacturer ID is used in the
address, the Device Type code should be allocated as indicated in Table 1. Further
specifications regarding allocating Device Type Codes can be found in the Command
Summary Specification: Section 6.1 Compatibility Rules
A 3 byte Device Identifier. This is similar to a serial number in that each device
manufactured with the same Device Type Code must have a different Device
Identifier.

Table 1 Device Type Code Allocation
Manufacturer ID Device Type Code Allocation

0-63 (0x00-0x3F) Begin allocating at 0
64-127 (0x40-0x7F) Begin at 239 (0xEF) and assign

succeedingly smaller valued codes
128-191 (0x80-0BF) Begin at 127 (0x7F) and assign
succeedingly smaller valued codes
192-255(0xC0-0xFF) Begin at 128 (0x80) and assign
succeedingly larger valued codes
In addition to long frame addresses based on the device's unique identifier, the protocol supports a
broadcast address. A broadcast address is defined as 38 bits of zeros in place of the unique identifier
in the long frame address. Devices shall treat a frame with this address as though the frame was
addressed directly to them. Frames with broadcast addresses shall only be used for services that use
other parameters in the broadcast frame to ensure that zero or exactly one device generates a
response frame to the broadcast (e.g., Universal Command 11).
2.2.2.2 Short Frame Addresses

Previous, obsolete revisions of the protocol utilized short frame addresses. In order to maintain
backwards compatibility, only Universal Command 0 now supports short frame addressing. This
allows the protocol to dynamically associate a short frame address with each slave device on the link.
The short frame or polling addresses may be used during link initialization to rapidly scan the link
address space. The protocol provides the capability necessary to manipulate these addresses on
initialization as well as during normal operations. It also provides the capability to obtain the unique
identifier associated with a particular short frame address when necessary.
Figure 4 shows the required format of the one byte short frame address consisting of:
The master address and the burst mode bit as described above in Section 2.2.2:
Addressing.
The next two bits (4-5) must be set to zero.
The least significant 4 bits specify the polling address.

Data Bit 7 Data Bit 0
0 0
4-Bit Polling Address
Reserved
1=Slave in Burst Mode
1=Primary Master
0=Secondary Master
Figure 4 Short Frame Address
2.2.3 Error Detection Coding

To perform error detection, HART utilizes a single parity check product coding scheme. This allows
HART to use parity checking in two dimensions: across the bits in a single byte; and across the bit
positions in the transmitted message. The two dimensions of parity checking can be seen in Figure 5.
Each byte consists of 8 bits plus odd parity ("Vertical Parity"). The Vertical Parity can be
automatically generated and checked by most UARTs. Figure 5 shows the organization of the
individual bytes into a HART long address frame. The second dimension of error detection is
generated by exclusive "OR"-ing all bytes from the Delimiter up to and including the last Data byte.
The result is transmitted as the last byte ("Check Byte") of a message. There is odd parity on the
Check Byte as well.
Byte Count
Check Byte
Address 4
Command
Address 0
Address 1
Delimiter
Data n
Data 0
Data 1
Bit 0
Bit 1
8 Data Bits "Longitudinal Parity"

(Parity Across Each Bit
Position or Row)
Bit 7
Odd Parity
"Vertical Parity"
(Parity on Each Byte or Column)
Figure 5 HART Error Detection Scheme

2.2.3.1 Slave Response

The operation of a slave device in the presence of communication errors must be consistent.
Communication errors could occur in any portion of the HART frame. As a result, the response of
the slave device depends on the field in the frame where the error is detected. Table 2 summarizes
the required slave action upon detection of a communication error in particular fields.
Table 2 Slave Action by Frame Field Upon Error Detected
Field Response
Delimiter
Framing of the message must be aborted. No reply shall be generated. If the slave is
in Burst Mode then the burst wait timer should be set to RT1.
Address The message should be treated as if addressed to another device. No reply shall be
generated. Note: if a broadcast address is used then this action applies to an error in
the additional identification field (e.g., the tag in Universal Command 11).
Command The device must reply. The response frame shall consist of the command that the
slave detected and the communication error status byte shall indicate the appropriate
error. No data shall be returned.
Byte Framing of the message must be aborted. No reply shall be generated. If the slave is
Count in Burst Mode then the burst wait timer should be set to RT1.
Data The response shall indicate the appropriate error in the communication error status
byte. No data shall be returned.
Check The response shall indicate the appropriate error in the communication error status
Byte byte. No data shall be returned.
2.2.4 Master to Slave or Burst-Mode Device Frames

Figure 2 shows the format of a master to slave or burst-mode device message. Reading from left to
right, in the order in which the frame is transmitted, the fields are:
1 Two preamble characters followed by the delimiter. The high order bit of the
delimiter determines whether the following frame is a short or long format frame (see
Figure 6). The low order three bits encode the type of frame. The reserved fields
may be used in the future1 and should be masked out in current implementations.
The combination of these three characters are used to recognize the start of a frame.
See Section 2.2.1, Preambles, for more information.
2 Address: As described above, the high order bit of the delimiter determines whether
the following frame is a short or long addressed frame. The format of the address is
described in Section 2.2.2, Addressing.
1
HART Revision 5 to Revision 6 Forward Compatibility Specification Minimum Feature Set. Rosemount Document
No. 8900111 Rev. B. Fisher-Rosemount Systems, Inc.

1=Long Frame
0=Short Frame
Reserved
Frame Type
001 Burst Frame
010 Master to Slave
0 0 0 0
110 Slave to Master
Figure 6 The Delimiter Character
3 Command. This field is one byte long. Command byte values are echoed back
unchanged in responses from slave devices.
Note: Command number 254 is reserved and shall not be used in any implmentation.
4 Byte Count. This field is one byte in length and is the count of the number of bytes
of user data that follow between the byte-count and the parity check byte (both
excluded from the count). All values between 0 and 255 (both inclusive) are legal in
this field.
5 Data. The fifth field consists of an integral number of bytes of user data.
6 Check Byte. This value is determined by a bitwise exclusive OR of all bytes of a

transmitted frame beginning with the leading delimiter. The Check Byte is calculated
and checked as described in Section 2.2.3, Error Detection Coding.
2.2.5 Slave to Master Frames

Figure 2 also shows the format of a Slave to Master frame. These frames are identical to Master to
Slave frames except for the leading frame delimiter and the presence of a response code field. The
fields are:
1 Two preambles followed by the leading delimiter. The structure of the delimiter byte
is identical to that for master to slave frames.
2 Address. The structure of the second field is identical to that for master to slave
frames. The value of the burst mode bit is set or cleared depending on whether this is
a device in burst or non-burst mode. The rest of the address is echoed from the
incoming Master to Slave frame.
3 Command. Echoed from the incoming Master to Slave frame.
4. Byte Count. This is set to the number of bytes between it and the longitudinal parity
or check byte at the end of the message. The minimum value of this field is 2, since all
Slave to Master frames have at least the two byte response code.

5. Response Code. A two byte response code unique to Slave to Master frames. This
field holds information that describes the result of the attempted transaction.
-- If bit 7 of the first response code byte is set, a communication error has
occurred, and the remaining bits provide a summary of the communication
error.
-- If bit 7 of the first response code byte is clear, the remaining bits carry upper
level protocol information about the success or failure of the command.
-- The second byte of the response code carries data link and device status. It
may be set to zero if a communications error is reported in the first byte.
Additional guidance on the use of the 2 response code bytes can be found in the
Command Summary Specification and Appendix 1: Command Specific Response
Code Definitions
6. Data. The sixth field consists of an integral number of bytes of user data.
7. Check Byte. This is calculated as described in Section 2.2.3, Error Detection Coding.
2.2.6 Burst-Mode Device to Master Frames

Burst mode frames are generated without a corresponding master request to each burst "response"
frame. Burst mode frames are distinguished by their unique delimiter. These frames are identical to
the format of a Slave to Master frame (see Figure 2) except for the delimiter and the usage of the
master address bit in the address field. The fields are:
1 Two preambles followed by the delimiter indicating that this is a frame identical to a
Slave to Master frame except that it was generated spontaneously by a burst-mode
device. Burst mode frames shall be generated in the long frame format only.
2. Address. The second field is identical to Slave to Master frames. The burst-mode
device alternates the the value of the master address bit between "1" or "0" (see
Section 2.4.3). It also sets the burst mode device bit to "1" since it is in burst mode.
3. Command. The command byte is set by the burst mode device to the command that
is being burst.
4. Byte Count. This is set to the number of bytes between it and the longitudinal parity
byte at the end of the message. The minimum value of this field is 2, since all Slave to
Master frames have at least the two byte response code.

5. Response Code. The fifth field is identical to that used in Slave to Master frames.
This field holds information that describes the result of the attempted burst
transaction.
-- Bit 7 of the first response code byte is always cleared, since there is no
incoming message about which to report communication errors.
-- The second byte of the response code carries data link and device status.
6. Data. The sixth field consists of an integral number of bytes of user data.
7. Check Byte. It is calculated and checked as described in Section 2.2.3, Error Detection
Coding.
2.3 HART Protocol Services

Services described in this section are used to obtain:
A reliable, "at least once", transaction service between peer entities. The service is
not designed to provide duplicate detection.
An optional, reliable, transaction service between peer entities that provides end-to-
end segmentation and duplicate detection.
Management services for device identification and device configuration.
The primitives defined in this section fall into two classes, those associated with the transfer of user
data in the normal sequence of usage are termed user primitives. Those that are concerned with the
initialization of the protocol, such as the setting up of addresses, establishing a unique relationship
between addresses and peer protocol entities are called management primitives. All primitives
described here must be supported by a protocol implementation. The mapping of these primitives
into an implementation is entirely a local matter and is in no way restricted by this specification.
2.3.1 Model for Service Specifications

Figure 7 explains the structure of a typical sequence diagram. The two vertical lines represent the
interfaces between users of a protocol service (who lie outside the lines) and the protocol service
provider (which lies in between them). Arrows meeting these lines indicate events at each end of the
communication link. Time increases down the page. Points on these axes mark when protocol
transactions are initiated or received. Diagonal lines joining the time axes represent the propagation
of messages or data between the two entities on the link and represent transactions that take place
internal to the protocol. Diagonal lines outside the vertical axes represent signals or events that occur
at the user interface to the protocol. The convention used in labeling these interface events is as
follows: Transactions initiated by a user are labeled with a trailing ".request" to show that they are
directed towards the protocol. The result of a request is communicated back to the user by the
protocol in a transaction labeled with a ".confirm", to show that they are in response to a previous

".request". At the other end of the link, the protocol responds to an incoming transaction by
providing an indication to the local user that data or control information has arrived. Such
transactions are labeled with a trailing ".indication". The response of a peer protocol entity to an
indication is labeled with a trailing ".response". The distinction between the use of a request /
confirm pair and an indication / response pair to label a set of primitives is based upon whether the
primitives are used to cause a protocol transaction or are caused by one.
Protocol User Protocol Provider Protocol User
Request Indication
Confirmation Response
Figure 7 Model for Protocol Service Specifications
2.3.2 User Interface Primitives

The HART protocol supports three kinds of data transfer services:
Transmit services are used to provide a basic capability to send a message and receive a
reply.
Transfer services use a sequence field in each message to support duplicate detection and
message segmentation. Transfer services provide a reliable bi-directional message transfer
between master and slave devices.
Cyclic services to provide a repetitive broadcast of data.
These services are initiated by a master. The slave or burst mode device functions as a responder for
these services.
2.3.2.1 Transmit Services

There are four user primitives defined to support the transmit service. In the definition of the
primitives, certain parameters are optional and may not be present in all invocations of the primitive.

Such parameters are distinguished by enclosing them within square brackets ("[","]") in the primitive
definitions. Sequence diagrams describing these primitives are shown in Figure 8
t r a n s m i t . r e q u e s t ( a d d r e s s , c m d , [ d a t a ] ) : This
primitive is used by the master HART
protocol user to request the transfer of information to a slave entity at the given address. Note that
all information must be supplied by the user of this service and it is the responsibility of the user to
determine validity of the parameters. The protocol implementation shall carry out a limited
validation of the parameters (e.g., address out of range) to the extent of its capability.
This primitive shall be encoded as a request message addressed to a slave/burst-mode device.
transmit.indicate(address, cmd, [data]): This primitive is invoked by the data link

protocol layer to indicate to a slave user that a valid message has been received from a peer protocol
entity. The user receives the contents of the command byte and optional data if any.
Encoding of this primitive is a local matter and is not limited by the specification.
transmit.response(status, [data]): This primitive is executed by the slave user entity

to respond to an incoming transmit.indicate. It is the mechanism used to return the results of
executing on information provided in the immediately previous indication.
This primitive shall be encoded as a response message addressed to a master device.
transmit.confirm(local_status, response_code, [data]): This primitive is

returned to the master protocol user to communicate the results of a previously executed
transmit.request. The last received slave response (if any) is returned together with a status
word. The status should indicate the success or failure of the request. The local status byte carries
the status of the communication routines in the master.
The HART Command Specification Documents detail the encoding of frames on the communication
link and of application layer mappings into these services.

Transmit.request
(Possible losses and retries)
Transmit.indicate
Transmit.response
(Possible losses and retries) Transmit.indicate
Transmit.response
Transmit.confirm
Figure 8 Transmit Service Sequence
2.3.2.2 Transfer Services

Transfer services are used to support applications (such as uploads/downloads, block transfers etc.)
that require the data link to protect the transfer against lost and duplicate data. Because of the
master-slave relationship of the HART link layer protocol, operation of the transfer service is
entirely controlled by the master device. Slave devices only perform the responder functions.
Transfer service frames carry a sequence number field that is used for segmentation as well as for
duplicate detection/rejection and lost frame detection. Essentially, frames must be received in
sequence. Transfer services are configured and controlled by issuing and receiving control requests.
A pre-configured context is defined for transfer services. If no control requests are issued, the default
context is a reliable bi-directional byte stream. This is sometimes also called "ASCII terminal mode".
There are eight user primitives defined to support the transfer service. Four of these are used for
control, and four for data transfer using the service. In the definition of the primitives, certain
parameters are optional and may not be present in all invocations of the primitive. Such parameters
are distinguished by enclosing them within square brackets ("[","]") in the primitive definitions.
Sequence diagrams describing these primitives are shown in Figure 9
transfer_control.request(address, function, service_identifier,

[ d a t a ] ) : This primitive is used by the master HART protocol user to initiate, control or abort an
invocation of the transfer service with a slave entity at the given address. Optional control data
parameters may be required depending on the function being requested. Note that all information
must be supplied by the user of this service and it is the responsibility of the user to determine validity
of the parameters. On initiation, the high order bits of the function byte specify in which direction
the initiator is willing to support data transfer. The responder similarly indicates its willingness.
Data transfer shall proceed in the direction(s) determined by the "AND"ing of the direction bits in
the request and response function bytes. The function codes identify the control activity being
requested. For control functions other than initiate, the direction bits define which transfer direction
the control request is to be applied to. The service identifier indicates the protocol that is to be used
for this transfer session.
This primitive shall be encoded as a request message addressed to a slave or burst-mode device with
command value. The command value shall indicate that this is a transfer control frame.
transfer_control.indicate(address, function, function,

s e r v i c e _ i d e n t i f i e r , [ d a t a ] ) : This primitive is invoked by the data link
protocol layer to
indicate to a slave user that a valid transfer control message has been received from a peer protocol
entity. The user receives the contents of the sequence field and optional data if any.
transfer_control.response(status, function, service_identifier,

[ d a t a ] ) : This primitive is executed by the slave user entity to respond to an incoming
transfer_control.indicate. It is the mechanism used to return the status of the indication, and
optional control parameter data from the slave to the master device.
This primitive shall be encoded as a response message addressed to a master.
transfer_control.confirm(local_status, response_code, function,

s e r v i c e _ i d e n t i f i e r , [ d a t a ] ) : This primitive is returned to the master protocol user to
communicate the results of a previously executed transfer_control.request. The last received
slave response (if any) is returned together with a status word. The status should indicate the
success or failure of the request. The local status byte carries the status of the communication
routines in the master. The sequence number is that set by the slave device.
transfer.request(address, sequence_no, [data]): This primitive is used by the

master HART protocol user to request the transfer of information to a slave entity at the given
address. Note that all information must be supplied by the user of this service and it is the
responsibility of the user to determine validity of the parameters. The protocol implementation shall
carry out a limited validation of the parameters (e.g. address out of range) to the extent of its
capability.
This primitive shall be encoded as a request message addressed to a slave or burst-mode device. The
command field shall indicate that this is a transfer service frame. The first byte shall contain the one

byte sequence number. It shall be the data link layer protocol responsibility to increment the
sequence number with each invocation of this service primitive. The data link layer will not
increment the sequence number on re-tries.
transfer.indicate(address, sequence_no, [data]): This primitive is invoked by

the data link protocol layer to indicate to a slave user that a valid transfer message has been received
from a peer protocol entity. The user receives the contents of the sequence field and optional data if
any.
t r a n s f e r . r e s p o n s e ( s t a t u s , s e q u e n c e _ n o , [ d a t a ] ) : This primitive is executed by the

slave user entity to respond to an incoming transfer.indicate. It is the mechanism used to return
the status of the immediately previous indication, and to optionally transfer sequenced data from the
slave to the master device.
This primitive shall be encoded as a response message addressed to a master device. The command
field shall indicate that this is a transfer service frame. It shall be the data link layer protocol
responsibility to increment the sequence number with each invocation of this service primitive. The
data link layer will not increment the sequence number on re-tries.
Transfer.request
(Possible losses and retries)
Transfer.indicate
Transfer.response
(Possible losses and retries) Transfer.indicate
Transfer.response
Transfer.confirm
Figure 9 Transfer Service Sequence

transfer.confirm(local_status, response_code, sequence_no, [data]):

This primitive is returned to the master protocol user to communicate the results of a previously
executed transfer.request. The last received slave response (if any) is returned together with a
status word . The status should indicate the success or failure of the request. The local status byte
carries the status of the communication routines in the master. The sequence number is that set by
the slave device.
2.3.2.3 Cyclic Services

Cyclic services are supported by several primitives. Two of these primitives are defined for the
responder of the cyclic service (i.e., the burst mode device) to allow updating of data that is being
cyclically broadcast. Others allow the enabling of cyclic message transfer, the disabling of cyclic
message transfer, and to indicate the receipt of a cyclic message in the responder / receiver.
cyclic_configure.request(cmd): This primitive is used by the burst mode device protocol

user to specify the identity of the data to be cyclically broadcast. This primitive and its
corresponding response can be issued at any portion of the cyclic service sequence. It is encoded as
a request on the communication link.
cyclic_configure.confirm(local_status, response_code, [data]): This

primitive confirms the identity of data to be cyclically broadcast from the remote device. Encoding
of this primitive is a local matter and is not limited by the specification.
cyclic_start.request( ): This primitive is used to request the transfer of specific

information without further polling by the requesting device. It is encoded as a request on the
communication link.
cyclic_start.confirm(local_status, response_code, [data]): This primitive

confirms that cyclic broadcasts of data from this device have been initiated and will occur as
determined by the media access protocol arbitration rules and the burst rate parameter. Encoding of
this primitive is a local matter and is not limited by the specification.
cyclic_stop.request( ): This primitive is executed by the burst mode device user layer to
disable cyclic broadcast of data. It is encoded as a request on the communication link.
cyclic_stop.confirm(local_status, response_code, [data]): This primitive

confirms disabling of cyclic data broadcasts. Encoding of this primitive is a local matter and is not
limited by the specification.

cyclic.indicate(cmd, status, [data]): This primitive indicates that a cyclic broadcast

of data has been received at this device. Encoding of this primitive is a local matter and is not limited
by the specification.
cyclic_configure.request
cyclic_configure.confirm
cyclic_start.request
cyclic_start.confirm
cyclic_update.request
cyclic_indicate
cyclic_indicate
cyclic_update.confirm
cyclic_indicate
cyclic_stop.request
cyclic_stop.confirm
Figure 10 Cyclic Service Sequence
2.3.3 Management Interface Primitives

Management primitives for the data link layer are defined in HART for both master and for slave
devices. For slave devices, such management functions are entirely local. For master devices, both
local and remote management functions are defined.
2.3.3.1 Master Device Management Interface Primitives

Master management functions in the HART protocol are concerned with two kinds of functionality.
The first, handled by local management requests is concerned with the configuration of master entity
parameters such as retry limits and preamble lengths. The second kind of functionality, handled by

remote management requests is concerned with the addressing and identification of devices or peer
entities. The sequence of events for these primitives is shown in Figure 11.
management.request management.request
management.indicate
management.confirm
management.confirm
management.response
(A) Local Management Sequence (B) Remote Management Sequence
Figure 11 Remote/ Local Management Sequence
local_management.request(cmd, [data]): This primitive is used to configure protocol

parameters. Note that this primitive does not require any data to be transmitted onto the
communication link.
Table 3 Local Management Commands
Command Data in Request Data in Confirm

Set_re-try_limit new re-try limit old re-try limit value
Initialize Host address
Enable_burst_reception
Set_preamble new preamble length old preamble length
l o c a l _ m a n a g e m e n t . c o n f i r m ( s t a t u s , [ d a t a ] ) : This primitive is used to return the

results of a corresponding local_management.request. The status shall return the results of
executing the request.
The purpose of the remote management primitives described here is to uniquely identify a slave
device on the end of a link and to establish a temporary correspondence between this unique
identification and a polling address that allows efficient use of communication bandwidth. These
primitives are identical to regular user primitives except for the use of the command and status fields
to carry protocol control information. also shows the remote (i.e., master to slave) primitives.
m a n a g e m e n t . r e q u e s t ( a d d r e s s , c m d , [ d a t a ] ) : This management primitive is used to

request the execution of a management function in a master or a slave protocol entity. The following
commands should be implemented.

management.confirm(status, [data]): This primitive is used to return the results of a

previously executed management request. This primitive is identical in function to a
transmit.confirm primitive, except for the fact that the commands carried by this primitive are
executed entirely by the peer protocol entity and not by the user of the protocol service. In case of a
communication error, the same status codes are to be returned as for a transmit.request.
Table 4 Remote Management Commands
Command Data Encoding Expected Response
Identify poll address or tag Cmd 0 For both commands unique ID of device,
Cmd 11 revision codes, number of preambles,
etc.
set_polling_address new poll address Cmd 6 new poll address as read from non-
volatile memory
set_remote_preambles number of response Cmd 59 number of preambles
preambles
Notes:
1. Commands 0, 6 and 11 are Universal Commands must be supported by all slave devices
2. Command 59 is a Common Practice Command. Support by slave devices is optional.
management.indication(address, cmd, [data]): This primitive is invoked by the

physical layer entity to indicate the arrival of a media access layer management message.
m a n a g e m e n t . r e s p o n s e ( s t a t u s , [ d a t a ] ) : This primitive is used by the slave management

entity to return the results of executing the previous management.indication to the invoker.
2.3.3.2 Slave/Burst Mode Device Management Interface Primitives

l o c a l _ m a n a g e m e n t . r e q u e s t ( c m d , [ d a t a ] ) : This primitive is used to configure protocol
parameters. Note that this primitive does not require any data to be transmitted onto the
communication link.
Table 5 Slave Device Management Primitives
Command Data in Request Data in Response

Initialize slave address (not applicable)
Burst mode control on/off (not applicable)
Set_preamble new preamble length old preamble length

local_management.confirm(status, [data]): This primitive is used to return the

results of a corresponding local-management .request. The status shall return the results of executing
the request.
2.3.4 Physical Layer Interface Primitives

The physical layer interface is determined by a set of transmit and receive primitives. At any given
instant the interface may undertake either a transmit or receive primitive sequence, but not both
simultaneously (i.e. the interface is half duplex). To make the specification clearer a suggested
mapping of the interface primitives into typical modem control signals is also supplied.
The following primitives described by the sequence diagrams in Figure 12 must be supported by the
underlying physical layer.
reset.request( ): This primitive is passed to the physical layer to request it to undergo a

physical reset. Some implementations may optionally return a reset confirm.
reset.confirm( ): This optional primitive is passed from the physical layer to indicate that it
has completed a physical reset in response to a reset.request.
reset.request
Optional
reset.confirm
enable.request
enable.indicate
enable.confirm
data.request
data.confirm
or
error.indicate
Figure 12 Physical Layer Primitive Sequences

enable.request(state): This primitive is passed to the physical layer to request it to prepare

for data transmission or to terminate a data transmission depending on whether the parameter state is
"high" or low". This signal is usually implemented as the request to send (RTS) signal in a modem.
An enable.request may only be issued if the interface is in an idle state. (i.e. no pending
transmit.indicate or transmit.confirm).
enable.confirm(state): This primitive is passed back by the physical layer to confirm its
ability to accept data for transmission, or to indicate that it will accept no further data. In a modem
implementation this primitive is usually mapped into the clear to send (CTS) signal from a modem.
The physical layer may implement RTS/CTS turn-on/off delays in order to give its corresponding
physical layer entity (the other modem) time to establish communication. See the HART Physical
Layer Specification for details.
data.request(data): This is the primitive used to actually transfer a unit of data (byte) to the
physical layer for transmission. This would typically be implemented as a write to a transmit data
register or some other such operation.
d a t a . c o n f i r m ( ) : The primitive used by the physical layer to indicate acceptance of the data
from a previous data.request, and its readiness to process more of such requests. Implementation
of this primitive may be by setting a status bit in a register for a simple polled implementation, or by
initiating an interrupt on the transmit data register becoming empty in a more sophisticated version.
error.indicate(data): Returned by the physical interface to indicate an error in transmitted

or received data or its handling. Examples of errors that may be returned by the physical interface
are transmitter overruns, parity and framing errors and indications of receiver underrun.
enable.indicate(state): A receive primitive passed by the physical layer to indicate the

establishment of communication with a peer physical layer entity, or to indicate the termination of a
currently established connection, depending on whether state is "high" or "low". This primitive is
usually implemented as a carrier detect (CD) signal from a modem. Typically a CD turn-on and
turn-off delay together with hysteresis on the receive carrier levels that trigger this transition is
implemented to prevent oscillation and provide protection against noise bursts. See the HART
Physical Layer Specification for details.
data.indicate(data): This primitive is passed back from the physical layer to indicate the
availability of a data unit (byte). In implementation, this primitive may be mapped into a "receive
data register full" status bit or a "receive data" interrupt
data.response( ): This local confirmation is passed back to the physical layer to confirm the
processing of the previous data.indicate, and to confirm readiness to handle subsequent
transitions. Typically implemented as a read of a "receive data register" or clearing of a status bit.

2.4 HART Protocol Specification

Media access layer services are specified using a state transition diagram notation. An example is
shown below. The media access protocol defined in this document is intended to allow the
coexistence of a single active (i.e. initiating transmissions) primary master and a single active
secondary master together with a single active burst-mode device. It is not designed to handle more
than one each of these device types being simultaneously active.
The protocol normally provides equal priorities to masters such as a handheld communicator and the
control system by allowing them to alternate transmissions on the link. The protocol however is
also designed to prevent "lock up" of access to the communication link by assigning different
priorities to the two masters in case of simultaneous unarbitrated access requests. The arbitration
scheme is a very simple one based on an implicit token pass.
2.4.1 Model for Protocol Specifications

Figure 13 shows a typical state transition diagram. The following notation is used:
Each protocol entity is defined by a state-transition diagram.
Labeled circles represent states that protocol entities can be in.
Transitions are directed arcs. They show which state a protocol leaves and which
state it transitions to. A transition is labeled with the condition that caused it and the
corresponding outputs (this may be null). A transition label is written as the pair
"<transition cause> / <output>".
Actions to be executed as a consequence of taking a transition are bracketed by

"{actions}". These generally apply to state variables.
Heavily outlined states are terminal states for the machine, i.e., at the end of
processing of transitions the machine must end in a terminal state.
A dash (" - ") means "Not Applicable".
A tilde (" ~ ") means the ones complement or negation.

Figure 13 Finite State Machine Model
2.4.2 Primitive Receive and Transmit Machines:

To simplify the state transition diagrams, two primitive state machines, a receive machine and a
transmit machine are defined in Figure 14 and Figure 15. They are executed on data transmission and
reception. In the main state transition diagrams, their invocations are represented by the "xmt_msg"
and "rcv_msg" actions respectively. Typically these machines would be implemented as interrupt
driven i/o drivers.
The receive machine state transition diagram describes a simple "i/o driver". It first watches for a
valid start of a frame (two consecutive preambles followed immediately by the delimiter). If the
inter-character gap is too large, a parity error occurs, or a character other than a delimiter or preamble
is received RCV_MSG status is set to an error. If a valid set of preambles and delimiter are reached,
RCV_MSG sets the type of message received (request, acknowledgment or burst message). It then
processes the rest of the message, till the end of the message is determined as shown by the byte
count. At this stage, or earlier if there has been a parity error on the byte-count, such that it cannot
be used (see Section 2.2.3.1), RCV_MSG transitions to complete handling any remaining characters
in the message. RCV_MSG terminates processing when enable.indicate is negated. In other
words, when no further characters are left to be processed from the current message.

Figure 14 RCV_MSG Receive State Machine
The transmit machine state diagram describes a similar "component". The "INIT" state of the
machine implements a start up handshake to give the physical layer time to establish communication
with its peer entity at the other end of the link. Once the physical layer issues the confirm, data
transfer requests are made in the "WRITE" state. As each data byte is transferred, and a confirm is
received from the physical layer, another byte is written until either the end of the message to be
transmitted is reached or an error occurs. The negated enable.request to the physical layer tells it
that no further transmission is required for this message. A status is returned.

Figure 15 XMIT_MSG Transmit State Machine
2.4.3 Slave / Burst-Mode Protocol Machine

Slave / burst-mode device operation is described in Figure 16. Associated with all slave devices is a
slave time out, "TT0". It is identical for all slaves. This time out is the maximum amount of time
permitted for a slave to respond to an incoming message. If a response cannot be generated within
this time period, the transaction is considered to have failed by the master.
Enabling and disabling of burst mode is carried out by the device in response to a request from a
master. When burst mode is enabled by a master the first burst frame should be transmitted
contiguously with the slave response. In other words, there should be a gap of less than one bit time
between the slave response message to the command enabling burst mode and the first burst message.
There must be only one burst mode device active on the communication link at any given time.
When issuing burst messages, the device shall toggle the master address bit value in the burst frame.
It does this by setting the value of the bit to the value of its internal state variable "HOST", which it
updates with each burst transmission.
An incoming message (enable.indicate is set) triggers the RCV_MSG protocol state machine
which begins operation by looking for a correctly framed message (error free preambles, delimiter,
address and length bytes). Incorrectly framed messages are ignored. Upon return from RCV_MSG
processing the incoming message type is checked. If this is an acknowledgment, the device can burst
right away. If this is a request, the address field is checked against the slave address. If there is no
match, the message is ignored, and the slave device, if in burst mode, prepares to defer any burst by
setting "BT" to "RT1". (This will allow the master to timeout). If no acknowledgment is sent by
the other slave the burst mode device should start bursting immediately after RT1 expiring. The
device shall not delay its attempt to burst beyond TT0 after the end of RT1. Otherwise a validity
check is made on the data portion of the message. If any of the parity check tests fail, or if the

message buffer overflows, then a response with communications error information is returned, since
the message was framed correctly.
If the message has been received without errors, the protocol passes the information in the message
back to the user through a "transmit.indicate". When the user executes a "transmit.response",
a response message is formulated and returned. If the device is in burst mode, a burst will follow.
A burst mode device sets "BT" whenever it has issued a burst. A subsequent burst can be issued
only after the timer has expired. This permits a master an opportunity to address the device during
this interval. A burst mode device shall issue bursts as soon after BT expiring as permitted. The
device shall not delay its attempt to burst beyond TT0.
Figure 16 Slave/ Burst-Mode Device State Machine
2.4.4 Master Protocol Machine

Both primary and secondary masters run the identical state transition machine. The arbitration of
access to the communication link is controlled by time-outs. Time-outs are measured as the interval
between transitions of the protocol state machine. These define lengths of time that devices (masters
and slaves) executing the communication protocol use to decide on what they do next based on
whether or not they hear transmissions on the communication link.
Differentiation between the two masters is on the basis of the value of a single time-out used in two
of the transitions within the protocol. This results in equal prioritization of the two masters that
access the link except when there has been a failure of arbitration (due to concurrent attempts to
access the link).
The master state machine has three states, "WATCHING", during which masters are monitoring the
communication link for their turn to use it, "ENABLED", during which the masters can transmit on
the communication link if they have a message to send, and "USING", during which they are waiting

for a reply to a message they have sent. A master implementation maintains the MSG_PENDING,
RCV_MSG and RT1, RT2 timer status variables as state variables for its operation.
Link arbitration is controlled by two defined intervals, the link grant time "RT2", and the link quiet/
slave time-out "RT1".
The smaller arbitration constant is "RT2". It is a constant for both masters. It is set to a
sufficiently large value to allow the other master on the communication link adequate time to initiate
transmission (if it desires to do so) after the master which is executing the "RT2" time-out has just
completed a transaction. The link grant time "RT2" delays a subsequent transmission long enough
for the master to detect a carrier/ start of message due to the other masters communication. If no
transmission from the other master is heard during this interval, the granting master is free to initiate
another transmission.
The link quiet time/ slave time-out defined by timer "RT1" is the larger interval. This time period
must be long enough to ensure that any response from a slave would be received at a master and
hence must be greater than "TT0" by at least the turn-off and turn-on delays associated with carrier
and message detection in the serial interface of the masters.
When used for link quiet time detection, "RT1" ensures that no ongoing transaction will be
interrupted by a master which is seeking access to the communication link. It is the maximum
interval of time that an unsynchronized master, which is trying to access the link, waits after seeing
the end of any ongoing transmissions on the link. If no intervening transmissions occur, the link has
come free and may be accessed. The arbitration and transmission process occurs as described in the
next paragraph.
When an initial transmission request occurs, the state machine cycles through the arbitration process.
First of all, a check is made for ongoing transmissions on the link. The link layer monitors all
transmissions to extract link state information (kind of frame, and whether or not the device is in
burst mode). The link is called "quiet" if no transmissions are seen for a period defined by the link
quiet timer (RT1). The arbitration process is also considered complete if during this wait a response
from a slave, or a burst mode message addressed to the other master is received. In either case, the
master device is now in synchronization, and can immediately transmit its message. Message
transmission must start during the window defined by the HOLD timer which determines the time
the state machine remains in the "ENABLED" state.
Transmitting a message carries the state machine to the "USING" state. The retry count associated
with the transmitted message establishes a re-try mechanism that allows the state-machine to recover
from failures on the communication link. This is controlled by the link quiet/ slave time-out interval
associated with timer RT1. This interval is the length of time for which a master will wait after
sending a message to a slave before deciding that the transmitted message has been lost or that the
slave has failed. Note that this is the identical time period a master seeking to use the link needs to
wait to ensure that no ongoing transmission is disrupted. Different values are used for RT1 in the

two masters to ensure that link synchronization can be recovered if masters make "simultaneous"
(within the resolution of the carrier detect / framing mechanism) attempts to transmit.
The master will leave the USING state for the WATCHING state updating the retry count for this
message if either "RT1" times out, or an illegally addressed or garbled message is received. If a
correct response (ACK with status = OK or ERROR) is received, the transmission request has been
completed and the master will also transition to the WATCHING state. In this case, the link grant
timer ("RT2") is enabled.
At this stage the master is in synchronization in the WATCHING state. It monitors the link waiting
for "RT2" to expire. This allows the other master, or burst mode device as the case may be, if any,
on the link to transmit, if it needs to. Such a transmission by the other master must be initiated
outside the window defined by the carrier/ message detect delays around "RT2".
When there is no device in burst mode on the link, if "RT2" expires without the master detecting any
transmissions the master is "ENABLED". It can then re-transmit a current message if an incorrect
response (ACK with status = ERROR) was received and the re-try count has not been exceeded. It
may alternatively transmit any new message associated with a transmit request that it receives while
in this state or exit if no such request is pending. Note that if the master exits, (i.e., stops monitoring
the link), it is no longer synchronized and will have to go through the longer synchronization time-out
"RT1" before transmitting than the shorter "RT2" time-out if it is synchronized.
If, while waiting for "RT2" to expire, or in the USING state, the master detects a transmission on the
link, then it must presume that the other master is undertaking a transmission. In this case it must
now wait for as long as "RT1" or until it sees a response addressed to the other master on the link as
it did when first attempting to access the link.
If there is a device in burst mode on the link, sequencing of access among masters that might be
attempting to access the link is determined by burst mode messages. A master may only access the
link after a burst mode message addressed to the other master. Note that when a burst mode device
exists on the link, it is the only active device permitted on that link. It is assumed that on system start
up (from a power-off condition) a burst mode device will be up and bursting before hosts attempt to
communicate with it using these arbitration rules.

Figure 17 Master State Machine

2.4.5 Arbitration and Time-out Constants

Discussion of timer values for the protocol requires some assumptions about the functional behavior
of the underlying physical hardware and software. The assumptions in this section are based upon
the FSK Physical Layer. The following sections and timing diagram show how these lead to the
specified values for TTO, RT1, RT2, HOLD and BT.
2.4.5.1 Character formats

Individual characters are transmitted asynchronously and consist of eleven bits. These are, in order
of transmission, a start bit, eight data bits (least significant bit first), an odd parity bit, and a stop bit.
Characters forming a message must be transmitted in a single contiguous stream. There should not be
a single idle bit (e.g., additional start/ stop bits) between consecutive characters. Consecutive
characters in a frame must have intervening inter-character gap of less than 1 character time.
At 1200 bits per second (bps), transmitting a character takes 9.167 ms. This time period is referred
to as a character time. All of the following protocol timing information is expressed in units of
character times.
2.4.5.2 Timer model

Link arbitration is controlled by time-outs that represent lengths of time that devices executing the
protocol use to decide what they do next based on whether or not they hear transmissions on the
link.
Time-outs are measured as the interval between transitions of the protocol state machine.
Transitions are initiated when a transmission is completed or when a response is received (i.e.
preambles and frame synchronization are detected). Note that in the case where there is a finite
amount of time involved in deciding that a response is received (e.g., where enable.indicate is
mapped into a valid carrier detect together with a minimum number of valid preambles), it is possible
for a time-out to occur during the "transition". In this and all other such cases, processing of the
transition currently in progress is to be completed before any subsequent input to the state machine
(such as the time-out just mentioned) may be recognized.
Figure 18 shows the timer model assumed by the protocol arbitration process. This model assumes
the existence of a hardware generated clock with a clock "tick" period of T seconds. The model
assumes that transitions that initiate a protocol time measurement such as "RT1" are unsynchronized
with the timer ticks. This model yields a fundamental resolution uncertainty of -1/+0 ticks. It is
required that values of time-out intervals be measured with an accuracy of -0/+l character times,
implying that the calculated number of ticks corresponding to a measurement interval be incremented
by one before being used to generate a time-out.

3 Timer ticks, elapsed time = 2T

(worst case)
Carrier Detect
Timer tick
3 Timer ticks, elapsed time = 3T
(best case)
Figure 18 The Timer Model
2.4.5.3 Slave Time-out

The most fundamental protocol time-out is the slave time-out. This is the maximum amount of time
that it could possibly take a slave to respond to an incoming message. All other time-outs are based
on the value of this time-out. It critically controls performance of the system and should be made as
small as possible. It is identical for all slaves.
TT0 = 28 character times (256.7 ms) (1)
2.4.5.4 Master / Burst-Mode Time-outs

Figure 19 is a timing diagram for calculation of the value of "RT2" used during the link arbitration
process. The purpose of "RT2" is to allow the master devices to exchange control of the bus. It is
presumed that both masters have been monitoring the bus. The origin of the timing diagram is at the
instant in time when the last byte of the response from a slave is received by both of the masters.
This origin is established "identically" by both masters by processing the slave response and
counting off the number of bytes specified by the length field in the slave message. The diagram
assumes that this message was a response to a message from the master labeled "Master(0)". "RT2"
must be chosen large enough to allow "Master(1)" to start transmitting a message, and for
"Master(0)" to reliably detect that "Master(l)'s" message transmission has indeed begun. A
maximum response window of 20ms after detecting the end of the slave response has been allotted
for "Master(l)" to begin transmission. i.e.
HOLD = 2 character times (20ms) (2)

(0)
Slave Tx
(2)
Master(1) Tx CD Turn on
(3) (4) (5) (7)

Master(0) CD Timer slop
(8) (9)
Deserialization
RT2
Safety margin
Figure 19 RT2 Timing
After a 12-25ms delay for carrier detect circuitry to unclamp the receive data line, and a further 1-2
character delay for de-serialization in the UART (including inter-character gap) a valid preamble byte
will become available at the protocol interface in "Master(0)". A safety factor of one character time
is added. Note that it is assumed that the timer slop is -0/+l character time. The resulting value of
"RT2" is:
RT2 = 8 character times (75ms) (3)
Note that if "Master(l)" cannot begin transmission within the response window interval, it must defer
transmission for a period of "2*RT1" from the end of the response window interval, in order not to
interfere with "Master(0)'s possible use of the bus. This gives a polling master device an opportunity
to maintain synchronization on the bus. If no transmissions are seen on the bus after this interval, the
bus is considered to be free for access by either master.
For a burst mode device to see a message from a master device requires an identical calculation of
response margin. Thus the resulting value of BT is:
BT = RT2 = 8 character times (75 ms) (4)
Figure 20 is a corresponding timing diagram for the calculation of the value of "RT1" for "Master(0)"
and "Master(1)". The origin is the instant at which the last byte of a message to a slave device has
been transmitted by a master / received at the slave. Up to a maximum of "TT0" seconds can elapse
before the slave starts transmitting a response. A maximum of 25ms plus two character times
beyond this is required for valid preambles to be detected at either of the masters. For the higher
priority master, adding in the one character safety margin results in a value of "RT1(0)" given by:
RT1(0) = 33 character times (305 ms) (5)

Since "RT1" for the "Master(1)" must be long enough to resolve the result of "Master(0)" timing out
and re-transmitting, "RT1" for "Master(1)" is obtained by adding one character of margin for the
timer slop, a one character turn-around time for "Master(0)" on timing out, a maximum of 25ms for
carrier detect turn on delay, a 2 character de-serialization delay and a one character safety margin to
the value of "RT1(0)". The resulting value of "RT1(1)" is given by:
RT1(1) = 41 character times ( 380 ms) (6)
(0) Tx timeout (27)
Tx
CD Turn on
(28) (29) (30) (32) Response time

CD(0)
Timer slop
(34) (35)
RT1(0) Deserialization
(36) (37) (38) (40)
Safety Margin
CD(1)
(41) (42)
RT1(1)
Safety Margin
Figure 20 RT1 Timing

APPENDIX A: REVISION HISTORY
A.1 REVISION 7.1

The most significant changes are confined to Section 2.2. This section is almost completely rewritten
in order to clarify addressing, frame format, error detection and the slave's response when
communication errors are encountered. Only small clarifications are made elsewhere in the
document. The appearance of the DLL Specification was changed significantly as the result of
formatting the document as per the HCF standards.
A.1.1 Description of Changes
A.1.1.1 Section 2.2.3 is renamed as "Error Detection Coding". The wording was changed to
accurately reflect the required error detection coding and consistent use of "vertical
parity" and "longitudinal parity". The associated Figure is reworked.
A.1.1.2 Section 2.2.3.1 was added. This section and the accompanying table defines the slave
response when a communication error is detected.
A.1.1.3 The discussion of preambles was consolidated into Section 2.2.1: Preambles (in
Revision 7.0 the preamble specification is split between Sections 2.2.4 and 2.2.1).
A.1.1.4 The Specification was clarified to indicate the preambles are a physical layer issue and
the preambles transmitted can vary from 5 to 20.
A.1.1.5 A reference was added to Section 2.2.4 were the start character is defined.
A.1.1.6 What was Figure 2 was decomposed. The diagram defining the start character is in
2.2.4.
A.1.1.7 The discussion of addressing was consolidated into Section 2.2.2: Addressing (in
Revision 7.0 the preamble specification is split between Sections 2.2.4 and 2.2.2).
Subsections 2.2.2.1 Long Frame Addresses and 2.2.2.2 Short Frame Addresses were
added. What was Figure 2 was decomposed. Two diagrams defining the long and
short frame addresses were placed adjacent to the corresponding specifications.
A.1.1.8 The specification was clarified to indicate that it is the slave's responsibility to set the
burst mode bit correctly.
A.1.1.9 A note was added to indicate that only Command 0 supports short frame addressing
in order to maintain backward compatibility.
A.1.1.10 The composition of the long frame address is now clearly defined. A table was added
to indicate the preferred Device Type Codes for a given Manufacturer ID

A.1.1.11 Section 2.2 was modified to indicate that the characters in a frame are transmitted
contiguously and should not have any gaps between succeeding characters.
A.1.1.12 Since Section 2.2 is the first reference to the composition of a frame the diagram of a
frame was placed there.
A.1.1.13 Section 2.4.5.1, Character Formats, was revised to clarify this requirement.
A.1.1.14 The description of the Command byte in Section 2.2.4 was deleted.
A.1.1.15 Notes were added to Table 4 referencing the Universal and Common Practice
Command Specifications. The notes indicate that Command 59 is an optional
Command.
A.1.1.16 Section 1.3.1 was modified to be less restrictive and the references to the 4-20mA
loop were removed.
A.1.1.17 Section 2.4.3 now clearly states that a burst should occur immediately after a slave
response and must not start later that TT0.
A.1.1.18 Section 2.4.3 now indicates that a burst mode device must burst within TT0 after an
RT1 timeout waiting for a slave response.
A.1.1.19 Section 2.4.3 now states that only one burst-mode device may be active on a link at a
given time.
A.1.1.20 The definitions of the use of the dash (-) and tilde (~) characters were added to Section
2.4.1. In addition a comment indicating that the actions in the state machines
generally affect state variables was added.

Version History
HART
Revision 7.1 27Nov96
Revision 7.0 21Nov89
FIELD COMMUNICATION PROTOCOL
Document Title: HART SMART Communications

Protocol, Data Link Layer Specification
Document Revision: 7.1
HART Communication Foundation Document

Number: HCF_SPEC-81
Maintenance Control Distribution Control

Location of Original Master: Location of Copy Master:
Company: HART Communication Foundation Company: HART Communication Foundation
Address: 9390 Research Blvd., Suite I-350, Austin, Address: 9390 Research Blvd., Suite I-350,
TX, 78759, USA Austin, TX, 78759, USA
Distribution Contact: Foundation Director
Location of Electronic Archive:

Computer: PM7200
Archive copy path: Archive:SPEC:81:7.1:A
Approval Control
Company name / Persons title (Executive) Persons Name Persons Signature Date Signed

HART Communication Foundation / Director Ron Helson On File 10an97
Rosemount Inc. / Chairman Exec Comm Jim Cobb On File 2Jan97
ABB Instrumentation / Chairman Conformance WG Santokh Kandola On File 12Dec96
HCF/Senior Engineer, Editor Wally Pratt On File 9Dec96
HCF Form Number: HCF001, Rev C Total Number of Informational Pages: 55

(英文) HART数据链路层规范 SPEC 081 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

(英文) HART数据链路层规范 SPEC 081 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

HART Communication Foundation Document Number: HCF_SPEC-81

HART -SMART Communication Protocol: Data Link Layer Specification

Revision 7.1. 27 November, 1996 Page: 3 of 41

Revision 7.1. 27 November, 1996 Page: 4 of 41

1. INTRODUCTION AND OVERVIEW

1.3 Functional Requirements

1.3.1 Application Environment

Revision 7.1. 27 November, 1996 Page: 5 of 41

1.3.2 Device Types

1. HART-SMART Communications Protocol, FSK Physical Layer Specification.

2. HART-SMART Communications Protocol, Command Summary Specification.

3. HART-SMART Communications Protocol, Universal Command Specification.

Revision 7.1. 27 November, 1996 Page: 6 of 41

4. HART-SMART Communications Protocol, Common Practice Command

5. HART-SMART Communications Protocol, Appendix 1 - Command Specific

In addition, the documents:

Data Link Layer Slave, Structured Analysis. HCF_LIT-8. HART Communication

Data Link Layer Master, Structured Analysis. HCF_LIT-9. HART Communication

HART Slave Library Software Design. HCF_LIT-11. HART Communication

2. SERVICE AND PROTOCOL SPECIFICATIONS

2.1 Protocol Model

Revision 7.1. 27 November, 1996 Page: 7 of 41

Figure 1 HART Protocol Model

2.2 Frame Formats

Revision 7.1. 27 November, 1996 Page: 8 of 41

Preamble Delimiter Address Command Byte [Data] Check

Master to Slave Frame

Slave to Master Frame

Figure 2 HART Frame Format

A slave device should default to transmitting 5 preambles. If Common Practice Command 59 is

Revision 7.1. 27 November, 1996 Page: 9 of 41

6 Least Significant Bits of

1=Slave in Burst Mode

Figure 3 Long Frame Address

2.2.2.1 Long Frame Addresses

Revision 7.1. 27 November, 1996 Page: 10 of 41

Table 1 Device Type Code Allocation

Manufacturer ID Device Type Code Allocation

64-127 (0x40-0x7F) Begin at 239 (0xEF) and assign

2.2.2.2 Short Frame Addresses

The next two bits (4-5) must be set to zero.

The least significant 4 bits specify the polling address.

Revision 7.1. 27 November, 1996 Page: 11 of 41

Data Bit 7 Data Bit 0

4-Bit Polling Address

1=Slave in Burst Mode

Figure 4 Short Frame Address

2.2.3 Error Detection Coding

8 Data Bits "Longitudinal Parity"

Figure 5 HART Error Detection Scheme

Revision 7.1. 27 November, 1996 Page: 12 of 41

2.2.3.1 Slave Response

Table 2 Slave Action by Frame Field Upon Error Detected

2.2.4 Master to Slave or Burst-Mode Device Frames

Revision 7.1. 27 November, 1996 Page: 13 of 41

Figure 6 The Delimiter Character

6 Check Byte. This value is determined by a bitwise exclusive OR of all bytes of a

2.2.5 Slave to Master Frames

3 Command. Echoed from the incoming Master to Slave frame.

Revision 7.1. 27 November, 1996 Page: 14 of 41

2.2.6 Burst-Mode Device to Master Frames

Revision 7.1. 27 November, 1996 Page: 15 of 41

2.3 HART Protocol Services