SEPA
United States
Environmental Protection
Agency
Office of Research
and Development
Washington, DC 20460
EPA/600/R-06/120
September 2006
Real Time Control of Urban
Drainage Networks
-------
Notice
The U.S. Environmental Protection Agency (EPA) through its Office of Research and Development has
financially supported and collaborated in the research described here under contract No. 4C-R344-NTSA to
Dr. Z. Cello Vitasovic. It has been subjected to the Agency's peer and administrative review and has been
approved for publication as an EPA document. Mention of trade names or commercial products does not
constitute endorsement or recommendation by the EPA for use.
-------
Foreword
The U.S. Environmental Protection Agency (EPA) is charged by Congress with protecting the Nation's
land, air, and water resources. Under a mandate of national environmental laws, the Agency strives to
formulate and implement actions leading to a compatible balance between human activities and the ability
of natural systems to support and nurture life. To meet this mandate, EPA's research program is providing
data and technical support for solving environmental problems today and building a science knowledge
base necessary to manage our ecological resources wisely, understand how pollutants affect our health, and
prevent or reduce environmental risks in the future.
The National Risk Management Research Laboratory (NRMRL) is the Agency's center for investigation of
technological and management approaches for preventing and reducing risks from pollution that threaten
human health and the environment. The focus of the Laboratory's research program is on methods and
their cost-effectiveness for prevention and control of pollution to air, land, water, and subsurface resources;
protection of water quality in public water systems; remediation of contaminated sites, sediments and
ground water; prevention and control of indoor air pollution; and restoration of ecosystems. NRMRL
collaborates with both public and private sector partners to foster technologies that reduce the cost of
compliance and to anticipate emerging problems. NRMRL's research provides solutions to environmental
problems by: developing and promoting technologies that protect and improve the environment; advancing
scientific and engineering information to support regulatory and policy decisions; and providing the
technical support and information transfer to ensure implementation of environmental regulations and
strategies at the national, state, and community levels.
This publication has been produced as part of the Laboratory's strategic long-term research plan. It is
published and made available by EPA's Office of Research and Development to assist the user community
and to link researchers with their clients.
Sally Gutierrez, Director
National Risk Management Research Laboratory
in
-------
Abstract
Real-time control (RTC) is a custom-designed, computer-assisted management technology for a specific
sewerage network to meet the operational objectives of its collection/conveyance system. RTC can operate
in several modes, including a mode that is activated during a wet weather flow event to control local
flooding and sewage releases. RTC of conveyance systems has been emerging as an attractive and cost-
effective approach that can be undertaken in addition to (or in lieu of) more traditional construction-focused
alternatives such as sewer separation or construction of storage facilities. Although there are still relatively
few documented applications of RTC to large urban sewerage systems, the technology has been
successfully implemented.
RTC implementation includes several different aspects, including hydraulics, instrumentation, remote
monitoring, process control, software development, mathematical modeling, organizational issues, and
forecasting of rainfall or flows. Addressing each of these issues in detail would require a large document,
beyond the scope of this report. Accordingly, the report provides a summary and a broad introduction to
these different issues and does not elaborate on them in great detail.
The main goal of the report is to provide a guide on RTC technology to facilitate its understanding and
acceptance by the user community. The primary audience is the practicing engineer, in a municipality or in
a consulting firm, who has had limited exposure to RTC. Also, the report should serve as a resource
document for use by federal and state program officials and regulators, researchers, and the interested
public.
There is no simple or single "recipe" for successful RTC implementation. The report provides some
guidance for the methodology to be used in the design, development, and implementation of RTC systems,
but it does not identify or recommend a single solution that will fit any municipality or any set of
operational issues.
IV
-------
Contents
Notice ii
Foreword iii
Abstract iv
Contents v
Figures ix
Tables xi
Glossary of Terms and Acronyms xii
Acknowledgments xiv
Chapter 1. Introduction 1
1.1 Definition of RTC 2
1.2 How Would One Use RTC? 2
1.3 When Would One Consider RTC? 3
Chapter 2. Components of a RTC System 5
Chapters. Process Equipment 7
3.1 Sluice Gates 11
3.2 Movable Weirs 13
3.3 Pumping Stations 13
Chapter 4. Instrumentation and Monitoring of Urban Drainage Networks 15
4.1 Level Sensor Technology 16
4.1.1 Direct Submerged Pressure Transmitters 16
Principle of Operation 16
Materials of Construction 16
Accuracy and Repeatability 16
Installation on Maintenance 16
4.1.2 Ultrasonic Level Measurement 17
Principle of Operation 17
Materials of Construction 17
Accuracy and Repeatability 17
Installation 17
-------
Maintenance Requirements 18
4.2 Flow Sensor Technology 19
4.2.1 Flumes 19
Principle of Operation 19
Materials of Construction 19
Accuracy and Repeatability 19
Installation 20
Maintenance Requirements 20
4.2.2 Area/Velocity Meters 20
Principle of Operation 20
Materials of Construction 21
Accuracy and Repeatability 21
Installation 21
Maintenance Requirements 21
4.3 Rainfall Sensor Technology 21
4.3.1 Principle of Operation 21
4.3.2 Materials of Construction, Installation, and Maintenance 22
4.4 Rainfall Forecasting Technology 22
4.4.1 Forecasting Objectives 22
4.4.2 Forecasting Approaches 22
4.4.3 Evaluation of Technologies 23
Chapter 5. SCADA 26
5.1 Introduction to SCAD A 26
5.2 Communications Options 26
5.2.1 Telephone 27
5.2.2 Fiber-Optic Cable 27
5.2.3 Radio Systems 27
5.2.4 Other Techniques 28
5.3 Communications Methodologies 28
5.4 Local Control Devices 29
5.5 SCAD A Design Considerations 30
5.5.1 Equipment Enclosures 30
5.5.2 Environmental Conditioning 30
5.5.3 Field Interface Wiring 30
5.6 Other Design Considerations 32
5.6.1 System Documentation Requirements 32
5.6.2 Training Requirements 33
VI
-------
5.6.3 System Testing Requirements 33
Factory Demonstration Test 33
I/O Point Checkout 33
Site Demonstration Test 33
System Availability Demonstration 34
5.7 Project Delivery Methods for SCAD A 34
Chapter 6. Data Validation, Filtration, Aggregation, and Storage 35
6.1 Data Validation and Filtration 36
6.1.1 Gap Filling 37
6.1.2 Range Check 37
6.1.3 Rate of Change Check 38
6.1.4 Running Variance Check 39
6.1.5 Checking for Long Term Drift 39
6.1.6 Cross Validation Methods 41
6.1.7 Data Filtration 42
6.2 Data Storage and Aggregation 42
Chapter 7. Alternative Configurations/Levels of RTC 45
7.1 Local Manual Control 46
7.2 Local Automatic Control 47
7.3 Control Modes that Require Remote Access 48
7.4 Managing Control Modes: Fail Safe Operation 54
Chapter 8. RTC Control Algorithms 57
8.1 Local Control Algorithms 57
8.1.1 Primary Controls 57
8.1.2 Programmable Logic Controller - Based Controls 57
8.2 Selection of System-Wide Control Algorithms 58
8.2.1 Reactive Systems vs. Predictive Systems 59
8.2.2 Automated Rules vs. Optimization 59
Chapter 9. Design/development Methodologies for RTC 61
9.1 Considerations in Planning 61
9.1.1 Development and Evaluation of Operating Scenarios 62
9.1.2 Weather Conditions to be Examined 63
9.1.3 Considerations for the Project Team and SOP Document 63
9.2 RTC Infrastructure Design 63
9.3 Defining Operational Goals and Performance Metrics 64
9.4 Analysis of Hydraulics 65
9.5 Offline Analysis of RTC 67
vn
-------
9.6 RTC Implementation 72
9.7 Hydraulic Analysis Tools for Urban Sewer Networks 72
Chapter 10. Project Management and Organization 74
10.1 Long-Term Support and Maintenance 76
10.2 Critical Success Factors for RTC 76
10.3 System Integration and other IT Issues 77
Chapter 11. Decision Support for Operators 79
11.1 Integration of Online Models into DSS and RTC 80
Bibliography 81
Vlll
-------
Figures
Figure 2-1. Components of aRTC System 5
Figure 3-1. Cross sectional view of a slot regulator 8
Figure 3-2. Cross sectional view of a slot regulator in conjunction with a dam 9
Figure 3-3. Cross sectional view of a manually operated sluice gate 10
Figure 3-4. Typical regulator structure (courtesy of King County) 11
Figure 3-5. Radial gate operated by float 12
Figure 3-6. Schematic diagram of a typical pumping station (courtesy of King County, WA) 13
Figure 4-1. Diagram of a typical stilling well (courtesy of ISCO, Inc.) 18
Figure 4-2. Diagram of a typical Palmer-Bowlus flume installation (courtesy of ISCO, Inc.) 19
Figure 4-3. Plot of forecasted rain event volume versus actual volume. (Internet Source: National Weather
Service) 24
Figure 4-4. Plot of threat scores over time for different storms. (Internet Source: National Weather
Service) 24
Figure 4-5. Plot of threat scores over time for different forecast horizons. (Internet Source: National
Weather Service) 25
Figure 4-6. Plot of threat score comparisons over time for different forecasting methods. (Internet Source:
National Weather Service) 25
Figure 4-8. Picture of a SCADA control console 26
Figure 4-9. Picture of a fiber equipment rack 27
Figure 4-10. Picture of a radio transmission tower 28
Figure 4-11. Picture of a typical PLC 29
Figure 4-12. Picture of a typical RTU panel 29
Figure 4-13. Picture of interface wiring 32
Figure 5-1. Information flow inanRTC system 36
Figure 5-2. "Gap filling" data validation method 37
Figure 5-3. "Range check" data validation method 38
Figure 5-4. "Rate of change" data validation method 38
Figure 5-5. "Running variance check" data validation method.than 0.01 39
Figure 5-6. Combined method for overall assessment of the confidence in the measurement value 39
Figure 5-7. Expected mean check method for determining drift in measurement 40
Figure 5-8. Acceptable trend check method for determining drift in measurement 41
ix
-------
Figure 6-1. Flow diagram of local manual control 46
Figure 6-2. Diagram of components of local automatic control 47
Figure 6-3. Diagram of components of supervisory control 48
Figure 6-4. Diagram of automatic (remote) regional control 49
Figure 6-5. Diagram of automatic system-wide global control 50
Figure 6-6. Diagram of predictive system-wide ("global") control 51
Figure 6-7. Diagram of system-wide ("global") control using linear optimization 52
Figure 6-8. Diagram of conceptual layout of optimization in RTC 53
Figure 8-1. Schematic of RTC planning process steps 68
Figure 8-2. Components of offline simulation environment for assessing RTC 69
Figure 9-1. Typical applications and associated databases in a large municipality 77
-------
Tables
Table 5-1. NEMA Enclosures Standards 31
Table 6-1. Data Filters Used in Real Time on Measurements 42
Table 6-2. Methods for Detection of Long Term Drift 43
Table 6-3. Data Filters Used in Real Time on Measurements 44
Table 7-1. Components Required for Different Control Modes 55
Table 9-1. Metrics for Simulation Type 66
XI
-------
Glossary of Terms and Acronyms
ANSI
CIS
CMMS
cso
CS (gates)
DSS
ETV
FCC
FDT
FRP
GCM
CIS
HGL
HPC
IEC
I/O
ISA
ISS
IT
ITA
JIWWTP
LIMS
MMSD
NEMA
NFPA
NWS
PID
PLC
American National Standards Institute
Customer Information System
Computerized Maintenance Management System
Combined Sewer Overflow
Combined Sewer Overflow Gates (Milwaukee)
Decision Support System
Environmental Technology Verification (program)
Federal Communications Commission
Factory Demonstration Test
Fiberglass Reinforced Plastics
Global Circulation Models
Geographic Information System
Hydraulic Grade Line
Hydro-meteorological Prediction Center of NWS
International Electro-technical Commission
Input/Output
Instrument Society of America
Inline Storage System (deep tunnel in Milwaukee)
Information Technology
Instrument Testing Association
Jones Island Wastewater Treatment Plant (Milwaukee)
Laboratory Information Management System
Milwaukee Metropolitan Sewerage District
National Electrical Manufacturers Association
National Fire Protection Association
National Weather Service
Proportional Integrated Derivative
Programmable Logic Controller
Xll
-------
PM
Q/H
RTC
RTU
SAD
SCADA
SDLC
SI
SS (gates)
SSO
SSWWTP
TS
US EPA
Project Management
Flow versus Head relationship (curve)
Real Time Control
Remote Terminal Unit
System Availability Demonstration
Supervisory Control and Data Acquisition
Software Development Life Cycle
System Integrator
Gates at South Shore Treatment Plant
(Milwaukee)
Sanitary Sewer Overflow
South Shore Wastewater Treatment Plant (Milwaukee)
Threat Score
United States Environmental Protection Agency
Xlll
-------
Acknowledgments
This is to acknowledge the valuable and significant contributions to this document made by the following
fellow professionals:
Phil Gaberdiel and Thomas DeLaura, Westin Engineering (http://www.we-inc.com/)
Dr. Robert D. Hill, EMA (http://www.ema-inc.com/)
Edward Speer and Dr. Eric Loucks, COM (http://www.cdm.com/)
Anders Lynggaard Jensen, Gunvor Tychsen Philip, and Lars Yde from DHI Water and Environment
(http://www.dhigroup.com/)
Special thanks to Nancy Schultz, CH2MHill, and Virgil Adderley, City of Portland's Bureau of
Environmental Services, for their technical comments, input, and insight.
Ms. Mary Stinson, the U.S. EPA Project Officer, provided important guidance, help, and support to this
report throughout the project.
xiv
-------
Chapter 1. Introduction
Real time control (RTC) includes practices and tools for actively managing the operation of wastewater
networks and facilities. The goal of RTC is to improve the overall performance of urban sewer systems
and integrate their operation with wastewater treatment facilities. In many cases, the specific driving force
behind the implementation of RTC is the need to reduce wet weather overflows. RTC consists of
operational strategies and/or algorithms that control the sewer collection system using online measurements
that are collected in "real time," thus adjusting the operation of the sewer system based on its current state
and dynamic conditions. A more rigorous and detailed definition of RTC is provided later in this
document.
Wastewater collection and conveyance systems represent a crucial part of the urban infrastructure. The
cost and complexity of these systems is great, especially in highly urbanized areas. Managers, engineers,
and operators of these systems are faced with difficult problems related to the operation and maintenance of
their facilities. In addition to the issues related to the operation and upkeep of the system, many sewerage
agencies are facing increasing public concern about the environmental impact of combined sewer
overflows (CSOs) and local flooding. In many instances, these operational challenges need to be faced in
an atmosphere of limited resources and fiscal pressures to "achieve more with less." Often, fiscal pressures
are accompanied by concurrent increases in performance requirements from the regulatory agencies.
The design practices for sewer networks have historically been conservative and include significant safety
factors that result in larger pipes in the collection system than typically needed. As sewerage network
design does not normally include consideration of RTC, there are often opportunities to optimize the
utilization of the existing system through operational strategies.
The problem of sewage releases to receiving streams or backups into basements, as well as local flooding,
has traditionally been addressed by large-scale capital improvement programs that focus on construction
alternatives such as sewer separation or construction of new conveyance pipes or storage facilities. The
cost of such projects is often high, especially in older communities where the population density and the
value of land is high. In the last few years, RTC of conveyance systems has been emerging as an attractive
alternative. Although there are still only a few documented implementations of RTC this technology has
been successfully implemented in several large urban sewerage systems.
Implementation of RTC includes several different aspects, including hydraulics, instrumentation, remote
monitoring, process control, software development, mathematical modeling, organizational issues, and
forecasting of rainfall or flows. Addressing each of these issues in detail would require a large document,
beyond the scope of this report. This report is a broad introduction to these different issues; its objective is
to bring these different aspects into view rather than elaborate on each of them in great detail. The primary
goal is to introduce RTC to practitioners who have had limited exposure to RTC in the past and to make
this technology more accessible and understandable.
The secondary goal of this report is to provide the reader with an entry point to learning more about RTC.
The report includes examples of RTC projects and implementations and provides references to literature
that contains more detailed information. It does not focus on the latest research on RTC but rather on
information from different areas and aspects of RTC. The intention is to provide an overall introduction of
this technology that is useful to practicing engineers in a consulting firm or in a municipality.
-------
Although some of the RTC applications described in this report are advanced and complex, the reader
should not interpret this to mean that all RTC must be advanced in order to provide value. In many cases,
simple RTC strategies can yield benefits over the advanced and complex designs.
Most importantly, experience with RTC shows that there is no simple or single "recipe" for successful
implementation. Accordingly, the report provides guidance on the design, development, and
implementation of RTC systems and does not identify or recommend a single solution that will fit any
municipality or any set of operational issues.
1.1 Definition of RTC
RTC can be broadly defined as: a system that dynamically adjusts the operation of facilities in response to
online measurements in the field to maintain and meet the operational objectives, both during dry and wet
weather conditions.
Flows and levels in sewer systems are typically manipulated by static facilities (e.g., weirs) that are not
adjusted in real time. RTC adds a dynamic component, where some of the facilities are actively adjusted in
real time based on system conditions.
The term "Real Time Control of Sewer Systems" has often been used to describe control systems that
include system-wide ("global") control rules and may include such sophisticated components as linear
optimization algorithms. Some of these complex systems have been reported in the literature and for many
in the wastewater industry, the term "RTC" has somehow become synonymous with this type of complex
system and application.
When municipalities consider RTC, they should consider a range of possible solutions, starting from simple
and straightforward and potentially culminating in a "global predictive optimal" configuration. A complex
system is by no means always the best choice.
1.2 How Would One Use RTC?
RTC may be used to achieve different operational objectives. These objectives will be not only site-
specific (different urban communities will have different operational issues and priorities) but even within
the same network they may change at different times (or under different conditions).
In order to better answer the above question, it may be useful to first define a simplified view of RTC
functionality. An RTC system generally performs the following functions:
Collects information about the current state of the sewer network
Compares the current state of the sewer network with the desired state of the sewer network
Determines the settings for the control facilities that will bring the sewer network (closer) to the
desired state
Implements the settings into actions of the final control elements (e.g., gates, pumps, inflatable dams)
During the process of designing an RTC system, it must be decided what the desired state (operational
goals) of the sewer system will be. This, however, can be a bit tricky because of different operational goals
that depend on the system state itself. For example, there may be different operational objectives during
dry weather, in the middle of an intense storm, or during a security emergency.
RTC can be used for different purposes. Control strategies can address operational issues during both dry
weather events and wet weather events. Examples of operational goals include:
-------
Reducing or eliminating sewer backups and street flooding
Reducing or eliminating sanitary sewer overflows (SSOs)
Reducing or eliminating CSOs
Managing/reducing energy consumption
Avoiding excessive sediment deposition in the sewers
Managing flows during a planned (anticipated) system disturbance (e.g., major construction)
Managing flows during an un-planned (not anticipated) system disturbance, such as major equipment
failure or security related incidents
Managing the rate of flow arriving at the wastewater treatment plant
To view RTC as only "a way to reduce CSOs" is therefore a bit restricted view because a well-designed
RTC system may need to address a number of different operational goals at different times. This report
includes information that mostly focuses on the goal of reducing CSOs but the methodologies and tools
presented are equally applicable when some of these additional operational goals are to be considered.
1.3 When Would One Consider RTC?
In most cases, implementation of RTC can offer benefits and improve performance of an urban sewer
system. The costs and the extent of the benefits that RTC can provide may differ from one sewer system to
the next and therefore the answer (whether RTC is the appropriate solution) is not always straightforward.
This section of the report provides some assistance to those municipal managers who are considering
whether RTC will be beneficial for their specific issues.
It is important to point out that there are no technological barriers to implementing RTC. Fears from "new
technology" are largely misplaced. RTC technology has been around for at least 20 years and many
successful applications can be seen in many wastewater plants where RTC is more common. Although
RTC implementations in collection systems remain relatively rare, there are several successful examples.
The report by Schuetze et al., aims to facilitate a greater acceptance of RTC by the municipal engineers and
managers and suggests a process for evaluating the applicability/suitability of RTC technology to a specific
case.
Sometimes, issues with RTC implementation may be not technical but rather organizational or procedural.
While the primary users of RTC are the operational staff, initial vision and enthusiasm for RTC systems
may come from the management ("downtown" vs. "the field"). In some cases, application of RTC is
suggested and encouraged by the upper management or by vendors and consultants who are engaged in the
development and implementation of RTC. At the same time, the final success of an RTC system demands
support from staff on the "operational front lines," those who are directly involved in operations and who
would be the primary users of the RTC system. It is important to understand that the success of an RTC
project requires a good understanding of the organizational issues and that the RTC development strategies
need to consider and ensure acceptance of the RTC system by the users.
Municipalities are often risk-averse. In such environments new or advanced technology (including RTC)
may be perceived with some concern. However, since the benefits of RTC can be significant, this report
aims to demonstrate that this technology can bring such benefits without a great risk.
Some of the remaining barriers to a broader implementation of RTC are:
-------
General perception that RTC must always be a complex system, and thus concern about these systems
being "fragile" or unreliable. Hopefully, this report will show that such concerns can be addressed and
that RTC scope can be adjusted to fit a site-specific set of operational needs.
Most municipalities are concerned about legal exposure and issues related to regulation; if the sewer
system does not include automation, and overflows occur, it is often seen as an "act of God" since
nothing more could have been done. Therefore, the concern is that introducing automation and RTC
may well open up "second guessing", increased scrutiny about operations, and increased reporting to
regulatory agencies.
RTC is often seen as a complicated "computer project" and there is general concern because IT
projects have earned a reputation for being late and over budget.
This report cannot provide a single, simple recipe for overcoming all of the barriers but it "demystifies"
RTC, describes the components, presents a methodology for development, and includes a number of
examples. Hopefully, the information provided will facilitate the acceptance of this promising technology.
There are some cases where RTC can provide only very limited immediate benefits, at least in the short
term. This could be the case, for example, if a collection system simply does not have any available in-line
storage (i.e., if the pipes are close to full, even during dry weather, there is little that RTC can do by itself).
However, even in those cases, it is prudent to consider RTC during planning of future facilities (e.g., if they
provide additional storage capacity).
-------
Chapter 2. Components of a RTC System
This section presents a typical layout for components that might be included within a RTC system. Some
of these components are organized hierarchically; the components on the lower levels (e.g.,
instrumentation) are essential for RTC but some of the "higher level" components may be optional (RTC
does not necessarily need to include them and could work without them).
The word "component" is used here to describe either equipment (e.g., sensor or a final control element
such as gate or pump) or a software program (e.g., RTC algorithm, or a database). What these components
have in common is that they are related to control actions and they may collect, process, or deliver data to
other parts of the overall system. The components are most often graphically represented with boxes and
the arrows that connect them indicate the communications and data that is passed on between the
components (Figure 2-1).
Engineering
Workstation
Rl
Algo
!
Engii
r
-c
'ithm
leering/Modeling server
nvlronment, offline
Forecasting
Online Model
k
Central SCADA
Online
Environment
, RTC Workstation
(SCADA GUI)
Uwuured Data ham the Fu
Sensors
Control
Elements
Remote
Siten
Remote
Site 2
Remote
Sitel
Figure 2-1. Components of a RTC System.
-------
The organization of the components and the conceptual design of the RTC system is often referred to as
"architecture." The structure of this document reflects, and partially follows, the architecture of the overall
system. The architecture can be presented at different levels of detail; the overall components of the
architecture are presented in Figure 2-1. An RTC system architecture may contain one or all of the
components shown. This architecture illustrates a highly sophisticated RTC system; but not all the shown
components are essential for a successful system.
Each remote site includes sensors (flow, level). Sensors are connected to the inputs of the local RTC
device (in most cases a Programmable Logic Controller, PLC, or Remote Terminal Unit, RTU). The final
control elements (e.g., gates, pumps) are connected to the output side of the PLC (or RTU). The PLC
controls the final control elements based on the rules embedded (programmed) into the PLC. These rules
are feedback algorithms, where action is based on the difference between a setpoint and the measured
variable. For example, a PLC may be programmed to maintain a certain level in the wet well and will
reduce the flow through the pump (on the effluent end of the wet well) if the level is too low or increase it
if the level is too high.
Information captured in the field needs to be communicated from the remote stations to the computers and
systems that will process, store, and archive it. Communication is an important link and reliability
requirements often drive the need for redundancy in equipment. The Supervisory Control and Data
Acquisition (SCADA) system includes standard graphics and user interface (GUI) tools that operators can
access through the RTC workstation. In most cases, SCADA systems provide a number of displays
("screens"), organized so that operators can monitor the overall network and also zoom in on specific
facilities. RTC software will, in most cases, be located on its own hardware (Systems Engineer
Workstation), where system engineers will be managing the software related to RTC (e.g., RTC control
algorithms, online models, forecasting algorithms, etc.). Algorithms are computational modules that solve
one or more equations. Direct control of the control elements is almost always located on the PLC. The
setpoint for the controller may either be fixed and programmed locally or it may be changeable and be
downloaded in real time from the RTC algorithm. What these components have in common is that they
collect and process signals and/or data and exchange signals/data with other parts of the overall system.
The facilities in a sewer system are spread throughout the service area and the "bottom layer" of
automation resides in different geographical locations ("remote sites"). In each remote site, a local
processing unit (PLC) collects the signals (measurements) from the sensors and also provides outputs
(control setpoints and signals) to the control elements (pumps, gates, etc.) PLCs are usually programmed to
execute control of the facilities within their area. These PLC programs include setpoints that are defined
locally (within each PLC) and are also capable of receiving a "remote" setpoint from the central server.
The information from the remote sites is collected through telemetry and delivered to a central location via
SCADA system. Usually, the information that is collected from the field is displayed in "real-time" to the
operator at the RTC workstation as well as stored in the central servers that may be located at the main
control facility. The central SCADA system also provides "remote" setpoints to each remote site. The
information stored in the main SCADA servers includes the current (real time) and past (archived)
measurements from all the remote sites. This information is normally used in the following ways:
Operating staff make real time decisions based on the information that they receive online
Engineers use the measured data to analyze system performance, develop computer models of the
sewer system, and design new RTC algorithms
The RTC algorithms are normally connected to the SCADA database; they retrieve the information
about the status of the system, and provide the setpoints back to the SCADA system in real time
In the sections that follow, each of these components will be discussed in detail.
-------
Chapter 3. Process Equipment
Sewer systems are conveyance networks; their role is to collect and transport the sewage to treatment
facilities. In some cases, sewer networks need to have some flexibility so that flow rates can be adjusted to
meet various operational objectives. The overall objective is to convey wastewater away from the people
and the environment to protect public health and safety, property, and the environment. Process equipment
provides the necessary flexibility to achieve this objective. A brief summary of process equipment is
presented in this report since the main intended audience for this document (operators of sewer collection
systems and practicing engineers) will already have a great deal of familiarity with such equipment and
especially with the equipment that is part of their network.
Process equipment in a sewer system consists of gates, weirs, and pumps that serve as components in the
broad category of diversion structures. These structures may contain movable elements and electrically
operated equipment or sophisticated control systems associated with them. This chapter will discuss the
elements associated with flow diversion structures (sluice gates, moveable weirs, and pumps).
The broadest category of sewer system process equipment involves the diversion structure. While most
sewer systems are dendtritic in nature (tree-like structure with branches combining into trunks and leading
to a single point at a treatment facility), the safe operation of the sewer network in many cases requires a
diversion where flows can be diverted in different (typically two) directions. These are commonly found in
combined sewer systems where high flows may be experienced during storm events. However, even in
sanitary systems, there may be relief sewers or other alternative paths designed into the system that must be
managed, either passively or actively through the use of moveable elements.
A passive diversion structure typically includes a fixed weir, a stop-log weir, or a manually adjusted slide
gate. A leaping weir can also be used (Figure 3-1) or a "slot regulator" in conjunction with a dam can be
used (Figure 3-2). These passive structures may contain orifice plates or other manually adjustable
elements but for the purposes of RTC these would be treated as fixed elements. Typically, the adjustments
are made only during installation/testing or for seasonal changes.
A configuration of a manually operated sluice gate is shown in Figure 3-3.
Passive control structures are configured to split the flows in different ways, depending on the system
conditions (e.g., high flows vs. low flows). While passive diversions are not usually considered part of
RTC (because they cannot be adjusted in real time), simulations and analyses of operational strategies often
provide insight into how these passive structures could be adjusted for optimal effect. In an active
diversion, flows can be affected by a control element that changes position in real time. Two examples of
active elements are sluice gates and inflatable dams.
Sluice gates are most often implemented within regulator structures which are diversion structures that use
moveable gates to regulate (actively change) the flow split. A typical configuration for a regulator structure
is shown in Figure 3-4.
-------
DISCHARGE PIPE
TO INTERCEPTOR SEWER
Figure 3-1. Cross sectional view of a slot regulator.
-------
FLOW,
L
SLOT
DISCHARGE PIPE
TO INTERCEPTOR SEWER
FLOW
Figure 3-2. Cross sectional view of a slot regulator in conjunction with a dam.
-------
GEAR HOUSING
SLUICE GATE
Figure 3-3. Cross sectional view of a manually operated sluice gate.
10
-------
Figure 3-4. Typical regulator structure (courtesy of King County).
As shown in Figure 3-4, a typical regulator structure includes two gates; a regulator gate that controls the
flow from the trunk sewers upstream into the interceptor that takes flows to the treatment plants and the
outfall gate that controls the flows between the regulator station and the receiving water.
During dry weather flows, the regulator gate is fully open and all the flows are diverted to the treatment
plant via the interceptor. The outfall gate is fully closed during dry weather operation. As the level
increases in the interceptor during rain events, the regulator gate is usually throttled to avoid overloading
the interceptor. When the regulator closes during wet weather, the level in the trunk sewer (and
immediately upstream) rises. Once the level in the regulator station exceeds a certain value (setpoint), the
outfall gate is opened to release the excess sewage and an overflow occurs.
As described, the regulator gate is controlled based on the interceptor level while the outfall gate is
controlled based on the level in the trunk sewer entering the regulator station. Other control scenarios are
possible; however, this is the most common regulator configuration in combined sewer systems.
3.1 Sluice Gates
Sluice gates are commonly vertical rising gates held in place by vertical grooves on either side of the sewer.
Some sluice gates have a curved surface and are operated radially from a horizontal spindle or pinion.
Sluice gates can be operated by a float mechanism or by an electric motor that receives commands from an
electronic control system. Typically a sluice gate will serve one of two purposes:
A normally closed gate will open to relieve a sewer during high flows, allowing part of the flow to go
to a relief sewer or to an open channel
A normally open gate will close to limit flows in order to protect downstream equipment or property
11
-------
The earliest installations of automatic sluice gates used float devices to operate the gate (Figure 3-5).
Depending on the location of the float, the gate can close in response to high flow downstream or it can
close in response to high flow upstream. However, float-controlled chambers are limited in their ability to
be modified to provide specific control sequences.
Figure 3-5. Radial gate operated by float.
Programmable electronic controls have become standard equipment for many remote facilities. These
provide a very flexible method to provide control to diversion structures as well as to other control
equipment, such as pumps or backup generators. They also can participate in a distributed control system
that forwards alarm and event information to a central control or monitoring console.
Gates can be controlled effectively and without much risk, if they are set up properly. The following
paragraphs outline simple methods for addressing some of the common concerns encountered when setting
up the control of a gate.
In order to provide safe operation of the moveable gate, a limit on the speed of the gate is enforced, either
through the gear ratio from the electric actuator or within the control unit itself. A gate that closes quickly
during high flows can cause a wave that can travel upstream or downstream and has the potential for
damaging other structures. The controller for the gate should be programmed to issue a no control action
when the measured level is within a reasonable distance from the setpoint. This distance is called the
deadband, and is required to prevent the gate from constantly moving small distances in an attempt to
achieve the desired setpoint. The value of the deadband must be obtained through testing and field
experience.
In locations where storage is desired, it is possible to use an inline sluice gate. However, in order to
provide redundant flow paths in case of equipment failure (e.g., a stuck gate), either a bypass weir or other
passive path is designed into the system. As discussed above in the description of a regulator station,
several gates are often combined within one control structure. However, in many cases the locations of the
12
-------
gates, referred to as belonging to the same "station," may be several hundred feet apart, with separate
power and telemetry feeds.
3.2 Movable Weirs
Movable weirs are a large class of structures that can behave like a fixed weir but can also be adjusted to
provide diversion of flow at differing heights, depending on system conditions. A popular type of
moveable weir that is used to restrict flow at varying levels is an inflatable dam. This large, industrial
grade rubber bladder is installed along the invert of a large sewer (typically larger than 60-inch diameter)
and connected to an air compressor that is controlled electronically. For most applications, the dam is
normally inflated to prevent stormwater or combined sewage from passing on to an outfall and into a
receiving waterway. Sewage or water stored upstream of the dam is diverted to a treatment system.
During storm events that cause elevated flow conditions upstream, the pressure in the inflated dam can be
lowered allowing flow to pass for the purpose of relieving the system upstream.
3.3 Pumping Stations
Pumping stations can be found in most medium to large sewer systems. A typical configuration for a
pumping station is shown in Figure 3-6. Usually, although not shown in the generic figure, pump stations
will also include weirs or gates to handle the overflow, to protect the facility during conditions of very high
flows or emergencies.
Downstream
Discharge Interceptor
Structure
Upstream
Interceptor
- Bar Screen
Figure 3-6. Schematic diagram of a typical pumping station (courtesy of King County, WA).
In order to provide reliable operation, at least two pumps are usually placed in a pumping station and
controlled through a local electronic controller. These controllers often operate based on a level sensor
placed in the wet well of the pump station. Pumps can operate at a fixed rate of rotation or they may be
driven by a variable-speed motor. For fixed speed pumps, control can only occur by turning the pump on
or off. Although variable-speed pumps can throttle the flow based on the speed of the impeller, multiple
pumps are still used to provide additional pumping during high flow periods.
For safe and reliable operation of a pump station, the local controller is programmed to operate only on
local signals at the station (typically the level in the wet well). This "pump program" is usually determined
during station design and is not modified on a regular basis.
13
-------
Remote control of the station is usually implemented by submitting a new setpoint to the local controller.
This is an indirect method of control compared to directly sending a remote signal to start and stop
individual pumps. By using a remote setpoint, the local pump program can be used to establish the
conditions necessary to produce the setpoint and thereby rely on the inherent stability of the pump program.
Pump programs for a large pumping station will turn on additional pumps as the level in the wet well rises.
This anticipates additional flow into the pump station that must be "matched" by the pumps in order to
prevent flooding upstream. However, if sufficient storage exists upstream, regional or system-wide control
algorithms may direct the station to reduce and store the flow in order to provide relief downstream. This
"reduced flow" signal from the remote setpoint may be translated into a value for the process variable to
which the pump program can react.
In some situations, pumps will be controlled using existing analog controllers. When computer controls are
added, the analog controllers may remain in place which means that they will interact with the PLC and
other RTC. In such a situation, the existing (analog) pump control will be based on fixed setpoints, such as
the level in the wet well. When computer controls are added and the analog controllers remain, the
computer may provide a new ("fake") wet well level setpoint that would indirectly achieve the desired
pumping rate.
An additional control element that can be utilized is an influent gate to the wet well. In some cases, it may
be desirable to lower the influent gate to control the level in the wet well and therefore produce the desired
flow rate from the pump station. As in the previous example, this implementation is only practical if
sufficient storage or alternative flow routing is available upstream. In general, pumping stations with large
diameter sewers upstream that could provide storage are most commonly used in RTC applications.
14
-------
Chapter 4. Instrumentation and Monitoring of Urban Drainage
Networks
Instrumentation is the foundation of any RTC system; without reliable measurement(s), RTC cannot
function properly. RTC systems typically require only a few types of basic measurements, such as water
levels within pipes, manholes, and structures, as well as flow rates and rainfall amounts. Instruments for
these types of measurements in the process industries have been available for many decades.
Unfortunately, some of these "process industry" instruments are poorly suited for the "challenging"
environment of the urban drainage network. This environment can include:
Corrosive atmosphere (H2S, NH3, H2SO4)
Sometimes explosive atmosphere (methane and hydrocarbons)
High humidity
Exposure to oils and greases, organic waste, industrial wastes
Periodic submergence (pressurized)
A wide range of process values (levels and flows)
Deposition of solids on the bottom of the pipes (silting)
Lack of nearby power and communications
Limited surface access and almost always in a confined space
Fortunately, instrumentation for drainage networks has been developed over the past thirty or so years that
specifically address each of these issues. In particular, these instruments have been designed to work in a
corrosive and potentially explosive atmosphere with periodic submergence. The instrumentation developed
in the 1990s with multi-path velocity measurements and built-in microprocessors is especially robust. In
general, this instrumentation represents a mature technology with many thousands of installations providing
reliable and accurate information.
Power is always required for instrumentation. For critical locations and measurements, a backup (or
redundant) power source is desirable. If an instrument is to be used for RTC (not just for monitoring),
requirements for reliability are higher and it is especially important to ensure uninterrupted operation. An
important design parameter at sites without permanent power is the battery life for remote sites that cannot
easily be connected to the electrical power grid. Batteries may provide the primary source of power.
Battery life depends on the frequency of measurement and how often data is polled or downloaded from the
instrument. Typical battery lives vary from six weeks to well over a year.
Maintenance of instrumentation is key to its reliability. Experienced operators will monitor and
periodically check the trends of signals coming from all of the key instruments. Based on the trends,
15
-------
operators will identify (or "flag") the instruments that are likely to be experiencing problems. When
automation and RTC are introduced into the organization, organizational aspects of maintenance will come
into play. It is important that the maintenance crews understand the RTC of the network, are familiar with
maintenance issues specific to sewer networks (e.g., manhole access, traffic control) and also have proper
experience with RTC equipment. For large systems, specialized maintenance crews can be a good
approach.
Maintenance can also be improved by using Computerized Maintenance Management Systems (CMMS),
software that helps operators manage the maintenance of the facilities and the equipment in the field. Due
to the nature of their different functions, many agencies have a specific CMMS for the treatment plant and
pump stations and another CMMS for the collection system. Staff will need to decide where the data and
maintenance schedule and work orders will reside for the RTC structures.
4.1 Level Sensor Technology
Continuous level measurements are often required in pipes and structures of an urban drainage network.
This section is limited to only continuous level measurements (analog values) and excludes point level
measurements. Point level measurement devices are on/off switches that are triggered when the flow rises
above or below the target level. All of the area/velocity flow meters discussed in the next section also
require continuous level measurement. Various technologies have been successfully used for level
measurement including mechanical, pressure transmitters, ultrasonic, and bubblers. The direct submerged
pressure transmitters and two types of ultrasonic level technologies are the most often used and are
discussed in more detail.
4.1.1 Direct Submerged Pressure Transmitters
Principle of Operation
Submersible transducers use diaphragms to sense differential pressure. Diaphragms are either flat or
concentrically corrugated metal or ceramic disks. Process pressure applied across the diaphragm causes it
to compress. Electrical signals proportional to differential pressure are obtained by mechanically
connecting an electrical component such as a capacitor, strain gauge, resistive, or inductor to the
diaphragm. These electrical signals are then converted to estimates of pressure and water depth and
broadcast to the communication system. Submersible transducers are purchased with a sealed cable
assembly to prevent the process from coming in contact with the sensing element electronics. Integral to
the cable assembly is a breather tube that acts as the low-pressure reference leg for the transducer. The
breather tube is routed beyond the maximum level of the process and is either vented into the enclosure or
is routed to a breather bag. When the tube is vented to the atmosphere, a desiccant filter in the enclosure is
needed to ensure that humidity does not have the ability to condense in the breather tube and cause
inaccuracies in the level reading.
Materials of Construction
Process sensing elements are typically metal or ceramic. Typical process connection materials are 316-
stainless steel, Hastelloy, and Monel.
Accuracy and Repeatability
Typical accuracies for submersible transducers are +0.1% of the measurement range (span). For most
sensors, the measurement range is 4 to 20 milliamps or sometimes 5 to 10 volts. The software maps the
measurement range into engineering units (e.g., flow or pressure).
Installation on Maintenance
The direct submerged pressure transmitter is usually installed in the invert of the pipe or near the bottom of
a structure. For pipe installations (usually in conjunction with a flow meter), care should be taken that trash
will not catch on the mounting and that high velocities will not tear the instrument away. Usually, the
manufacturer will supply a custom mounting bracket that fits the size of the pipe and is compatible with the
piping material. Direct pressure transmitters can still provide accurate level measurements even when
covered with silt. For level measurements in a structure (such as a lift station), it is often sufficient to
suspend the direct pressure transmitter on a chain for easy access. Annual calibration checks of the level
16
-------
instalment should be conducted. Potential drift, which may be caused by debris hanging on the devices,
should be checked monthly.
4.1.2 Ultrasonic Level Measurement
Principle of Operation
Ultrasonic level sensors typically are based on time-of-flight principle. A sensor (attached above the
surface of the sewage/water) sends pulses so that the surface of the process being measured reflects the
pulses back to the sensor. The required time of flight represents the path traveled in the empty portion of
the pipe or process tank. The instrument is calibrated to calculate the difference between the maximum
empty pipe (or tank) distance and the distance of the empty space representing the pipe diameter (or tank
level). A variation found on some area/velocity flow meters utilizes an ultrasonic transmitter mounted on
the invert of the pipe that shoots a signal upwards to find the water surface.
Ultrasonic wave velocity depends on temperature, pressure to a limited extent, and humidity to a minor
extent. Where changing conditions are anticipated, automatic compensation can be provided. Only
temperature is typically compensated for because other factors are usually negligible.
Sensors are available with frequencies from approximately 9 kHz (sonic) to 20 kHz plus (ultrasonic). The
pulse generator can have a variety of shapes including cone, parabolic configurations, or threaded-pipe
configuration for ease of connection directly to a stilling well pipe. Cone shape configurations are selected
to minimize attenuation due to reflection. Ultrasonic level instruments are available with measuring ranges
from 6 in. to 200 ft depending on sensing probe selection.
Signal attenuation (a reduction in signal strength) can be caused by absorption into the air, reflection away
from receiver's sensing area, and absorption by foam on top of the process being measured, or by the
process medium. Propagation distance and wave frequency affect attenuation by absorption. As distance
from the sensor to the liquid level increases, signal strength decreases in proportion to the distance squared.
Persistent dense foam is typically a problem for sonic and ultrasonic devices.
Two common problems associated with vapor are corrosion and freezing. Heaters are available for sensors
to prevent freezing and proper material selection can reduce the corrosion effects. Most transducers are
designed to work in vented tank applications; however, if submerged pressurized conditions are a concern,
manufacturers offer transducers capable of operating in pressure vessels greater than 50 psi.
Materials of Construction
Transducer probes are available in a variety of materials facilitating measurement of a wide variety of
processes. Typically, the transducers are provided with polyvinylidine fluoride (PVDF) facings, or have
polytetrafluoroethylene (PTFE) flange facings installed for corrosion resistance. PVDF facings can be
utilized in process environments from -40°F to 300°F. For aggressive chemical or abrasive process level
measurement, facings are available from other synthetic materials.
Accuracy and Repeatability
Accuracy of +0.25% and repeatability of +0.1% of span are typical. Air space conditions, water/sewage
turbulence, foam, and interfering objects can reduce accuracy and repeatability. Manufacturers can assist
in calculating the total attenuation attributed to the presence of interfering objects and process variations.
Installation
The mounting location of the transducer is determined from restrictions as recommended by the
manufacturer. Typically, the sensor is mounted on the ceiling or over-head structural member at least 6in.
above the maximum level to be measured; this distance is commonly referred to as the blanking distance.
Blanking distances vary widely depending on the transducer selected. The transducer should be mounted
far enough from the tank walls to prevent false echoes. The distance is dependent upon the beam angle of
the transducer. The transducer should be mounted away from physical obstructions.
17
-------
In structures, a stilling well (Figure 4-1) can be used with ultrasonic (or other level) sensors to dampen out
liquid level turbulence, reduce foam, increase signal strength, eliminate noise from stray echoes, or reduced
condensate problems. The stilling well is cut from a single piece of piping at least 4 in. in diameter. The
bottom is cut at a 45-degree angle. Air relief holes should be drilled near the top of the stilling well where
the transducer is mounted. For flumes and weirs, the stilling well can be mounted on the side of the
primary element with a connecting pipe. The size of the connecting pipe determines the stability and
damping of the level.
Maintenance Requirements
Sonic and ultrasonic level transducers do not contact the process fluid; therefore, they can be used in nearly
every wastewater conveyance and treatment process. They are suitable for and are frequently used as
secondary elements in flow measurement. The term "secondary" refers to the fact that the level
measurement is used to infer a flow rate rather than directly measure it.
Periodic cleaning of the transducer facing may be required depending on the rate of accumulation of
coating on the transducer surface. Annual calibration checks of the level instrument should be conducted,
or when utilized for compliance, semi-annual or quarterly calibrations should be performed. A staff gauge
to conduct calibration verification is frequently used, especially when the transducer is utilized as a
secondary element in a flow measuring system.
Stilling
Well
Staff
Gauge
Figure 4-1. Diagram of a typical stilling well (courtesy of ISCO, Inc.)
18
-------
4.2 Flow Sensor Technology
Continuous flow measurements are often critical to the control of an urban drainage network. Various
technologies have been successfully used for flow measurement; however, flumes and area/velocity flow
meters are most often used and are discussed in more detail in this section.
4.2.1 Flumes
Principle of Operation
The most common type of flume used in urban drainage networks is the Palmer-Bowlus flume, Figure 4-2.
The flume is usually placed in a manhole or other access point and acts as a hydraulic control in which
critical flow is developed. This condition is usually assured when water is backed up in the pipe above the
flume and when discharge from the flume is super critical (typically a free fall). The flow rate is then a
well know function of upstream water depth which can be measured with any of the level measurement
technologies previously mentioned.
ypper
Transition
lower
Transit Ion
Flew
Upstream
Dapm
Small Jump
Should Occur
In Its is Region
Pr etarreci Head
M«sufifn|| Pom I
0 = Conduit Diameter
Figure 4-2. Diagram of a typical Palmer-Bowlus flume installation (courtesy of ISCO, Inc.).
Materials of Construction
Flumes may be fabricated out of any material that is stiff enough not to deform under the hydraulic load.
Typically, fiberglass reinforced platic (FRP) or aluminum are used Cascading raw wastewater over a
flume will often aerate the water and allow for the dissolved sulfides to be released from solution. If a
flume is going to be a permanent installation, the material of construction should resist the corrosive action
of the wastewater.
Accuracy and Repeatability
The accuracy of a measurement derived with a flume depends on a combination of the accuracies of the
primary (flume) and secondary (level measurement) elements. For a correctly fabricated and installed
flume, the estimated accuracy of the depth discharge equation is ± 3% of the flow rate. A combined flume
and level-measurement accuracy of ± 5% of the flow rate is attainable with repeatability to ± 0.5% of the
flow rate. Several additional sources of error, if uncorrected, can increase the error (decrease the accuracy)
of the flow measurement. These include:
19
-------
Deviations of the throat width from standard dimensions
Any longitudinal slope of the floor in the converging section. (Tests on a 0.075m (Sin.) flume
demonstrated that a downward sloping floor produced added errors of 3 to 10% from low to high flow
conditions)
A transverse slope of the flume floor
Violation of the assumption of a free discharge caused by backwater in the downstream sections of the
pipe, common during wet weather conditions
Poor approach conditions
An incorrect zero reference of the level-measurement device and, if a stilling well is used, the
connector hole is improperly sized
Installation
The flume requires an approach channel long enough to create a symmetrical, uniform velocity distribution
and a tranquil water surface at the flume entrance. A general rule is that at least two channel widths or ten
throat widths of straight run are required upstream of the flume inlet. The elevation of the flume floor must
be high enough to prevent submergence conditions at maximum flow and the floor section level
longitudinally and transversely. Leakage under the flume should be avoided. The upstream level
measurements of about 0.5 pipe diameters upstream of the flume entrance should be taken.
Maintenance Requirements
The flume should be checked periodically to ensure debris, especially rags, has not accumulated. Rags and
other debris can interfere with the flow pattern through the flume. Calibration of the secondary level
measuring device should be checked at least annually.
4.2.2 Area/Velocity Meters
Principle of Operation
All area/velocity flow meters work on the principal of multiplying an average velocity of flow by the cross-
sectional area to calculate an average flow rate. All of these flow meters also use a level measurement to
assist in calculating the cross-sectional area of flow. The many flow meters on the market, however, vary
greatly in how the velocity is measured and how many measurements are required. Some flow meters use a
single velocity measurement and an assumed depth-area-flow profile (which may have been determined
experimentally for the site) to estimate the flow rate. Errors accumulate when the assumed profile changes
due to upstream or downstream constrictions or changes in the pipe cross-section. Other more
sophisticated instruments use multiple velocity measurements on multiple paths to determine the average
velocity of each flow segment and then sum these individual subflows. These multi-path flow meters
generally have less error over a greater range of flow conditions but also at a greater cost.
Area/velocity flow meters all must measure the level of water in the pipe to determine the cross-sectional
area. The most common methods of measuring this level are direct submergence pressure transducers,
ultrasonic transducers mounted on the pipe crown, and ultrasonic transducers mounted on the pipe invert.
All were discussed in the previous section. Velocity is usually measured with one of two technologies,
electromagnetic or ultrasonic Doppler.
Electromagnetic sensors are based on Faraday's principle of electromagnetic induction, in which the
induced voltage generated by an electrical conductor moving through a magnetic field is proportional to the
conductor's velocity. The accuracy of electromagnetic sensors may be affected by buildup of oils and
grease. Therefore, self-cleaning streamlined designs are particularly important.
Ultrasonic Doppler flow meters work on the principal of frequency shift due to relative motion. A signal of
known frequency between 600 kHz and 1 mHz is sent into the fluid where it is reflected back to the
20
-------
transducer by suspended particulates and/or gas bubbles. Because the reflective matter is moving with the
process stream, the frequency of the ultrasonic energy waves is shifted as it is reflected. The magnitude of
the frequency shift is proportional to the particle (flow) velocity and is converted electronically to a linear
flow signal. The more sophisticated Doppler meters will use one signal to generate a vector of velocities
along the entire path.
Area-velocity flow meters often have software that provide an option to calculate the flow rate based on
depth and the Manning equation alone by assuming a normal flow condition (non-backwater, less than full
pipe). This feature is useful as an added check if the velocity data appears suspect.
Materials of Construction
Flow meters must be constructed for submerged and potentially explosive conditions. Applicable ratings
are IP 67 (equivalent to NEMA 6P) and Class 1, Division 1. IP 67 is s standard for protection against
temporary immersion in up to 1 m of water for 30 min. Class 1, Division 1, is a safety standard for
equipment operating in hazardous environments where flammable gases, vapors, liquids, combustible
dusts, or ignitable fibers are likely to exist under normal operating conditions.
Accuracy and Repeatability
Accuracy of flow measurements vary greatly depending on flow conditions at the measurement point and
the particular technology used. In general, single point flow meters are not as accurate over the entire
range of flows. Depending on the assumed flow profile, errors can exceed 25% of the true flow rate under
poor conditions. The multi-path instruments may have errors as low as 1 to 3% of the true flow rate.
Installation
Each specific manufacturer will provide mounting hardware depending on the pipe size and material of
construction. As much upstream straight lengths of pipe (minimum 10 pipe diameters) as possible should
be provided to create a symmetrical, uniform velocity distribution.
Maintenance Requirements
The area/velocity flow meter should be checked periodically to ensure debris, especially rags, has not
accumulated. Electromagnetic sensors should be cleaned periodically per manufacturer's
recommendations.
Flow Meter Testing and Verification
There are two primary sources of third party verification of flow meter technology. The Instrumentation
Testing Association (ITA) tested six area/velocity flow meters from five manufacturers in a full-scale
sewer application in 1998. This evaluation report is available for purchase at their web site
(www.instrument.org). The U.S. Environmental Protection Agency's Environmental Technology
Verification (ETV) program (www.epa.gov/etv/verifications/verification-index.hmtl) tested two
area/velocity flow meters from a single manufacturer. These tests reports are available (at no cost) online,
and show typical errors for laboratory and field conditions.
4.3 Rainfall Sensor Technology
Rainfall meters are used to measure precipitation. Historically, these measurements are used for calibration
of hydrologic and hydraulic models. In RTC systems, these measurements can be used as part of a forecast
of the affects of precipitation (see next section).
4.3.1 Principle of Operation
Most rainfall meters work on a very simple principle. Water is collected in a small "bucket" until 0.01 in.
accumulates. This precise volume then tips the bucket, provides a momentary contact closure, and empties
the bucket. The contact closure is monitored by an electronic unit that accumulates the closures over
various time periods and communicates these values. This class of rainfall meters is collectively called
tipping bucket rain gauge and are built to standards set by the National Weather Service. The unit can be
heated in the winter time to melt snowfall.
21
-------
4.3.2 Materials of Construction, Installation, and Maintenance
Rainfall gauges are typically constructed of epoxy or enamel coated aluminum and anodized aluminum
and/or stainless steel. The rainfall meter and collector should be located on a flat, level surface in an open
area with no overhanging obstructions. They should not be mounted on a steel or iron surface. Some
manufacturers recommend one rainfall gauge every 2 mi2 for good rainfall correlations. Every few months
the collector should be checked to make sure its strainer is free from obstruction of leaves, pine needles,
and other debris.
4.4 Rainfall Forecasting Technology
Precipitation forecasts are difficult to perform and evaluate because of the large number of variables and
variety of forecasting objectives a wastewater agency might have. The factors that define a forecast include
the forecast horizon and the intensity, duration, volume, spatial and temporal distribution within the storm,
and possibility even the type of precipitation.
4.4.1 Forecasting Objectives
The forecast horizon is the period over which the forecast applies. Clearly, the accuracy of any forecast
technology will decrease as the beginning of the forecast horizon is set further into the future. The length
of the horizon also affects accuracy. A pin-point forecast of precipitation over a short period in the future,
for example 12 to 18 h from the present time, can be very difficult to perform with great success. However,
the specific time of day when the rainfall occurs could be important because wastewater systems usually
have more capacity at night.
Precipitation is a process that varies in time and space. Each wastewater agency is affected differently by
precipitation and thus, each will have different forecasting objectives. In some cases, the location of the
precipitation within the service area could be very important while with others, the intensity of the rainfall
might be a critical operational factor. It is nearly universal that agencies are mainly concerned with
extreme storms having a large total rainfall volume, although the definition of large and the storm durations
of interest vary from place to place. This adds to the difficulty of acquiring accurate forecasts because
extreme storms, particularly high intensity events, are subject to greater spatial variability than lighter
events.
In many locations, the type of precipitation, rain versus snow, can be very important. In Milwaukee,
Chicago, Boston, and New York, the largest overflow events are created when intense rain falls upon an
existing snow cover. Such rain on snow events necessarily take place during the winter season when the
rain portion of the event could occur as snow with a slight change in conditions. Typically, a relatively
narrow band of snow will be generated 50 to 150 mi north of a low pressure center as it moves northeast
along a frontal boundary. A slight change in trajectory or timing can easily turn a snow event into rain.
4.4.2 Forecasting Approaches
The primary methods employed in forecasting precipitation are climate modeling and synoptic forecasting.
A climate model is a computer simulation of the atmosphere process affecting weather. This generally
involves the movement and interaction of air masses which are driven by the jet stream and the earth's
rotation. As a result, many climate models are global circulation models (GCM). These models simulate
processes across the entire planet which means they have fairly low resolution (usually a minimum of 50 to
100 km), and because of very long run times and high computer processing requirements, GCM are
typically developed and operated by government agencies. The US Naval Observatory has a model called
NOGAPS, Environment Canada operates the CGCM3 model, and the Hadley Centre in England has its
own Hadley Model. There are also regional climate models which simulate climatic processes over a
limited area but at a much greater level of spatial resolution. Regional models have the potential to be
more accurate in predicting rainfall depth and intensity and to define the spatial distribution of rain over an
area as small as a wastewater district, which is impossible in a GCM. To be successful, regional climate
models must account for local anomalies such as urban heat islands or the effects of large lakes. Even the
presence of crops on agricultural lands can influence local weather. Thus, building and operating a
regional model can have extensive data and input requirements. Regional models are accurate over a
22
-------
limited area and accuracy diminishes greatly near the model boundaries. Boundary conditions must be
provided as input throughout the simulation and are subject to significant errors.
Another computer modeling technique is the statistical model. Statistical models evaluate a time series of
recent observations and synthesize a forecast of future values. Statistical models are generally in the
experimental stage and are not currently in wide use as a rainfall forecasting tool. These models require a
large amount of reliable historical data to build and calibrate the model. Continued use of the model then
depends on the availability of the observations used to build it. However, urban development and funding
often leads to changes in the location or condition of the monitoring equipment which then affects the
reliability of the statistical model.
Synoptic forecasts are made by trained professionals who use atmospheric measurements, recent history,
experience, and judgment to develop a prediction. Most professionals also utilize the results of GCM runs
in formulating their synoptic forecasts. A key element in creating a synoptic forecast is precipitable
moisture. An air mass with a known temperature and dew point temperature has a particular precipitable
moisture content. This is the amount of water that would be precipitated if the air mass were suddenly
cooled to its dew point. By assessing the likelihood and degree of such cooling, the synoptic forecaster can
predict the volume of future precipitation.
Finally, it is worth mentioning ad hoc forecasters; i.e., people who are very experienced with the weather in
a particular geographic area. Although they have no formal training in climatology, their experiences allow
them to make remarkably reliable forecasts. The best ones include farmers, trail guides, park rangers, and
frequently, operators of wastewater collection systems. Ad hoc forecasters use observations of wind,
clouds, and pressure along with their vast experience augmented, perhaps, by radar summaries, to develop a
prediction of future rainfall. This type of forecasting technology, that includes an experienced operator
armed with radar, local observations, and an internet connection, is probably the most common forecasting
technology employed by wastewater agencies.
4.4.3 Evaluation of Technologies
In practice, forecasters rarely rely on a single approach; rather, forecasters use a hybrid of model results,
synoptic analysis, and judgment. There is little evidence to suggest that any of these methods perform
better than the others. The biggest problem is, in fact, attempting to define success in forecasting and being
able to gather the data necessary to evaluate a significant unbiased sample of forecasts.
A company known as Great Lakes Forecasting has been preparing synoptic forecasts of 24-h precipitation
for the Milwaukee area for more than 10. The forecasts are generally prepared at midnight for the
subsequent 24-h period thus it is possible to develop a consistent comparison between the forecast volume
and the actual volume of precipitation. Figure 4-3 is a plot of forecast volume versus actual volume for
forecasts made between September 1997 and December 2001. This plot shows that these particular
forecasts tend to underestimate the precipitation quantity. The problem appears to get worse with
increasing actual storm size.
A statistic known as the threat score (TS) is used to measure the adequacy of quantitative precipitation
forecasting methods. The threat score is the ratio of correct predictions divided by the number of
opportunities where opportunities are instances of predicted or actual events. More precisely, it is defined
as:
# correct forecasts
± *J "
# forecast events+# actual events-it correctforcasts
In this context, an event is a precipitation volume of a particular size range, duration, and period of
occurrence. The National Weather Service Hydrometeorological Prediction Center (HPC) maintains
records of various forecasts and corresponding threat scores.
23
-------
2.0 --
45 Degree Perfect
Forecast Line
o.o
1.0
1.5 2.0 2.5
Actual 24-h Precipitation (in.)
3.0
3.5
Figure 4-3. Plot of forecasted rain event volume versus actual volume. (Internet Source: National Weather
Service)
Results of historical forecasts are shown in Figures 4-4 through 4-5. Figure 4-4 compares TS values for
water year 2005 for storms of various volume classes (less than 0.5, 0.5 to 1.0, and 1.0 to 2.0 in.) with a
few anomalies, the data shows that the threat score gets much lower for the larger storms and is typically
less than 0.25, sometimes much less.
HPC QPF Day 1: Sept 2004 - Sept 2005
Threat Scores for .50,1 and 2 in.
0.70
0.60
0.50
0.40
CO
1 0.30
0.20
0.10
0.00
T
Sep Oct Nov Dec Jan Fab Mar Apr May Jun Jul Aug Sep
Month
-m- .50" 1.00" -m- 2.00"
Figure 4-4. Plot of threat scores over time for different storms. (Internet Source: National Weather Service)
24
-------
0.33
0.30
A -)A
0.15
0.09
0.06
0.03
n nn
Annual HPC Threat Scores: 1.00 in
Day 1 / Day 2 / Day 3
V
*-% "~
" ', --"""
_^ **-*~~iT»".»*" *" «
^S-*-r**T" '" * ,^r^*
^* ,' . .*«"
*J**^ / " "
«
.
i
M>5»"*«
I : ''-" .---^ --..- - -
'
. i.i. i. 4-4-.fr. «T«.4.4.*.i.4
4.6 ;
3.8 «
3-4 5
on $
Z*
I
IB 9
"i n
1960 1964 1968 1972 1976 1980 1984 1988 1992 1996 2000 2004
Day 1 ° Day 2 Day 3 PCI Coverage
Figure 4-5. Plot of threat scores over time for different forecast horizons. (Internet Source: National Weather
Service)
Figure 4-5 shows the annual average TS for the 1-, 2-, and 3- day forecast horizons. This plot shows, as
expected, that the forecasts 2 or 3 days in the future are much less reliable than that for the 24 h
immediately following the prediction. This plot also shows how increasingly sophisticated GCM and
accurate measurements have improved forecasting accuracy. For the 1.0 in. storm shown, however, the TS
have improved from about 0.16 to nearly 0.27 in. in about 45 yrs. Even with such improvements, about 73
% of forecasts will be incorrect in some fashion. Figure 4-6 compares several of the forecasts that were
available in 2005 demonstrating the superiority of the HPC forecast over models alone.
Threat Scores: 1-in. OPF Day 1
October 2004 through October 2005
0,50
0.00
Pc< llov (toe J«f> Fe-b Mar Apr N!*y Jun Jul Aug Sep Ott
Month
NGN BNAM BGFS BHPC
Figure 4-6. Plot of threat score comparisons over time for different forecasting methods. (Internet Source:
National Weather Service)
25
-------
Chapters. SCADA
5.1 Introduction to SCADA
The term SCADA is an acronym for Supervisory Control And Data Acquisition (Figure 5-1). In its truest
sense, a SCADA system acquires process data from field instruments and final control elements and then
presents that information to a centralized location so that a human operator can initiate supervisory control
commands. In the early days of SCADA systems, this description accurately portrayed system operation.
The components that interfaced to the final signals (RTUs) had limited computational capabilities and even
more limited memory. Therefore, it was impractical to consider any RTC rules executing in the RTUs
themselves and manipulating the facilities. Since the computer components used at the centralized control
location (sometimes referred to as Master Station or top-end) were more sophisticated, some early systems
had limited supervisory control algorithms that executed on the central computer and provided supervisory
commands to the RTUs based on field signals.
Over the years, microprocessor technology has evolved, becoming much more powerful and inexpensive.
In addition, the cost of digital memory has decreased to the point that it is no longer a significant
consideration in control system design. SCADA system designs have taken full advantage of the advances
in computer technology. Modern systems now employ RTUs or PLCs with more computing power and
memory than the Master Station computers of old. As such, modern SCADA system designs regularly
employ sophisticated RTC algorithms which execute in the RTU itself. The central human operator is kept
constantly apprised of the automatic controls being implemented by the remote units and can always
assume remote, manual control. In certain instances, the system operator may be required to "approve"
planned control actions prior to their being implemented remotely.
Figure 5-1. Picture of a SCADA control console.
5.2 Communications Options
The fundamental purpose of a SCADA system is to communicate data and control commands from a
centrally located operator to geographically dispersed remote locations. Some form of electronic media is
required to support this communication.
26
-------
5.2.1 Telephone
Early SCADA systems typically employed tone signals transmitted over leased telephone circuits. As
communications technology evolved, the use of modems communicating over leased or dial-up telephone
lines became more prevalent. Due to the low cost of installation, telephone-based communication systems
are still widely used in SCADA system applications.
5.2.2 Fiber-Optic Cable
Many utilities sought to eliminate the recurring costs (monthly charges) and maintenance uncertainties
associated with telephone-based systems. From a system performance standpoint, one of the most
attractive communications alternatives is the use of dedicated, fiber-optic cable (Figure 5-2). Fiber-optic
cable supports high-speed communications, is immune to electrical interference, and exhibits high system
availability. However, the cost for fiber-optic cable is often prohibitive, especially for long distance
installations. In recent years, the cost of the fiber-optic cable itself has been reduced dramatically making
the installation cost the primary consideration. A number of utilities have adopted the practice of installing
fiber-optic cable as an integral part of all pipeline construction projects. By doing so, the cost of the fiber-
optic circuits represents only an incremental amount of the overall construction costs. In other SCADA
system applications in which the remote sites are located in largely urban areas, some utilities have been
able to negotiate the use of spare fibers in the local cable TV supplier's network. Conversely, some utilities
who have installed fiber-optic cable as a part of their SCADA system have included additional unused or
"dark fiber" for future use by the utility or to lease to cable TV, businesses, or other utilities.
Figure 5-2. Picture of a fiber equipment rack.
5.2.3 Radio Systems
A more common alternative for SCADA system communications is the use of some type of wireless
network. There are a wide range of radio systems that have been adapted to SCADA system
communications. Systems using licensed, 900 MHz radios were widely used in the late 1990s, with many
systems still in operation. Some SCADA system designs took advantage of the trunked radio systems that
many utilities have in place to support voice communications. Trunked radio systems utilize several pairs
of frequencies to enhance transmission. Most trunked radio systems are in the neighborhood of 800 MHz.
In some cases, to support higher throughput requirements, dedicated microwave links have been employed
for SCADA communications. All of these alternatives provide high-speed data communications.
However, they are all also complex systems which are costly to design, install, and maintain. In addition,
many utilities have experienced problems obtaining the required FCC radio licenses to support these
systems, especially in dense urban environments.
In recent years, a number of unlicensed radio systems have become available. These systems have evolved
using technology developed to support pager and cell phone applications. The unlicensed systems employ
low-power radios (less than 1 watt) and transmit effectively over short distances, generally one mile or less
(Figure 5-3). One of the most popular unlicensed radio technologies is Spread Spectrum. In performing
Spread Spectrum, the radio transmitter takes the input data and spreads it in a predefined method. Each
receiver must understand this predefined method and "despread" the signal before the data can be
interpreted. There are two basic methods to performing the spreading: (1) frequency hopping, and (2)
direct sequencing. Frequency hopping spreads its signals by "hopping" the narrow band signal as a
27
-------
function of time. Direct sequencing spreads its signal by expanding the signal over a broad portion of the
radio band.
Figure 5-3. Picture of a radio transmission tower.
The Federal Communication Commission allows the use of Spread Spectrum technology in three radio
bands, 902-928 MHz, 2400-2483.5 MHz and 5752.5-5850 MHz for transmission under 1 watt of power.
5.2.4 Other Techniques
In addition, depending on the specific geographic topology of the SCADA system components and the
existing infrastructure of the utility, there is a wide range of other available communication techniques
available including point-to-point microwave (both licensed and unlicensed), satellite-based systems, etc.
Many utilities have begun to use cellular telephone-based communications. As emerging communications
technologies, such as wireless Internet access, continue to evolve, they will be applied to SCADA system
applications.
5.3 Communications Methodologies
One of the factors that can have a significant influence on the type of communications media to be used is
the methodology employed by the SCADA system to exchange data between the master station and the
RTUs. The most common methodology is referred to as "master-slave". In this scheme, the master station
polls each RTU in a pre-determined, round robin fashion. In the simplest implementation, each RTU
reports the current value of each input/output (I/O) point in its database and the master station transmits the
required state of all control points. In a more sophisticated scheme referred to as "report-by-exception," the
RTU reports only those discrete points that have changed state and those analog points that have changed
by more than an adjustable deadband. Likewise, the master transmits only those control points that have
changed since the last RTU scan. Report-by-exception schemes reduce the amount of communications
traffic, allowing the use of lower throughput communication media, but are more complex to program.
Another communications methodology which can be used to limit the amount of data transferred between
the master station and RTU is referred to as "RTU cry-out". In this scheme, the RTU itself initiates
communications to the master station when data changes beyond an adjustable deadband. This
communications method requires sophisticated software to arbitrate when two or more RTUs cry-out at the
same time; however, it can be very effective especially in mostly quiescent applications.
An additional system requirement that affects the choice of communications media is the need for peer-to-
peer communications. In some SCADA applications, it is necessary for one RTU to communicate directly
with one of its peer RTUs. For example, a remote pump station may be controlled by a tank level
measured by another RTU. In these applications, both the communications media and methodology must
be designed to allow communication between RTUs without the intervention of the master station.
28
-------
5.4 Local Control Devices
As discussed previously, there are two general categories of devices that can be used as local control
devices: Programmable Logic Controllers (PLCs) and Remote Terminal Units (RTUs). The evolution of
these two types of devices was distinctly different.
PLCs (Figure 5-4) were originally designed as replacements for discrete relay logic. As such, PLCs were
ideal for discrete control applications, but were not well suited for continuous control. Another strength of
PLCs was their rugged design which allowed them to operate with minimal failures in harsh industrial
environments.
Figure 5-4. Picture of a typical PLC.
RTUs (Figure 5-5) were developed as proprietary devices that employed microprocessor technology and
custom operating systems and programming languages. Since RTUs were essentially computers,
sophisticated control strategies utilizing both discrete and continuous logic could be developed. Early
RTUs were constrained by the limited computing power of the available microprocessors and the high cost
of memory.
Figure 5-5. Picture of a typical RTU panel.
Recent advances in PLC design have eliminated their shortcomings in regard to continuous control
applications. The International Electrotechnical Commission (IEC) has developed the IEC 1131-3 standard
which defines five PLC programming language standards as follows:
Ladder logic
Sequential function chart
Function block diagram
Structured text
Instruction list
29
-------
Most modern PLCs support the full range of IEC 1131-3 languages allowing very sophisticated RTC
applications to be developed. The choice between using PLCs or RTUs as local control devices is largely
determined by preference. As recent advances in technology have blurred the line between an RTU and
PLC, the term "RTU" will be used to indicate a generic field automation unit in the remainder of this
section.
5.5 SCADA Design Considerations
There is a wide range of practical considerations associated with the design of a SCADA system. Perhaps
the most varied and complex issues are associated with the physical installation of the RTUs. By the very
nature of wastewater collection and conveyance systems, the RTUs that are part of the SCADA system will
most likely be installed in somewhat challenging environments. Design considerations for RTU
installation include: equipment enclosures, environmental conditioning, and field interface wiring.
5.5.1 Equipment Enclosures
Remote site conditions associated with a wastewater SCADA system are typically not conducive to the
electronic components that are part of the RTUs. In order to protect the RTU components and to extend
their useful life, particular care must be given to the design of the RTU enclosures. The National Electrical
Manufacturers Association (NEMA) has developed a set of standards for equipment enclosures which
define the expected operational environment for electronic equipment. Adhering to these standards for
RTU enclosures will help to ensure that the RTU equipment is adequately protected. Table 5-1 summarizes
NEMA enclosure standards.
5.5.2 Environmental Conditioning
In addition to selecting the appropriate enclosure, it is important to ensure that the required environmental
conditioning is provided for the RTU equipment. Temperature extremes, both heat and cold, have
detrimental effects on the RTU's electronic equipment. The typical operating range for RTU components
is 0 - 60 °C. For installations in colder climates in which subzero operating conditions are likely,
thermostatically-controlled enclosure heaters are generally included as part of the RTU design
requirements.
There are a number of different design approaches available for use with RTU installations which exhibit
high ambient temperatures. For outdoor installations, a simple sun shield is often sufficient to keep the
cabinet temperatures within an acceptable range. For additional cooling, thermostatically-controlled
cooling fans can be added to the RTU design. For the most extreme conditions, sealed-system air
conditioning units can be utilized.
A document published by the National Fire Protection Association (NFPA) entitled NFPA-820 Standard
for Fire Protection Measures in Wastewater Treatment and Collection Facilities, addresses the means of
protection to be applied for electrical equipment installed in hazardous locations as defined by NFPA-70
National Electrical Code. Although locating equipment in hazardous locations should be avoided,
sometimes it is unavoidable. These documents should be referenced when considering environmental
conditioning.
5.5.3 Field Interface Wiring
The field interface wiring associated with SCADA system RTUs (Figure 5-6) represents a sizable portion
of the overall system costs. Not only are the initial costs for purchasing and installing the field interface
cables significant, the costs and complexity for maintaining the integrity of this wiring over the life of the
SCADA system must be considered in system design. Unfortunately, in many existing SCADA systems,
after years of add-ons and expansion, the field wiring is a tangle of poorly labeled cables along with
undocumented field conditions. Troubleshooting or expanding these systems can be a daunting task. There
are a number of design techniques which can be used to lower the life-cycle costs associated with field
interface wiring. To begin with, a comprehensive standard should be employed for wire labeling. Several
standard organizations, such as ISA and ANSI, provide suggested labeling schemes. Whichever standard is
selected, it is critical that all interface wiring be clearly labeled with permanently affixed wire tags. It is a
good practice to install wire tags on both ends of interface cables, especially long ones.
30
-------
Table 5-1. NEMA Enclosures Standards
Type
1
2
3
4
4X
5
6
6P
7
9
12
12K
13
Use
Indoor
Indoor
Indoor or Outdoor
Indoor or Outdoor
Indoor or Outdoor
Indoor
Indoor or Outdoor
Indoor or Outdoor
Indoor
Indoor
Indoor
without knockouts
Indoor
with knockouts
Indoor
Protection Against
Incidental contact; falling dirt
Type 1 plus dripping and light splashing of liquids
Type 1 rain, sleet, snow, and windblown dust
Undamaged by external formation of ice on
enclosure
Type 3 plus splashing water and hose-directed
water
Type 4 plus protection against corrosion
Type 2 plus settling airborne dust, lint, fibers, and
flyings
Type 4 plus entry of water during occasional
temporary submersion at limited depth
Type 4 entry of water during prolonged
submersion at limited depth
Capable of withstanding pressures from internal
explosion of specified gases, and contain such
explosion sufficiently that explosive gas-air
mixture existing in atmosphere surrounding the
enclosure will not be ignited.
Capable of preventing entrance of dust. Enclosed
heat generating devices shall not cause external
surfaces to reach temperatures capable of igniting
or discoloring dust on the enclosure or igniting
dust-air mixtures in the surrounding atmosphere.
Type 2 plus circulating dust, lint, fibers, and
flyings
Type 2 plus circulating dust, lint, fibers, and
flyings
Type 12 plus the spraying, splashing, and seepage
of water, oil, and noncorrosive coolants
Another technique that should be considered in RTU installation design is the use of separate, dedicated
field termination panels. These panels, which include modular termination assemblies, can be installed in
31
-------
advance of the RTU enclosures. This practice allows the field interface wiring to be installed and tested
while the SCADA system is still being developed in the factory. Then, once the system has passed factory
testing, the RTU enclosures can be installed and field wiring completed using factory-fabricated interface
cable assemblies.
One technology that promises to simplify the issues associated with field interface wiring is "smart"
process equipment and instruments. Instead of requiring individual interface cables for each signal, these
devices utilize serial cables that can provide control and monitoring information about all signals associated
with the device. Some protocols allow multiple devices to be multi-dropped on the same cable. There are
currently a number of smart instrument protocols, including HART, FieldBus, and ProfiBus. As this
technology evolves and is applied on a more widespread basis, the costs and design considerations
associated with field interface wiring will be simplified.
Figure 5-6. Picture of interface wiring.
5.6 Other Design Considerations
There are a number of other non-technical considerations which can have a significant impact on the
success of a SCADA system project. These considerations include: system documentation requirements,
training requirements, and system testing requirements.
5.6.1 System Documentation Requirements
System documentation is one of the most important, yet often overlooked aspects of SCADA system
implementation projects. System specifications typically define the appropriate levels of engineering, user,
and technician documentation. The problem is that the delivery of system documentation usually occurs
late in the project when everyone's attention is focused on getting the SCADA system installed and
operational. One approach for addressing this issue is to require three distinct submittals for each required
document: preliminary, draft, and final. The preliminary version of a manual should define the format of
the manual and provide sufficient detail to review the basic outline and scope of the topics which will be
addressed. This submittal should be required early in the project as soon as 90 days after notice to proceed.
It is best to get agreement on the format and content of the manuals as soon as possible. The draft
submittal of each document should be generally complete (at least 90%) and should be clearly marked to
indicate where all missing or incomplete information will be included. Ideally, draft documentation
submittals should be required at 30 days prior to the start of factory testing. This requirement will
encourage the contractor to apply resources to development of system documentation while the majority of
the development team is still intact. Final versions of system documentation should be required before the
start of field acceptance testing.
32
-------
5.6.2 Training Requirements
Training is another aspect of SCADA system implementation projects that sometimes doesn't receive the
attention that it deserves. Comprehensive training should be provided to system users on a number of
different levels, including overview, user, engineer, system administrator, and maintenance. Overview
training should be presented to all users to provide a basic introduction to the SCADA system but is
especially important for utility management. User training should cover not only the basic operation of the
SCADA system but should also address aspects of system operation specific to the particular application.
In order to accomplish this course content, a member of the client's staff will need to work with the system
supplier in developing the training materials. Engineer training should cover the steps necessary to expand
the SCADA system, such as adding new RTUs, adding new database points, and adding or changing
graphic displays, control strategies, or reports. System administrator training should address such tasks as
tape backups and recovery, software upgrades, and maintenance of system files, such as operator log-in IDs
and access rights. Maintenance training should focus on the steps necessary to troubleshoot system
malfunctions. Typically, system hardware maintenance is limited to the PLC/RTU level. Most modern
SCADA systems utilize standard, off-the-shelf computer components at the top-end level. Repair of this
type of hardware is usually best left to the computer manufacturer. It is important for the owner's staff to
be able to troubleshoot RTU and communication system problems and make repairs from system spare
components.
5.6.3 System Testing Requirements
The SCADA system should undergo a comprehensive system test process to demonstrate that the system
performs as an integrated unit. The contractor, as a normal course of system development, should conduct
all element, subsystem, and system tests necessary to ensure the proper operation of the control system at
various stages of system development. This type of testing will normally be unwitnessed; however, the
owner should reserve the right to witness these tests if concerns arise about the progress of system
implementation. Four formal, witnessed tests should be conducted on the SCADA system:
Factory Demonstration Test
I/O Point Checkout
Site Demonstration Test
System Availability Demonstration.
Factory Demonstration Test
The Factory Demonstration Test (FDT) should be a comprehensive demonstration of every functional
aspect of the SCADA system. The contractor should develop a test procedure that clearly describes each
individual test, including setup, simulation required, and expected results. The test procedure should be
reviewed by the owner and engineer. The SCADA system should not be shipped to the project site for
installation until there has been a successful completion of FDT. The FDT usually includes a list of
functions that are checked off during the test.
I/O Point Checkout
As the SCADA system is being installed, the contractor should perform a complete, end-to-end checkout of
every I/O point. I/O Point Checkout should be witnessed by the owner and should be conducted on an
RTU-by-RTU basis. After the contractor has completed installation of an RTU (including all associated
instrument calibration), the contractor should test every input and output point for proper operation. End-
to-end testing should use the process graphic displays to verify proper operation of the I/O points all the
way to the operator control console.
Site Demonstration Test
A Site Demonstration Test of the functions, software, and performance of the SCADA system should be
conducted after all system elements have been installed and the I/O Point Checkout has been completed.
The system site demonstration tests should be performed to verify complete operation of the system,
33
-------
requiring a repeat of much of the factory demonstration tests but with the equipment installed at the
permanent sites and should include additional tests required to verify field-installed equipment which was
not available at the factory.
System Availability Demonstration
At the completion of the Site Demonstration Test, the owner should conduct a System Availability
Demonstration test utilizing all equipment, software, and services of the SCADA system in normal day-to-
day operations. During the test the system should be required to meet the availability criteria and
performance requirements defined in the system specifications.
5.7 Project Delivery Methods for SCADA
There are a number of different project delivery methods for the implementation of SCADA systems. The
most common approach is referred to as design-bid-build. In this approach, the owner employs a design
consultant to develop a set of bid documents that define the required functionality of the SCADA system.
The owner then solicits proposals from qualified contractors. Some agencies use a selection process in
which the contractor's proposal and approach are evaluated along with the proposed price. Once selected,
the contractor has single source responsibility for the SCADA system implementation. Due to the
specialized nature of SCADA projects, often a System Integrator (SI) will perform the work. A SI is a
specialized contractor that implements SCADA systems. The SI can fulfill the role of General Contractor
or Sub-Contractor depending on the scope of the project.
A variation of the design-bid-build approach involves the system configuration activities. Of course, in the
standard approach, the contractor is responsible for all aspects of system development, including system
configuration. However, modern SCADA systems utilize easy-to-use, intuitive tools for the development
of the system database, graphical displays, control strategies, and reports. Many owners have begun to take
advantage of this system flexibility by assigning the SCADA system configuration to a team of their
internal resources and staff from the design consultant. This approach allows for much more flexibility
during system implementation and provides significant hands-on training for the owner's staff, but can
result in higher initial system costs.
An alternative project delivery approach is design-build. In this approach, the owner develops general
functional requirements for the SCADA system; this is often considered a 30% design. The project is then
awarded to a team which has responsibility for system design and implementation. The design-build
approach can sometimes result in a shorter overall project duration.
34
-------
Chapter 6. Data Validation, Filtration, Aggregation, and Storage
An RTC system usually gets most of its data from a SCADA system. However, there might be more than
one SCADA system involved in an RTC system covering a sewer network and other sources of real-time
data might be needed to run the RTC system properly. Further, if the RTC system is a part of a reporting
and decision support system, then data from sources in addition to SCADA will be needed. Finally,
SCADA systems are primarily designed to control production processes and are therefore often not flexible
enough to cover the different tasks to be performed by an RTC system for sewer networks. An efficient
and cost effective method to overcome these shortcomings is to use a data management and storage system
as a part of the RTC system in order to carry out necessary tasks as:
Data integration from different sources
Data validation and filtration
Data storage and aggregation
Handling of identified events and scheduled tasks (automatic reporting)
Hosting of the (model-based) RTC algorithm
This chapter focuses on the second and third bullet. However, as incorrect data can cause problems when
used in automated RTC systems, data validation has been given special attention in a more thorough
description of some available methods. The RTC system usually communicates with a SCADA on:
measurements (levels, flows, gate positions....); status information (pumps and valves on/off....); counters
(elapsed operation time for pumps....), etc.,
This information is read from the SCADA by the RTC system (typically once a minute). Data from other
sources such as, radar weather systems, downstream wastewater treatment plants, remote monitoring
stations, etc. can also be collected and included together with the SCADA data, and passed through the
same information path as shown in Figure 6-1.
The necessary data are transferred to the RTC algorithm after necessary signal conditioning (validation,
filtration, aggregation, etc.). The RTC algorithm can be different for different scenarios, as different
control strategies can be necessary to handle different situations. The chosen RTC algorithm provides the
setpoints for the controllers that function within the individual control structures and facilities in the sewer
system; setpoints are communicated through the SCADA system and control action is implemented at the
final control element.
-------
Decision support
Rtri tinv mil ti <*jcj Mill i
Real ttre conroi algafttni
and *lose4eetinrf
ccrtrd-strafe^/
Figure 6-1. Information flow in an RTC system.
As shown in Fig. 6-1, "Decision Support" is an open loop setup. "Real Time Control" is a closed loop
setup. The open loop setup requests interaction from an operator, while the closed loop setup relies on
automated (programmed) operational rules. As the RTC system reacts directly to its inputs, the quality of
the incoming data is critical. Real-time data validation and filtration therefore become one of the important
tasks in a well functioning RTC system.
6.1 Data Validation and Filtration
The most common errors in the input data include missing data, measurement values out of range, peaks
(outliers) and constant ("frozen") measurement values (indicating that the sensor is out of order). It is
possible to check the data for these typical errors using simple methods known as single data validation.
However, even if these methods are simple, it is not common that they are implemented directly in PLCs,
although the range check might be an exception.
The single data validation methods are applied as part of the interaction between the RTC system and
SCADA. One or more methods can be applied as data is read from the SCAD A; each method as a result
gives a confidence value between 0 and 100 for each data point. If the confidence is lower than a preset
threshold, different actions can be taken (avoid using data for control, suspend the control based on the
RTC-algorithm and fall back to default control by local control loops, calibrate/repair sensor, etc.).
The single data validation methods are based on the immediate, recent reading, and therefore other methods
must also be used to assess the quality of the data in the long term, looking over hours and days (e.g., look
for gradual "drift"). These "long term" validation methods are partially based on the same principles as the
short term validation methods but are using data from a much longer period of time typically looking days
back from the actual time. The long term methods also include additional validation methods to distinguish
between instrument drift and a real (actual) gradual change in the process variable. These methods include
"cross validation" methods.
36
-------
Data validation is an essential step, required before measured data can be used for automated control
strategies. In addition to data validation, it might also be necessary to apply filtering methods before the
validated data can be used in RTC, because even correctly measured data can still include a variation that is
too pronounced for closed loop RTC algorithms.
In order to illustrate the single data validation methods, each method is shown in an example based on the
same data (Figures 6.2 - 6.6 In all figures, x-axis represents arbitrary time units, the right y-axis is
confidence level and the left y-axis is strength of the signals). The data comes from a measurement logged
every minute for three hours and showing an hourly variation and a trend. Further, the data has:
Missing values at 00:15 - 00:20 and 00:30 - 00:32
Peak values (outliers) at 0 1 : 50 and 02 :20
Constant values at 01:55 -02:05
6.1.1 Gap Filling
Every time a single data point is missing, it has to be considered if a possible control action should use a
default option or if it is possible to use an estimate for the missing value and then continue normal
operation based on this. Depending on the variability and knowledge of the process measured, several
possibilities exist for the estimation of missing data (gap filling). The most simple is to use the value from
the last measurement or use the trend from previous values of the measurement. However, if a correlation
with other measurements exists or a model is available, better estimates can be obtained.
r inn
IS
ID .
n
Filling
nn :m aaaa at'on 0100 02 av meap
Measured values: blue; calculated confidence: red. Method adjusted to give zero confidence after five missing values and
estimate a value using the previous measured value.
Figure 6-2. "Gap filling" data validation method.
Regardless of what method is used, the confidence in an estimate will be lower than the confidence in the
value from a real measurement. Furthermore, confidence will decrease more and more for each
consecutive value missing - eventually resulting in zero confidence. How fast confidence reaches zero, and
if the decrease in confidence is linear or decreases faster for each value missing, depends on the confidence
in the estimates.
6.1.2 Range Check
Values out of range can be related to either the measurement itself or to the expected range of values for the
process monitored. The measurement is having a normal working range, where, if properly calibrated,
values are believed to be true. This working range should fit the normal variation band of the
measurement.
The working range of a sensor is not necessarily the same as the full scale of the sensor. Often, the quality
of a measurement is lower at the ends of the full scale, which suggests that confidence in the measurement
shall be maximum within the normal working range and decrease gradually to zero through two "warning
bands" on each side of the working range. The result of applying these assumptions is shown in Figure 6-3,
37
-------
where the calculated confidence shows unacceptable values in the start of the period, but after a few
minutes the values are only triggering a warning. Due to the hourly variation and the drift in the
measurement, a warning is again issued after an hour (values too low but might be valid) and after 2.5 h
(values too high but might be valid).
3D .
ig,
-..
Q
IflD
. ~rj
. «0
. 2D
D
on.an
D1 3D
B20U
D23B
Measured values: blue; calculated confidence: red. Method adjusted to accept values in the band from 5 to 20
(confidence = 100) and give zero confidence for values below 1.25 and above 23.75.
Figure 6-3. "Range check" data validation method.
6.1.3 Rate of Change Check
The rate of change in a process variable is an important indicator of the signal quality/reliability. When the
rate of change is bigger than the realistic variations in the measurement and/or the noise generated by the
sensor, it is usually a clear signal of a disturbance or a problem. The confidence in data that exceeds the
feasible (physical, actual) rate of change is normally zero. In such cases, it is often reasonable to accept the
previous value (before the disturbance) as a reasonable estimate of the measurement.
Smaller outliers and unexpected peaks in a measurement can also be detected but it can be difficult to
distinguish between these when using a simple method. In such cases, confidence can be calculated using a
"warning band" similar to the method used for the range check.
The measurement value used in the example varies with approximately 15 units/half h corresponding to
0.5/min, and the random component is not bigger than 1.5/min. Therefore, as long as the numerical
difference between two consecutive values is less than two, the values are given a maximum confidence. If
the width of the "warning band" is set to 0.5, a numerical difference between two consecutive values has to
be bigger than 2.5 before the calculated rate of change is declared as a peak value (peak height greater than
2.5).
Figure 6-4 shows that the peaks can be detected. Also, the shift from estimates to real measurement values
at 00:20 is detected, but as this is already known from the gap filling, it can safely be neglected. However,
this shows that a sudden shift in measurement values will also be detected by this method.
OOBP
Ul'JQ.
Measured values: blue; calculated confidence: red. Method adjusted to accept peak heights of +/- 2 (confidence = 100)
and give zero confidence for peak heights of +/- 2.5.
Figure 6-4. "Rate of change" data validation method.
38
-------
6.1.4 Running Variance Check
Constant measurement values are typically a result of planned maintenance (automatic calibration) or
unexpected (failure) sensor performance, because normally functioning sensing devices always have a
small variation in the measurement values. None of the previous methods are able to detect if a sensor fails
and "locks" on a fixed measurement value, if this value is within the working range. Therefore, there is a
need for a validation method to check the nature of the signal variation. The method should decrease the
confidence if the expected variation decreases too much. The confidence will end up with a zero value
when the variation has diminished significantly (still allowing for bits to shift in analog to digital
converters).
The running variance over 5 min for the measurement used in the example is always higher than 0.05, so
the method applies a maximum confidence for a running variance bigger than 0.025 and a minimum
confidence for a running variance less than 0.01. Figure 6-5 shows that the constant measurement values
around 02:00 are nicely detected together with the estimates used for gap-filling.
BB?» H'flQ lira area
Measured values: blue; calculated confidence: red. Method adjusted to use the last 5 measurement values and to accept
a variance higher than 0.025 (confidence = 100) and give zero confidence for a variance less
Figure 6-5. "Running variance check" data validation method.than 0.01.
The above methods can be combined and applied at the same time. An overall assessment of the
confidence in the measurement value can then be calculated as the minimum of the individual calculated
confidence estimates (Figure 6-6). However, as the resulting confidence has focus on the current
"snapshot" of sensor performance (here and now), without any comparison to the reference values, these
checks will not be able to address the long term drift of the measurement values.
00 an
BD3B
DlrQD B13B 02 HO
Measured values: blue; calculated confidence: red.
Figure 6-6. Combined method for overall assessment of the confidence in the measurement value.
6.1.5 Checking for Long Term Drift
A known bias in the measurement can be compensated and an unknown bias can be avoided by proper
calibration procedures. However, a bias in the measurement value can slowly develop in time, therefore, a
validation method detecting long-term drift in the measurement value is needed. Checking for long term
drift includes two steps: first detection, and then identification of the cause (trend based on instrument drift,
or an actual long-term trend in the measurement).
39
-------
Detection can be done using two different methods, Expected Mean Check and Acceptable Trend Check,
both of them demonstrated below (Figure 6-7 and 6-8) using a measurement having a range of 0 - 100 and
logged every 12 min (five times per h). Data from a period of 14 days shows a process variable with a
periodic variation of half a day, an expected mean value of approximately 50, and a drift in the
measurement starting approximately after a week.
The Expected Mean Check method is based on a calculation of a moving average of the last measured
value "n". The moving average is compared to the expected mean value and is allowed to vary within a
certain range; the method is therefore a "long term equivalent" of the range check method. It is important
that n is chosen in such a way that the moving average is able to accommodate possible periodical
variations in the process that is monitored. As shown in Figure 6-7, the expected mean has a value of 50
and the moving average (calculated using the last 60 measurement values) is allowed to vary in the band
from 47.5 to 52.5 with warning bands on each side with a width of 2.5.
The Acceptable Trend Check method is based on a calculation of a moving slope. The slope is calculated
from the last n value of the moving average calculated as described above. The moving slope is compared
to an acceptable trend, and the method is therefore a "long term equivalent" of the rate of change check
method. It is important that n is chosen in such a way that the moving slope in fact shows long term drift,
and the n for this method is typically 2-5 times higher than for Expected Mean Check method.
10000
7 8 9 10 II 12 13 M
01 2 3 4 S
Dtgrt* of Comproftc* Imbuing Aerage
Figure 6-7. Expected mean check method for determining drift in measurement.
As shown in Figure 6-8, the moving slope (calculated using the last 240 measurement values) is allowed to
vary in a band from -0.75 to 0.75 with warning bands on each side with a width of 0.25. The drift is
detected and a warning given after 7 days based on the moving slope. However, the moving average
(Figure 6-7) shows that the resulting bias (or drift in the process variable) is still within acceptable limits.
During day 8, the drift becomes unacceptable (Figure 6-8) and the resulting bias increases over the next
two days to an unacceptable level (Figure 6-7). After day 13 the drift disappears again but leaves the
measurement with an unacceptable bias.
40
-------
HO DO
100}
OJQO
Mbasurement Degree olCompiance ^Mning, Slope
Figure 6-8. Acceptable trend check method for determining drift in measurement.
These methods enable an operator to assess the warnings, and even if both methods works in real time, they
are (at least in this example) not so time critical as the single data validation methods. Therefore, actions
taken do not necessarily have to be started automatically (even if they could be programmed that way), and
the operator can therefore proceed to the next step, which is to determine the cause of the drift. The
operator can decide to make a manual measurement (measure a level, analyze a grab sample, etc.) or he can
invoke a cross validation method (see next section) and compare the result to the measurement values, and
thereby judge if the drift is instrument or process based.
6.1.6 Cross Validation Methods
A cross validation method exploits the possible correlation between measurements and is therefore a multi
data validation method. If the measurements are highly correlated, it is possible to build and calibrate a
model (simple or complex) describing the relation between two or more measurements. It can be a
deterministic or a statistic model, or a combination (known as a grey-box model), and it can have one or
more measurements from different sensors as input and one or more of measurement(s) as output. If such a
model is running in real time giving a new estimate every time data are logged from different sensors, the
estimate can be regarded as a "derived measurement" with the same properties as other measurements.
Such an estimate is also known as a software sensor or a virtual sensor.
Some of the more simple examples of software sensors are: a flow sensor based on a level measurement
and a flow-depth (Q/H) relationship (one input, one output); a mass sensor based on a flow and a
concentration measurement (two inputs, one output); a process rate sensor based on several consecutive
measurements of a concentration (at least two inputs, one output); and finally the more complex examples
of software sensors which may include real time modeling of the sewer system itself (multiple inputs,
multiple outputs).
If a software sensor "measures" the same parameter at the same location as a real sensor, cross validation is
quite straightforward because the difference of the two measurements then can be regarded as a new
measurement with an expected mean at zero. This new measurement can undergo a range check with
narrow limits or directly give an estimate of a bias, which can be followed by the expected mean check.
Such a software sensor is also very useful in the case of missing data because the estimate of the
measurement then can be used for gap filling.
41
-------
The simplest cross validation can of course be performed, if an application (for operational security) uses
redundant (two or more of the same type of) sensors. Another simple cross validation can be set up in a
situation where a flow meter, a level measurement, and a Q/H relation are available.
6.1.7 Data Filtration
Measurements can be rather noisy and fluctuating, which can make them difficult to handle, and difficult to
use in calculation of set-points for control. Filtering gives a smoother signal that is better suited for control
purposes. However, it has to be remembered that filtering adds to the response time of a measurement.
Four of the more commonly used (and simple) filters are described in Table 6-1
Table 6-1. Data Filters Used in Real Time on Measurements
Filter
General expression
Comment
Moving average
v -
St ~
Also called a rectangular filter. All
measurements included are given the
same weight. Filters out periodical
events with a period equal to the time
period covered.
Parzen filter
Also called low-pass filter if weights
calculated to decrease with age.
Filters out events occurring more
often than the time period covered.
Robust filter
yt=-
i n-l
V
n-'.
/ , ~t-i
max "mm
Filters out the max and min value in
the time period covered and
calculates the mean of the rest.
Exponential filter
An auto regressive filter
remembering past measurements
according to the factor a. If a=0.5 an
abrupt change in a measurement will
have reached 97% of its value after
five steps.
xt: raw measurement at time t; yt: filtered measurement at time t; n: number of time steps involved.
6.2 Data Storage and Aggregation
The database of an RTC system can be divided into two parts, the static information (that changes less
frequently) and the dynamic information. As part of the static information, the database will contain all the
configuration information, including user information and configurable properties of the measurements
such as:
Identity name
Descriptive name
Location (from location list)
Method
42
-------
Parameter (from parameter list)
Unit (from unit list)
Type (from type list)
Lifetime (how long time measurement values will survive)
Duration (the period of time a measurement value covers)
Access permissions (write, edit, append)
Source identity name (connection information to data source, logging frequency, etc); if empty, data
subject to manual input
Validation parameters
The dynamic information consists of the records logged to configured measurement "channels" in the
database. A record should contain the timestamp, duration, value, quality stamp, confidence - where the
quality stamp is a more operational way of handling calculated confidences. For example, each
measurement could have its own configured quality stamp as shown in Table 6-2.
Table 6-2. Methods for Detection of Long Term Drift
Quality stamp
OK
Estimated
Suspect
Useless
Confidence level
C>=90
75=
-------
and standard deviation. However, detailed analyses of events, calibration of models, etc. will require data
with a high frequency. Due to new technology, a data management and storage system can accept large
amount of data, e.g., several years of values in minute-based measurements, before the oldest values will be
removed by a data diluting service running on the database. Data with a lower frequency will typically
"live forever" in the database. High frequency data will normally be available on backups, but as storage
capacity becomes cheaper and access times faster, it is easier to have the data a few clicks away and avoid
having to restore from a backup.
Table 6-3. Data Filters Used in Real Time on Measurements
Time Period
Aggregation Method
Hour
Day
Week
Month
Year
User defined (in minutes)
Average
Minimum
Maximum
Standard Deviation
Median
Sum
Difference
Integration
Count
44
-------
Chapter 7. Alternative Configurations/Levels of RTC
There are several ways to categorize control systems and algorithms:
With respect to where the control decisions are made:
Local control is executed at a remote site and it does not depend on the communication with
the other facilities or other parts of the sewer system.
Remote control configuration means that the control actions at a remote site depend on, and
are influenced by, input that comes from a different location (most often central control
server). Therefore, in case of the communication breakdown, local control can still be
operating normally.
With respect to who makes the control decision:
Control can be manual (if the operator on site makes the decision)
Supervisory (if the operator in the central control room makes the decision on control at a
remote site)
Automatic (if the control logic and rules and programmed and made without the input of the
operator)
With respect to the timing of the inputs that are used for making the control decision:
Some control algorithms use only current and past (measured) information in order to make
the decisions about control; these algorithms are called reactive, or feedback algorithms.
If the control algorithms (also) rely on inputs that are not measured, but are computed as
predictions (forecasts) of the future variables (e.g., forecasts of flows, or rainfall), then these
algorithms are called predictive algorithms.
With respect to the scope of their control (what is being controlled by the algorithm:
Local algorithms control only one site
Regional algorithms control several sites
System-wide algorithms control all the facilities within the sewer system. Such algorithms
are frequently referred to as "global" control algorithms, however, the term system-wide is
more appropriate.
With respect to their inclusion of a mathematical model:
45
-------
Control algorithms that include a mathematical model, which must be executed online in
order to compute the setpoints and determine the control actions, are called model referenced
control algorithms.
Control algorithms that do not include a mathematical model executed online.
The following paragraphs will describe different options and configurations for RTC of sewer networks,
with different levels of complexity and cost, starting from the simpler configurations.
7.1 Local Manual Control
The first level of control is local manual control (Figure 7-1). The operator simply observes the instrument
readings at the control site/facility and makes manual adjustments. The only hardware/software (HW/SW)
components required for this level of automation is instrumentation and manually operated actuators or
controls.
I
Measurements,
Observations
-Inputs-
Measure men is,
Ob$erv3tion$
Gmpirts-
Disturbances
Figure 7-1. Flow diagram of local manual control.
The operator may examine both the outputs of the system (e.g., current flow through a gate) and variables
that could be considered inputs (e.g., level upstream of the gate). The operator uses his experience to make
adjustments. Since in this case the data acquisition system does not exist, the operator needs to observe the
measurements. In some situations, this level of control may be adequate. Experienced operators may
sometimes be able to observe and recognize some things that are not routinely captured by sensors (e.g.,
odor problems, some types of instrument malfunction, or excessive sediment deposits after a rain event).
The possible limitations of local manual control include:
The presence of the operator is required at the facility to observe the status and implement control
actions. This mode of operation is labor intensive for sewer systems that include many different
facilities that may need to be controlled.
46
-------
The operator can only observe what is happening at this one location and cannot easily assess and
consider system-wide conditions.
Control actions are slow; in case of emergency, it is not possible to react quickly. The actual control
actions for a given site are the same either way because the control action is dependent on the gate
motor or the pump. However, getting to the site to administer control is slow compared to remote
control.
Since many/most of the stations will be unmanned, the default controls will be static and very
conservative; therefore, the sewer network capacity is typically not utilized very efficiently.
For sewer systems that are not very complex and include only a limited (small) number of facilities that can
be controlled, local manual control may be adequate. However, many agencies are under financial
pressures to reduce and minimize staff levels. Additionally, there may be problems when experienced
operating staff leaves or retires. Such organizational factors can adversely affect the ability of the agency
to maintain the adequate level of operation by relying only on manual control.
Another potential issue regarding local manual control is that the sewer systems are undergoing slow but
continuous changes. Facilities are changed as a result of capital improvement projects or even temporary
changes due to maintenance activities. Such changes can impact the way a certain facility or the entire
sewer system will "behave" under different conditions and therefore the experience gained in the past may
no longer be entirely applicable.
7.2 Local Automatic Control
The next level of control is local automatic control (Figure 7-2). Under local automatic control, the rules
and algorithms for controlling the operation of facilities are programmed into the PLCs. The inputs to
these programs include the measurements taken locally at the station (e.g., flows, levels, equipment status)
and the outputs are the control signals for the local control elements (e.g., gates, pumps) at this station.
This is how most pump stations are normally operated; the level in the wet well is measured and used to
make operational decisions and run the pumps. This can be accomplished by placing either analog
controllers or digital (programmable logic) controllers (PLCs) into a station. Local automatic control can
perform quite well but only the local conditions are considered when control decisions are made.
Remote
Control
Elements
Figure 7-2. Diagram of components of local automatic control.
In the past, before the cost of computers decreased significantly, analog control devices were commonly
used for automatic local control. The signals from the sensors were connected directly to an analog control
device, and the outputs were wired to the actuators for the control elements. The control settings were
47
-------
difficult to change. In some cases, the analog control equipment remained in the stations even after the
PLCs were installed and the PLC interacted with the analog controller. However, it is more common today
to connect the PLCs directly to both the sensors (on the input side) and the actuators for the control
elements (on the output side).
The possible limitations of local automatic control is that the control strategy implemented at a specific
facility can only be based on the conditions at that specific location and does not consider system-wide
conditions. Since many/most of the stations will be unmanned, the default controls will be static and very
conservative; therefore, the sewer network capacity is typically not utilized very efficiently.
7.3 Control Modes that Require Remote Access
When communications and SCADA are implemented, two more control modes become possible:
System-wide (or "Global") supervisory control (Figure 7-3). Under this mode, the operator can
observe the system-wide conditions from the (often centralized) control console and control any
facility in the system remotely.
Central
SCADA
System
Figure 7-3. Diagram of components of supervisory control.
48
-------
Regional control (Figure 7-4). Control algorithms can be set up to control a section or part of the
sewer system automatically. This control mode can use remote process variables; for example, the
gate at one structure can be controlled using the level signal from somewhere else in the network (not
the local level in the same station). This would mean that the rules for operating one or more of the
facilities in the region have been programmed and implemented to run automatically on the Central
SCADA Server (without requiring operator intervention).
RTC Algorithm
for automatic control
of one or more of facilities
Central
SCADA
Server
w%
Data from the Field
1 Remote
1 Siten
Remote
Site 2
Remote
Site 1
CO!
Figure 7-4. Diagram of automatic (remote) regional control.
Both regional control and system-wide supervisory control offer a broad range of useful functionality.
System-wide (Global) supervisory control requires not only careful attention from the operator but also a
good understanding of the system dynamics. For complex urban networks, determining the most efficient
way to operate the facilities can be demanding and requires analysis and planning prior to developing the
system design. Regional control may not fully take into account the system-wide conditions because the
control logic is based on separate parts of the system and there is no consideration of system-wide
conditions.
49
-------
The next level up is system-wide automatic control (Figure 7-5). This control configuration includes a set
of algorithms running on a dedicated RTC server. The algorithms contain rules for system-wide, global
control of the network.
RTC Algorithm
for automatic control
of one or more of facilities
Central
SCADA
Server
;
Figure 7-5. Diagram of automatic system-wide global control.
System-wide, global control includes the development and testing of embedded algorithms and logic for the
(automatic) operation of the sewer network and the facilities. There are several options for the RTC
algorithms; the two main categories of algorithms include:
Logic based on operating rules. Such logic is referred to as "traceable" or "transparent" because the
rules behind the control strategies can be easily discussed with operations staff. The rules of operation
can be defined in such a way that everybody involved (including operations staff) has a good
understanding of what the rules for different control actions will be under different circumstances.
Logic based on optimization algorithms that minimize a certain "objective function" that is usually a
composite of one or more variables. The RTC based on optimization algorithms must include
50
-------
forecasting (of rainfall or flows) and also demands online models that execute in real time to calculate
the state variables for optimization. This control algorithm produces a set of control decisions based
on a mathematical procedure that minimizes the objective function. The objective function is a
quantified expression of our operational goals and in the process of optimization this function is
iteratively evaluated to "find" the strategy that produces the extreme (e.g., minimum) of the function.
In order to evaluate the objective function, optimization will demand advanced knowledge of the rainfall
(and the resulting inflows). Therefore, optimization falls into a broader category of predictive control
methods (Figure 7-6). Forecasts might be obtained in different ways; an example is by using a component
that provides forecasts of rainfall. Forecasts would make it possible to implement system-wide, global,
predictive control.
RTC Algorithm
for automatic control
of all of the facilities
Forecasting
Algorithms
-Predicted rainfall w Sews-
Central
SCADA
Server
Contraf
Efemente
Figure 7-6. Diagram of predictive system-wide ("global") control.
51
-------
There are some risks associated with using rainfall predictions online, as it is not clear that this technology
is at the point where it can be reliably applied. Although some improvements in forecasting rainfall have
been made, available methods are not yet at the point of providing reliable and accurate long term (e.g., 12
or 24 h) forecasts for high-intensity (e.g., storms with rainfall exceeding 1 in.) events. Forecasts can be
provided by radar systems or using a combination of rainfall gauges and black-box models (such as neural
networks).
One specific method for computing the system's control response that has gained high visibility is the
linear optimization algorithm. As shown in Figure 7-7, this algorithm requires that a hydraulic model of
the network runs online.
Optimization
Algorithm
Forecasting
Algorithms
Predicted rainfall or flews'
Objective function
evaluation
J
Centra!
SCADA
Server
Figure 7-7. Diagram of system-wide ("global") control using linear optimization.
52
-------
A typical, simplified layout of the components for an implementation of an optimization algorithm within
RTC is shown in more detail in Figure 7-8.
Sys'em
f
Inflows
(riydrographs)
Hydrologies I
(rwoff)
Modal
Desired
flows
Hydraulic
Rainfall
Rainfall
Prediction
S«"poin;s
lor control
Werner is
(e.g gale position)
iinitili %! teoar
SCADA
Figure 7-8. Diagram of conceptual layout of optimization in RTC.
As Figure 7-8 demonstrates, this algorithm requires both forecasting and the use of online models for the
network. The optimizing "engine" itself is normally an off-the-shelf software package; e.g., in Seattle
(King County) and Hamilton (Canada), this component was MINOS package from Stanford University.
Referring to Figure 7-8, a typical sequence of computation for online optimization is as follows:
SCADA system collects the data from the network (e.g., flows, levels, rainfall, radar forecasts, etc.) by
"polling" all the remote sites at regularly scheduled intervals. The polling (sampling) interval is
normally between one minute and five minutes for a sewer network.
The module for predicting rainfall reads the process (SCADA) database and computes the precipitation
predictions for the specified period of time (called the "prediction horizon"). These predictions can be
generated by different systems and algorithms and in some cases may include sophisticated hardware
(such as radar) or "black box" algorithms based on historical data (such as time series tools or neural
53
-------
network algorithms). The output from this module is the predicted rainfall for the duration of the
prediction horizon.
The predicted rainfall is provided to the models that can compute the predicted inflows to the network
during the prediction horizon. These inflow prediction models can be based on hydrological
relationships or other (statistical) models that relate the precipitation to the flows that come from the
drainage basins and enter the combined sewer network. The output from this module is the predicted
inflows to the sewer network during the prediction horizon.
The predicted inflows are included in the "system function" that describes the state of the system as it
responds to inflows and control decisions. This system representation is connected to the optimization
algorithm which tries to minimize the objective function (such as minimize overflows or minimize
peak discharge rates).
As the optimization algorithm searches for the best solution, it needs to compute the system state for
each of the alternatives (control settings) that it uses in the search for the optimal scenario. Therefore,
it needs to be integrated with the representation of the system that can mimic the behavior of the
system and produce the system state. This model of the system is executed online and is often referred
to as the "online model."
The online model can have different characteristics and sometimes simplified (linearized)
representations are used because of concerns related to the required computer execution time and
stability. In some instances, good results can be achieved by using a simplified hydraulic model that
contains only the main trunk lines, interceptors, and controls structures ("skeletonized" version) of the
network.
The optimization algorithm uses the results of the online model to produce a set of desired control
actions that are supplied back to the SCADA system (as setpoints) for implementation.
The optimization approach creates a significantly greater demand and expense for maintenance (of models
and computer programs) than the rule-based approach. As mentioned previously, the optimization
approach requires rainfall prediction.
In summary, with regard to forecasting, it is important to remember that optimization requires that forecasts
are provided. Optimization is only one possible way to utilize forecasts for RTC; forecasts can also be used
within a rule-based system, where operational rules are adjusted based on the forecasted rainfalls or flows.
The best choice of technology and approach depends highly on a number of site-specific factors that must
be taken into consideration. It is always prudent, however, to consider the most basic, simplest, and
cheapest alternatives first, and then assess the benefits and costs of each additional increment in complexity
and cost. A six-year old RTC system in Quebec City shows the specific details of the optimization
implementation in that particular application. A very similar optimization method was applied in Seattle
(King County) in the mid-1980s.
7.4 Managing Control Modes: Fail Safe Operation
One of the complicating issues about the RTC of sewer networks is that the operational goals change
depending on the state of the sewer network. During dry weather, for example, the objective may be to
minimize energy consumption, while during wet weather the most important goal may be to avoid
overflows. Under all conditions, there are critical constraints such as safe operation, avoiding damage to
the equipment, and avoiding flooding. A well designed RTC system needs to effectively manage the
different operational objectives and handle the transition between different operational modes in order to
provide reliable and efficient operation. An important part of RTC is the management of transitional
conditions and operational modes to avoid failure. A reasonable approach to this issue must (at a
minimum) address two major categories of risk; failure of equipment, and emergency conditions caused by
external factors. Each control/operational level requires that some components of the overall system are
54
-------
functioning properly. Table 7-1 summarizes which components of the overall system have to work
properly in order to support different control modes/levels.
Table 7-1. Components Required for Different Control Modes
Control Mode
Local Manual Control
Local Automatic Control
Regional Automatic Control
Supervisory Remote Control
Global Automatic - Rule Based
Global Automatic - Optimization
CO
c
CD
E
C
X
X
X
X
X
X
CO
0
Q.
X
X
X
X
X
CO
c
o
-i*
CD
0
X
X
X
!_ O)
o c
-i* i_
CD Q
CD ~
& °
CD ^
.> -H-T
< g
X
X
p
fV i
"cc 2
i= CD
CD
0
X
X
O)
= ~
« CO
C CD
TO CD
>2
X
CD
a
o
CD
O
X
Note: Forecasting may be part of rule-based system but is not mandatory.
The fail-safe procedures need to be configured so that they are triggered when the requirements for the
current operational mode of the system cannot be met. The fail-safe procedures need to be designed to
automatically place the system into the next (lower) mode/level of operation that can be fully supported by
the current state of the system components. For example, if the system is operating in the Local Automatic
Control mode and the PLCs malfunction or loose power, control would need to revert to Local Manual
Control. If the system is operating in Regional Automatic Control, failure of the SCADA system or the
central server should automatically trip the system into Local Automatic Control, etc. In case of Global
Automatic Predictive control using the optimization algorithm, failure can happen due to problems in any
one of the following components:
Sensors (flow meters, level sensors, rainfall gauges)
PLC malfunction
Loss of communication
SCADA failure
Central server problems
Errors or problems with forecasting
Online model failure or errors
Therefore, even if the ultimate goal is to execute a sophisticated control scheme, such as global predictive
optimization, it is a good idea to develop and test the "lower" levels of control that might need to provide
backup in case of emergency or component failure. This layered approach can provide the most
appropriate level of control for different conditions and helps to manage the overall risks.
55
-------
The risk management procedures also need to include the ability to deal with emergency conditions that
can be detected using the measurements in the field. Special rules can be defined to react to conditions
such as, rapidly rising levels in a part of the system. The response can be either an adjustment to the
automatic control strategy or a change of operational mode by providing the operator with the Standard
Operating Procedure for handling the emergency situation.
56
-------
Chapter 8. RTC Control Algorithms
An RTC algorithm is a set of rules that determine the control action that will be taken in response to the
conditions in the sewer network. The conditions in the network are defined by the levels and flows
throughout the network. Levels and flows are often called system variables and a "snapshot" of the
specific values for system variables at a particular time is often referred to as system state. In this section,
some of the commonly found RTC algorithms are presented and discussed.
8.1 Local Control Algorithms
Local control algorithms are rules that govern the behavior of a specific control element based on local
sensor data and implemented at location of the specific control (remote site).
8.1.1 Primary Controls
Many control elements (e.g., pumps, gates) are controlled using analog controllers. Analog controllers take
analog inputs (e.g., levels from a level sensor) and produce output signals that are delivered to the control
elements. The control logic is therefore "hardwired" within the electronics of the analog controller and
cannot be easily changed. Analog controllers also use discrete measurements (e.g., high-level alarm
switches) to start or stop (or open/close) the control elements. The operational logic within analog
controllers is usually based on rule curves for starting/stopping pumps or opening/closing gates based on
the measurements.
8.1.2 Programmable Logic Controller - Based Controls
PLCs include "industrial grade" processing power and provide the users with a programming environment
to define the control rules (algorithms). The most common way to implement local automatic control in
sewer system facilities is through using the Proportional Integrated Derivative (PID) feedback (reactive)
algorithm that comes standard with most modern PLCs.
As a reactive algorithm, the PID algorithm works by using the difference between the observed (measured)
value of the process variable and the desired value of the process variable. The process variable is the
variable that we are trying to control; the desired value for this variable is called the setpoint. In a pump
station, for example, the wet well level may be a process variable and the pump speed (and ON/OFF status)
would be controlled to achieve a setpoint (a specific value of the wet well level). The general form of the
PID algorithm is:
u(t) = uO + K* [e(t) + \e(T)dr + Td <
\ / L \ / rj-,. I \ /
Tli
Where:
u(t) = controller output at time t
K = controller gain
e(t) = "process error," or difference between process variable and setpoint
57
-------
Ti = integral time constant
Td = derivative time constant
As can be seen from the above equation, the PID algorithm adjusts the output of the controller in three
different ways:
The Proportional part reacts directly and proportionally to the process error (the difference between the
process variable and the setpoint); the bigger the process error, the stronger the controller reaction.
The Integral part is used to address, in a way, the history of the process error; i.e., as the process
decreases, the proportional reaction is decreased as well. Therefore, the integral portion of the PID
controller helps the controller adjust to small but persistent differences between the setpoint and the
process variable.
The Derivative part addresses the direction of the process error and in a way adjusts the controller to
the perceived future values of the process error. This component of the PID algorithm is generally
intended to speed up the controller and make it more "agile," but in practice it is rarely used because it
also can result in unstable behavior of the controller.
The description above is a simplistic, "textbook" explanation of the PID algorithm. Setting up a PID
algorithm for optimal performance requires a good understanding of the control theory and an
understanding of the underlying process that is being controlled. In practice, algorithms are usually
configured based on experience and the algorithm parameters (K, Ti, and Td) are configured for a stable
and predictable, rather than optimal, operation. PID is the most common algorithm in process control. It is
described in considerable detail in many publications.
8.2 Selection of System-Wide Control Algorithms
A brief summary discussion of several different system-wide control algorithms has already been provided
elsewhere in this document. In this section, some general thoughts are presented to facilitate the process of
choosing between these different options.
There is no single best choice of algorithm that could be recommended to fit any RTC application. Every
RTC application will face site-specific challenges and the choice of the most appropriate algorithm will be
influenced by the following factors:
Size and complexity of the sewer network and the overall hydraulic conditions and dynamics
Topology of the sewer network and the general flow pattern ("looped" flow with many
interconnections or "dendritic" flow pattern without many interconnections)
Inline storage opportunities. (Are they concentrated in some storage facilities or distributed as inline
storage along the sewer network? Where in the network are major storage opportunities located?)
Organizational issues, including the inhouse expertise and resources available for hydraulic modeling,
RTC development and implementation, and for future maintenance/support of RTC
Budget constraints, both short term and long term
Overall IT maturity of the organization, status of legacy IT applications (e.g., how stable is the
SCADA system?)
Number, complexity, flexibility, and operational experience with the final control elements (e.g., gates,
inflatable dams)
58
-------
Organization's experience with instrumentation (e.g., will RTC system use existing instruments or will
mostly new instruments need to be installed? How well established are the processes and the funding
for maintaining the instruments?)
Organization's experience with (any type of) RTC of their sewer network (e.g., are local control
strategies well established and is there significant experience with using final control elements on the
local level? To what extent is their treatment plant run by similar RTC systems?)
The algorithm may also be impacted by the nature of events that RTC will need to deal with (longer
duration, lower intensity events, intense shorter duration events?)
The operational objectives may change depending on the state of the sewer network. During wet weather,
the main objective may be to reduce CSOs; during dry weather, the objective may be to save energy (e.g.,
pumping costs). There may also be a transition period where during the transition from wet to dry flow the
objective may be to dewater the storage slowly enough to maximize the total treated volume through the
secondary system at the plant. In some cases, therefore, it is not unreasonable to consider different control
algorithms for different conditions (e.g., dry weather flow, low intensity event, high intensity event). Some
of the specific decisions to be made regarding the system-wide control algorithm may include aspects
presented in the following discussion.
8.2.1 Reactive Systems vs. Predictive Systems
Introducing forecasting may improve performance but will add complexity to the algorithm. Forecasts of
rainfall deteriorate with the length of the forecasting horizon and forecasts are also less accurate for larger
storm events. It is important to remember that rainfall forecasts are not the only way to predict flows/levels
in the sewer system. It is also possible to use current measurements (e.g., rainfall and levels in some parts
of the network) to forecast levels and flows in the network. For an example of such forecasts, see Heinz
and Schultz (2006) (Milwaukee). Since forecasting increases the complexity of the system, benefits over
the simpler reactive system should be identified in order to justify the additional complexity and expense.
8.2.2 Automated Rules vs. Optimization
Rule-based systems are transparent and can be easily understood by the operators. Optimization algorithms
require forecasts, online models, and the algorithm itself is not readily transparent to the operators. In
general, optimization algorithms must be proven to offer sufficient additional operational benefits to justify
additional resources for the development, implementation, support, and maintenance. Also, it is important
to remember that the word "optimal" is often used in colloquial language with the meaning "the best
possible or available." However, in this case "optimal" translates only into one specific mathematical
procedure (optimization) and it should not be misunderstood to mean "the best possible" overall approach
to this specific problem.
It would be difficult to specify the exact and straightforward generic (non-site specific) selection criteria for
choosing the most appropriate algorithm for RTC. Such a decision requires careful consideration of several
different factors such as:
Is the system running "close to full" even during dry weather? In such a case, it will be difficult to
obtain benefits from RTC of any kind and additional ("brick and mortar") storage will be required.
Using modeling and simulations, different RTC approaches (and algorithms) should be considered as
part of the planning and design of new facilities.
What is the situation with online measurements (e.g. , flows and levels)? Have these sensors been
properly maintained in the past? Are there plans in place to maintain them properly in the future?
Online measurements are the foundation of the RTC system. An organization that does not have a
strong commitment to keeping the online sensors up and running should be very careful when
considering automation.
59
-------
Is there enough historical data to calibrate the models and provide for a meaningful analysis of system
dynamics? Without such data, it will be difficult to build models, and thus assess the impact of
different RTC strategies.
What is the history of communications and SCADA systems in this organization? Have these systems
been implemented? Have they been operating reliably? Again, automation should be applied
cautiously if there is a history of problems with systems that provide the necessary infrastructure for
RTC.
Does the organization have experience with dynamic ("movable") control elements? One organization
discovered that a major control facility (gate) was wired incorrectly: indicators were showing "open"
when the gate was actually closed, and "closed" when the gate was actually open. This gate operated
this way for years and nobody noticed it. There are obviously risks associated in automating such a
facility.
Is the hydraulic nature of the problem complex? For example, most of the overflows may be
concentrated in very few facilities. Therefore, most facilities may not have much of an impact and
spending money for their automation may not be effective.
Will the organization make the financial and organizational commitment to maintaining a complex
piece of software?
Rule-based systems are generally more intuitive, less complex, and they introduce a significantly smaller
maintenance burden. Clear operational benefits from optimization over rule-based systems should be
identified to justify the additional complexity and cost. Since forecasting is part of optimization, there
should also be sufficient confidence in the forecasting methods.
Rule-based systems can also be more flexible. Optimization requires that the objective function is
(mathematically) formulated. In many cases, such objective function focuses on reduction of overflows.
The operational objectives, however, may change depending on the state of the system. During dry
weather, for example, the objective may be to save energy. Heuristic rules can easily consider different
objectives and their transparent nature makes operator involvement easier.
60
-------
Chapter 9. Design/development Methodologies for RTC
This chapter addresses the steps in developing an RTC system. Not all systems will include all the phases
listed below. The appropriate level of RTC, and the appropriate level of investment into RTC, depends on
the specific aspects of each collection system. The steps listed are generic and the activities can also vary
in their scope and size.
9.1 Considerations in Planning
The need and proper application of an RTC system is best understood in the context of a plan for how the
overall collection system is expected to operate. A System Operations Plan (SOP) defines the operating
strategy for the major facilities in the collection system during dry weather and wet weather conditions as
well as the transition phases between dry and wet weather. The SOP shows how the existing and future
collection system components (including static, local, and remotely controlled facilities) will operate to
achieve specific operational objectives. By considering the entire system operations, the need and
functional requirements for RTC become more evident and understood. The SOP should be developed
and/or updated as part of the design of new sewer facilities that may require real time controls. The SOP
will likely identify additional communications and controls that are necessary for system operations and
should be implemented along with the new facilities.
An SOP should provide the descriptions, graphics, and supporting information for the following elements:
Regulatory and performance objectives that are to be achieved by the collection system. Operational
objectives include minimizing overflows, minimizing energy consumption, minimizing sediment
deposition, and maximizing the volume treated through secondary treatment. Operational objectives
are discussed more thoroughly in Section 9.3 below.
Overall collection system layout including the location of major control facilities such as diversion
structures, interceptor conduits, pump stations, and treatment facilities.
Development and evaluation of various scenarios that have been simulated via a hydraulic model and
evaluated according to how well they meet the regulatory and performance objectives.
Functions of each major control facility during dry weather conditions, transition to wet weather
conditions, wet weather conditions, and finally the transition to dry weather conditions.
Function of the overall integrated system (each component working together) during dry weather
conditions, transition to wet weather conditions, wet weather conditions, and finally the transition to
dry weather conditions.
Location and function of the monitoring and communication systems necessary to inform the operators
and provide control over the collection system to achieve the operational objectives.
Recommendations, including expected implementation schedule and costs. Implementation may
include a more extensive RTC feasibility study to better define the design requirements of the control
system.
61
-------
9.1.1 Development and Evaluation of Operating Scenarios
As part of the system operations planning process, a variety of operating scenarios should be developed and
evaluated to determine the benefits, costs, and impacts of different levels of automation and control at the
key facilities. At this point in the process, it is useful to examine each structure and determine if a simple,
low-tech solution will sufficiently meet the objectives, and determine if there are significant benefits and
capabilities provided by a more sophisticated control system that justify the costs. As applicable, each key
structure can be examined for different levels of control:
Fixed or static controls, such as an orifice and a fixed weir
Manually variable controls, such as a stop-log weir or a moveable gate
Automated local controls, in which a gate or pump is controlled based on the local sewer level
Automated remote (centralized) control, in which gates and pumps are controlled from a central
location using remote sensing to determine the state in the sewer at multiple locations and make
control decisions based on that current state
Predictive centralized control, in which decisions for gates and pumps are controlled based on the
current state and the hydraulic modeling predictions using rainfall forecasts
Upon reviewing these levels of control for different facilities, the simplest level that will cost-effectively
achieve the operational benefits should be selected and recommended for use in the SOP.
While examining each structure or facility, the scenarios should also examine system-based options for
achieving the operational objectives. Scenarios containing typical system-based options may include:
Flow-routing options: Examine different routes for flow to be directed in order to conserve energy
consumption (via pumping), maintain scouring velocities through all conduits to minimize sediment
deposition, and provide odor control by keeping septic sewage away from populated areas.
Flow-source options: Examine different strategies to capture flows from specific sources while
minimizing flows from other sources. For example, examine different methods to capture priority
flows from an SSO source versus a CSO source versus a stormwater source.
Flow-equalization options: Examine methods to minimize the rate of change in flow to the treatment
plant during both dry and wet weather conditions. These would include different flow routes, pump
controls, and use of inline and offline storage.
Dewatering Options: Examine various rates for dewatering stored wet weather flows in order to
maximize the total volume of sewage treated through the secondary system while also preventing the
formation of septic conditions (odor, H2S, and biological impacts) and preventing unnecessary
overflows resulting from back-to-back storms that occur before the storage facilities have been
emptied from the previous storm.
When examining the individual structures or the system-based options, the evaluation should include
appropriate hydraulic model simulations, evaluation of benefits (compared against operational objectives),
estimation of costs, and a decision making process to select and recommend specific controls and operating
strategies. Although the final SOP does not need to contain all the documentation from the development
and evaluation of scenarios, it must include the recommendations and the basis (justification) for those
recommendations. In some cases, automation of a structure may be recommended due to organizational
preference and efficiency as opposed to minimum costs in that it may be preferred by an organization to
provide remote control of a gate rather than send out an operator on a weekly basis to change the gate
setting.
62
-------
9.1.2 Weather Conditions to be Examined
The SOP will naturally examine the operational strategies for dry weather and wet weather conditions.
Each operational objective can typically be classified as either a dry weather objective or a wet weather
objective or both. The duration of the dry weather period is typically longer than the wet weather period,
yet both last sufficient time to justify close examination of the expected system performance during each
condition. It is also important to closely examine the transition phases between the dry and wet conditions
because that is where some of the most difficult questions arise. Some of these questions include:
What system measurement or event triggers the end of the dry weather condition and the start of the
wet weather condition? What measurement determines that the wet weather event is over?
What is the sequence of response actions that should be implemented once a wet weather event is
triggered? And when the wet weather event is over?
How does the prioritization of operational objectives change as the system moves from the dry weather
objectives and changes over to the wet weather objectives?
For these reasons, it is important for the SOP to cover at a minimum:
Dry weather conditions (can be further examined as "summer dry weather" and "winter dry weather"
conditions)
Transition to wet weather conditions
Wet weather conditions (can be further examined as "wet weather - prior to overflow" and "wet
weather - during overflow" and "wet weather - flooding" conditions)
Transition to dry weather conditions
9.1.3 Considerations for the Project Team and SOP Document
The engineering planners and designers will typically lead the project team assigned to develop the SOP
because it is often a component of a larger facilities design that will significantly change the operations of
the collection system. However, the targeted audience for the SOPis primarily the operations staff who will
be taking control of the collection system once the new facilities are completed. Therefore, it is necessary
to have operations staff on the project team, sharing responsibility for developing the plan as well as
providing extensive review of the documents. Because of the complexity inherent in the functions of a
collection system, it will be necessary to strive for simplicity and clarity in the descriptions of the operation
strategy. For example, the operations manager of a 300 MOD POTW required the project team to
summarize the operations plan in the basic terms of: "Is it a "Pump First - Store Second" strategy or a
"Store First - Pump Second" strategy, or something entirely different?" The project team was able to state
it was a "Pump First - Store Second" strategy and went on to describe how each system component
supported that overall strategy and how it met the operational objectives.
The SOP will also provide extensive information for the engineering staff charged with designing the RTC
infrastructure. The SOP can be used to develop monitoring specifications, PLC and control panel
requirements, as well as control narratives for operating each of the major structures. The process for
designing the RTC infrastructure is presented next in Section 9.2.
9.2 RTC Infrastructure Design
The foundation of any RTC system includes the instrumentation, online SCAD A, and control facilities
(e.g., gates, weirs, valves dams). In many cases, the infrastructure that supports an RTC system will exist
before RTC is considered or developed. Design practices for the components of this infrastructure are
covered in detail in different sources and are beyond the scope of this report. This report focuses on the
development and implementation of RTC strategies, assuming that the required infrastructure is in place.
63
-------
The process for designing RTC usually includes the following stages:
Feasibility study, to determine whether there are opportunities for RTC to improve the operation of the
collection system, including the definition of the operational goals, the development of hydraulic
models for the collection system, the analysis of system hydraulics, and preliminary investigations of
(the impact of) some potential RTC strategies.
Detailed analysis of different control strategies and selection (or design) of the most appropriate RTC
algorithm, including model simulation and offline testing. Different strategies are simulated using the
model results (levels, flows) as inputs and their performance is evaluated using the model results.
Strategies are evaluated using the performance metrics discussed in the next section.
If necessary, design and installation of additional sensors and/or field automation components
(PLCs/RTUs).
Possible upgrades to final control elements (e.g., adding remotely controlled actuators to gates) along
with applicable field testing of control elements.
Development and programming of RTC algorithms.
Installation of RTC algorithms into the online environment.
Supervised online testing and training.
Online startup and implementation of the RTC system.
A brief summary of the key RTC implementation tasks is presented below.
9.3 Defining Operational Goals and Performance Metrics
In many cases, RTC is at first assumed only to be a method for reducing wet weather overflows during
heavy rains. However, operators need to deal with many other issues and operational goals are often more
broader and more complex than just reduction of wet weather overflows. An important component of a
RTC project is to determine the most important operational goals and operating constraints. This should be
done in the very early stages of the project, as these goals and constraints will be the foundation for all
technical activities. The methodology to determine the operational goals and constraints includes the
following:
Study the operational manuals and documentation on the current operational strategies
Conduct structured interviews with staff at different levels of the organization
Examine regulatory requirements and guidelines for new facilities being implemented (i.e., EPA CSO
Policy and Guidance, as well as state requirements for implementing CSO facilities)
The result of this research will be a prioritized list of objectives. An example of such a list, from the RTC
project at the Milwaukee Metropolitan Sewer District (MMSD) Project Report is as follows:
"The evaluation of different operational alternatives was done within the framework of the stated
operational objectives, listed below in the order of importance:
Minimize Basement Backups
Minimize Potential for Sanitary Sewer Overflows (SSO)
64
-------
Minimize Risk of Failure
Minimize the Number of Combined Sewer Overflow (CSO) Events
Maximize Long- term Sustainability
Minimize CSO Volume during CSO Events
Use the Inline Storage System (theMMSD deep storage tunnel) Effectively
Minimize Operating Costs with No Adverse Consequences to Other Objectives"
"During the objectives definition process, certain elements of system operation were identified as
operating constraints rather than objectives. These constraints include:
Comply with all requirements of the Wisconsin Pollutant Discharge Elimination System (WPDES)
permit.
View the Jones Inland Wastewater Treatment plant (JIWWTP) and South Shore Wastewater Treatment
Plant (SSWWTP) treatment capacities as externally defined variable-operating constraints, which will
be provided as inputs to the strategy.
The WPDES permit contains operating requirements for the ISS, which include: The ISS cannot be filled
above the crown of the ISS main tunnel (elevation equal to -177.17 feet, MMSD datum) at its upstream
terminus. The ISS shall be operated in a manner that ensures a net positive head. Holding time within the
ISS should be minimized so that the likelihood of compliance with the net positive head requirement is
maximized.
The wastewater influent capacities at the JIWWTP and SSWWTP will be treated as input constraints to the
RTC strategy. These wastewater influent capacities are assumed to be available to the strategy at all times.
Because capacities can change at any time, for example, if a major treatment unit fails and is taken out of
service for repair, the strategy will need to respond accordingly. "
Prioritized operational objectives and constraints can serve as a critical guide for the development of the
RTC strategy, but are not sufficient. In addition to establishing the goals and the constraints, it is very
useful to quantify them by establishing the metrics. An example of metrics, from the same report and
linked to the operational objectives listed above, is shown in Table 9-1.
Once the metrics are established, they are used as a basis for comparison between different scenarios,
strategies, and operational alternatives. As can be seen from the above example, a number of the objectives
listed can be assessed based on simulations; they are included in the hydraulic model results.
Some of the objectives are not linked to hydraulics; for example, from the list above, the operational
objective to maximize long term sustainability reflects the desire to implement an RTC system that does
not impose an unreasonable maintenance burden after implementation. Such objectives may not have a
clear and straightforward metric but are important and need to be considered as well. In this particular
case, an RTC design must always consider simpler algorithms before more complex and demanding
algorithms.
9.4 Analysis of Hydraulics
In order to effectively plan and implement RTC in a sewerage and stormwater system, it is essential to
understand the hydraulics of the network. In this regard, computer models provide the opportunity for well
structured analyses and offer a scientific framework for coordinated management and planning of RTC.
65
-------
Hydraulic models provide two key capabilities; simulations are used to compare different operational
scenarios and such analysis also enhances our understanding of the network dynamics and behavior under
different conditions. Urban drainage models are used to understand the rather complex interaction between
rainfall and network hydraulics. Once the existing conditions have been analyzed and understood,
alleviation schemes can be evaluated and the optimal control scheme can be designed and implemented.
Table 9-1. Metrics for Simulation Type
Operational Objective
Minimize basement backups
Minimize potential for SSOs
Minimize risk of failure
Minimize number of CSO events
Maximize long-term sustainability
Minimize CSO volume during CSO
events
Use the ISS effectively
Minimize operating costs with no
adverse consequences to other
objectives
Metric
Flag activation frequency
Did an SSO occur?
Dependence on mechanical
devices
Did a CSO occur?
Reproducible strategy
development procedure
Volume of CSO (MG)
Volume left in ISS when event
ended (MG)
No metric
Model Analysis Approach
Check maximum water levels at
each critical node
Determine if SS gates close in
the result file
Number of gate and pump
activations and hours of pump
operation
Determine if CS gates close in
the result file
Not a model outcome
Add discharge at every CS gate
to determine total CS volume in
the result file
Total ISS volume minus
maximum volume stored
Not a model outcome
A model is a simplified mathematical representation of the physical system. This representation may be
based on a deterministic approach (i.e.,with a fixed relationship that includes known mathematical
descriptions of the underlying processes), or it could be stochastic (i.e., involving terms of probability into
the model inputs and the interpretation of model results). Models for urban drainage and stormwater are
predominantly deterministic models; the text below will refer only to this class of models. Furthermore,
deterministic models applied for urban drainage can be roughly classified as physically-based models and
conceptual models. Attributing a model to one of these classes depends on the level of mathematical
sophistication in the treatment of underlying physical processes in the model. Practically, the models are
classified according to the importance of empirical parameters for the models' ability to describe these
processes accurately. The reliance on empirical parameters classifies the model as conceptual and
emphasizes the need for validation against field measurements. In this context, various hydrological
models would belong to the class of conceptual models, while a hydrodynamic network model is an
example of a physically-based deterministic model.
Urban drainage models are expected to reproduce behavior of the modeled system with a high level of
accuracy. This is usually ensured through the process of parameter calibration and the verification of
model results against the measured performance of the real system. Calibration involves adjustment of the
model's key parameters, under the objective of minimizing the differences between the model results and
the field measurements (e.g. , of water levels). A continuous period or a set of intermittent events used for
calibration should preferably include a full range of expected operational conditions in the system.
Verification provides a proof that the model generates results within the acceptable error range. A reliable
66
-------
verification should be carried out for a simulation period or intermittent event(s), which are different and
independent of those used for the model calibration.
All models must, if possible, be calibrated before application. Conceptual models require more attention in
this respect compared to fully deterministic (physically-based) models and the assumptions of the
conceptual models must be proven valid. Thus, in urban drainage modeling, focus of model calibration is
usually based on correcting and adjusting the parameters in the hydrological models (conceptual), while the
deterministic hydrodynamic models of the drainage network typically require just minor adjustments for an
accurate performance. However, independent of the applied model type, a good modeling practice
recommends thorough model verification before any serious application.
Reliable field measurements in the sewer system and laboratory analysis results are essential for successful
model calibration and verification, i.e., for the model application as the whole. Harsh environment in
sewers and urban drains (presence of poisonous gases and pathogen microorganisms in confined conduits,
aggressive fluids, floating debris), as well as particular hydraulic conditions (alternating free-surface and
pressurized flow, rapid flow surges, etc.) require special monitoring equipment and highly trained
specialists for achieving good results. Routinely measured variables include water level, flow velocity,
flow rate, conductivity, temperature, pH, H2S, etc. Chemical and biological properties of the water, as well
as sediment characteristics, are obtained by manual or automated sampling, followed by laboratory
analyses.
The standard of hydrological and hydraulic models today is that they are able to simulate flow though all
important parts of a hydrological and hydraulic network. Thus, dynamic hydraulic models can typically
describe processes such as surface runoff, infiltration, and the hydraulics of pipes, channels, weirs, gates,
pumps, etc. It is outside the scope of this document to provide a detailed description of all of the elements
that may be found in an urban drainage system but the text focuses on the description of the flow equation
applied to describe the hydraulics in the pipes and channels. Since stability of the model is an important
factor in simulating operational changes, it is important that the model can handle all dynamic conditions
normally encountered during operation. Models using implicit (as opposed to explicit) methods generally
provide a better platform for RTC design and evaluation.
9.5 Offline Analysis of RTC
The planning process of RTC can typically be divided into a number of steps as outlined in Figure 9-1. The
first is naturally to formulate the objectives in terms of drainage system functionality, operations, and
environmental impact. As a support for any further analysis, a set of statistical performance descriptors,
which describe the defined objectives, have to be defined. For example, if the objective is to reduce the
CSO overflow, then the descriptor could be the frequency of CSO. Another typical example could be the
area of flooding, the load on the treatment plant, pollutant emissions area to the receiving waters, etc.
The development of a hydrological and hydraulic model of a complex urban drainage system for a large
city is an elaborate process. This process includes a number of activities, focused on the transformation of
the operator's practices and experiences, raw data set, and other available knowledge about the system
(PLC, previous setpoints, etc.) into operational simulation models of the system, capable of reproducing the
actual system functionality. The developed models may differ in the area of geographical coverage and the
level of modeling detail, all according to the intended purpose. A typical "layout" of the modeling tools for
offline evaluation of RTC is shown in Figure 9-2.
67
-------
PLAHHIHG OF AN UPS AH DRAINAGE RTC SYSTEM
AS A PART OF AM OWRAM, SOLUT10H
ST6 P1:
FORMULATION-OF OBJECTIVES
MTERMS Of:
-drainage fuictional if y
'trw«fenm*ntil impact
STEP2:
ASSESSMENT OF PRESENT SVSTEM
PERFORMANCE UMOER PRESENT AND
FUTURE WADS vs.
SPEC1FIEDOBJECTIVES
STEPS:
'VALUATION OF FEASIBLE ALTERNATIVES
AND
SEIEGTIQN 0 F THE BEST S-OtLTriQ N
SIE P4:
DETAILE D BE SIGN OF THE SYSTEM
Figure 9-1. Schematic of RTC planning process steps.
Often, the initial task within the context of numerical modeling activities is the development of a reference
model of the city's sewerage and stormwater system. The reference model should comprise the entire
sewerage system of the city and should be based on the existing asset database and operating procedures.
The reference model should provide a detailed insight into the storm and sewerage system in terms of
structural composition, connectivity, specific sites, existing local and system-wide control algorithms, etc.
As such, the reference model is used as a reliable foundation for subsequent modeling activities. It is
important to insure that data asset analyses and consistency checks must be integral activities of the
reference model development. Data consistency and quality are essential conditions for successful model
performance. The wastewater asset data obtained from the source database must be examined for
inconsistencies and for obvious errors. Any inconsistencies found must be investigated in the field and any
survey work deemed necessary in order to provide the missing information must be organized.
The next step in modeling activities is the development of operational models, which will form the
foundation for further analysis. The reference model (described above) should be used as the source for
this development. Establishment of operational models would often be realized through a series of
activities as outlined below, although the actual selection of project activities depends on the specific
project characteristic.
68
-------
Dynamic
Hydrology
Data
Time Series
Hydrology
Model
Dynamic
Hydraulic Model
Database
Settings for
control elements
(e.g, gate positions)
Intov* into
-Conveyance -
Network
Hydraulic
Modei
Setpoints,
commands for
control elements
RTC
Algorithm
(Stnstegy)
_ Levels Jems
In the network'
Drainage Basin
Characteristics
Characteristics
of network
(e.g. topology, geometry)
Static
Hydrology
Data
Static
Hydraulic
Model Data
Figure 9-2. Components of offline simulation environment for assessing RTC.
The first activity will typically aim at giving an overview of the hydrology within the total catchment area,
and specifying the hydrological load. In some cases, it is important to extend the hydrological description
to a model concept that takes into account the direct surface runoff and overland flow, as well as the slow
response component caused by infiltration into the sewer system from the surrounding soil. The latter load
component depends strongly on the hydrological history, i.e., on the preceding events. Once the hydrology
of the system has been defined and modeled, it is followed by the development of pipe models. The
development of the pipe (network) hydraulic model is often separated into several stages, such as:
Development of main trunk sewer model
In very large cities it may be advantageous to develop operational sub-models, based on the sub-areas
identified within the main trunk model
Integration of the sub-models into a general operational model
The purpose of the main trunk sewer model is to establish a global hydraulic description of the system.
The main trunk sewer model will usually include the following key elements:
Main trunk sewers and some secondary sewers as identified
Important storage facilities and elements
Significant overflow structures located on the trunk sewers
Significant pumps located on the trunk sewers
69
-------
In many applications it is fully sufficient to develop a trunk model, while in very large cities it may be
necessary to separate the main trunk sewer model into hydraulically independent areas. For each sub-area,
a more detailed operational model may be developed. The purpose of these sub-models is to provide an
accurate, yet rational, hydrological-hydraulic description of the drainage system functionality in all
operational conditions for all individual sub-areas and to enable efficient hydraulic analyses of individual
structural and functional upgrades in the area of concern. The appropriate level of modeling detail should
be defined in close cooperation with the municipality staff and on the basis of experience from similar
projects. Finally, all the different sub-models could be merged into one comprehensive model covering the
entire system.
Calibration and verification of computer models is often a very complex and critical step of the model-
setup process. The level of confidence in the models, and subsequent recommendations based on the
models, is a direct function of how well the models are calibrated and verified. The amount of time
required to calibrate the models is dependent on the amount and quality of the monitoring data and the
effects of the various assumptions and simplifications regarding the layout and size of the network. For
example, the exclusion of many of the minor branches may require addition of compensation storage or
capacity.
The confidence level of model outputs will largely depend on the spatial extent of the flow and level
monitoring and the magnitude of the rainfall events. A relatively high number of flow monitoring sites
would be required to establish the spatial distribution of both wastewater and stormwater sources. The
paucity of flow monitoring data within these areas will necessitate assumptions, which will influence the
validity of the hydraulic models. Water consumption data for sub-basins should be adopted for calibration
of the models for dry weather flow conditions.
Calibration of each model is typically done as follows:
Calibrate the model to dry weather flow conditions (full diurnal patterns)
Calibrate the model according to the below mentioned selected type of rain events
Verify model calibration to other independent wet weather events
The adequacy of the calibration should be consistent with the manner in which the collection system has
been represented in the model and the quality and applicability of the measured rainfall and flow data used.
The developed models should, at a minimum, be calibrated and verified against:
A short extreme rain event
A long term rain event
Two rain events which show large spatial variation
After the evaluation of the present system performance has been completed, the next step is to select the
RTC sites and evaluate different feasible alternatives for RTC strategies.
Review of the potential RTC sites may include both physical condition limitations and hydraulic
performance constraints. As outlined in the previous chapters, potential RTC sites are selected with
consideration of available storage within the system, uneven loading on the system, and critical diversion
(flow-splitting) structures in the system, etc. Physical condition limitations of the RTC sites include, for
example, the stability of the pipe bedding to support insystem storage, the structural integrity of the sewer
to withstand potential hydraulic surges and prolonged period of surcharge, and adequate space for the
installation and maintenance of RTC control devices. It may be necessary to perform site visits to identify
potential physical limitations. Often, RTC strategies are designed based on simulation of events. However,
70
-------
long-term continuous simulations are also frequently carried out to confirm the suitability of the RTC
scheme and its impact on the long-term system performance.
It is difficult to define a fixed, unique, prescribed list of simulations that should be conducted as part of
offline analysis. A brief summary of generic ideas regarding offline RTC analysis is listed below:
Perform simulation of the existing system (under current control strategy) for a range (light - medium
- heavy) of rainfall events. The purpose of these initial simulations is as follows:
Establish a reference that any future simulations of potential RTC strategy will be compared
to (based on defined operational goals).
Identify the "gross" storage limitations of the existing network. For example, if the pipes are
close to full all throughout the network even during a small event, the potential for using
"existing storage" will be limited.
Examine the spatial variability of storage; where is the "available storage volume" located?
Examine the distribution of wet weather overflows; are they concentrated around just a few
facilities?
Examine parts of the model where additional pipes may need to be added to the model; for
example, if a conduit connecting to our network is not currently modeled in detail, but it
appears that it is significant from the hydraulic point of view, the model may need to be
adjusted.
Prepare simulation runs that include potential "candidate" RTC strategies that will be examined.
Every simulation run will build on the lessons learned from the previous simulation. Modelers and
engineers can make better progress if they bring experienced operators into this process and discuss the
proposed strategies with people who have experience in running the "actual" system.
Present the operational objectives represented in the models and the results of simulations to the
operators and solicit their ideas. Sometimes, people will practical experience will point out why a
strategy that looks good "on paper" may not be a good idea and they can provide other ideas that they
have developed to address similar operational objectives.
Always start simulations from simpler, "lower cost" alternatives that would require fewer changes to
the existing infrastructure. An example of such progression is presented below:
Simulate the network configuration as is and only change the operating rules/strategy for
existing control elements
Consider simple operating rules first
Gradually increase the sophistication of the RTC approach and assess the benefit of each
added "layer of complexity" to the RTC approach
If additional sensors may improve RTC, add the sensors into the model
Consider automating existing facilities (e.g., adding a remotely operated gate actuator)
Consider physically upgrading existing facilities (e.g., adding a gate where one does not exist
currently)
Consider more expensive network modifications (e.g., adding a storage tank)
71
-------
It is important to always frame these analyses within the context of the costs and the operational goals, as
described in Section 9.2.
9.6 RTC Implementation
As is the case with many other types of IT systems, the best methodology for the implementation of a
specific RTC system is the one that is based on, and remains focused on, the underlying business needs.
The methodology for implementation also needs to recognize the specific issues and conditions of the client
organization. This means that we must always focus on the primary user, the operations staff and their
needs. Since sewer networks (in different cities) are different from each other, and the business issues and
drivers for RTC vary from one municipality to the next, there is no single recipe for RTC implementation.
However, there are some general guiding principles that may be applied to most RTC implementations, as
follows:
Phased approach works very well for RTC. It is unwise for an agency that does not have much
experience even with basic RTC components (e.g., SCADA systems or instrumentation) to consider
moving to sophisticated RTC technology without some carefully planned transition.
Simple control strategies should always be considered first. The fewer things can go wrong, the more
stable RTC will be. Any change towards more sophisticated algorithms, and/or more complex RTC
systems, should be incremental and should be considered on its own cost-benefit merits.
Implementation needs to include carefully planned testing phases, including offline testing, and online
startup and testing. Operator training needs to be part of these testing phases.
It is critically important to involve the users (operators) in the development of RTC as early as possible
and to continue that full involvement through implementation. Otherwise, the RTC system may not be
embraced and accepted by the users.
The methodology for implementation needs to recognize the specific issues that each client has. In
many cases, obstacles to successful RTC implementation are not technical but political (e.g., users may
not accept the system). Therefore, implementation methodology needs to recognize the organizational
aspects of the municipality and it should not go "against the cultural grain" of the organization.
For the long-term viability of RTC, it is also essential to develop good documentation both on the
"programmer" level and on the "user/operator" level. Although intense training classes (short courses) are
very useful, it is best if the users (e.g., operators) can be introduced to the technology throughout the
duration of the project, through meetings and workshops, so that they can gradually learn and adopt the
RTC technology and tools. A hands-on, one-on-one training program for the operators during system
startup is critical to the adoption of the RTC system by the permanent users.
9.7 Hydraulic Analysis Tools for Urban Sewer Networks
Hydraulic models can play different roles in designing and implementing an RTC system. During the RTC
design process, hydraulic models are used to simulate different operational scenarios so that different RTC
strategies can be compared against each other. Hydraulic models can also be implemented online and
embedded into the solution as part of the actual RTC strategy (algorithm). Some hydraulic models are
better suited for RTC design or implementation than others. However, the capabilities of hydraulic models
that are available in the marketplace change from one product release to the next, so statements regarding
specific modeling products that are provided by different vendors would only be valid for a specific period
in time. In general, however, there are some features that make the model well suited for RTC, as follows:
Since operation of control elements to take advantage of the available inline storage will introduce
backwater in some cases, it is important that the hydraulic model is based on the dynamic wave
solution to the St. Venant equations. It is not necessary nor desirable for the model to simulate rapidly
varied flow (transient analysis) such as water hammer effects.
72
-------
The hydraulic model should include a dynamic representation of the control structures and the final
control elements (e.g., pumps, gates, inflatable dams, etc.). The user should be able to easily configure
the operational settings for the control elements so that the model can accurately represent their
operation.
If a hydraulic model is to be incorporated into the online environment as part of the actual RTC
algorithm, the model needs to have the ability to dynamically interact with the online environment.
The upfront purchasing and annual maintenance costs to license hydraulic modeling software is often a
very small part of the overall budget in an RTC project but selecting an inferior tool can introduce
problems and headaches in implementation. Therefore, it makes sense to select a product that has a
demonstrated ability (e.g., actual installations) of performing well as part of RTC projects or implemented
RTC systems.
73
-------
Chapter 10. Project Management and Organization
Managing projects is a key function within every municipality. A wealth of information exists regarding
general project management. A good place to start the search for the most appropriate reference is the web
site (www.pmi.org) of the Project Management Institute.
RTC sometimes has the image of a "complicated computer project" and many municipal managers are
concerned about projects that deal with automation and hardware/software components. This is especially
true if the projects in question are complex. Complex computer projects have a less-then-perfect
performance record overall and have often gone beyond the anticipated budgets or schedules. Most of the
projects that a municipality may execute include actually building facilities and are therefore traditional
civil engineering ("brick and mortar") projects.
A number of key components in an RTC project are computer programs; therefore, a significant portion of
the deliverables is software. When the deliverable is software, traditional project management techniques
that are applied to "brick and mortar" projects are not adequate. Rather than looking to traditional project
management techniques, it is far better to consider the experience that has been gained from managing
software projects.
Management of software projects includes a set of procedures and methodologies that are called Software
Development Life Cycle (SDLC). There are different models for SDLC (e.g., waterfall, spiral, rapid
development) and they are discussed at great length in IT literature. The key overall objectives that should
be addressed within the SDLC include:
Ensure that the requirements for the project are well defined and documented; requirements should be
prepared in such a way that acceptance testing can be easily performed at the end of the project
Establish testing procedures that will make it possible to identify the issues and problems as early as
possible
Provide effective interaction between domain and IT experts
More recent software development methodologies, along with the increased acceptance of advanced object
oriented software development tools and languages, have led to some changes in the approach to the
development of functional requirements. There is often no longer an expectation that all aspects of how the
application will work can be described in detail in a document before the application development begins.
Overall, the best approach to managing the development of RTC is incremental and iterative. Therefore,
RTC projects should be structured in phases and additional layers of complexity should be added only if
they are cost justified, preferably after the less complex components of the overall RTC system have been
implemented and tested.
Although project management techniques from software development may be used, it should be noted that
RTC users may not be computer specialists. The critical success factor in an RTC project is user
acceptance; therefore, the project management methodology must include mechanisms for obtaining and
maintaining user acceptance. The user for the RTC system is the operations staff, and therefore they need
74
-------
to take the central role in all aspects of the project. In order to successfully introduce and implement an
RTC system for a municipality, it is very important to understand the culture and the tradition of the
organization. The understanding of the organizational culture is important in every phase of the project,
from the early stages when the funding for the project is being established, to the final stages of startup and
implementation.
The reader might wonder what "understanding of the culture" really means in this context. This might
sound like a generic, and perhaps vague, phrase that everyone can agree with, but what does it really mean
in this practical, specific case of completing an engineering (RTC) project? To answer this question
thoroughly and provide some theoretical foundation might require a significant effort that is far beyond this
document. However, the following are some practical examples and suggestions based on twenty years of
experience dealing with RTC issues in a number of organizations. These thoughts are formatted as
questions in first person since these are some of the questions which will need to be considered when
approaching an RTC project:
Where did the idea for the RTC project come from? Did it originate in the operations department, or
was it "invented" and "imposed" on the operations by upper management, engineering, or planning?
Often, there are tensions between operations and management or engineering and in private the
operations folks might feel that the engineering folks do not care or understand what "their real
problems are." There is often even a sense of independence and pride with being a "field guy."
Is there a "project sponsor" for RTC? The project sponsor is a senior manager or a person on
executive level, who is interested in RTC. Sometimes, a project sponsor is a visionary, keen to bring
in the technology to his organization. While this enthusiasm can provide great benefit and momentum
to the project, it is a good idea to find out how the project sponsor defined the RTC, as they promoted
the idea within the organization. In other words, some promises may have been made internally even
before the request for proposals ever came out. Some of these promises, while well intentioned, may
be difficult to achieve. They must all be noted and the expectations of RTC must be understood.
Is there a "project champion"? A project champion is a technical person who is interested in RTC and
is an advocate for it. A project champion has strong technical skills but often does not have decision-
making authority; he is hands-on and also keen to see that RTC is successful. It is important to know
how the project champion gets along with other people in the organization because it is likely that
people will "personalize" the RTC project and sometimes resistance to the project champion may turn
into resistance to the project.
Who is the "go to guy" in operations? In most organizations, there are one or two guys who have been
around for many years. When there is an emergency or a question, other people in operations will go
to them with questions. It is very important to include these folks in all aspects of an RTC project and
also to show them a healthy dose of respect for the knowledge that took twenty or thirty years to
gather. The "go-to-guy" can provide a great sounding board as we evaluate different alternatives.
What is the general attitude towards automation? In one case, upper management in a municipality
advertised the automation effort as part of the effort to "de-man the facilities" (even a more favorable
interpretation of this term implied loss of jobs). When an RTC engineer appears to interview the
operators after such announcements, he might not be met with complete enthusiasm from the
operators.
Have there been some "horror stories" in the past that will make people in operations very cautious?
People generally do not like taking risks. If we want them to embrace the RTC project we must
convince them that they will not be taking a risk.
Different organizations have different cultures and different levels of interest or pride in their work. In
many cases, the dedication and ingenuity of the people who keep RTC systems running is very
75
-------
impressive. It is a good idea to tour and visit as many facilities as possible. Are they kept clean? If
facilities are not cleaned they may not end up being well maintained either.
What might operations be privately concerned about? It is very unusual for people to bring up their
real concerns in meetings, especially if many people are present and if their supervisors or managers
are present. They will bring it up one-on-one if they trust the other person. Therefore, it is important
to spend time with operators, listen, and earn their trust, before they will be willing to tell us what they
really think.
The list above is by no means complete but it illustrates the types of issues that can be considered when we
are working on RTC and that fall within the broad term "culture" in an organization. In all of the examples
listed above, the words "he" or "guy" are used to describe the organizational issues. This is not meant to be
interpreted as an example of exclusionary gender-specific language, but it was simply easier to write this
way.
10.1 Long-Term Support and Maintenance
Completing an RTC project is not enough; mechanisms must be in place to keep the system running. Some
of the general guidelines regarding long-term maintenance of the RTC system are as follows:
Simpler RTC systems are easier to maintain. Therefore, increased complexity (of RTC design) must
yield sufficient operational benefits to offset these costs and risks.
Active involvement of the operators and maintenance managers throughout all the phases of the project
including the RTC conceptualization, design, and implementation, will increase their understanding of
the system and facilitate acceptance and long term viability.
When the RTC is being designed and developed, there may be a temptation to develop customized
("one of a kind") software components. Keeping highly customized software to an absolute minimum
and maximizing the use of commercial off-the-shelf software components will make maintenance
easier.
If the municipality has internal technical (engineering and IT) staff that has the expertise and the
experience to perform majority of the maintenance, this will greatly enhance the chances that the
system will keep running in the long term. Hiring such staff is often difficult for many reasons; e.g.,
caps on the number of employees ("full-time equivalents" or FTEs) in municipalities frequently make
this very difficult. Also, compensation levels for people with such skills can be relatively high in the
private industry and there may not be a logical "upward mobility" career path for such a person within
a municipal organization (public agency).
Some of the recommendations listed above are easier to accomplish for a large agency than for a small
agency, because the resources are less readily available in a smaller agency. In all cases, however, the
maintenance aspects must be considered early on in the project and need to be reflected in the RTC design.
10.2 Critical Success Factors for RTC
Development and implementation of RTC projects can be a complex task and such endeavor carries certain
risks. Risks can be minimized if one pays attention to some key issues or "success factors":
Operational staff (the users of the RTC system) must be involved in RTC design, development, and
implementation. This involvement needs to start as early as possible and the involvement needs to be
active.
Operational needs, goals, and requirements must be clearly understood and documented because RTC
strategies must specifically address these needs. If the agency has a system operations plan, RTC
should be addressed along with other operational issues.
76
-------
Operational goals must always be the key metric and reference point, along with costs. Technology
must remain the means, rather than the end.
Reliability of the RTC system is very important; it is essential that the system does not break down
when people depend on it. For this reason, treatment plant operators and engineers involved with the
RTC design will require increased levels of redundancy and safety factors incorporated into the design
similar to the plant systems.
RTC systems will require effort after implementation; this effort includes maintenance and support of
all RTC components, including instrumentation, communications, SCADA, and RTC software. This
effort must be properly planned and funded.
Since there is significant need for coordination, it is not wise to push for short schedules and quick
implementation. Great pressure for accelerated schedules may jeopardize the overall quality and
reliability of the system and adversely affect system acceptance.
The above "success factors"are based on practical experience and observations.
10.3 System Integration and other IT Issues
Throughout the past twenty or thirty years, municipalities have implemented a number of different
information systems to address a broad array of different business needs. A typical "landscape" of such
applications, likely to be found in a municipality, is shown in Figure 10-1.
On-line
Data
PM data
li
IF
Maintenance
Data
Personnel
data
Figure 10-1. Typical applications and associated databases in a large municipality.
11
-------
As shown, applications include SCADA, Project Management (PM), Computerized Maintenance
Management System (CMMS), Laboratory Information Management System (LIMS), mathematical
models, Geographic Information System (GIS), and administrative systems such as Financials and Human
Resources. Additionally, there could be IT systems to handle inspections, customer information systems,
and a number of others.
When a sophisticated RTC system is implemented, it will join the family of applications that already exist
and function within the organization. Therefore, it is important that the RTC fits well into the existing
overall IT environment. The term "system integration" describes the ability of different computer systems
and applications to "work well together." Systems integration can be implemented on the data level or on
the functionality level. Integration on the data level implies that different applications can exchange or
share data; integration on the functionality level implies that the functionality provided by one application
may be invoked from a different application.
Issues of computer system integration are especially important if the design of the RTC system will be
more complex and advanced, e.g., system-wide RTC that is model-based or includes optimization. In
general, it is much better to integrate systems on the data level because the structure of data is relatively
stable. A model-based system-wide RTC system, for example, will require that the RTC algorithm is
integrated with SCADA (to obtain the measurements from the field and to deliver RTC setpoints) and also
connected to the model that represents the hydraulic behavior of the network. Additionally, if results
presentation includes maps, at least a connection to a GIS will be needed as well.
78
-------
Chapter 11. Decision Support for Operators
In discussions about RTC, emphasis is often placed on automated control strategies, where algorithms
make decisions about the operation of the system. In many ways, this is a limited view that excludes the
role of the operator and ignores some important issues; examples of such issues are:
Algorithms for reducing wet weather overflows during heavy rainfall are not of much use during the
periods when such rain events are absent.
Operational objectives change depending on the state of the network; RTC could be designed so that it
is helpful to operators even during dry conditions, when they deal with emergencies or special
conditions caused by equipment failure, or major maintenance or construction activities that impact the
network and the facilities.
Therefore, focusing RTC discussion only on automated strategies (algorithms) ignores many other needs
that operators may have. One could say that there are two ways to automate a sewer system; automation
could make the operator more effective or the goal may be to replace the operator in some decision-making
processes. While focus of RTC is usually on the later, decision support systems (DSS) aim for the former.
Rather than producing operating decisions through algorithms, DSS aim to help the operator make their
own decisions.
The key to helping the operators make better decisions is to provide them with information that will
facilitate their decision-making process. Information that could be helpful to operators often exists already,
but it may reside in a computer system or application where it is not easily accessible. The central concept
of a DSS is system integration. A DSS integrates the information that resides in different parts of the
"computer system universe" within an organization and allows the users to view and analyze enterprise-
wide data. The benefits of such a system include:
Information that would otherwise be "hidden" within a single computer system or application, and
difficult to access for any but the few users of the primary application, becomes available to users on
different levels of the organization. The DSS facilitates information exchange between different
functional groups within the organization.
Analysis that requires information from more than one area or source (e.g., SCADA, LIMS, GIS,
models, or CMMS) is greatly facilitated when such diverse data is available through a single access
mechanism (often called "portal"). With increased emphasis on holistic approaches to reporting and
decision-making, such analytical capabilities provide a direct benefit on the planning (strategic level).
Some methodologies (e.g., publish-and-subscribe model) for integration can simplify long-term
maintenance of links between different computing systems and are preferable to a point-to-point
integration directly between different software applications.
Preferably, DSS can deliver a generic, off-the-shelf tool kit that offers many advantages over one-of-a-
kind customized integration solutions developed with only site-specific criteria in mind.
79
-------
The implementation of DSS helps coordinate delivery of data by individual primary applications to a
broader audience within the organization; DSS development helps establish the guidelines that each
application can follow to provide some of its data to users throughout the organization.
An example of the monetary benefit will be if the capital project implementation can be optimized
because some of the projects can be postponed, delayed, or avoided based on more complete analysis.
Overall, the DSS helps obtain value from the previous investments that had been made in different IT
systems. Just a few examples of how information could be used on different levels include:
A sewer network modeler could have access to information about the sediment levels in different
branches which normally reside in the inspection database.
An operator could use a map view (coming from GIS) to observe the history of flooding complaints
(from Customer Information System). Using SCADA data for current levels at measuring points and a
hydraulic model, a hydraulic profile within a conduit could be presented to the operator. Combined
with elevations for different manholes, potential flooding risk could be identified.
A supervisor could be alerted if a contract (e.g., for sludge hauling) is close to expiring.
Information could be passed between different applications, run times from SCADA to CMMS, status
of work orders from CMMS to operating personnel.
The DSS could have many uses. The examples provided above are just a few of the possible situations
where a DSS could add value. Improved access to information can provide a foundation for better
decisions .
11.1 Integration of Online Models into DSS and RTC
DSS could be seen as a broader IT framework for management of urban drainage systems and therefore
RTC could be seen as a component of an overall DSS. The specific role of RTC within a broader DSS
framework would be to provide tools and methods for online functions, addressing a selected objective
function (e.g., reducing CSOs).
When mathematical models are integrated into the online RTC environment, they can add valuable
analytical capability to the operators. In order to integrate mathematical models into the online
environment, at a minimum it is necessary to provide the following:
A mechanism for the models to extract the online information about the state of the sewer network
from the SCADA system
Tools so that users can configure the interface between the model and "the real world" including setup
and "mapping" of SCADA points to the model elements
Tools and a mechanism for scheduling the automated execution (launch) of the model
User interfaces for the configuration of scenarios
User interfaces for presentation of results
With models connected to the online environment, operators can test different operating scenarios using
online information.
80
-------
Bibliography
This report illustrates that developing an RTC system (especially a more complex one) will demand an
understanding of several different technical and management areas. The report provides a brief
introductory overview of these different aspects in order to give the reader a quick overall view of each
aspect. Each of these aspects and technical areas is addressed in many specialized publications, books, and
journals. Therefore, a thorough and detailed bibliography would be too large, and potentially disorienting
for the intended audience of this report.
In order to expand the view of RTC beyond this report, the reader may want to pursue further, specific
knowledge about RTC. One such source is a list of general references regarding different aspects of RTC,
listed below. Note that each of these aspects is a broad field of study in itself and it is not possible or
practical to provide a complete bibliography. The goal for the list provided below is merely to provide a
suggestion for a reasonable starting point into these different aspects of RTC.
For a historical perspective on the application of RTC, the reader is referred to:
Schilling, W. (Ed.) (1989) Real-Time Control of Urban Drainage Systems, The State of the Art. IAWPRC
Task Group onReal-Time Control of Urban Drainage Systems, Pergamon Press, London
For a recent reference on the state of the art of RTC:
Schutze, M, Campisano, A., Colas, H., Schilling, W., Vanrolleghem, P. "Real time control of urban
wastewater systems - where do we stand today?" Journal of Hydrology 299 (2004) 335-348
For a thorough overview of RTC issues and technologies in the wastewater field:
Olsson, G., and Newell, R.B. (1999) Wastewater Treatment Systems - Modelling, Diagnosis, and Control,
IWA Publishing, London
Olsson, G., Nielsen, M., Yuan, Z., Lynggaard-Jensen, A., Steyer, J.P. (2005) Instrumentation, Control, and
Automation in Wastewater Systems, IWA Publishing
For an extensive introduction to the mathematics of hydraulic modeling (includes almost 2,000
annotated references):
Miller, W.A, Yevjevich, V. (1975) "Unsteady flow in open channels", Water Resources Publications, P.O.
Box 303, Fort Collins, CO, 80522
For an overview of DSS and the state of the art for DSS in the wastewater industry:
Vitasovic, Z. and Barnett. M. (2004) "Decision Support Systems in Wastewater Facilities", WERF report,
available at WERF web site www.werf.org
For more information on SCADA systems and software development methodologies, the following
references are a good start:
81
-------
Boyer, S.A. (2004) SCADA: Supervisory Control and Data Acquisition, 3rd Edition, ISA (Instrumentation
Society of America)
Seffah, A., Gulliksen, J, Desmarais, M.C. (Editors) (2005) Human-Centered Software Engineering -
Integrating Usability in the Software Development Lifecycle, Springer Publishing Company, New York,
NY
For some suggestions on assessing the applicability of RTC:
Schutze, M; Erbe, V., Scheer, M, and Weyand, M. (2004) PASST - "A planning aid for sewer system real
time control" 6th International Conference on Urban Drainage Modeling, UDM '04, Dresden, Germany,
15-17 September 15-17, 2004
Examples of case studies for RTC implementation:
Brueck, T.M. and Nye, J. (1991) Automated Combined Sewer Overflow Control in Lima, Ohio: Ten Years
After Installation, Presented at WEF Conference in Toronto, Ontario
Heinz, S. and Schultz, N. U. (2006) Milwaukee Case Study in Example Evolution of Sewer Controls,
proceedings of World Water and Environmental Resources Congress 2006, Omaha, Nebraska, May 21-25,
2006
Hernebring, C., Yde, L., and Magnusson, P. (1999) Regulation of the Sewer System in Helsinborg CSO
Reduction by RTC and Model Based Regulation, DHI Software Conference, and June 7-9, 1999
Fuchs, L. Gtinther, H. and Lindenberg, M. (2004) Minimizing the Water Pollution Load by means of Real-
Time Control - The Dresden Example, in: Krebs, P.; Fuchs, L. (Eds.): Proceedings of the 6th International
Conference on Urban Drainage Modelling, September 15-17, 2004, Dresden, Germany
Fuchs, L. and Beeneken, T. (2005) Experience with the Implementation of a Real-Time Control Strategy
for the Sewer System of the Vienna City., Proceedings of the 10th International Conference on Urban
Drainage, Copenhagen, Denmark, August 2005
Fuchs, L. and Beenken, T. (2005) Development and Implementation of Real-Time Control Strategy for the
Sewer System of the Vienna City, Water Science and Technology, 52(5) IWA Publishing, London
Vitasovic, Z., Swarner, R. and Speer, E. (1990) "Real Time Control System for CSO Reduction", WPCF
Water Environment and Technology Journal, Vol. 2, No.3, pp. 58 - 65
Akridge A., Bingham B., Carty D., and Colas H. (2006) An Operational Perspective to Real Time Control
for Consent Decree Compliance, WEF Collection Systems Specialty Conference, Detroit, August 6-9, 2006
Colas H., Lamarre J., Charron A., and Trieu Duong D.D. (2005) Optimizing the Operation of Large
Interceptor Systems in Montreal, WEF Collection Systems Specialty Conference, Boston, July 17-20, 2005
Colas H., Robitaille L., Charron A., Marcoux C., Laverdiere M., and Lessard D. (2005) Application of Real
Time Control For CSO And SSO Abatement: Lessons Learned From 6 Years of Operation In Quebec City,
ASCE, EWRI Conference, Anchorage, AL, May 15-19, 2005
Maeda, M., Mizushima, H. and Ito, K. (2005) Development of the real-time control (RTC) system for
Tokyo sewerage system, Water Science and Technology, Vol 51, No.2 pp 213-220, IWA Publishing,
London
82
------- |