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

Share Print Related RSS

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.

However, as time went on, the case for using intelligent device technology became more compelling. And, as the technologies became more sophisticated, it became clear that most users were not looking at EDDL versus FDT as an either/or decision, but as a both/and issue. Sometimes one or the other  was the best choice. Sometimes a user might need both.

That, of course, left suppliers with a problem. To meet the needs of their customers, they had to support multiple fieldbus protocols and multiple communication technologies, lengthening product development time and expense. Because EDDL and FDT had many overlaps, they also had to duplicate a lot of effort.

Martin Zielinski, board of managers member of FDI Cooperation LLC, representing Emerson Process Management, expands on the vendors' dilemma. "FDT Group does not have communications protocol, but it is an integration technology used by protocols, for example, HART. HART provides a specification to deliver information to the system. In addition, it provides tools and software that helps systems use that information. Foundation fieldbus and Profibus do the same. FDT only takes up the host system. It doesn't care how the information is delivered. Once it's there, what you do with it is what FDT is concerned with."

He adds, "Back in mid-1990s, HART, Foundation fieldbus and Profibus all had EDDL technology. Each found different ways to enhance it. If you were a host supplier in 2000, you had to implement the same thing in three different ways. In this convergence, there was an agreement to harmonize EDDL and incorporate part of FDT as well."

Meanwhile, all users really wanted was simplicity. While plug-and-play might be too much to hope for, they really didn't want to have to sort through yet another complex technology, and they didn't want their vendor choices limited by which technology a vendor used or by the one they themselves chose.

Zielinski says, "NAMUR would complain because they [end users] had to make choices about these integration tools. They didn't like that. No single manufacturer provides all the necessary equipment a user might need. Interoperability is important to end users."

These twin sets of pressures led to a growing consensus that some kind of rationalization between the two technologies needed to take place. NAMUR, a European process industry user group, also strongly encouraged this movement. In 2004, it published "Recommendation NE 105—Specifications for Integrating Fieldbus Devices in Engineering Tools for Field Devices," which essentially made the technical case for FDI.

Enter FDI

By 2007, the push for rationalization had built up enough of a head of steam that, at that year's Interkama/Hannover trade fair, the FDT Group and the EDDL Cooperation Team (www.eddl.org) announced the Field Device Integration (FDI) effort. Its goal was to rationalize EDDL and FDT/DTM technologies to make a uniform device integration solution for the process industries that would work for all systems and devices and all the major process fieldbus protocols.

However, even with the best of intentions in the world, the effort began to languish. Not much happened until 2011, when FDI Cooperation was formed. [Editor's note: That's not a misspelling. It is FDI Cooperation, which is as good a way as any to denote the purpose of the group.]

FDI Cooperation is run by a board of managers that consists of representatives from all the interested parties:  FDT Group, HART Communications Foundation, OPC Foundation, Fieldbus Foundation, Profibus and Profinet, plus a lineup of the process automation suppliers, such as ABB, Emerson Process Management, Endress+Hauser, Honeywell Process Solutions, Invensys, Siemens and Yokogawa.

O'Brien adds, "Most people use both [FDT/DTM and EDDL]. FDI is just a way of rationalizing this, so you only have to use one device package. There will be common development tools that will make it easier to build devices and easier for end users. Not much happened with this until NAMUR got hold of it. They came up with recommendations about how to rationalize the two. Then the five sponsoring organizations got together and said, 'Okay. Let's do this.' They signed a memorandum and formed the LLC. Now we have a roadmap and a specific set of milestones to make it happen."

What FDI Will Do

When the specification is completed, it will integrate the complementary strengths and EDDL and FDT/DTM technologies with the advantages of the OPC UA standard IEC 62541. The completed solution will be platform-, operating system- and host system-independent; compatible with existing EDDL and FDT/DTM technologies; protocol-independent; an open specification and an international standard; compatible with OPC UA technology; and provide access to the full capabilities of field devices, from the simple to the most complex.

FDI also promises transparency that will enable users to buy their preferred hardware without worrying about compatibility with their control host, no matter which field device communication they're using.

FDI will also provide a common validation effort and interoperability with FDI/FDT 2.0 and a set of common tools for device developers, including an integrated development environment, host interpreters, package and host conformance tools, EDDL profile harmonization and extensions, and a common EDDL file format.

It will also be the responsibility of the five founding organization to keep the protocols harmonized, says Emerson's Zielinski. The work will mostly fall on the Foundation fieldbus, HART and Profibus groups, who will share their results with the FDT Group and the OPC Foundation.

What FDI will not do is handle certification, Zielinksi adds. "All FDI does is explain what our device is to the host system," he explains. "The devices will still be different and independent of one another. All we've done is harmonize the way the device is described and used within the system. We're not changing the protocols, just the way the device is described to the host system, so it can have a uniform way to use stuff."

Progress So Far

Unlike many efforts involving a complex mix of competitive and complimentary organizations and interests, FDI Cooperation has made some fairly remarkable progress since its inception in 2011. "We're very close to being done with the whole thing," says the Fieldbus Foundation's O'Brien.

The group is planning to demonstrate the specification and release a beta version at this November's NAMUR meeting. The current plan is that a final release of the specification will come during 2014.
Whether or not FDI Cooperation meets that deadline, or getting to a final release takes a bit longer, the plan is that once it is complete, FDI Cooperation will disband, leaving maintenance of the harmonized specification to the individual protocol and solution organizations.

Zielinski explains, "When FDI Cooperation LLC dissolves, it is the contractual obligation of the Fieldbus Foundation, the HART Communications Foundation and the Profibus/Profinet organization to collectively maintain the FDI technology, and prevent it from diverging as their communication protocols evolve. The other two foundations, OPC and FDT Group, do not have a communication protocol. They will have a right to use the FDI technology and can provide input to the other three foundations."

Share Print Reprints Permissions

What are your comments?

Join the discussion today. Login Here.

Comments

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

    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: http://www.eddl.org/Pages/VisualDifference.aspx

    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.

    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.

    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.

    An intelligent device management software using EDDL can also interface with multiple devices. Advanced diagnostics can be displayed using EDDL, see tutorial here: http://www.eddl.org/DeviceManagement/Pages/DeviceDiagnostics.aspx Not supporting advanced diagnostics is an old misconception.

    EDDL will remain an integral part of the FDI device package so FDI will inherit many of the unique characteristics of EDDL.

    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.

    Reply

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