A colleague forwarded a recent ARC Advisory Group report, FDT Reaches Out to Process End Users. It described a recent briefing by representatives of the FDT Group to the ARC team. A few parts of the report that really raised some eyebrows among members involved in the ISA104, Electronic Device Description Language (EDDL) standard (a.k.a. IEC 61804-3).
The first part I’ll highlight:
FDT technology essentially standardizes the communication interface between field devices, control systems, and asset management systems. FDT is communication protocol independent, supporting devices that use HART, PROFIBUS, and more recently, Foundation Fieldbus (FF). It allows users to access device data and settings through any protocol or operating system.
Emerson’s Jonas Berge, a member of the SP104 committee sent me the following response after he had a chance to read this report:
Although it is true that both open and proprietary protocols are supported by FDT/DTM, it is not correct that any operating system is supported. FDT/DTM is based on Microsoft technology and only works for Windows. Operating system independence is a unique characteristic of EDDL so it protects investment in software and devices against obsolescence as new Windows versions, service packs, and hot fixes are introduced over the life of the system. With EDDL, workstations can freely be upgraded. Because it is not tied to Windows, EDDL also avoids registry conflicts when new device types and versions are introduced. This in turn enables EDDL to be loaded on the DCS operator console (device management need not be an isolated console) so operators can see device failures and take evasive action and inform the technicians (who are in the field, not in front of maintenance console). This is a key capability to integrate predictive diagnostics into daily work processes. Moreover, new device types and versions can be integrated without divulging the administrator password. Operating system independence is a necessity even if you use Windows workstations. It also makes EDDL suitable for handheld field communicators (the technician’s best friend for fieldwork) which are embedded devices not based on Windows. Thus, EDDL is supported in all tools from DCS engineering station for configuration, handheld communicators for commissioning and field service, device-management software part of asset management solutions during operation, and laptop software for the workshop. This is the reason why you only need EDDL and need not grapple with two technologies. EDDL with enhancements need not be complemented.
Another part of the report notes:
One major difference between FDT and EDDL is FDT’s standard interface between field devices (DTMs) and supervisory system (frame application software). Due to the standardization and openness of FDT, DTM’s from any supporting vendor can operate on frame applications from any supplier. The frame application provides a HMI to display device configuration, diagnostics, predictive alerts and more. EDDLs require an application that typically is proprietary, developed by vendors for their products that can be applied to multi-vendors with appropriate testing.
Jonas responds:
Device management software using EDDL are not proprietary. EDDL is an international standard IEC 61804 established since many years ago. Every control system supports the original EDDL from 1992 and most if not all support enhanced EDDL or have announced they will. Millions of devices from hundreds of manufacturers support EDDL including all HART and FOUNDATION fieldbus plus many PROFIBUS devices.
The OPC Foundation also supports the EDDL standard. Jonas recently wrote an article, OPC Made Easy, about the integration of the important OPC standard and its relationship with EDDL.
The ARC report also highlights an FDT evaluation report:
FDT further discussed the results of the WIB lab FDT evaluation report, dated November, 2007, executed by Shell Global Solution (SGS) using the FF protocol. The WIB International Instrument Users’ Association, of which SGS is a member, executed the unbiased test on behalf of WIB in their facilities. SGS compared specific FF functionality and evaluated the ability FDT to access and utilize device data for commissioning and maintenance purposes. Five distributed control systems (DCS) with standalone framework applications were tested with five field devices that supported both EDDL and FDT/DTM in all feasible combinations.
Jonas adds these observations to this report:
The WIB report, if read in its entirety, has some interesting observations. Although only one device was compared (so not all EDDL capabilities were seen), it makes clear EDDL is unique in supporting FOUNDATION fieldbus block configuration. Several times over, it mentions EDDL is the technology with no interoperability issues. The EDDL approach has a clear structure for configuration and setup. It also implies EDDL does a better job of commissioning and parameterization with a single tool. It also suggests EDDL has a less manufacturer specific, more consistent, look and feel. Lastly, it hints EDDL is more attractive for DCS systems because the files are not executable.
Although it may be true that combining EDDL with FDT/DTM you get some benefits from both, unfortunately you also get the drawbacks of both. Since FDT/DTM adds little or nothing to enhanced EDDL (they both do the same thing, albeit differently) there is no additional benefit to speak of. However, the drawbacks of mixing both technologies are plenty. For example, on its own EDDL protects the system investment because it is independent of Windows. Mix in FDT/DTM and your system no longer has this advantage. Similarly, the ability to integrate diagnostics in operator stations is lost as is consistent look and feel. The ability to add new device types or versions without conflicts is also lost.
Update: Welcome Feed Forward blog readers! I welcome your thoughts on this.
