Tutorial: Instrumentation / DCS integration languages, EDDL
24 November 2008
One of the tools that can help you get more from your instrumentation and other process control devices are integration languages, such as EDDL and FDT.
While the two have many similar characteristics and capabilities, there are subtle differences. This article considers EDDL.
EDDL (electronic device description language) was developed originally simply as DDL through a collaboration between Rosemount (now Emerson Process Management), Siemens, and Endress+Hauser as a utility that could communicate with HART enabled instrumentation via a hand-held device. The objective was to create a system that would allow control system builders a means to avoid having to write specialised software for their systems to communicate with a variety of device manufacturers. It is agnostic to communication protocol, and can operate with standard analogue wiring, or with fieldbus networks such as Foundation Fieldbus or Profibus.
Originally, the DDL utility had three major functional parts:
*Language—Syntax structures to enable a device’s designer to describe the field device parameters.
* Methods—A small scripting language to allow the device’s design engineer to write something like an interactive calibration feature that can operate on a PC or hand-held communicator.
* Menus—A hierarchical description of the parameters and how you want them organised.
Once it became clear that users wanted to be able to extend DDL’s capabilities, the group added three major enhancements and re-christened it EDDL:
* Definition of parameter screen displays (how devices should be displayed);
* Ability to have charts and graphs; and
* Persistent data, meaning you can save things you create for later use.
An EDDL file for a given device is like a plain text document that you can open in any number of word processing applications; while the text will always be the same, the way you see it on screen and how you manipulate it depends on the characteristics of the application you’re running.
When a control system opens an EDDL file, the system uses it as appropriate for the application. Unlike HART, the file does not exist in the device, so it doesn’t feed information to the system. The EDDL file is contained in the control system in a library. If you have a number of the same devices (e.g. the same pressure transmitter used in multiple locations) you only need one EDDL file for the group.
Control system vendors often have a wide variety of device files already in the system, in the same way that a computer can have drivers for a variety of printers from various manufacturers. Even if you change or upgrade control system platforms, the EDDL file for a given device remains the same. Conversely, if the device is upgraded, you can easily add the file for the upgrade to your control system.
The host control system builder has to support the platform, which has caused something of a division between builders. While there are builders who work with both EDDL and FDT, most only support one or the other.
So what are the functions that EDDL supports? How can it help you when installing a new device?
* All the parameters for setting up the device are included;
* Calibration routines for that device are included;
* All the HART diagnostics and secondary variables are outlined in detail;
* How data should be displayed on the HMI is defined; and
* How to graph the process variable is described.
None of this information is required to use a given device; however, like HART capabilities, EDDL provides tools that will allow you to get the most from a device, particularly in the context of a larger asset management program. Moreover, it supports consistency in HMI and data displays, which has many direct benefits.
Like HART, EDDL capabilities are there and can provide these important tools. All you have to do is use them.
—Peter Welander, process industries editor, Control Engineering Process Instrumentation & Sensors Monthly
Contact Details and Archive...
Most Viewed Articles...