FDT stands for Field Device Tool and is a technology for configuration and access of field devices. This technology is established as an open standard and therefore vendor independent. Device manufacturers add to their individual field devices a piece of software called Device Type Manager or DTM. FDT compliant software tools - so-called frame applications - can communicate via DTMs across fieldbuses with each device. Configuration of the device and access of the data is a child's play.

With the aid of the frame applications, the information of processes in the field is accessible in realtime and is available across the life cycle of a plant or application. Those tools support you efficiently during engineering, installation, commissioning, production and maintenance.

Currently the FDT Group consists of these members.

However, there are more companies that use FDT.

FDT standardizes the communication between field devices and tools used to engineer and automate plants or applications. This tools can be for example engineering tools, production management tools, maintenance tools, or asset optimization tools.

Here's how it works.

The device supplier develops a software driver called Device Type Manager (DTM) for each of its devices or group of devices. DTM’s can be - broadly speaking - compared with printer drivers that we use for our office PC.

A DTM for a device class that does not have direct access to communication is named DeviceDTM. The DeviceDTM encapsulates all the device-specific data, functions and business rules. DTMs can reach from a simple graphical user interface for setting device parameters up to a highly sophisticated application that, for example, can perform complex calculations for diagnostics and maintenance purposes or can implement arbitrarily complex business logics for device calibration.

One DeviceDTM must exist for every device. The device manufacturer provides the DeviceDTM. However, the driver contents is inaccessible to third parties and the manufacturer’s know-how is protected.

A DTM which has direct access to the communications backbone that connects the device to a particular fieldbus is called a Communications DTM (CommDTM). The CommDTM encapsulates all communication specific aspects.

The system (host) engineering environment has an FDT “Container”, that defines a set of interfaces between the hosting application (‘Frame Application’ in terms of FDT) and the ‘device drivers’ (DTM). Frame Applications can be device configuration tools, control system-engineering tools, operator consoles, or asset management tools. FDT initiates the DTM and generally interfaces the device to the system engineering and operation environment.

End users want to use a unique, standard interface that connects any automation system to any device, so that they have the freedom of choice to select the device fitting best the demands of their applications, regardless of supplier or communication protocol.

They want this “open” interface to access all the wealth of information available in modern field devices, even for the most complex ones. The specialized applications should support the devices through their life cycle and enable engineering, operation, monitoring, calibration, diagnostics, maintenance and audit trails.

The engineering and configuration information should be displayed on a standard graphic interface and the tool should be easy to learn and easy to use.

And finally, whatever the solution, it should evolve with the state of the art in communication and information technology, so that the automation investment is protected well into the future.

Automation suppliers are faced with the high development costs due to the very diverse environments in host systems and field devices, which require customized interfaces for every combination. They would much rather invest their resources where they belong, in specialized, differentiated features that bring benefits to the end users, rather than in integration problems.

FDT provides a standard interface for all compliant systems and devices. Additionally, it is the same for automation systems and for stand alone tools. DTM’s leverage the existing DD’s (Device Descriptions) and are unique for each device (i.e. they need to be built only once, regardless of the host system), thereby protecting the supplier’s investment.

Finally, the technology itself allows for migration to future platform developments such as evolution from COM to .Net.

FDT frame applications and DTMs are programs, which only need to be reinstalled in a new the new system environment, just as system software. (Office 97 still runs under Windows XP)

Both, Device DTMs and Communication DTMs are not comparable to the device drivers of the operating system. Thus, there is no dependence on the hardware installed in a computer.

Only the computer hardware responsible for communication with the field devices, e.g. PROFIBUS card, requires, under certain circumstances, new system drivers. New DTMs are not required. Communication DTMs use system drivers, but are not concerned itself, comparable to OPC communication drivers.

There will be still access to all data bases and device configurations. The storage of data and device configurations is done in FDT Frame Application.

Hardware, software and device technology build a single unit in a plant. If nothing is changed, nothing happens.

In further developments of an operating system, an existing technology is mostly not (weiter-) developed anymore, but is still supported by the operating system.

Up to now Microsoft has never dropped the history and has always provided an upward compatibility.

DOS-Software is still running up to now in the DOS-Box, if it is engineered “clean” on BIOS (Basic Input/output System) interfaces.

DOS-Software which works with BIOS interrupt-calls are able to access file formats, which even have not been known at time of development. Norton Commander is able to access NTFS file format.

WORD 3.0 documents can still be opened in Windows XP.

Microsoft has mostly pursued a migration strategy.

A migration strategy has been provided for e.g. document formats (Word) or file formats (FAT32/NTFS). Conversion programs are available for the transformation.

Microsoft has always created upward compatibility for internal interface technologies (e.g. DDE, OLE, COM).

DTM certification is a prerequisite for all compatibility requirements regarding FDT technology. The certificate gives user the assurance that the DTM conforms strictly to the FDT standard.

A certificate is issued only when the DTM has successfully passed the tests made with the dtmINSPECTOR. This is a software tool for all types of DTM. It logs both the behaviour of the DTM and any deviations in functionality. The FDT Group issues a certificate only when the DTM has passed the test without error.

A similar certification process has been put in place for frame applications. The frame application may be an independent Windows program, or be integrated into a control or asset management system. It must be installed in this way in the operating system and is subject to the Windows criteria.

The Project Group “Style Guide” within the FDT Group is working on a standard for a uniform user interface and operating philosophy.

The requirements have been formulated by end users (e.g. NAMUR AK 2.6 Fieldbus). These form the basis of the FDT Style Guide. The Style Guide includes a multilingual glossar. The Style Guide becomes part of DTM certification

The device supplier develops the Device Type Manager (DTM) for each of its devices or group of devices and supplies it with the instrument.

Existing DDs can be used to build DTMs.

The effort required to develop a DTM will depend on the complexity of the device. Simple DTMs can be easily built from existing DDs and generic DTMs.

Building DTMs for more complex devices requires greater effort. A number of companies offer tools, consulting services, expertise and other resources to support DTM development. They are all members of the FDT Group and you can contact them directly or use our contact form.

There are companies that charge for device DTMs with full functionality. Example: DTM without printing and device data storage is free of charge, with these functions at a fee.

The not-for-profit FDT Group is a collaboration of international automation companies that support the proliferation of FDT/DTM technology. The mission of the group is to promote the acceptance and usage of FDT in the automation industry. This is clearly a long-term goal.

FDT technology is available to all companies that wish to utilize it. Membership is available at different levels. For more info please contact the FDT Group using our contact form.

Get in contact by clicking here.

A draft specification was given to members in June 2010.
The final specification is expected to be released by February 2011.

FDT2.0 uses .NET4.0.

FDT 2.0 uses .NET framework. Software that is based on .NET can be developed to be independent from hardware architectures and operating systems. Only components that are not .NET based are specific to operating system and/or machine hardware, e.g. device drivers in Communication DTMs. The .NET framework is available on all Windows platforms (Desktop or Server Version on machine architectures x86, IA32, x64, IA64) and some others.

Yes, the certification process will be available in time for FDT2.0.

No.

Yes.

There is no deadline for the cessation of 1.2.x DTMs. Vendors will gradually switch to FDT2.0 DTMs with new devices.

This will depend on the device vendor since the vendor decides when a DTM for a certain device type will be available. However there is no urgent need to update all DTMs in one step because an FDT2.0 Frame Application will also support 1.2.x DTMs.

Yes, this is required for certification.

No, this will not run because the new interfaces of FDT2.0 are not supported by a 1.2.x Frame Application.
In this case you have two possibilities. Either your device vendor has to deliver a FDT 1.2.x DTM or your Frame Application provider has to update the Frame Application to a FDT2.0 based version. An FDT2.0 based Frame Application together with a FDT2.0 DTM will bring you the benefits of the FDT2.0 technology. An FDT2.0 Frame Application is able to integrate both FDT 1.2.x DTMs and FDT2.0 DTMs.

FDT2.0 will support the “FDI device package”.

The IEC standard will follow the standard maintenance procedure to include the FDT2.0 specification.

Yes, the FDT specification itself is independent from any operating system like Microsoft Windows. However, the implementation of the specification can be based on a particular operating system. Please consult your suppliers to determine which operating systems their products support.

Yes, the FDT2.0 standard suppors Windows 7. Please consult you suppliers to determine which operating systems their products support.

If you have a running application with FDT 1.2.x there is no reason to update it. You should think about an implementation of FDT2.0 when planning a new application/plant and your DCS system provider supports FDT2.0.
However, if you would like to benefit from the improvements of FDT2.0 you can update your application.. All DTMs based on FDT 1.2.x are useable in the new FDT 2.0 frame application.

Using FDT2.0 will make your applications future-proof.

The existing technologies COM and ActiveX are replaced by .NET as a state of the art technology. As a result, the FDT2.0 project was initiated to migrate the FDT standard and to address additional feedback and requirements from users.

FDT2.0 also prepares the platform for future capabilities that are on the FDT Group technology roadmap.

FDT2.0 will improve interoperability and will optimize DTM resources utilization. FDT2.0 will speed up calling times and data storage times of DTMs.

With FDT2.0 you will use a future-proof technology. Backwards compatibility is one of the highest priorities of FDT2.0 thereby ensuring that existing 1.2.x DTMs can still be used in an FDT 2.0 application.