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.”
Plug-Ins and Snap-Ons
Interestingly enough, almost all of the above mentioned plug-ins and snap-ons rely on COM/DCOM just like FDT/DTM does, but are only useable with the host/asset management system for which they’re written. Consequently, they have less functionality than the open standard-based FDT/DTM systems. As of October 2005, the DTMs are subject to certification by the FDT Joint Interest Group (JIG). A list of certified DTMs can be viewed on the FDT-JIG web site. All certified FDTs have an “approval check mark” (Figure 1), which is similar to the one used by the Fieldbus Foundation.
FIGURE 1: THE MARK OF THE BEAST?
Some DCS vendors froth at the mouth when they see this symbol, but end users welcome it as a symbol of open standards.
Another anonymous end user from an international petroleum company that is relying heavily on Foundation Fieldbus for all its control system growth adds, “I don’t think FDT/DTM is a good solution for device configuration. This is where I think EDDL is best. I also think FDT/DTM technology can be of use in advanced diagnostics. I think there are some challenges to work through in this regard, but the potential is there.”
Challenges for FDT/DTM
FDT is an executable program that is provided by the device vendor, and is downloaded off the Internet to be loaded or installed on your computer system. Because DTMs are multi-megabyte files, it’s not possible to load them into field devices. Also, because these files are executables downloaded from the Internet, some users will have concerns about their integrity, and consider them to be possible security risks.
There has also been discussion of FDT on the Fieldbus Forum, where the concern is that using ActiveX could pose additional security risks to a system, or at least give someone an opportunity to use the technology to launch a cyber-attack on associated systems. This is because FDT/DTM requires the necessary ports and open access to work.
Of course, if an outsider can access the network on which this information is being transmitted, the system likely has bigger problems than ActiveX to worry about, and needs a complete security audit. This system should not be open to the business LAN or public internet environment in the first place.
The FDT engine runs on top of OPC DA, and uses DCOM to get data from controllers. OPC DA is not optimized for this high level of traffic and communications. However, as OPC Universal Architecture (UA) becomes available and this technology becomes adopted, reliance on DCOM will be removed. Interestingly, EDDL is also working with the OPC Foundaton to move to a UA environment.
However, running diagnostics in the host environment is limited by bandwidth of the communication channel to field devices. This limitation will restrict the diagnostic performance possible in the host versus running the diagnostic in the field device.
Because the host system reads the EDDL file directly, device configuration and control related interfacing will be much better integrated with the system when done with EDDL. At a recent meeting in Cambridge, Mass., Scott Bump of Invensys, and a member of the FDT Group, stated, “EDDL is for control and FDT/DTM is for applications,” confirming FDT Group’s position that these two technologies are complementary. As indicated above by the end users, there is hope that the organizations supporting these two technologies realize it as well, and will work together for better integration and application of the right tool for the right task.
Positives for FDT/DTM?
FDT reportedly will provide bigger benefits to the “slower” digital communications technologies, such as HART, by giving them a degree of advanced diagnostics capabilities, especially for off-line tools such as those associated with valves. HART Communications Foundation is more accepting of FDT’s capabilities because the devices are restricted to 9.6 kbaud, use ASIC processors for which functionality can not be added without a new chip set, and, after using the majority of their power budget to transmit the signal, have little left to perform the types of diagnostics being expected of digital devices.
A lead engineer at Shell Global Solutions suggested that a big positive of FDT is, “They managed to get the HART and Fieldbus Foundations moving on DD improvements—albeit rather late in the game.” These enhanced EDDL improvements were demonstrated at the recent ISA Expo 2005 show by the Fieldbus Foundation, while more work is in development.
|
"My hope is that vendors will use the right tool for the job rather than trying to win a political battle over market segmentation.”
|
Gareth Johnston, fieldbus communications specialist at ABB Ltd., states, “The value of FDT is that FDT provides full access to intelligent device features such as set-up (especially for multi-variable devices) and diagnostic information (signature analysis—clear language maintenance description). The DTM can use these to execute automatic commands to simplify device set-up. It also provides a flexible communication path that allows users to select the communication device (remote I/O with HART Passthrough, USB HART/ProfiBus modem, etc.) regardless of the vendor.”
For devices that don’t have a DTM yet, there also are FDT applications on the market that interpret EDDL applications on the fly. This makes it possible for end users buying equipment without FDT support to generate a basic FDT for use in their asset management or host system.
Because FDT/DTM is an open standard, it enables non-DCS device vendors with a level playing field for all device manufacturers. This helps them compete more strongly, using their enhanced diagnostics capabilities, and providing full access to these capabilities in any environment. Unless the snap-ons and related “add-in” pieces of software used to communicate with the asset management system are made available as an open standard, as was done with DD technology and is being proffered by FDT Group, the owner of the software for which the add-in is developed will remain in control of the way data is presented and made available.
The recently released FDT Style Guide will provide a more consistent “look and feel” for future DTMs, while also satisfying the recommendations of the NAMUR working group on the features/requirements of an effective asset management system. As a result, it’s likely that most DTMs will provide a similar “look-and-feel” device interface that is very similar to the vendors’ existing maintenance and configuration software tools.
What’s in the Future?
Most control system and device vendors are looking at FDT/DTM to see if or how it fits into their future. It looks like it may be an even better fit after OPC UA is available, though most of the vendors will likely continue to use EDDL for configuration.
Yet another anonymous major oil company engineer is concerned that, “Users will have to maintain a steady push to assure that diagnostics data and alarms are integrated with DCS operator subsystems for effective graphical user interface and alarm management. Vendors have a distressing tendency to segregate these applications into separate systems that don’t share information with operators.”
In addition, after the Swiss National Standardization recently made a new work proposal to the International Electrotechnical Commission (IEC), FDT was unanimously approved as a “publicly available specification” under the auspices of new standard working group IEC SC65C WG14 “FDT.” Following an initial meeting in January 2006, the hope of the committee is that the standard will be completed by October 2007.
Similarly, Profibus Nutzerorganisation e.V. (PNO) and FDT Group have agreed to develop a PLC programming tool, Tool Calling Interface (TCI), as an open tool to integrate the factory automation and process automation environments with one interface. The TCI specification will contain a bidirectional communication channel from the tool to the field device via the PLC programming system. Hopefully, this tool will also be compatible with the IEC 61508 on which all PLC programming software and documentation is based.
Also, FDT-JIG has indicated that FDT is a complementary rather than competitive technology to EDDL. They also acknowledge that FDT has some limitations including:
- FDT is a Microsoft Windows-based technology. As such, it is subject to the inevitable upgrades and operating system version changes with which we have all become familiar. As with all software tools on all operating systems, FDT platforms and device applications will need to be updated occasionally.
- FDT only defines interfaces between system components. As such, FDT components cannot replace DD files, which continue to be an integral part of major fieldbus systems.
There is hope that the FDT/DTM versus EDDL battle soon may be declared a ceasefire, since a member of the Fieldbus Foundation’s board of directors says, “Most of the members of foundation are also members of FDT Group, so the Fieldbus Foundation board needs to make a clear statement on the EDDL/FDT relationship.” Hopefully this can happen at the FF’s general assembly at the end of February 2005.
Using FDT
Achim Laubenstein, ABB’s manager of fieldbus development, says, “FDT is the opportunity for device vendors to provide the application software that best fits their device. One and the same DTM can be used in many hosts without extra effort. This saves costs for the host and on the device side. One can imagine that device vendors especially have a high level of interest in such interface technology.
“When implementing FDT, rather than starting from scratch, we recommend using existing components available on the market. A user should check whether the products he wants to use are certified by FDT Group.”
End-users just want a simple, intuitive way to access, interpret, and understand what’s happening in their process and to their devices. Fortunately, it sounds like the manufacturers also are getting the same message, even though it looks like some are fighting a rear-guard action to protect proprietary technologies from the open systems movement. Hopefully, OPC UA will be the common technology that will enable them to come together in a smooth, unified way.
What Is FDT/DTM Anyway?
FDT/DTM technology is made up of two basic components:
- The Frame Application: this is the Device Management Environment.
- The Device Type Manager (DTM): this is a software component that simply operates as a “driver.”
DTMs can be further classified into two categories:
- CommDTMs are software components/applications that enable the Device Management Environment, called a Frame Application, to access different fieldbuses. This approach makes the Device Management Environment open to all fieldbuses. Just add the required CommDTM. CommDTMs for HART, Profibus, Foundation Fieldbus’ transducer blocks and Interbus S already exist, and are being developed for AS-interface, DeviceNet, Profinet and Modbus.
- Device DTMs again are software components/applications, but these DTMs enable users to configure the associated device within the Device Management Environment. These DTMs are the individual “device drivers” that allow users to configure, diagnose, and manage the field device. The DTM is often compared to the drivers loaded into computer operating systems to support external devices such as printers. These don’t just to allow the printer to operate, but also help diagnose and troubleshoot faults (ink cartridge low, align print head, etc.). The DTM offers this same support for field devices connected to a control system (control valve stuck, signature change, etc.).
The chart below shows how EDDL and FDT/DTMs combine to communicate between the field device and the “host-based” software, be it a configuration tool or asset management system.
THE MATING DANCE OF EDDL AND FDT/DTMEnd-Users Wanted
TAKING a page from the success of end user councils, originally established by the Fieldbus Foundation, and now adopted by other groups including OPC, FDT Group held its first End User Group Forum in October 2005 in Amsterdam. The event was attended by more than 40 participants, including representatives from 14 end user and engineering companies. Those attending the event learned more about FDT technology, and also provided input on requirements to make it better in the future. Based on the success of this initial meeting, similar events will be held in 2006.
| About the Author |
