How to Streamline water main failure and condition assessment using Geospatial Technology

How to Streamline water main failure and condition assessment using Geospatial Technology

Skip Heise
Senior GIS Consultant EMA, Inc. 4463 Lake Forest Drive East Ann Arbor, MI 48108
Phone: (734) 913-7956, Fax: (734) 913-7957
Email: sheise@ema-inc.com

Holly Takara
GIS Project Manager Honolulu Board of Water Supply
630 South Beretania Street Honolulu, HI 96843
Phone: (808) 527-5060, Fax: (808) 550-5050
Email: htakara@hbws.org

Abstract
The Honolulu Board of Water Supply (HBWS) uses a manual process that is highly labor and time intensive to document information during a water main break incident. HBWS currently documents and tracks information about water main breaks on a paper- based “Water Main Failure Report” (WMFR). This paper report is routed to four or five different people, in addition to various reviews and approvals, each adding various pieces of information. This process is extremely inefficient and provides opportunity for error.

HBWS initiated a project with EMA, Inc., a specialized utility consultant, to improve the processes for collection and documenting information regarding a main break and pipe condition, through the use of software technology. The manual processes would be automated using laptop and handheld devices with electronic forms to replace the paper-based reports. The electronic forms provide ways of collecting this critical information using pick lists and standard input, reducing data entry errors, minimizing data redundancy, and preserving data integrity.

In addition, Global Positioning System (GPS) technology is introduced to capture the location coordinates of the main break or pipe to be included in the enterprise spatial database. Web-based tools would be developed to publish main break reports to the desktops of HBWS management.

Background
The Honolulu Board of Water Supply (HBWS) uses a manual process that is highly labor and time intensive to document information during a water main break incident. HBWS currently documents and tracks information about water main breaks on a paper- based “Water Main Failure Report” (WMFR). This paper report is routed to four or five different people, in addition to various reviews and approvals, each adding various pieces of information. This process is extremely inefficient and provides opportunity for error.

In addition, since this report is paper-based, the information has to be manually entered into a database. The report is handwritten, which provides for interpretation by the dataentry specialist, allowing for error or misinterpretation of the information. The spatial location plotted in GIS by IT staff is based on the approximate location listed on the WMFR.

Intermittently, information regarding the water main’s condition is collected on a paper- based “Investigation of Water Main Condition” form (IWMC). This form is filled out while the main is exposed during connections, service renewals, adjustments to existing main (lowering, jacketing, etc.), maintenance, or other work requiring excavation that exposes the pipe. Similar to the WMFR, the IWMC follows an inefficient path from data collection and documentation to being filed in a folder. The IWMC form collects some but not all of the same types of information as the WMFR.

In addition to the WMFR and IWMC, a third form is used during a water main break incident, called a Water Service Interruption (WSI) form. This form is used to identify the customers and fire hydrants that will be out of service due to the isolation of the water main. A WSI is completed for all service interruptions. In addition to main breaks, service interruptions may be caused by planned closures for connections and other work on the system, including clamping or caulking a joint under pressure, or other work done by BWS staff or private contractors.

Some of the same information is being collected on both the WSI and the WMFR. This provides for redundant data entry and opportunity for errors.

The following describes redundant information being captured on the three forms:

Location (street address and between, to, and from streets)
Pipe size and material type

The following information is redundant between the WSI and the WMFR:

Throttle date and time
Date water off
Work Order number
Number of services affected
Number of hydrants out of service
Hydrant number (Out of Service)
Location of water wagon(s)

In addition, the following information is redundant between the IWMC and the WMFR:

Type of soil
Pipe condition
Groundwater encountered

HBWS initiated a project with EMA, Inc., a specialized utility consultant, to improve the processes for collecting and documenting information regarding a main break and pipe condition, through the use of software technology. This paper describes a businessdriven methodology used by HBWS and EMA to define a geospatial application solution.

Application vision and goals
The vision for the Main Failure and Condition Assessment Application is to provide an efficient method for capturing, storing, retrieving, and analyzing data and information about a water main break incident and pipe condition. The goal for the implementation of this application is to improve the processes for collecting and documenting information regarding a main break incident and pipe condition. HBWS envisions that these processes can be automated using laptop and/or handheld devices with electronic forms to replace the paper based reports. The electronic forms will provide ways of collecting this critical information using pick lists and standard input reducing data entry errors, minimizing data redundancy, and preserving data integrity. In addition, Global Positing System (GPS) technology can be introduced to capture the location coordinate of the main break or pipe to be included in the database. Collecting the location of the incident using GPS will offer easy integration with the HBWS’s Geographic Information System (GIS).

Methodology

A business-driven approach was used to identify the drivers and validate the needs to automate the processes relating to water main failure and pipe-condition assessment. The following are the high-level steps of the methodology.

Identify stakeholders and core user group
Define the problems and vision for a successful solution
Business-process modeling
Develop functional requirements
Develop conceptual solution

1. Identify Stakeholders and Core User Group
The project sponsors include the managers of the maintenance, engineering, and field operations units. Together, the managers selected the group of people from the affected business units to participate in the project. This group became the “core team,” or core user group.

The following table shows the roles and responsibilities that these people have within their respective business units:

2. Define Problems and Vision for a Successful Solution
Workshops were conducted with the project sponsors to identify the problems and vision for a potential solution. The following were determined to be main problems with the current processes:

The current data collection process is manual and cumbersome.
The WSI and WMFR data collection and review process takes too long to complete.
Redundant and inaccurate data being collected.
Not taking the opportunity to collect information regarding a main’s condition during exposure.
Inaccurate information regarding the location of a main break or pipe.
Analyzing and retrieving data regarding main breaks and condition is difficult.

The problems were further discussed and analyzed to identify who are affected by the problems and the impacts. From this, characteristics for a successful solution were identified. These characteristics include the following:

Automate the data-entry process by providing electronic data-entry forms within an easy-to-use environment.
Streamline the review process, standardize the data collection and entry methods, and maintain the data in a centralized database.
Standardize data input through electronic forms, trap errors, incorporate pull down menus and pick lists, automate data input, and establish data stewards.
Provide processes and technology for inspectors to collect data and information about the condition of water mains.
Acquire the GPS coordinate location for main breaks, and provide a standard for describing the location of facilities.
Provide customized reports and map creation capabilities.

3. Business Process Modeling
Before any new system or technology can be designed and developed, an understanding of current business processes must exist. Therefore, it is essential to make a model of the business. A model is a means of creating an abstraction that eliminates irrelevant details and allows all stakeholders to focus on one or more important aspects of the business at a time. Both an “as-is” business-process model, representing the current situation, and a “to-be” model were developed.

We used a process-focused, workflow-driven approach to understand the business and define the requirements for the technology solution. The business modeling activity began by facilitating a series of work sessions with the application stakeholders and core user groups to document their current business process and work activities relating to the water main failure and water main condition reports. This information was documented as business use cases and activity diagrams using Rational Rose, a business-modeling software tool from Rational Software Corporation. The business use cases will represent the “as-is” situation.

Once the “as-is” business use cases were documented and analyzed a second meeting with the stakeholders was conducted to determine the “to-be” business use cases. The “to-be” business use cases represent the processes that are automated through the use of software technology and stakeholder needs. Analysis of the “to-be” business use cases is the starting point for identifying the functionality of the main failure and condition assessment application. These requirements were documented as system use cases in Rational Rose and outlined in a functional requirements document.

4. Develop Functional Requirements
During user needs and requirements workshops conducted at HBWS, a set of business processes and activities were identified. The activities were analyzed to determine how the main failure and condition assessment application is used within the business. In doing so, common activities were extracted and decomposed using activity diagrams. The activities were then analyzed to determine system use cases suitable for the intended system. After further analysis, the system use cases formed a set of functional requirements that serve the needs of the stakeholders.

The system use cases describe the system’s functional requirements. Each of the use cases contains a specification that describes how users and the system work together. When looking further to determine how the system needs to do its job for the user, it is important to use the use case-driven approach to specify system behavior. A use case describes a sequence of actions, performed by a system, that yields a result of value to the user.

5. Develop Conceptual Solution
Once the functional requirements were documented in terms of system use cases, work began designing the conceptual solution. The following technology standards currently in place at HBWS were used. These standards include:

Microsoft SQL/Server
Microsoft Windows NT, Windows 2000
Visual Basic
ESRI GIS Technology
Microsoft Windows Based Servers and PC’s

In addition to the technology standards, a number of technical constraints were identified that helped determine the recommended conceptual solutions. Some of these constraints include the following:

The need for a local database on the client machines so that the application continues to operate when disconnected from the network and database server.
Email support requirement based on database triggers (e.g. when x is updated a certain group of people receive email notification).
The client applications will be dependent on connecting to the database if the network connection is active. If the database goes down all users will be unable to access the system. The implementation should include a redundant failover for the SQL server database to support a 24x7 operation.
GPS coverage may be limited around some areas of the island.

The conceptual architecture is a two-tier client/server system (see Figure 1.) The client side would consist of the end user client application communicating directly with a SQL/Server database on the server side. A two-tier system is recommended over a three-tier system, which would include an additional middle tier consisting of business logic using MTS components on a web server, due to limited remote access to HBWS web servers. HBWS web servers are only accessible through dial-up connection. There is no outside web access to internal HBWS servers.

The benefit of a two-tier implementation is shorter development time since there will be no need to build additional components in a middle layer, which act as the brokers between the database and client application. The drawback to a two-tier architecture is that future changes to the client application may require updates to the database, especially if the table structure is to be altered. Future changes may also require the updates to be synchronized between the database server and client computers.

Conclusion
HBWS and EMA used a business-driven methodology for the development of a conceptual solution to automate processes relating to water main failure incidents and pipe condition assessment. This methodology contained steps to identify the problems and root causes for the need to automate these processes, better understand the current business processes and develop future practices, create a functional requirements specification, and to develop a conceptual technical solution addressing the organizations needs. This methodology, focusing in the business, involved the end users and program sponsors in each step of the process. This end-user involvement was critical to maintain interest and buy in from the user community and ultimately resulted in a solution recommendation that truly meets the need of the employees that perform the work.

Next Steps
HBWS and EMA would use the business requirements and conceptual solution to evaluate Custom Off the Shelf (COTS) packages and related geospatial technologies that are currently available. A combination of COTS software and custom implementation will be required to transform the conceptual solution into reality.