The migration path from FDT to FDI

The development of FDT began in the early 2000s to improve the integration and interoperability of field devices in automation systems. Initiated by leading automation companies, FDT provided a vendor-independent platform for the communication and management of devices. FDI was later developed in response to growing demands for a simplified and consistent user experience. FDI combines the benefits of FDT and EDDL (Electronic Device Description Language) to provide a more comprehensive solution that further simplifies the integration and management of field devices.

Now that the FieldComm Group, owner of the FDI-based technology, also owns the FDT technology, device manufacturers whose products are based on FDT technology have several things to consider.

The FDT history

The majority of existing FDT-based products on the market are based on FDT version 1.2, which is strictly tied to Windows and is now around 20 years old. The later specifications 2.0 and 3.0 were intended to adapt the underlying technology to current standards such as WebUIs and platform-independent component technology. However, there is far fewer adoption of FDT 2 and FDT 3 in market-ready products from device and host manufacturers. Following the transfer of FDT technology to the FieldComm Group, it was announced that FDT 1.2 and FDT 2.0 would be placed in a maintenance-only status. Future specification work on core FDT 3.0 specifications and the development of tools will also be limited to necessary maintenance work. New specifications and new functions for existing specifications beyond those already in process will no longer be created. An example of specifications already in progress are FDT 3 protocol annexes for IO-Link and Foundation Fieldbus. The future goal is to create an FDI specification that 'marries' both the existing FDT and FDI worlds.

As the majority of FDT components available on the market are also based on the .Net Framework, which has already been discontinued by Microsoft, there is an urgent need for action on the part of device manufacturers - particularly with regard to the requirements of the Cyber Resilience Act.

From FDT-DTM to FDI-DevicePackage

In FDT, the device manufacturer creates a binary component and the device logic is programmed in C# or C++ for specified interfaces. This DTM is installed on the target computer with its own setup for Windows. An FDT server then searches for the installed DTMs. © FieldCom Group

It will be challenging to reuse existing FDT software components, so-called DTMs (Device Type Managers), in FDI. In FDT, the device logic and the user interface are typically created in a programming language such as C++ or C# based on the discontinued .Net framework from Microsoft, translated for a specific platform and delivered and installed as a binary component for Windows, often a specific version of Windows. FDT 2 and FDT 3 also offer the option of creating user interfaces with web technologies (as HTML and JavaScript). However, most of the products available on the market are based on FDT 1.2 technology.

In FDI, the device logic and the UI are described using an EDDL and converted into a platform-independent binary format. This is packaged together with, for example, technical documentation in an FDI device package (similar to a ZIP file). An FDI server imports such a package, interprets the binary format and then executes it.

In addition to the option of describing the user interface in EDDL, FDI offers the option of creating user interfaces using HTML and JavaScript and providing these as UIPs (User Interface Plugin) in a device package. Existing, programmed FDT-DTM user interfaces must be recreated using web technologies.

For this reason, new investments in FDT technology, particularly FDT 1.2 technology should be carefully considered by device suppliers. Manufacturers of field devices should start developing FDI device packages as soon as possible.

Communication in nested topologies

Manufacturers of communication components, for example remote IOs, have the problem that it is currently not possible in FDI to implement a device package for so-called gateways, i.e. protocol converters between different fieldbus technologies, using an EDDL. Aspects such as parallelism of several requests, timeouts, queues and complex byte operations cannot be realized with an EDDL.

FDI needs a solution for this in the form of binary, but platform-independent plug-ins, which will be included as an additional element in a corresponding device package of a gateway. Such plug-ins are programmed in C# for the current and platform-independent Microsoft .Net. This specification work is near completion.

ABB Field Information Manager based on FDI

With its Field Information Manager, ABB demonstrates how device management based purely on FDI is possible even for deeply nested fieldbus topologies with tens of thousands of field devices and a wide variety of fieldbus technologies (such as HART, Profibus, Profinet, Ethernet-APL, Hart IP, Ethernet-IP, ASi) in a large plant. For several years now, extended, ABB-specific device packages (known as FIMlets) have been available for use in such plants. These contain a binary but platform-independent component created in C# for Microsoft .Net for implementing protocol conversion with standardised interfaces. ABB offers device manufacturers a software development kit (SDK) that enables the creation of such FIMlets with manageable effort.

With the knowledge of the device functionality programmed in an existing FDT DTM, a corresponding FDI device package can be created as an EDDL. With PACTware, it is already possible to configure the same field device with either the corresponding FDT DTM or a newly created FDI package in a single tool and thus check the quality of the migration from FDT to FDI.

Migration path for device manufacturers

Device manufacturers whose products are currently integrated into systems on the basis of FDT/DTM should start the migration to FDI packages immediately. The development tools are available from the FieldComm Group. In addition, PACTware is a free tool for operating both worlds, FDI and FDT, together in one system. By creating an ABB FIMlet, manufacturers of remote IOs, i.e. protocol converters, can prepare themselves in the best possible way for the upcoming FDI specification update, which will only be available in a few months' time.