FDI meets plant’s device integration needs

By Jonas Berge, Terry Blevins, Stephen Mitschke, and Ludwig Winkel

The future is digital, and digital should be intuitive and easy to use. Some users of 4–20 mA/HART, Foundation Fieldbus, and Profibus devices have to grapple with two sets of files to integrate their devices: electronic device description (EDD) files and device type manager (DTM) software drivers. Field device integration (FDI) is a new device integration technology that can be used on any system. It combines electronic device description language (EDDL) with elements of Field Device Tool version 2 (FDT2). The NAMUR chemical industry user organization has released seventeen new user requirements for FDI in addition to the approximately 35 device integration technology requirements in their NE105 recommendation. The FDI technology has been designed to meet these plant needs, which includes investment protection, robustness, easy system administration, easy-to-use devices, interoperability, and easy migration.


The FDI technology is a device integration technology that plays a key role in addressing device management in an operating plant, as illustrated in figure 1.


May-Jun system web exclusive art 1 rev

Figure 1. Field device integration


In this article, we touch on each of these areas.

Enabling technology

At the core of the FDI technology is the device package and the common host components.

Device package

A device package is a file created by the device manufacturer that allows the device to be integrated in a system. FDI has a user-friendly file name convention. With FDI it is very easy to identify the right package for the right device. The base technology of FDI is EDDL, and a device package contains an EDDL file. Optionally the device package may also include a “plug-in” and other integration files, such as the Profibus general station description (GSD) file or Foundation Fieldbus capability file (CFF). Even a file containing the user manual can be included.


Figure 2. FDI device package


Table 1. Contents of an FDI device package

Device definition

Description of all device parameters, including label, data type and localized help text

Business logic

Wizards that step a user through the processes. Conditionals to hide internal dependencies

User interface description “device pages”  

Visualization graphics and task/role-based hierarchical menu system

User interface plug-in (UIP) “plug-in”  

Optional software component for setup and diagnostics not available in the device


Other optional integration files and manuals, etc.

A digital signature provides a standard way to verify the integrity and authenticity of the package for security.

Common host components

The common host component is software used in the host system. If an FDT2-based host were to implement a DTM version 2 to read a device package, it must also implement the common FDI host components. The subset of the FDT2 specification used by the plug-in would already be supported.

Investment protection

System workstations have to be upgraded to new versions of Windows over their many years of operation to be compatible with new software. The FDI technology was designed to extend the life of the system, and it is not shortened by the rapid pace of development in the information technology (IT) world. This is because of its EDDL-based technology.

System investment protection

Because the EDDL-based technology of the FDI packages is text based, much like HTML or XML, it is independent of the Windows operating system, and therefore compatible not only with all versions of Windows, but also with other operating systems. There is no need to upgrade Windows, etc., when a new device type or version is integrated to the system as part of expansion or replacement. The system is not rendered obsolete by new FDI packages. The FDI technology protects system investment.

Device investment protection

Being independent of the Windows operating system also means FDI packages need not be upgraded; devices are not rendered obsolete with every new version of Windows or .NET framework, or when a service pack is released. Moreover, system support for an existing device is not lost when a new Windows version or hot fixes are installed. However, the optional plug-in is dependent on the Windows operating system, and suppliers may include ancillary features in the plug-in. The base technology of FDI packages is intrinsically unaffected by the rapid obsolescence in the IT world. An additional benefit is that there is no need to wait for new FDI packages before new Windows versions and language editions, etc., can be used on the system. New technology can be adopted faster. A system can operate without having to obtain updated FDI packages each time Windows is upgraded. Devices will not go obsolete, because their FDI package does not go obsolete. The FDI technology protects device investment.

Moreover, to pass the registration process, new versions of systems will also have to be compatible with older versions of FDI packages. That is, FDI packages are backward- and forward-compatible.

Greater robustness

In the past, installing many driver programs resulted in version conflicts, which caused system problems, a substantial source of risk. FDI packages do not overwrite system files or make registry entries. Thus FDI packages do not affect system robustness.

Typically, an FDI package for one device type has a dedicated folder on the system and a unique version name, and therefore does not overwrite other files. Adding support for a new device does not break an existing device, enabling multiple versions of the same device type to coexist.

Integrated device diagnostics

Because FDI-based technology does not interfere with other software, FDI packages can be permitted onto the distributed control system (DCS) itself, enabling intelligent device management to be integrated within the DCS operator workstations, in addition to separate maintenance workstations. The operator can thus verify device health to distinguish device problems from process problems, take action for the process, and inform the instrument technician—in only three clicks or fewer—without moving to a separate maintenance workstation. Using predictive diagnostics becomes a natural part of daily operations and maintenance.

Integrated device configuration

Similarly, FDI packages can be loaded on the DCS engineering station, enabling system and device configuration from the same workstation. This makes it easy to check if ranges and other settings match.

Easy system administration

New types and versions of devices come into the plant over its years of operation. FDI packages ensure the system can be kept up to date with these new devices. Thanks to FDI, existing and future devices can easily be integrated into systems. FDI is a single common technology for all systems and devices, instead of having multiple standards and different system administration.

Easy to keep system up to date

FDI packages for registered devices can be downloaded from the respective bus organization website. Because the EDDL portion of FDI packages is encrypted text, packages are copied onto the system. They are not installed programs, and there is no need for the technician who commissions a new device to install driver programs or have IT skills. Nonexperts can integrate new device types and versions into the system. There is also a security benefit in that all technicians need not be given “administrator” level access to the system to commission new devices. Rebooting the workstation is also not required. The wizard that loads the FDI packages for new types and versions of devices onto the system is part of the system itself (not the individual packets), ensuring all FDI packages are loaded the same way regardless of device manufacturer or protocol.

Loading of FDI device packages is flexible. When the device package is loaded on the system, the technician has the option to integrate the device with both device pages and plug-in, or just with the EDDL text-based device pages.

Just like EDDL, each version of a device has its own FDI package. This ensures a new version of a device can be integrated by adding its FDI package (without removing the FDI packages from prior versions of the device), thus ensuring multiple versions of the device can coexist in the system without conflicts. A system can display a “library” of device types and versions for which the associated FDI package has been loaded, providing an overview of the devices supported by the system. Each device type has its own FDI package, allowing the FDI package for a single device to be loaded without having to load FDI packages for other devices from the same manufacturer. This allows the system administrator to maintain a minimalist set of FDI packages if desired, and prevents overwriting existing devices. The FDI package can include the GSD and CFF files required for integration of the device into the system. This saves system integration time. An FDI package can be loaded on one workstation and then automatically copied to other workstations in the system. The host may provide services to automatically download the FDI files.

Easy device database build

FDI is a single common technology for all systems and devices. The FDI package includes the codes for device manufacturer, device type, and version, enabling both the control system and intelligent device management software to automatically pick the correct FDI package for a device without manual binding. As with EDDL, FDI technology thus avoids a substantial amount of system configuration work. FDI technology is designed to be plug and play.

No license keys

The FDI package is made available with the device. The EDDL portion of FDI packages requires no license key, so system administration is easier and less costly. The optional plug-in may be licensed. There is only one interoperability registered FDI package per device type. There is no need to “tier up” to another FDI package to access full functionality. Common functions such as save, print, export, and reconcile are provided entirely by the system, and therefore available for all devices, not just some. This makes it possible to take full advantage of all devices. The device manufacturer development for an FDI package is short, and the cost very low, as special consultant programmers need not be hired. This matter to plants, because it ensures FDI packages will be available soon, without additional cost.

Easy-to-use devices

Device manufacturers provide FDI packages for their devices with an easy-to-use interface. With FDI, users do not have different device setup, calibration, diagnostics, and so on.

Common software

FDI-compliant systems use standard FDI host components. Devices are displayed as intended by the device manufacturer and do not need host-specific files. FDI enables all devices to be managed the same way regardless of the communication protocol. This gives plants freedom to choose systems and devices.


Figure 3. The FDI host renders graphics with content and structure defined by the device manufacturer.


User guidance

Device manufacturers create FDI packages defining the step-by-step guidance of setup and calibration wizards, as well as text and illustration for diagnostics and other help. The visible dialog box interaction for wizards is provided entirely by the system, and is therefore consistent for all devices. Configuration and setup becomes easier. Similarly, troubleshooting tips for diagnostic alarms are presented consistently.



Figure 4. Setup can be manual or guided by wizards created by the device manufacturer.


Wizards, already familiar to many EDDL system users, make complex procedures such as device setup and calibration easy, reducing mistakes, and at the same time making sure all technicians perform these tasks the same way. Device manufacturers impart their know-how to technicians with text, images, and context-sensitive help to make their devices easy to use. Only relevant information and valid options based on prior selections and images based on actual state are presented, thus shielding the technicians from the internal dependencies and complexities of devices.

Audit trail logging, displaying, and printing are provided entirely by the system and therefore are supported for all devices, not just some. Similarly, printing documentation and exporting device parameterization are provided entirely by the system for all devices. The system also handles displaying and editing parameter values, ensuring that when multiple users change device parameterization from different workstations, there are no data synchronization issues.

Consistent look and feel

Device manufacturers create base FDI packages using EDDL to define the content and structure of how parameters, tend charts, waveform graphs, and wizard buttons for information and features in their devices are organized in system displays to make their devices easy to use. Graphical rendering of the device pages (i.e., the EDDL portion of the FDI package) is provided entirely by the system and therefore the look and feel is the same for all devices. For instance, parameters are flagged or color coded for “read-only,” to remind technician to “commit” changes, or to “reconcile” parameter settings the same way for all devices. Similarly, all trend charts and waveform graphs are rendered entirely by the system, and therefore panned and zoomed the same way using the same toolbox for all devices. Common buttons for committing parameter changes, accessing help, reconciling, and printing are rendered the same size and color, and with the same label or icon in the same screen location for all devices. This consistency among devices of different types, from different manufacturers, and using different protocols, makes work easier for technicians who have to manage a mix of devices.

A standard multilingual EDDL dictionary of parameter labels, options, help, and common wizard phrases further promotes consistency.

Easy device navigation

Device manufacturers separate commonly used features and parameters from special features and parameters such as advanced diagnostics. The structured menu system makes navigating large sets of parameters intuitive and easy. Device manufacturers provide an at-a-glance device overview and access to key features readily accessible from the top-level menu (“home page”) for the device. Less frequently used advanced information and special features are located deeper in the menu system to prevent clutter at the top level of the menu display. Even unique manufacturer-specific features are provided by the FDI package.

Access to full device functionality

Powerful graphics, including trend charts and waveform graphs with multiple simultaneous values, as well as table grids, allow advanced setup and advanced diagnostics of sophisticated (complex) devices like control valve positioners, vibration transmitters, variable speed drives, gas chromatographs, and radar level transmitters using the same common software as simple pressure and temperature transmitters. Various software and tools based on FDI technology are suitable for all phases of the life cycle, including DCS operator consoles, DCS engineering consoles, the intelligent device management software part of asset management systems, laptops or tablets, handheld field communicators, and documenting calibrators. FDI packages make devices fully interoperable, since they are displayed as intended by their manufacturers with nothing hidden.



Figure 5. Trend chart rendered graphically from device description


Interoperability registration

Interoperability testing applies to both devices and systems to ensure interoperability between systems and devices from different manufacturers.

Interoperable devices

The EDDL-based device definition, business logic, and device pages part of the FDI package are mandatory, ensuring devices can be commissioned. The HART Communication Foundation, Fieldbus Foundation, and Profibus organizations test the FDI package together with the interoperability testing of devices. This independently verifies the FDI package is correct and matches the device, thus ensuring interoperability for the respective protocol. Registration applies to every type and version of a device before it is released on the organization website. Mandatory and optional features of the FDI package are tested and registered. Devices that have passed the HART Communication Foundation, Fieldbus Foundation, or Profibus organizations interoperability registration test are permitted to carry their respective registration checkmark. Because FDI packages are part of the interoperability test, the checkmark also means FDI interoperability for the respective protocol. Full device and system interoperability registration results are available on the organization websites. Registration details include manufacturer, device type, device version, FDI package version, and tester version. An FDI package uses harmonized EDDL.

FDI package compliance with style guide criteria such as menu structure can be automatically tested as part of the interoperability registration process.

Interoperable systems

Systems must implement common FDI host software components. These software components used in FDI-based systems are maintained by the FDI organization ensuring interoperability. For systems, the intelligent device management software part of asset management systems is tested to ensure it interprets FDI packages correctly. Mandatory and optional features of the system are tested and registered.

Easy migration

The FDI technology enables many migration solutions for existing systems, while protecting existing investment in devices.

Easy system migration

Existing system software can be upgraded to a version supporting FDI without making changes to underlying system hardware or network infrastructure. There are migration paths for both EDDL- and FDT-based systems; no investment is lost. They both can be upgraded to support FDI.

No device replacement

Device communication is independent of FDI. There is no “EDDL device,” “FDT device,” “DTM device,” or “FDI device.” Devices are 4–20 mA/HART, Foundation Fieldbus, or Profibus. FDI can be deployed without replacing devices or upgrading device firmware. Device manufacturers may provide FDI packages for existing devices, enabling the full benefit of FDI for older devices also. The system may also support EDDL and FDT technologies in parallel with the new FDI technology, for devices without an FDI package.


FDI technology provides a single common device package for device integration on any system. Thanks to the base EDDL technology, the FDI solution meets plant needs, such as investment protection, robustness, easy system administration, easy-to-use devices, and interoperability. Moreover, existing systems can easily be migrated to FDI technology. FDT Group, Fieldbus Foundation, HART Communications Foundation, Profibus and Profinet International, and the OPC Foundation have been working aggressively to develop the FDI specification. Migration to FDI should be in the long-term plans of any plant.

About the Authors

Jonas Berge (jonas.berge@emerson.com) was educated in Sweden and is a director at Emerson Process Management in Singapore. He has more than 27 years of experience in the field of instrumentation and controls. Berge is a subject matter expert in fieldbus, wireless, and intelligent device management. He is a senior member of ISA and member of the steering committee of the Fieldbus Foundation in Asia Pacific. Berge is the author of the books Fieldbuses for Process Control: Engineering, Operation, and Maintenance and Software for Automation: Architecture, Integration, and Security and has contributed to several others and is frequently featured in articles.

Terrence L. “Terry” Blevins (terry.blevins@emerson.com) has been actively involved in the application and design of process control systems throughout his career. He was the team lead for the development of DeltaV advanced control products. Terry was the Fieldbus Foundation team lead for the development and maintenance of the Function Block Specification. He is the US expert to IEC SC65E WG7, chairman of ISA104 committee and technical advisor to the United States Technical Advisory Group (USTAG) for the IEC65E subcommittee. Terry coauthored the ISA bestselling books Advanced Control Unleashed and Control Loop Foundation and has over 50 patents on process control system design and applications. Terry received a Bachelor of Science in Electrical Engineering from the University of Louisville in 1971 and a Master of Science in Electrical Engineering from Purdue University in 1973. He is a member of Control magazine’s Process Automation Hall of Fame and an ISA Fellow. Presently, Terry is a principal technologist in the applied research team at Emerson Process Management.

 Mitschke photoStephen Mitschke (stephen. mitschke @fieldbus.org) is director, Fieldbus products at the Fieldbus Foundation based in Austin, Texas. He is responsible for the Foundation’s products and services, including specifications, product development tools, conformance and interoperability test tools, product registration services, certified training, and consulting. Mitschke has more than 17 years of experience with the design, development, deployment, and support of Foundation Fieldbus technologies, including H1 for process control, high speed Ethernet, Foundation for safety instrumented functions and EDDL. He serves as an official delegate to the FDI project.

Ludwig Winkel (ludwig.winkel@siemens.com) received his degree “Diplom Ingenieur” in electrotechnical, electronic, and control engineering from the University of Saarbruecken, Germany, in 1977. He joined Siemens AG in Karlsruhe, Germany, in November 1977 in an R&D group for electrical measuring devices. Winkel introduced microcontroller technology and large-scale integrated chips in the measuring devices that were revolutionary in 1977. He became an R&D group leader with the projects to invent closed-loop control hardware and software for programmable logic controllers (SIMATIC PLC). He wrote two books on the system design, SIMATIC Software – Process Control System PCS 7 – Validation Support Manual I and SIMATIC Software – Process Control System PCS 7 – Validation Support Manual II. Since 1992, Winkel has been actively involved in developing and promoting standards for instrumentation and control systems. He became a member of the Interoperable Systems Project, the IEC Subcommittee 65C for Function Blocks for process control, and the fieldbus committee IEC SC65C WG6. In 1999, he joined the strategic group in the Siemens Automation division for fieldbus communications.

Reader Feedback

We want to hear from you! Please send us your comments and questions about this topic to InTechmagazine@isa.org.