Standards for Device Integration: FDT/DTM

01 June 2007

Following the article in our last issue (April, 2007) on EDDL technology, we present the device integration technology FDT/DTM.

Both EDDL and FDT/DTM technologies, though often marketed as being emutually exclusive, 'are driving at supporting the end user of field devices in configuring, engineering and maintaining his assets in a plant.
Furthermore both technologies claim to be open, to support different vendors and protocols, and to help the plant operator in protecting his investment.

Astonishingly, most of these statements can be considered as correct for both technologies, so the most
interesting issues to be discussed are the different technical principles behind them and the need for guidance so that device vendors and plant operators can understand the issues.

In the last issue of this magazine we concentrated on EDDL. In this issue we will focus on FDT/DTM.

Where FDT/DTM came from
In 1998 an initiative within the ZVEI (the German association for electro technical and electronic industry) started with the discussion on how to simplify the integration of field devices into distributed control systems (DCS) with the availability of modern software component technologies. As the first fieldbus organisation the PROFIBUS User Group adopted the specification results and later transferred the rights to the FDT Joint Interest Group, which was established shortly after.

Due to the vast usage and support of the FDT/DTM technology throughout the industry, the FDT Group AISBL was founded and is now driving and maintaining the specification and certification of the FDT standard(s). Since 2001, when version FDT 1.2 became publicly available, there has been one major enhancement, the downward compatible FDT 1.2.1, and several fieldbus protocol specific adoptions that opened the FDT technology to fieldbus device manufacturers beyond HART and PROFIBUS. Fieldbus Foundation, Interbus,
DeviceNet, and AS-interface are among them and more are to follow.

The technical principle
FDT/DTM technology separates an automation architecture into three categories:

....Software applications like Asset Management Tools and DCS systems; often referred to as 'FDT frame

....Device Drivers representing field devices, referred to as 'Device DTMs' (DTM=Device Type Manager); and

....Communication Drivers that represent the communication hardware needed for connecting the field devices to the automation software, referred to as 'Communication or Gateway DTMs.'

A Device DTM is comparable with a printer driver that can be installed on a Windows-PC and is then available for all Windows applications. By analogy a communication DTM is comparable to a network adapter driver (e.g. for an Ethernet PCI card) that allows the printer driver to actually send its data to the
physical printer. So accordingly, the main part of the FDT specification is defining the software interfaces between instances of these components as well as the responsibilities of each component type.

Components of an FDT automation solution
The figure on page 32 shows the components in an automation solution. The FDT frame application, a device DTM and a communication DTM are installed and plugged together on a notebook computer and the operator is now able to work with the field device.

The tasks of the frame application are mainly the management of the device instances and the storing of the
engineered data in a project database. Furthermore the FDT frame implements the administration services, e.g. user rights management, device catalogue management, and scanning for connected hardware. Additionally FDT specifies how a frame application has to deal in a multi-user environment, especially with respect to locking/unlocking devices for simultaneous access by multiple users. Beyond that, engineering applications like calibration tools or historical data loggers can access device data through the FDT interfaces.

A device DTM is a binary software component (deployed as *.exe or *.dll) that can be instantiated, controlled, and closed by the frame application. All functionality that the manufacturer has intended to provide to the end user of the device is programmed inside the DTM.

This is especially true for the graphical user interfaces of a DTM. They are provided in ActiveX-Controls that will be started upon request within the frame’s user interface area. They usually provide the device parameters and functions in a fully Windows-like manner for a comfortable device operation.

Most important, the FDT specification does not specify the inner functionality of a DTM itself but it specifies the means for accessing it via the FDT interfaces, which can be seen as a logical grouping of related methods. The table below shows the interfaces of a DTM.

The main interface, IDtm contains the central functions for controlling the DTM’s state machine. For example, the function InitNew() is used to initialise the DTM after it was instantiated.

One basic design principle behind modern component-based architectures and especially in FDT is to provide functionality through interfaces AND keep the interfaces stable. Therefore data that are transferred via an FDT interface are wrapped by an XML document in most cases. The XML document is always to be validated against the XML schema, which is defined in the FDT specification. This technique has allowed FDT to be compatible since the release of the specification 1.2.

For more detailed technical information about all FDT interfaces and methods please refer to Simon, Kleegrewe, Birkhofer, Jeske, Merget: ‘FDT FieldDevice Tool’, English Edition, Oldenbourg Industrieverlag 2005, and FDT Group: ‘FDT Technical Description’, 2006; available through the web site The specification itself is FDT Group: ‘FDT Specification 1.2.1’, 2005, available at

Current state and use
The support and the acceptance of the FDT/DTM way of device integration is already vast and still growing at a fast rate. At the moment, there are 55 members in the FDT Group AISBL, mostly device manufacturers who actively drive the technology and issue products based on the FDT specifications.

There are already some distributed control systems that have implemented the FDT interface and gain profit from protocolindependent network topology possibilities. Also there are several asset management software packages available (e.g. FieldCare from Endress+Hauser and Pactware as an open source software) that enable the user to quickly set up commissioning projects and install maintenance
workstations. For nearly all communication hardware in the automation world, communication and gateway DTMs already exist or are under development. This allows the end user to combine the available hardware according to his wishes.

Most importantly, nearly all device manufacturers already offer device DTMs (or complete libraries of them) for their equipment. For the missing pieces there exist several solutions like profile DTMs for PROFIBUS profile devices, generic DTMs for HART devices (supporting universal commands), and DTMs that are
compiled from device descriptions.

A very important role for FDT/DTM technology is applications in factory automation. The boundaries between
process and factory automation do not exist for FDT, thus making it easier for hybrid plants and applications to set up a seamless asset management solution.

Pros and cons
From an end user’s point of view two integration technologies are not the best solution, because it enlarges the training effort of its personnel as well as the administrative effort regarding updates, version management, archiving and validation (in certain industries).

On the other hand, neither of the technologies will simply disappear in the near or middle term future because there are a lot of investments made by device, DD-host and FDT-frame manufacturers.

From the technical side, both solutions have their pros and cons. FDT/DTM has certain advantages when specific device capabilities need highly sophisticated user interactions (e.g. fieldbus diagnostic devices) or persistency mechanisms (e.g. compressed echo curve recordings for a radar device) that cannot be described within the bounds of the current EDDL standard.

If there is no need for such programming, the decision of describing the device in EDDL might be the simpler way. On the other hand, if the challenge is to set up a heterogeneous network, consisting of a deeply structured communication topology, then using FDT/DTM might be the best choice.

The advantages and disadvantages of both technologies have already been discussed in depth in this magazine and in other publications. It has become clear to most users that they will have to deal with both integration means in the future, like they already have to deal with several fieldbus protocols. A suggestion towards a way to handle this situation is to choose DCS systems that support both integration technologies at the same time (see, for example, Suselbeek, H. ‘Presentation on WIB workshop Utrecht: EDDL or FDT/DTM – Characteristics of EDDL and FDT/DTM’, 2006;

Another solution to the problem is the recent proposal to merge the technologies into one; see the article
‘FDI - The Future of Open Device Integration’ starting on the next page.

Most device manufacturers already support both technologies and have introduced the development and test activities into their processes. One main challenge here is to secure the consistency of the EDD and the DTM for one device.

Fortunately, there exists a solution in form of the conversion software DTMstudio, from CodeWrights. It takes
an EDD file for a HART, Profibus or FF device as an input and is able to generate a matching device DTM using the information of the EDD. This approach also leverages the best of both technologies—describe the device model in EDDL and integrate it into software systems using FDT interfaces.

Dr. Rolf Birkhofer, CodeWrights GmbH,

Contact Details and Archive...

Related Articles...

Additional Information...

Print this page | E-mail this page