What Is a HART Device Description (DD) File?
The first time a generic HART host fully configures a transmitter it has never seen, something had to teach it what that transmitter's menus, parameters, and special commands mean. That something is the device description file. This page explains what a DD is, how it is written, and why loading the right one is often the difference between a host that can only read a device and a host that can actually configure it. It is aimed at anyone maintaining a device-description library or wondering why their host does not show a device's advanced settings.
HART Device Description in one line: A HART device description (DD) is a standardized file, written in the Electronic Device Description Language (EDDL), that describes a specific field device's variables, commands, menu structure, and configuration procedures to a host. Loading the correct DD lets a generic HART host or asset-management tool present and configure that device fully, including features behind device-specific commands, without the manufacturer's own software.
What a DD Actually Describes
A device description is a portable file that answers, for one specific device model and revision, every question a host would otherwise have to guess. It lists the device's variables and their units, names its commands including the device-specific ones a generic host cannot interpret on its own, defines the menu tree an engineer navigates, and encodes the step sequences for procedures like a sensor trim. In effect it is the device's manual translated into a form software can execute, so the host renders the same menus and runs the same procedures the manufacturer intended.
DD files are written in EDDL, the Electronic Device Description Language, which is a standardized, text-based description language rather than executable code. Because EDDL is a description and not a program, the same DD works across any conforming host - a handheld, a plant asset-management station, or a configuration tool from a different vendor - and it cannot carry the platform-specific behavior or the crashes that native drivers sometimes do. The DD tells the host what to show and do; the host supplies the actual user interface.
This is why the command tiers matter here. Universal and common-practice commands are portable enough that a host can use them without a DD, but device-specific commands are opaque numbers until a DD explains them. Loading the DD is what turns a host from something that can read a device's dynamic variables into something that can reach the vendor's advanced diagnostics and calibration. The related page on HART universal versus device-specific commands sets up exactly the gap the DD fills.
Living With a DD Library
Because a DD is tied to a specific device type and revision, plants end up maintaining a library of them, and keeping it current is real work. When a manufacturer releases a new transmitter or a new firmware revision that adds parameters, the matching DD has to be installed in the host before that device can be fully configured; an out-of-date DD may show an older device's menus and quietly omit new features. FieldComm Group maintains registered DDs for conforming devices, and asset-management tools typically import from that library, but the responsibility to install the right revision sits with the plant.
The most common field symptom of a missing or wrong DD is a host that connects to a device, reads its identity and variables, but cannot show or change its detailed configuration, or shows a generic reduced menu instead of the device's real one. That is the host falling back to what universal and common-practice commands allow because it has no DD to interpret the rest. If a technician says the communicator can see the transmitter but half its settings are missing, the DD library is the first place to look.
For monitoring, the DD question separates two jobs. Bringing a device's process values and status into a system such as Merobix through a gateway or multiplexer leans on the portable commands and does not require every device's DD, so operations data flows without a full library. Deep, model-specific engineering configuration is where the DD becomes mandatory, and that work stays in the asset-management or handheld tool. The parallel concept for host integration on the FDT side is the DTM, covered in the companion page on HART DTMs and FDT frames.
Frequently Asked Questions
What is EDDL in HART?
EDDL, the Electronic Device Description Language, is the standardized text-based language a HART device description is written in. Because a DD in EDDL is a description rather than executable code, the same file works across any conforming host, from a handheld to a plant asset-management station, and the host supplies the user interface while the DD supplies the device's variables, menus, and procedures.
Do I need a DD file to read a HART transmitter?
Not for basic reading. A host can read identity, dynamic variables, and status using universal and common-practice commands without any DD. You need the correct DD to reach the device's full menu and its device-specific features - advanced diagnostics, special trims, and configuration behind device-specific commands - because those are opaque to a host until the DD explains them.
Why is my host missing some of a device's settings?
Usually a missing or outdated DD. If the host connects and reads variables but shows a reduced generic menu or omits newer parameters, it is falling back to what portable commands allow because it has no DD for that device type and revision. Installing the correct DD revision from the device-description library normally restores the full menu.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.