FDI – The Future of Open Device Integration

01 June 2007

At Hannover Fair, the Institute for Information Technologies in Mechanical Engineering (itm) of the Technische Universität München announced their proposal called Field Device Integration (FDI). The client-server scheme combines the advantages of EDDL and FDT and integrates them into a single architecture.

FDT technology specifies the interfaces between the device specific functions for operation, the so called Device Type Manager (DTM) and the device independent engineering system, the FDT frame. Since a DTM has to comply only with the interface specification, the device manufacturer is not restricted in the design of the functionality, in the implementation of the DTM software component, and in the choice of the programming language. The operation of very complex devices can be realised with this standard.

However, one substantial disadvantage of FDT technology is the tight coupling between the DTM software components and the Microsoft Windows platform. Furthermore the freedom of programming a DTM allows
different philosophies for device operation and can also compromise the robustness of the engineering system when programming principles are disobeyed. The FDT Group’s style guides for user interfaces try to cope with such issues.

In contrast, EDDL technology defines its own language that the device manufacturer uses to write textual
descriptions (Electronic Device Description, EDD) for their devices. The result is a ‘digital datasheet.’ Compared to standard programming languages the amount of EDD language elements is limited and specific to device description. This allows for easy and efficient development of EDD device descriptions
which are processed by an EDD specific interpreter, and is independent of hardware and operating system
platforms. It provides a uniform philosophy for device operation, and the interpretation yield high robustness.

EDDL technology suits devices with low to middle complexity very well. For very complex devices the limited scope of EDDL leads to restrictions. The current extensions of the language concerning new features for graphical user interfaces and additional functions try to resolve this disadvantage, however, the complexity of the language increases.

Integrating the advantages
The authors have developed a new concept that integrates the advantages of EDDL (platform independence, ease of use, and robustness) with the advantages of FDT (unlimited functionality, extensibility, and market differentiation) in a clearly structured client-server architecture. This also includes the positive system aspects of EDDL and FDT such as robust interpretation or ‘nested communication,’ the open communication within heterogeneous hierarchical networks.

In order to systemize device operation in a client-server architecture a clearly structured model for device integration was defined that consists of two parts: the Device Information Model (DIM) and the Device Operation Model (DOM).

The DIM describes the device data (and their dependencies) that are available from the outside via the
communication interface. It provides read and write access to the device, assures consistency, and is a one-to-one mapping of the device data that are accessible within the device firmware.

The parameters in the DIM are the same as the parameters in the field device. The data ‘dependencies’ means that some parameters may be dependent on other parameters. An example would be the engineering units (EU) of the alarm levels of a level device and the EU of the process value. A change of the EU of the process value also needs to trigger a re-calculation of the alarm levels to reflect the new EU. The server ‘knows’ about these dependencies.

The DOM contains the role specific device operation via a graphical user interface (GUI). Functions for processing device data (Advanced Business Logic, Figure 1) are an important element of the DOM.

Since different use cases and roles pose different requirements for device operation, more than one DOM can exist for a single device. For example there could be one DOM for device operation and another DOM for asset management. Both are using the same device data, but focusing on different use cases. No matter how many DOMs there are, they all access the device’s DIM in order to access device data.

An example of data in the DIM would be a linearisation table to adjust a level device to the vessel shape, or an envelope curve that the device has recorded. The DOM does not store data on its own. It accesses the DIM to retrieve, for example, the envelope curve to display it to the user. Or the DOM could contain ‘business logic’ to calculate the linearisation table from a 3D CAD file. The DOM would then write the calculated table to the DIM, and therefore, to the field device.

No device relevant data are stored in the DOM, because this could cause, inconsistency if a different DOM (or only different instances of the DOM, for example, in different engineering stations) are used.

This clear separation between DIM and DOM is an essential attribute of the FDI concept and allows a cleanly
structured client-server architecture based on OPC UA. The OPC UA server uses the DIM to present device data in its address space. The server communicates with the devices via ‘nested communication’ and also through gateways. On the OPC UA client side the Device Engineering Framework displays the device DOMs as a device independent engineering system comparable to a FDT-frame (Figure 1).

The reader might ask, ‘How do EDDL and FDT fit into all this?’ In the server the focus lies clearly on the presentation of the data interface of field devices in terms of structure and behaviour. The description of device data within the DIM EDDL is the ideal basis since it provides all means necessary for the description of the DIM. Therefore the platform independence and the interpreter-based execution provide a high level of
technology independence—both very important requirements for a server-side technology.

In addition an EDD that describes the DIM is very easy to create. Another advantage of using EDDL for the DIM is the well known fact that nearly all DTMs currently available on the market also contain a DIM-like EDD, only that it is not as clearly structured as in the FDI concept. Since the server also represents the
network topology, the approved ‘nested communication’ concept of FDT is adopted which allows the open
integration of any fieldbus system.

Any EDD today completely describes the DIM and additionally includes a relatively simple DOM. Therefore, an existing EDD for a device may be used as it is. In the future the DIM and DOM in an EDD should be separated. If a DIM for a new device has to be created, EDDL can be used to create the EDD, but it is only
necessary to describe the DIM. Using EDDL to describe the DIM should be easy, and more effective than programming the dependencies in a normal programming language because EDDL is specially designed for that use case. Any language editor or IDE supporting EDDL might be used to develop DIMs. The DOM could either be described in EDDL or, if necessary, programmed.

The client side Device Engineering Framework can be compared to the FDT frame application. It allows the user to operate the device by providing the DOM. The focus lies on the sequences that are necessary to operate the device. For simple GUIs EDDL covers all requirements. More sophisticated functions are programmed by the device manufacturer via universal languages The use of Java leads to platform and
operating system independence for the DOM.

The Device Engineering Framework loads the DOMs from the server into the client and provides the framework for the programmed functionality. So a DOM can be seen as simplified DTM with significantly
less complexity. The new concept picks up both technologies EDDL and FDT and integrates them in a universal architecture using their respective advantages where they are of the most benefit.

Prototype proves feasibility
The prototype of the concept was demonstrated during Hannover Fair. A challenging Siemens drive DIM with more than 2,000 parameters was completely described with EDDL. Via the parameters the so called free function blocks can be activated and connected to realise simple logic functions directly in the drive. This is achieved by the drive DOM that consists of both an EDDL part, for quick commissioning, and a programmed extension that provides a graphical editor to connect the free function blocks of the device via ‘drag and drop’ configuring.

The communication aspect was addressed by integrating CANopen communication. A Profibus-HART
gateway demonstrated that nested communication in heterogeneous networks is possible. For the prototype, Java was used to provide platform and operating system independence. Figure 2 shows the programmed graphical editor that allows drag and drop connecting of the function blocks of the drive.

Who delivers the components?
Different scenarios for the application of the new solution are possible. The DCS vendor delivers an OPC UA server that provides access to the device data within its address space via an open client interface based on the DIMs of the plant’s field devices. The Device Engineering Framework as an OPC UA client for the DOMs can also be part of that system or can be purchased from other vendors.

The open configurable nested communication is another important feature of the OPC UA server. It allows
integrating and supporting other devices with different fieldbus protocols independent of the system vendor. Such openness helps to gain widespread acceptance and to avoid the fear of being overly dependent on a single vendor, which is especially important for small and medium-sized companies.

The device vendor delivers a package that contains the device DIM and DOM to be stored in the server database. This DIM/DOM package is the replacement for the EDD and DTM. The end user can benefit from the OPC UA server by retrieving device data for other applications such as MES and asset management.

Manifold advantages
The biggest advantage of FDI is the clear architecture that defines distinct tasks which reduces the complexity of device operation.

Platform independence and robustness via interpreter based execution (EDDL and Java) allow for long term technology independence which is a very important issue in industry. The central management of the elements DIM and DOM within the OPC UA server reduces the effort for installation and versioning since, by loading the DOMs from the server, client installations are not necessary. This is a big advantage in multi-client environments which may include operator, maintenance, and diagnostic work stations (Figure 3).

The new concept provides specific strategies that allow using current EDDs and DTMs further on without the need for change. For EDDs a client side GUI generator takes care of displaying the user interface based on EDDL language elements. DTMs are executed on the client side within a FDT wrapper that provides the DTMs their accustomed environment.

During the presentation of FDI at Hannover Fair many discussions with visitors pointed to one conclusion: The technical challenges have been mastered and the combination of the advantages of both EDDL and FDT in a single solution is impressive. The decision of the EDDL Co-operation Team (ECT) and the FDT
Group to join forces to specify a common solution based on the FDI concept before the end of 2008 marks a milestone in the field of device integration. With the specification likely to become an IEC standard, we are about to enter a new era of device integration.

About the authors
Prof. Dr.-Ing. Klaus Bender is head of the Institute for Information Technology in Mechanical Engineerin (itm) of Technische Universität München and member of the board of Profibus International. Dipl.-Ing. Daniel Grossmann and Dipl.-Ing. Benjamin Danzer are research assistants at the institute.


Contact Details and Archive...

Related Articles...

Print this page | E-mail this page