Romilly's HART® and Fieldbus Web Site

Revisions of the HART protocol

Copyright © Romilly Bowden 1997-2015.

The current revision of the HART protocol specification is 7.1. 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

6.0

2001

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

6.4

?

 16-bit manufacturer ID.

7.0

2007

 Major enhancements ... WirelessHART™. New general-use commands #77, #84 to #104, #512, #513. New WirelessHART commands in the range #768 to #1023. Many commands extended. Trend data. New data type: time. Publishing on exception. Command aggregation. More status information. Commands #38 and #48 become Universal.

7.1

2008

 Extensive document corrections and clarifications.

7.5

2012

 New common-practice commands. Added Discrete and Hybrid Devices.

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. Revision 7 brings WirelessHART networking and many other enhancements. Some of 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 Revisions 5 and 6.

In HART Revision 7, the popularity of HART has resulted in further modification to this scheme. The manufacturer ID is now 16 bits instead of 8 (and is reported in an extension of the Command #0 data) and the "expanded device type code" remains at 16 bits but no longer includes the manufacturer ID as an identifiable part. This code is now allocated by the HCF for each new field device (starting at hex E080). Pre-HART 7 devices are unaffected by this change, retaining their existing 16-bit expanded device type codes. (The "254" indicator is still required.)


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 expanded 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.


WirelessHART™

HART Revision 7 introduces WirelessHART, a low-power wireless technology providing a mesh network operating in the unlicensed 2.4GHz ISM band with ranges up to around 200m between devices. The mesh structure means that communication paths from a field device to a Gateway can be redundant, and self-healing in the event of a communication problem or fault.

The required network management functions are provided by additional Network and Transport protocol layers, and use a new TDMA (Time Division Multiple Access) Data Link Layer to replace the Token Passing of FSK HART. Many of the new commands in HART 7 are primarily designed for the wireless network, but can also improve the flexibility and performance of wired FSK HART.

Battery or solar power are potentially valuable options, allowing field devices to be placed in locations where cabling is difficult or impossible.


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 fully support HART Revision 5 or later. 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:


Home        Top of page       
Home                 Top of page