Paper presented at \'95 ESRI NW Conference and \'96 Scott & Scott Conference (no PPT available)

1. Peter Di Turi, Seattle City Light
SERVING GIS DATA TO ELECTRICAL
DISTRIBUTION ANALYSIS
TABLE OF CONTENTS
Abstract
Introduction
Needs of the Electrical Engineer
The Rationale of the Systems Analyst
Critical Factors in Determining the Best Product
Spatial Diversity in the Data Models
Integrating Other Data Sources
Issues In Integrating Data
The Data Interchange And Crossing Over Platforms
Setting Engineering Specifications In The Model
What About Quality Control?
Conclusion
Relevant Links and Signature
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.

2. 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:

3. 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

4. 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

5. 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:

6. 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

7. 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.

8. 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

9. 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

10. 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