Pumps & Systems, October 2008
Explore the current condition of SCADA reports and some new technology that will improve the quality of those reports.
With the advent of SCADA for sewerage collection and water reticulation systems, utilities have a new diagnostic tool for systems management. To date, however, system monitoring has often provided only basic operational parameters. SCADA reporting, which at best can only be as good as the data collected, has lagged behind even further. Historically, the challenges of SCADA reporting have been many, and the solutions offered have been few and inadequate.
Reports from the Field
In practice, few municipal wastewater organizations are satisfied with the quality and depth of field reports from collection systems. Many small municipalities do not have any reporting, relying only on the graphical interface and trending system for visibility system performance. The operators know their system "up close and personal," and what little system information is available is often unrecorded.
Medium-sized and larger municipal wastewater organizations have embraced SCADA reporting to a higher degree, as a management tool for larger, more complex systems. The value of reporting is clearly evident when assessing performance across a wider geographical area. Yet, a common complaint is that the overall system reporting is rudimentary, does not yield many clues as to asset quality and gives no predictive maintenance measures.
Frequently, organizations looking at new SCADA systems are doing so in a quest for better, more in-depth reporting. Certainly, larger organizations have specific reporting demands by department. Hydraulic Engineers want to know if they will need to increase the size of pumps or lift stations, or whether the current storage capacity is adequate. They are also keenly interested in monitoring infiltration and inflow (I/I) system-wide. Operations Managers are concerned with operational cost and site visits. Asset Managers want to know the costs of pump and station operation and maintenance.
Requests for this level of data are usually met with varying degrees of success. Often there is a waiting period for the data to be collected and/or converted from one format to another. Upon inspection, the data may indicate a potential pattern that bears further watching. For example, call outs to particular areas may indicate voltage supply problems, blocked pumps or a need for electrical maintenance. However, further requests for data may be unsuccessful since the small amount of collected data was provided upon the first request. Field crews may offer anecdotal information, but that is also subject to interpretation and human error.
Need for Better Reports
The need for more comprehensive wastewater system reporting is growing in part due to the changing global economy. For example, Florida has been particularly hard hit by the current housing and credit crisis. With fewer new home starts, there is less revenue from developers to the cities, yet the local municipalities still must comply with regulatory requirements. With reduced budgets and a smaller workforce, the nagging concern is this: How do you maintain your system assets? How do you know you are not running the system into the ground?
By simply maintaining the system, but not knowing whether asset quality is deteriorating, utilities may be compiling a problem that will only be painfully realized in 3 to 5 years. Comprehensive SCADA reporting at a per-station level could provide the appropriate data for cost-effective maintenance.
With all the apparent need in small, mid- and large-sized organizations, why don't we have comprehensive reporting at the present time?
A number of technical reasons have combined to make it one of the most challenging areas of municipal SCADA. The reporting modules themselves are limited, there are many problems with accurately capturing the data from the field into the reporting packages' databases, and the data from the field usually is not rich in quality.
Reporting Modules
Initially, SCADA software platforms focused on visualization, trending and alarming. For the first time, it was easy to visualize real-time field data, especially since the graphical interface of the SCADA systems was the easiest module to learn and customize.
Initial reporting modules, however, were frequently "bolt on" modules to SCADA, sometimes from third parties. Until recently, most of them had significant difficulties in practical use. At the very least, they were much more challenging for most utilities than the graphical interface.
Capturing the Data from the Field
A typical older system might have a pump controller or a PLC doing primary control at the lift station. This device communicates over a radio network, typically via Modbus. The individual PLC is polled by the SCADA, which sends out a request for data to each site to turn as quickly as possible. That might mean that the SCADA only collects data every 10 minutes or so from each site. The speed of this process can be increased, but only by using faster radios or adding more channels.
This method yields accurate but incomplete data; each poll captures the current snapshot, but not the changes or when they occurred. Another drawback is that this communications scheme is an inefficient use of bandwidth, as most of the data has not changed from poll to poll.
Storing the Data
Typically, in an older system, the data is pulled into the SCADA system and sampled to the trend logger. The trending engine is normally set up to sample at certain rates, creating another opportunity to lose data if it changes too quickly. Often, the trend files use proprietary data systems, making extraction through a reporting tool difficult.
Quality or Breadth of Field Data
The final limitation of older SCADA systems is the quality of data from the field-the "breadth" of data.
Given that many field devices only report pump running, pump fault, level, level alarm and mains fail, plus a few I/O, a lack of useful data remains, even if the data integrity through the system is excellent.
One example is the mains fail alarm, which is essential, but limited in assisting the organization in solving whatever underlying problems exist. The mains fail alarm lacks the ability
