What Is a HART DTM and FDT Frame?
There are two ways a host learns how to talk to a HART device in depth, and the DTM is the one that trips people up because it looks and behaves so differently from a device description file. This page explains what a device type manager is, how it plugs into an FDT frame application, and when you reach for a DTM versus a DD. It is written for integrators who keep seeing both acronyms and want a clear model of which is which.
HART DTM in one line: A DTM (Device Type Manager) is a software component the device manufacturer supplies that plugs into an FDT (Field Device Tool) frame application to configure and diagnose a specific device. Unlike a device description file, a DTM contains its own executable user interface and logic. The FDT frame is the host that hosts DTMs, giving one tool a common way to manage devices from many vendors.
DTMs Plugged Into an FDT Frame
FDT, Field Device Tool, defines a standardized way for a host application to host manufacturer-supplied device components. The host is called the frame application, and the components it hosts are DTMs, device type managers. A DTM is a piece of software written by the device vendor that knows everything about one device or device family and provides its own screens, wizards, and logic for configuration and diagnostics. You install the DTM into the frame, and the frame gives it a place to run and a standardized channel down to the field device.
The important architectural point is that a DTM carries its own user interface, whereas a device description is only a description that the host renders. A DTM can present a custom graphical wizard, a proprietary diagnostic dashboard, or an interactive calibration screen exactly as the vendor designed it, because it is executable software rather than a portable text description. That power is also its cost: a DTM is platform-specific and can bring the compatibility and stability quirks of any installed software, which a DD, being non-executable, cannot.
The frame application also handles the communication path. A DTM does not need to know whether it is reaching the device over a HART modem, a HART multiplexer, or a gateway, because a separate communication DTM abstracts the transport and the device DTM talks through it. This layering is what lets one FDT frame manage a whole plant's worth of mixed devices and connection types through a single application, which is a large part of FDT's appeal for asset management.
DTM or DD: Choosing the Integration Path
In practice, HART devices are supported through one or both integration technologies, and which you use depends on your host and your needs. If your asset-management tool is a DD-based host, you install the device's DD from the description library and the host renders its menus. If your tool is an FDT frame, you install the vendor's DTM and get the vendor's own interface. Some environments support both, and a device may ship a DD, a DTM, or both, so part of commissioning is confirming the integration file your host can actually consume.
The trade-off is portability versus richness. A DD is portable, lightweight, and works on any conforming host because it is a standardized description, which suits large multi-vendor fleets where consistency and simplicity matter. A DTM can offer a richer, more graphical, more vendor-specific experience for a complex device, at the price of being tied to the FDT frame and behaving like installed software. Neither is universally better; the right choice follows your host platform and how much device-specific depth you actually need.
For a monitoring architecture the distinction matters less than it first appears, because the deep configuration a DTM or DD enables is engineering work, not day-to-day operations data. Pulling process values and device status into a platform such as Merobix relies on the portable command set through a gateway or multiplexer, so neither a DTM nor a DD is on the critical path for surfacing readings and diagnostics to operators. The DTM and DD live in the engineering tool; the companion page on the HART device description file covers the DD side of the same integration question.
Frequently Asked Questions
What is the difference between a DTM and a DD?
A DD (device description) is a standardized, non-executable file that a host renders into menus, so it is portable across any conforming host. A DTM (device type manager) is executable software the vendor supplies that carries its own user interface and plugs into an FDT frame application. A DD trades richness for portability; a DTM trades portability for a richer vendor-specific interface.
What is an FDT frame application?
An FDT frame is the host application that hosts DTMs. It gives each device DTM a place to run and a standardized communication channel down to the field device, usually through a separate communication DTM that abstracts the transport. One frame can manage devices from many vendors and over different connection types through a single tool, which is FDT's main appeal for asset management.
Do I need a DTM or a DD for a HART device?
It depends on your host. A DD-based asset-management tool needs the device's DD; an FDT frame application needs the vendor's DTM. A device may ship one, the other, or both. For simply reading a device's variables and status into a monitoring system through a gateway, neither is required, because that relies on the portable HART command set.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.