Using HART with asset management systems
Since it’s the most broadly deployed smart device platform, is HART the right choice for your plant? Here are some considerations for end users.
Implementing an asset management system that covers field instrumentation in a process plant environment requires some type of smart device platform. Since most modern field devices provide HART communication capability in addition to the analog process variable, plants may have to weigh approaches employing either traditional or integrated HART I/O as part of the decision to move to an instrument asset management system.
This article examines some key questions for end users seeking to optimize the lifecycle performance of their instrumentation assets. Is HART information sufficient for a comprehensive asset management program? Is native HART-enabled I/O a necessity, or are there practical ways to use it in a legacy I/O environment? Should users expect to make substantial hardware changes to have something that works well?
Increasingly, manufacturers are turning to instrument asset management systems (IAMS) to improve their process efficiency, reduce maintenance requirements, and enhance overall productivity. Plants can achieve significant reductions in operating costs and production downtime as a result of implementing an effective asset management strategy. Since a large percentage of manufacturing revenues are budgeted for maintenance, these savings contribute significantly to a company's bottom line.
As soon as plant equipment is commissioned, it is subject to degradation. The process, human interaction, and time all conspire to corrupt the function of process equipment and associated field devices. To control and slow the decline, plant maintenance groups are responsible for the operational oversight and timely repair of equipment. Their challenge is to keep installed assets performing while also reducing the resources and personnel required for the maintenance function. A local operator interface or handheld communicator can be used for temporary on-site interaction with smart field instrumentation devices. What’s needed is a means to interface with field instruments on a continuous plant-wide basis to capture preventative maintenance information and conduct appropriate remote servicing activities. That’s the basic function of an IAMS.
Understanding the technology
In recent years, field devices and equipment supporting digital technologies have proven to provide benefits to the typical process plant operation. Digital devices offer a great deal of data about the operating environment. This data can be utilized by applications that prevent losses or disruptions, enhance quality and reliability, and reduce maintenance costs.
One of the reasons for the growth and popularity of digital device technology has been the broad adoption of the HART Communications protocol, which provides an open standard for digitally enhanced 4-20 mA communication with smart field instruments. Most modern distributed control system (DCS) solutions include integrated HART I/O modules that connect to smart devices. This I/O is essentially hybrid, because part of it handles the conventional 4-20 mA signal—and looks very much like the old non-HART I/O—while the other part handles the digitally encoded HART signal.
In any DCS, integrating an asset management system basically requires a means of connecting the asset management software to the HART I/O and on to the devices. While the basic protocol is pretty much the same in all control systems, the mechanism for this integration is normally proprietary, with each vendor choosing an implementation approach that works best for them. There’s a lot of room for some “secret sauce” to make better use of the limited bandwidth available with the HART protocol.
Despite the lack of an open standard for integrating HART I/O, there are certain features automation end users expect in all DCS platforms. For example, the I/O should be able to use the instrument range information from the smart HART side to tell the analog side automatically how to range the 4-20 mA output. In addition, standard HART information such as engineering units, digital process variables, and alarm information should be available to the DCS for control purposes and accessible from every field instrument without any knowledge of the specifics of the device. The HART protocol has universal commands for obtaining this information.
The rest of the unique information in a smart instrument used for configuration, calibration, troubleshooting, maintenance, and diagnostics is described in its Device Description (DD) files. DD technology has been refined to include useful graphical and organizational constructs, and this refinement is referred to as EDDL, or Electronic Device Description Language. DDs are binary files containing an electronic description of parameters and functions needed by a host application to communicate with the device. Instrumentation vendors use specific programming tools and a tokenizer to create the encoded DD files. The software or tools that make use of the DD information are generally considered to be the asset management system, which is primarily of interest to instrument maintenance technicians.
Many automation equipment suppliers now use FDT/DTM (Field Device Tool/Device Type Manager) technology so they can present more meaningful device information. DTMs are software components that contain device-specific data, functions, and logic elements. They can range from a simple graphical user interface for setting device parameters to highly sophisticated applications that perform complex calculations for diagnostics and maintenance purposes, or implement complex business logic for device calibration. The DTM also contains interfaces to enable communication with the connected system or tool.
Device suppliers are able to embed intelligence in a DTM in a way that is very difficult to accomplish with DD files, such as a number of graphical constructs that cannot be expressed within DD technology. Moreover, the DTM is device and revision specific so that it has knowledge about the particular version of each device on the control network. It is interesting that the automation industry attaches so much importance to the IAMS, when it is the contents of the DTM that really have value for the end-user. The IAMS is simply a container enabling communications to the devices, a way to organize information, as well as a path to the technician or operator.
Issues to consider
While FDT/DTM technology offers some very attractive benefits, there are practical caveats and cautions that end users should be aware of. First, and of greatest concern, is the fact that a DTM must be installed in every client (frame) where it is needed. So, an end user with 10 clients spread around the plant and DTM packages from 10 different vendors must perform at least 100 installations—maybe more if a given vendor has several DTM packages. Combine that with multiple revisions available for given DTM packages, and the result can be a significant maintenance problem. A future revision of the FDM specification (Rev 2.0) promises to allow DTMs to be loaded to a server and deployed to the clients, but for now, this is how DTMs must be managed. By contrast, it’s read-it-and-forget-it for most systems using DDs.
Since DTMs are Microsoft Windows programs, they are dependent upon Windows versions, supporting infrastructure such as DOT NET, programming tools, and the specific frame revisions level. A DTM that works in one environment may not have been tested in another. As such, the end user must be careful and check all of the specifications provided by the DTM vendor. When in doubt, test it first.
Additionally, DTMs sometimes behave differently in monolithic or stand-alone frames like PactWare, from the way they act in a DCS environment. With a stand-alone frame, the path to the device can be relatively short and simple with no bandwidth restriction. A DCS must carefully manage the limited available bandwidth, especially for HART devices. A DTM doesn’t know what environment it is in, and so it has no way of knowing how to wait in line. The result can be poor apparent performance in a DCS environment. Device vendors are becoming savvier about this issue, but the end user must still watch out for the occasional offender.
Lastly, some DTMs are fragile and can crash, even bringing the client down with them. This is generally not catastrophic, but it can be quite annoying. DD technology may not be perfect, but at this stage of the game, it has proven more mature and easier to manage.
For the last several years, work has been going on to unify DD and FDT/DTM technologies and produce a single solution for Field Device Integration (FDI). FDI Cooperation, LLC, was formed in response to end-user demands for easier integration of automation and control devices across industrial networks. While it is apparent this effort will mean a lot of work on all sides of the smart device technology supply chain, it is yet to be seen how transparent the coming changes will be to end users. DD files and DTMs don’t go away, and backwards compatibility is being promised, which is quite reassuring.
Choices facing end users
Process manufacturers seeking to implement a comprehensive instrument asset management solution based on HART technology are faced with a number of important choices. For example, can plants utilize a solution with smart field devices connected to a control system that doesn’t fully support HART I/O?
In most cases, operations with legacy DCS platforms that want to make use of an IAMS must rely on external HART multiplexers, or muxs, to bring digital HART messages into the IAMS. The multiplexer is used to strip off the digital HART message and provide it to the IAMS software package. The multiplexer hardware module routes the HART analog and digital signals to two separate communication pathways. The standard analog 4-20 mA signal is routed to a standard, non-HART enabled, analog input module while the digital signal passes through the multiplexer hardware and is transported over an RS-485 network to the instrument management system.
Experience has shown that HART multiplexers can offer extremely flexible and reliable systems for handling anything from a handful to thousands of HART devices on a single network. Frequently, the mux approach is the only way to bring older control systems forward unless the plant wants to use handhelds or upgrade the DCS, which often is not an option. For some operations, however, it’s not worth the investment.
The preferred integration solution, as implemented by current generation DCS technology, employs HART-enabled I/O modules supporting HART digital device data along with analog 4-20 mA data. With this technology, digital device data from HART-enabled I/O is treated alongside the analog process variable data, which is tightly integrated into the control system environment. This enables the use of additional process variables (e.g., PV, SV, TV and FV), range information, device identification information, and the device status (general and device-specific) as part of the control strategy.
With HART-enabled I/O, device diagnostics can be tightly integrated into the DCS alarm/event subsystem and asset management applications. There is no need for separate instrument monitoring systems or software packages. Instrument alarming is either handled in the software package used for configuration, troubleshooting, and diagnostics, or, preferably, in the control system itself, where alarms can be sequestered for maintenance technicians.
Some automation suppliers have developed robust device management solutions designed to communicate with HART devices connected to HART-enabled I/O as well as HART devices connected to hardware multiplexers, remote I/O systems, and HART modems. These solutions provide plant instrument engineers, technicians, and maintenance personnel with an optimized environment that simplifies tasks and enables remote device management, whereby instruments that have faults or need diagnosis are automatically identified and classified. Integrated with the safety system HART I/O, for example, these solutions use live data from connected devices to establish database records and assign templates so maintenance personnel can compare configuration of one device with another device, or historical configuration of the same device or another device.
Device management solutions can employ a technique known as “mux monitoring” to bring non-integrated HART data to the control room. Mux monitoring allows plant personnel to monitor HART devices on hardware multiplexer/remote I/O networks and provide alerts from these devices to the DCS alarm and event system. This approach simplifies migration from legacy control systems to newer DCS platforms while retaining installed field devices and the value of smart instrumentation. Simplified export-import capabilities make migration of existing databases much easier and less intensive.
Companies around the world have begun formal programs to make use of the diagnostic data in their HART smart instruments. HART field device responses contain valuable information regarding the device's health, and having this data sent with every message provides plant personnel with confidence in the integrity of the process measurement along with immediate notification of any problem.
Despite ongoing advancements in intelligent instrumentation, such as those delivered by DDs and DTMs, the value of smart devices cannot be realized without a capable instrument asset management system. From a maintenance perspective, a HART-enabled asset management solution allows an entire plant to be monitored from a single location, with fault diagnosis often performed remotely. Many HART instruments provide additional status information that can be used for predictive maintenance and replacement of equipment on an as-needed basis. This results in reduced maintenance trips, fewer process disruptions, and high system availability.
Yingst is a senior principal product manager for Honeywell Process Solutions.
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.