Fieldbus Wars continue: EDDL vs. FDT/DTM

By Dick Caro, CMC Associates, Acton, MA

FOR MANY YEARS, the User Layer working group of ISA standards committee SP50--the creator of the function block concept now used in Foundation Fieldbus--characterized the function block as a software object resident on any network node. As in any software object, the internal algorithm of the function block is not visible or programmable by the user, although the supplier typically documents it. All the function block’s communication with the outside world is through its parameters, called “attributes” in software object language. The attributes are defined by the programming of the function block as specified in Foundation Fieldbus specifications or the supplier’s proprietary specifications, but their values are supplied from one of four sources:

1. Dynamic output attributes, such as the desired output valve position of a PID, are from the function block calculation,
2. Dynamic upstream cascade linkage, such as setpoints in a multi-level cascade,
3. Data entry by the configuration engineer during function block configuration, such as for initialization options
4. Operator or control engineer data entry during operation, such as for tuning parameters or manual setpoints, from the operator HMI.

Following this design, the name, data type, and any initial default values for function block attributes in Foundation Fieldbus were defined in the Device Descriptions or DDs that were exactly modeled on the equivalent definitions of HART. Profibus-PA also had similar definitions called EDDs, but were less well-defined, since there were no specified computations specified in the Profibus-PA standard for field devices. All of this has now changed since there has been an agreement by the Fieldbus Foundation, HART Communications Foundation, and Profibus International to use the common EDDL being defined in a draft international standard: IEC 61804-2 (2004-05), “Function Blocks (FB) For Process Control - Part 2: Specification of FB Concept and Electronic Device Description Language (EDDL).” All three consortiums are presently in the process of adapting the attributes specified in the draft standard to the same functions previously expressed by their proprietary data definitions. Therefore, all suppliers conforming to any of these three fieldbus specifications will accept the same terminology for any one attribute.

FIGURE 1: FIELDBUS AT WORK

More than 20 different pressure transducers connected via Foundation Fieldbus, saving wiring cost and making operation easier.

All three fieldbus organizations have contributed to the formation of the EDDL standard and continue to enhance it, especially in the area of display attributes. In the base DDs of HART and Foundation Fieldbus, display of data from a function block was limited to that data visible on a text-oriented handheld display. Realizing the limitations of this definition, EDDL is being extended to provide more extensive formatting information for presentation of attribute data on graphic operator stations used for HMI.

The following is a description of EDDL from the announcement of joint cooperation by the Fieldbus Foundation, HART Communications Foundation, PROFIBUS Nutzerorganisation e.V., and OPC Foundation:

“With EDDL, device developers do not need to deal with the burden of designing and programming a graphic display system to run under a variety of platforms and environments, from large HMIs to the small handheld. Instead, they can utilize common graphic display capabilities provided by commands in the EDDL. Since many host systems today already implement EDDL-based graphic display systems, devices using the extended EDDL have a common look and feel with existing devices. This permits uniform integration, configuration/setup, operation and diagnostics/maintenance, all very important in an interoperable, multi-vendor environment.”

EDDL seems to handle the problems of data exchange for both real-time access and for engineering use as long as the host system is a process control-oriented DCS or similar computer-based system. However, for general data access to user written or utility data historian software, another data access mechanism has been necessary. This application need has been filled by OPC. Again, OPC assumes the presence of software objects in the real-time system, and access to the named attributes of those objects, and is the reason OPC supports the EDDL agreement.

FDT (Field Device Tools) was created, several years before the EDDL agreement, to eliminate the need for the user to maintain the different attribute definitions for each fieldbus in use. FDT allows the field device supplier to offer a single DTM (Device Type Manager) independent of the fieldbus to be used for a project, whereas the host device uses an FDT Framework server that communicates with the DTMs of the field devices. Only the field device manufacturer knows the relationship between the DTM parameters and the equivalent EDDs. Most process control suppliers seem to be supporting FDT, especially those that also support Profibus-PA. FDT does not seem to have this same level of support in the factory automation world since few PLC suppliers have created FDT Framework servers or DTMs for binary field devices.