By Henry Palechek
With tighter regulations and economic issues on the rise, water districts are under increasing pressure to find ways to better manage their SCADA system assets. Staff at Helix Water District responded to these pressures by working out a solution that answered their need for reliable reporting and an up-to-date SCADA system. Using web-based software that connected their PLCs and databases together within the network, they were able to build a scalable system that generates a variety of reports.
Some of the reports include short- and long-term water usage patterns that can be beneficial in estimating future water purchases, thereby aiding budget and strategic planning. Without an open SQL database, this level of reporting was not possible.
Background
Helix Water District is in the east county of San Diego and has a distribution system consisting of 22 tanks filled by 62 pumps located within 21 pumping stations. The distribution system is supplied from a 106 mgd treatment plant and supplies drinking water to about 260,000 customers plus two other water districts. The SCADA system is used to oversee daily flow and pumping operations, help predict needed water purchases, and run the system under special conditions that may include when a pipeline, tank or pump station is offline.
This client screen displays details for a small hydro pump station that pressurize a small water vessel.
The Helix SCADA system has evolved over the past couple decades. The first system in 1986 cost $1.2 million. The next upgrade was a Windows-based system including PLCs, a plant LAN and new radio system, which cost $350,000 in 1996.
One weakness of the system, like most SCADA systems of its time, was the limited reporting capability. The need to improve distribution system monitoring was hindered by a propriety database and a lack of an open communication standard. The system only supported three communication protocols: two that would be obsolete by Microsoft (DDE and NetDDE), and the third a proprietary protocol called Suitelink. In addition, the proprietary data structure was weak and would stop logging data without any indication of a problem. Also, it was slow at trending and if a user asked for too much data, it was likely to lockup.
Upgrade Path
Helix's first attempt at a solution was to have the SCADA system push data into an external Microsoft SQL database. This allowed for the creation of daily, monthly and annual reports. However, this proved somewhat unreliable. The company then began looking for a supplemental data historian, which would completely bypass the legacy SCADA.
The second attempt was a two-step approach. First, the communication tagserver was replaced with an OPC-DA server that could also speak Suitelink. Then a software product was added that could read the OPC data and insert it into an SQL database. The new solution worked better–however, the OPC-to-SQL software was unstable when adding new signals or making changes. It was also cumbersome to administer and lacked good technical support.
The third time was the charm. Continuing to look for a better solution, Helix tested the leading software providers and found Inductive Automation's FactorySQL. This software was an OPC-to-SQL data historian/logger that was so easy to set up and administer that it was up and running in less than an hour. Over the course of time, the data logger proved to be extremely stable.
The timing for the new software was perfect because of increasing governmental regulations and reporting needs. The Surface Water Treatment Rule and State of California regulations require water utilities to log critical data at 15-minute intervals. This data is then used to produce a monthly compliance report that is submitted to the state.
Another advantage of the historian is that it can be triggered to log data on an event such as when an operator backwashes a filter. Signals such as total gallons filtered, gallons to wash the filter, filter runtime and other water quality parameters are used to create a filter performance summary. The summary can then be used to evaluate the efficiency of plant operations.
Within a short period of time, the legacy SCADA system had the problem of being unable to run on Vista and upgrading would be cost prohibitive. Because FactorySQL worked so well, Helix decided to try out another Inductive Automation product, FactoryPMI, which is a SQL to web-based SCADA solution. It uses a Java runtime and is started by entering an IP address into a web browser to launch clients.
The district appreciated how the software was designed to enable long-term growth and scalability. There is no limit to the number of tags or clients, which allows Helix to continue making applications with the software without having to spend more money on software licensing.
"Essentially, after purchasing the server software, we are free to add as many tags or client computers as desired at no additional cost," said Brain Olney, plant operations supervisor. "Because the software is licensed by the server and not the number of tags or client PCs, economically it was a very attractive purchase. The purchase price of the software was less than 15 percent of what the legacy SCADA software product cost back in 1996."
Improving the System
While Helix was excited about the cost advantages of a scalable software solution, they still approached it with caution by running a 60-day pilot test. They began by building a pump station screen, followed by the more challenging tasks of alarming and system summaries.
The pilot test fared very well, and Helix's system in-house developers decided to move forward and build the full SCADA project. They separated the project into three main groupings: the distribution system, the conventional treatment plant, and the ozone system.
The first step was to create screens for the distribution system, dividing the work among Helix's instrumentation and control technicians. Developing the first pump station screen and new tag name database went quickly. After the first pump station screen was finished, the technicians were able to save a duplicate of it as a template, thereby expediting the creation of each new screen. They were able to generate almost every tag name by using a CSV file and doing a find-and-replace function.
"The end result was that we were able to produce almost all of the tag names for a pump station in less than 30 seconds," said Dave Harris, senior instrumentation and control technician. "Once the tags were done, they were dragged and dropped onto the template screen."
Because SCADA systems oversee critical tasks, every data point had to be verified. The new SCADA software has an active window maker. As signals are dropped onto the screen they immediately begin updating. Additionally, the software has the ability to send data values to the PLC. To qualify the new system, technicians displayed the new system and old system side by side. They then generated a test tank level or an alarm and watched it appear on both systems. Any signal that did not work properly was then easily corrected.
About the Author:Henry Palechek is the information systems and process control supervisor at Helix Water District. He has been with the district more than 16 years. He holds a Bachelor of Science in Information Systems and has been teaching water technology courses at the local community college since the mid 90s. He also holds a California T3 Operator license.
More WaterWorld Current Issue Articles
More WaterWorld Archives Issue Articles
