HART Feature Summary
HART Protocol Revision
Feature
5
6
7
PV with Status
m
m
m
Device Status
m
m
m
Broadcast Messaging
m
m
m
Device Configuration
m
m
m
4-20 mA Analog Loop Check
m
m
m
Multi-Variable Reads
o
m
m
32 Character Tag
-
m
m
All Variables with Status
-
m
m
Digital Loop Check
-
m
m
Enhanced Multi-Variable Support
-
m
m
Local Interface Lock
-
o
o
Manual ID of Device by Host
-
m
m
Visual ID of Device
-
m
m
Peer-to-Peer Messages
-
o
o
Report by Exception
-
-
o
Synchronized Sampling
-
-
o
Time or Condition based Alerts
-
-
o
Time Stamp
-
-
m
PV Trends
-
-
o
Wireless Co-Existence
-
-
o
Wireless Diagnostics
-
-
o
Wireless Mesh & Star Topologies
-
-
o
Wireless Message Routing
-
-
o
Wireless Security
-
-
o

m = Mandatory   o = Optional  


Changes moving from HART 5 to HART 6 without Burst Mode

  1. Device Variable Classification - Required

Provides master applications with a simple mechanism to determine the number and type of process related variables (pressure, temperature, etc.) that are available within a device. A key enabler for many HART 6 improvements, this mechanism provides master applications with considerable information about device capabilities. (Commands 0, 8)

  1. Extended Device Status - Required

One additional byte of well defined status information with Command 0 and new cyclic data access Command 9. This new Extended Device Status byte is in addition to the current device status byte returned with each command response. Provides additional device status alerts such as “Device Needs Maintenance” plus more. (Commands 0, 9)

  1. Device Variable Status - Required

One byte of well defined status for each Device Variable returned by new cyclic data access Command 9. Enables field devices to self-validate and report on the quality of the data in the command response (good, poor, bad, fixed) plus more. (Command 9)

  1. Long Tag - Required

This new Long Tag with international (ISO Latin 1) characters allows consistent implementation of the longer tag names required by many industry users. The specifications currently reflect the length of this tag to be 32 characters as outlined in the Long Tag proposal approved by HCF members in January 1998. (Commands 20, 21, 22)

  1. Configuration Change Counter – Required

Improved mechanism for master applications to determine that a field device configuration has been changed. Protects integrity of plant configuration databases. (Command 0)


Changes moving from HART 6 to HART 7 without Burst Mode

  1. Expanded Manufacturer Codes - Required

Widespread growth and adoption of the HART Protocol has resulted in the available code space for 8-bit Manufacturer ID Codes being exhausted. Resolution requires the expansion of Manufacturer ID Codes from 8-bits to 16-bits. Previous addendums to the Data Link Layer Specification, Command Summary Specification and Universal Command Specification that are proven and already in use have been incorporated into the HART 7 revision of the HART Protocol Specifications.


For existing 8-bit manufacturer ID’s:

8-bit manufacturer IDs will be padded with 0 for the MSB. The expanded device type will be the 8-bit manufacturer ID and the device type assigned according to the rules of HCF-99.

 (Command 0, Command 11, Command 21)

  1. Private Label Code and Device Profile

Command 0 now contains the private label code and the device profile in addition to the other changes outlined above. Command 15 now returns value 250 in place of the private label code.

The Private Label code in command 0 will be set to the manufacturer ID if the manufacturer and distributor are the same.

The Device Profile uses enumerations from the Common Tables.

(Command 0, Command 15)

  1. Time Stamped Data - Required

New Data Type (Time) for Time Stamping of Device Variable Values in Universal Command 9 response. This new capability enables the Time Stamping of process variable values at the Field Device and their reporting to host applications via Command 9 with the Time Stamp or time interval from the previous value. Also, Common Practice Commands to set the device time of day have been added.

The time stamp does not have to be a real time clock. The time stamp could be a monotonic counter that resets every 24 hours.

(Command 9)

  1. Expanded number of device variables in Command 9 – Required

Command 9 previously only allowed up to 4 Device Variables to be accessed in a single read. Command 9 can now include up to 8 device variables. This provides the opportunity to access more data with a single transaction. (Command 9)

  1. Support of 6 device variables – Required

Mandatory Device Variables are now defined:

244 Percent Range

245 Loop Current

246 Primary Variable

247 Secondary Variable

248 Tertiary Variable

249 Quaternary Variable


The 6 device variables listed above must be implemented in every HART 7 devices. These device variables are not reported in the Command 0 response. Please note that if the device does not support device variables, the command 0 response will indicate 0 for the last device variable code supported.


The device is not required to implement more than these 6 device variables. If the device does not implement device variables other the ones listed above, the device will also need to support PV for device variable 0, SV for device variable 1, TV for device variable 2, and QV for device variable 3.


When a Device Variable requested (or dynamic variable) is not supported in the Field Device, then the following must be reported for the listed information:

Value must be set to "0x7F, 0xA0, 0x00, 0x00"

Status must be set to 0x30, (i.e., Status = "Bad" and Limit = "Constant")

Units Code must be set to "250" Not Used

Device Variable Classification set to "0", Not Yet Classified.


There is a device variable required for wireless devices in addition to the ones already listed:

243 Battery Life

  1. Command 38 behavior modified – Required

Command 38 now returns the configuration change counter. Upon receiving this command the device now compares the Configuration Change Counter received in this command request with the device's current value. If they do not match then the device must return "Configuration Change Counter Mismatch" and not reset the Configuration Changed bit.

Field devices receiving Command 38 with no data bytes must assume the Master is HART Revision 6 (or earlier) and reset the appropriate configuration changed bit. (Command 38)

  1. Upgrade of Command 38 & 48 to Mandatory - Required

These Common Practice Commands for Device Specific Status and reset of the Configuration Change Flag are upgraded to “Universal” status with HART 7. (Command 38 and Command 48)

Command 48 can reset the more status available bit if the device has had no other changes since the last report.


Optional Changes Moving from HART 5 to HART 6

  1. Device Families Optional

Establishes standard commands and status indicators for devices based on the type of process connection. Standard commands allow simple master applications to more fully communicate and configure devices without having to rely on the complexity of DDL. Initial Device Families for Temperature and PID Control are included in the specification package. The Valve Positioner / Actuator Device Family is in final preparation.

  1. Transducer Trim Commands Optional

New Common Practice commands for performing transducer trim (calibration) operations.  Reduces need for device specific commands to perform this common function.  Standard commands make it easier for master applications such as field instrument calibrators to perform calibration functions on all HART devices.

  1. Delayed Response – Optional

The Delayed Resposne Mechanism(DRM) enables the slave to indicate to a master that it received the request but is not able to formulate a reply in the time allowed by the Data Link Layer. This mechanism provides an informative and flexible convention for slave devices needing additional time to perform relatively infrequent operations like self diagnostics, calibration, or configuration. Unlike the Response Code BUSY, the master knows that the slave has understood the command is still communicating. This is optional unless the HART 5 product used busy. If the HART 5 device used busy, then DRM is mandatory (No commands necessary)

  1. Sub-Devices Optional

A simple mechanism using Common Practice Commands to support “HART device within a HART device” functionality. Potential uses include flow computers and multi-channel temperature devices.

  1. Block Data Transfer Optional

An updated mechanism to support the movement of large blocks of data between masters and field devices. Potential uses include the movement of diagnostic information stored in the field device and upload/download of device configurations.

  1. Catch Device Variable Optional

A simple mechanism using Common Practice Commands to support the sharing of process data between field devices on the same HART network. Allows a listening field device to capture process data from another field device to be used in calculations such as tank gauging, flow computers or PID control functions.

  1. Write Device Variable Optional

New Common Practice Commands to support forcing the digital value for any Device Variable to a specific value to aid in commissioning and troubleshooting.

  1. Lock Device Optional

New Common Practice Commands allow a master application to lock the “local” front panel of a field device while performing remote configuration functions.

  1. Squawk and Find Device Optional

New Common Practice commands to support commissioning and troubleshooting of HART devices in multi-drop and multi-pair cable installations.


Optional Changes from HART 6 to HART 7

  1. Wireless – Optional

A major new enhancement to the HART technology providing additional capabilities to monitor the performance of plant assets in areas that were uneconomical or technically difficult with wired systems. This new enabling technology provides reliable, robust and secure wireless communication using standard IEEE 802.15.4 radios at 2.4 GHz for global application with Channel Hopping, Mesh Networking and robust Security appropriate for process applications.

  1. Enhanced Sub Device & I/O System Commands – Optional

New Common Practice Commands have been defined to support the set-up and operation of Wireless Adapters and I/O Systems. (Command 101, 102, 77, 84, 85, 86, 87, 88, 94)

  1. Enhanced Burst Mode including events, trends, and burst data – Optional

Burst mode communication has been enhanced to allow the bursting of more than one HART message and the ability to specify time interval or frequency for how often the message is to be sent (burst frequency). A form of event reporting is also defined enabling devices to automatically send message noting a change in Command 48 status or a change to the Configuration Change Counter. (Command 103, 104, 115, 116, 117, 118, 119)

  1. Flush Delayed Response – Optional

If the product implements the Delayed Response Mechanism(DRM), the device must allow the master to flush the DRM buffers. The master may request the device to clear all pending delayed responses for the Master that issues the command. Delayed responses currently running that must not be interrupted or aborted may be completed. (Command 106)

  1. Read Trend Command – Optional

New Common Practice Command to read multiple values (or the trend) for a specified Device Variable. (Command 91, 92, 93)

  1. Aggregated Read Command – Optional

New Common Practice Command to support expedited upload of Device Configuration enabling more than one command response to be read at a time. (Command 78)

  1. Synchronized Actions – Optional

Synchronous Actions are used to defer a device activity or action to a specified, future time. The Action could be to simply synchronously sample a single measurement (i.e., a Device Variable), triggering a (e.g., vibration) waveform acquisition, an automatic calibration cycle, or some device specific procedure. In addition, this allows measurements or other operations performed by multiple devices to be synchronized. (Command 89, 90, 96, 97, 98, 99)

  1. Common Tables Additions – Optional

New Common Tables Additions to support Wireless and all other enhanced functionality.

  1. Discrete Applications – Optional

This new Specification establishes the framework for defining the application of HART Communication to devices for point detection or discrete on/off type functionality.