Using GIS to support natural gas leak detection
Brett Johnson, Dan Heselton, Nancy Pehrson Reliant Energy Minnegasco 700 West Linden Avenue Minneapolis, MN 55403 Introduction Reliant Energy Minnegasco is a natural gas utility serving over 685,000 customers in over 240 communities in Minnesota. REM, like other gas utilities, incurs significant costs in surveying its distribution system for leaks and maintaining leak records. Technicians conduct leak surveys by driving leak-detection-equipped vehicles over underground gas lines. Paper documents are used to track and maintain 19 types of surveys that can be performed on over 800 leak survey areas. Thousands of different survey records are produced. In 1997 REM was involved in the testing of a new leak-sensing technology. During this effort, automation of REM's leak detection system was identified as an area that could provide cost savings and other benefits and eliminate the intensive manual effort involved in the leak detection survey process. Early in the analysis phase, it was determined that the Automated Leak Detection System (ALDS): (1) needed to work with multiple leak detection technologies and (2) provide technicians with the capability of downloading on demand digital map data exported from the company GIS for scheduled or uniquely defined surveys. Our vision of the ALDS was to enable leak detection technicians to utilize GIS on a daily basis in their mobile survey work. The system would provide each technician with a list of scheduled surveys that added route tracking, leak location and completion date data as the survey work was executed. At day's end, data would be uploaded and imported into the company GIS. When a leak was encountered, the technician would be able to enter leak report information on a computer screen. Leak data would be uploaded to a construction work management mainframe system application. The ALDS would completely eliminate the paper map and leak report process in place at the time. We designed the ALDS vehicle systems to include on-board computers, GPS, and dead reckoning hardware integrated with leak-detection equipment. Xplore's GeneSys P133 hardened tablet PC was selected for this vehicle application. The computer's design met the functional requirements for the application and the screen visibility was evaluated as best for outdoor/vehicle use. We selected a vendor to customize a vehicle-mapping software package, write interfaces to the leak detection equipment and provide GPS and dead reckoning hardware required to obtain system accuracy. Software designed for the ALDS needed to interface with existing REM legacy systems and the vehicle mapping software while being user-friendly for field applications. Integration of the various systems needed to provide users with an application that appeared to be a single, easy-to-use system. Acceptance of the ALDS system was key to seeing efficiency and productivity results. Data model Development of in-house software to automate the leak detection process involved resolving a number of problems related to transferring data between existing systems and the technicians' field hardware. Before development work could begin, we defined a GIS data model. The major objects defined for the data model are the Leak Survey Area, the Survey Type, Survey Stage and the Survey Result. The model captures the relationships between GIS leak survey areas (LSA), the surveys associated with those areas, and the routes driven during the leak surveys. LSAs are digitized and all surveys in a LSA captured in a spreadsheet. Spreadsheet data is loaded into the GIS model in anticipation of the export process. Leak Survey Area LSAs are area objects that represent actual REM survey areas. Due to additions, replacements and reinforcements to the underground piping or gas main that makes up the gas distribution system, these drivable areas are very dynamic. Boundaries change, streets are added as gas main is run, deleted as gas main is abandoned and surveys modified as gas main piping types are replaced. During any one year, surveys are modified, deleted or added to the hundreds of REM LSAs. Prior to ALDS project implementation we maintained these areas by hand and kept all records in books. LSA maps had to be copied yearly and organized for work scheduling. This manual method of tracking made it difficult to know how many LSAs needed to be surveyed and when. Survey Type State and Federal regulations and company requirements result in different types of gas mains being surveyed at varying time intervals. Any given LSA could have one to many surveys to perform and complete. We designed the system to deal with Survey Types. The Survey Type object is a pictureless object that enables attachment of information about one or many surveys to a specific LSA. For one survey in LSA E10, one leak survey object is attached; for ten scheduled surveys in LSA E10, ten different survey types are attached. This method determines how many and which surveys need to be done for a particular LSA. The Survey Type contains information such as: Survey name (for special surveys) Interval (time between surveys) Last completed date Next due date Survey Stage Surveys can take anywhere from 10 minutes to 10 days to complete. Additionally, surveys may need to be stopped and resumed many times before they are completed. The data model must have the ability to capture portions of survey routes at a time. This is accomplished with the Survey Stage object. Some of the most important data captured with this object are: Survey type Survey name Technician Start data and time End date and time Miles surveyed Leaks found Survey status Survey Result The Survey Result object in the data model is basically a totaling bucket. Every time a new leak survey is begun, a new Survey Stage is imported, a Survey Result created for that survey, and the Survey Stage attached to the created Survey Result object. Subsequent Survey Stages for this survey and its data are added to the Survey Result object. The Survey Result object is itself attached to the Leak Survey Area that this new Survey Stage is created for. Some of the information totaled for both in-progress and completed surveys is: Survey Miles Number of Leaks Status GIS data is used to define leak survey background maps. This data represents a subset of land and gas objects. REM's leak surveys are divided into 5 regions with leak technicians assigned primary responsibility for leak surveys in specific regions. Initially it was thought possible to export all the data for a region at a time. Data for these 5 regions would be exported into 5 different directories. The leak technician would come into the office and download a copy of the region being surveyed. The need for speed and reliability made the export process infeasible. It was estimated to take up to 8 hours or more to export just the gas main data for a region. The time is an estimate since PC resources and translation crashes prevented any successful attempts at export completion. We decided that exporting data by Leak Survey Areas, instead of regions, would provide flexibility in workload and scheduling, but still be manageable from a time and data volume standpoint. We developed an in-house application to automate the conversion process. Prior to export to the FTP site, the application enables selection of any combination of LSAs and GIS data within the LSA. The process involves identification of the LSA, selection of the objects to be exported within the LSA, passing the selected objects to the translator for conversion and writing the files to the FTP site. Surveys were evaluated to determine which GIS gas main files needed to be exported for a particular survey. Multiple types of gas mains can be on a street, yet the technician is interested only in the type of gas main associated with the survey he is currently performing. For example, if a LSA has a "Cast Iron" and an "All Mains" survey associated with it, the in-house application creates two different gas main shape files for the LSA. Interface files used by the technician and the truck application are also created at this point. These files provide the technician and the truck application with survey schedule information and identify to the on-board system what shape files are to be displayed on the computer screen for each survey. Data download Exported data is downloaded over the company LAN to vehicle computer hardware for use as background maps for display on the vehicle-mapping software. We developed a company Visual Basic application so on-board computers can connect to the company FTP site over the LAN or phone line. Depending on the work scheduled, technicians select LSA maps required to complete the day's work. Data is downloaded, providing technicians with information concerning scheduled survey work. Once on the road, the technician selects the survey to be executed from a list of surveys previously downloaded. Vehicle mapping software Customized vehicle mapping software captures survey information i.e., truck route, elapsed time, mileage, and leaks detected. This capture is vital to the ALDS process. In order to meet our needs, customization of mapping software was required. Successful implementation depended on finding a vendor who was willing to partner with REM on the customization of the software mapping application to meet functionality requirements. We selected Baker-GeoResearch for its willingness to customize its mapping program. The software program (GeoLink) was modified to use exported GIS map information as background display maps. The software also tracks vehicle location and collects survey (trace) and leak information during survey execution. Increased productivity is gained by the system's ability to perform more than one survey concurrently. Geolink, the truck application and import application required modification to achieve this concurrent performance. The size of the "Survey Type" field was increased, and relationship in the data model modified. Leak survey types are associated using the truck application. We added a dialog box to query whether surveys are to be associated with an initially selected survey. If the answer is yes, the technician is directed to select additional surveys for that LSA. Once all surveys are selected, the application compiles a delimited list of the Survey Types to be started into the Survey Type field of the Survey Stage object. At this time, all gas main files needed for the survey are displayed. Baker-GeoResearch also provided interfaces to the leak detection software and expertise in GPS and dead reckoning equipment. The leak detection interface provides visual display of leak detection equipment readout and audio and visual notification of preset methane levels. The software continually displays GPS headings and dead reckoning equipment status. Upload data Survey data and leak information are uploaded to the company FTP site and mainframe. We internally developed a Visual Basic application to upload the leak and route information to the Leak Detection and GIS systems. This Visual Basic application uses the LAN or a phone line to connect to the company FTP site. A technician need only connect and then press an "upload button" to send data. The upload process performs two functions. Captured leak information is sent through IBM's Mqseries to a queue residing on a CICS region. Once the leak resides in the queue a COBOL program automatically starts, selects the record and inserts it into the leak detection system. The survey route, in a shape file, is uploaded to the FTP site where it waits for importing into GIS. Import file conversion Uploaded shape files are inserted into the GIS database as Survey Stage objects. A determination is made as to whether the survey is new or a continuation of a survey in progress. An in-progress survey has its Survey Stage attached to the Survey Result object and the totals are updated. A new survey has its Survey Result object added with the new totals. New or in-progress Survey Result objects are connected to the Survey Type and Survey Stage, the result object is updated and the stage connected. The survey status, completion date, times of the survey result and the survey type are updated appropriately. When a leak survey is completed, the next due data field on the survey type object is updated to reflect the new date. To accomplish conversion, an import application using SAFE Software FME translation software was created. The translator takes the truck survey route in the shape file and creates a Survey Stage object. This data represents the route the technician drove to complete the leak survey. When the survey is designated complete, the import application updates the model with a complete status and assigns the next due data to the survey based on a defined time interval dependent on survey type. This prepares the survey and inserts it into work status with the proper target completion date. Results The results have been impressive. Many surveys have been consolidated and documented in one record. Employees and regulators appreciate this consolidation during audits. Paperwork has been greatly reduced. The time consuming task of preparing hand cloned survey maps is no longer required. Documentation is performed as the survey is executed, no longer requiring the technician to spend additional time after the survey to document execution. The ALDS system is more than a replacement for paper maps. ALDS provides the ability to easily perform and document more than one survey concurrently. It provides leak route, main and leak information on a single screen. When a leak is detected, the technician can easily find the exact coordinate where the leak was detected; optimizing the time it takes to pinpoint the source of a leak. System generated work schedules allow for optimized use of resources and have simplified scheduling to meet survey completion dates. When a survey is completed, the system automatically updates the due date. This information is always available and can be generated at any time to determine the scheduled date of any of the thousands of surveys to be performed. Resources can be deployed on a daily basis as required. Survey route direction is provided to the technician in a format that is easily seen and understood. Any technician can perform work in any region. The system directs the work, not the experience of the technician with a particular area. Any survey to be performed can be quickly selected by date and displayed on-screen with the truck location centered in the area to be surveyed. Preparation required for regulatory audits has been streamlined. Instead of accumulating, organizing and reviewing thousands of paper records, auditors can sit at the GIS system and easily verify regulatory compliance. Considerable time had previously been spent updating maps to include new gas main. Since all the LSAs are on the GIS this function can now be programmatically performed. Lessons learned Implementation problems resulted in several lessons learned. One of the more interesting problems we ran into was how to enable the technician to capture important field-generated surveys like odor investigations or what REM refers to as "Special surveys". To resolve this problem, we modified the truck application and the import application. For the majority of surveys started on the truck application, the technician selects the appropriate survey from an easily read table and the survey starts. When a field generated or odor investigation survey is started, the technician is prompted to enter a survey name. This name must be unique. In the odor investigation example the address of the call is entered. When this survey is imported, stages are processed differently. A Survey Type and Survey Result are created and connected but the Survey Stage is attached to the new result. Since these surveys are performed once only, they are automatically completed once they are created and they are not rescheduled. During initial testing it became apparent that technicians were performing more than one regularly scheduled survey at a time to gain productivity. It is important to fully understand the work that is being performed and how it is performed before automated systems are implemented and we had not fully accomplished this in the design phase. This knowledge required modifications to the truck and the import application. The importance of understanding what is happening in the field and why it is happening can not be emphasized enough. Working closely with the field technicians during development minimizes changes to the design during implementation as well as creating a shared sense of ownership, which can only improve the likelihood of project success. When implementation takes more than a year, as it did with this project, staying current with software is essential. Vendors are constantly upgrading software products that result in changes to software performance, some good and some bad. The ALDS application uses software from 3 vendors as well as several customized "in-house" applications. Taking advantage of newly updated functionality is desirable. If software upgrades are not implemented to keep versions in synch, problems may result and support effectiveness in problem resolution can become negatively impacted. When a software product is customized for a particular application, customized code changes need to address all changes to the basic product. If not, when the upgrade is implemented, the system may no longer perform in the same manner. Integration is difficult but worthwhile. The in-house applications make the multiple software programs appear as one and disguise the complexity of the programs involved. ALDS is user friendly and liked by those who use it. Keeping truck PCs in synch during development is very difficult. Changes and modifications made to software need to be loaded on all field hardware tested. More than once, we found ourselves solving a problem we thought we had resolved, only to find the PCs were not identically imaged. What next? Near Term To improve file transfer efficiencies, the export function will be modified to create only the files necessary for survey purposes. Instead of exporting base map information that rarely if ever changes, such as street location and name, gas main data only will be involved in the export function. Leak information will be captured and imported to GIS. This will expand use of the application from documentation purposes only to use for analysis and evaluation of distribution system replacement plans. While we have referred to this system as mobile, the technicians do leave the vehicles on occasion to perform short walking surveys of areas that can not be reached by truck. We want to incorporate the ability to draw the walking portion of the survey on the truck route trace. Customization of the truck application hardware will be required in order to do this. Further Out To enhance scheduling flexibility, we are interested in pursuing a Web-based GIS application. Taking advantage of REM's Intranet for data transfer would enable technicians to access data from the field and not have to return to base to access the LAN. Two technologies with promise in this mobile application are voice-activation software and vehicle heads-up display. Voice-activation software has advantages over both keyboard and touch screen technologies. Not needing a keyboard increases user acceptance and not using touchscreens can reduce maintenance problems caused by improper use. No current laptop provides excellent visibility in direct sunlight. It is expected that vehicle heads-up displays would eliminate this problem. Current work by vehicle manufacturers in the area of windshield displays for their on-board electronic based systems may allow for this option in the future. | ||
|
|