Fieldbus instruments support a larger vision
Intelligence moves plant from preventive maintenance to predictive maintenance.
By Laura Thomas, Jay Kalinowski, Curtis Cook, and Lou Verduzco
Applying fieldbus technology to a water treatment plant requires a shift from traditional instrumentation and electrical design methods.
Orange County Water District (OCWD) is creating a new, advanced water treatment facility (AWTF) to replenish the groundwater in the lower Santa Ana River basin with reclaimed wastewater effluent from the neighboring Orange County Sanitation District treatment plant.
This project develops a new, cost-effective source of reliable, high-quality potable water to refill the Orange County groundwater basin and expand the existing seawater intrusion barrier. However, the groundwater replenishment (GWR) system will significantly increase the complexity of managing, operating, and maintaining OCWD water production facilities.
Orange County Water District had the opportunity and the challenge of developing a control system that would enable it to change its approach to operations and maintenance. OCWD's vision of a control system architecture that would enhance its asset management program led to the decision to use fieldbus technology and distributed control. The preliminary design phase of the project relied heavily on input from the manufacturers of the process equipment. The process included microfiltration (MF), reverse osmosis, and ultraviolet disinfection. The traditional controls approach with these technologies was to allow the manufacturer to provide all control system programming on a programmable logic controller (PLC) system architecture using ladder logic, and then turn over the whole system to the owner. OCWD had to weigh the desire to have a fieldbus-based distributed control system (DCS) against the major equipment manufacturer's lack of standard products using this type of system.
OCWD made the decision to preselect a DCS, develop software and hardware standards, and have all systems developed using those standards. Before preselecting a DCS, OCWD decided to use Foundation fieldbus for instrumentation and DeviceNet for motor control centers and variable frequency drives. Classic I/O would serve as necessary. After a preselection process, OCWD selected Emerson Process Management's DeltaV system.
The organization had to develop system design standards, software design standards, and hardware design standards to ensure uniformity and, ultimately, maintainability of the system. In addition, OCWD developed a "pilot" project called the initial microfiltration facility (IMF) to use DeltaV on the MF process to allow operations staff to get familiar with the new control system on a much smaller scale than the final plant. The IMF is in the final stages of start-up.
This article will show design considerations such as selection and application of the fieldbus, the process and instrumentation diagram (P&ID) presentation, segment diagram development, and instrument and equipment specifications. Here is an analysis of the costs, benefits, and challenges associated with using fieldbus technology. The benefits include reduced wiring costs, greater access to diagnostic data, and the ability to support predictive maintenance procedures. The challenges of using a new technology include limited availability of experienced designers and integrators, limited fieldbus products, and limited manufacturer support of fieldbus products.
Applying fieldbus technology to a water treatment plant requires a shift from traditional instrumentation and electrical design methods. P&IDs, loop diagrams, conduit routing, and equipment and instrument specifications end up significantly different through the use of fieldbus technology. One must develop fieldbus design standards early and strictly adhere to those standards. In addition, the work flow process becomes more challenging, and a higher level of coordination between the instrumentation and electrical disciplines is required.
Selection and application of fieldbuses: The most critical design decision is the selection of specific fieldbuses and their application in the design. For the GWR system project, bus selection depended on the buses' technical strengths and prevalent application in process plants. This ensured maximum performance and the greatest number of available, compatible field devices. As questions arose concerning the use of these buses, it was helpful to have developed some "big picture" constraints in advance:
- Foundation fieldbus would handle transmitters, analyzers, and control valves. Its application would favor analog signal processing, with the exception of open/close valves.
- Foundation fieldbus control logic would reside in the process controllers (not in field devices), but devices that interact to form a traditional transmitter and control valve proportional, integral, derivative (PID) algorithm loop would be assigned to the same segment for possible future migration of PID control to the field device.
- DeviceNet was to handle smart motor starters, variable frequency drives (VFDs), power monitors, and remote clusters of hardwired signals. Its application would favor discrete signal processing, with the exception of VFDs.
- The control system would be limited to two types of fieldbuses.
Slight modifications in approach can take place as the design progresses, but changes to these fundamental criteria can severely affect design schedule and costs.
P&ID presentation of fieldbus interfaces: Neither ANSI/ISA-5.1-1984 (R1992) "Instrumentation Symbols and Identification" nor ISA-5.3-1983 "Graphic Symbols for Distributed Control/Shared Display Instrumentation, Logic and Computer Systems" addresses fieldbus interface or instrument line symbols. For the GWR system project, the design team found it helpful to distinguish data flow on fieldbuses from data flow between controllers and human-machine interface (HMI) devices. The team used the standard software or data link symbol on P&IDs to show control network communications between controllers and HMI devices, and they developed new symbols for communication over Foun-dation fieldbus and Device-Net (generically called "motor bus"). In addition, the team developed bus interface symbols to depict which field devices were "smart" and which bus they were associated with.
Besides the symbols and line types, the team decided not to depict relationships between devices and bus segments on P&IDs. This allowed free formatting of P&IDs that communicate the process and control concepts rather than physical connections. Physical connections show up on the loop segment diagrams, electrical plans, conduit and circuit schedules, and in the I/O list.
To simplify the presentation of multiple data values associated with each piece of equipment and to standardize controller and operator interface software programming methods, the design extensively uses standard function templates per device or logic operation.
Loop diagram development: Although traditionally left up to the contractor during construction, the GWR system plant design included instrument loop diagrams. These diagrams were renamed "loop segment diagrams" and were limited to physical connections between devices on Foundation fieldbus and DeviceNet networks. The contractor will further develop these diagrams and supplement traditional loop diagrams for hardwired devices during construction. With a fieldbus-based control system, the team must develop these diagrams during design, because rules regarding segment loading and separation of parallel equipment must apply during the device assignment to fieldbuses, followed by the conduit and wire design (see "Electrical design" below).
ANSI/ISA-5.4-1991 "Instrument Loop Diagrams" does not specifically address fieldbus segments, so the design team developed diagrams showing overall bus topology and individual segments with major sections for field devices, panel-mounted fieldbus hubs, or I/O bricks and process controller connections. The loop segment diagrams developed so as to show specific models of Foundation fieldbus passive hubs, DeviceNet modular I/O modules, taps, and terminators. Because the actual bus devices could vary based on performance specifications and a competitive bid process, the team added notes to the drawings stating the devices shown are for presentation purposes and the contractor must update the diagrams based on the final selected components.
Instrument and equipment specifications: Because Foundation fieldbus is not yet prevalent in the water industry, many common instrument types are not available with Foundation fieldbus capability (e.g., chlorine and turbidity analyzers). For others, there is currently only one manufacturer available (e.g., ultrasonic level transmitters and ultrasonic flow transmitters). In each case, the team weighed its desire for additional data and wire and conduit savings against the inability to write a sole source specification and the lack of familiarity with the only available device. In some cases, current-to-fieldbus converters worked to achieve the conduit and wire savings. The converters can smoothly transition to full fieldbus capability when a device becomes available in the future.
When specifying field devices, consideration goes to physical connections, measurement accuracy, and user interface. For fieldbus devices, additional consideration must go to the level of effort required to configure the device and the device's ability to perform on the fieldbus segment. For the GWR system project, several field devices were bench tested before the specifications became final. These tests revealed some weaknesses in performance and vendor support, but also verified the performance of new devices that had not yet passed certification by the fieldbus organizations or by the control system manufacturer.
One must modify traditional testing methods for fieldbus-based control systems. Testing requirements also change for fieldbus-based control systems. It is most important to factory test interconnected field devices before shipment to the plant site to identify and correct any configuration, performance, or data flow issues. For the GWR system project, the specifications include factory tests of each unique device type and the most heavily loaded segments, minimum. This includes motor control centers with smart motor starters networked to a process controller.
Control system I/O lists require modification, and I/O counts take on a slightly different meaning with fieldbus-based systems. Because fieldbus devices do not wire up signal by signal to an I/O channel, the I/O list requires additional fields for "port," "bus," and "device." Port equates to the segment interface at the fieldbus modules (assumes two or more ports are available). Bus represents the unique fieldbus segment number for the associated controller. Device is the unique device number on the segment. All of these fields should correlate to information shown on the fieldbus segment diagrams.
Electrical design: In a traditional plant design, after a field instrument is located and the associated controller is identified, electrical engineers can determine the best conduit and tray routing for the signals and develop conduit and circuit schedules without much interaction with instrumentation and control (I&C) engineers. After the signals get to a control system panel, the assignment of signals to I/O channels displays on the I/O list.
With a fieldbus-based plant design, I&C and electrical engineers must work together to group devices on segments based on a number of constraints, including device communication limitations (in the case of the GWR system, four valves, 10 transmitters, or some combination thereof), bus communication limitations (some longer distance DeviceNet buses communicate at slower rates), separation of parallel equipment to prevent a power loss from disabling multiple equipment trains, and in some cases, the cost of bus interfaces when in close proximity to the controller cabinet.
Clearly defining fieldbus segments must happen before conduit and wire design begins. This adds a level of complexity to the work flow process and requires more interaction between disciplines. Also, because of the tight linkage between segment diagrams, I/O lists, and electrical design, the impact of a change during the final design is greater. Good planning and consistent adherence to design standards can offset these additional constraints.
Cost versus benefit of fieldbus
The early decision to use fieldbus instruments supported a larger vision of using the intelligence available from microprocessor-based instruments to move OCWD from a preventive maintenance mode to a predictive maintenance mode. The DeltaV system includes asset management software that allows the user to call up the status of any fieldbus device. The ultimate success of OCWD's asset management program will be the successful integration of a computerized maintenance management system with its new financial information system and the DeltaV controls, thus enabling OCWD to realize the full potential for savings using an intelligent plant. However, some immediate savings of using fieldbus are:
Device configuration: Configuration of field devices is easier and simpler using the new system. OCWD estimates the configuration time required for a device using a PLC-based system is thirty minutes (fifteen minutes to configure the I/O channels and fifteen minutes to document the changes). With DeltaV it is about five minutes, because the system automatically senses a fieldbus device when it is connected. Also, the configuration of a device documents automatically within the device, which eliminates documentation time altogether. Given that OCWD plans to install 1,200 fieldbus devices, the savings potential during commissioning is approximately $50,000.
Device calibration documentation: OCWD determined that the largest savings in device calibration labor using a fieldbus system versus a PLC-based system is in the documentation. Defining a calibration procedure would take about the same amount of time with a PLC-based system or a fieldbus-based system. The time to locate a test procedure would halve from ten minutes to five minutes using fieldbus, because the procedures are readily available. Also, the time to locate an instrument in the control system is less, because the historical information for each instrument is readily available via the HMI. Documentation of configuration changes occurs automatically with the new system, so that time goes to zero minutes. Total time to document a device calibration was twenty-five minutes less. If 65% of devices are affected, then there is a potential savings of $75,000.
Reduced wiring costs: Conventional wiring requires one to provide analog and discrete signal wires for every signal and every device. Using a fieldbus system, a communication cable can combine signals from multiple devices on fieldbus segments using a trunk-and-spur topology, thus greatly reducing the wiring and conduit requirements. This benefit was especially good for OCWD, because the space available to build the AWTF was limited, so a design that would reduce conduit and junction box sizes was invaluable.
Valve diagnostics: OCWD identified the potential to reduce maintenance costs on valves as a huge plus for the AWTF because it would be installing 600 new valves. Fieldbus would provide intelligence in the devices to alert operators to potential failures. The organization presumed a diagnostic test would take approximately forty-five minutes on a PLC-based system and fifteen minutes on the DeltaV. In addition, the time to analyze which valves need to swap out would go down from seventy-five minutes to thirty minutes. The time to pull, rebuild, install, and document a valve went from sixty-four hours to thirty-seven hours with an estimated savings of $1,755 per device. A huge benefit to using a predictive maintenance strategy with valves was to be able to focus the maintenance resources only on problem valves rather than rebuilding a whole train of valves.
Investment payback: When comparing the additional costs of fieldbus hardware, software, cabling, and control system interface modules to the labor savings associated with configuration, calibration, documentation, and enhanced valve diagnostics, OCWD calculated a payback period of just over three years, with approximately half the payback in the first year.
Start-up lessons learned
OCWD immediately leveraged the lessons it learned during software development on the pilot project to incorporate them into the AWTF design and standards development. To reduce capital costs on the AWTF project, OCWD plans to reuse as much of the controls equipment from the IMF project as possible. The following is a summary of issues that faced the start-up team.
Witnessed factory test emphasis: When evaluating lessons learned on the IMF start-up vis-à-vis the AWTF, the start-up team decided the one thing it would do differently would be to make the requirements for the witnessed factory test much more "software-centric." The primary focus of the witnessed factory test was confirming the wiring was correct and the hardware was functioning properly. The control algorithms and HMI graphic screens were not adequately tested. This led to continued software development in the field during start-up. The team agreed fully testing the control algorithms and HMI graphics in a controlled environment would have minimized frustration during start-up, when it was unclear whether a problem was occurring because of the control system or because of the field devices.
Keeping pace with system software development: Approximately eighteen months elapsed between the control system selection and start-up of the IMF system. During this time, the vendor continued to discover and resolve software anomalies in addition to developing future DeltaV software releases. When problems cropped up during IMF start-up, the start-up team called the vendor's support center to ask questions. For many minor problems, software fixes sometimes arrived with inconsistent versions of help files that had to be resolved in the field. In some cases, resolution was delayed to future software releases that would not be available in time for start-up. The start-up team learned it is important to make sure the latest software release installs and tests just before start-up for the best performance and support. It is also important to plan for careful installation of upgrades and software patches on an ongoing basis.
Training and troubleshooting techniques: For a fieldbus network to operate, all components on the network need to function properly. Failures require network-wide troubleshooting. The start-up team's lack of familiarity with DeltaV caused frustration during start-up when networks failed. The team used logical troubleshooting techniques to isolate and fix problems, but the lack of familiarity with the DeltaV system heightened the tendency to "assume" the problem was with DeltaV and a software patch was required. Now that start-up is nearing completion the team has developed confidence in the system and hopes this will be a very minimal issue during start-up of the AWTF. The start-up team learned it is important to have team members who are familiar with the selected control system and the fieldbuses to minimize problem solving in the field.
Despite the challenges inherent in implementing a fieldbus-based DCS in a water treatment plant, OCWD does not regret its decision to go in this direction. As with any significant advance in technology, careful evaluation, planning, teamwork, and flexibility are required to develop monitoring and control concepts into a working control system that produces high-quality water.
One can successfully implement fieldbus technology in a water plant, resulting in life-cycle cost savings derived from continuous access to vital plant data.
Behind the byline
Laura Thomas is an electrical and I&C engineer with the Orange County Water District. Jay Kalinowski works for that same organization as a process control system manager. Curtis Cook and Lou Verduzco work for Camp, Dresser & McKee, Inc. as a senior I&C engineer and as an I&C system specialist.
fieldbus A digital, serial, multidrop, two-way data bus or communication path or link between low-level industrial field equipment such as sensors, transducers, actuators, local controllers, and even control room devices. It is also a specific ISA SP50 (Foundation fieldbus) standard for digital communications that operates at the lowest level of data communications in automation.
DeviceNet An "open" network on the top of a controller area network. Created by Allen Bradley, the Open DeviceNet Vendors Association now owns and promotes the technology.
CAN Controller area network; Intel and Robert Bosch Gmbh developed CAN for real-time automotive industry needs. Primarily European, it provides a data link for J1939 used with off-road construction, agriculture, and other vehicles; often used on top of EIA 485, and more recently on ISO DIS 11898. In 1994 Allen Bradley along with 20 other companies promoted DeviceNet on top of CAN; Honeywell promoted Microswitch using SDS on top.
Profibus "process fieldbus," a German national fieldbus standard—DIN 19245—operational since 1989 for linking sensors, actuators, and controllers in an automation system. Many companies outside Germany support Profibus. The technology is OSI 7497 based.
Return to Previous Page