Peter Di Turi, Seattle City Light

SERVING GIS DATA TO ELECTRICAL DISTRIBUTION ANALYSIS

TABLE OF CONTENTS

ABSTRACT

Seattle City Light has made an intensive investment in its GIS database. Information from this database, normally derived for cartographic production, is given new life as part of a simulated model which analyzes City Light's primary distribution system. The ability to integrate the database design of the GIS to a vendor's turnkey software design is of great benefit, but is a highly challenging task. In comparison to developing an application proprietary to its own GIS, City Light determined that exporting data to a distribution analysis software package is a much quicker and more cost-effective solution.

The development of applications to extract, manipulate, relate and format GIS data for a software package can only do so much to simulate a real-world scenario. The software requires detailed information for each distribution system component. Assumptions are made upon available data, electric utility standards and software development limitations where they occur. The benefits of automating updates to the distribution analysis software database helps ensure the design engineer that data is as timely and exact as what exists in the GIS. The electrical design engineer becomes more productive, and the distribution system benefits from an implementation of a highly efficient, computer-assisted electrical design.

INTRODUCTION

Seattle City Light, a 94-year-old municipal utility, has over one- third of a million customers (ranging from residential to the Boeing Company) in a compact 131 square-mile area covering Seattle and surrounding areas of King County. Its average customer rate is the lowest of any major city in the United States, yet City Light tracks the efficiency of its equipment over its 3,600-plus miles of distribution. The aging of City Light's inventory and constant change in customer needs force City Light to analyze its distribution system, and make improvements.

Computerized feeder analysis was discussed at City Light as early as the late 1960's, but would not be reconsidered until the mid- 1980's with the advent of geographical information systems (GIS) software. City Light participated with other City departments in creating a land database as the background for quarter-section (half-mile square) maps which were converted from manual to digital form. Distribution conversion started in 1991 with a four square-mile prototype, and upon the successful completion of the prototype, full conversion began in 1992 geared toward an initial 2001 completion date. However, an opportunity arose to save the City of Seattle time and money, and a new vendor was selected from an RFP process. The result would be a several million dollar savings and a conversion ending five years sooner. With the increased availability of data, there was now a greater impetus for distribution analysis.

NEEDS OF THE ELECTRICAL ENGINEER

City Light's conversion prototype not only proved that maps could be automated, but also that the same data could be reused to model electrical distribution. In 1991, a pilot was performed to show that AM/FM data could be reused by a GIS application to perform a trace from a substation to a customer. The successful trace was enough evidence for City Light's management to prove that this test application would be a useful tool for analyzing the utility's distribution system.

The electrical engineers saw far more potential. Tracing meant that the engineer could actually determine the spatial extent of a feeder and its laterals. In a non-automated system, it is necessary to manually maintain both quarter-section area maps as well as feeder maps, and one can only imagine the probability of errors just attributed to inconsistency, let alone data errors. A feeder could have its load analyzed, voltage drops measured, line losses determined, fault currents calculated, and capacitor placements determined instantly. Fuses could now be checked for reliable coordination, and the availability of secondary in City Light's AM/FM design meant that transformer load management was realistic. Undersized conductors could be singled out quickly, and "what-if" testing could give an engineer flexibility in design and cost. Analyses that took person-weeks could be done in minutes. In power operations, this tool could even be used to detect the nature of outages.

THE RATIONALE OF THE SYSTEMS ANALYST

The systems analyst was faced with a dilemma: building a GIS- based application in-house versus interfacing with a vendor's application to meet the electrical engineers' needs. There were several factors that were important in arriving at such a decision:

1. Scope.

What electrical engineering needs would be covered for this task?

2. Deliverables.

What would be provided for distribution analyses?

3. Schedule.

What would be a reasonable time frame for providing the deliverables?

4. Budget.

How much in labor and materials would this cost City Light?

5. Engineering expertise.

Who would provide specifications and work with application development?

6. Application development expertise.

How could we get the best electrical and GIS expertise?

7. Maintenance.

What would be the long-term means of maintaining data and supporting distribution analysis applications?

CRITICAL FACTORS IN DETERMINING THE BEST PRODUCT

Each factor went though an analysis of its own:

1. Scope.

City Light usually doesn't have any major problems with voltage drops. However, it does have a problem with undersized neutrals, and wants to have them singled out. Our current AM/FM database supports that capability. Yet, in designing new feeders or shifting loads through switching or among phases, there is a definite need to measure the performance of a feeder in a model before implementing enhancements in the real world. The proposed GIS application would require intensive calculations which are best handled by a C or FORTRAN routine through a procedure call. This will require some serious application development. But wouldn't it be easier to export data to an application already designed for this purpose and save the application development process?

2. Deliverables.

The engineer needs something that is easy to use. Our engineers are familiar with PC-based applications which they use for administrative purposes. Learning something on another operating system platform will take time. There should not only be deliverables for use by the engineer (analysis tools, graphical selection options, report options, et al.), but also an incentive to use these deliverables. If the engineer can use the software to easily solve a system-wide problem, such as replacing undersized neutrals, this would give the engineer an incentive to use the software instead of traditional data acquisition and research methods. If City Light decides on a third-party solution, then the engineers should see that the necessary deliverables are satisfied by the solution.

3. Schedule.

The engineers haven't had anything like this before, so initially they would be happy with a modest amount of deliverables. Let's take the time to do things right the first time and make a realistic schedule on providing quality deliverables. The schedule will be driven chiefly on in-house application development and testing.

4. Budget.

We don't have enough funding to procure additional labor for this task. Conversion labor won't be available for almost another year. Can we do this task at all with one full- time equivalent? What will it take for that to happen?

5. Engineering expertise.

If we develop the application, the engineer must supply formulae and all relevant specifications needed for evaluating our distribution system. The engineer must also verify the results in testing the application. If we use a third- party solution, all the engineer needs to provide are the specs needed by the solution. Besides that, our engineers' time is quite limited; can we rely on their full support?

6. Application development expertise.

We need someone to develop front-end and back-end interfaces to this application, and know all of the possible sources to the application. A third- party solution with an external data interchange will remove the need for front-end development.

7. Maintenance.

The existing process of maintaining quarter-section maps can be folded into a much larger-scale process to report potential feeder data errors, correct them using the existing AM/FM database maintenance procedures, detect changes in the AM/FM system, determine feeders affected by such changes, and automate conversion of those feeders as needed.

Based upon a limited budget, City Light also limited its scope by developing specifications for a third-party distribution analysis software solution with an external data interchange. Because of changing engineering and technological priorities, several iterations of specifications were developed and reviewed until a set was given full concurrence. A bid was solicited, proposed deliverables were reviewed for each bid and a subsequent procurement was made. City Light would develop its own back- end processing for the interchange application, which was scheduled for a nine-month pilot implementation.

However, the intricacies of relating the two data models and maximizing the efficiency of serving data from AM/FM to distribution analysis turned a projected nine-month task into eighteen months. Expertise in engineering and applications development were jointly necessary in the generation of a successful pilot. The rest of this paper will now focus on the relevant technical aspects of back-end batch processing, development and integration to the third-party solution.

SPATIAL DIVERSITY IN THE DATA MODELS

City Light's AM/FM database is of very high detail, planned as such for the eventual reuse of its data. The spatial conventions used by City Light in its database were geared toward its quarter- section map product; the same document was the principal source document used in AM/FM conversion. Distribution analysis could not be attempted until enough maps were automated to create several contiguous feeders in the AM/FM database.

The main deliverable in the AM/FM conversion was not the database, but the quarter-section map itself. It seems to make sense that what you get out of a conversion should match what you put into it, but this involved gearing the AM/FM data model toward symbology and map aesthetics and away from connectivity and simplified data structures. Two examples of this are the use of terminators and dead ends in City Light's model. Both features have symbols to represent their existence, but represent symbolized rather than spatial connectivity, and processing these features required adjusting the model to better suit spatial connectivity.

It is intuitive that a conductor should be modeled as a line, and that facilities be represented as nodes or points at the end of each line. However, how someone attempts to model equipment along a distribution circuit becomes more of preference and rationale rather than a generally accepted standard. For example, in City Light's AM/FM model, a switch is modeled at a node at one end of a line, to allow for symbology to be clearly identified on a quarter-section map, and to identify the facility on which the switch is installed. But some have modeled switches on a node itself, since it (dis)connects two conductors. Others, like the third-party vendor, modeled a closed switch to represent an arc, while an open switch means that no connecting arc is present.

The third-party vendor simplified its software by modeling all equipment (transformers, capacitors, protective devices, et al.) onto an arc. To the GIS systems integrator, that leads to two uncomfortable occurrences:

1. Increased back-end processing time.

Although, City Light's GIS arbitrarily links a line to each node, it takes time to do reassignments of node-modeled equipment to arcs. Further, the third-party software may not allow multiple equipment records per line/node, so the application now must split lines and create psuedo-lines and pseudo-nodes to comply with the third-party model, while trying to remain consistent with its own.

2. Less reliable distance accuracy.

The deviation from actual location of equipment at a facility can be as much as half the length of a conductor which links to that facility. City Light's average conductor length in 100 feet, and most of its feeders are about 20 miles long in wire, so the discrepancies over a feeder aren't too great a concern. But, if a conductor represented a mile, then there may be cause for concern about the reliability of analysis calculations.

INTEGRATING OTHER DATA SOURCES

City Light's AM/FM database supplies a significant amount of conductor attribute information which is exported, along with its spatial attributes, to the third-party application. However, there are other sources, automated and manual, which were required for integration.

1. Customer load.

Annual demand per customer meter is kept on City Light's Customer Information System (CIS), located on a mainframe platform. This information is related to the AM/FM database by a geocode, which will be discussed further in discussing data relationships. In order to obtain customer load, an extract of the mainframe's records must be written to a flat ASCII file which includes meter number, geocode and annual customer demand for each record. A UNIX process transfers the file to the AM/FM system, where an application loads the data for use in the back-end application.

2. Parcel addresses.

This information resides on the Seattle Engineering Department's AM/FM database and is maintained through the King County Assessor's Office. The address information is accessed and spatially referenced via the back-end application, which ties feeder conductors to the nearest parcel, as per the engineers' request and as the third-party application supports.

3. Equipment and conductor specifications.

This information never made it to the initial AM/FM database in total. Attributes such as R and X conductor values, or interrupt ratings on protective devices couldn't be entered with any degree of accuracy, due to different vendor procurements or types of equipment that made it difficult to give precise values. The engineers had to make an initial set of values to reference data in distribution analysis, and allow for potential variances. The information, kept in many manuals and printed media, was entered into a master set of tables in the AM/FM database, used in the back-end application and also exported to the third-party application as reference tables in the distribution analysis application.

ISSUES IN INTEGRATING DATA

There were five key issues which had to be considered in integrating data:

1. Accuracy.

City Light was able to put its faith in the integrity of its customer load and parcel address data rather easily, but the equipment and conductor specifications required subjective review and knowledge about the distribution system.

2. Connectivity.

Of greater importance is the AM/FM database itself, where connectivity over the entire database is critical to the analysis. Maintaining City Light's AM/FM database requires checking connectivity over quarter-section boundaries, which is critical for determining a feeder's extent.

3. Timeliness.

Parcel addresses or existing residential customer load generally changes little over a 12-month period of time. However, it is important to take into account new loads, particularly commercial or industrial loads, in measuring the reliability of a feeder. Thus, downloads of customer load extracts must occur with higher frequency. Worse still, if the information doesn't coincide with the AM/FM database because there's a lag between updating CIS and AM/FM due to operational procedures, valuable data will be unavailable for analysis.

4. Data relationships.

Using geocode to relate customer load to the AM/FM isn't exacting enough, since the AM/FM model supports the possibility of more than one feeder at a facility. CIS geocodes sometimes have to be subjectively altered or "fudged" to create a unique identifier, which compromises the geocode's integrity.

5. Software performance.

The third-party vendor's software assumes that groups of transformers will share a common impedance. However, City Light records show that each transformer has its own unique value, which appears too detailed for what the software allows. The engineers decided to group impedances based upon transformer type, kVA and secondary voltage output as a short-term solution for modeling primary transformer data.

THE DATA INTERCHANGE AND CROSSING OVER PLATFORMS

To serve AM/FM data to distribution analysis, a set of GIS applications was developed to do three specific things:

1. Extract selected spatial and attribute data to reduce the processing set.

2. Manipulate and merge spatial attribute data from all sources.

3. Format and generate output files for the interchange.

The lengthiest amount of time occurs in spatial manipulation and processing extensive relationships between attributes. The extraction will take the second longest amount of processing time on the average, but times will vary according to the length of a given feeder and number of associated data records to process.

Upon completion of the GIS applications, the files are immediately processed by a DOS-based interchange program, which is run within a PC emulator in the UNIX environment. The summarized files are converted from UNIX to DOS prior to processing. The resulting database is kept also in the UNIX environment, but is "mounted" as an emulated DOS drive using a software transport package. The data is thus accessible to the front-end distribution analysis program.

SETTING ENGINEERING SPECIFICATIONS IN THE MODEL

Getting concurrence on accurate software reference table data is of great importance. Trying to get information to complete the tables has involved sifting through many old manufacturer manuals and tables, making many assumptions for missing or debatable values, and calibrating data to ensure consistency. This takes time and requires a lot of research, causing a slowdown in implementation. The electrical engineers, as a group, are responsible for generating an accepted set of values, but have the flexibility in the third-party software to make their own further assumptions and adjustments to the distribution analysis model.

WHAT ABOUT QUALITY CONTROL?

Quality control is critical to the success of data integration. Attempting to reuse garbage data in integration only produces a landfill as the end result. Fortunately, City Light has an excellent quality control plan in map maintenance. The distribution analysis software has log files and reports which augment the quality control process very nicely.

The distribution analysis software also revealed some shortcomings to the existing maintenance process. Many errors resulted from poor initial conversion specifications of the quarter- section map. There were cases of loops detected in a feeder which were caused by data errors, such as missing dead end or superfluous conductor in the AM/FM database. Quality control procedures geared toward the quarter-section map were and still are being developed to include feeders which transverse many quarter-section maps, but are whole in the AM/FM database.

The third-party software detects loops by section rather than by phase, and loops were detected where phases split and came back together. However, the software handles by-phase analyses with no problem, and gives the engineer the option to put a logical rather than a real switch to permit calculations to work around looped areas.

The engineer has to perform a radial build when selecting a feeder. The number of sections in an average feeder is about 1,000; a feeder may have up to 2,000 or more sections. The radial build must process every section before analysis calculations can be performed. But that's a minuscule time for the engineer to wait, since the amount of time the engineer has to spend to retrieve quarter-section maps, determine the feeder by eye and calculate unbalanced phase/fault current analysis can be tremendously higher and less accurate in comparison. The engineer is more productive in less time, generating an immediate labor savings to City Light and greater employee satisfaction in simplifying and expediting the completion of the task.

The more important benchmark, which is harder to measure, is the long-term impact to customer service by creating a more efficient distribution system. The engineer can now evaluate alternatives using distribution analysis software based upon labor/material costs and electrical efficiency, and implement the best solution for Seattle City Light customers.

The distribution analysis software was piloted on 14 feeders in City Light's North Service area. A sample dataset was provided for the engineers to review; only table data issues remain in delivering the final product. There are many facets of implementation that City Light still has to explore: an overall implementation plan for the remaining 300-plus feeders, integration with protective device coordination software, generation of GIS-compatible files for analysis, additional procurement of software licenses, evaluation of UNIX-based software, and demand-driven processing as an alternative to lengthy processing times.

CONCLUSION

There are few real obstacles compared to the significant benefits in serving AM/FM data to distribution analysis. For any utility, regardless of size, a successful completion of this task depends upon the utility's investment in its existing support systems.

A utility considering a GIS could use reverse engineering to make its AM/FM database geared toward feeders rather than fixed areas of land. For those already with a GIS, knowing the third-party data model in advance can help in determining any required transformations from your AM/FM data model to the distribution analysis software's. Getting the specifications about your equipment can be a difficult task, but having these specifications as accurate as possible lends credence to your electrical distribution analysis.

Obtaining a cooperative effort between information technology and engineering staff is critical for the success of data integration, so a project plan with clearly defined roles and responsibilities is a must. Don't do everything at once, create a prototype and evaluate it thoroughly. And, if you don't have good quality control, you may be wasting a lot of time and money.

The feeder analysis project at Seattle City Light is a refinement of ideas based upon tools available to measure electrical efficiency, and the understanding of what kind of data is served to operate these tools. The hard work and effort that City Light experiences now is expected to pay for itself, in the form of decreased expenditures and increased customer satisfaction, as a result of improved electrical distribution services.

RELEVANT LINKS

The Seattle City Light home page

The Scott & Scott Systems (developers of the analysis software used by Seattle City Light) mail link

The Esri home page

Peter Di Turi
Seattle City Light
700 5th Avenue, Suite 2940
Seattle, WA 98104 USA
vox: (206) 684-3926 fax: (206) 684-3423
e-mail: peter.dituri@ci.seattle.wa.us