Introduction
With the recent public release of the Field Device Integration (FDI) specification, instrument and automation manufacturers can now develop compatible products and host systems for managing field devices. For the user, the specification combines the attributes of competing Device Integration technologies: EDDL and FDT/DTM. A key objective of the specification is to combine the simplicity of the text-based DD technology with the flexibility of specialized Windows-based FDT features and complex graphical representation.
This article first delves into the key issues faced by users of device management tools and how FDI attempts to answer them. The latter part of the article looks at issues where FDI may fall short.
Fieldbus device management tools
Today, more than 30 open and proprietary communication protocols serve industrial/process automation. Three, HART, PROFIBUS and FOUNDATION Fieldbus, account for 90% of industrial process automation. Obviously these three protocols hold a lot of importance and potential in improving and optimizing plant operations and enterprise asset management.
Since these three protocols form the basis for large improvement potential, they play a key role in maintenance and upkeep of field instruments. The tools for commissioning, calibrating, diagnosing, and maintaining these instruments must be capable of taking full advantage of the fieldbus communication protocols. Further, the tools must use these advantages in the simplest possible way, keeping the end user in mind.
More than one type of user of these tools operates at a single plant location. For example, an instrument service technician who is diagnosing a device requires only online communication with the device. A commissioning engineer may want to first configure the device offline and then download the data to the device. Instrument engineers and maintenance managers would want access to an overview of device health. So the management tool for the field device should simultaneously and simply serve to all these users.
Key end-user issues
Today, each major process automation manufacturer has product portfolios ranging from instruments to full-fledge control systems. Most also offer their own tools for managing field devices. The same device may have different device drivers for different tools.
Despite much standardization, the device drivers supplied for one system do not function, look, and feel the same way in other systems. So the user has to maintain different drivers for different tools for the same underlying device. This is also a problem for instrumentation manufacturers as they have to execute tests of their device drivers with multiple device management tools.
The FDI device package will serve all devices and tools. Each device comes with an FDI package used by all the tools or systems, including standalone PCs, field instruments, and process control and automation systems. The FDI device package, Fig. 1, makes sure all device management tools function with Devices without any issues, regardless of the manufacturer. Each host interprets a device driver slightly differently to fit into the layout of its user interface (UI) layout.
Device vendors typically design their driver for one preferred tool. Although the driver may adapt to the other tools, most often it still does so imperfectly.
The Common Host Components consist of the EDD Engine and the UI Engine. All FDI device packages will be tested and approved with reference to the FDI reference host containing the Common Host Components. These components will be available for implementation to host system manufacturers for their tools. The usage of Common Host Components ensures that the representation of the FDI Device Package is similar in various tools. Importantly, since the device package developers will use the FDI Reference host during product development, the representation of graphs, images, text, etc. in the device package will be highly optimized as desired by the instrument vendor. Instrument and host system manufacturers will not need to test their device drivers in various tools.
One of the most irritating issues for the end user has been the inconsistent look and feel as well as inconsistent behavior of a field device's driver in different host systems. Also, the drivers for different devices in the same host system may also behave differently.
The major factors contributing to this situation are:
• Each host fits a device description into its own user interface architecture.
• Each device manufacturer has its own understanding about what tool parameters are important for a user.
FDI has undertaken activities that to a large extent minimize these inconsistencies. A usability style guide elaborately documents several aspects of user interface design. The guide provides examples of source code or sketches of the graphical representation of controls or frames. It also standardizes labels. For example entry level menus like Device Settings, Diagnostics, Operate and Action become labels like "Apply", "Cancel", "Next", etc. Lastly, the guide documents translations in key languages (German, French, Spanish, Italian, Chinese, Portuguese, Japanese and Russian).
In addition, the FDI Device Packages will be based on the Harmonized EDDL applicable for all the three major protocols: HART, PROFIBUS and FOUNDATION Fieldbus. All new EDDs must use the updated and optimized IEC 61804-3 standard.The "User Views" concept and Harmonization of EDDL have been key requirements from the User Association of Automation Technology in Process Industries (NAMUR).
Locked valuable device information
In the initial life cycle of a plant, most users are content with employing the device information within the tool. Sooner or later, however, they get into situations where the valuable information from the device needs to be made available to external tools or systems. They may need to analyze the field device conditions, failures, and calibration data or they just think that another specialized tool would benefit from access to a particular device.
Most device management tools do not allow transparent and easy access to this valuable information. Even if the tool does allow access, a complex series of steps or additional hardware/software may be required. Technologies like OPC-Unified Architecture play an effective role in easily opening up this information to third party tools.
The usage of the standard interface OPC-UA in FDI hosts allows easy access from other applications.
• Applications can be designed and developed without any support of the supplier of FDI host
• OPC-UA services supported by the FDI server allow safe and secure access to the Device or to stored offline data
• Generic OPC-UA clients can be maintenance tools or Manufacturing Execution Systems (MES) or Enterprise
Resource Planning (ERP) systems
Of course not all existing devices will have FDI Device Packages immediately. It will take some time before a sizeable number of FDI Device Packages are available in the market. But users need not worry since FDI will support existing device drivers.
Some unanswered issues
Will FDI answer every issue of all the users of fieldbus device management tools? Not quite. A few areas cannot be simply answered by a specification or standardization. Problem issues may include procuring and installing the tool, non-intuitive tools, inadequate or overly complex tools, and inflexible and non-scalable tools. The first step sometimes becomes the most time consuming step. Many tools have a heavy footprint that makes them time consuming to download and install. Many tools have .NET and/or SQL as pre-requisites, increasing installation time.
Additionally, the device drivers must be installed or imported, and updated to the latest version. Additional steps include installing & configuring the modem driver, which varies from vendor to vendor. Then most tools need a manual catalog update. Some tools require the enabling or activation of license. Lastly a few more clicks enable communication, scan, or go-live with the device.
Often, the user just wants to configure the same basic parameters (for example Tag, Range, Unit) or execute the same parameters or functions such as zero settings over and over again. Most tools do not support such tasks. Even if they do, many steps may be involved, increasing user frustration.
by Neil Shah, ABB Control Technologies
Print this page
