The Stucker Fork Conservancy District, located in Austin, Indiana, USA, treats and distributes water in a seven-county region. The water system consists of an intake pumping station, which extracts raw water from the Muscatatuck River. The intake station delivers the water to a dual-channel treatment plant where it is processed. From the treatment plant, the water is pumped into three water-distribution zones. The water-distribution zones include nine elevated water tanks, tank feed control valves, and three pumping booster stations. The tank feed control valves and pump booster stations control the levels within the elevated tanks.
When the Stucker Fork Conservancy District decided to expand capacity in 1997, it opted to automate the entire process and chose a systems integrator to configure and install its scada system.
Scada evaluation
The systems integrator, IEC Contractors (hereafter, SI) had to decide on several options that would ultimately determine the robustness and complexity of the system. The SI did consider installing PLCs at the intake pumping station, water plant, booster stations, and at each of the tanks (18 units in all). Then ladder logic could be written to control each of the devices at each station. Each PLC would have connected to a central computer through a conventional UHF radio. With the computer running scada software, the operators could have monitored process values and issued setpoint changes to the PLCs.
Instead a PC-based scada software capable of performing the control logic internally was opted for, instead of at the remote PLCs. This eliminated the need for ladder logic programming and simplified the editing process when having to modify the control logic in an installed system.
In addition, 'dumb' remote terminal units (RTUs) could be used instead of PLCs, lowering the cost of hardware for the district. Additionally, unlike PLCs, RTUs are designed for use in remote telemetry applications and are better suited for this application. Three scada software packages were considered and National Instruments' Lookout was chosen because of its ability to effortlessly perform the required control logic, its flexibility in communications, and its ease of use compared to the other packages considered.
In the Stucker Fork Water System, Lookout communicates to 18 RTUs through a Zetron Model 1700 controller using the Modbus protocol through the PC serial port. The controller polls the 18 RTUs over conventional UHF radio. No control logic actually runs in the RTUs. Rather, Lookout makes all automated decisions. For example, the SI used the Neutralzone object of Lookout to perform on/off control. Lookout automatically issues open and close commands to the feed valves for the various elevated tanks to maintain each tank's water level. Operators can also change level setpoints. Lookout was used to perform pump lead-lag control at the three booster stations and lead-lag1-lag2-standby control at the water plant. Although the SI originally expected the alternator object to handle this function, a combination of objects had to be used, including the DataTable, some timers, and expression objects - because of the lack of I/O, each pump had to be monitored, and additional logic was added to compensate.
System benefits
One unexpected benefit of using Lookout was the inherent flexibility it delivered within the connections between objects. Object connections can be more than simple data pathways. The SI created custom logic to pull data from sources within the object connections themselves, as well as making use of the general-purpose Expression object extensively to create complex Boolean logic.
A Lookout feature worth noting is the online configuration capability: Because the SI could see its modifications online as they were made, a considerable amount of development and start-up testing time was saved. After installing Lookout at the plant, the SI could make changes to the graphics and I/O without shutting down the system. The district did not lose any historical data and stayed in control of its process. Typical of a scada system, the Stucker Fork application had a lot of repetitive work. Water tower functionality was the same, as was the functionality of the booster pump stations. Because an object represents each RTU, the SI defined the tag database of a single RTU and replicated it for each. This was accomplished using the database import/export feature of Lookout.
As for the control logic, the SI was pleasantly surprised to discover that although most Lookout applications are defined interactively, by creating and connecting objects, Lookout also includes a compiler. The logic was first interactively created and tested for one of the booster stations by using the interactive dialogue boxes to create and connect objects. The SI then replicated the source code that Lookout automatically generated for the other booster stations. All the booster station logic was then simply rolled into the rest of the application.
The same was done for the elevated tank controls. Making use of these development tools saved considerable time. In fact, the SI implemented the full Stucker Fork application in less than 40 man-hours - defining all the control logic, historical data collection, alarming, custom graphics, trending, and security.
Conclusion
The Stucker Fork project has run successfully for more than a year now. It has had no crashes and communications are completely reliable. The district has asked the SI to expand the Lookout application and add seven more RTUs. Five Lookout scada projects following this same model have been implemented. Four of the five districts require project expansions and the SI has received an order from a sixth district. "We are definitely continuing to use Lookout," says IEC Contractors.
For more information contact National Instruments South Africa, 011 805 8197, [email protected]
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version