Comment

1 July 2005

Teamwork

HART, fieldbus work together in integrated environment.

By Alan R. Dewey

Before talking about how HART and Foundation fieldbus devices can work together in the same system, it is important to understand how these technologies are similar and how they are different.

Devices using HART communication technology hit the market in the early 1980s. The HART Communication Foundation estimates there are 10 million HART devices in service throughout the world today. Foundation fieldbus devices started showing up in the mid 1990s. The Fieldbus Foundation estimates there are 300,000 Foundation fieldbus nodes in service in the world today. From these numbers, it is clear to see the installed base of HART field devices exceeds those using Foundation fieldbus. Fieldbus adoption does continue to grow, however. Although some plants going up today are virtually 100% fieldbus, the great majority of Foundation fieldbus devices are going into plants where HART devices already exist.

For this reason, it is important to understand how these two protocols can work together.

HART and fieldbus devices contain a myriad of configuration and diagnostic data. In HART devices, this data delivers via digital signaling "superimposed" on top of the traditional 4-20 mA current loop used to return (or send) the process variable (PV). The communication speed for HART signaling is 1.2 Kbps. With HART devices, the PV almost always derives from the 4-20 mA signal from the device despite the fact the PV is also available as part of the digital data provided by the device. In fact, many HART devices installed today still use only this PV and ignore the digital data provided by the HART protocol. On the other hand, HART protocol does allow several devices to connect in series in the same current loop, thus providing data digital data from each device. In this case, the current in the loop stays at a constant value, and the PV for each device comes from the digital data. Multi-drop HART networks see use in applications where fast update rates are not required.

A fieldbus protocol is 100% digital. The communication speed for fieldbus signaling is 31.5 Kbps. The concept of a device's PV being proportional to the current in the loop no longer applies.

Fieldbus devices connect in parallel on a segment that must terminate at both ends. Multi-drop configurations are common with fieldbus. Up to 32 devices can connect in parallel on one segment (without repeaters). The practical limit is less than this and depends on things like the fieldbus segment's power supply, intrinsic safety, and required response time of the devices.

Architectures

Different architectures are possible for integrating HART and fieldbus. The type of architecture used will depend on factors such as the capabilities of the control system computer, the ratio of HART to fieldbus devices, and whether the architecture can migrate to support fieldbus (or vice versa). Similar I/O interfaces would connect the HART loops and the fieldbus segments to the control system computer. In such a configuration, it would be typical for the fieldbus I/O interface to connect to multiple multi-drop fieldbus segments with multiple devices on each segment. The HART I/O, on the other hand, would typically be wired so each Hart device connects to a separate channel on the HART I/O interface. In any case, an on-line system will make available process and diagnostic data from the HART and fieldbus devices to the operator and maintenance consoles in a fairly seamless manner.

In some cases, the existing control system's I/O interface may not fully support HART I/O. In this case, a 3rd party HART Multiplexer can work to bring the digital HART messages into the control system. The HART Multiplexer can strip off the digital HART message and provide it to a software package running in one of the control system computers.

In some cases, there may be a desire to integrate HART and fieldbus devices on the same pair of wires. Although this is not possible directly, it is possible to accomplish something like this by using gateway-type devices. This may be the case if you have a fieldbus segment in a particular area of the plant where you want to re-use an existing HART device without having to run separate wiring.

Another example might be where you simply cannot find a fieldbus device to make the measurement you want so you must use a HART device for a particular measurement. In cases like this, you would most typically use a current to fieldbus input converter. In a similar way, you might want to re-use a HART valve on a fieldbus segment. Here you would use a fieldbus to current output converter. Although the use of these converters can be a good temporary solution, the disadvantage is you are no longer bringing the HART device's configuration and diagnostic data into the system.

Only the PV of the device is read or written. Some gateway converters on the market do attempt to map some of the HART configuration data into a pseudo fieldbus transducer block, but these gateways tend to be very device specific.

Managing data

HART and fieldbus devices have similar configuration and diagnostic data contained in them. HART and fieldbus use the same Device Description Language (DDL) to define their contents. That is where the similarity ends.

When HART first came out, the primary means of configuring these devices were handheld computers and simple PC tools. This drove the HART device manufacturers to develop menus for their devices using the DDL language. These menus organized configuration and diagnostic data into logical groupings such as basic setup, detailed setup, and range. These text based menus worked well with handheld communicators. When more sophisticated PC configuration and Asset Management packages came out, suppliers of these programs usually required a different file be developed for each device to better make use of the color graphic capabilities of a CRT screen.

Although roughly based on the menus developed for handhelds, the configuration files used for the PC programs provided the device's configuration and diagnostic data in a more user friendly manner.

When the fieldbus protocol came out, device parameters organized into blocks. Parameters in a fieldbus device are:

• One resource block containing general identity information about the device.
• One or more transducer blocks containing configuration and diagnostic information specific to that device.
• One of more function blocks for implementing control in the field on the fieldbus.
• Other miscellaneous device parameters such as tag and node address.

Suppliers of fieldbus control systems and configuration tools usually display a fieldbus device's parameters organized by the above block types. Within each block type, the parameters list either alphabetically or in accordance with a special vendor specific file provided for that device.

Again, this special file should organize the parameters in a logical manner and make use of the color graphics capabilities on the control system's console. Because no handheld configurators for fieldbus were available when it came out, there was less incentive for device suppliers to develop device description menus like they were for HART. Therefore, the device's registered device description is less likely to provide a logical organization of a device configuration and diagnostic data in a fieldbus device than in a HART device. This makes the vendor specific file for formatting this information even more important for fieldbus devices.

The industry understands the need to provide a standard way to organize parameters for HART and fieldbus devices. A joint committee from the Fieldbus Foundation, the HART Communication Foundation, and the Profibus Nutzer Organization released a specification for extensions to the Electronic Device Description Language (EDDL). The EDDL extensions provide a way of grouping parameters in the device's device description without the necessity of special formatting files for the control system.

Integrated strategies

One fundamental difference between HART and fieldbus devices is you can implement control strategies in the field devices themselves with fieldbus devices. You can implement the same control strategies with HART devices, but the execution of actual control algorithms would go on in the control system computer or PLC. A well-designed control system will allow an integrated control strategy to use devices independent of their communication protocol.

HART and fieldbus devices have the capability of providing a wide range of diagnostics data about the device's health. In general, the diagnostic capabilities of HART and fieldbus devices are about the same. The types of device diagnostics vary widely depending on the type of device. Measurement transmitters will have diagnostics related to the status of the transducer and measurement logic in the device. Control devices such as valves will provide a lot of information about the mechanical condition of the device. Both transmitters and valves will provide diagnostics information about the communication electronics in their respective devices.

Although the diagnostic data provided by HART and fieldbus devices is very similar, the way they get to the control system and the way the operator or technician see it can be quite different. The reason has to do with the speed and characteristics of the communication technology used by these two protocols. Fieldbus uses point-to-point communication technology. This means when a fieldbus device detects a diagnostic condition it wants to report, it can send an event out on the bus with the relevant information. The control system picks up the event and immediately displays or annunciates it on the console. HART devices, on the other hand, have to continually undergo polling to see if there is anything to report. Because the polling occurs at 1,200 BPS with HART, there are limitations on how many devices it can poll for alerts in a specific timeframe.

An operator can poll a small number of critical devices for alerts within seconds or a large number of devices within

minutes. Nevertheless, it is possible to implement an effective diagnostic alert system with HART as long as you understand the restrictions on response and device count.

Once the operator or maintenance person becomes aware of a problem in a field device either via an alert or some other means, the actual display of the status information from HART and fieldbus devices is very similar. Often times, a record of this status event will automatically log into the control system. Again, the logging of HART and fieldbus device problems should normally look the same on a well-integrated system.

The diagram shows how a user might setup a control strategy using fieldbus and HART devices. The function blocks in the "HART" loop (i.e.AI1 and PID1) loop look exactly the same as those in the "fieldbus" loop (i.e. AI2, PID2, and AO1). The only difference is the input block in the HART loop (i.e. AI1) is identified with the host control system's I/O card and channel number while the input and PID blocks for the fieldbus blocks use the device tag of the fieldbus devices.

Integrated tools

It is also important to consider what type of portable maintenance tools one needs in systems that contain HART and fieldbus devices.

Portable tools currently fall into two general categories. The first is intrinsically safe handheld devices. Several exist for HART only devices. A combined HART and fieldbus intrinsically safe handheld device has become available. This integrated tool allows the user to configure and diagnose HART and fieldbus devices while in the field.

The second type of portable tools is around laptop or notebook computers. Ruggedized versions of these portable computers can make an effective tool. The only disadvantage is you need a separate interface for HART and fieldbus. These types of computers cannot go in hazardous (i.e Class 1 Div 1) areas of a plant.

As far as small handheld computers go, how practical these will be in a plant environment—even the ones classified for Class 1 Div 1 areas—remains up in the air.

Behind the byline

Alan R. Dewey is principal product marketing manager for Emerson Process Management in Eden Prairie, Minnesota.