Field Device Integration opens up a new era in fieldbus technology says Neil Shah from ABB Control Technologies.
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 specialised Windows-based FDT features and complex graphical representation.
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 per cent of industrial process automation. Obviously these three protocols hold a lot of importance and potential in improving and optimising 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 fully-fledged 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 standardisation, 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.
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. Specifications and recommendations from the manufacturer don’t solve these issues, leading to
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 optimised 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.
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 analyse 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 standardisation. 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 and 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.
Today, the user finds a host of tools – from basic freeware to high-priced fully integrated tools. Most often the user would like to employ the same tool in different ways. For example, a field technician standing next to transmitter would want a lightweight, quick and simple tool capable of online communication with the device–no more. When in the lab the same technician requires much more functionality, such as diagnostics, calibration, loop-checking, and device exchange. The point: scalability and flexibility become important criteria when selecting a tool to satisfy different uses. FDI is about to initiate the rise of a new era in fieldbus technology. Users should note carefully how the providers of device management tools benefit from the new standard.