HART Protocol - FAQs
These FAQs have been compiled from HART Communication, PACTware, and FDT Group with some changes to fit the unique questions asked by our customers.
Additional information and support for the HART Protocol can be found at the Romilly's HART and Fieldbus web site.
The HART Communication Protocol (HART = Highway Addressable Remote Transducer) defines a bi-directional field communication protocol standard for instrument, control and automation systems. Actually, it's not just a standard, but the global standard for sending and receiving digital information across analog wires between smart devices and host systems. A host can be any software application from technician's hand-held device or laptop to a plant's process control, asset management, safety or other system using any control platform.
There are several reasons for using HART Communication to enhance the data flow between hosts and field devices. These include device (re)configuration, diagnosing and troubleshooting instruments, reading values of additional measurements provided by the device, and much more. It can provide many benefits, including playing a major role in improving plant operations, increasing asset availability, reducing maintenance costs and aiding in regulatory compliance. In all these roles, HART technology has proven to be easy to use and very reliable. For more information on the features and benefits of HART technology, please refer to the "About the HART Protocol" section of our website.
The HART Protocol provides two simultaneous communication channels on the same wire: 4-20mA “current loop” analog and a HART digital signal. While the analog signal continues to provide primary values to and from field instruments, the digital signal provides additional device information. This is a very robust method with roots in the Bell 202 Frequency Shift Keying (FSK) standard, which originally superimposed a digital communication signal "on top of" the 4-20mA current loop to bring Caller ID technology to the field of telephony.
Key to the HART Protocol's ability to "get data out of the field device" is a data file called a Device Description (DD). This describes the features and functions of a device, such as the form and content of menus and graphic displays to be presented in host computers or handheld devices. The DD is written in conformance with a Device Description Language in the protocol. The HART Communication Foundation manages a library of Manufacturer Device Descriptions, and provides regular updates to which any Foundation member can subscribe. DD’s are available for download at the HART Communication Foundation website. The DD is not required for communication with HART-enabled devices. It is an optional enabling element of HART technology that most device and host suppliers support in order to offer HART Users the added value of multi-vendor interoperability
PACTware does not support DDs directly, but there are several software tools available on the market which convert DDs into DTMs to be used in FDT frames like PACTware.
In this case Generic DTMs can be used to configure most of the parameters. Microflex HART protocol modems include the fully licensed Generic HART DTM-4.
The Generic DTM supports the HART commands which are common to all HART instruments (Universal and Common Practice commands). A typical instrument will contain device specific commands that will require a more device specific DTM for full support.
PACTware supports all common communication protocols by adding the specific protocol layer. Microflex modems ship with PACTware and the HART communications protocol layer.
The FDT standard supports both DD and DTM configuration methods.
The DD (Device Description) Language allows a device to be described using a text like language. This is then compiled into a DD file that is unique for each HART, FF, and Profibus network. The host system interprets the compiled DD file and determines how a device appears in the applications..
While the DD method is a simple way to describe the device, it is at the same time limited in the features it offers.
The DTM method of representing a device is consistent in any FDT Frame application. The device supplier is in control of the visualization, functionality and advanced features.
FDT Technology standardizes the communication interface between field devices and control systems or engineering and asset management tools. Key features are its independence from the communication protocol and the software environment of either the device or the host system. FDT Technology allows any device to be accessed from any host through any protocol.
The FDT interface specification describes the standardized data exchange between devices and control systems or engineering and asset management tools. Devices can be configured, operated, and maintained through the standardized user interfaces integrated in an FDT Frame Application.
A Device Type Manager (DTM) is part of the FDT standard that is a software component for a device that contains the device-specific data, functions and logic elements. DTMs can reach from a simple graphical user interface for setting device parameters up to a highly sophisticated application that, for example, can perform complex calculations for diagnostics and maintenance purposes or can implement arbitrarily complex business logics for device calibration.
The DTM also contains FDT-compliant interfaces to enable communication with the connected system or tool. DTMs are classified as Device DTMs, which represent a field device, and CommDTMs, which represent communication components (gateways, remote I/Os, couplers, etc.).
A typical FDT based application can contain dozens, hundreds, or thousands of Device DTMs and CommDTMS from a variety of manufacturers to make up the system.
The FDT specification supports the communication protocols AS-interface, CANopen, CIP Annex Configuration, ControlNet, DeviceNet, EtherNet/IP, FOUNDATION Fieldbus, HART, INTERBUS, IO Link, MODBUS SL/TCP, PROFIBUS DP/PA, and PROFINET I/O.
The FDT Group is open to future developments and market requirements and continues to expand its support of new protocols.
Due to the open nature of the standard, several device and host manufacturers have even added their own proprietary or legacy protocols to the standard for use in their own applications.