7/28/2019 Hart 2

1/4

311

HARTHost System Issues and Guidelines

1. Introduction

This document brings together some of the issues confronting the developer of a HART host (or

master) device that may not be immediately apparent by reading the HART specifications. Becausehost applications will have a wide variety of functionality the developer must make informed

decisions on which capabilities of the HART field (slave) devices are to be accessed and exploited.

2. Physically connecting to a HART device

2.1. Input/output Subsystems

Connection to a HART field device is made using a HART interface that can support the connection

of one or possibly multiple HART networks. The Physical Layer specifications for HART require an

impedance of between 230O and 1100O.

If an I/O system is used that supports more than a single HART network then the capabilities andperformance of the system will depend on how many HART networks are supported by each HART

modem chip.

2.2. Outputs

Output devices may require the use of filters to limit the rate at which the output is driven by the

system such that the HART communications is not disrupted.

3. HART Revisions

3.1. Revision Support

HART field devices have been designed to three major revisions to date, Revisions 3, 4, and 5. By far

most devices have been designed to Revision 5 which has been in place since July 1989. Since that

time several minor revisions have been created to update table values and other improvements. Host

should always be designed to the latest revision of the HART specifications.

Revision 5 was a major change from the earlier versions and an interface designed to Revision 5 will

be able to identify but not communicate with a Revision 3 or 4 product. Therefore a Host developer

must make a decision whether or not the earlier revisions are to be supported.

3.2. Backward CompatibilityThe HART specifications contains a rule governing backward compatibility of a field device. If the a

new version of a HART product uses the same device ID code then all of the functions that were

previously supported must continue to be supported in the new version. This means that the host

application can operate on the newer product and obtain the same results and functionality as with the

earlier version. Newer features that may have been added to the field device would not necessarily be

known to the host application but would not interfere in its performance.

7/28/2019 Hart 2

2/4

312

4. Establishing Communication with a HART Field Device

4.1. Establishing Communications

All HART devices support the broadcast command #0 in the short-frame format regardless of their

revision level. This means that a host can easily determine the revision level of the device and other

communication parameters.

4.2. Polling Addresses

The short frame command #0 broadcast command provides for a polling address to support

multidrop networks. Typically a device is supplied by the manufacturer with the polling address set to

zero. For typical point-to-point installations issuing command#0 with a polling address of zero will

establish contact with the field device. (Also, see section on multidrop networking)

4.3. Obtaining the Unique ID

The major improvement in Revision 5 was to create a unique identifier for each field device

providing secure addressing in any environment. The information to create the unique id necessary

for communications can be obtained by issuing a broadcast command (0 or 11). This ID is acombination of the manufacturer code, device type code and device identification number. The 38 bit

unique ID is then used for all subsequent messages. The unique ID is not typically known to the end-

user therefore it is not a good practice for a host application to require the end-user to enter the unique

IDs for the devices that the application will be communicating with. The information can be obtained

automatically.

5. Primary/Secondary Master Arbitration

The HART protocol allows for both a primary and secondary master to communicate on the same

network. This is done by time sharing the bandwidth on the network. Each master (or host) must

observe the arbitration rules to allow the other master time to initiate messages to the field device.

6. Message handling

The HART specifications require any HART field (slave) device to implement the Universal

Command Set. Common-Practice commands are optional but provide a standardized way of

implementing many common functions. Device Specific commands are created for each product to

support its unique characteristics and features.

Although the Universal commands must be supported, the data contained in these messages does not

always apply to each device. It is acceptable for the command to be returned with the floating point

value of Not-a -Number. Enumerated values may contain the standard entry of 250 indicating the

field is not-used.

Sending a command to a field device that the device does not implement should result in a message

error response of 64, Command-Not-Implemented.

7. Device Descriptions

A Device Description (DD) provides a way for a manufacturer to specify the operation of a product in

a standardized format that can be used directly by an application, analogous to a PC printer driver.

7/28/2019 Hart 2

3/4

313

The DD contains information on each variable, command, and procedure used by a field device. DDs

eliminate the need to provide hard-code for each device and to allow the application to easily

accommodate new products as they become available. There is a software tool set called Device

Description Services available from the HART Communication Foundation that facilitates the use of

DD technology by a host application.

8. Generic Device Support

A host application may choose to provide complete support only for specific products based on the

application or other considerations. In that case it is recommended that the host provide a more

limited generic interface that will allow communication with ANY HART product. A typical

generic interface would include the Universal Commands and a selection of common-practice

commands.

9. Multidrop Networking

9.1. Addressing options

The HART protocol provides two mechanisms for implementing multidrop networks. First is the useof the polling addresses in the command #0 broadcast command. If each device placed on the network

is given a different polling address, the host application and issue a broadcast command to each one

to obtain the information for the unique ID. Polling addresses can be in the range of 0-15 allowing up

to 16 devices on a single HART network. Setting the polling address to a value greater than zero also

sets the analog output of the device to a fixed value, usually 4 ma.

A second method of addressing networked instruments is through the use of the 8 character TAG ID.

The broadcast command #11 allows the host to establish communication with the device with TAG

ID matching the one in the command data field. This requires the end-user to be sure that the TAG ID

in the field device is identical to the one the application expects. This approach has the added

advantage of not being restricted to the 0-15 addressing limits of the polling address. This can beuseful in remotely networked applications using radio, or telephone telemetry.

10. Burst Mode

The Burst Mode of operation is an option in the HART protocol and therefore is not implemented in

all field devices. Burst modes provides a mechanism for a device to continuously broadcast one

specific command until told to stop. This provides a message update rate of over 3 times per second

for command #1 (PV). The Burst mode arbitration mechanism provides for both a primary and

secondary master to gain access to the device to disable the burst mode or issue another command.

Refer to the specifications for details on this implementation.

11. Host Functionality

A HART host has almost unlimited freedom in the functionality that it chooses to provide. While this

is necessary, it also can create confusion for the end-user. Most end-users are familiar with the

handheld configurators that provide access to all of the capabilities in a field device. However most

other host applications are more narrowly focused. A host may choose only to monitor the PV and

provide a straightforward monitoring application. Other hosts may choose to provide full access to

the variables and parameters in the field device for diagnostic and maintenance capabilities. It is

7/28/2019 Hart 2

4/4

314

important for the supplier of the host application to provide details of the implementation describing

which parameters and functions are supported.

12. Multliplexers

There are several multiplexers on the market that provide support for HART networks. They have a

range of capabilities that cover maintenance, data acquisition, and control applications. These

multiplexers provide a means for a single host application to gain access to multiple HART networks

and not be limited to the serial I/O capacity of the host computer. One class of multiplexer uses amodified HART protocol together with the RS485 standard. A second type of multiplexer acts as a

protocol gateway by communicating with the host application using Modbus, TCP/IP and other

protocols.