Integrating field devices in process automation is an evolving story, and users are still grappling with rewriting different endings to fit their manufacturing processes. The task at hand for several years has been how to provide a common interface look and feel for all devices, finding software that allows staff to access and manage engineering, startup, and maintenance data during operation and maintenance phases. But the proof is in the pudding. Can one technology really meet all industry demands? Our test lab took one software technology to task—with promising results.

Today’s market demands require manufacturers to implement multi-phase coverage of system life cycles. Two technologies are making waves in the marketplace to facilitate this: field-device tool (FDT) and electronic device description language (EDDL). (See accompanying articles on FDT and EDDL.)

Although both have their advantages and disadvantages, they should meet user demands, as formulated under Normenarbeitsgemeinschaft für Mess-Und Regeltechnik (NAMUR) Recommendation 105, imposed for integrating fieldbus devices into engineering tools for field devices. The most important of these demands include:

* Device descriptions should be independent of the operating system involved.
* User interface and style guides are necessary.
* Device installation/uninstallation should incorporate into configuration tools.
* Device functionalities should see full support.

The FDT technology group met with EDDL’s cooperation team (ECT) last spring at Hannover Fair in Hannover, Germany, to become official members of the ECT. The goal was to develop a common future device integration (FDI), based on a client server architecture and hopeful as an international standard. The FDI would be based on an independent platform and operating system and independent host system. It would be compatible with existing EDDL- and DTM-based device descriptions and applicable to any field device communication technologies. It would also be applicable for hierarchical and heterogeneous network topologies and an open specification.

Lab tests EDDL with use cases

BIS Prozesstechnik’s testing laboratory in Frankfurt, Germany, conducted comprehensive testing to clarify the extent to which the current EDDL standard allows the process automation industry to meet the demands of device startup, operation, and diagnostics. During an online test, the lab developed a series of typical user cases that could arise during device life cycles and verified these on existing devices. We tested the utility of enhanced EDDL and its advantages and disadvantages from the user’s perspective. This test program included four phases: planning, startup, operation, and maintenance. Each use case contained a series of testing stages.

The test system contained devices for measuring temperatures, pressures, and fill levels, as well as various actuators and a frequency converter. Devices equipped with Fieldbus Foundation (FF)/HART/Profibus decentralized peripherals (DP)/process automation (PA) interfaces were available.

Planning, startup phases

Here are some answers to users’ questions during planning and startup phases.

Q: Which device models suit which electronic device descriptions (EDD) revisions, and are there any incompatibilities between host-system EDDs and device EDDs?

A: The authors of the specification believed it was important to keep existing EDDs from FF/HART Communication Foundation libraries upwardly compatible to protect existing installations. Compared to HART and FF, Profibus supports the most extensive subset of the entire linguistic syntax specified under the standard. Its Profibus DP devices, e.g., frequency converters, which are employed in manufacturing industries, frequently impose more stringent demands on their operation, and thus on the software applications involved.

BIS noted host manufacturers were working feverishly to implement the standard, and had either already implemented it within broad areas or will have completed its full implementation in the near future. Because of the various states of development, some dependencies remain. For example, one of the host systems tested did not support representations of operator guides (wizards) and yielded host-dependent EDDs. If the suppliers of host systems uncompromisingly and fully implement the standard as they have stated, we can realize interoperability—a single EDD per device.

Q: Which software tools are needed for planning and startup phases?

A: For planning and startup purposes, it is sufficient to install an EDD host system that makes available a number of basic functionalities and covers every device involved. The next step is to load the enhanced EDDs supplied by device manufacturers onto the respective host systems for each device involved. Offline viewing of the EDDs then provides users with a brief overview of the applications and features of the various devices.

The devices involved frequently incorporate numerous (usually well over 200) parameters. Users formerly had to search through long lists of parameters to find the correct ones before setting these on each device. However, users only need short subsets of parameters for their applications. These most-important parameter settings may be set by wizards that allow rapid, intuitive, device startups.

Q: Which protocols does EDDL support?

A: IEC 61804-3 describes the language content for use with FF/HART/Profibus DP/PA devices. None of the host systems currently available support all protocols involved. However, Emerson Process Management and Siemens have said their host systems will support all three protocols within the next year or two.

Q: Are software updates necessary to use all features?

A: In the case of all those EDDs installed, the lab found the host systems currently being supplied almost completely support all EDDL enhancements. Since current EDDs have been only slightly tailored to suit given host systems in areas related to their graphical user interfaces, those host systems need no updates or add-ons to fully execute such EDDs. However, the goal must be the ability to use EDDs that exploit the full complement of EDDL’s features on any host system.

Operation, maintenance phases

Q: Is error-free installation of an EDD possible, even on existing installations and during operation?

A: A catalog of devices will usually be provided for installation of a host system. Some or all of these devices may be installed on the system. Host systems have their own applications for retrofitting devices. EDD setup procedures will thus have the same look and feel, which is highly beneficial. Even during operation, installation of device EDDs using the applications mentioned proceeded rapidly and without errors. Since the EDD syntax is translated, or interpreted, only by the host system, EDDs have no effect on the operating system involved. No restarts were necessary following their installation. There also were no interactions with Windows system files.

Q: Can devices be simply, intuitively operated?

A: The lab defined a series of different applications scenarios for various types of devices, ran the applications, and analyzed the results. Example scenarios included rapid operational procedures under which users had to set only the most-important parameters and conduct procedures typical for the devices involved. These procedures included the partial-stroke test for actuators and determinations of the echo profiles of fill-level radars. A series of language enhancements under IEC 61804-3 allow much more flexibly configuring user interfaces than was formerly possible.

The first step involves setting the values of parameters, such as starting position and step length. A graphical display clearly informs users what each parameter means. The second step involves measuring the reference time and determining the limits beyond which violations of the reference time will trigger notifications about maintenance status. Users may then conduct a partial-stroke test, save the plot, and compare it to earlier measurements. This sort of representation guides users step by step through the procedures involved, without the need to consult other documentation. It is a good example of how to use EDDL to intuitively implement a complex operational procedure.

Q: Is it feasible for interfaces and operational procedures to have a common look and feel?

A: All host systems support a number of basic functions, such as reading, writing, printing, numerical comparisons, and data storage. The lab found in all cases users could call up certain functionalities, such as device status transmittals or processing parameter displays, from the same locations. Since those basic functions are not constituents of EDDs, they appear on the respective host systems in forms that have a common look and feel. However, device operational procedures or parameter terminologies, which are usually implemented in EDDs, differed from manufacturer to manufacturer in this test program. Text entries and tabular data previously dominated visual displays of EDDs. It is now possible to implement much more sophisticated interfaces, although they may differ widely from manufacturer to manufacturer. It is imperative to develop a guideline to implement EDDs for typical types of devices from all manufacturers, particularly during early implementation of the standard. That guideline should cover the terminology used to define parameter names and devote particular attention to how the parameters involved are formatted, including their offline/online representations and diagnostics.

Q: Can all device functionalities be implemented using EDDL, or are additional tools necessary?

A: Of course, the growing complexity of the current generation of processing devices imposes more stringent demands on user software. EDDL is frequently criticized for its failure to allow implementation of complex device operational procedures. However, the BIS testing showed all operational procedures relevant to the tested devices could be implemented without the need for additional software. These included the handling of interfering echoes in the case of fill-level radars, the calibration procedures for temperature gauges, and the startup of frequency converters.
ABOUT THE AUTHOR

Sven Seintsch (Sven.Seintsch@BIS.bilfinger.com) is a senior test engineer at BIS Prozesstechnik GmbH, a Frankfurt, Germany-based industrial service provider specializing in the chemical and pharmaceutical process industries.
EDDL, FDT: The basics

EDDL technology defines a language of its own, the electronic device description language, which allows manufacturers to describe field devices by means of an electronic device description (EDD). A special software tool processes this EDD. Which tool manufacturers use depends on the particular operating system involved. But because of the EDDL standard, the EDD is independent of operating-system platforms. In the past, the language had limited functionality, which was a disadvantage of EDDL technology. To address this problem, the language has recently been extended to include enhanced EDDs.

EDDL per IEC 61804-3 incorporates all features needed for the intuitive operation of modern devices employed in processing industries. However, the testing to date has also shown discrepancies occur among the various manufacturers, particularly with implementing the standard on host systems.

According to the FDT Group (www.fdtgroup.org), field device tool (FDT) technology standardizes the communication interface between field devices and systems. It closes the fieldbus gap by providing a standard way in which device vendors create user interfaces for advanced device management. FDT technology is deemed truly open, so the theory is users can have device data presented effortlessly as useful information, regardless of their chosen fieldbus protocol, device vendor, or device type. The key feature of FDT technology is its independence from the communication protocol and the software environment of either the device or the host system.

SOURCES: Sven Seintsch, senior test engineer at BIS Prozesstechnik GmbH in Frankfurt, Germany, and FDT Group (www.fdtgroup.org).

EDDL vs. FDT: Thwarting misconceptions

InTech talked to proponents of EDDL and field device tool (FDT) to find out how the two technologies stack up. Experts Terry Blevins and Jonas Berge of Emerson and Ahmad Zahedi of Flowserve Corp. gave their views on how the industry is using both.

InTech: What’s the difference between EDDL and FDT?

Berge: FDT and EDDL are two technologies that do pretty much the same thing but differently. The purpose of both technologies enables software to send the right command to the device, get the information back, decode it, and display it to the user. So both technologies are used to enable users to configure and set up, calibrate, and diagnose the devices.

Zahedi: The major differentiator between EDDL and FDT is how devices are presented and who defines the diagnostic interface. With EDDL, the DCS supplier defines how a device is presented and which diagnostic features are included for the device. FDT defines a standard interface between the device and DCS frame as well as a style guide for development of DTMs.

Blevins: FDT/DTM provides some capability that the original device description (DD) technology from 1992 did not support. This includes, for example, graphics and persistent data storage (keeping test results for future comparison). Therefore, original DD could not be used for complex devices or advanced diagnostics. The newer enhanced EDDL has graphics and data storage and supports sophisticated devices as well as advanced diagnostics and setup. It thus supports all phases of the life-cycle: configuration, commissioning, operation, and maintenance. So it need not be complemented by other technologies or proprietary tools.

InTech: Who would use EDDL and who would use FDT?

Zahedi: The end user is the ultimate customer of FDT and EDDL. However, FDT technology coupled with diagnostics can be integrated into the plant asset management systems and provide more functionality to the maintenance engineers. EDDL would be more geared toward proprietary systems or simple devices, which may not require advanced diagnostics. FDT/DTM will give the device manufacturer the freedom to work on their advanced diagnostics as well as provide operational software geared towards a customer’s specific needs (engineered-to-order diagnostics).

Blevins: From a device-management-software point of view, FDT/DTM does the same thing: information, calibration, setup, and diagnostics. However, FDT/DTM only works on Windows, so it is used for work from the control room. Although you can bring a Windows laptop with interface to the field, it is too heavy to hold and cannot be operated with a gloved hand, has limited battery life, and in general is not rugged enough. EDDL is also used on device management software part of asset management solutions and then enjoys the full Windows look and feel, but EDDL can also be used on handheld field communicators that are ideal for field work and have become the technician’s best friend.

InTech: How are users using EDDL and FDT now?

Zahedi: End users and major companies are increasing specifying FDT/DTM requirements for new projects and plant re-instrumentations. Smaller end users are showing a great interest in having advanced diagnostic capability to reduce reliance on their in-house engineering and technical resources. Small end users see advanced diagnostic capabilities of FDT/DTM running on a simple frame (and without a DCS system) as a cost-saving measure and critical to maintaining their competitive edge in the market place.

Blevins: EDDL is used in DCS engineering workstation to configure database and function block control strategy. It is used in handheld communicators for commissioning and field calibration and in device management software for calibration, diagnostics, and setup of simple and sophisticated devices. It also sees use on laptops in workshops for bench setup and calibration.

InTech: What are users saying about EDDL and FDT?

Zahedi: Feedback from end users is that eliminating proprietary systems will free them to choose devices that provide the most cost effective solution for their application.

Blevins: DD/EDDL was never promoted on its own; therefore awareness is low although almost every plant is using it. Because EDDL is an integral part of HART and FF, plants will tell you that is what they are using. They have used EDDL for 15 years without even knowing. Only over the past year or two have users started hearing about DD/EDDL, and they are often not told the right thing, causing confusion.

 

Links