Tutorial: Instrumentation / DCS integration languages, part 2: FDT
Tools to help integrate instrumentation into your DCS are available. They help with configuration, communication, calibration, and HMIs.
One of the tools that can help you get more from your instrumentation and other process control devices are integration languages, such as FDT and EDDL . While the two have many similar characteristics and capabilities, there are subtle differences. This month we consider FDT. ( Read last month’s article .) ( Read an earlier article on the competing technologies .)
Between the two platforms, FDT is the more elaborate and complex. While EDDL (electronic device description language) is essentially a text file, FDT (field device tool) is more of a software program, similar to a printer driver. If you buy a printer to use with your computer, the printer manufacturer writes a driver program to interface with the computer. That program supports communication between the two devices, so text can be sent to the printer along with configuration, diagnostic, and other functional information specific to that model printer.
FDT provides a means for an instrumentation manufacturer to write a driver for a pressure sensor, control valve, or other device so the larger control platform can communicate with it at multiple levels. The system designer therefore does not have to create such utilities for devices from various manufacturers. FDT provides the DCS builder with this framework application, in which the device developer writes the individual driver or DTM (device type manager). So the DTMs for individual devices operate within the FDT framework embedded in the DCS.
The DTM (like a device descriptor) contains information specific to that device, such as type, parameters, calibration, diagnostics, HMI graphics, and so forth. This is supplied by the device manufacturer.
Configuring HMI graphics is one point of departure between the two competing platforms. EDDL provides information about the device to the DCS vendor, but the vendor creates the actual graphic representation. This ensures consistency on HMIs even if multiple field device manufacturers are involved. On the other hand, the DTM creates the actual graphic for a device and provides it to the DCS vendor. FDT’s organization has published guidelines for graphic representations of devices to promote HMI consistency, but the designer has to use them.
While the FDT frame is almost a full asset management platform in itself, it typically works in conjunction with asset management functions on a larger host system. Even so, it provides much in the way of navigation, device management, and database utilities. It is able to communicate using all common analog, fieldbus, and Ethernet based protocols, and serves as the bridge between the individual devices and the higher level platforms.
Each device has a corresponding DTM which carries information about that model:
Setup and configuration parameters;
Calibration routines and instructions;
HMI graphics, including the device representation and data display; and
The FDT platform has to operate within a larger DCS and asset management environment that is capable of supporting it. This means a system must be new enough or must have been upgraded, and was made by a vendor that supports the technology. Just as when HART was first released, existing systems could not take advantage of the protocol due to hardware and software inadequacies. Similarly, older systems need to be upgraded to use FDT. It is difficult to provide specific implementation dates since different manufacturers adopted the technology at different times.
Moreover, not all manufacturers have embraced the technology. Some individual device suppliers choose not to write DTMs, and some control system builders do not support FDT. A growing number of system designers support both FDT and EDDL, but this may only help you if you are considering a new platform. There are translators that can access an EDDL and read the device data into a DTM environment, although this is not as complete as an original DTM. If your system is not able to support FDT, a handheld communicator can talk to individual devices through HART wiring to use the DTM.
EDDL is not supported by every supplier either, so ultimately the decision to use one technology platform or the other could depend largely on what host systems you have and what your installed base of instrumentation includes. Neither system is universal, but in many respects the gulf between the two is narrowing. More vendors are supporting both for host systems and devices. There is even a working group that is trying to synthesize the two systems into a common platform. While that may still be years away, it is at least in the works.
—Peter Welander, process industries editor, PWelander@cfemedia.com ,
Control Engineering Process Instrumentation & Sensors Monthly
Register here and scroll down to select your choice of free eNewsletters .
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.