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
Page 2 of 2 1 | 2 Next » View on one page

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

Page 2 of 2 1 | 2 Next » View on one page
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