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.