The FDI concept is based on the client-server architecture model. In an architecture of this kind, a server provides services that various clients (usually distributed) access. A popular client-server architecture is the Internet, for example.

In the FDI client-server architecture, an FDI server provides access to the ‘information model’. The information model maps the communication topology of the automation system by representing the entire communication infrastructure and the field devices as objects. In concrete terms, this means that the data, functions and user interface of field devices are mapped in the information model.

FDI clients then access the information model via the FDI server in order to load the user interface of the field device and display it on the client side, for example. If the user now uses the user interface to change parameters of the field device, the client transfers these back to the information model. In addition, FDI clients can also access the device parameters in the information model without a device-specific user interface (eg for condition monitoring).

The data, functions and user interfaces of the FDI server that have to be represented in the information model are defined by the device manufacturer by means of the FDI device package with the following contents: Device definition, business logic, user interface descriptions and user interface plug-ins. The device definition describes the field device data and the internal structure (eg blocks). The business logic primarily ensures that the device definition remains consistent. User interface descriptions and user interface plug-ins define the field device user interfaces.

Device definition, business logic and user interface description are based on EDDL (IEC 61804-3). The user interface plug-in offers the advantages of freely-programmable user interfaces familiar from FDT/DTMs. Other FDT concepts that are being seen in FDI are nested communication, ie the open integration of gateways, and the inte-gration of communication drivers over communication servers.
Ultimately, of course, what counts is the advantages for device manufacturers, control system manufacturers and, in particular, customers.

For device manufacturers, FDI reduces effort and saves costs because in future, only one FDI device package with clearly delimited protocol-specific parts will have to be created, instead of the current three EDDs and three DTMs. Another advantage is the scalability of the device package.

For control system manufac-turers, the client-server architecture simplifies the use of device data and functions in powerful, distributed control systems. In addition, transparent access to device data and functions facilitates the integration of other applications (eg connection of MES).

For the customer, the main benefit of FDI lies in the stand-ardised integration of field devices through a future-proof standard. One basic prerequisite for this is the unrestricted interoperability of device packages from a wide variety of device manufacturers with FDI systems from a wide variety of control system manufacturers.

One Standard, Multiple Implementations
The description language EDDL is specified in full in IEC 61804-3. Because of the different communication protocols, FF, HART and Profibus, there are necessarily a few protocol-specific language elements. In the specification, this fact is reflected in the EDDL profiles. These define which language elements of EDDL are permitted for a device with a specific type of communication. While some of the differences are indeed due to the differences in the protocol features, far more are due to the history of the language in the various fieldbus organisations. This leads to the problem of a device manufacturer being unable to write a protocol-independent ‘core EDD’ for a device type because
• The language constructs are mapped differently in the profiles for FF, HART and Profibus
• The profiles are not implemented in full by the various hosts

The FDI team has looked into this point and will ensure that EDDL mapping for FDI is fully standar-dised apart from the necessary communication-specific factors.

Further expense is generated as a result of the different ways the fieldbus organisations have implemented EDDL over time. There are different binary formats and each of the organisations maintains its own tools and components for creating, testing and processing EDDs (reference interpreter). The tools and components vary significantly in their structure, functional scope and quality. Additional tools are needed for FDT implementation.

From a technical point of view, there is no need for this variety. However, it is clear that more costs than necessary are generated (Fig 2).

If we were to continue with this approach, the implementation of FDI would generate expense in each of the three fieldbus organisations in order to carry out the same enhancements for the tools and components. The resulting costs are indirectly paid for by the members of the organisation, ie the manufacturers.

For the host manufacturers, additional expense arises for the integration and maintenance of three interpreter components. Integration is made more difficult because the implementation concepts and the scopes of delivery in the fieldbus organisations differ considerably. Each interpreter component has its own development cycle. This needlessly increases the complexity on the host side and is a potential source of interoperability problems.

Additional expense arises for the device manufacturers because they must create different EDDs for the same application depending on the particular fieldbus standard. For this, they use different development and test tools. Finally, host-specific modifications are also required. All variants need to be maintained over many years.

Customer demands for a standardised, low-cost solution and good interoperability can scarcely be met because of the variety of EDDL implementations. Problems in device integration are ultimately an obstacle to the use of fieldbus technology.

The introduction of FDI offers the unique opportunity to increase the acceptance of FDI in particular and the fieldbus in general through the standardisation of EDDL and its implementation.

Genuine Standardisation
‘Genuine’ standardisation requires that the FDI standard is fundamentally independent of communication protocols, but can be adapted for communication protocols. It should be possible for a device manufacturer to create a device package per device type without host- specific or interpreter-specific modifications.

A standardised workflow and standardised tools and components for the implementation of FDI are decisive for achieving these aims (Fig 3).

The standardisation of FDI tools and components will significantly reduce the complexity and thus costs for device and system manufacturers:

Parallel development and maintenance expense in the fieldbus organisations is avoided.
Host manufacturers have lower expense because they only have to procure, integrate and maintain one standardised interpreter component.

The expense for device manufacturers is lower because a significant part of the EDD is protocol-independent and can therefore be used multiple times. Host-specific variants are not required. Standardised development and test tools reduce training expense and increase efficiency in development.

The manufacturers can concentrate on improving their applications instead of having to deal with different versions of the same technology.

The development times for host and device manufacturers are reduced. New products reach the market more quickly.

Interoperability is improved because protocol-specific or host-specific variants are no longer required. The behavior of an EDD in a standardised interpreter component is always the same.

For these aims to be achieved, it is necessary for a standardised binary format to be defined for the use of EDDL within the FDI technology on a protocol-independent basis. Based on the tools that exist today, it is necessary to provide standardised development and test tools that can be used for the development of FDI device packages for all communication protocols. A standardised EDD interoperability component should be downwardly compatible with the EDDL formats that currently exist.