FDI and FDT are not the same. FDI is only for DD-based protocols that coincidently happen to be the major ones used in the process industries and, hence, of greatest interest to most of the members of the traditional process automation community. FDT presently supports 15 protocols (HART, Foundation Fieldbus, Profibus, Profinet, AS-i, CANopen, CC-Link, ODVA protocols (CompoNet, ControlNet, DeviceNet, EtherNet/IP), EtherCAT, InterBus, IO-Link, and sercos). The organizations behind the first three (the DD-based protocols) are participating in FDI. FDT is also working to expand the number of supported protocols to includ BACnet, ISA100.11a and Modbus.
FDT is not a protocol, but rather an open integration platform. As a result, it's likely that FDT applications can be found in any industry or market. Support for additional protocols will expand FDTs footprint to other areas as well.
For example, when BACnet is added to the stable, an entirely new set of industries are going to start using FDT. BACnet is the primary digital network for building automation, as well as the final link for the SmartGrid/smart buildings of the future, adding building supply, automation, security, architecture and electricity generation, among others, to the industries where FDT's influence could be felt.
Speaking of "smart buildings," some of the smartest of them being built are in the pharmaceutical industry. This is because pharmaceuticals and biotechnology require very rigorous control of ambient temperature, never mind clean room requirements. Because FDT supports multiple protocols in a single environment, it will now be possible to use the same interface to view both building and process control devices.
Read Also: Group Network Health
With Modbus as the 'common denominator' protocol for many industries, once FDT supports it, it becomes theoretically possible to connect to any smart device for which both a COMMunications DTM (COMM DTM) and Device DTM are available. This is because, much like a black channel, a FDT host system is able to natively communicate with devices by tunneling through networks using nested communications, so that the host is not required to intervene in any way or modify the communications stack of any network through which tunneling occurs.
For example, it is possible to have a network between your FDT Frame (viewer/HMI) and the field device consisting of EtherNet/IP (between two Rockwell PLCs), then Modbus from the Rockwell PLC to the building controller, and finally from the building controller to the BACnet building automation device.
FDT can also be used as your monitor for industrial wireless networks because it will soon support both HART and ISA100.11a. You can therefore use the tools to monitor network health, accessing the gateways and continuing from there to individual devices. If a DTM is missing for a DD-based device, a basic interface can be created from the DD through an 'Interpreter DTM' to provide access to the parameters, though not necessarily in the full graphical environment that would result with an approved device DTM.
Another improvement with FDT2 is that the functions, such as data transfer, instantiation and frame updates, range from three to 20 times faster than the original FDT 1.x specification, while retaining backward compatibility.
FDT is like a Swiss army knife, enabling viewing of in-depth device information from multiple protocols in one environment. Like the army knife, however, it may not be the best tool for a single task, but it certainly does the job well enough for everyday activities. Perhaps it is for this reason that all the major DCS and PLC suppliers fully support this technology, either relying on it as an integral part of their asset management and device configuration suite, or supporting its use as a common interface to the many protocols that they're required to support.