The Field Device Initiative (FDI) is moving forward

Though only mentioned in my last column, the Field Device Initiative (FDI) is continuing to move forward. The reason this is important is because I estimate that 95 per cent of the field devices used in the process industry are based on DD technology.

HART, Profibus and Foundation Fieldbus are all based on DD technology and these groups are working with FDT and OPC to have the resulting documents out for IEC ballot as Committee Draft for Vote with the expectation for publication early next year, with products released at approximately the same time. As always, one challenge of releasing products is coordinating the timing of field devices and host systems to support the new capabilities. It is this factor that will drive the timing for use of FDI in the plant environment. Let’s have a look at what has led to the development of EDDL and just how FDI will change the way we interact with our field devices.

As a declarative language, EDDL describes the capabilities of the field device, leaving it to the host system to determine how to access all data and properties of all devices. As a result, EDDL tends to be used for device configuration with limited graphical support conducive to maintenance activities. Hence, the FDT organization developed DTMs. FDT is independent from any communication protocol and the software environment of the host system.

A device DTM can be used to access device parameters, configure and operate the device and diagnose problems. A second DTM, called a Gateway or Communications
DTM, is used to connect to the device DTM and handle protocol transformation.

A key group in the development of FDT and recent additions to EDDL technology is the NAMUR organization of end user manufacturers. The recommendations in its document NE105, “Specifications for integrating fieldbus devices in engineering tools for field devices,” was one of the guiding documents identifying the requirements for FDI.

So what is FDI, beyond another acronym to learn? The core of FDI technology is the scalable FDI package containing up to four different elements. The FDI package is a collection of files: The Electronic Device Description (EDD), based on
Electronic Device Description Language (EDDL, IEC 61804-3), includes the device definition (Def) that serves as the information model of the device and describes the device data and type; business logic (BL) outlines the rules for accessing the device data and any dependencies and is used to define if and how the data may be viewed when interpreted by the server; and user interface description (UID). The optional user interface plugin (UIP) offers the advantages of freely programmable user interfaces based on Windows Presentation Foundation (WPF) used by FDT as software components that define special device functions/application information and user interfaces to run on the client.

Attachments are also optional and include things like product manuals, images and electronic certifications. To prevent inadvertent errors, a number of safeguards are built into the protocol so that if there are EDD constructs (including built-in functions) that are not known to the FDI Server, the execution of the business logic shall be cancelled and if the FDI client’s UID Interpreter is not able to interpret and/or visualize a part of the UID, the user shall be informed that the resulting information is likely invalid.

The device manufacturers define via the FDI Device Package which data, functions and user interfaces are stored on the FDI Server. This makes version management of FDI packages much easier as they are managed centrally within the FDI Server.

Device packages created by device manufacturers will be certified and registered by their respective technology foundation, so it will still be best to verify the device package you are using on the relevant technology foundation approved lists on their website.

Because the EDD, DTM and new FDI Package exist only on the computer, not in the device, it is possible to migrate from DTM or EDD to FDI without changing the devices, thus protecting the existing investment of your field devices. However, one of the requirements of FDI is that the major revision of all clients, servers and packages in a given system shall be the same. FDI servers support all FDI packages following the same version or lower.

FDI clients can typically be connected to FDI servers that are implemented following the same FDI technology version or higher.

An FDI client may access multiple devices, while User Interface Descriptions and User Interface Plug-ins may only access a single device. FDI clients can communicate with the FDI server through proprietary protocols; however, if the FDI server supports third-party FDI clients, it shall support OPC UA as well so that generic OPC UA clients with no knowledge of FDI can connect to the FDI server.

The comprehensive set of services provided by OPC UA enables the “how” of system integration while the basic building blocks of the “what” of system integration are defined by OPC UA’s an extensible object model. OPC UA services act on an object model, which is managed by the server and discoverable by a client. Information is conveyed using standard and vendor-defined data types, and servers define object models that clients can dynamically discover.

Though an FDI communication server can be embedded within a communication device or can be provided via a separate server, the FDI server is usually distinct from the servers that provide run-time data to the operator, engineering and maintenance stations.

Though it appears that FDI will be more complicated than the EDDL we are using now, a lot of effort is being made to hide this complexity from the end user by providing an integrated graphical environment in which it will no longer be necessary to become protocol experts to keep your devices working and THAT is always a good thing—and a definite upgrade from today.

This article originally appeared in the June 2013 issue of Manufacturing AUTOMATION.