Fieldbus Wars continue: EDDL vs. FDT/DTM

The following is extracted from paragraph 1.4 of the FDT Interface Specification, Ver 1.2, 2004: “Within FDT only interfaces in ActiveX technology are specified for the engineering components of field devices. If the engineering system implements the corresponding interfaces, the ActiveX technology provides the automatic integration of the components and takes care of the interaction between the engineering system and the software components of the devices. Furthermore the FDT interface specification allows the integration of device components with integrated user interfaces as well as the embedding of ActiveX controls provided by the device component for special engineering tasks.”

FDT advocates are quick to point out that FDT was designed to support the field device configuration tools, but not the real-time operational software for which EDDs are designed. The question is: Now that EDDs have been defined as a standard by the IEC, making no distinction between engineering use and real-time use, and have been accepted by all three process control fieldbus consortiums, is there any need for FDT?

To complicate the matter even further, OPC (Online linking and embedding for Process Control) also has applications in this same space: the interface between the control system and the field device. OPC states that it is a high-level protocol for standardizing “host to controller communications.”

However, with controllers potentially resident in field devices, OPC impacts this same area of communications. FDT claims to be a high-level protocol for standardizing field device to engineering configuration tools. Both are built on Microsoft COM/DCOM and use XML-encoded data frames (in OPC/DX and OPC/XML). OPC states that it is intended for Ethernet-based automation networks, whereas FDT is designed for fieldbus networks. However, OPC has been used on a wide variety of networks other than Ethernet, as well as with operating systems other than Windows. Furthermore, OPC is now used with Foundation Fieldbus networks to access measurement and control attributes of Foundation Fieldbus function blocks in both controller and field devices. Finally, as stated in the announcement of joint cooperation, the OPC Foundation supports EDDL. Clearly, as Ethernet-based control networks converge into the domain of fieldbus, there will eventually be a conflict between OPC/DX, FDT/DTM, and EDDL.

Practical Analysis
Process control end users do not write programs, and do not see these interfaces directly. They see only software tools provided by the device or system manufacturer that usually express the attributes by an expressive phrase such as “High-High Limit.” This permits the software supplier to build data input scripts in different languages according to the native language of the end user. Entire closed loop regulatory control systems are configured without knowing EDDL, FDT, or OPC using only the fill-in-the-blanks on-screen forms provided by the control system supplier’s engineering software. Likewise, HMI screens and SCADA systems can be configured using only the tools provided by the HMI or SCADA software supplier without knowing EDDL, FDT, or OPC.

FIGURE 2: VERY DISTRIBUTED CONTROL

Fieldbus and smart valves permit locating the controller in the control valve, distributing control to the exact point it is needed.

Finally, the main issue is: support by manufacturers. Emerson and Siemens have declared that they will not support FDT/DTM on their products. This means that Rosemount field instruments, DeltaV DCS, MicroMotion flowmeters, Brooks instruments, Fisher control valves, Siemens field instruments (formerly Moore Products), and Simatic 7 DCS will not provide this support. No change in supplier preferences are predicted from this lack of FDT/DTM support, since the end user will not see any material difference in using these products, all of which will support EDDL, from using competitive products from Foxboro, ABB, Endress+Hauser or Yokogawa. Honeywell has not yet committed to FDT/DTM. All have committed to support of EDDL, however.

DDL is presently used by most DCS suppliers to design robust operator HMI and engineering tools for system configuration. The EDDL modifications simplify this software by elimination of many proprietary extensions and differences between the fieldbuses. Legacy DDL-based field devices from all suppliers will interoperate with DCSs written to this new standard. DCS suppliers will be free to make any changes without affecting field device performance.

FDT/DTM was developed with goals similar to DDL, but directed toward simplification of engineering software used to configure systems with intelligent field devices operating on several different networks. The goals for the development of FDT/DTM are admirable, but they were developed well before the evolution of EDDL. Now, from the position of looking backwards from the future, it appears that EDDL exceeds the goals of FDT/DTM in the following ways:

• 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.