Understanding HART status information

Using HART protocol is more effective when connected instruments provide status information back to the control system, providing reliability about the process variable, instrument reliability and troubleshoot. Learn nine HART statuses. See HART status diagram.

By James Powell, P.Eng. July 13, 2021

 

Learning Objectives

  • HART commands help with understanding HART protocol.
  • Status coming back in all HART commands.
  • A HART smart card can show the control systems what information is being provided.

One of the most significant benefits of having a Fieldbus is having the instrument provide status information back to the control system. Questions such as: Can I trust the process variable? Is the instrument working correctly? What is the problem with the instrument? All can be answered with this status information.

Highway Addressable Remote Transducer (HART), a protocol now administered by the FieldComm Group, has been around for a long time. It was the first open Fieldbus and is used in process manufacturing industries. For most of its history, the status information has been hidden inside the instruments and only looked at when a maintenance person attaches to the instrument via a HART modem. With the deployment of HART smart cards, the status information built into HART can be viewed by the control system.

Nine types of HART statuses

HART has a rich amount of status information. The challenge in understanding HART statuses is there are several different statuses, many of which are called status:

  1. Status
  2. Response code
  3. Communication status
  4. Device status
  5. Extended device status
  6. Condensed status (setting in the device)
  7. Device variable status
  8. Device family status
  9. Additional device status.

The reason for so many statuses is historical. The protocol has evolved over time along with the idea of statuses. The key to understanding HART status information is to look at it from a HART command point of view (see Figure). Once they’re seen this way, it becomes easy.

HART commands

HART is a query/response type protocol with many different commands that have grown over time. Some are general commands, and others are specific to one instrument. Most end-users never need to know about HART commands it use HART. However, if the end-user wants to benefit from status information coming back from the instrument, then have a rough idea about the HART commands is useful. The commands are divided up into three classifications:

  • Universal commands, which are commands 0 to 30. These are commands every HART slave must support. In V7 of the protocol, commands 38 and 48 were added to the universal commands.
  • Common practice commands are commands 32 to 121. These commands are common to many types of devices, which the device manufacturer has the option of using or not.
  • Device-specific commands are commands 128 to 253. These commands are fully defined by the device manufacturer.

Status coming back in all HART commands

All HART commands return two bytes of statuses. The first byte is called the response code. If the response code is 0x00, then communication is good, and the device was able to process the command without an error. If there is a problem with communication, then the response code contains the communication status.

If communication was okay, but there was an error in processing the command, then the response code is returned in the first byte.

The second byte of the status is the device status. This indicates the current operating health of the field device as a whole.

Before HART V6, if there were a communication error, the device status would be meaningless. In HART V6 and above, it is now required this value is meaningful in every response. The charts above are for HART V7. These charts have been evolving. Bits have been added, but none removed. Some meanings have also evolved.

For example, in HART V7, a process problem like “loss of echo” would have the device issuing a device status value of 0x90 (0x80 + 0x10), meaning users cannot trust their primary variable and there is more status available. A HART V6 device would issue a 0x80 only if a device malfunctioned, and a “loss of echo” would cause only a 0x10 value.

HART extended field device status

The extended field device status is returned in commands 0, 9, 48, 78, 119, and 64386. This status is one byte long. Traditionally, only the first two bits were used:

  • Bit 0 – Maintenance required. If this is set, the device has not malfunctioned but does require maintenance.
  • Bit 1 – Device variable alert. This is set if any device variable is in alarm or warning state. If the NAMUR NE107 condensed status selection is set, in the field device, then the following five bits of the extended field device status are used and mean the following:
  • Bit 2 – Critical power failure
  • Bit 3 – Failure
  • Bit 4 – Out of specification
  • Bit 5 – Functional check.

NAMUR is an organization made up of several large chemical companies in Germany/Europe. As a group, they have published many different documents they call “Recommendations.” These are essentially specifications on how they would like something done.

NE 107 is entitled “Self-Monitoring and Diagnosis of Field Devices.” It talks about the importance of statuses to the operation of a plant and how best it should be done. When NAMUR NE107 condensed status is turned on in a HART device, the additional bits in the extended field device status result in the device complying with the recommendations in NE 107.

HART device variable status

Device Variable Status is a measure of the overall health of the variable being read. The chart provided gives the general meanings of this status:

HART device family status

Device family status is part of the device variable status. HART has a series of “device family specifications” for different types of field devices such as temperature, level, flow, etc. Each family will define the meaning of these four bits and may define the entire byte. These specifications have been at various levels of release, so many vendors have defined their codes here in the absence of a released specification. For decoding the device variable status and the device family status, it is best to consult either the field device manual or the HART field device specification document (Lit 18) for the device.

HART additional device status

HART command 48 is used to read additional device status. The response message contains 25 bytes of data. Bytes 0 to 5 and 14 to 24 hold the device-specific status which corresponds to the error display codes shown on the screen of the device. The mapping is related to bit location of the bit value ‘1’ in the device-specific status.

For example, if there is a “1” located in bit 4 of byte 0 of the response message, then that will correspond to an error code 4. If byte 2 of the response message has a 1 in bit 0, then it would be code 2*8+0=16.

HART command 48 has also evolved. It was a common practice command, and now in HART V7, it is a universal command. It has also expanded in size as well, adding more bits to extend the possible error messages.

To properly decode this, users will need either the device manual or the HART field device specification document (Lit 18) for the device.

HART commands help with understanding HART protocol

HART has a rich amount of status information. However, given the HART protocol’shistory, the status information can appear complicated unless users look at it from the point of view of the HART commands. When view in this manner, the status information then makes sense. For the end-user, then can then look at their HART smart card and easily determinate what information is being provided.

This article is adapted from the information presented in “HART Communication Protocol – A Practical Guide” by James Powell.

James Powell, P.Eng., is the principal engineer and owner of JCOM Automation Inc. Edited by Mark T. Hoske, content manager, Control Engineering, CFE Media and Technology, mhoske@cfemedia.com.

KEYWORDS: HART protocol, HART status

CONSIDER THIS

Are you using all the instrument status capabilities HART can provide?


Author Bio: James Powell, P.Eng., is the Principal Engineer and owner of JCOM Automation Inc. in Peterborough, Ontario, Canada. James is an expert in Profibus, Profinet, EtherNet/IP, Modbus and HART. He has written “HART Communication Protocol – a practical guide” and co-authored “Catching the Process Fieldbus – An introduction to Profibus and Profinet.”