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 to see the actual three-phase supply values-particularly a problem since many lift stations experience continual poor supply and frequent brown-outs. Some examples of other missing data that provide a clearer picture of the real conditions at each site: three-phase currents for each pump, power and energy used per pump; inflow to the station; pump flow rates; pump efficiency; and specific faults for each pump instead of a generic pump fault.
Putting all of this capability into a PLC would be a major design project, and it would also require a significant investment in control panel components (e.g., signal conditioning). This is not a practical solution for most municipalities.
With all these technical issues, valuable reports are difficult to produce.
Solutions
Each of the problems identified have solutions; some of them have been around for a considerable time and some are relatively new technology. Water/wastewater utilities are often not aware of the technical advances and live with the inefficiencies brought on by older technologies.
Better Reporting Modules
There has been a steady stream of releases of reporting tools by SCADA vendors (and other third parties) in recent years. This article does not attempt to survey them or provide any recommendations, other than to comment that a good quality reporting tool allows someone familiar with databases and reporting to produce Excel, PDF and HTML reports on demand, periodically (daily, weekly, etc.) and on "triggers." The reporting tools should allow aggregation of data from live SCADA data, historical SCADA data and databases from other areas of the organization.
Capturing the Data
While the Modbus protocol has tremendous value, especially in its simplicity, it is not a great protocol for "telemetry," i.e., capturing data from remote field hardware. A better protocol is DNP3, widely used by electricity utilities around the world and water utilities in many countries, including Australia. This protocol is open, supported by a strong user group and designed for the challenges of reliably communicating with remote field devices in critical infrastructure. Security has also recently been added to the protocol.
DNP3 sends only changed data along with the date/time stamp of that change. This gives the organization accurate data while minimizing the bandwidth requirements of the communications network.
Storing the Data
Most SCADA architectures also now include a "historian." This is essentially a data repository that captures all changed data and provides open database connectivity (usually ODBC and OPC-HDA) for trending and reporting tools. An essential feature of a good historian is the ability to keep the native data/time stamp associated with the data, not the date/time stamp from when the information was received by the SCADA and historian.
Better Data from New Field Hardware
Today, many water and wastewater utilities have begun using pump station managers. Pump station managers provide 400-500 tags per site, including inflow and station volumes; pump flow rates; energy, power and efficiency per pump; supply voltage; three-phase currents; insulation resistance of the motor windings; and detailed fault data instead of a generic "pump fault."
This level of information, combined with asset data such as hydraulic connections between stations, the catchment and the type and age of pumps installed, allows for a series of standard reports that give assets and operations management the tools they need to improve their systems.
A few of the reports facilitated by this new generation of data-rich monitors are:
- Changes in pump efficiency for all pumps and all sites (over time, by vendor, by age), which allows assessment of the best pump vendor for the application
- Breakdown of faults by station and breakdown of callout faults by station, which allows operations staff to quantify the benefits of replacing aging assets versus continual maintenance
- I&I reports by section of the hydraulic network
Utilities now can drill down into every component of the business and see exactly what has gone on, what is going on and what is trending for the future. Without this level of scrutiny, organizations are flying blind with no clear area of focus. Once reports are fine-tuned for an individual system, these reports can be generated on an ongoing basis-at any chosen interval-to keep all parties within the utility informed and aware of system conditions.