HART Networks

By Wally Pratt, HCF Chief Engineer

April 2002

HART enhances the 4-20mA standard by providing two-way communication with smart field devices. The two-way communication is modulated onto the 4-20mA signal at a higher frequency than normally observed by process control equipment. This allows communication via HART to occur simultaneously with 4-20mA signaling. Since HART field devices are fundamentally 4-20mA devices, backward compatibility with existing plant systems and personnel is maintained. Consequently, plant personnel can utilize HART-compatible field devices with little knowledge of the Protocol and gradually adopt HART Protocol features at their own pace. In some cases plant personnel may even unknowingly utilize the HART Protocol (e.g., via a hand-held communicator) during the course of their normal workday. HART has been well established and accepted for many years. Device types are available supporting both mainstream and niche process instrumentation needs. In addition, many multivariable instruments are available to simplify system design and reduce costs. In addition to supporting the 4-20mA standard, HART-compatible field devices provide (for example): digital process variables (in IEEE 754 floating-point) with standardized engineering unit codes and status; device status in every response from the field device allowing system integrity to be continuously monitored; and extensive calibration support and diagnostic information.

Significant benefits can be realized by utilizing capabilities that are found in all 4-20mA HART compatible field devices. In this article we will: provide an overview of basic HART capabilities; review the architecture of smart field devices; allow the evaluation of HART compatible equipment and software; and summarize the evolution of HART.

This article will not focus on bits and bytes, provide guidance on the development of a HART field device, or provide all the details a system integrator may desire. Other resources are available to fill that need at no cost or for a nominal fee. Instead, the focus here is on the capabilities provided by the HART application layer and the benefits they provide. Note: Unless otherwise noted, all features and capabilities discussed in this section are standardized in the HART Specifications and the vast majority of the features are mandatory (i.e., universal). Consequently, any host can support the capabilities

Page 1 of 1

discussed in this section with moderate development effort and without requiring any device-specific drivers.

Evolution of the "Smart" Field Device

A Smart Field Device is a microprocessor-based process transmitter or actuator that supports two-way communications with a host, digitizes the transducer signals, and digitally corrects its process variable values to improve system performance. Many field devices contain sophisticated signal processing algorithms to perform the measurements or control action required. The value of a smart field device lies in the quality of the data it provides. Both HART and the capabilities of smart field devices were developed in tandem. When HART was invented, smart field devices were just beginning to emerge. Most field devices were analog and most of the engineers developing smart field devices had little experience with microprocessors. Consequently, engineers did not have a clear image of the benefits a microprocessor could provide to their product. Since 4-20mA transmitters provide a single process variable to the control system via the loop current, early HART development focused on the primary process variable (PV). In HART, PV includes all the properties and data items necessary to support the loop current (see Fig. 4.10a). HART Universal Commands provide access to all loop current data and properties. Process values associated with PV include the digital value, percent range, and loop current. Properties of the PV include Upper and Lower Range Values, Upper and Lower Transducer Limits, Transducer Serial Number, and Minimum span. Status information includes Loop Current Fixed, Loop Current Saturated, PV Out Of Limits, and whether or not the device has malfunctioned.

Soon developers began finding many uses for the microprocessor. Most development efforts focused on improving accuracy and reliability. For example, adding an ambient sensor (e.g., temperature) along with linearization and compensation software dramatically improved accuracy. Even simple pressure and temperature transmitters now have an embedded temperature sensor. Today, virtually all HART field devices are multi-variable, and even more sophisticated multivariable field devices are becoming available all the time. For example, there are: pressure transmitters that provide the sensor temperature; level transmitters that can calculate volume; and flow meters that contain totalizers and perform data logging. The growth in multi-variable field devices continues to accelerate as microprocessor capabilities increase and power requirements decrease. At the same time, HART communication has evolved to provide access to secondary process variables in multi-variable field devices.

Page 2 of 2

"PV"
Pressure = 42.5 kPa

Loop Current Pressure

Upper limit Lower limit Serial number Minimum span

Loop Current = 10. 4 mA

Range
Upper range value Lower range value Transfer function

DAC
Alarm level DAC trim

Percent Range = 40%

Temperature = 26.2C

Temperature Device Information

(e.g., materials of construction)

HART
(communication parameters)

Fig. 4.10a Smart pressure transmitter HART was initially developed by transmitter companies and then later adopted by intelligent valve controllers. Unfortunately, most systems manufacturers have been slow to accept and fully support HART. As a result, todays huge installed base of HART-compatible field devices offers a wealth of largely untapped capabilities. However, an increasing number of systems suppliers are beginning to recognize the potential of HART. The continual growth of multivariable field devices provides additional encouragement to suppliers to add support for HART or to improve existing support.

THE EVOLUTION OF THE HART PROTOCOL HART was invented by Rosemount, Inc. in the 1980s as an enhancement to their process transmitters. Initial HART development focused on supporting the 4-20mA loop current and providing digital process variables. Much later, HART gained a reputation for its diagnostics and troubleshooting capabilities. While these were important strengths, it was digital process variables and competition that motivated development of the HART Protocol. HART Revision 4 was the first version of the Protocol to be included in a significant number of (mostly Rosemount) field devices. While several hundred thousand HART 4 devices were produced, the vast majority of installed HART devices today (more than 10 million) support HART 5 or HART 6 Revisions.

Page 3 of 3

In 1989 Rosemount released HART 5 and made the Protocol available to any manufacturer desiring to incorporate it into their product. HART became (and still is) the only open protocol supporting 4-20mA devices. This led to the formation of the HART User Group in 1990. Soon a large number of manufacturers were supporting HART. Technical support needs resulted in the formation of the HART Communication Foundation (HCF) in 1993. When the HCF was established, Rosemount transferred ownership of all HART technology to the HCF including patents, trademarks and other intellectual property. The HART Communication Foundation All members of the HCF have an equal voice in any enhancing or modifying of the HART Protocol. The HCF is supported by a professional and technical staff responsible to the entire HCF membership. The HCF mission is to support the application of HART technology worldwide as the standards setting body for HART communication. The Foundation: educates both end users and manufacturers; maintains the HART Protocol specifications and develops enhancements to the HART technology; and directs the HCF quality assurance (QA) program to ensure adherence to Protocol requirements.

In its role as educator, the HCF provides many materials at no charge including white papers, application notes and technical overviews. The HCF staff makes presentations at conferences worldwide. The HCF also offers developer and end user workshops at a nominal charge and provides assistance to member companies and non-member companies alike. To date, the HART Specifications [1] include 11 documents each with their own revision number (see Table 4.10a). The revision level of the Protocol is indicated by the document titled "HART Field Communications Protocol Specifications". Within this document, the revision level of all other specifications documents is specified. All HART products must meet all requirements of a specific Protocol revision. All HART devices must support all Universal Commands exactly as specified. The HART specifications are revised every six to nine months principally to add additional manufacturer codes and engineering units. All versions of the Protocol, including the early Rosemount versions, are available from the HCF. The HART Specifications are available (upon request) to anyone, anywhere. To ensure adherence to HART Protocol requirements, the HCF operates a QA program. All products claiming HART compatibility must pass all applicable tests included in the QA program. When evaluating a product, users should insist the supplier complete these tests. There are logos and trademarks frequently associated with the HART Protocol. There are restrictions on the use of these logos and trademarks. For example, the round "HARTability"
Page 4 of 4

logo may be used only by members of the HCF. HART is an open protocol and a manufacturer is not required to be a member of the HCF. However, any product describing itself as HARTcompatible must meet all the requirements of a specific Protocol revision. HART is a registered trademark of the HCF. Consequently, products that do not meet HART Protocol requirements are not allowed to claim "HART" compatibility. Table 4.10a HART Field Communications Protocol Specifications Document Title HART Field Communications Protocol Specification FSK Physical Layer Specification C8PSK Physical Layer Specification Data Link Layer Specification Command Summary Specification Universal Command Specification Common Practice Command Specification Device Families Command Specification. Common Tables Specification Block Data Transfer Specification Command Response Code Specification Early Adopters of HART HART began at the grassroots level of process automation with transmitter and valve companies and with instrument technicians in process plants. Time-saving tools, such as handheld configurators and instrument-specific software, facilitated rapid growth and acceptance of HART in the instrument shop. Purchasing agents began specifying HART compatibility at the insistence of instrument technicians and as a way to shorten bidders' lists and simplify bid evaluations. These demands by instrument technicians and purchasing agents prompted even more field device manufacturers to support HART. As manufacturer support of HART increased, more and more suppliers began using HART in the manufacturing process. HART can reduce field device production costs. For example, with HART capability, sensor characterization can be performed by the field device itself rather than using expensive specialized production test equipment. Furthermore, by providing increased field device software capabilities, overall parts costs and the number of optional assemblies can be reduced. Utilization of the Protocol during field device production has become so common that HART allocates a range of command numbers for device-specific factory use only. In some cases, cost savings produced by using HART in field device production even help justify the manufacturer's investment in the Protocol.
Page 5 of 5

Rev. 6.0 8.1 1.0 8.0 8.0 6.0 8.0 1.0 13.0 1.0 5.0

Doc. Number HCF_SPEC-12 HCF_SPEC-54 HCF_SPEC-60 HCF_SPEC-81 HCF_SPEC-99 HCF_SPEC-127 HCF_SPEC-151 HCF_SPEC-160 HCF_SPEC-183 HCF_SPEC-190 HCF_SPEC-307

Another early adopter of HART communication was SCADA applications. Pipeline monitoring, custody transfer and water/waste water applications all have significant communications requirements. HART communication simplified SCADA systems and reduced costs. In SCADA applications, analog I/O cards were dropped in favor of direct acquisition of digital process data using HART communication. Multi-dropping HART field devices reduced power consumption and allowed smaller power supplies, batteries and solar panels to be used. The use of HART in SCADA systems also led to ad-hoc embedding of HART messages in other protocols such as packet radio, satellite communication, TCP/IP, MODBUS and others. Climbing the Automation Pyramid Somewhere along the way, the myth that HART was invented only as a maintenance protocol became ingrained. Some system suppliers subscribed to this myth and used it to justify token support for HART. For example, many systems were supplied with only painfully slow, multiplexed I/O. A few system suppliers even used the myth to justify not supporting HART at all. Starting around 1997 (and after years of acceptance by instrument technicians), end users began demanding better HART support from systems suppliers. End user demands are prompting many systems suppliers either to improve their support for HART or to develop totally new interfaces. HART is relatively simple (albeit not trivial). The Protocol specifications include many mandatory requirements for all HART compliant equipment. Consequently, considerable functionality can be included in any system without resorting to special drivers or supporting any device specific commands. Table 4.10b lists the data and simple functions that any host system should be able to provide. Knowledgeable end users should insist on this minimum level of support when evaluating system offerings. In addition to improved system support, the embedding of HART messages within other protocols is also on the rise. This process allows backbone control networks to support and exploit the HART installed base. Both standardized and ad-hoc support are also available using several protocols including PROFIBUS-DP, TCP/IP, and MODBUS. HART messages are often passed through control system proprietary networks and I/O as well.

Page 6 of 6

HART FIELD DEVICES All HART field devices support two communication channelsthe traditional current loop and HART communication. The current loop occupies the 0-25Hz band used by all 4-20mA devices to continuously transmit a single process value. HART resides in a higher 500-10,000Hz band. While frequently referred to as HART digital communication, it is actually analog. Specifically, HART communicates digital data using analog signals (see Section 4.3, Sorting Out the Protocols). There are minimum requirements that all HART field devices must meet: adherence to physical and data link layer requirements, supporting minimum application layer requirements (e.g., device status information, engineering units, IEEE floating-point), and implementing all Universal Commands in all devices exactly as specified.

In addition, most HART field devices support a variety of Common Practice Commands. Whenever a field device supports a Common Practice Command, it must implement that command exactly as specified. The minimum data content of any field device is summarized in Table 4.10b. The minimum command set is listed in Table 4.10c. Note: Table 4.10c includes several Common Practice Commands. Field device support for these commands is not required. However, surveying the hundreds of device types registered in the HCF DD Library shows that a majority of field devices supports the listed Common Practice Commands. Of course, some devices support many additional Common Practice Commands. In even the earliest HART revisions, support for digital process variables was mandatory. These were called "dynamic variables" and were accessed using Universal Commands. Four dynamic variables may be supported by HART field devices: the primary (PV), secondary (SV,) tertiary (TV), and quaternary (QV) variables. All devices must support the dynamic variable commands. However, a device may not return (for example) the TV and QV if the device is not multi-variable. The 4-20mA current loop communication channel connects the HART field device to the control system (see Fig. 4.10b). The current loop is always connected to the PV (see the calibration subsection below). Furthermore, some devices support more than one current loop connection. When this occurs, the second current loop is connected to the SV and so on. In other words, the dynamic variables connect a HART field device to the control system. Note: For transmitters, PV and the loop current are outputs. For valves, they are inputs.

Page 7 of 7

Table 4.10b Overview of standardized HART field device data and capabilities

Process Variable Values

Primary Process Variable (analog PV) The 4-20 ma current signal continuously transmitted to the host Primary Process Variable (digital PV )

Status and Diagnostics Bits

Device Malfunction Device self-diagnostics has detected a problem in device operation Device Needs Maintenance (HART6)Device self-diagnostics indicates that preventive maintenance is required Primary Process Variable Out of Limits Primary process variable value is outside the transducer limits (i.e., the digital value is bad) Secondary Process Variable Out of Limits A secondary variable value is outside the transducer limits (i.e., the digital value is bad) Loop Current Saturated The process value is out of range and the 4-20mA signal is saturated Loop Current Fixed The 4-20mA signal is fixed and does not represent the process Cold Start Device has gone through a power cycle Configuration Changed Indicates device configuration (e.g., range values, units code , etc.) has been changed More Status Available Indicates additional devices status data available using Command 48

Percent Range Primary process variable expressed as percent of calibrated range Loop Current Digital loop current value in milliamps Secondary Process Variable 1 ("SV")

Secondary Process Variable 2 ("TV")

Secondary Process Variable 3 ("QV") Notes on Process Variables: 1. All digital values are IEEE floating-point with engineering units and (HART6) data quality status. 2. Secondary process variables are available in multivariable devices.

Device Identification
Instrument Tag User defined abbreviated name of the device, (8 characters) Long Instrument Tag (HART6) User defined name of the device. (32 international characters) Message User defined (32 characters), often used to record asset info (e.g., replacement ordering information) Descriptor User defined, often used to describe instrument location Write Protect Status Device Write Protect indicator Manufacturer Name (Code) (Read-only) Code defined by HCF that indicates the device manufacturer Device Type (Read-only) A code defined by the manufacturer indicating the model of the device Device Revision (Read-only) Indicates the revision of the device's command set (i.e., the set of ALL device data available via HART) Firmware Revision (Read-only) Incremented every time the device's firmware is modified. Hardware Revision (Read-only) Incremented every time the device's hardware design is changed Device Serial Number (Read-only) Unique for every manufactured device. Allows device to be tracked

Page 8 of 8

Table 4.10b (continued)

Primary Process Variable Properties and 4-20mA Current Loop Support

Loop Current Transfer Function (Code) Relationship between Primary Variable digital value and 4-20mA current signal Loop Current Alarm Action Loop current action on device failure (upscale/downscale/hold last value) Upper Range Value Primary Variable Value in engineering units for 20mA output point Lower Range Value Primary Variable Value in engineering units for 4mA output point Date 3-byte code. Date of last calibration PV Damping Primary Process Variable Damping Factor (Time constant in seconds) Upper Transducer Limit (Read-only) Largest process variable value that is accurate Lower Transducer Limit (Read-only) Smallest process variable value that is accurate Transducer Minimum Span (Read-only) Indicates transducer precision. Smallest delta between upper and lower range values that produces device specified accuracy. Transducer Serial Number Allows replaceable process transducers to be tracked. Upper Transducer Trim Point (HART6) The point last used to calibrate the upper end of the digital process variable Lower Transducer Trim Point (HART6) The point last used to calibrate the lower end of the digital process variable Notes on Properties and Calibration: 1. Unless noted, all values are IEEE floating-point with engineering units. 2. Upper and lower transducer trim points, were supported by device-specific commands in HART5 3. Transducer limits, serial number and minimum span mandatory for PV and optional for other process variables

Standardized Host Functions

Identify Device. A host function used to establish a connection to a field device. Perform Loop Test. Forces the loop current to different values to allow the field device's milliamp value be verified. Calibrate Loop Current. Forces the field device's loop current to the specified value and adjusts its value to match a milliamp reference meter. Does not affect device range values or the digital PV value. Re-Range Loop Current. Change the 4 and 20ma operating points to different set of high and low process variable values. Does not affect loop current calibration or the digital PV value. Set PV Damping Value. Change the time constant used to dampen the primary process variable value's response rate. Set Tag / Long Tag Set Message Set Date Set Descriptor Select PV Units. Change the engineering units returned with the primary process variable. The PV digital value and all of the PV properties are now calculated in the selected engineering units. Initiate Self Test

Page 9 of 9

Minimum set of commands supported by HART field devices. Universal Commands

Cmd No. Description 0 1 2 3 Read Unique Identifier Uses the "polling address" to establish a connection with the field device. Read Primary Variable Read Loop Current And Percent Of Range Read Dynamic Variables And Loop Current Reads the loop current, PV and (if device is multi-variable) SV, TV, QV Write Polling Address Read Loop Configuration Reads the polling address and whether the loop current is active or not. Read Dynamic Variable Classifications (HART6) Reads the type of each process variable (pressure, temperature,. mag-flow, etc.) Read Device Variables with Status (HART6) Reads up to 4 process variables with data quality status. Read Unique Identifier Associated with Tag. Uses the 8-character tag to establish a connection with the field device Read Message Read Tag, Descriptor, Date Read Primary Variable Transducer Information Read Device Information Reads upper and lower range values and other device related Read Final Assembly Number Write Message Write Tag, Descriptor, Date Write Final Assembly Number Read Long Tag (HART6) Read Unique Identifier Associated with Long Tag (HART6) Uses the 32-character tag to establish a connection with the field device Write Long Tag (HART6) Notes: 1. All devices must support all Universal Commands. 2. There are many common practice commands. However, the ones listed are commonly used in the vast majority of devices including even the simplest ones. 3. Commands 0, 11, 21 are three of the Identity Commands. All return the same identity data (see Table 4.10d)

Common-Practice Commands
Cmd No. 34 35 38 40 Description Write Primary Variable Damping Value Write Primary Variable Range Values Changes primary process variable values used as the 4 and 20ma operating points Reset Configuration Changed Flag Enter/Exit Fixed Current Mode Allows the loop current value to be forced. Used in Loop test and calibrating the loop current (see Commands 45 and 46) Perform Self Test

6 7 8 9 11 12 13 14 15 16 17 18 19 20 21

41 42 44 45 46

Perform Device Reset The device perform a hard reset (i.e., the same effect as cycling the power on and off). Write Primary Variable Units Trim Loop Current Zero Adjusts the loop current to 4ma. Does not affect the range values or the digital primary process value Trim Loop Current Gain Adjusts the loop current to20ma. Does not affect the range values or the digital primary process value

22

Page 10 of 32

However, as multi-variable field devices began to proliferate, the dynamic variable concept proved too restrictive. Revision 7.0 of the Common Practice Command Specification added support for "device variables" and provided additional standardized capabilities to developers of multi-variable field devices A "device variable" directly or indirectly characterizes the connected process. For example, in Fig. 4.10b, device variables 0, 1, and 2 are connected to the process and device variable 4 is calculated based on device variables 0 and 1. Device variable 3 is within the field device itself (e.g., it may be an onboard temperature sensor).
HART Field Device
Dynamic Variables

The Process

Process Connections
0 1 2

4 PV SV TV QV 3

Analog Channels

Control System

Dynamic Variable Mapper

Device Variables

Fig. 4.10b HART device variables versus dynamic variables Sophisticated multi-variable field devices allow the device variable mapped to PV (i.e., the current loop) to be configured based on application requirement. For example, a level gauge may measure level and calculate volume. Sophisticated level gauges will allow the user to choose whether the current loop reports level or volume. This allows the data that is most important to the user to be transmitted continuously via the current loop. Using HART communication, the other process variables can be accessed simultaneously on the same wire. Since devices supporting multiple current loops are rarely used, HART is usually the only way to access secondary process variables. Since many control systems support only one measurement (i.e., process variable) per I/O connection, multi-variable devices can present serious problems. This problem can be compounded when a poor I/O system design is chosen. Older systems with poor or no HART support can still indirectly support multi-variable field devices. Some products can convert digital HART secondary process variables into multiple current loop signals. These devices make a field device look like it generates four current loops instead of one. Of course, the control system needs four I/O points instead of one, as well.

Page 11 of 32

Backward Compatibility Clearly, the HART Protocol is backward compatible with 4-20mA equipment. However, HART's backward compatibility extends far beyond that. HART Protocol Specifications include specific backward compatibility requirements. These requirements apply to both modifications to an existing HART product and modifications of the HART Specifications themselves. Backward compatibility rules, in general, allow data and commands to be added. However, the meaning of the data already present cannot be changed. Furthermore, commands and data may not be deleted under any circumstances. For example, a field device adding a data byte to device-specific command 136 is only required to increment the Device Revision (see Table 4.10d). However, if Command 136 were deleted, the developer must change the Device Type number and, in effect, create a new type of field device. Table 4.10d Application of HART field device identifying data Data Items Tag; Long Tag; Manufacturer ID; Device Type Manufacturer ID; Device Type; Device ID (i.e., serial number) Purpose
User Identification of the Field Device

These three data, when combined, identify a single, unique field device. Frequently these data are used to track field device through an installation, calibration, plant operation, and refurbishment cycle. These three data also provide the basis for the device's 5-bye address. Field Device Command and Data Item Set Identification. The combination of these three numbers always indicates a unique command set. For example, if a new device-specific command is added the device revision number is changed. If a device specific command is deleted and new device type number must be used (to maintain backward compatibility) Field Device Revision Information. The hardware and software revisions track the configuration of the Field Device and its software. The device revision reflects the set of commands supported by the device. The Universal Command revision ties the Field Device to a major revision of the HART Protocol. For example, a software revision can be made to correct a defect or enhance device operation without necessarily affecting the device revision level (i.e., the HART commands it supports)

Manufacturer ID; Device Type; Device Revision

Device Revision; Software Revision; Hardware Revision; Universal Command Revision

Backward compatibility is critical to ensuring continued operation of installed plant systems. A host using any feature in a field device can be assured that the same feature will always be available and operate in the same way with all future revisions of that field device. This allows any field device to be safely (i.e., without breaking or reconfiguring the control system) replaced by a newer revision device even if the system is using device-specific commands or data.

Page 12 of 32

CALIBRATING HART FIELD DEVICES All field devices, regardless of the communications protocol they support, need periodic calibration [2]. Calibration of HART devices includes calibrating the digital process value, scaling the process value into a percent of range, and transmitting it on the 4-20mA current loop. HART devices use standardized commands to test and calibrate the loop current, re-range a field device, and even perform a transducer trim. Note: Understanding the principles in this subsection will provide valuable insights into the organization of the HART application layer. Fig. 4.10c is a block diagram showing the processing steps associated with generating PV and will be used to illustrate the calibration process. Three blocks are used for data acquisition and communication of PV via the current loop. From left to right, these blocks include the transducer block, range block, and DAQ block.
Transducer Limits and Transducer Trim Points Range Values and Transfer Function Analog Channel Zero and Gain Loop Current

Digital Value

Transducer

Percent Range

The Process

Control System

Digital Value Range Conversion

Percent Range DAQ

Transducer

Analog Channel

Fig. 4.10c PV blocks that can be calibrated Calibrating the process variable The transducer block is responsible for generating a precise digital value representing the connected process. In HART, the transducer block contains properties like the upper and lower transducer limits, transducer trim points, and device specific transducer characterization data. Access to characterization data is usually not available or adjustable in the field. All smart field devices (no matter the communication protocol supported) contain something equivalent to the HART transducer block. Furthermore, all devices require periodic calibration of the digital value produced by its transducers. The calibration of the transducer blocks (i.e. transducer trim) consists of supplying a simulated transducer value and comparing the transducer value provided by the field device with the value measured by a traceable reference to determine whether calibration is required. If calibration is required, it is performed using the HART Protocol. In general, calibration is performed by providing the field device with correct transducer values, one near the lower limit and another

Page 13 of 32

near the upper limit. Using these values, the field device performs internal adjustments to correct its calculations. Today there are documenting process calibrators that perform all of these functions. These documenting process calibrators: 1. 2. 3. 4. provide the simulated process signal and an accurate, traceable reference value; determine if adjustment is required; issue the HART commands to complete the calibration process; and record the as-found and as-left calibration data.

Some instrument management systems are capable of automatically uploading the calibration records for trending and later analysis. Standardized MS-Windows-based protocols exist to facilitate communications with documenting process calibrators [3]. The latest release of the HART Specifications provides standardized commands that support transducer calibration. Note: Earlier versions of the HART Protocol did not include standardized transducer trim commands. Despite this limitation, most HART calibrators support a wide range of HART-compatible field devices. In many cases, the developers analyzed the contents of the HCF DD Library to learn the device-specific commands required for each individual field device. Scaling the process variable The next two blocks in Fig. 4.10c translate the transducer value into a 4-20mA signal. Traditionally, this has been referred to as the "zero and span" of the device. HART has always supported standardized commands to re-range a field device and to calibrate the loop current. In the range block, HART uses the upper and lower range values to scale the transducer value into "Percent Range". The lower range value sets the transducer value that produces a 4mA signal. The upper range value specifies the transducer value that will produce a 20mA signal. In many field devices, the upper range value can be smaller than the lower range value. For example, a level gauge could be configured to provide a 4mA value when the tank is full and a 20mA value when it is empty. This can be useful, for example, when the level gauge 4-20mA signal is connected to a proportioning valve. Note: Understanding Fig. 4.10c and the differences between the ranging and calibrating of a device are critical. Considerable confusion can result if the difference between calibrating the PV's digital value and re-ranging the instrument is not understood [2]. Many hours can be spent attempting to get an "accurate" 4-20mA signal if the function of the transducer and range blocks is ignored.

Page 14 of 32

The range block can also apply a transfer function (e.g., linear, square root, cubic spline, etc.) to the PV signal. Square root functions are frequently used to approximate a flow from a differential pressure measurement. Producing the loop current The DAQ block is responsible for the actual production of the 4-20mA signal. HART has always provided standardized commands to calibrate the loop current. Since the range block already scales the process value, the responsibility of the DAQ block is to ensure 0% produces 4mA and 100% produces 20mA. The objective of calibrating this block is to ensure that when the device thinks the loop current is (for example) 7.956mA there are exactly 7.956mA on the wire. The meaning of 7.956mA, in terms of the process value it represents, has already been established in the previous two blocks. From a system viewpoint, the whole purpose of the 4-20mA current loop is to communicate with the control system. Consequently, the most critical requirement is that the field device and the control system both agree on the value of the current loop. Agreement between the field device and the control system on the milliamp value is much more critical than the absolute accuracy in most applications. HOST APPLICATIONS While the minimum requirements for field devices are quite strict, host applications are provided some leeway in their implementations. This is due to the wide range of applications supporting HART. Applications vary from simple, like an embedded application closing relay contacts based on HART status information, to complete process control systems. Of course, all host applications are required to adhere to all physical and data link layer requirements. HART hosts identify field devices using standardized procedures and "identity commands". There are several identity commands and each provides a different procedure to initiate communications. Among other things, identification procedures allow the 5-byte communication address of the Field Device to be ascertained. Hosts are required to support all Field Device identification procedures (e.g., connect to the device by poll address, tag or by using the "find device" command). Note: HART requires all field devices to provide all identity data exactly as specified. All identity commands return the same data and hosts must analyze this data to properly support communications. Identity commands return information such as what is the device type, who made the device, what is the device, and software and hardware revisions. The data is used to learn specific properties of the field device (see Table 4.10d).

Page 15 of 32

Host Conformance Classes All hosts utilize standardized identification procedures to initiate field device communications. Beyond that, however, the services provided by a host become application specific. To simplify assessment and ranking of host systems, the HART Specifications require hosts to disclose their conformance class (see Table 4.10e). The classes range from zero (the simplest, least capable host) up to five (a universal host). As the conformance class number increases, so does the capability of the host. For each conformance class, support for specific HART commands and procedures are required. Class 0 and 1 hosts tend to be simple embedded or special purpose applications. Class 3 is called a "generic host". Even at this level, no special device-specific drivers are needed for compliance. Any reasonably capable host (e.g., PLC or control system) should be able to adhere to generic host requirements. In addition, most day-to-day operations can be supported by any generic host. Levels 4 and 5 frequently need device-specific knowledge supplied (e.g., by a DD or a DTM). Level 4 and 5 hosts, while very important, may not be necessary for daily communications with every field device in the plant.

Table 4.10e Host conformance classes Class 0 1 2 3 4 5 Description The host does not meet the minimum requirements of Conformance Class 1. The host can utilize cyclical process data from any field devices. The host can supply the user with basic identification and configuration data about any field device. The host can perform basic configuration of any field device. Minimum level required to be classified as a "Generic Host". The host provides basic commissioning and calibration support for any device. The host is capable of accessing all field device data items and all device-specific commands for any field device.

Page 16 of 32

Understanding I/O System Tradeoffs All communications systems can be characterized by their throughput and latency: Throughput indicates the maximum number of transactions per second that can be communicated by the system. Latency measures the worst-case maximum time between the start of a transaction and the completion of that transaction.

Throughput and latency are affected by the communication protocol requirements and by implementation decisions. Knowledgeable end users will insist on receiving these two statistics when evaluating system components. The HART Application Guide includes a host capability checklist [4]. The performance (throughput and latency) of I/O systems can vary dramatically. Design Decisions and Architecture that affect HART I/O System Performance In general, HART can provide 2.65 PV updates per second via Command 1. This is a typical value and actual throughput can be less. For example, slave devices may begin their response later in the allotted transmit time window or the message might be a HART command containing a longer data field. In addition, hosts have a small time-window to begin their message transmission. If that window is missed, the HART network becomes "unsynchronized" and the host must back off an extra time interval. The resulting extra time lowers performance to 0.88 updates per second (or about 3 times slower) or less. Note: All calculations in this discussion assume the HART FSK Physical Layer is in use. If the HART PSK Physical Layer is used then all values are increased about 5-fold. For example, the FSK Physical Layer allows 2-3tps and the PSK Physical Layer provides 10-12tps. Missed host transmit windows are seen in several HART hosts (e.g., those running on MSWindows systems have very poor latency). Consequently, many point-to-point HART networks are running at significantly reduced speeds. Missed transmit windows can be avoided by including message FIFOs in the HART interface. I/O systems containing the small amount of extra memory for FIFOs provide significantly better performance.

Page 17 of 32

Multi-Drop Connections All HART-compatible host and slave devices must support multi-drop. In multi-drop, several HART field devices are connected via the same pair of wires. Latency is increased because several commands may be enqueued and waiting for transmission. Note: In multi-drop applications, all field devices are typically parked at a fixed current and only HART communication is available. There are installations, however, where the field devices may use current loop signaling although several devices are on the same wire. Two proportioning valves wired in series for split-range operation is a good example of these applications. In Multi-Drop networks, throughput remains the same (approximately 2.65 tps). However, latency increases and is proportional to the number of devices on the loop. Even with the degraded latency, multi-drop is suitable for many applications (e.g., temperature monitoring or tank inventory management). Multi-Channel I/O Systems For optimum performance, I/O systems should include one (hardware or software) modem for each channel. With such an I/O system, utilization of all HART capabilities is practical including continuous status and diagnostics, remote configuration of instruments, acquisition of secondary process variables from multi-variable field devices and the deployment of multi-drop networks. Lower cost I/O systems multiplex HART communication by using one HART modem chip to support several I/O channels. With multiplexed I/O, all transactions must be serialized and the host must resynchronize its communications each time the HART channel is changed. Consequently, the execution of the last requested command may be delayed by the time required to process all commands already enqueued plus the resynchronization delay time. Table 4.10f summarizes system performance based versus I/O architecture. While actual performance can vary, this table provides a basis for evaluating I/O system designs. Multiplexed I/O is clearly the poorest performer and is even worse then multi-dropped I/O. For 8 channel analog I/O (a common format in many systems), multiplexed I/O throughput is 14.5 times worse than when a modem is used for each channel. Clearly, the use of multiplexed systems dramatically degrades system performance. In fact, real-world performance may be even worse (e.g., due to delays introduced by other system overhead). Note: Multi-variable HART field devices are very common and secondary process variables can be accessed only via HART communication. Multiplexed I/O severely limits utilization of secondary variables found in multi-variable field devices.

Page 18 of 32

Impacts of burst-mode on I/O performance Burst-mode allows a field device to be configured to continuously transmit digital process values. All HART hosts must support burst-mode, however, utilization of burst-mode will depend on the application. If common multi-variable field devices are employed, burst-mode maximizes the update rate of secondary process variables. For example, secondary process variables can be normally updated (using Command 3) 1.8 times per second. With burst-mode the secondary process variables can be updated 2.4 times per second (about a 30% improvement). However, configuration of a field device can take somewhat longer. When burst-mode is enabled the burst-mode device is responsible for token recovery. Consequently, hosts have network access only after a burst message from the field device. This results in a throughput of 0.80 configuration read commands per second or about 2.5 times slower than with burst-mode not in use. This is about the same throughput as if the host missed its transmit window (discussed above). Table 4.10f Summary of Latency and Throughput for I/O Systems Latency (seconds) Number Channels 1 4 8 16 32 Point-Point 0.38 0.38 0.38 0.38 0.38 Point-Point
(unbuffered)

Multi-Drop Multiplexed 0.38 1.51 3.02 6.04 12.08 0.38 2.73 5.46 10.92 21.84

1.14 1.14 1.14 1.14 1.14

Throughput (Transactions per second) Number Channels 1 4 8 16 32 Point-Point 2.65 10.60 21.19 42.38 84.77 Point-Point
(unbuffered)

Multi-Drop Multiplexed 2.65 2.65 2.65 2.65 2.65 1.47 1.47 1.47 1.47 1.47

1.14 4.56 9.12 18.24 36.48

In summary, burst-mode improves system support for multi-variable field devices while somewhat slowing uploads and downloads of instrument configurations. Of course, uploads and

Page 19 of 32

downloads are infrequent compared to cyclic updates of secondary process variables. For multiplexed I/O systems, performance is difficult to estimate. In some cases, burst-mode may actually provide an overall benefit to multiplexed systems. This is certainly the case for multiplexed systems supporting cyclic access to secondary process variables in multi-variable field devices. INSTALLING HART NETWORKS HART communication is designed to be compatible with existing 4-20mA systems. In fact, the HART signal is a modulated analog signal. Consequently, no special requirements are needed for most installations. That being said, no discussion of HART can be complete without providing an overview of basic HART signaling and the mechanics behind installing a HART network. HART communication is based on communication techniques long used in telephone and telecommunications and consequently, HART is very forgiving. For example, there are several ways to calculate HART cable lengths. No matter the technique used, the result is very conservative (i.e., HART will normally be successful on cables 25-50% longer than calculated). Note: HART cable run lengths are a function of the quality of the cable used. The lower the capacitance, the longer is the possible cable run. In many cases, the cable runs are determined by Intrinsic Safety capacitance limitations before HART limits are reached. Since HART is based on modems designed for analog telephone networks, in most cases, HART communication will be successful over some of the worst imaginable wiring to be found. Understanding the HART Physical Layers All HART devices support two communications channels: (1) the traditional 4-20mA signaling and (2) the modulated HART communication. These exist in separate communications bands (see Fig. 4.10d) and the signals do not interfere with each other. This allows both communications to occur simultaneously. In fact, a significant portion of the physical layer specification is dedicated to defining the filtering and response times to ensure the separation of these bands.

Page 20 of 32

4-20mA Signal Band

HART Signal Band

DC

25Hz

500Hz

10KHz

Fig. 4.10d HART frequency bands Process control equipment normally contains a low pass filter to block out noise. Consequently, HART looks like noise to most existing systems and is filtered out. In most cases, this feature allows HART to be used with existing systems without special modifications. All HART devices are required to support the HART FSK physical layer (the PSK physical layer is optional). The FSK Physical Layer is based on the Bell 202 modem standard. FSK modulates the digital data into frequencies ('1' is 1200Hz and '0' is 2200Hz). FSK is quite robust, can be communicated long distances, and has good noise immunity. A single, simple HART modem chip is used by a device to send and receive the HART modulated signals. Fig. 4.10e provides an overview of different physical connections. Depending on the device, the HART signal is modulated by varying the loop current or by directly modulating a voltage onto the loop. Process transmitters vary the loop current +/- 0.5mA. On a typical loop the current sense resistor is 250 Ohm which produces a 250mV peak-to-peak HART signal. Other equipment (e.g., handhelds, DCSs, valves) modulate a voltage on the loop. For each type, the specification establishes signaling levels, device impedances and internal filter requirements (see Table 4.10g). All of these requirements are fulfilled in the device design and, consequently, no special terminations or installation practices are required. HART Network Guidelines As previously discussed, HART was designed to work in typical 4-20mA loops. Consequently, guidelines for HART networks are simple (see Table 4.10h) and virtually identical to normal 420mA instrumentation practices. The loop with a two-wire transmitter in Fig. 4.10e is an example of a typical HART loop. The loop is wired using standard 4-20mA practices and by default meets all of the guidelines in Table 4.10h. It has a current sensor (i.e., one low impedance device), a transmitter controlling the 4-20mA signal (i.e., only one device varying the analog signal) and a single HART secondary host (when a handheld is connected to the loop). Virtually all control systems use a 250 Ohm current sense resistor and a linear power supply.

Page 21 of 32

Control System "Three-Wire" Transmitter

Current Sense Resistor

Multi-Drop Network

"Two-Wire" Transmitter Secondary Master

Loop-Powered Valve/Actuator

Fig. 4.10e HART devices and networks Table 4.10g Characteristics of the HART devices shown in Fig. 4.10e
T -wir o e Three ire w w Multi-dr p o C ntr l Sy tem o o s tr nsmitte r nsmitte r netw k a tr a o r cur ent input r L 4-2 4-2 HA HA p-poo w d e o 0 signaling m a 0 impedanc m a R T signaling R T nce imped a og m o und r e r e
Yes Curr nt Sink e High Curr nt e High Yes No Curr nt sourc e High Curr nt e High No e Yes None High Curr nt e High Yes No Curr nt rece ve i r e Low Volt ge a Low No

C ntr l Sy tem o o s cur ent o tput r u

No Curr nt Sourc e High Curr nt e High No e

Se nda o r y lva- e c V M star e a tua t c

No None Ve y High r Volt ge a Medium Yes Yes Curr nt e re ivc r ee Low Volt ge a Low Yes

Isola edtfr

As seen in Fig. 4.10e, HART also supports multi-drop networks. In a multi-drop network the current loop is used to power two-wire devices and all devices park at a fixed current (e.g., 4mA). While supporting more field devices is possible, a network typically only has up to 16 multi-dropped field devices. Of course, the number of devices affects the process variable scan rate and fewer are allowed when Intrinsic Safety rules are in effect. In summary, the HART physical layers are simple with most of the details managed by a lowcost modem chip. HART signaling is in a separate frequency band from the 4-20mA analog
Page 22 of 32

signal and, in most cases does not interfere with existing 4-20mA systems. The impedances, filtering and signaling of HART devices are specified to ensure reliable HART communication when using standard 4-20mA installation practices. Table 4.10h HART network guidelines
A network must have at least one, typically only one, low impedance device. Total loop resistance must be between 170 and 600Ohms A network must have no more than one device varying the 4-20mA signal. Only one secondary device is allowed. Cable run lengths to 3000m for single pair cable and 1500m for multi-conductor cables is typical. Actual length depends on the number of multi-dropped field devices and the quality of the cable used (see Table 4.10i). Low capacitance shielded twisted pair cable is recommended. However, HART has been successfully used over poor quality, unshielded wiring. Don't replace wiring until you have attempted HART communication. Linear power supplies should be used. HART is compatible with I.S. rules and HART communicates across most I.S. barriers. In general, zener diode barriers are acceptable as they do not prevent twoway communication. However, isolating barriers must be HART compatible (i.e., some isolating barriers support one-way communication only).

Table 4.10i Allowable cable lengths for 1.02 mm (#18 AWG) shielded twisted pair cable Cable capacitance No. Devices 1 5 10 15 65 pf/m 2,769 m 2,462 m 2,154 m 1,846 m 95 pf/m 2,000 m 1,815 m 1,600 m 1,415 m 160 pf/m 1,292 m 1,138 m 1,015 m 892 m 225 pf/m 985 m 892 m 769 m 708 m

Page 23 of 32

DEVICE DESCRIPTIONS Considerable functionality is available using the standard HART commands that all field devices support. While these commands address routine continuous systems requirements like acquisition of cyclical process data and online status and diagnostic monitoring, from time to time device-specific features and configuration properties must be accessed. Device descriptions (DDs) facilitate access to these device-specific features. The Device Description Language (DDL) is a very powerful technology that provides significant benefits for the configuration and setup of device-specific features (see Table 4.10j). While DDs are an optional part of the HART Protocol, most HART-compatible devices have a corresponding DD registered with the HCF. The Device Description Language (DDL) is an object-oriented modeling language tailored to describing field devices which DDs do very well. The HART DDL has been in extensive use for over seven years and there are DDs for hundreds of different field device types registered with the HCF. Elements of the HART DDL can also be found in the DDL associated with Foundation Fieldbus and PROFIBUS. DDL consists of three major functional areas: Modeling the field device application layer data, Describing the commands used to transport that data, and Specifying the Standard Operating Procedures (SOPs) used for periodic maintenance.

The data modeling is the central role of DDL. The majority of both DDL constructs and most of the lines-of-code in a DD are used to describe the real-time database found in the field device.

Page 24 of 32

Table 4.10j Summary of device description strengths and weaknesses Strengths

DDs allow the development of very beneficial universal hosts supporting both commonly used standardized HART features and infrequently accessed device specific features. When problems arise, a universal host using DDs greatly simplifies the diagnosis and trouble shooting of field device problems. DDs allow the capture of 100% of a field device's configuration. This allows device configurations to be engineered in advance of plant commissioning thus reducing start up times and costs. DDs are technology independent and can be used in MS-Windows platforms, embedded real-time devices and other computing environments DDs allows the schema of the field device's realtime database to be defined and exported.

Weaknesses
DDs do not enhance interoperability. While DDs model a field device, they do not tell a host what to do with the field device. Interpretation of the DD and all the possible combinations of DD constructs requires significant host software development effort. DDs allow modeling of field device features that do not comply with protocol requirements. DDs have limited MMI support and no support for GUIs. Additional development by the device manufacturer may be needed to support some DD-based hosts. DDs allow device-specific commands and data to be used in place of standardized (e.g., common practice) commands.

A system consisting of controllers, MMI, I/O, and smart field devices can be considered a distributed database system. The control system and MMI keep copies of the device's database to control the process and keep the plant operator informed. DDs describe that database and HART is used to keep the system's copy of the database up to date. Control systems that do not view the smart field device as part of "the system," ignore the valuable process-related data found in HART-compatible field devices. The system should not stop at the 4-20mA input card. DDL provides significant benefits and allows any field device to be fully modeled. The principle benefit to device manufacturers and end users is that DDL allows universal hosts to support 100% of a field device's features including features rarely used. Device developers do not need to develop a custom application or a hand-held, and end users do not need to acquire and track hundreds of applications and special device drivers.

Page 25 of 32

HART APPLICATIONS With few exceptions, the applications discussed here are relatively simple to implement using commands and data common to all HART field devices. Using HART in the control systems Many plants already have large numbers of HART-compatible field devices and therefore, a significant investment in HART technology. This subsection will discuss emerging system architectures, how to exploit the untapped capabilities found in all HART field devices, and methods for maximizing the value of existing installed HART field devices. Traditionally, 4-20mA field wiring is brought to a junction box and then, a multi-conductor "home run" cable connects the junction box and an I/O located in a marshaling room. I/O system data is then communicated to the controller using a proprietary backbone bus. The controller in turn provides data to operator consoles, data historians and engineering workstations. In this traditional architecture, the only information available from the field device is the 4-20mA signal. This architecture is now frequently replaced by a distributed system consisting of hardened remote I/O, controllers, operator consoles and engineering stationsall connected using "open" communications protocols. The remote I/O is mounted close to the process units with short 4-20mA analog cable connecting to HART field devices. The expensive multi-conductor cable from the junction box is replaced with a network cable connecting the remote I/O to the balance of the control system. In this emerging architecture, continuous communication of the primary variable is provided via the 4-20mA signal with HART communication used to enhance the capabilities and integrity of the system. One of the simplest and most valuable assets HART communication provides is access to the device's status information. Device status is provided with every HART response message. Using HART communication, detailed knowledge of the field device's health can permeate the control system. Monitoring device status can predict device failures and unscheduled plant outages can be reduced. The integrity and availability of the system are improved and the effectiveness of predictive maintenance programs can be significantly enhanced using HART status data. Furthermore, the latest release of the HART Specifications provides standardized data quality status that supports development of self-validating field devices. As these devices emerge, the value provided by utilizing HART status information will be enhanced even further. Control system can provide further value by using HART communication to tap the wealth of secondary process variables found in many multi-variable HART field devices. Multi-variable process data can be updated 2-3 times a second (10 to 12 times with PSK). While not particularly fast, this update rate is much faster than the time constants associated with many processes. For example, the temperature sensor bonded to the transducer in most HART pressure transmitters can be monitored. This can be used to provide temperature indication of the process or provide

Page 26 of 32

early warning of potentially damaging freezing conditions during winter. Utilizing this "free" data may eliminate the need for additional transmitters and I/O in some applications. Maximizing the value of HART's current loop support The current loop is fundamentally a communication channel. The properties of the current loop are universally available from HART field devices. Any system designed to utilize the power of HART should be able to: Automatically configure the I/O channel. The range values can be read by the control system to configure the calculation of the process value from the received current loop. Confirm the integrity of the low-level current loop signal. The transmitted current loop value can be read from the field device and compared to that received by the system. The control system can alert the plant operator to any discrepancy. Perform an end-to-end validation of process variable communication. The process value calculated by the control system from the current loop can be verified against the digital process value originating in the transducer block of the field device.

A smart transmitter is the primary indicator of process conditions. The current loop signal and HART communication allows the process values in the control system to be accurately slaved to the process values originating in the HART field device. Since the current loop is a communication channel, agreement between the current loop reading in the control system and the field device is critical. HART communication allows the value of the current loop perceived by the field device to be continuously verified against that measured by control system (see Universal Command 2). In addition, the control system can test current loop integrity by forcing the HART field device to output any milliamp value desired (see Common Practice Command 40). Any discrepancies between the control system and the field device can then be brought to the operators attention. If desired, a control system supporting HART should be able to automatically calibrate the loop current value generated by the field device (e.g., using Common Practice Commands 45 and 46). Since the I/O system knows the milliamp value it is measuring, as long as value from the HART field device agrees, the 4-20mA analog communication channel is secure. The control system has a fundamental interest in the process value the 4-20mA signal represents. When HART communication is not supported, the equation used by a system to convert the mA value into usable process value must be manually configured. For example, the controller must be told that 20 mA = 100 kPa. Furthermore, if a technician should re-range the field device, the process value calculated by the control system would no longer be accurate. All HART devices contain the information necessary to automatically configure the I/O channel (see Universal Command 15). Significant savings in system engineering and commissioning can result. While in operation, the system should be able to periodically monitor the range values and detect any inadvertent changes in the system configuration. Should any changes occur the operator should be alerted.
Page 27 of 32

While primary process value is continuously updated using the current loop, it can also be read using HART communication (see Universal Commands 1, 3 and 9). Continuous HART communication allows end-to-end validation of primary process value used by the system. All of the intermediate calculations and the current loop signal itself are tested together to ensure the system functions correctly as a whole. Any deviations detected should cause the operator to be alerted. SCADA applications SCADA applications usually focus on acquiring real-time data. The speeds of operations are frequently measured in minutes as opposed to a control system requiring fractions of a second response times. HART communication is very complementary to the objectives of SCADA systems. Some of the SCADA applications using HART communication include: pipeline monitoring, custody transfer, inventory and tank farm management, automated meter reading, and the monitoring of remote petroleum production platforms. The key to HART's successful use in SCADA applications is the digital process values supported in all HART field devices. In addition, the status information provided via HART can be used to schedule field trips for performing preventive maintenance and to reduce unscheduled down time. Other benefits HART provides: HART communication can be transmitted directly over leased telephone lines (HART FSK Physical Layer is based on Bell 202). The leased lines can create a virtual multi-drop network of instruments (for example) distributed along a pipeline. Dedicated RTUs may not be required. Power consumption can be reduced minimizing battery and solar panel sizes. A system with (for example) multi-dropped devices requires significantly less power (4mA times 8 devices = 32mA total) and I/O (1 point) when compared to a point-point SCADA implementation (160mA and 8 I/O points). With the multi-dropped approach, process values can be read once every four seconds, which is much faster than required for most SCADA applications Some spread-spectrum radio equipment supports HART communication. With this equipment, field devices scattered within a 100km radius can be linked together into virtual multi-drop networks thus greatly reducing costs.

Page 28 of 32

Control in the field Almost since its inception, HART devices have been used to provide a simple control in the field. One of the early uses may have been in tank level control. In this application, HART's standardized support for re-ranging is utilized (see Common Practice Command 35). The level gauge can be configured with the lower range value set to the target tank level and the upper range value used to provide proportional action. The loop current from a level gauge is directly connected to a control valve filling the tank . The upper range value (i.e., the 20mA point) sets the valve full open tank level. HART requires process variables be correct any time the process is between the lower and upper transducer limits. In other words, when the process is outside the upper and lower range values and the current loop is saturated, the HART digital process variable is still available and accurate. Consequently, the tank level can be monitored using HART even while the current loop is used to control the tank level. PID controllers in HART field devices also utilize the unique hybrid nature of the Protocol. Some HART transmitters have supported PID control functionality since the early 1990s and more recently, HART intelligent valve controllers have begun including PID controllers. These controllers allow a transmitter and valve to be connected in series to create a stand-alone control loop in the field. When the PID is in the transmitter, the current loop continuously updates control signal and, when in the valve, the process signal is carried on the current loop. In these applications, the current loop provides the basis for continuous closed loop control. This is similar to the single-loop controller topology used for many years. HART communication is used to monitor control loop operation (e.g., read process variables and monitor status) and change setpoints. Device-specific commands were used to interact with PID controllers in early device implementations. However, HART specifications have now standardized PID support. This allows devices that support a PID controller to use standardized commands and data thus allowing even simple hosts to utilize this functionality. Instrument Management Instrument management systems are specialized data base applications. Their database allows instrument configurations to be tracked and maintenance activities to be planned and recorded. When combined with documenting process calibrators, instrument calibration histories can be automatically captured. Simple systems utilizing common HART capabilities can provide valuable assistance in monitoring basic instrument configurations. Standard HART communication allows devices needing maintenance to be identified and allows any changes to device configurations to be detected. Range values and device status can be continuously monitored by the management system. When plant calibration procedures reset the Date Field in devices as they are calibrated, even a simple system should be able to automatically list devices requiring re-calibration.

Page 29 of 32

HART provides two standard data items that are specifically directed to tracking configuration. The first is the "Configuration Changed" flag (see Table 4.10b). The second is a "Configuration Change Counter" (see Universal Command 0, 11and 21) that is incremented every time a command is received by the field device that changes the instruments configuration. Both of these data are easily accessed and can be tracked by even the simplest host. This allows any host to detect a configuration change. High-end instrument management packages have sophisticated databases and many automated reports can be generated (e.g., instrument technician work orders for devices needing maintenance). Frequently these systems are universal hosts that can capture 100% of each field device's configuration data and many can even access infrequently required device specific features. To support 100% of the device's data items, universal hosts usually support DDL and utilize the hundreds of DDs registered in the HCF DD Library. By utilizing the HART device's identity information (see Table 4.10d) these packages can also document the entire life of the plant's field devices. Analyses of these histories allow predictive maintenance activities to be optimized and maintenance costs to be reduced. For either a simple or a complex instrument management system, HART communication can automate many activities, simplify record keeping and reduce manual data entry. Valve Diagnostics Valve diagnostic software packages are specialized tools using HART two-way communication to support intelligent valves and actuators. While the Protocol standardizes some valve properties, many of the diagnostics are device-specific and use proprietary algorithms. Any HART-capable host should be able to access some basic valve information: Device Needs Maintenance, Valve In Manual, and Valve Upper or Lower Limited status is available (HART6). These provide basic information about the operation of the valve. Actual valve position is generally returned as a secondary process variable. This information can be monitored and trended to confirm basic valve operation. For pneumatic positioners, actuator pressure is generally available as a secondary process variable.

In addition, many other device-specific, smart valve capabilities can be accessed remotely using HART including: Manually stroking the valve or manually controlling valve position; Linearization of the valve's flow characteristics (i.e., ensuring a change in the loop current causes a linear proportional change in the flow); Evaluating tracking of valve position versus setpoint to assess the mechanical condition of the valve;

Page 30 of 32

Accessing predictive maintenance indicators like total valve travel, number of reversals and stroke count data stored in the smart valve; and Characterization of the valve (e.g., testing the valve travel speed).

Many of these diagnostics are available while the valve is online and additional diagnostic features continue to be added. OPC OPC (OLE for Process Control) provides high level communication between software modules. OPC servers comply with specific software interfaces. These interfaces encapsulate the underlying details of the hardware and communications supported by the server. This allows OPC clients to connect to any compliant OPC server to create a whole system. Several OPC servers exist that support HART. These allow for example, standard MMI and historical trending packages to access HART data. These OPC servers support direct connection to HART networks and communication via intermediate I/O systems. While HART inherently supports two hosts, OPC allows many clients to access HART data via MS-Windows networks and share connections to HART field devices. HART OPC servers broaden and simplify access to HART data. OPC allows clients to access "named data items". These "named data items" are defined by an OPC-compatible server. The OPC Client "browses" the named data items provided by the server and subscribes to the data item of interest. The data items can be grouped and the group turned off and on by the client. When a group is turned on, the server will publish the data items based on the criteria set by the server. These criteria include update rate and dead band. This allows the client for example, to get the data item only when it changes. At a minimum, a HART-compatible OPC server should provide access to the application layer data shown in Table 4.10b. In addition, some universal hosts support an OPC server interface that allows access to device-specific data as well. However, one source of potential mischief should be recognized. Standard HART data items should all be referred to by the same name. If the naming scheme varies by device, then the client application risks becoming linked to one and only one device (with the primary variable named "PRESSURE"). If that device is replaced with a similar product from another manufacturer and the primary variable is named "DRUCK", the client application will fail. Utilization of standardized OPC naming schemes is important to ensure interoperability and the openness of the Protocol.

Page 31 of 32

IN CLOSING The simplicity of the HART Protocol contributes to its popularity and to the low cost of HARTcompatible equipment. The preceding demonstrates the power, value and the wide range of HART capabilities and applications. Growth of HART capabilities and applications are certain to continue for many more years. Use this information to understand the capabilities of HART and to evaluate the field devices and host systems you encounter.

REFERENCES 1. HART Field Communications Protocol Specification. HART Communication Foundation. HCF_SPEC-12 2. Holladay, K.L. "Calibrating HART Transmitters." ISA Field Calibration Technology Committee. http://www.isa.org/~pmcd/FCTC/FCTC_Home.htm 3. Holladay, K.L., Lents, D. "Specification for Field Calibrator Interface." ISA Field Calibration Technology Committee. http://www.isa.org/~pmcd/FCTC/FCTC_Home.htm 4. HART Application Guide. HART Communication Foundation. HCF_LIT-34. (see http://www.hartcomm.org) BIBLIOGRAPHY 1. HART Technical Overview. HART Communication Foundation. HCF_LIT-20. (see http://www.hartcomm.org) 2. "The Complete HART Guide." HART Communication Foundation. (see http://www.hartcomm.org) 3. "Unleash the Power". Control Magazine. August 2001

Page 32 of 32