- Dynamic output attributes, such as the desired output valve position of a PID, are from the function block calculation,
- Dynamic upstream cascade linkage, such as setpoints in a multi-level cascade,
- Data entry by the configuration engineer during function block configuration, such as for initialization options
- 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.
Fieldbus and smart valves permit locating the controller in the control valve, distributing control to the exact point it is needed.
- More field instruments will continue to be available with EDDL, and not FDT/DTM.
- HMI displays of field device data will be more clear and uniform since they will be able to use EDDL.
- Use of EDDL for both configuration and operation provides much better integration with HMI and control systems.
- Control system and field device suppliers need only maintain a single interface data set.
It should also be noted that FDT/DTM does not provide for servicing the millions of HART, Profibus DP and Foundation fieldbus devices already installed by users without DTM support, but which support legacy DDL. FDT/DTM is also not currently supported on thousands of existing modern control systems installed over the past decade that support legacy DDL, and can use software updates to support EDDL.
Technical Analysis
FDT is designed to be a "software receptacle" into which a DTM from each field device is "inserted." FDT provides interfaces to the control system and becomes an integral part of it. FDT provides access to underlying services such as display, keyboard, database, digital communication interfaces, and other control system features. The mechanism is much the same as used within Microsoft Office to “insert” an Excel spreadsheet into a Word document.
The FDT specification requires the control system to be implementated using Microsoft Windows Operating System (OS) since it is built on Microsoft's Component Object Model (COM) and Distributed Component Object Model (DCOM) technology. Since COM/DCOM was not intended to communicate with process automation field devices, FDT extends these technologies to accommodate this requirement.
FDT provides the interface to the HART, Profibus, and/or Foundation Fieldbus communication drivers if they are present in the control system.
DTM software is supplied by the field device supplier as an Active X component on a disk or via the Internet. FDT is installed on the computer to be used for configuration as a component of its software architecture. The DTMs from each type of field device are then "plugged into" the FDT, using Microsoft Active X. Using available FDT services, the DTM provides all access to the field device during configuration.
All the information the field device manufacturer wishes to make available is programmed into the DTM. This includes real-time data, alarms, events, configuration information, screen displays, multilingual help screens, device specific documentation, parameter validity check, generation of dependent variables, diagnostic functions, and the device calibration sequence. A DTM can support more than one type of field device, but this increases its programming complexity.
In the FDT/DTM architecture, software for implementing HMI visualization of field device data is the responsibility of the field device suppliers. The HMI screen images appearing with data from the field devices have a different look and feel depending on the definitions of each field device supplier, and are not designed by the HMI supplier or the control system supplier. In contrast, EDDL ensures a consistent look and feel on the HMI of the control system, because the control system supplier designs a single interpretation for all device description files. The field device supplier only defines the specific DDs used for that field device and any of its function blocks, after they have been configured. FDT/DTM is not presently capable of providing a DTM that can display the DDs of a configured (instantiated) function block in a field device.
EDDL is designed for interoperability with all operating systems, since it does not depend upon any operating system support. FDT/DTM requires drivers (DTMs) that tightly integrate the field device software with the HMI or DCS operating system. This executable software must be maintained by the field device manufacturer and integrated by the control system supplier each time the operating system is updated.
FDT/DTM technology's operating system dependence, and its requirement for tight integration of software, lead to more challenging upgrades. For example, there are significant differences between Microsoft Windows 95, 98, Me, NT, 2000, and XP operating systems. More significant changes are coming in future Microsoft Windows releases that may require significant Graphical User Interface (GUI) changes. Each new operating system will likely require changes in ActiveX components that are part of the DTM. It is not reasonable to expect field device suppliers to maintain different software versions of their DTMs compatible with all of the versions of Windows used by the DCSs owned by their customers.
Finally, it is not reasonable to expect that all future HMI software will operate on a Microsoft Windows operating system, and will support COM/DCOM and ActiveX objects. Such operating system dependencies are at odds with the needs of industrial automation, even though we have been used WinTel-based systems for several years. The history of this industry also involves products constructed with various versions of UNIX. Use of FDT/DTM would preclude the use of Linux in future HMIs simply because it does not support the ActiveX architecture.
EDDL is operating system independent, and can be implemented without any dependencies on a specific host architecture. EDDL will certainly be supported on a Windows environment, but is easily implemented in a Linux or any other operating system environment. Field device suppliers have been supplying DDs for more than a decade and will find it easy to expand their capabilities with EDDL.
Conclusion and Recommendation
At the time it was created, FDT/DTM was a good idea, especially to compensate for the diversity of fieldbuses and the highly divisive market at that time. The situation has changed dramatically over the past few years: first by the agreements at the fieldbus standards level, and now by the adoption of an international standard EDDL by all of the major process control-oriented fieldbus consortiums. FDT/DTM has done its work with the majority of its ideas being included into the scope of EDDL.
End users are tired of vendor squabbling over technical issues that do not affect their ability to do work, and tend to divide the market over inconsequential issues. FDT/DTM has now become one of those inconsequential issues that tend to inhibit the end user from freely selecting field instrumentation based on important issues of accuracy, availability, longevity, serviceability, delivery and price. For the 95 percent of end users interested in using one of the dominant three fieldbuses--HART, Profibus-PA, or Foundation Fieldbus-- support of EDDL is an important issue. Support of FDT/DTM is no longer important and only serves to mask the important issues. Suppliers of both control systems and field instrumentation should concentrate all of the limited resources on development and support of EDDL, and no longer implement or enhance FDT/DTM beyond current levels.
About the Author |
Continue Reading

Leaders relevant to this article: