GISdevelopment.net ---> GITA 2002 ---> Mobile - Taking it to the street

When two technologies converge: Supporting service restoration in the field

Ivor Block
BC Hydro, 6911 Southpoint Drive (E10), Burnaby, B.C., Canada V3N 4X8
Phone: (604) 528-2466
E-mail: ivor.block@bchydro.com
Web site: www.bchydro.com

Alan Mah
Westech Information Systems Inc., 401 West Georgia Street, 14th Floor, Vancouver, B.C., Canada V6B 5A1
Phone: (604) 663-3447
E-mail: alan.mah@westechinfosys.com
Web site: www.westechinfosys.com


Abstract
To complete their outage management process, BC Hydro 3 deployed a mobile GIS to put field crews on the same page or map as the trouble centre dispatchers. The ability for the crews to hot link from wirelessly transmitted trouble orders to the actual trouble location on a laptop running the mobile GIS has improved both efficiency and safety. This presentation discusses the successes and pitfalls to actually implementing a mobile GIS in the field.

Introduction
At BC Hydro, GIT has had roots back to their first AM/FM system in the early 1980’s. Converting to new software platforms in 1989, and 2000, their enterprise geographic information system (EGIS) now covers the entire service area, and contains both the topology, and the electrical network. From the earliest days of GIT at BC Hydro, mobile computing was one of the visions. Since 1992, there have been several mobile computing applications that use geospatial information.

Outage Management is an essential responsibility for all electric utilities. Prompt restoration of service, and effective communication with customers are two key factors in maintaining high levels of customer satisfaction. Through the use of an outage management system, BC Hydro has been able to improve both their ability to keep the lights on, and their ability to let the customers know more about the status of their outages. Technology has allowed the outage management task to move from a manual process to a system where automation not only helps call centres, dispatchers, and power line technicians (PLT) do their job, but it has all but eliminated busy signals when customers call to report outages during storms. Both geospatial technology, and mobile computing are essential to the success of the outage management system.

In this paper, we will describe some of BC Hydro’s mobile geospatial computing applications, and mobile dispatch applications. We will show some of the pitfalls of the early applications, and how the convergence of mobile geospatial applications and mobile dispatch applications assist power line technicians, and how future enhancements will not only improve efficiency, but also improve workplace safety. Mobile Geospatial Computing Applications:

For BC Hydro, adopting mobile geospatial computing has had its challenges. Since the first system in 1992, the Service Design System (SDS), there have been great advances in software and hardware technology. In hindsight, faster hardware and more advanced software would have benefited the early applications. However, not all of the challenges have been addressed by new technology, and many of the lessons learned by the early applications have been invaluable when creating new tools. In planning their latest system, as with SDS, BC Hydro knew that trade-offs were necessary to arrive at a cost-effective solution that meets the desired business objectives. Some of the early systems include: Service Design System, VegMap, Service Data Collector, and Trouble Call Management System with Mobile Dispatch System. The following is a brief description of each of these earlier systems, their main features, and the challenges associated with each of them:

Service Design System (SDS) – 1992 Release 1 / 1994 Release 2
Service Design System was a mobile geospatial computing application that allowed service designers to make connections of services to customer locations. The main geospatial system did not have a mobile software component, so a third party product was used to develop this application.
  • GIT data was extracted from the main GIT data base, and converted to an intermediate format. An additional conversion was required to create a map backdrop – no object attributes were translated in the initial conversion process.
  • A second extract process created a separate data base with separate attribute files, and indices for lookup tables – very few objects had their attributes converted.
  • SDS was a pen enabled application.
  • Hardware - Monochrome laptops with both pen and keyboard interfaces
  • Limited electronic storage on these units
  • Slow processors (Intel 80286 and 80386 processors) and expensive system memory
  • Data was mapsheet based.
  • All of the data had to be re-extracted to refresh – incremental updates were not available.
  • The second generation of this application gave the ability to automatically load the next map, if you panned to the edge of the existing mapsheet.
  • SDS did not have the ability to query all devices. Only devices that had the second extract performed on them to create separate attribute files could be queried.
Due to the slow hardware available at that time, the amount of processing time required to extract and convert data for use by the application made it difficult to deploy. Pen interface standards and scripting languages were not as well established as they are presently, and so clients did not readily adopt the pen interface. Mapsheets were in small chunks, and programs were created to automatically load the adjacent map sheet when the client panned to the edge of the display. The application was used primarily as a map-viewing tool.

Vegetation Management (VegMap) 1994 Release 1 / 1997 Release 1.4
VegMap was designed to add a geospatial component to a data collection process.

A vegetation management specialist would identify properties that had trees which endangered power lines. He would inventory the trees on the property, and file recommended remediation techniques on his laptop computer. With this data, the vegetation management specialist would obtain permission from the property owners, and use the collected data to create maps, and reports, and include them in packages for the tree trimming crews.
  • GIT data was extracted from the main GIT data base, and converted to an intermediate format. An additional conversion was required to create a map backdrop – no object attributes were translated in the initial conversion process.
  • A second extract process created a separate data base with separate attribute files, and indices for lookup tables – only power poles had their attributes converted.
  • Hardware – Colour laptops – Pen interface optional
  • Limited storage on these units
  • Somewhat better processors (Intel 80386 and 80486)
  • Data was mapsheet based.
  • All of the data had to be re-extracted to refresh – incremental updates were not available.
VegMap was actually a mobile geospatial program, run from within a data base program. The data collection was primarily to populate the data base program’s data base, while the existing geospatial data was used as a map backdrop. The freshly collected data was geospatial, but it was never sent back to the main GIT data base. Data extraction was still a long process, however, a common tool was developed to extract data for both SDS and VegMap. This generic extract tool would be used as the front end for many of the early mobile geospatial applications. Incremental update of the geospatial information was not possible. The system was more popular in rural areas where a mixture of public and privately held land made it difficult to tell who the owner of a property was. With the land parcels from the main geospatial data base, the map backdrops made it easier to determine property ownership.

Service Data Collector (SDC) - 1999 Release 1
Service Data Collector was a data collection application, used to improve the quality of the main geospatial data base. The data translation process was performed by the Service Data Collector application. Edits created in SDC are output in a format recognized by the main geospatial data base, as a result, changes made in SDC are ready to load back to the main geospatial data base. The application was used for digitizing service connections to customers, and to associate customer locations with their account in the Customer Information System (CIS.)


Figure 1. Service Data Collector

  • GIT data extracted from the main GIT data base could be read into SDC. The client did not perform any additional conversions (the application took care of the conversion.)
  • CIS information was extracted from the Customer Information System, and loaded onto the laptop.
  • Hardware – Special monochrome portable computers called pen tablets – used a stylus and glass keyboard
  • Good processors – Intel Pentium I processors
  • Data was mapsheet based.
  • All of the data had to be re-extracted to refresh – incremental updates were not available.
Service Data Collector managed several things better than the original Service Design System. As the application could import and export data from the main geospatial data base in its native format, it eliminated the requirement to convert to an intermediate format. It also supported attributes for the data. A second conversion to populate attribute tables was no longer necessary. It also had additional functionality, including a Global Positioning System (GPS) receiver which allowed the application to locate the correct map sheet to position the field personnel. Still the application was mapsheet based, and incremental updates were not supported.

Outage Management Systems:
Traditionally, trouble centre staff in each regional office would have telephones, manually drafted maps, and a radio to receive customer calls, determine where the outage might be, and to dispatch crews. In the late 1980’s the first computer aided mobile dispatch system was put in place for the trouble centre staff. In the early 1990’s, the first computer system to manage trouble call entry was integrated with the mobile dispatch system. The initial trouble call management system handled customer calls, and kept track of whether crews had been assigned to them.

Following is a brief description of Trouble Call Management System (TCMS) and Geospatial outage management systems (Geospatial OMS) with their interfaces to Mobile Dispatch (MD). We’ll look at their main features, and the challenges associated with their use.

Trouble Call Management System with Mobile Dispatch early 1990s First Release Developed on the mainframe, TCMS allowed staff to create records for each trouble call.


Figure 2, Trouble Call Management System – Entering a new trouble call

  • Provided the ability to send work orders to crews
  • Analysis of the trouble calls remained manual.
  • There was a map component in the dispatching software that would give you the approximate location of the outages and the crews.
  • Crews could update work status (received work order, enroute, arrived, complete) through their mobile data terminal.
  • Software had limitations during storms (only handle 1000 trouble calls at a time.)
Limitations
  • If trouble centre staff were busy with another client or crew, clients would get a busy signal.
  • There was no mechanism to easily give clients an update on the status of their problem – staff would have to look up the problem in two systems to determine the status.
  • System was vulnerable to overloads during storms.
  • Dedicated hardware was required in the service trucks.
  • Wireless dispatch system worked only in areas where radio or cellular network repeaters are present.
  • Crews kept map books in their trucks to determine where they are going, and they also had sets of circuit location diagrams to assist in locating devices out in the field.
Geospatial OMS with Mobile Dispatch 1999 Release 1
Geospatial outage management system (Geospatial OMS) is being phased in to replace TCMS. Geospatial OMS uses the network connectivity of the GIT data to allow for prediction of failed devices on circuits. Geospatial OMS is linked to the Customer Information System (CIS) to relate customers to their phone numbers, so when a customer calls, they can be located in the GIS by providing their home phone number.


Figure 3, Geospatial OMS – Geospatial display of a crew truck that has arrived at the service location

  • Trouble calls are received, then using the network connectivity information, the likely failed device is predicted.
  • Additional trouble calls can change the prediction to a device further upstream.
  • Subsequent calls for outages on the same device are then filtered out by an Interactive Voice Response (IVR) system.
    • If the outage is already known, the IVR returns a message explaining the status of the outage to the customer.
  • Integrates crew dispatch function with trouble call analysis
    • Once the prediction is made, crews are dispatched using the same mobile dispatch system that was developed for TCMS.
  • Uses the Cellular Digital Packet Data (CDPD) network where available
    • Otherwise crews must go to the local office to pickup hardcopy trouble orders.
  • Crews feed information back to the dispatchers using their Mobile Data Terminals (MDT.)
  • Crews inform dispatchers of en-route, arrived, predicted time of restoration, actual restoration time, actual cause of outage, comments.
  • Changes to the work order can be sent to the crew via the mobile dispatch system.
  • Introduced an Intranet interface (Q4 2000) that allows a text based interface to dispatch crews

Figure 4, MDSI – Trouble order as received in the crew truck

Limitations
  • Proprietary MDT hardware.
  • MDS hardware aging and becoming difficult to maintain.
  • Requires excellent data (geospatial and CIS) to be successful.
  • Crews do not have access to electronic mapping.
  • Crews must be in the cab of the truck to receive or send information.
  • Wireless dispatch system works only in areas where radio or cellular network repeaters are present.
  • Crews still keep map books in their trucks to determine where they are going, and they also have sets of circuit location diagrams to assist in locating devices out in the field.
Convergence - new products for GIT and OMS Mobile Computing
As our dependence upon electrical devices grows, and the infrastructure to deliver electricity grows, the urgency of restoring power to customers grows more important. BC Hydro recognized that its geospatial data could be used to assist with the outage management process. In 1999, installing the new geospatial outage management system and merging it with the existing mobile dispatch, and trouble call entry systems, proved that you could assist the service restoration dispatchers by giving them geospatial data. We will describe the new products that ha ve emerged in 2001. New products that make mobile dispatching more flexible, and new products that equip the service restoration crews with geospatial data. Finally we will look to the future, the plans for 2002 and beyond, and how convergence of the existing technologies, and new communications technology will help “keep the lights on” for BC Hydro.

Geospatial OMS with Web Remote Dispatch 2001 Release 1
To address the aging mobile dispatch system, a new system is being piloted. This new system uses Web technology to remove many of the limitations of the original mobile dispatch system. Added onto the geospatial outage management system, the Web Remote Dispatch System has all of the functionality mentioned in Geospatial OMS with Mobile Dispatch p lus the following additions:


Figure 5, Web Remote Dispatch – dispatchers view of projects and available crews on a web browser

  • Dispatch application uses XML and thus is compatible with web-browser enabled devices such as desktops, laptops, Personal Data Assistants (PDA) (non-proprietary hardware.)
  • The PDA implementation will allow crews to receive and send information from outside of the cab of the truck.
  • Dispatch application is served from a web server.
  • Worked with the vendor to ensure that amount of data transmitted was kept to a minimum to keep data transmission costs down
  • Easy to use for both dispatchers and crews
  • Integrated into the outage management system
  • Use CDPD initially
Limitations:
  • At the time of initial product development, PDA web-browser software was not robust enough to support the application.
  • Wireless dispatch system works only in areas where cellular network repeaters are present.
Mobile Map Viewing System – 2001 Release 1
The Mobile Map Viewing system was designed for use by the power line technicians, when they were out in the field restoring electrical service. This system was designed as a viewing tool, so edits cannot be loaded back to the source geospatial information system.
  • GIT data is extracted from the main GIT data base, and imported into the application.
  • Indices are created during the data import.
  • Hardware – Pentium III laptops w/colour displays
  • Data is pre-loaded into truck mounted laptops.
  • Contiguous maps
  • Incremental updates supported
  • Clients have the ability to query all devices.
  • Clients have the ability to display pre-defined and define own map types.
  • Clients have the ability to theme according to pre-programmed criteria.
With the mobile map viewing system, there have been significant improvements over the earlier data collection and map viewing tools. Contiguous data as opposed to map sheet based data, support for an incremental update of the map data, the ability to view map types, and theme based on circuit are all advanced features of this system.

Geospatial OMS with Web Remote Dispatch and Mobile Map Viewing System (2002) Although it would be best to always send fresh maps to the crews, the reality of spatial data is that even with compression, a large amount of data must be sent to the crews to provide usable maps.

Additionally, if you provide attribute information the amount of data transmitted increases yet again. With the cost of wireless data transmission still remaining relatively high, the alternative is to pre-install geospatial data in the trucks, and to send crews a key to bring up the correct part of the map on their map viewing system. This is the approach that BC Hydro has taken with providing service restoration crews with spatial data.


Figure 6, Mobile Map Viewing System – circuit trace

Features of the merged applications:
  • Trouble orders sent to crews via their remote dispatch system, will include instructions for the mobile GIT that will show the crew the location of the failed device.
  • Crews can perform many functions on the mobile GIT:
    • trace the entire circuit
    • highlight tie points
    • query devices on the circuit to find more information
  • Eliminates the need for map books and circuit location diagrams in the trucks
  • Quicker draw times for maps, as compared to receiving map data live over a CDPD connection
  • The entire process, from trouble call entry, trouble prediction, dispatch to crew, look up of location, completion by crew, and closure of record by dispatch staff does not require paper.
  • Crews no longer need to keep map books, or circuit location diagrams in the service trucks.
The following chart (see Table 1) shows the evolution of the mobile geo-spatial computing applications at BC Hydro, and how the functionality has improved over the years. Key breakthroughs to increase acceptance of GIT that are not shown on the chart include:

Table 1 Features vs. Mobile Geospatial Computing Application

  • Enhanced Quality Assurance checks on the geospatial data Œ builds user confidence in the tools they are taking out into the field
  • Faster input of data into the geospatial system Œ better tools make it easier to enter data into the system
  • Faster hardware that allows large amounts of data to be installed on mobile devices, and also permits complex processing such as network traces to be conducted out in the field
Drawbacks of the merged applications:
  • Data is currently updated by creating Compact Discs (CD) with incremental updates, then manually loading these updates onto the laptops in the trucks.
  • Restricted to use on laptops Œ map viewing component cannot yet be deployed on PDAs
Future Enhancements
The next development area for the BC Hydro project has not yet been identified, however, these are some of the technologies and business objectives being watched.

General Packet Radio Service (GPRS) – As coverage improves, and prices of modems continue to drop ($500 Canadian at time of writing), this technology will improve data throughput to 6 times as much as CDPD (60 kb. vs. 10 kb.) GPRS does not have sufficient bandwidth to send detailed maps to a laptop, however, view-only maps sent to a PDA would be practical. Provides better security than CDPD and superior throughput. The drawback is limited coverage outside of urban centres, and additional cost of securing enhanced availability.

802.11b Wireless LAN – Instead of physically connecting laptops to the LAN, or creating CDs to load new data, using a wireless LAN, we can update GIT data once the truck is back in the yard

Global Positioning System (GPS) – GPS would provide the ability to locate service trucks. This would help dispatchers to better determine which crews to dispatch, and allow emergency crews to be directed to their exact location, should aid be required. This would be benefit both productivity and safety.

Satellite communications – Satellite communications could be used to deploy the application in a mixed terrain environment, where CDPD, or GPRS may not completely cover the service territory. Seamlessly switching between CDPD, GPRS, radio and satellite communications to maintain communications between dispatch centres and crews.4

Safety – For safety reasons, we are considering equipping power line technicians with PDAs. The plan is to incorporate man-checks into the software, such that when a crew member is in the bucket portion of a line truck, they must check-in at a prescribed interval, and this check-in needs to be recorded. With a PDA, the check-in can be done from the bucket with one action on the PDA, as opposed to the calling into the dispatch centre, or waiting to return to the cab of the truck. Recording of the check-in can also be incorporated into the system.

Display of maps on PDAs – Wireless technology already implemented in our web remote dispatch software can be adapted to allow us to deliver maps directly to a PDA. Compression technology for the delivery of map information and the cost of wireless communications are the critical barriers to proceeding with this technology. With existing CDPD technology, throughput of 10kb is not sufficient to display usable maps on PDAs.

Suggestions for Others:

Big bang vs. Incremental Victories
Don’t rely on the big bang to solve all your problems. The BC Hydro outage management system has evolved through small and large incremental victories. Along the way there have been challenges, such as data quality, emerging technology, cost of wireless services, cost of hardware, acceptance by employees. In most large organizations there is a resistance to change, unless you can show that the changes are beneficial. Throughout the process, each incremental change has had to prove itself.

© GISdevelopment.net. All rights reserved.