01 May 2004
Demystifying a protocol - Part 1
A device manufacturer develops a software driver called device type manager for each of its devices.
By Nick Zucchero
Field device technology/device type manager (FDT/DTM) technology has been around for more than two years, and it still confuses many.
Is FDT/DTM another fieldbus communications protocol? Do DTMs replace device description (DD)?
FDT/DTM technology is not another fieldbus communications protocol nor do DTMs replace DD. I continue to hear people claim that another fieldbus war is coming due to FDT/DTM technology. There is no need to fire the automation industry artillery in another fieldbus war, because FDT/DTM is a complementary technology to the fieldbus communications protocols (HART, Profibus, Foundation fieldbus).
The premise behind the FDT/DTM technology is in fact extremely straightforward. In an industry consisting of multifieldbus configurations deployed in process automation and factory automation installations, a technology is required that consolidates the different configuration tools and device management tools into a single engineering and maintenance environment.
These requirements are familiar.
End users demand one engineering environment to manage, commission, and configure any field device, from any device manufacturer, connected to any fieldbus communications protocol backbone. End users want the flexibility to select any supplier's product and not to be restricted or tied to one vendor.
End users require open technologies that preserve the current investment in installed field devices and that do not require the bulldozing of existing assets to take advantage of the open technologies. In addition, end users need seamless data exchange with asset management applications, regardless of device type, vendor, or communications protocol. Easy management, commissioning, and configuration of complex field devices such as radar level transmitters and smart valve positioners are no longer optional to qualify to bid on end-user jobs.
Field device manufacturers need technologies that embrace and extend their DD engineering, without replacing it. This includes the reuse of device description structured text to produce DTM logic.
FDT/DTM technology enables device manufacturers to lower ongoing product maintenance costs by eliminating the necessity to develop costly system- and bus-specific interfaces to integrate their devices into a control system.
Field device manufacturers can easily integrate their field devices into any control system without having to change their device engineering to ensure system compatibility.
Control system manufacturers require a technology platform that supports one configuration and device management engineering tool set and that eliminates the need to develop multiple configuration applications for different devices and different fieldbus communication protocols.
Field device tool set
The FDT 1.2 specification describes an open interface for integrating any field device, from any device manufacturer, connected to any fieldbus communications protocol in a control system.
FDT/DTM technology is device manufacturer independent and fieldbus communication protocol independent. It defines a single engineering environment for field device configuration, field device commissioning, and the ongoing management of field devices.
The specification describes an open, plug-and-play technology. There are three key and simple parts to the FDT/DTM architecture, a frame application (DTM container), a device DTM, and a communications DTM.
FDT/DTM uses extensible markup language (XML) for data exchange between frame application and devices. Using XML enables the technology to provide an open interface that hides the fieldbus communications protocol details. Because the technology deploys an open, plug-and-play model, it is extensible, allowing for the addition of other fieldbuses.
FDT/DTM supports HART, Profibus, Foundation fieldbus, and other vendor-specific bus configurations. It can easily support fieldbus technologies such as DeviceNet.
Frame application invokes
The frame application uses a set of standard interfaces between it and the field device. Frame applications are device configuration tools, control system–engineering tools, operator consoles, or asset management tools. The frame application initiates the connection between the device and the system engineering and operating environment.
The frame application invokes the communication component to interface the host system with the specific fieldbus communication protocol (HART, Profibus, or Foundation fieldbus).
The communications DTM ensures that the frame application does not need to change even when a new fieldbus communications protocol backbone enters and becomes part of the control system.
The open host interfaces make it unnecessary to create device-specific connection logic to add field devices. The communications DTM provides the fieldbus-specific interface to enable access to all the information available in intelligent field devices, even the most complex ones. It connects the frame application to the field devices during engineering, operation, monitoring, calibration, maintenance, and diagnostic analysis of the field device.
The device DTM is the component of FDT/DTM technology that defines and specifies the details of the field device. The interface to the frame application is standard, and the interface between the device DTM and the communications DTM is standard.
The device supplier develops a software driver called device type manager for each of its devices or group of devices. The DTM encapsulates all the device-specific data, functions, and business rules such as the device structure, its communication capabilities, internal dependencies, and the human-machine interface structure.
They provide functions for accessing device parameters, configuring and operating the devices, and diagnosing field device problems. DTMs can range from a simple graphical user interface for setting device parameters to a highly sophisticated application capable of performing complex calculations for diagnosis and maintenance purposes.
An automation industry expert pictured device DTMs, "All of the information that the device manufacturer wishes to make available is programmed into the DTM. This includes all real-time data, alarms, events, configuration information, screen displays, multilingual help screens, device-specific documentation, parameter validity check, generation of dependent variables, diagnostic functions, and the device calibration sequence. A DTM can support more than one field device."
The FDT/DTM specification describes the architecture in which these three key FDT components interact with each other.
The frame application loads a device DTM into the DTM container, and the device DTM invokes the relevant communications DTM.
The device DTM visualization is also loaded and launched in the DTM container. This enables the instrument engineer or the instrument maintenance technician to connect to the field device and access and modify device data. P
Behind the byline
Nick Zucchero has a master's degree in computer science. He is director of systems technology at Invensys Foxboro and is Invensys' representative on the FDT Joint Interest Group Steering Committee.
Extending device description
The not-for-profit FDT joint interest group (JIG) is a collaboration of international automation companies that support the proliferation of FDT/DTM technology. The group is open to all companies and organizations that wish to participate.
The organization has started the international standards process for the FDT version 1.2 specifications. It is planning to submit the specification to the International Electrotechnical Commission and/or the International Organization for Standardization this year, 2004.
The group has also created test and certification procedures not unlike those of Fieldbus Foundation, Profibus International, and HART.
New device DTMs must be certified. The FDT JIG has invested in a test harness to inspect DTMs and is currently working on plans for a frame application inspection test harness.
A third party maintains the test harnesses, and the test and certification process is vendor independent.
The member companies support this technology, because it doesn't replace or cannibalize existing DDL technology investments. They see the technology as extending DDL engineering.
DD a device description (DD) provides an extended description of each object in the virtual field device (VFD). It includes information that a control system or host needs to understand the meaning of data in the VFD.
VFD a virtual field device (VFD) is used to remotely view local device data described in the object dictionary. A typical device will have at least two VFDs.
XML extensible markup language (XML) is a computer authoring language for publishing documents through the World Wide Web on the Internet. For use in automation, it is better and more flexible than hypertext markup language (HTML).
HART an open, smart field instrumentation protocol developed by Rosemount that a number of other companies adapted, resulting in a de facto standard fieldbus. It imposes a 1200-bit-per-second digital signal on a twisted pair of wires carrying a 4–20 mA input.
DDL device description language (DDL) is from the interoperable systems project and HART. Device description, in Foundation fieldbus technology context, is the definition and description of function blocks and their parameters.
Function block a logical processing unit of software that has one or more input and output parameters.
Return to Previous Page