GISdevelopment.net ---> GITA 2000 ---> Data Development and Evolution

Data for DMS/OMS - How much is enough and where to get it

Mark C. Hatfield, Hahn Tram
Convergent Group, 6399 South Fiddler's Green Circle, Suite 600
Englewood, CO 80111


Introduction
Improving and differentiating customer service and reducing operational costs have been part of utilities' strategies to stay competitive in the deregulated environment (Juhl, 1998). Outage Management Systems (OMS) have been proven to improve customer services by helping utilities reduce outage duration and by facilitating communication internally within utility operations and externally with customers and the public, particularly during storm outages. Distribution Management Systems (DMS), in addition, is a proven technology that helps utilities reduce operational costs of distribution by coordinating automated network and manual crew operations and by facilitating communication in the control room and operation centers (Tram, 1999; Tram, Engelken, Gay, 1999). Yet, data has probably been the most often cited reason for delays in deploying DMS/OMS, either because it is inaccurate, incomplete, or not up to date. This paper addresses: what data is needed, how much is enough, how to get it, and how much it costs. To set the framework for the discussion on data, the following is a brief review of the DMS/OMS functionality and its business benefits.

The major DMS/OMS applications include:
  • Trouble call management - Trouble calls entry, classification, and prioritization; restoration callback; automated trouble ticket closing and archive; etc.
  • Outage prediction, analysis and reporting - Automatic grouping and regrouping of outage calls into possible outage locations; automatic calculation of outage areas and customers, either confirming or restoring outages caused by network connectivity changes.
  • Trouble crew dispatch and management - Automated prioritization of outage tickets, decision support for selecting investigators and crews, and tracking of crew activities.
  • Outage restoration tracking, logging and reporting - Logging and reporting of restoration progress and outage closing information, e.g., outage cause, work performed, etc.; historical data archive, analysis and reporting.
  • Switching control and safety tagging - Decision support for emergency switching, planned switch order development and management, and switching and operation logs and reports.
The primary business drivers for implementing DMS/OMS vary among utilities, but the benefits of DMS/OMS generally include:
  • Reduced operating costs by providing decision support for dispatchers and system operators and by improving utilization of investigation and repair crews.
  • Improved customer service by automating on-line feedback of outage status to customers and service restoration confirmation, as well as a variety of differentiated customer services such as proactive customer communication of changes to the estimated restoration time and follow-up work status, wire warranty programs, etc.
  • Meeting regulatory requirements by providing information for outage reporting to the public and government, for timely status updates during storm outages, and for customer litigation research, etc.
  • Supporting asset management and planning by providing accurate data for reliability trending analysis, reliability improvement planning, reliability centered maintenance, and valued-based planning.
DMS/OMS Data Requirements and Impact on Functionality The DMS/OMS data and data modeling requirements are described in "Implementation of a Unified Data Model for Distribution Management Systems" (Tram, et al, 1999). Basically, the input data requirements include these four major data categories:
  • The as-built and as-operated connectivity and facility model of the electric distribution network
  • The landbase for displaying geographic background information and for locating network equipment and customer services based on street addresses or street intersection
  • Crew data for maintaining investigation and repair crew, vehicle types, as well as tracking crew availability and field activities
  • Customer Information, including customer name, premises address and phone number, electrical location (e.g., meter or transformer location), priority indication, etc.
Out of these four input data categories, the first two, the network model and the associated landbase information, represent the biggest data issues facing utilities that plan to implement DMS/OMS. Developing and properly maintaining this data will make or break the deployment of DMS/OMS at the utility. Therefore, the following discussions will focus on the network and associated landbase data.

The major differentiation factors in modeling the electric network and their impacts on DMS/OMS functionality are summarized below.

Model Difference Effects on DMS/OMS Functionality
Model Difference Effects on DMS/OMS Functionality
Graphical representation -schematic or geographic From the network switching operation standpoint, a graphical user interface is essential, whether the graphical representation is schematic or geographic. A schematic model may provide better clarity for the dispatcher or operator to make switching decisions. However, particularly if landbase data is available, the geographic model presents significant additional benefits: it helps the dispatcher associate noncustomer calls (e.g., police or fire department) with customer outage calls and direct crews to network equipment locations. Priority: Very high, geographic if landbase data is available.
Secondary network model For utilities that have extensive secondary networks, e.g., most European utilities and some U.S. utilities serving major urban areas, modeling the secondary allows the operator to isolate problems on the secondary and allows DMS/OMS to track outage statistics in a finer resolution. Priority: Low for most North American systems, medium for most European systems.
Three-phase connectivity model The three-phase connectivity model allows the calculation of customers affected by phase, e.g., the number of customers affected by blowing a single-phase tap fuse. The three-phase details are especially important to North American utilities that have extensive single-phase and two-phase circuits. The phase information will also support other important distribution engineering functions such as phase balancing. Priority: High for most utilities
Model of spans in addition to device connectivity Modeling the connectivity of only switching and interruptible devices is adequate for basic OMS if the utility does not perform temporary operations like line cuts and jumpers. On the other hand, including spans in the model would not only support the occasional line cut and jumper operations, but also pave the way for OMS to track storm damage assessments and for DMS to perform loading and voltage analyses as part of the switching and control function. Priority: High
Model Difference Effects on DMS/OMS Functionality
Including facility attribution in the network model Facility attribution is not strictly needed for a good OMS model. However, adding key facility attributes to the connectivity model has additional benefits. The dispatcher will be able to tell the crew what type and size of equipment may need to be replaced. The equipment characteristics such as ampacity and impedance will also allow DMS to perform loading and voltage analyses as part of the switching and control function. The attribution in the facility model will support asset management, planning and engineering functions. Priority: Medium
Without device internals versus with device internals Device internals are useful in modeling complex network objects like substation equipment, switch cabinets, and automated transfer switches. They are also useful in providing a clearer graphical user interface for switching these objects in a geographic representation of the primary network. In addition, because most Supervisory Control and Data Acquisition (SCADA) controlled devices are in these internals, modeling the internals become a must for SCADA – DMS/OMS integration. Priority: High
Landbase information The landbase information helps the dispatcher locate noncustomer calls and associate them with customer outage calls. When coupled with a geographic-referenced network model, it helps the dispatcher direct crews to network equipment locations. More frequently, government authorities are requesting utility reliability reports by geographic and political areas, e.g., townships and streets, not by substations and circuits. The landbase information will help such reporting. Furthermore, the landbase information is an essential reference for maintaining the as-built network data. Priority: Very High


Data Development

Conversion Process
Once the level of DMS/OMS data required to meet the desired DMS/OMS functionality is identified, the next step is to begin the conversion process of loading the network connectivity model into the DMS/OMS system. The conversion process is a painstaking and laborious process, the quality of which will ultimately determine the accuracy of DMS/OMS predictive algorithms and outage area calculations. Therefore, following a rigorous conversion methodology is essential to achieve the required DMS/OMS functionality.

The following conversion steps should be followed for populating DMS/OMS:
  1. Develop conversion specification(s): A conversion specification documents all conversion rules necessary to interpret the network sources. The source and conversion rules for each network object and attribute must be identified, default values for each attribute should be identified if data is missing from the source, and priority among sources should be identified if sources are in conflict. If source documents differ among operating companies or districts, a conversion specification must be developed for each unique documentation set.
  2. Develop data scrub procedures: Data scrub procedures are required to clarify, correct, and consolidate all source materials before they are delivered to the conversion team.
  3. Conduct a prototype: A small prototype conversion (one or two feeders) provides a minimum test of the conversion specifications to ensure the rules documented by a few experienced individuals can be interpreted by a larger conversion team. The prototype should adequately test all procedures, including a test of all data loading software and quality assurance (QA) software.
  4. Review prototype and modify conversion specifications: The prototype will demonstrate where changes, additions, and clarifications must be made. Take the time to make the changes. Once the prototype is complete, you are ready to begin full conversion:
  5. Freeze records: As you prepare each subarea district or feeder for conversion, you must formally freeze the source records. As the records are being converted, as-built and asoperated changes will be made in the area. You must be able to identify what has changed after you froze the records.
  6. Perform data scrub: Perform all data cleanup and consolidation tasks identified in your scrub procedures.
  7. Deliver sources to the conversion team: Require the conversion team to document all documents received.
  8. Implement a problem resolution process: No matter how good your sources and conversion specifications are, the conversion team will still have questions throughout conversion. Implement a system to report problems for clarification, track all problem resolution reports, and respond in a timely manner.
  9. Implement QA procedures: Ensure the conversion team is implementing a QA process at key steps in the conversion process that include both manual and automated checks. This process must include reporting procedures to track trends throughout the process.
  10. Implement an independent QA team: Once a delivery is made by the data conversion team, an independent QA assessment using manual and automated checks is essential.
  11. Post frozen records: Once the data is accepted, all changes that occurred after the records were frozen must be posted.
You can deploy DMS/OMS as operating districts are completed.

Typical Data Sources
The following identifies typical data sources for each level of network model:

Model Representation Typical Data Sources
Graphical representation - schematic or geographic Schematics, paper maps, CAD drawings, and/or GIS files are the typical sources for the primary network connectivity model. If these sources are not available, field inventory is required.
Secondary network model Schematics, paper maps, CAD drawings, and/or GIS files are the typical sources for the secondary network connectivity model. If these sources are not available, field inventory is required.
Three-phase connectivity model Schematics, paper maps, CAD drawings, and/or GIS files are the typical sources for the phasing model. If these sources are not available, field inventory is required.
Model of spans in addition to device connectivity Paper maps, CAD drawings, and/or GIS files Including facility attribution in the network model Paper maps, CAD drawings, GIS files, databases, spreadsheets, and manual records
Without device internals versus with device internals Schematics, CAD drawings, GIS files, and manual drawings.
Landbase information Existing paper maps, CAD drawings, GIS files, new landbase information created from orthophotography, purchased commercial landbase information (ETAK, GDT, etc.), and local government shared/public information.

Conversion Costs
The following factors will impact the cost and time of the project:
  • Internal team versus external contractor: Internal team may appear to be cheaper. An external contractor can do it faster; therefore benefits can be realized sooner while decreasing the total project cost.
  • Data quality: Your network data is not as good as you think it is.
  • Data migration: If you have a functioning network model in a GIS, your data is likely suitable for migration. If you have an automated mapping system, your data may or may not be suitable for migration (see bullet above). Migration is cheaper than manual conversion.
  • Customer-transformer-network link: Establishing this link is essential for successful
  • DMS/OMS implementation. Availability and quality of this link will impact cost and duration.
Considering the factors above, the following table identifies the general cost ranges for different model representations:

Model Representation Cost Ranges and Variables
Schematic representation of primary network < $2 per customer Variables: Quality of primary network source data; customernetwork link
Geographic representation of primary network (with landbase) $2 - $5 per customer Variables: Depth of DMS/OMS data model; landbase availability, quality of primary network source data; customernetwork link
Geographic representation of primary and secondary network (with landbase) > $7 per customer Variables: Depth of DMS/OMS data model; landbase availability, quality of secondary network source data; customernetwork link

Critical Success Factors and Lessons Learned
  • Create a good, complete initial database through a proven conversion methodology: Follow a proven data conversion methodology for rapid, high-quality development of the data. Data management is a unique skill set that takes years of experience to develop.
  • Maintain the data in a timely manner: Make data maintenance part of the utility's daily operation and work process, maintaining data at its source. Data maintenance must be part of the process and not an after-thought.
  • Make data maintenance easy: Implement an integrated business process and technology model that allows one-touch data entry and one-stop data access. The users will naturally postpone entering the data if it is painful and too time consuming.
  • Ensure data accuracy and integrity: Use proven data QA software tools integrated as part of the initial data development and the continual day-to-day data maintenance processes. Data quality must be an integral part of the data process, and data errors are best corrected at the time of entry.
References
  • Juhl, G., 1998, "Trends in the Utility Industry: Will They Make or Break You," GIS World, pp. 42-46.
  • Tram, H., 1999, "Integrating Utility IT Systems to Meet Distribution Management Needs in the Competitive Environment," Electric Light and Power, January 1999.
  • Tram, H.; Engelken L.; and Gay, A., 1999, "Strategy for Spatially Integrated Distribution Information Systems in Energy Delivery Utility Mergers," GITA Conference, April 1999.
  • Tram, H., et al, 1999, "Implementation of a Unified Data Model for Distribution Management Systems," DistribuTech Conference, February 1999.
© GISdevelopment.net. All rights reserved.