Template of Operational Toolkit for Water Distribution System Operational Decision

Support Tool (WDSODST)

Developed by The University of Kentucky

Prepared for the National Institute of Hometown Security

368 N. Hwy 27 Somerset, KY 42503

November 19, 2012

This research was funded through funds provided by the Department of Homeland Security,

administered by the National Institute for Hometown Security Kentucky Critical Infrastructure Protection program, under OTA # HSHQDC-07-3-00005, Subcontract # 02-10-UK.

Table of Contents List of Tables ............................................................................................................................................. 2 List of Figures ........................................................................................................................................... 3 1.1 Background ......................................................................................................................................... 4

1.1.1 Energy Management ................................................................................................................ 4 1.1.2 Water Quality Management ..................................................................................................... 4 1.1.3 Emergency Response Management ......................................................................................... 4 1.1.4 Event Detection ........................................................................................................................ 4

2.0 Operational Decisions ......................................................................................................................... 7 2.1 Hydraulic Sensors ........................................................................................................................... 7 2.2 Telemetry/ Communication Systems .............................................................................................. 7 2.3 Graphical Flow Model .................................................................................................................... 8 2.4 Off-Line Hydraulic Model .............................................................................................................. 8 2.5 Off-Line Water Quality Model ........................................................................................................ 8 2.6 Water Quality Sensors ..................................................................................................................... 9 2.7 Supervisory Control and Data Acquisition Systems (SCADA) ...................................................... 9 2.8 Online Hydraulic Model ............................................................................................................... 10 2.9 Online Water Quality Model .......................................................................................................... 11 2.10 Application of Real Time Models In Event Detection ................................................................. 11

3.0 Decision Support System Architecture ........................................................................................... 12 4.0 Explicit Decisional Response (Predetermined Decision Tree) ......................................................... 13 5.0 Implicit Decisional Response (Knowledge Database Structure) ...................................................... 14

5.1 Subcontract Workflows ................................................................................................................ 16 5.2 Toolkit Functionality as Proposed ................................................................................................. 16 5.3 Knowledge Retrieval Functionality .............................................................................................. 17 5.4 Knowledgebase Functionality ....................................................................................................... 17 5.5 Inference Engine Functionality ..................................................................................................... 18 5.6 Spatial Reasoning Functionality ................................................................................................... 18

6.0 Current Status of Development of Water Expert .............................................................................. 19 6.1 Reporting Guidelines .................................................................................................................... 19 6.2 Primary Sources of Documentation .............................................................................................. 19 6.3 Physical Model Analysis: Report Synopsis .................................................................................. 20 6.4 Physical Model Analysis: Toolkit-Relevant Outcomes ................................................................. 20 6.5 Graphical Flow Model: Report Synopsis ...................................................................................... 20 6.6 Graphical Flow Model: Toolkit-Relevant Outcomes .................................................................... 21 6.7 Mathematical Models: Report Synopses....................................................................................... 21 6.8 Mathematical Models: Toolkit-Relevant Outcomes ..................................................................... 22 6.9 Achievable Toolkit Functionality Based on Available Information .............................................. 22

7.0 References ......................................................................................................................................... 23

List of Tables Table 1. Description of System Components of Expert System ............................................................. 15

2

List of Figures Figure 1. Components of a Contamination Warning System (EPA 2008) ................................................ 5 Figure 2. Incorporation of WDSD into a CWS Operational Plan (EPA 2008) ......................................... 5 Figure 3. Hierarchy of Operational Components ...................................................................................... 6 Figure 4. Decision Support System Architecture .................................................................................... 12 Figure 5. Diagram of Integrative Framework ......................................................................................... 14 Figure 6. Diagram of Integrative Framework Detail .............................................................................. 15

3

Water Distribution System Operational Decision Support Tool (WDSODST)

1.1 Background

The Water Distribution System Operational Decision Support Tool has been developed to assist water utilities in designing a monitoring/control system for their water distribution system that will provide water distribution system data (WDSD) for use in support of various system operations. Such data could include both general operational data as determined from either real time telemetry or off-line computer models, or on-line data (including data from both hydraulic and water quality sensors). Operational applications could include 1) energy management, 2) water quality management, 3) emergency response management, and 4) event detection.

1.1.1 Energy Management

Water distribution systems are designed and operated to satisfy a range of objectives, including hydraulic performance and economic efficiency. Metrics of hydraulic performance include pressure levels, fire protection, water quality, and various measures of system reliability. Economic efficiency can be influenced by such factors as general operation and maintenance costs and pumping costs. In conventional surface water supply systems, pumping of treated water represents the major fraction of the total energy budget. In ground-water systems, the pumping costs normally represent the major fraction of the total operating cost. With the advent of real time models of water distribution systems, the potential exists for operators to explore different operational scenarios that could lead to a reduction in the total energy budget for the utility.

1.1.2 Water Quality Management

Water quality management continues to be a significant challenge for water distribution system operators, especially in light of increasing water quality regulations. The use of real time water quality models provides the opportunity for system operators to improve the water quality of their delivered product by having the capability to model the water quality impacts of different operational changes in the system as well as to explore the impact of the location of regional chlorine booster stations.

1.1.3 Emergency Response Management

Water utilities are frequently faced with the challenge of having to respond to a range of different emergency situations. Such emergencies can included pipe breaks, component failures (e.g. pumps), low pressure issues, cross connections, and contamination events (either accidental or intentional).

1.1.4 Event Detection

In addition to the previous potential applications, the WDSODST is also envisioned to provide guidance in the development of a system that could provide critical water distribution system data in

4

support of the detection of either hydraulic or water quality anomalies that could in turn be incorporated into a contamination warning system (EPA, 2008) as illustrated in Figure 1.

Water Distribution System Data

Figure 1. Components of a Contamination Warning System (EPA 2008)

The use of such data in a comprehensive CWS operational plan is envisioned in Figure 2.

WDSD

Figure 2. Incorporation of WDSD into a CWS Operational Plan (EPA 2008)

The types of critical water distribution system data available for use in supporting various operational applications, such as event detection will be dependent upon the nature and components of the associated water distribution system data acquisition and control hierarchy. Several potential levels of such a hierarchy are envisioned for a typical water distribution system as illustrated in the ladder diagram in Figure 3. Adjacent to the rungs on the ladder are possible decisions that are supported by the WDSODST. Also illustrated, are possible auxiliary software in support of such applications.

5

Hydraulic Sensors

Telemetry/Communication Systems

Spatial Visualization of Network Components

Of-Line Hydraulic Model

Of-Line Water Quality Model

Water Quality Sensors

Supervisory Control and Data Acquisition (SCADA)

On-Line Hydraulic Model

On-Line Water Quality Model

On-Line Water Quality Model

Event Detection System

Figure 3. Hierarchy of Operational Components

6

2.0 Operational Decisions Operational decision associated with a water distribution system are envisioned to be organized in a hierarchal fashion as illustrated in Figure 3. A summary of the types of operational questions that could be associated with each level of the hierarchy are summarized below along with possible associated documents [ ].:

2.1 Hydraulic Sensors

1. What type of hydraulic sensors are available for use with a water distribution system?

2. What are the sources of such sensors?

3. What is the most efficient strategy for obtaining such sensors?

a. Manufacturer

b. Vendor

c. Consultant

4. What types of data should you collect prior to selection of a sensor?

5. What types of questions should you ask a potential supplier?

6. What are the typical costs and specifications of such sensors?

7. Where should such sensors be located?

[General Guidance Document]

[Sensor Placement Program (SPP) Website]

[Sensor Placement Program (SPP) User's Manual]

[Sensor Placement Program (SPP) Tutorial]

2.2 Telemetry/ Communication Systems

1. What type of telemetry and communication systems are available for use with a water distribution system?

2. What are the features, specifications, costs, and communication requirements associated with each type of system? What are the advantages and disadvantages of each?

3. What are the basic types of sensor interface components? (e.g. RTUs and PLCs)

4. What are the basic steps of the design and selection process?

a. Predesign

b. Design

c. Implementation

d. Startup and baseline

e. Operation and maintenance

7

f. Evaluation and refinement

g. Resources/References

5. What types of data should you collect prior to selection of a particular system?

6. What is the most efficient strategy for implementing a system?

a. Manufacturer

b. Vendor

c. Consultant

7. What types of questions should you be prepared to ask in each situation?

2.3 Graphical Flow Model 1. Is your water distribution system located in Kentucky?

2. Do you currently have a schematic of your water distribution system?

3. Do you have a GIS data coverage of your water distribution system?

4. Do you currently have a computer model of your water distribution system?

5. Would you like to develop a graphical flow model for your distribution system?

[GFM Website]

[GFM User's Manual]

[GFM Tutorial]

2.4 Off-Line Hydraulic Model 1. What types of hydraulic network models are available?

[KYPIPE]

[EPANET]

2. What are their features?

3. How do you calibrate a hydraulic network model?

[Guidelines for model calibration]

[Case study of model calibration - Nicholasville]

[Case study of model calibration - Paris]

2.5 Off-Line Water Quality Model 1. What types of hydraulic network models are available?

[KYPIPE]

[EPANET]

8

[EPANET MSX]

2. What are their features?

3. How do you calibrate a water quality network model?

[Guidelines for model calibration]

[Case study of model calibration - Nicholasville]

[Case study of model calibration - Northern Kentucky]

2.6 Water Quality Sensors

1. What type of water quality sensors are available for use with a water distribution system?

2. What are the sources of such sensors?

3. What is the most efficient strategy for obtaining such sensors?

a. Manufacturer

b. Vendor

c. Consultant

4. What types of data should you collect prior to selection of a sensor?

5. What types of questions should you ask a potential supplier?

6. What are the typical costs and specifications of such sensors?

7. Where should such sensors be located?

[General Guidance Document]

[Sensor Placement Program (SPP) Website]

[Sensor Placement Program (SPP) User's Manual]

[Sensor Placement Program (SPP) Tutorial]

2.7 Supervisory Control and Data Acquisition Systems (SCADA) 1. What are the basic components of a SCADA system?

a. Control Units (RTUs, vs PLCs)

b. Communication System

c. Computer hardware

d, Computer software

e. Database

f. Security

2. What are potential uses of SCADA in a water distribution system?

9

3. How do other utilities utilize SCADA in their operations?

[SCADA Survey]

4. What is the most efficient strategy for obtaining such sensors?

a. Manufacturer (landscape assessment, specifications, questions to ask)

b. Vendor (landscape assessment, specifications, questions to ask)

c. Consultant (landscape assessment, specifications, questions to ask)

5. What type of data should you assemble in support of designing a system?

6. What are the types of questions you should ask a potential supplier?

a. Capabilities

b. Cost

c. Reliability

d. Technical support

e. Training

f. Potential interface options with online computer models

7. What are the basic steps of the design and selection process?

a. Predesign

b. Design

c. Implementation

d. Startup and baseline

e. Operation and maintenance

f. Evaluation and refinement

g. Resources/References

2.8 Online Hydraulic Model 1. What are potential uses of a real-time hydraulic model?

2. Do you have a calibrated hydraulic model of your system?

3. Do you have an operational SCADA system?

4. What are the different ways you can link a hydraulic model with your SCADA system?

5. What are the additional requirements for providing your hydraulic model access to your SCADA database?

6. What existing models provide an interface for real time operations?

[Real Time Operational Report]

[User's Manual for EPANET -RTX]

10

[Case Study of Application to NKY System]

7. What level of model calibration is necessary for use of the model in a real-time environment?

[Physical Model Report]

8. How can you improve the calibration of the model to support a real time operational use?

[Case Study of Water Quality Calibration of NKY System]

[Case Study of Water Quality Model Application to NKY System]

2.9 Online Water Quality Model 1. What are potential uses of a real-time water quality model?

2. Do you have a calibrated water quality model of your system?

3. Do you have an operational SCADA system?

4. What are the different ways you can link a water quality model with your SCADA system?

5. What are the additional requirements for providing your water quality model access to your SCADA database?

6. What existing models provide an interface for real time operations?

[Real Time Operational Report]

[User's Manual for EPANET -RTX]

7. What level of model calibration is necessary for use of the model in a real-time environment?

[Physical Model Report]

8. How can you improve the calibration of the model to support a real time operational use?

[Case Study of Water Quality Calibration of NKY System]

[Case Study of Water Quality Model Application to NKY System]

2.10 Application of Real Time Models In Event Detection

1. What is the general EPA protocol for event detection?

[EPA protocol document]

2. What different strategies existing for event detection? (Explain strategies)

a. SCADA/Sensors

b. CANARY

[CANARY Case Studies]

c. Use of Real Time Models

3. What are the advantages of using real time models for event detection?

11

4. What are the challenges of using real time models for event detection?

[Case Study of Real Time Model Application to NKY System]

3.0 Decision Support System Architecture Support for operational decisions will be provided through the decision support systems through two primary methods: 1) an explicit decisional response path based on predetermined decisional decision trees (e.g, flowcharts) or 2) an implicit evolving decisional response path as developed an expert system inference engine in response to sequential answers as provided through the user interface (see Figure 4).

User

Question

Data & Facts

ExplicitDecisional Response:

Predetermined Decision Tree

ImplicitDecisional Response:

Traditional Expert System

Model Results

Model Results

Responses/Recommendations

Fact Sheets WebLinksReports

Figure 4. Decision Support System Architecture

12

4.0 Explicit Decisional Response (Predetermined Decision Tree) Depending upon the nature of the question and the nature of the required data or facts, one approach to providing a response is to simply take the user through a pre-defined decision tree. Depending upon the particular response, the decision tree will then branch to the next appropriate question or required set of data and facts. At the end of the decision path, the user will be provided a set of responses or recommendations in one of several potential formats: 1) online narrative summary along with potential supporting figures or tables, 2) a summary fact sheet that can be download for archival purposes, 3) a more detailed report, or 4) a link to an external website that may provide access to supporting software (e.g. EPANET, KYPIPE, GFM, SPP) or additional pertinent information.

13

5.0 Implicit Decisional Response (Knowledge Database Structure) The user's primary mode of interaction with the expert system integrative framework is through the provision of data and facts through a user interface (see Figure 5). Depending on the type of information provided to the system, the user may simply browse or retrieve Data and Facts as content directly from the Knowledgebase. Queries requiring the application of inferential logic are routed through the Rule-Based Decision Support Tool, which uses an inference engine to match user-supplied information against rules and global facts in the Knowledgebase to return Recommendations for action to the User. As in the case of the inference engine being called as part of the Rule Based Decision Support Tool, other Toolbox components can similarly be executed in response to relevant queries. Configured Toolbox components can draw data from the User and the Knowledgebase through the relevant Data entry pages.

Figure 5. Diagram of Integrative Framework

WDSODST has been developed as an integral part of a larger Water System Information System (see Figure 6). The The primary entry point into Water Expert to access the Hydraulics and Flow Dynamics (WDS) knowledge domain is anticipated to be through the stipulation of Operational Goals, with additional constraining information provided within the context of the Water System information and Network topological or other configuration information.

Knowledge based needs criteria in support of water distribution system operations can then be used to match against the user-supplied facts to provide the User with Recommendations for improvements in the network infrastructure. Network Operational Recommendations can similarly be derived from the User-prescribed Operational Goals with additional data from either offline (KYPIPE or EPANET2) or online (EPANET-RTX) hydraulic models and the companion contaminant transport extension (EPANET-MSX). Compound improvements can also be derived by combining recommendations for network infrastructure improvements (i.e. SCADA & Sensor placement), along with resultant improvements in mathematical model simulation accuracy and operational responsiveness.

14

Table 1. Description of System Components of Expert System

Indicates the user's perspective within the selected workflow.

Indicates a content node, allowing the user to enter facts and other information to Water Expert.

A knowledgebase is essentially a combination of facts and rules within a specific domain of knowledge.

Indicates a Water Expert output node. This is generally static content such as contextual help, the results of a Completed workflow process such as a Report or Recommendation, or nominally navigable content such as interactive guidance documents.

Any independent server-side or desktop applications that interface with Water Expert. This includes the inference engine Integral to Water Expert, along with other applications such as Map Server and EPANET2

Designates a point in the work flow that requires a choice be made by the user. For example, if multiple ways exist for providing the same type of data to Water Expert.

Figure 6. Diagram of Integrative Framework Detail

15

5.1 Subcontract Workflows Information for use in populating the knowledge database of the expert system will be derived from a synthesis of results and outcomes of Tasks 3 - Task 8 of the project. These tasks are summarized as follows.

Task 3 - Survey and Evaluate SCADA Systems Task 4 - Build Laboratory Scale Model of Water Distribution Network Task 5 - Develop Graphical Flow Distribution Model Task 6 - Develop and Calibrate Hydraulic and Water Quality Model Task 7- Evaluate Real-Time Model Using Historic SCADA Data Task 8 - Develop Sensor Placement Guidance

It is anticipated that the results from these tasks will be synthesize to provide the responses associated with the operational decision questions summarized in section 2.0. The initial beta version of the toolkit will be constructed so as to illustrate the capabilities of the Decision Support System in support of Tasks 4, 5 and 6, with the final version incorporating components of the remaining tasks.

5.2 Toolkit Functionality as Proposed The toolkit functionality proposed is critically dependent on preceding project Tasks 3 through 8. Data collected and reported in these tasks are intended to be synthesized into knowledge elements for incorporation into Water Expert.

• Knowledge Retrieval - An Interview-style user interface is envisioned to prompt the user through a sequence of rule-driven queries to ascertain both the level of system knowledge and simultaneously provide a nominal level of system characterization. This approach has previously been successfully implemented for small systems collaboratively developing Long Term Control Plans for Combined Sewer Overflow Management.

• Spatial Reasoning - Further, past work in expert-system shell integration with Geographical Information Systems will allow seamless development of an integrated guidance tool. Incorporating spatial reasoning will allow the user to refine sensor placement strategies.

• Knowledge base - Preliminary activities under this task will involve extraction and codification of the information gathered during the preceding Tasks into a series of Boolean "rules" that can be acted on by both Forward and Backward Chaining Inference Engines. This knowledge base will incorporate information on Individual asset/network component functionality and connectivity.

• Component Protocols - Pressure sensor operating principles and locational requirements, or isolation valve connectivity restrictions are examples of rule sets specific to individual network component functionality, that, once codified, may be combined with a super-set of network-level operating protocols that together will define the functionality of water distribution networks in general.

• Network Protocols - Network level operating protocols may by further subdivided into component inter-connectivity and interaction rules and higher-level network functional restrictions. These may be represented as hydraulic or contaminant fate and transport principles (e.g. conservation of mass, energy; advection, diffusion, transformation, decay), regulatory (local and/or state) specifications, or, more likely, a combination of the two.

• Inference engine - From the rules-system perspective, SCADA components are simply additional categories of assets that have associated functionality. In parallel to the rule-base

16

development, existing expert-system shells will be further refined for use within this toolkit. Forward Chaining systems such as JESS will be used primarily for the structured queries used to elucidate additional facts regarding the user’s system, with a primary goal of being able to aid sensor, actuator, and controller selection for SCADA system and scope selection. Using a backward chaining Inference engine such as MANDARAX, a nominal amount of deductive reasoning can be executed in order to elucidate knowledge gaps and provide the user with some direction regarding the selection of hydraulic and water quality models and the comparative benefits of adoption.

5.3 Knowledge Retrieval Functionality In order to streamline the knowledge retrieval process and simplify the user interaction process, prescribed pathways have been developed with pre-defined endpoints representing the typical use cases.

• Fact Sheets - Fact sheets are prepackaged content that can be retrieved with minimal user input. Information on a fact sheet is designed for rapid access and addresses specific aspect of the selected knowledge domain.

• Interactive Guidance Documents - Guidance documents are interactive, navigable content that allows the end-user to peruse information in a self-determined sequence. Information in guidance documents is designed for hierarchical access to increasing detail.

• Goal-Driven Recommendations - The key element in goal-driven recommendations is the application of user-supplied facts regarding a scenario or situation against domain-relevant rules to return to the user scenario-specific recommendations. This constitutes an instantiation of the rule-based decision support system. Knowledge-domain specificity is achieved through prescription of the workflow to ensure relevant facts are provided within the context of the user's goal.

5.4 Knowledgebase Functionality The knowledgebase stores the facts and rules used by Water Expert in a relational database system, and is retrieved for use by the end user using the CMS interface or for use by the RBDST for machine reasoning.

• Knowledge as Content - The role of the content management system is to serve as the repository for the knowledgebase. The physical location of the knowledgebase data is determined by the structure of the content management system.

• Data as Content - Raw data is stored in the CMS as custom content types, allowing the user to user the data entry capabilities of the CMS. The CMS UI can also be used to execute the selected server-side applications incorporated into Water Expert as Toolbox items. Content can also be used to store output from Toolbox items, and for integration with visualization tools such as GIS, plotting andtime-series sequences (movies).

• Content as Ordered Facts - Custom content types can be created that define structured or ordered facts for use with the selected inference engine included in Water Expert. Content fields are equivalent to "slots" in ordered facts, with their respective content types being representing the structure of the ordered fact.

• Rules as Structured Content - Rules can be stored as custom content types that specify the patterns to be matched and the corresponding actions as content fields. Actions can trigger data to be returned to the CMS or the execution of other toolbox items.

17

5.5 Inference Engine Functionality Core to the function of Water Expert is its ability to perform deductive reasoning on the knowledgebase. The inference engine utilizes the facts and rules stored in the knowledgebase to deduce outcomes or goals.

• Function - The inference engine is a toolbox item consisting of a server-side application whose execution is transparent to the user.

• Operation - In order to minimize the learning curve for the end-user, the inference engine is executed asynchronously from prescribed goal-driven workflows.

• CLIPS - (C Language Integrated Production System) is currently the inference engine being used in Water Expert. CLIPS is a Forward Chaining (data-driven) rule engine. It is executed on the server by collecting the rules and facts entered into the CMS, with the output being returned to the user.

• JESS - (Java Expert System Shell) is being planned to replace CLIPS as the rule-engine. Advantages of JESS include the inclusion of Backward Chaining (goal-driven), and the ability to better integrate server-side execution using the Apache Tomcat server.

5.6 Spatial Reasoning Functionality There is functionally no difference between "Reasoning" and "Spatial Reasoning", other than the inclusion of logic that includes references to location and connectivity. However, the complexity and volume of information that is included in spatial information will generally require specialized processing and visualization tools for efficient assimilation by the end-user.

• User Interface - Representation of spatial data is generally effected using visualization tools such as GIS or network rendering software. Within Water Expert, the MapServer GIS server or GraphViz network processing toolbox items are used for this purpose.

• Spatial Facts - The user's spatial data can be represented as facts against which rules with a spatial aspect can be evaluated. Considering the volume of data generally included in spatial datasets, automatic conversion from traditional spatial data sources into a readily adaptable format is likely to be preferred over manual data entry into the CMS. Whole datasets may be converted into an intermediate format such as GML, or specific data elements needed may be extracted for direct inclusion as part of the input stream for the selected toolbox item, such as facts for the inference engine or network structure for hydraulic or water quality modeling. Spatial facts can include both locational and connectivity information.

• Spatial Rules - Rules must be created that incorporate facts that match spatial patterns represented by spatial facts. Actions triggered upon the matching of requisite spatial patterns can involve the assertion of new facts or the execution of other toolbox items, such as hydraulic models or asset management functions.

• Spatial Tools - Water Expert includes an expanding set of tools that utilize spatial data. Geospatial data visualization is accomplished through the MapServer application. Selection and extraction of GIS data can be accomplished in conjunction with the GIS rendering application through the use of servlet components. The Graphviz tool allows rapid rendering of connectivity and directional information, but does not readily include locational information. The EPANET2 hydraulic modeling tool can use network topological information extracted from the GIS data, and can use either GraphViz or MapServer for network rendering.

18

6.0 Current Status of Development of Water Expert The core functionality of the Water Expert integrative framework is in place. A knowledgebase exists, populated with knowledge from specific knowledge domains. Rules and facts from these domains can be processed through an inference engine and retrieved by the user through the CMS interface, providing a functional RBDST for the populated knowledge domains. Spatial reasoning functionality, driven primarily by the data sources, exists for a limited set of applications. In order to extend the scope of the Water Expert knowledgebase to include water distribution network hydraulics and flow dynamics knowledge, constituent knowledge must be collected and synthesized into a machine-comprehensible form. In this project, data is being collected by the various project research teams in support of the associated various operational decisional requirements as outlined in Section 2.0. Once synthesized, this information will then be segregated for use either in the explicit decision tree pathway or the implicit expert system pathway (i.e. See Figure 4).

6.1 Reporting Guidelines On August 27, 2012, during a meeting of the project PIs, a recommendation was made to develop a template for reporting subproject results in a coherent format for synthesis into knowledge elements. The template was forwarded to the project PIs on October 19, 2012. The list below is a synopsis of the type of data that would be initially extracted from traditionally formatted documents prior to synthesis into a knowledgebase.

• Decisions - What are the critical decisions that an end user can make based on the results of your research? (i.e. see Section 2.0)

• Data - What are the critical pieces of information or data that the end user must have in order to make each decision effectively? (i.e. see Section 2.0)

• Use-Cases - What are the most frequently occurring use-case scenarios, of each of the decisions or combinations of decisions, in which the results of your research are likely to be used? For example, following on the previous sections, this single decision could be utilized in the following use-cases:

• A planning process. • A large system investing in capital equipment. • A small system defining mutual aid. • Regional emergency support function availability.

6.2 Primary Sources of Documentation Currently, the following project task reports are available and are being used in the development of the initial beta version of the Operational Toolkit:

• Physical model design and analysis reports • Nicholasville hydraulic model calibration report • Nicholasville water quality model calibration report • Paris hydraulic model calibration report • GFM user manual

Data from each of these reports is currently being synthesized into a format to address the associated questions outlined in Section 2.0. A summary of the highlights of each report and the associated

19

potential toolkit-relevant outcomes is provided below. Additional data will be synthesized from the remaining reports:

• SCADA survey report • SCADA capabilities report • Sensor Placement Guidance Report • Sensor Placement Program • Water Quality and Flow Dynamics Data Analysis Report • Water Quality / Flow Dynamics Sensitivity Report

6.3 Physical Model Analysis: Report Synopsis The information detailed herein is extracted directly from the relevant project report:

• Objective - Investigate the accuracy of hydraulic and water quality models by constructing a physical scaled model of a skeletonized medium-sized water distribution system

• Configuration - The physical model contains a reservoir, a pump, and three elevated storage tanks.

• Sensors - It is equipped with pressure sensors, flow meters, and tank level meters to monitor the hydraulic boundary conditions of the network, as well as electrical conductivity meters to monitor the water quality of the network. All these sensors are fed to a single data acquisition system.

• Computer Model - An EPANET and KYPIPE model of the physical model was created to compare the results of the lab model with the results of the computer model.

• Steady-State Hydraulics - In order to compare the hydraulics of the network with the results of a hydraulic model, four different steady-state four scenarios were run and compared against the simulation output of computer models.

• Water Quality Tracer Study - Three tracer experiments were run in which a calcium chloride solution was injected downstream of the pump and compared against the simulation output of computer models.

6.4 Physical Model Analysis: Toolkit-Relevant Outcomes The information detailed herein is extracted directly from the relevant project report:

• Minor Losses - In order to create a more accurate model, it may be necessary to determine the minor losses of the network by experimentation rather than using the typical literature values.

• Model Calibration - In a full-scale water distribution, it may be sufficient to calibrate the model using a lumped C-factor approach.

• Sensor Calibration - Can any of the procedures & lessons learned during the individual sensor calibration process at the bench-scale be translated to full-scale SCADA component calibration?

• Data Quality - Can the statistical analysis procedures defined in the report to assess data quality be translated to add value to full-scale operational conditions?

6.5 Graphical Flow Model: Report Synopsis The information detailed herein is extracted directly from the relevant project report:

20

• Objective - The Graphical Flow Model (GFM) provides a graphical representation of a system within an interactive interface, capable of storing and manipulating data pertaining to many components of the system. Given certain hydraulic operational control inputs, the GFM is capable of returning output for many important system questions such as flow directions and magnitudes, pressures, hydraulic grade line contours, etc.

• Kentucky Infrastructure Authority Data - The GFM model includes functionality to upload KIA data on pipelines, water tanks, water treatment plants, water meters, and pump stations via a graphical user interface to permit the creation of a schematic of the water distribution system.

• Flow & Pressure information - The GFM can provide flow, flow direction, pressure and pressure contours as a result of static pumping and demand conditions.

6.6 Graphical Flow Model: Toolkit-Relevant Outcomes Since GFM is a Tool developed specifically to support the overall project objectives, primary relevancy to the Operational Toolkit lie in the interface between GFM and Water Expert:

• Fact Sheet - Information regarding the potential benefits and use-case scenarios can be embedded in a fact sheet within the Water Expert system, along with links to access the software.

• Data Exchange - Information both used and produced by GFM has significant potential use within Water Expert as user-supplied facts (both spatial and non-spatial). In order to fully utilize this knowledge, the knowledgebase would need to be updated to include relevant rules to act upon. For example, relationships between sensor selection criteria and topological flow/pressure patterns could allow refinement of SCADA selection for the end-user. Since such rules are yet to be elicited from other project tasks, and a data-exchange protocol between GFM and Water Expert is outside the scope of this project, this potential outcome will not be deemed achievable.

6.7 Mathematical Models: Report Synopses The information detailed herein is extracted directly from the relevant project reports:

• Objective - Successful calibration of the water distribution system in Nicholasville, KY. • Data Collection - Gather and review all available information on the Nicholasville water

distribution system in order to develop the computer model. This includes AutoCAD/GIS files showing all pipes, demand nodes, hydrants, and valves in the system. Customer usage bills will also be appropriate in order to gather accurate demand data. Specifications for the storage tanks, pumps, and the water treatment plant are also collected.

• Computer Model Development - Create a model of the system using KYPIPE, including all pipes, hydrants, nodes, junctions, demand nodes, elevated storage tanks, and pumps. Descriptive parameters that are known for each component should be entered appropriately.

• Field Testing - Develop and execute a field testing protocol. These tests will include C-factor tests and Fire Flow tests (procedure to be discussed). All data should be recorded appropriately, including all boundary conditions during test periods.

• Model Calibration - Results from field testing are compared to model behavior, and data in the model is adjusted until it reasonably agrees with measured system performance. System demands, roughness of pipes, pump operating conditions, and other attributes are altered in the model to match field conditions.

• Model Calibration Verification: To ensure the model calibration is an accurate representation of the system, a new set of field data is collected for verification purposes. An extended period

21

simulation (EPS) is executed on the calibrated model and compared to results from field data over an extended time, such as water levels in elevated storage tanks. If the new test results closely match model behavior, the calibration is verified.

6.8 Mathematical Models: Toolkit-Relevant Outcomes The information detailed herein is extracted directly from the relevant project reports:

• System Characterization - Including network data collection (pipes, demand nodes, hydrants, and valves in the system) and demand patterns (e.g. customer usage), as well as field testing to characterize system components (e.g. C-factor tests), fire flow testing, tracer studies, and determination of boundary conditions.

• Seven Steps of Model Calibration - (1) Identification of intended use of the model (2) Identification of calibration model parameters and their initial estimates (3) Model studies to determine the calibration data sources (4) Data collection (5) Macro calibration (6) Sensitivity analysis (7) Micro calibration

6.9 Achievable Toolkit Functionality Based on Available Information Based on the available information, the following elements have been identified as Toolkit-Relevant outcomes from the project activities to date. These elements will be incorporated into the beta version of the Operational Toolkit specified as "Deliverable 9.2 - Beta Version of Operational Toolkit", due on February 1, 2013.

• Data Quality Verification - The statistical tools employed in the Physical Model Analysis can be extrapolated into a set of fact sheets detailing procedures for verifying sensor data quality.

• GFM Fact Sheet - Information from the GFM User Manual can be extracted and combined into a fact sheet defining the value of topological and hydraulic models, with a link to the GFM download site.

• System Characterization - The system characterization processes detailed in the Nicholasville, KY model application reports can be synthesized into a series of step-wise guidance documents.

• Computer Model Calibration - The sensor, hydraulic and water quality model calibration process detailed in the Nicholasville, KY and Paris, KY model applications and the Physical Model Analysis can be synthesized into a step-wise model calibration guide.

22

7.0 References

1. Ashby, C., M. Jolly, and S. Yost, "Physical Model Analysis Report", Studying Distribution System Hydraulics and Flow Dynamics to Improve Water Utility Operational Decision Making, Lexington, Kentucky, University of Kentucky, 11/2012.

2. KYPIPE LLC, Pipe 2010 Help Manual, , 05/2011, 2010. 3. Ormsbee, L. E., "GFM: Graphical Flow Model User’s Manual", Studying Distribution System

Hydraulics and Flow Dynamics to Improve Water Utility Operational Decision Making, Lexington, Kentucky, University of Kentucky, 09/2012.

4. Ormsbee, L. E., S. Yost, T. Calkins, J.Goodin, D. Johnson, and J. McDaniel, "Final Nicholasville Water Quality Calibration Report", Studying Distribution System Hydraulics and Flow Dynamics to Improve Water Utility Operational Decision Making, Lexington, Kentucky, University of Kentucky, 09/2012.

5. Ormsbee, L. E., S. Yost, T. Calkins, J.Goodin, and S. L. Bryson, "Final Nicholasville Water Distribution System Calibration Report", Studying Distribution System Hydraulics and Flow Dynamics to Improve Water Utility Operational Decision Making, Lexington, Kentucky, University of Kentucky, 09/2012.

6. Ormsbee, L. E., and S. Lingireddy, "Calibrating Hydraulic Network Models", Journal of the American Water Works Association, vol. 89, issue 2, pp. 9, 02/1997.

7. Reed, R. E., E. C. Inniss, S. Poleneni, and J. McGrath, "SCADA (Supervisory Control and Data Acquisition) and Sensor Technologies for Drinking Water Distribution Systems", Studying Distribution System Hydraulics and Flow Dynamics to Improve Water Utility Operational Decision Making, Columbia, MO, University of Missouri, 10/2012.

8. Rossman, L. A., EPANET2 Users Manual, : United States Environmental Protection Agency, pp. 200, 2000.

9. U.S. EPA, Water Security Initiative: Interim Guidance on Developing an Operational Strategy for Contamination Warning Systems, EPA 817-R-08-002, September, 2008.

23