Standards for Device Integration: EDDL

01 April 2007

In this article and in the following issue (June 2007) we will present in more detail the device integration technologies currently spread in the process industry: EDDL and FDT/DTM.

Both technologies, though often marketed as being 'mutually exclusive,' are driving at supporting the end user of field devices in configuring, engineering, and maintaining his assets in a plant. Furthermore both
technologies claim to be open, to support different vendors and protocols, and to help the plant operator in
protecting his investment.

Astonishingly, most of these statements can be considered as correct for both technologies, so the most
interesting issues for us to discuss are the different technical principles behind them and the need for guidance so that device vendors and plant operator can understand the issues.

We will concentrate on EDDL in this article and save our discussion of FDT/DTM for next month.

Where EDDL came from
With the availability of so-called intelligent HART field devices and the emerging digital fieldbus technology in
the late 1980s, the need for telling the user how to set up such devices remotely became an issue. In 1992 the HART Communication Foundation was the first organisation to issue a specification for a 'Device Description Language (DDL).' This document and its basic concepts can also be seen as the ancestor of the 'Foundation Fieldbus Device Description Language (FF-DDL),' which was released by the Fieldbus
Foundation in 1996 and the 'Electronic Device Description Language (EDDL),' which became a standard of the PROFIBUS Nutzerorganisation (PNO) in 2000.

Each specification, though employing nearly identical syntax definitions, also described protocol specific elements, thus leading to incompatibilities between the device description dialects. In 2002 an international standardisation effort in the CENELEC and the IEC was started in order to have a single specification document. This goal was reached in 2004 when the IEC released the standard 61804-2 (now 61804-3).

In this standard document the device description language concepts and elements are specified in a harmonised manner. For each of the three fieldbus protocols an appendix defines the assignment of the DD elements.

In parallel with this, in a joint effort of the FF, HCF, and PNO, EDDL technology was enhanced generally by defining the means to describe richer user interfaces for device operation and to allow operations for data persistency. The results of this effort, also known as 'EDD enhancements part 1,' also found its way into the current IEC standard.

Still ongoing is the activity 'EDD enhancements part 2,' where FF, HCF, PNO, and the OPC Foundation are cooperating in order to further enhance EDDL. Their main goals are:

....The definition of means to use EDDL in OPC-UA server and client applications;

....Support of modular devices;

....Improve offline parameterisation means; and

....Specify means for a standardised identification of device data

The technical principle
The electronic device description language is mainly a descriptive language, not a programming language.
From a higher viewpoint, it can be said that it enables a device manufacturer to formally describe a model of its field device. The result of such a model is an ASCII-like text based file that can be edited and read with a simple text editor or, of course, with more sophisticated text-based tools. Such files are then called 'Device Descriptions' and can be processed by DD Host applications such as specific handheld devices or several
device parameterisation tools. The device manufacturer usually delivers the DD files with the device or insures the availability of DD files with the appropriate fieldbus organisation. The HART Communication
Foundation's HART CD is a well-known example of this.

The language elements of DDL can be assigned to three subsets:

....Device model;

....Communication model; and

....Operating model.

Though it is not our intention to be a tutorial for DDL, the following paragraphs use some rudimentary DDL
code for some main elements of these sub models.

The device model is built upon the atomic concept of the 'VARIABLE' reflecting a device's parameter (Figure 1). A 'VARIABLE' has an identifier (a name), a label and a help string for different languages, a class and a data type as well as an access definition and a validity condition.

In the example, the measurement value from the device is defined. A DD host application that is consuming such a variable definition now 'knows' that the matching device has a variable of type 'float' with corresponding default, minimum and maximum values. The variable is always read-only and according to its validity definition, the value will always be available. If the host is an application with some graphical
representation, it will use the LABEL and HELP texts in order to display them to the device operator. Usually a DD developer starts its work with defining all of the device's parameters in this way.

Current intelligent field devices contain 100 to 1,000 or even more of such parameters that become variables in a DD, so to display them to the user in a single, long list would not be very convenient or useable. Here the operating model becomes important. It allows the DD developer to structure the data set of the device, enrich its usage and even put it into a certain sequence. The main element of the DDL in this
context is the eMENUf that gives the DD host a means to display the device data in a structured and a clearly arranged way (Figure 2):

The DD developer first has to assign an identifier and a label to a menu. Based on that, any variable that was previously defined and further (sub-)menus can be listed under the 'ITEMS' construct. It is very clear that a DD host application can use such menu definitions for a simple and structured representation of the
device parameter set, even with the possibility of deeply structured menu trees. Especially the constructs defined in the aforementioned 'EDDL enhancements phase 1' initiative, give the DD developers improved means to enrich the operation of their devices. Among others,

....Graphs and waveforms allow assigning trend curves to parameters;

....Dialogues with line and column breaks and image references are means to graphically support the device operator.

The third model aspect is the communication model of a device, where the concrete access to the device (data) is defined. For HART devices, the HART commands that are supported are defined, for PROFIBUS and FF devices the addresses of the data within the device are declared (Figure 3).

A command consists of one or more transactions that always employ a request and a reply, reflecting the data to be sent to and to be received by the device (showing the HART origins). In an EDD for a HART device, the command number is necessary for the construction of the 'real' command to be sent via the HART interface. For a PROFIBUS device the slot and index information is needed in order to construct a correct acyclic read or write service.

Current state and use of EDDL
The use of device descriptions for the integration of field devices is widespread throughout the process
industry. Nearly all of the DCS systems offer a DD host that is able to interpret DD files. Also a range of several asset management software packages is available from different vendors that support EDD driven integration, such as AMS from Emerson and Simatic PDM from Siemens, as well as handheld devices like Emerson's 375 Field Communicator and the MFT from Meriam. Additionally, nearly all device manufacturers develop and distribute DD files for their devices, often collected and distributed through a communication foundation such as the HART CD from HCF. In the meantime, the first applications that support the EDDL enhancements are becoming available.

Dr. Rolf Birkhofer, CodeWrights GmbH, rbirkhofer@codewrights.biz


Contact Details and Archive...

Print this page | E-mail this page