Swimming in the Alphabet Soup of Device Management

FDT. FDI. EDDL. DTM. What They Are, Why They Matter and How Sorting Them Out and Using Them Is Getting a Bit Easier

By Nancy Bartels

1 of 2 < 1 | 2 View on one page

Anybody who's worked in technology for longer than about a week begins to understand, if only dimly at first, the problem of competing technologies and its implications for one's technical life. Mac or PC? iOS or Android? Wired or wireless? Foundation Fieldbus, Profibus or HART?

Deciding which way you want to download your music files or use your cell phone is one thing. When you're talking about connecting hundreds or even thousands of field devices to your PLCs or DCS, the decision is a bit more fraught. Once you've committed to one method, you've committed to a particular way of doing things and sometimes a particular set of vendors. If, like most operations, yours uses technology from multiple vendors, you now have the problem of getting multiple systems and architectures to work smoothly together, and making sure the legacy systems work with the new ones, all of which inevitably adds time and money to any project, not to mention frustration and more gray hair.

The Past Is Prologue

Device management, the business of organizing and connecting the myriad of field devices in your operation and then making best use of the information gathered from them, is no different—which brings us to the alphabet soup that surrounds any discussion of device communication technology.

The first two technologies and acronyms you need to learn are Field Device Tool/Device Type Manager (FDT/DTM) and Electronic Device Description Language (EDDL). These are the two major technologies that, under the covers in your devices, make their connectivity possible.

The two technologies are at the same time complementary and competitive. So, in the early days at least, their history sounds a bit like the notorious fieldbus wars. Even now, the true believers in both camps carry on arguments not unlike those heard in coffee houses about Macs and PCs. There are details and nuances about each that only a true techno-geek—or a medieval theologian—could love.
For the rest of us, here are the distinctions. EDDL is used by major suppliers in the process industries to describe the information accessible in smart field devices. It supports device diagnostics and calibration, and it can be used in any device from a handheld terminal to a process control system.

It's an international standard (IEC 61804) and is supported by the HART Communications Foundation, Profibus and Profinet International, the Fieldbus Foundation and the OPC Foundation.

FDT is the IEC 62453 standard. Its roots are in discrete manufacturing, and since the early 1990s, it's been supported by vendors with interests there, such as ABB, Endress+Hauser, Invensys, Metso and Siemens. But, it's also used in the process industries. It supports more than 16 protocols used in the process industries and factory automation, including Foundation fieldbus, HART, Profibus/Profinet, DeviceNet, Interbus and AS-Interface. It has some advanced functions that EDDL does not, such as graphical representation of information. It also works well with complex devices, such as radar level gauges. The notable virtue of FDT is its independence from a particular communications protocol and from the software environment of the host system. Any FDT-enabled device is accessible from any compliant FDT host using any field communications protocol.

FDT is also more complicated than EDDL. It has two parts: the frame application, FDT Frame, and the Device Type Managers (DTMs), which are available for field devices and communication equipment. Think of the two as the equivalent of the print manager in your Microsoft Office program and the print drivers. The strong suit of FDT/DTM is its ability to interface with multiple devices and process a high level of diagnostic information.

Larry O'Brien, global marketing manager for the Fieldbus Foundation, explains, "EDDL is like XML for intelligent devices. FDT is more sophisticated software for handling diagnostics. It's more of a runtime environment. It's really good if you're managing information from complex devices, and it has more power than EDDL. EDDL is very simple. FDT has more complexity and the same issues as any Microsoft environment in terms of updates and patches."

It's easy to see how choosing one or the other could be a complicated and frustrating decision, and one that end users might seek to postpone as long as possible, even if it meant doing without the advantages offered by intelligent devices.

1 of 2 < 1 | 2 View on one page
Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


  • <p>It is good the article helps prepare the industry by bringing awareness to the upcoming FDI technology. Here are some updates on EDDL as it is different from the older DD technology.</p> <p>It is correct that the old “DD” technology prior to 2006 indeed did not have graphics. However, with the graphical enhancements introduced to the IEC 61804 standard in 2006, EDDL has graphical representation since 6 or 7 years ago. Lack of graphics is an old misconception. See some examples here: <a href="http://www.eddl.org/Pages/VisualDifference.aspx">http://www.eddl.org/Pages/VisualDifference.aspx</a> </p> <p>EDDL also works well with radar level gauges. The top right graphic on the above page hyperlink is a radar level gauge echo curve. It can also be seen in some other documents and videos. Not supporting advanced devices is another old misconception. </p> <p>Independence from operating system version is a unique characteristic of EDDL files. That is, even as Windows and .NET is upgraded, the EDDL files continue to work (just like HTML and XML files). There is no need to obtain new EDDL files for the devices. This makes it easier to keep pace with new Windows versions, service packs, and .NET framework and staving off obsolescence. Thanks to the EDDL portion of FDI, the FDI device package will inherit this important characteristic.</p> <p>Just to be clear; regardless of integration technology, any device is accessible from any host; but not using any field communications protocol, it must be the specific protocol used by that device. That is, a HART device is only accessible using HART, a Fieldbus device is only accessible using Fieldbus, and a Profibus device is only accessible using Profibus. Regardless of integration technology, a host can support all three protocols and access devices using their respective protocol.</p> <p>An intelligent device management software using EDDL can also interface with multiple devices. Advanced diagnostics can be displayed using EDDL, see tutorial here: <a href="http://www.eddl.org/DeviceManagement/Pages/DeviceDiagnostics.aspx">http://www.eddl.org/DeviceManagement/Pages/DeviceDiagnostics.aspx</a> Not supporting advanced diagnostics is an old misconception.</p> <p>EDDL will remain an integral part of the FDI device package so FDI will inherit many of the unique characteristics of EDDL.</p> <p>The power of EDDL comes from the applications around it, just like the power of HTML comes from the brower. EDDL can be used in a handheld field communicator, on a laptop, in intelligent device management (IDM) software part of the asset management system, or even on the DCS itself. The applications can audit trail, print, export to Excel, and make data available as OPC tags etc. Not just for some devices, but for all. Files can be loaded on one machine, and propagate automatically to all machines in the system.</p>


RSS feed for comments on this page | RSS feed for all comments