What is a Device Description?

What is a Device Description?
What is in a Device Description?
Why are Device Descriptions a Good Thing?
Who creates a Device Description?
Who uses Device Descriptions?
Who distributes Device Descriptions?
How can I learn to write a Device Description?
What does a Device Description look like?
What about Fieldbus?

What is a Device Description?

A Device Description ("DD") is a formal description of the data and operating procedures for a field device, including commands, menus and display formats. It describes exactly what you can do to that particular device by HART communication. It is written as plain text, but is converted into a coded ("tokenised") form for use, for greater efficiency.

You probably already know that HART uses Universal Commands, which every device must implement, for common parameters such as Manufacturer, Device Type, Tag and Description, as well as to read the Primary Variable and up to three other process or derived variables. And HART uses Common-practice Commands for other common but not universal functions, such as changing the analogue signal range or reading more variables. It is possible to construct a fairly good and useful host application using just these commands.

But HART has the valuable feature that it also allows each device designer to invent new Device-specific Commands, giving access to unique functions or data within the device. It might seem difficult to write useful host software using these Device-specific Commands, without requiring customisation for each field device, but Device Descriptions provide the key.

What is in a Device Description?

The main things the DD describes are Variables, Commands, Methods and Menus. Every accessible variable in the device is included. That means the process measurements, any derived values, and all the internal parameters such as range, sensor type, choice of linearisation, materials of construction.

For each Variable, the DD specifies, among other things, the data type (for example: integer, floating point, alphanumeric, enumerated), how it should be displayed, a name for display to an operator, any associated units, and help text, perhaps describing the meaning of the variable or how it is used.

For each Command, the DD specifies the data structure of the command and its response, and the meaning of any command response status bits.

Methods describe operating procedures, so that a user can be guided through a sequence of actions, for example to re-calibrate an instrument.

The DD also defines a Menu structure which a host can use for an operator to find each variable or method.

Why are Device Descriptions a Good Thing?

If host software is written to use Device Descriptions rather than custom programming for each field device, a host can provide access to, and make use of, all the data and features of the field device, even though the writer of the host software knew nothing about the particular device. When a new field device appears on the market, we only have to give the host a copy of the DD to make all the new device's functionality available to it. No custom programming - no delay and no expense!

For an end-user, this means freedom to choose the field devices you prefer, from any vendor, yet gain full access to their capabilities from a single handheld communicator or other DD-using host system. All it takes is for you (or your host supplier's service department) to load the appropriate DDs into the host device.

Who creates a Device Description?

The device designer creates the Device Description as part of the development process for a new HART field device. It isn't difficult, and it doesn't take long to do. In fact, the discipline of creating a DD can help to clarify the development specification, making it more likely that the developed product behaves as planned.

The formal language used to write a DD is "Device Description Language" (DDL). It has defined keywords and syntax, with many similarities to the popular programming language "C".

Nearly all HART field device manufacturers have done this, and have made their DDs publicly available through the HCF's Device Description Archive. The result is that anyone, anywhere, can successfully configure their field devices, using the widely-used Fisher-Rosemount 275 HART Communicator.

Who uses Device Descriptions?

Host system designers use Device Descriptions, if they want the flexibility to work with any field device. This is particularly useful for instrument configuration and management applications; less so for a control system, which may well be satisfied with the access to measured variables provided by the Universal Commands.

As far as I know, the only hosts using DDs at the present time are Fisher-Rosemount's 275 HART Communicator, and their AMS ("Asset Management Solutions") software. In my opinion, this is rather sad, since there is so much data available in modern smart field devices, which could also be of interest to control systems and their operators. A particular case is the "additional device status" which is returned by Command #48. This often includes valuable diagnostic information (typically up to 30 individual items), including warnings of potential failure as well as reasons for an actual failure. The DD describes the name and significance of each of these status bits; a control system, or its operator, could make good use of this extra information to isolate, evaluate and respond to equipment warnings and failures.

Who distributes Device Descriptions?

A central archive of Device Descriptions is maintained by the HCF, and is available on CD-ROM to members. A new edition is published quarterly. If you want to see which field devices are included in the latest release of the DD library, download the PDF file from www.hartcomm.org/pdf/ddlman.pdf.

How can I learn to write a Device Description?

The HCF's Device Designers' Workshops introduce the concepts of the HART Device Description Language (DDL). But to get the whole story, you really should attend the HCF's 3-day DD Workshop. You can leave this workshop with an outline Device Description for your new field device.

What does a Device Description look like?

Here are a few small extracts from a HART Device Description. (Users: Don't worry if it's all gibberish! You don't need to understand it to get the benefits.)

What about Fieldbus?

The outstanding benefits of the Device Description mechanism are equally valuable when it comes to fieldbus instruments. And, indeed, FOUNDATION Fieldbus (FF) incorporates the same technology. Parts of the syntax of the FF Device Description Language differ from the HART DDL, because access to variables in FF is by Object Dictionary references, instead of HART's individual commands for each set of data. But much of the FF DDL is identical to the HART DDL, and the benefits are just the same - the ability to fully utilise the functions and data of a new field device, without custom programming. This is one of the keys to Interoperability, which is one of FF's strong points. (The other key to Interoperability in FF is Function Blocks.)

Home Top of page Consultancy