Tools

• 1
• 2
• 3
• 4
• 5

Current Rating: 1.0
(1 vote)

Click on a star to rate this article.

Print page

Email page

Is FDT good for fieldbus and device networks?

ControlGlobal.com

Keywords: Ian Verhappen, Fieldbus Foundation User Group, Fieldbus Wars, fieldbus, FDT/DTM, EDDL, field device tool and device type manager

CONTROL’s Ian Verhappen, Chair of the Fieldbus Foundation User Group, looks at the latest battleground in the Fieldbus Wars. Is this Fieldbus Wars II or can FDT/DTM and EDDL work together?

FIELD DEVICE Tool/Device Type Manager (FDT/DTM) is a multi-network-compatible, device-vendor-defined set of software tools that allow end users to view and interact with a device using the vendor’s own software. Since the technology was introduced at Interkama in 2001, improvements have been made to it. Of course, the underlying electronic device description language (EDDL) technology on which it relies has been improved as well.

These two technologies also have been at the heart of a controversy involving instrument suppliers and users. The main question is: do these two technologies conflict, or can they work together to complement each other? It appears most vendors and users have finally agreed that they do indeed complement each other.

To understand how these two technologies are interrelated, let’s start with a short lesson on how each of them works.

EDDL was created at the dawn of fieldbus for the purpose its name implies—it is used to describe devices. Systems that interact with fieldbus devices need to know the rules of the conversation before communication can start. What function blocks are present in a device type? What parameters are available? What are the data types of those parameters? What are the default values and permitted ranges of those parameters? This information is used by the system to understand a device even before the device is present in the system. As a result, fieldbus technologies, from the communications specifications through the various device descriptions, look at communications from the device’s perspective.

FDT is device, protocol and system independent, and therefore is capable of managing all digital communications protocols. FDT is the interface specification, while DTM is a driver that presents an interface to the physical communication channel between the system or tool and the actual fieldbus devices. The second component, the DTM frame application, is an interface to the platform.

End-User Perspective
When asked about the uses of FDT/DTM, many end users reply, “Ultimately, what it boils down to is what can be realized in the end-user world.” One end-user, who asked not to be identified because he felt that it might compromise his company’s relationship with its vendor, adds bluntly, “My hope is that vendors will use the right tool for the job rather than trying to win a political battle over market segmentation.”

An engineer at Shell Global Solutions responded that they would like to design a test that demonstrates EDDL’s value by itself, and compares it to a combined EDDL and FDT/DTM implementation. His thought is to take one or two typical positioners with their valve diagnostic features and one or two systems, and demonstrate how the diagnostics and advanced diagnostics information from the devices can be integrated into the DCS and asset management systems, either via EDDL or via the combined EDDL-FDT/DTM route. “This will give the end-user community the insight as to what approach provides best value for its money,” he says.

In fact, some people believe that this is the heart of the controversy. Jim Sprague, a controls engineer working for a major oil and gas producer in the Middle East, concurs with this idea. “We want to be able to use best-in-class Foundation Fieldbus instruments, regardless of vendor, with the host DCS of our choice,” says Sprague. “We also want to be able to access all maintenance, configuration and diagnostic software and displays—for ‘complex’ instruments—on our DCS system maintenance stations.

“We expect this software and its displays will operate and look/feel as the OEM instrument vendor intended. This software needs to be well integrated with the DCS, so it communicates configuration changes to the host system database, as well as manages online and out of service (OSS) mode changes appropriately.”

End-User as Agnostic
Sprague adds, “We don’t care if this software works via EDDL or FDT/DTM. We expect our host-system vendors will provide this interface, and will help us keep it current. We don’t expect a problem with either technology, and we don’t see that they will compete. We expect our selected host-DCS vendor will support both these technologies, and help us apply whichever works appropriately for specific applications.

“At present, the only place we use this kind of complex field device interface is on our control valve positioners. We use ‘plug-ins’ and ‘snap-ons’ from the positioner vendor that allow access to their maintenance and configuration software from our selected host DCS system.”

“Aye, There’s the Rub!”
“These applications are limited by which vendors have developed these plug-ins and snap-ons for which host-DCS systems, and the choices are few,” says Sprague bluntly. “We look forward to the day when all complex instruments have their software integrated by either EDDL or FDT/DTM.  Complex instruments we’re looking to integrate in this way including valve positioners, contact/non-contact radar level instruments, simple and complex analyzers, MOV valves, multi-variable transmitters and others.”