Print this article

Comment

1 September 2002

Mixing protocols: The problem

Fieldbus-capable devices are replacing traditional I/O and 4–20 mA instruments.

Before exploiting fieldbus benefits, the complete plant must undergo engineering and commissioning. When it comes to device configuration today, we typically see different tools used to address the needs of a single device or fieldbus.

To commission a complete system, data often needs to manually exchange between device tools and system tools. In large, heterogeneous installations, this is especially time-consuming and introduces a high potential for errors.

Intelligent field devices provide extensive diagnostics; self-test functions; calibration functions; online parameter adaptation; maintenance data about the degree of wear and tear; remaining utilization time according to the operating time, temperature, and dynamic stress; position counter histories; and temperature histories.

Tool of all trades

Ideally, a sophisticated engineering tool covers all tasks of configuration and commissioning. The tool has to manage the field devices and can access and configure the devices according to their deployment in the system context. The engineering tool sets up fieldbus communication and establishes communication paths, allowing a controller and high-level applications to access the relevant data.

Considering several fieldbus protocols coexist and often function together in the same plant, the tool must provide this comprehensive support for each fieldbus. A typical example is a plant with existing HART instrumentation that extends by new sections, where Foundation fieldbus (FF) handles the process control loops and Profibus takes care of fast communication of binary and analog I/O data retrieved via remote I/O.

Another aspect that becomes increasingly important in the sense of efficient engineering is the reuse of existing tried and tested solutions, especially in large installations where the number of signals may total more than 10,000 I/O points and more than 100 different device types.

The device description (DD) for HART devices is a starting point for state of the art approaches to configuration. Originally, it loaded only to handheld terminals that connected directly to a device in the field. With the aid of the DD, the handheld terminals master the devices, providing all necessary dialogs to set parameters or check the internal states of the device.

Today, the HART DD functions with handheld terminals and PC tools. However, integrated, comprehensive, field device management is not yet supported because the DD is made for online access and not for off-line planning purposes.

The FF communication protocol also furnishes a DD that is similar to the HART example. In addition, FF defined the so-called Capabilities File that provides off-line information about the device's various features. Together with the Value Files that allow storage of instance-specific data, this facilitates the engineering of FF segments.

However, there are still three different files or types of information to be handled in order to completely describe a device in all the different stages of its life cycle. This requires some extra administration, either done manually by the user or automatically by smart system mechanisms.

Profibus started its approach to device configuration from the off-line side. In the first stage, only a GSD file (GeräteStammDaten, or device database file, also called a device data sheet) is provided with the device. This file provides communication parameters and contains basic information about the possible configurations, parameter settings, and diagnostic messages.

While this is sufficient to start up a cyclic communication on a bus segment and to commission simple I/O devices, devices requiring a higher number of parameters necessitate a more sophisticated approach.

Profibus then defined the electronic DD. As with HART and FF, this language is suitable for operating transmitters and actuators that feature online parameterization and diagnostics via acyclic services. However, it reaches its limits in modeling device behavior when it comes to more complex devices such as modular remote I/Os or free-programmable drives, which are often used with Profibus.

The given examples show there is no universal method for integrating different fieldbus protocols into host applications. The existing means all stem from the same idea, but the implementation differs. Accordingly, it is hard to find engineering tools that have integrated all relevant protocols for heterogeneous installations.

There are tools on the market that cover more than one fieldbus. However, rather than using the DDs exactly as given by the respective standard, these applications often require some preprocessing of the DDs or additional information in order to present a unified interface to the user.

The device manufacturer has to spend extra effort integrating the device into different tools and maintaining the different DDs. Furthermore, the tools do not necessarily integrate with the engineering process beyond the fieldbus.

Thus, a planner of a control system today faces a multitude of tools that cover just single buses or single device types and that work on their own proprietary database. All data generated by these tools and needed by the control system must be exchanged manually or by some file import/export functions.

Because there is no standard for this type of data exchange, it is necessary to convert data, which requires detailed technical knowledge, a high degree of experience, and time. Guaranteeing consistency of data, documentation, and configuration can ultimately happen only through an intensive system test. Such practice is inefficient and unacceptable.

—Stefan Bollmeyer and Axel Lohbeck,
ABB Automation Products GmbH

Next month in this department, read Part II, "Mixing protocols: The solution."