Unlocking the potential of fieldbus: FDT, EDDL work together in harmony
Fieldbus advancements certainly hold great promise for reducing costs and improving efficiency in today’s chemical industry as well as other process plants. But even the most dedicated fieldbus adopters in these plants often struggle to configure, operate and maintain their fieldbus devices and systems.
Fieldbus advancements certainly hold great promise for reducing costs and improving efficiency in today’s chemical industry as well as other process plants. But even the most dedicated fieldbus adopters in these plants often struggle to configure, operate and maintain their fieldbus devices and systems. Two technologies have emerged to help remove this potential barrier to fieldbus acceptance: EDDL (electronic device description language) and FDT.
There’s been an unfortunate misperception in the marketplace that EDDL and FDT are competing fieldbus support technologies and that one or the other would eventually 'win’ out. EDDL and FDT are, in fact, complementary technologies that can work in partnership to dramatically simplify the care and feeding of fieldbus devices over their lifecycle.
From a purely technical perspective, EDDL and FDT are very different. One is a descriptive language. The other is an intelligent interface that simplifies integration of Windows programs into control systems. The confusion probably arises because both EDDL and FDT can be used to deploy device-related user interfaces that might appear, at first glance, to have similar capabilities. Some overly enthusiastic proponents of both technologies also have made somewhat exaggerated claims that their particular technology choice can offer all things to all people.
With actual hands-on experience comes the knowledge that a single technology is incapable of fulfilling all fieldbus system configuration, operation and support requirements. By combining the capabilities of both FDT and EDDL into one fieldbus system, users can realize the many benefits that digital fieldbus technology can offer in today’s process plants.
A new perspective on fieldbus
When Invensys began developing its new Field Device Manager for the company’s Foxboro I/A Series distributed control system, product planners examined the capabilities of field devices and the demands they place on the host control system. They looked at the tasks customers would need to perform over the plant lifecycle and followed a system philosophy based on maximizing integration of both end-user and vendor knowledge.
With the engineering of any new system, comes an extensive list of difficult tasks. Compounding the challenge is the large number of devices that must be incorporated, frequently 50,000 or more. Time and consistency are top priorities (Fig. 1).
The first job is defining the device types in the control system, which is clearly the job of EDDL and the primary reason for the existence of device description files. These DD files indicate the types of function blocks present in a device, the device parameters, parameter data types, enumerations, etc. %%MDASSML%% without the need to have a device present.
The DD file is used to create a template for each device type and device application. The EDDL language does a great job of defining the available parameters and a few of their attributes (writeable, data type, etc.). The EDDL does not, however, deliver other, much needed system information. Using EDDL as the basis for offline engineering and template generation also allows for a consistent engineering interface for multiple device types. EDDL files are interpreted on-the-fly and their information used to build and customize the interface used by the engineers as they are configuring templates and device instances.
Once the device types are defined, instances of devices are defined in the system topology. Once the template is defined, information from the DD files simply becomes available to the many engineering tool components.
Device instances take on the configuration choices made in the device template. If there are parameter adjustments to be made in an instance, the connection to the template remains intact, allowing later adjustments to large numbers of devices to be made.
For FOUNDATION fieldbus systems, DD files are also used to configure the system control strategy. Device function blocks are represented to the engineer exactly as they are defined in the DD file.
Once the system has been delivered to the site, it is time to bring all of those devices to life. For relatively simple devices, this might just be a matter of connecting the device and downloading its configuration. The DD file tells how to get a specific parameter to the right location in the device.
More complex devices, however, require more commissioning effort. Valve positioners, for example, must be calibrated to match the positioner to its actuator and valve. EDDL supports a feature called 'methods’ that can help with this. Methods are primitive scripts that can present text prompts to the commissioning technician as they follow the process that was defined by the device vendor in the DD file. Methods have been used with reasonable success for many years. A much better way to perform complex commissioning, however, is with a custom FDT Device Type Manager (DTM) that is written by the device vendor (Fig. 2).
For some aspects of device commissioning and maintenance, a custom user interface to a device type is best. Consistency of interface across device types is important during the engineering phase to minimize training and mistakes. In that phase of the lifecycle, engineers work with individual parameters, and the devices are not present.
Once the device is online, however, the instrument technician can benefit from a custom display designed to present the information specific to that device type that is useful for the function being performed. This is the domain of the DTM.
For the positioner example, a calibration screen on the DTM might be called up that allows the device’s calibration function to be started. The DTM can then monitor the calibration progress graphically, indicate and explain any issues that arise and then graphically present the results. Help screens can be made available in context to the activity that guide the user and help to interpret results. These results can be stored in a database where they can be evaluated over subsequent calibrations and compared to other positioners. A calibration report can be generated by the DTM and printed (Fig. 3).
Once the system is up and running, subjects such as engineering and commissioning rapidly become a distant memory. Attention turns to keeping the plant running, minimizing maintenance and down time, minimizing staffing and training requirements and creating value. FDT and EDDL both play a significant role in the operation of the plant.
When everything is running smoothly, device parameters being monitored are displayed in the format specified in the DD file. Device condition data is interpreted and converted to human-readable information based on the contents of the DD file. Simple adjustments to device parameters are handled by DD-based tools.
These functions are performed by the standard suite of system tools (HMI, system management, engineering, etc.), which are supplied information from the DD files. It gets more interesting when it is time to maintain the devices or to optimize their performance.
When a fieldbus device self-detects a problem, it has the capability to inform the system. The system uses information from the DD file to filter the event message and route it to the appropriate recipient. These messages can be very general as in 'Needs maintenance now’ or 'Needs maintenance soon.’
To understand precisely what is wrong, a DTM can be used to quickly analyze the problem. Screens in some DTMs range from simple lists of red and green diagnostic status indicators to complex analysis of challenging problems. Some DTMs offer help screens so the instrument engineer can solve the problem rapidly. DTMs can also allow the storage of historical data so the user can see if this problem has happened before to this device or even others like it in the plant.
Many devices simply do not have the processing power to perform their own self-analysis. In this case, a DTM is critical to understanding a device problem. If a device misbehaves, the DTM can be used to read many parameters from the device and execute the algorithms necessary to combine the parameters into the useful information needed to determine if a device must be replaced.
Historically, replacement of a device is one of the most challenging issues faced in a fieldbus system. The engineers that configured and commissioned the system are long gone and with them their knowledge of the devices. The staff that is present to perform maintenance tasks might lack the training to understand the role of a device or how it should be configured. This is another moment when the value of the device templates becomes clear.
The template defines all of the parameter settings and the rules for download, including parameter download list and parameter order and timing. The system sets the required parameters using information from the DD file. If more work such as in-situ calibration is necessary, the template can contain full notes on the necessary steps to complete the process. This can go as far as pictures or videos attached to the template.
Why this architecture?
While a handful of automation system and instrument companies still publicly favor one fieldbus support technology over the other, most would privately admit that EDDL %%MDASSML%% even with its recent enhancements %%MDASSML%% is not capable of delivering all the needed value from a device. And while it is capable of enabling systems to deliver open features never before available, FDT was never intended to be a device description technology.
Experience and some recent academic research on the subject of effective field device management lead to a clear conclusion. Control systems need to support both a descriptive language such as DD and an application integration technology such as FDT to deliver the full value of contemporary intelligent field devices. For today and into the foreseeable future, these two proven technologies are helping to make fieldbus easier, and reducing costs in several areas of plant operations.
Scott Bump is the director of Fieldbus Technology Development at Invensys Process Systems in Foxboro, MA. He is a member of the executive committee of the Fieldbus Foundation and a member of the executive committee of the FDT Group, AISBL.
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.