Logo GISdevelopment.net

GISdevelopment > Proceedings > GITA > 2002


GITA 2002 | GITA 2001 | GITA 2000 | GITA 1999 | GITA 1998 | GITA 1997
Sessions

Applications

Data Development & Evolution

E-Biz

GeoSolucions

Mobile

Municipal Perspective

Network Operations Management

New Technology

Project Management

System Architecture

System Integration

The Human Factor

User Presentations

Work Management


GITA 2002


Mobile - Taking it to the street


When two technologies converge: Supporting service restoration in the field


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.
Page 3 of 6
| Previous | Next |

Applications | Technology | Policy | History | News | Tenders | Events | Interviews | Career | Companies | Country Pages | Books | Publications | Education | Glossary | Tutorials | Downloads | Site Map | Subscribe | GIS@development Magazine | Updates | Guest Book