Romilly's HART® and Fieldbus Web Site

Revisions of the HART protocol

Copyright © Romilly Bowden 1997-2005.

The current revision of the HART protocol specification is 6.3. All new field devices and hosts should follow this revision. But what came earlier? And what should you do about it?


Introduction

In the mid-1980s, Rosemount Inc. developed a proprietary digital communication protocol for their smart field instruments. This soon evolved into HART, and was made an open protocol with Revision 2.1 in 1986. Since then, the capabilities of the protocol have been enhanced by successive revisions to the specification, including new commands, additional manufacturer and engineering units codes, protection against cross-reception of messages and improved reporting of command errors.

This note summarises the major changes that have been made, and suggests how instrument and host designers should treat them. Users may also be interested to ensure that the host equipment they use can operate properly with the field devices they have. As always, refer to the full specifications from the HART Communication Foundation, for more details.


Major revisions

The main changes were:

Revision Date introduced Features

2

1986

 First public specification. Commands #0 to #6, #33 to #48.

3

1987

 New command #49

4

1988

 Improved support for multiple variables. Write-protect status. Optional type-code expansion. New commands #50 to #56.

5.0

1989

 Long frame format, unique identifier. Burst mode. Block commands #4 and #5 replaced by new commands #12 to #18. New commands #11 to #19, #57 to #59, #108 to #112. Improved data link and physical layer specifications.

5.1

1990

 Support for multiple analogue outputs and non-current analogue outputs. New commands #60 to #70, #107.

5.2

1993

 Physical layer specification revision 7.2

5.3

1994

 Minor update to tables

6.0

2001

 Major enhancements ... Long tag (32 characters). Better support for multivariable devices and actuators. More device and variable status information. Device families. Block data transfer. New commands #7, #8, #20 to #22, #71 to #75, #79 to #83, #106, #111, #112. Many other commands extended. Most specs re-written for clarity.

6.1

 

 

6.2

 

 

6.3

 

 

With each revision, many of the common tables were extended, for example to accommodate more codes for manufacturers, units and materials. Revisions 5.0, 5.1 and 5.2 included better specifications for the HART physical layer, to assure better reliability and compatibility.

From Revision 5.0 onwards, changes have maintained compatibility with older devices. New commands have been added (never removed) and data fields of existing commands have been extended (never shortened). But this was not always so. In particular, Revision 4 introduced the manufacturer identification code, and the step from Revision 4 to Revision 5 brought significant changes in device addressing. These changes are described below.


Expanded device type code

In HART Revision 4, an option was introduced to allow manufacturer and device type to be coded separately, instead of as a combined 8-bit number. To indicate that this expanded form is used, a field device inserts "254" (hex FE) as the first data byte in its response to command #0. Then the next two bytes contain the manufacturer and device type codes. The expanded form continues in HART Revision 5, and is now mandatory.


The long frame address format

HART Revision 5 introduced the long frame format, including a "Unique Identifier" (Unique ID) as part of the device address in each message. This Unique ID is formed from a concatenation of the manufacturer code, the device type code, and a device ID number. The device manufacturer must ensure that the device ID number is unique, for each device having a particular device type code. It is rather like a serial number, but doesn't have to be the same as the serial number on the label. The complete Unique ID is (almost) world-wide unique for every HART device.

The advantage of this address format is that the wrong device never accepts a communication (even if signals are coupled between different HART loops due to poor installation).

Since security is now assured by the Unique ID, the previous requirement, that any device-specific command must include the device type code as its first data byte (in both command and response), is cancelled as from HART Revision 5. In moving from Revision 4 to Revision 5, existing field devices must drop that first byte from their data field specifications.


Command #0

For new devices, the only exception to the use of the long address form is Command #0. In Revision 5 (and above) a field device must support both short and long frame address forms of this command, so that a host can start communication with a field device without knowing its Unique ID. The response to command #0 includes the necessary data items for the host to construct the Unique ID.


Commands #4 and #5

In HART Revision 4 and earlier, commands #4 and #5 were used to read and write certain device data (called "common static data") including tag, descriptor, date, message, and device range and transfer function information. These commands used a "block number", 0 to 3, to select particular sets of data. In HART Revision 5, these are replaced by commands #12 to #18, abandoning the rather clumsy "data block" paradigm.


What must you do to be compatible?

Field device designers

Field device designers must implement HART Revision 5 (or later), using the long frame address format. The device must also support Command #0 in both short and long frame forms.


Host designers

Host designers should support HART Revision 5 (or later) fully. But you also have a decision to make: will you support older devices?

If you intend your host only to be used with new field instruments, then there is no need to support anything before HART Revision 5. But if you want to attach to existing field devices, or your user may have older devices as spares, you should consider supporting Revisions 3 and 4. There are quite a lot of pre-1989 instruments out in the world. At the very least, you should detect that you have connected to a Revision 3 or 4 device, and report this in a friendly manner to your user. Otherwise there may be a long and pointless argument about why communication isn't working.


Host software: how to begin communication

The procedure when first connecting to a field device can be as follows:


Retries

Hosts are recommended to try three times before giving up, if communication is expected but fails. It may be helpful to use 20 preambles for retries.


Other compatibility issues

Future extensions

In future revisions of the protocol, it is always possible that the HART Communication Foundation may add further items to the data field of any universal or common practice command. And in later revisions of a field device, the device manufacturer may add further items to the data field of an existing device-specific command. (Removing a data item, or changing its meaning, is not allowed.) To allow for such extensions, a field device or host should always take note of the "byte count" field in every message received, and expect to receive that many bytes of data before the checksum byte. It is then quite in order to ignore any bytes beyond those that you understand.

The HART common tables (unit codes, etc.) are also liable to extension in future revisions, but nothing is ever deleted. If a host uses the latest versions, it is quite possible that an older field device may reject a code value sent to it; the host should accept this and show a helpful message to the operator. Conversely, a new field device may report a code value that an older host does not recognise; the best thing to do is to display the un-decoded value with a polite message.

Refer to the HCF-SPEC-99 for the full compatibility rules.


HART Revision 2, 3 and 4 field devices

Early Rosemount and Micro Motion instruments using HART revisions 2, 3 or 4 include:

Instrument Rev 2 Rev 3 Rev 4 Rev 5
1151S Y Y Y Y
3001C     Y Y
3001L Y     (obsolete)
3044     Y (obsolete)
3051 Y Y   (obsolete)
3051C     Y Y
8712   Y Y Y
9712     Y Y

(If anybody knows of others, please let me know.)

Users! The model 268 and 275 handheld communicators support these older revisions. But some host software doesn't. (If in doubt, ask your host supplier.) If you want to find out the HART revision of your instruments, to be sure you won't have a problem:

Comments welcome, to the author: romilly@romilly.co.uk.


home        top of page        consultancy
 
            Home              Top of page              Consultancy