Tutorial: Instrumentation / DCS integration languages, part 1, EDDL
Tools to help integrate instrumentation into your DCS are available. They help with configuration, communication, calibration and HMIs.
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 month we consider EDDL . ( Read an earlier article on the competing technologies .)
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 specialized software for their systems to communicate with a variety of device manufacturers. It is agnostic to communication protocol, and can operate with standard analog 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 organized.
Once it became clear that users wanted to be able to extend DDL’s capabilities, the group added three major enhancements and rechristened 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, PWelander@cfemedia.com ,
Control Engineering Process Instrumentation & Sensors Monthly
Register here and scroll down to select your choice of free eNewsletters.
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.