EFFICIENT PLANT ENGINEERING AND MAINTENANCE USING FDT/DTM TECHNOLOGY

Stefan Bollmeyer Manager Technical Product Management ABB Automation Products GmbH Schillerstr. 72, 32425 Minden Germany Axel Lohbeck Manager Software Development ABB Automation Products GmbH Schillerstr. 72, 32425 Minden Germany

KEYWORDS
Process Automation, Plant Engineering, Plant Maintenance, Field Device Configuration, Asset Management

ABSTRACT
Fieldbus-capable devices are increasingly replacing traditional I/O and 4-20mA instruments. Before fieldbus benefits can be exploited, the complete plant must be engineered and commissioned. 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 be manually exchanged between device tools and system tools. In large, heterogeneous installations this is especially time consuming and introduces a high potential for errors. The problem of integrated device configuration is now addressed by Field Device Tool Interface (FDT) technology. This extensible, fieldbus-independent architecture makes integrating field devices into control applications as simple as adding new printers to computer networks by just installing a new device driver. Device vendors supply a software component (Device Type Manager, or DTM), with their device. This DTM is similar to a device driver. The DTM interacts with system applications like engineering tools and provides tailor-made user interfaces for configuration, commissioning, and maintenance. These user interfaces are tailored to the device so that handling of devices becomes easier and more efficient during the complete lifecycle. This paper provides an overview of the cost saving potential of FDT as standardized technology.

INTRODUCTION
With the increasing use of digital fieldbus communication technology (like PROFIBUS, FOUNDATION TM Fieldbus, and the communication hybrid, HART) in process control, the architecture of control systems is now undergoing structural changes. Where in the past automation systems ended at the I/O terminals of the module, the scope of modern control systems now extends to the sensors and actuators. Where standardized 24V signals or the 4...20mA standard signal used to be the definition of interoperability, expectations today are much higher. The extended limits of the control system must be reflected in the process control system tools. In the future, configuration, parameterization and diagnosis of a control system must include the field devices. In this instance, the term field device is defined broadly, because actuators, analyzers and low-voltage switchgears are also becoming bus-compliant and can thus be integrated. Even today, individual fieldbus systems allow function blocks to be implemented in the field devices. This requires engineering tools which are able to exploit these new opportunities. The integration of intelligent field devices into control systems also makes diagnostics information about the field devices available for further processing in these systems. This information should not be restricted to the transmission of error messages, but must also enable users to benefit from all the advantages of digital communication. Under the heading of "asset optimization", future users will find a multitude of functions which allow them to perform administration and to enable predictive maintenance on their automation components. A key user benefit will be the degree to which these functions are integrated into the control system. The architecture of the control system and the modeling of the automation objects must be sufficiently flexible for customers to monitor their plant components from multiple viewpoints. Process control system tools offer functionality for reducing engineering costs like reuse of templates and bulk data management. Today most of these tools are restricted to the bounds of the process control equipment like controllers and proprietary I/O while fieldbusses and field devices are not covered. The paper will introduce a technology that lets these limitations vanish.

PROBLEM DOMAIN
In process industries, fieldbus technology provides to the plant operator greater value than traditional 420mA wiring can provide. Information offered in addition to the pure measurement of a process value allows for pro-active decision-making with respect to maintenance or production planning. With process control systems and maintenance systems becoming closer integrated, even real time data from the field can be directly propagated to high-level system tools like Computerized Maintenance Management Systems (CMMS). Evaluating and combining device information at that level allows detection, at an early stage, of a device that is threatening to malfunction or that requires maintenance. Such optimized planning of predictive maintenance helps to improve the cost structure of a plant and to reduce unscheduled downtimes, thus increasing availability. [1]

Examples of information and functionality that become available with intelligent field devices are: 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 Temperature histories However, before these advanced fieldbus features can be exploited, the complete system must be engineered and commissioned. The information flow from the field device to the different consumers in the system context must be configured. Process data is needed by the control function, alarms should be propagated to the operator station, and maintenance data should be available at the asset management workplace or CMMS. Offline device information is also required by different applications. For instance, engineering units, alarm limits and allowed operating modes are needed to configure an operator faceplate. To set up an alarm page that provides the operator with meaningful information, alarm texts in the appropriate language must be assigned to alarm data generated by the device. Also a CMMS typically needs the device ID and serial number of the mounted device to generate a work order when a maintenance request for a device is pending.

FIG. 1 DEVICE INFORMATION USED FOR COMPLETE SYSTEM INTEGRATION

These examples indicate that before the benefits of intelligent field devices can be utilized in a running plant, additional effort and complexity have to be taken into account during engineering. When looking at the complete lifecycle costs of a plant, it turns out that a remarkable cost saving potential lies in the efficient planning and commissioning of a control system. Ideally, a sophisticated engineering tool covers all these described 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 is able to set up fieldbus communication and to establish communication paths allowing a controller and high-level applications to access the relevant data. Considering that several fieldbus protocols coexist and often are used 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 is extended by new sections where FOUNDATION TM Fieldbus is used for process control loops and PROFIBUS for 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 over 10000 I/O points and more than 100 different device types. To reduce costs it is desirable to create exemplary solutions for certain functional subsets, such as in the example of a reactor with complete instrumentation. These solutions should be tested, and then applied as templates. These templates can be copied -even automatically via bulk data handling- as needed in a project. With respect to field devices, this means that the templates are not limited to a representation on function charts but also include all device settings, including: alarms, limits, and complete parameterization. The device representation can be seen as an automation object that contains all device functions and attributes.[2]

FIG. 2 EFFICIENT ENGINEERING BY REUSE OF TEMPLATES

DEVICE CONFIGURATION TODAY

The question that frequently arises, How can todays means for device configuration support such efficient and cost optimized engineering approaches? The device description (DD) for HART devices can be seen as a starting point for state of the art approaches to configuration. Originally, it was designed to be loaded to Handheld Terminals that are connected directly to a device in the field. With the aid of the DD, the handheld terminals are able to master the devices, providing all necessary dialogs to set parameters or to check the internal states of the device. Today, the HART DD is not only used with Handheld Terminals, but is also interpreted by PC tools. These tools, connected to the instrumentation via multiplexers or HART-capable system I/O, allow access to the devices during runtime from a central control room. In this way, at least a subset of the desirable asset management functionality is made available. However, an integrated, comprehensive field device management is not yet supported, since the DD is made for online access and not for offline planning purposes. The Foundation Fieldbus (FF) communication protocol also furnishes a DD which is similar to the HART example. In addition, FF defined the so-called Capabilities File that provides offline information about the devices features. Together with the Value Files that allow for storage of instance-specific data, this facilitates 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 lifecycle. 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 offline side. In the first stage, only a GSD-file (or GerteStammDaten device database file; Also called a device datasheet) 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, a more sophisticated approach was needed when devices contain a higher number of parameters. PROFIBUS then defined the Electronic Device Description, or EDD. As with HART and FF, this language is suitable for operating transmitters and actuators that feature on-line parameterization and diagnostics via acyclic services. However, it reaches its limits in modeling device behavior when it comes to more complex devices like modular remote I/Os or free programmable drives which are often used with PROFIBUS. The given examples show that there is no universal method for integrating different fieldbus protocols into host applications. The existing means are all based on 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 which cover more than one fieldbus, however, these applications often do not use the DDs exactly as given by the respective standard, but require some preprocessing of the DDs or additional information in order to present a unified interface to the user.[3] The device manufacturer has to spend extra effort integrating the device into different tools and maintaining the different device descriptions. Furthermore, the tools are not necessarily integrated with the engineering process beyond the fieldbus.

FIG. 3 DEVICE CONFIGURATION IN CONTROL SYSTEMS TODAY

Thus a planner of a control system today faces a multitude of different tools that cover just single busses 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. Since there is no standard for this type of data exchange, it is necessary to convert data, requiring detailed technical knowledge, a high degree of experience, and time. Consistency of data, documentation and configuration can ultimately only be guaranteed through an intensive system test. Such practice is inefficient and unacceptable.

THE DEVICE DRIVER SOLUTION

In the late 90s control system manufacturers ABB, Elsag Bailey and Siemens recognized the gap between existing methods of fieldbus configuration and the needs of efficient control system engineering. These companies founded a working group under the umbrella of the ZVEI, the German electrical and electronic manufacturers association. The groups goal was to define a manufacturer-independent, protocol-independent integration of smart field devices into control system engineering tools. In office environments, the individual characteristics of a printer such as color gradations and print modes are enabled by a vendor specific printer driver installed on top of an operating system working on a well-defined set of software interfaces. Like installing a new printer driver on an operating system, the device drive solution arrived at by the ZVEI allowed a new device to be added to a control system tool just by installing a device driver provided by the device manufacturer.

FIG. 4 THE DEVICE DRIVER IDEA

Major goals of the ZVEI were: [4] Central workplace for remote planning, diagnostics, and service with direct access to all field devices. Eliminate the necessity for different tools and handheld diagnostic devices while maintaining data integrity Integrated consistent configuration and documentation for field devices, the control system, and the fieldbusses Single entry of engineering data for control system and field device data Central database and backup Easy and quick integration of new device types into the control system No limitation to a small set of commonly accepted configuration and diagnostics variables Enable new technologies like web Support of individual device characteristics and special features First results of the group attracted other companies (including Endress & Hauser and Foxboro), to join. Also, the PROFIBUS Trade Organization recognized the potential of the evolving concept and supported its development. In the summer of 2000, the group released the first version of the Field Device Tool (FDT) Interface Specification. The PROFIBUS Trade Organization adopted the FDT Spec as a guideline for device configuration in November 2000.[5] The FDT Specification defines a device driver object, the Device Type Manager (DTM). The DTM is integrated into a system tool via a set of software interfaces given by the spec. Via these interfaces, the DTM and hosting application can interact and exchange data. The architecture is highly scalable. It allows implementation of a subset of the interfaces in the beginning, and the opportunity to extend this functionality later. It is also possible to easily add new functionality in following FDT-versions.

FIG. 5 FIELD DEVICE TOOL INTERFACE ARCHITECTURE

All fieldbus peculiarities are encapsulated in XML documents that are exchanged via the interfaces. This allows new fieldbus protocols to be added without influencing the interfaces themselves. Only the new XML schemas need be defined for the respective fieldbus as a kind of contract between the DTMs and the hosting applications. The first release of FDT includes XML schemas for HART and PROFIBUS devices. FDT has no impact on the devices itself and therefore may also be used for the large installed base. The field instrument manufacturer provides a DTM for each field device. The following functions are covered by the DTM. The manufacturer will optimize these functions with respect to the special features of the instrument: User interface Verification of instrument parameters under consideration of the devices business rules User guidance for complex configuration, commissioning, or calibration procedures, if needed Read and write of parameters Device specific diagnostics functions Generating device instance specific documentation The above listed features depend on the inherent functionality of the field devices. A DTM covers at least one device, but could also handle classes of instruments. For devices that are not yet accompanied by a specific DTM, generic DTMs or templates can be implemented that allow for integration of devices into FDT environments based on the traditional means like DDs, GSD files or manually entered data. Information about the hosting applications the DTM is going to run in is not needed when building a DTM. The DTM implements its communication methods as if it were directly connected to the device. Similarly, from the DTMs point of view, the storage of device instance data is encapsulated by an inter-

face. So, the DTM does not need to care about the different types of databases or file systems that may be used to store data in a system environment. Accordingly, the hosting application, or Frame Application, as it is called in FDT terminology, has the following tasks: Storing and retrieving all device instance data for the DTM Versioning and archiving DTM data sets Guaranteeing plant wide data consistency Controlling multi user and client server operation on a device Establishing communication to the field device and routing the data through different communication hierarchies The support of data routing is defined by FDT in a very generic way. Nested Communication allows arbitrarily deep communication hierarchies to be built up. This can even include communication protocols that are only supported by field devices with gateway functionality, and that are unknown to the control system itself. FDT distinguishes between different user rights and application contexts. In this way, use of DTMs is suitable for more than just control system engineering tools. DTMs can be applied in any kind of Frame Application, such as operator panels or maintenance systems. By calling the DTM with appropriate user rights and application ID, it is possible to limit the accessible functionality according to the given context. For example, an operator can be prevented from changing the configuration of a device or instantiating new functions blocks, yet still be allowed to adapt limits or other parameters with the DTM. Due to its architecture and remarkable flexibility, the FDT/DTM technology fits ideally into the concepts behind modern, efficient system tools. The DTM is a device driver object that represents all device functionality and information, and that makes this information accessible in a well-defined way from all levels of applications within a process control system. FDT supports the duplication of device instance data. Thus it supports the engineering based on template solutions. In addition, FDT provides a uniform handling for devices using different communication protocols. With the seamless integration of field devices via FDT, the cumbersome data exchange between different independent tools becomes obsolete. The DTMs enable field device features which previously could not be completely utilized. Existing functional and technological limitations are overridden.

BENEFITS
Beyond the support of efficient field device management methods, users can gain further benefits from the use of FDT. The customized user interfaces of DTMs will help plant engineers to more efficiently utilize all the special features of our modern, fieldbus-enabled devices. Instead of browsing through lists with hundreds of parameters, and setting a handful of those parameters to invoke a desired function, plant engineers can save time and money by merely selecting the required function from a menu. The DTM carries out all necessary settings automatically and provides options for tuning the relevant parameters. Of course, the full set of parameters will still be available if somebody needs to perform a fine-tuning on selective parameters. For most of the standard applications however, the menu options will be sufficient. The user is guided through the set-up process by the DTM, thus time-consuming studying of user manuals and special training are reduced. In the commissioning phase, DTMs download the device configuration and help to perform loop checks easily from the control room. For instance, the output current of a HART transmitter can be set to con-

stant current mode and be modified by the HART devices DTM. The commissioning engineer can tune the value directly in the device and check to see that the output is correctly propagated to the consumers in the system and correctly treated by the different signal conversions. With the DTM of the actuator connected to the respective control loop, the engineer can read information directly from the device and thus verify the proper operation of the complete loop from the transmitter to the actuator. Also during plant operation, when devices must be diagnosed and maintained, DTMs can offer improved levels of support to the user. For example, a plant operator receives an error message from a device on the alarm page and calls the DTM for diagnostics. As the DTM is not restricted to individual or collective error messages, it can read additional parameters from the device and perform comparisons and calculations to provide an in-depth failure analysis complete with recommendations for remedial actions. This can significantly reduce plant downtime, as maintenance personnel can immediately take the appropriate measures without another iteration of failure analysis in the field. Early experiences implementing the FDT technology in projects with products based on a pre-standard version of FDT have been most positive. The most impressive reference is a plant of BASF in Germany which is cited to be one of the largest fieldbus installations in Europe. It is comprised of more than 10,000 I/Os with a mixed installation of HART and PROFIBUS devices. [6] The plant was successfully engineered and commissioned with the aid of FDT. Long-term observations will prove the cost savings that are obtained by the additional information from the field that is made available by DTMs.

FIG. 6 COMPLETE LIVECYCLE SUPPORT WITH FDT

The application of FDT is not only beneficial for the plant operator but also for device manufacturers. In the future, instead of creating and maintaining device descriptions for several different tools, device manufacturers will only need to provide a DTM. The DTM will be built once, and will run everywhere. On the one hand, this reduces costs with respect to the obsolescence of libraries of different DDs and by supporting different ways of integration. On the other, the device manufacturer can use the DTM to empower his devices features, thus differentiating them from competitors. If FDT is used in all systems it is automatically ensured that the device is always supported in the optimal way. In addition, since a DTM is a software component, its development is supported by software development kits. As the complexity of devices increases, features like tracing, debugging, and in-debug code changes that are not supported in the DD environment will ease development and make it more efficient.

SUMMARY
The question of integrated, efficient device configuration and operation in a control system is now answered by the FDT technology. This fieldbus-independent concept makes integrating field devices into control systems as simple as adding new printers to computer networks by just installing a new driver. FDT goes beyond the currently applied technology of device descriptions. Instead of a device description, the device vendor supplies a software component (the DTM) with the device. The DTM brings all necessary information to the system via standardized Graphical User Interfaces, or GUIs. It also provides user interfaces for device configuration, commissioning, diagnostics, maintenance, etc. These GUIs are perfectly adapted to the respective device so that handling the device is easier and more efficient throughout the entire lifecycle. As FDT is not only beneficial for the plant operator but also for the device manufacturer, more device manufacturers are becoming attracted to FDT and have started implementing products. First product releases based on the FDT standard are expected at the end of 2001.

REFERENCES
[1] Nicklaus, E.; Fu, H.-P.: Online-Asset Management (in German), atp, Munich Germany, Vol. 42 (2000), No. 5, May 2000, pp 30 [2] Niemann, K.-H., Laubenstein, A., Lohbeck, A.: Effects of fieldbus integration on the range of functions of control systems, Proceedings of Fachtagung verteilte Automatisierung Modelle und Methoden fr Entwurf, Verifikation, Engineering und Instrumentierung, Dschner, Ch. (Ed.), Otto von Guericke University Magdeburg, Magdeburg, Germany, March 22nd-23rd, 2000, pp 206-222 [3] Hempen, U.; Niemann, K.-H.: Small revolution in process automation (in German), Elektronik, Poing, Germany, Vol. 48, No. 21 (1999), October 19th, 1999, pp 66-72

[4] Bruns, H.; Hempen, U.; Ott, W.; Vahldieck, R.; Niemann, K.-H.: PROFIBUS goes Microsoft Vendor independent integration of field devices in engineering tools; in: Dietrich, D.; Neumann, P.; Schweinzer, H. (Ed.): Fieldbus Technology, Systems Integration, Networking and Engineering. Springer Verlag, Vienna, New York, 1999, pp 230 238. [5] PROFIBUS Nutzerorganisation e.V.: Specification for PROFIBUS Device Description and Device Integration Volume 3: FDT V1.1, Karlsruhe, Germany, November 2000 [6] Bollmeyer, S.: FDT in practice- The largest industrial PROFIBUS installation in the world, AMD&C International Magazine, Nuernberg, Germany, No. 10/99, page 21