HART PROTOCOL

---

What is HART?

---

HART (“Highway Addressable Remote Transducer”) is a popular digital communication protocol designed for industrial process measurement applications. The original and still most widely used version is the frequency shift keyed (“FSK”) version. The special feature of this is that it uses a low-level modulation superimposed on the standard 4-to-20 mA current loop which has been widely used for such measurements. Because the HART signal is small, and composed of sine waves, its average value is zero and does not significantly affect the accuracy of the analogue current signal, which can therefore still be used. This provides compatibility with existing systems, while allowing simultaneous digital communication for device configuration, status checking, diagnostics and so forth.

Later specifications cover a higher-speed 9600 bps option, and HART rev. 7 includes WirelessHART™, which offers high-speed short-range radio network functions using the 2.4GHz ISM band.

The signal of FSK HART looks like this:

---

The HART message structure

The structure of the FSK HART message is shown below:

The preamble, of between 5 and 20 bytes of hex FF (all 1’s), helps the receiver to synchronise to the character stream.

The start character may have one of several values, indicating the type of message: master to slave, slave to master, or burst message from slave; also the address format: short frame or long frame. Since HART rev. 6, it also indicates the number of bytes in the “expansion” field (see below).

The address field includes both the master address (a single bit: 1 for a primary master, 0 for a secondary master) and the slave address. In the short frame format, the slave address is 4 bits containing the “polling address” (0 to 15). In the long frame format, it is 38 bits containing a “unique identifier” for that particular device. (One bit is also used to indicate if a slave is in burst mode.)

The expansion field allows for up to 3 additional bytes to be inserted between the address and command fields. The number of bytes present will be indicated by bits 6 and 5 in the start delimiter. Use of this feature, introduced in HART rev. 6, is as yet undefined.

The command byte contains the HART command for this message. Universal commands are in the range 0 to 30; common practice commands are in the range 32 to 126; device-specific commands are in the range 128 to 253. HART rev. 6 introduced 16-bit “extended commands” for device family commands. These put 31 (hex 1f) in this byte, and the 2-byte command number as the first 2 bytes in the “data” field.

The byte count byte contains the number of bytes to follow in the status and data bytes. The receiver uses this to know when the message is complete. (There is no special “end of message” character.)

The status field (also known as the “response code”) is two bytes, only present in the response message from a slave. It contains information about communication errors in the outgoing message, the status of the received command, and the status of the device itself.

The data field may or may not be present, depending on the particular command. Universal and common-practice commands use up to 33 bytes of data, keeping the overall message duration reasonable. (But some devices have device-specific commands using longer data fields.) See also the HART data field.

Finally, the checksum byte contains an “exclusive-or” or “longitudinal parity” of all previous bytes (from the start character onwards). Together with the parity bit attached to each byte, this is used to detect communication errors.

---

Uses of HART

Using HART digital communication, up to four measurements (or more) can be transmitted in a single message. Multivariable instruments have been developed to take advantage of this. In addition, when using only digital communication, several instruments can be connected in parallel “multidrop” on a single pair of wires (with their analogue currents each set to a minimum value, usually 4 mA). Each device has its own address, so a host can communicate with each one in turn.

HART was developed by Rosemount Inc in the mid-1980’s, but has been made completely open, and all rights now belong to the independent HART Communication Foundation, which supports the protocol and oversees further development.

There are now upward of 200 member companies in the HCF, most of whom have HART products on the market. Virtually all measurement types are available, also valve positioners. A number of DCSs and PLCs provide HART-compatible inputs, so they can check device status, and read multiple measurements from a single field instrument.

---

Revisions of the HART protocol

---

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
• Major revisions
• Expanded device type code
• Long frame address format
• Command #0
• Commands #4 and #5
• WirelessHART™
• What must you do to be compatible?
• Field device designers
• Host designers
• Host software – how to begin communication
• Retries
• Other compatibility issues
• Future extensions
• HART Revision 2, 3 and 4 field devices

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.

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:

• Send command #0, with short frame format and 20 preambles. Start with polling address 0, then if multidrop operation is a possibility, try addresses 1 to 15 in turn.
• Look at the data in the reply. Check for “254” in the first byte (byte 0); if it is there, the reply is using the expanded device type scheme, with one byte each for manufacturer and device type. (This affects the location of subsequent bytes in the data field.)
• Look at the “number of preambles required” in byte 1 (un-expanded) or byte 3 (expanded). Use at least this many preambles in future outgoing messages.
• Look for the HART Revision (“universal command revision”) in byte 2 (un-expanded) or byte 4 (expanded).
• If the HART Revision is 5 or above, pick out the expanded device type code and device ID number, and build the complete 38-bit Unique Identifier. (Remember that the most-significant 2 bits of the expanded device type code (that is, the manufacturer code in revisions 5 and 6) are not used; you mustmask them off.) Then use the long-frame format and Revision 5 commands for future transactions.
• If the HART Revision is 4 or below, continue communication using the short-frame format and Revision 4 commands. (Use commands #4 and #5, if you need them, instead of #12 to #18). Or, if you do not support HART Revision 4, report the fact to your operator. (Don’t just say “Device not found” or “Communication failed”!)

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:

• Connect your 268 or 275 HART Communicator (you dohave one, don’t you?).
• Scan down the Review menu (a dedicated button on the 268, or Online/Device Setup/Review on the 275).
• With the 268, find “Software rev. x.y.z. “x” is the HART Universal Command Revision.
• With the 275, find “Universal rev.”

---

HART measurement variables, ranges and status

---

The primary variable (PV) of a HART measurement device is available both as a digital value, by HART communication, and as an analogue (usually 4-to-20 mA) signal. In fact, there are two representations of the PV in digital form: in engineering units (by Command #1 or Command #3 and others); and as a percent of range (by Command #2). In addition, the actual analogue output current in milliamps can be read by HART Command #3. Every HART message from the field device includes status information, in the form of 8 bits with pre-defined meanings, including two which describe the present state of these various representations of the measurement.

This note attempts to clarify the way in which these representations work when the measurement is out of range, and how this is indicated by the status bits. The preferred effect of a detected device failure on the analogue output is also described (though this is not part of the HART specification). The diagram below gives an overall picture.

First, let’s make clear the meanings of the various HART range parameters :

LRV and URV are the Lower Range Value and Upper Range Value, the two values of the PV which are to be represented by 4 mA and 20 mA respectively. You might have called these the “zero” and “full scale” (or possibly “span”) of a conventional analogue transmitter (though “span” should really mean the difference between the two). In general terms, this is the “range” of the instrument.

LSL and USL are the Lower Sensor Limit and Upper Sensor Limit. These describe the range over which the sensor works properly. Outside this range, the measurement may be unreliable.

A HART instrument digitises the sensor output over at least the range from the LSL to the USL. (If it doesn’t cover the full possible possible range of the sensor, then the range it does cover becomes the LSL and USL for the instrument as a whole.) This digitised value, once it has been converted, corrected, linearised or whatever, becomes the digital form of the PV. That is to say, the digital PV accurately represents the physical measurement over this range: LSL to USL.

Of course, the analogue signal cannot cover this whole range. It accurately represents only the range between the LRV and URV, with a small linear over-range allowance (typically from -0.6% to +105% of range).

It is common practice to indicate a detected device failure by forcing the analogue current value to a value outside the normal range, high or low by user choice, so that a control system can both respond safely, and (if set up with suitable alarm thresholds) can indicate the event to the operator. (This is not part of the HART specification, but is obviously a good idea, even for HART devices, since many hosts only use the analogue signal and do not make use of the HART status information.) For a discussion of this, see “Fault indication in Smart transmitters”.

So, looking at the diagram …

First, notice that the PV in engineering units can be read by commands #1 and #3, and is valid over the whole sensor range, irrespective of the analogue output range. The PV may also give useful (though maybe inaccurate) values beyond this range, or may indicate “not-a-number”.

Second, notice that the PV in “percent”, read by command #2, is also valid over the whole sensor range, although this may take its value far outside the range 0 to 100%. As a floating point variable, this is no problem. Beyond the sensor range (as for the PV in engineering units), the percent value may continue to be given or may be replaced by “not-a-number”.

However, the analogue output itself, and its digital value in milliamps read by command #3, is restricted to the configured analogue output range, plus the small allowable linear over-range from say 3.9 to 20.8 mA. In the event of a device malfunction, both analogue and digital values will be set outside this range, typically at 3.75 or 21.6 mA (depending on the configured choice of down-scale or up-scale fault indication). These are typical values used by a well-known transmitter supplier. NAMUR has recommended slightly different values (see “Fault indication” below).

Now, consider the status indicator bits …

If the measurement is outside the sensor limits, the “PV out of sensor limits” bit is set.

If the measurement is outside the linear analogue output range (LRV – 0.6% to URV + 5%), the “analogue output saturated” bit is set.

If a failure has been detected, the “device malfunction” bit is set.

Incidentally, it is not usually permitted to set the LRV or URV analogue output range values outside the LSL and USL sensor limits. The LRV can, however, often be set above the URV, to configure a reverse-acting analogue output.

---

Fault indication in Smart transmitters

---

One of the features of smart field devices is their ability to detect faults, either in the device electronics or in an associated sensor. Using HART, such faults are reported in the device status byte in every message (assuming that communication is still possible!). But, for the benefit of systems not using HART communication, it is still useful to follow the convention of indicating fault conditions by setting the analogue output current to a value which is recognisably beyond the normal operating range (including the small amount of linear over-range commonly allowed). If it is still alive, the microprocessor program should set the current output value to an appropriate value. Otherwise, a watchdog timer circuit may be able to do this, even if the microprocessor itself has failed. The intention is that a host system should be able to set alarm thresholds just outside the normal 4 mA to 20 mA range, to indicate measurement out-of-range, and to set further alarm thresholds to indicate a fault condition.

NAMUR Recommendation NE43 (18.01.1994) suggests the following:

• Measurement valid from 3.8 mA to 20.5 mA.
• Fault indicated by <=3.6 mA or >=21.0 mA.

However, not all instrument manufacturers follow the NAMUR recommendation. In particular, the 3.6 mA downscale fault indication value is regarded as difficult to implement in a smart transmitter, where every microamp of current consumption is carefully accounted for to support the demands of the microprocessor and sensor circuitry. One well-known supplier typically uses the values:

• Measurement valid from 3.9 mA to 20.8 mA.
• Fault indicated by <=3.75 mA or >=21.6 mA.

Fortunately, alarm threshold levels can be chosen which accommodate both these sets of values. A host system can set out-of-range alarm thresholds at 3.95 mA and 20.3 mA, and can differentiate between an out-of-range measurement and a fault, by further alarm thresholds at 3.78 mA and 20.9 mA.

In percent of range terms, these thresholds are -0.3% and +101.9% for out-of-range, and -1.4% and +105.6% for a fault. But remember to check that the values you use match the values actually used by your instrument supplier, if they don’t follow NAMUR.

---

HART cable lengths: H-Sim

---

The HART protocol is designed to work over existing analogue signal cables. But there are limits to how far it can go. The length of cable which can be used reliably depends on several factors. The main ones are:

• Loop load resistance
• Cable resistance
• Cable capacitance
• Number and capacitance of field devices
• Resistance and position of other devices in the loop.

Essentially, the requirement is that the network should pass the HART signal frequencies (1200 and 2200 Hz) without too much loss or distortion. The two main causes of loss are resistance (causing loss at all frequencies) and capacitance (causing loss at higher frequencies).

HART signal levels and receiver thresholds are specified in such a way as to allow for some loss, down to 0.66 of the current signal from a field device to a minimum-load master, or down to 0.3 of the voltage signal from the master to a field device.

As well as having sufficient signal amplitude, it is important that the two different frequencies making up the HART signal should be passed more or less equally well, to avoid phase distortion which could make the signal hard to decode. To assure this, the bandwidth of the network should be at least 2500Hz. This is the basis of the “65-microsecond rule”, which says that the product of the network resistance and capacitance should be less than 65 microseconds.

To determine the signal loss in a real network is easy enough, using an oscilloscope to inspect the actual signal levels. But to predict it in advance is not so easy. H-Sim is a Windows (3.0 or higher) program which solves a set of equations, representing a simplified model of a HART communication network. You may therefore find H-Sim useful in helping you design HART networks. However, you must ensure that the representation is adequate for your application. The User Manual gives full information about the equations and the circuit model.

You can use H-Sim to predict the signal level for a particular cable type and length, or to calculate the possible cable length which will still give a desired signal level. You should also apply the 65-microsecond rule to ensure that the network bandwidth is adequate. (A future version of H-Sim may include this check.)

H-Sim takes account of shunt diode (“zener”) barriers used in intrinsic safety (IS) applications, but does not deal with IS networks using active isolators or repeaters.

H-Sim is copyright, but the current version, H-Sim 0.5, is offered here free of charge.

When it’s running, the main screen looks like this:
 

Before

---

Now …

• Download HSIM05.EXE now into an empty directory.
   
• Check the file size. It should be 294,468 bytes. If it’s wrong, the download failed; try again.
   
• Run it, which expands it into the full H-Sim file set, in the same directory.
   
• Then run SETUP.EXE, which installs H-Sim and its associated files into another directory of your choice (C:\HSIM is the default, but you can choose something else).

The README.TXT file gives further information about installation. (The README file assumes you have H-Sim on a floppy disk, but you can just as well install it from its download directory on a hard disk, to another directory on the same or another hard disk.) After you have installed H-Sim successfully, you could well delete the download directory and all its contents.

The User Manual is included, as a Write document. You are strongly encouraged to print it out and read it!

By all means return the full registration form in the User Manual eventually, as well, and let me know how you find the product. E-mail is fine for that too, of course.

If you have any difficulty with downloading or installing H-Sim, please e-mail me.

New revisions of H-Sim will also appear here from time to time.

The HART data field

---

There has been some confusion about the length of the HART data field. An old version of the Data Link specification gave a 25-byte limit, but that document was withdrawn, and the current specifications apparently do not specify a maximum length.

The first and second editions of my “Technical Overview” booklet mention a 25-byte limit in several places, but this is wrong. As it says in the Preface, you should never regard the booklet as definitive!

Up until HART Revision 5, the Universal and Common-Practice commands have conformed to this limit, and most device designers have restricted themselves to 25 bytes or less for their Device-Specific commands. However, there do exist devices with Device-Specific commands using much longer messages for special purposes. The design of a general-purpose host may need to take account of this possibility.

HART Revision 6 includes new Universal Commands 20, 21 and 22 (using the new 32-character Long Tag) with data fields of 32 bytes (plus the two status bytes in a response). Also, remember that it is quite legal for the data field of any command to be extended in future revisions. Although slave devices are not required to understand any additional data bytes, they should either allow spare message buffer space, or use the byte count to track incoming data bytes, up to the check byte, so as to accept and check a message with an extended data field properly.

The protocol itself is unable to support more than 255 bytes in the data field, since the byte count has to be stated as a one-byte number (and this includes the two status bytes in a “response” message).

HART

URL	Destination
http://www.hartcomm.org	The HART Communication Foundation: the not-for-profit support organisation which owns the registered trademark “HART”, and all rights to the protocol itself. Provides information and support for vendors and users. You can download an “Application Guide”.
http://www.thehartbook.com	The HART Book – the web version of the printed magazine “The HART Book”. An extensive list of available products and suppliers. Also a reference section including an interesting and useful article on calibrating HART field instruments
http://www.rosemount.com/products/hart/index.html	Rosemount Measurement Division: the originator of the HART protocol. Probably still offers the widest range of HART products
http://www.analogservices.com	Analog Services have a large Technical Library section, including a 3-part article About HART and a useful Application Note on the design of HART devices
http://www.smar.com	Smar have information on HART, FOUNDATION Fieldbus and Profibus, including a general 6-page HART tutorial, downloadable as a PDF file
http://laguerre.psc.edu/	Pittsburgh Supercomputing Center has a good explanation of the IEEE754 floating point data format