Graphical Feeder Configuration & Display (GFCD)

Graphical Feeder Configuration & Display (GFCD)

Matt Tani and Michael Berkley
Arizona Public Service Co.
P.O. Box 53999, M/S 8705
Phoenix, AZ 85072-3999

Why read this paper?
One truth about Geographic Information Systems (GIS), at least for electric utility companies, is that they take significant resources - time, money and labor - to implement. Depending on such factors as:

the size (square miles) and complexity (waterways, mountains, roads, bridges) of the geographic territory,
the number and density of physical assets (e.g., poles) to be captured, and
the number of attributes (e.g., height; material) for each asset,

the cost for a GIS implementation can easily vary from hundreds of thousands to hundreds of millions of dollars - and the time to implement from one to many years. Given this significant expenditure of a company's resources, it should be the goal of any GIS Project Manager to begin returning business value to the company - as soon as possible - as a return on the investment in GIS.

There are several strategies for producing business value from a GIS long before the entire project has been completed. Since business value comes from software applications that run against the GIS database, some viable strategies are:

Divide the geographic territory into several logical subgroups. Finish one subgroup and implement applications for it, before moving on to the next subgroup.
Divide the database into several logical subgroups. For example, one data subgroup might consist of just the data required to implement the highest priority application. Finish that data subgroup and implement the application for it, before moving on to the next subgroup -- for the next highest priority application.

This paper - in addition to describing a specific application that provides valuable support to Distribution Operations -- addresses a different strategy for early return on GIS investment. Since applications represent additional investment beyond the core GIS, another way to increase the return on the core GIS investment is to decrease the additional investment in the applications. This is leveraging; that is, the total cost of developing several applications will be appreciably less than the sum of the costs of developing each of the applications - assuming that each application had been developed completely independently of the others.

Context / introduction
The context for this paper is based upon project experience during the Construction and Maintenance Management System (CAMMS) Project, which was initiated in 1993. The initial goals for CAMMS were to develop and deploy a Work Management System, Geographic Information System and Trouble Call Management System [a.k.a., Outage Management] for the Customer Service Division of Arizona Public Service Co. (APS).

APS is a vertically integrated electric utility serving 800,000 customers in 43,000 square miles of Arizona. (Of course, if you know Arizona, it's also true that 39,000 square miles of APS' territory have no facilities -- at least, not yet.) About 600,000 customers are in the Phoenix Metropolitan area.

The Work Management System was in service in 1996, state wide.

APS selected ESRI's GIS product, in part, as it is common to most of the governmental entities (cities and county) in the greater Phoenix Metropolitan area.

The Trouble Call Management System (TCMS) was an application integrated with the GIS, since the vast majority of the TCMS database would be loaded by a software program (DILBERT) that extracted electrical connectivity data from the GIS database. Therefore, TCMS and GIS were developed in parallel. APS' service territory was divided into several logical subgroups: three Metro Phoenix regions and four State Regions. TCMS was in service for Metro Western in 1997 and for Metro Central and Metro Eastern in 1998. Work on TCMS and GIS for State Regions will not begin until 2001, because there is greater business value to be extracted from the Metro Phoenix GIS database than from the State Regions.

After TCMS, six additional applications were developed:

DILBERT
Graphical TCMS
FAAR
Graphical Job Status Tracking
GetMap
GFCD (Graphical Feeder Configuration & Display)

This paper will briefly describe the first five applications, with an emphasis on how each was leveraged off other applications, starting with DILBERT. The paper then describes the primary focus of the paper: GFCD functionality and architecture. Finally, we present some conclusions - or, lessons learned - from the development and implementation of applications that support Operations.

Dilbert
Our TCMS system is a robust mainframe system acquired from another utility. The electrical connectivity to drive TCMS is maintained in a GIS database. A sophisticated in-house extract program was developed, including the capability to assist with extensive GIS connectivity cleanup as part of the GIS data collection effort. (The name DILBERT did originate from our programmer's favorite comic strip, and only after that was an acronym determined!)

While text-based at first, because the initial emphasis was on performance and generating data files to load into TCMS, it was obvious that a graphical component was necessary to be able to effectively manage the process. Other additional needs were also identified. The state of the existing software included a reliance on reviewing text log files to hunt down problems in the data, would core dump when too many loops were encountered, and did not have provisions for handling multivalent node/feed through conditions that existed in various switch-gear.

Requirements for new application functionality focused on

The need to close all switches on a feeder first, instead of trying to reconcile opened and closed conditions.
Removing feeder trace logic from the existing editing application.
Rewriting the core feeder configuration application to create and save individual feeder configurations (a.k.a. trees).
Adding basic logic to retrieve and graphically display the entire feeder tree(s) and associated loop conditions.
Adding graphical functions to assist with locating and re-connecting "missing" transformers and other devices.

Thus Graphical DILBERT became a key application to successfully pass accurate and timely data to TCMS. Figure 1 is a display from Graphical DILBERT. Despite it being relatively primitive, it sure beat a text version. As we will discuss later, this eventually evolved into the feeder management piece of GFCD.

Figure 1: Display from Graphical DILBERT

Graphical TCMS
Much like DILBERT needed to be visual, TCMS also needed a graphical component. The mainframe architecture presented a lot of information about trouble calls, trouble tickets, and troublemen, and was accessible from the trucks through Mobile Data Terminals and a private radio network, but it was hard to see the big picture. Utilizing GIS Web-based technology and the ability, through in-house developed software, to send data to our distributed, relational data base from the mainframe, TCMS and GIS were brought back together in a graphical display of trouble tickets. The underlying ticket data is available, as is of course a drilldown of GIS land and facilities data. Figure 2 is a typical Graphical TCMS screen during a storm.

Figure 2: Display from Graphical TCMS

FAAR
Once a critical mass of GIS data was available, it was important to be able to view that GIS data (as well as related CAD drawings such as operations diagrams and cabinet details) from the trouble and locates trucks in the field - as well as on the APS Wide Area Network. We selected NMT's FAAR product, and go through a quarterly data preparation and CD (compact disk) distribution process. In addition to the actual usefulness of the data, this became a cultural intervention, in that it got people to think about digital rather than paper maps, in preparing for future GIS applications. For further information about FAAR, see (Audley, 1998).

Graphical job status tracking (GJST) / GETMAP
With the continuing explosive growth (30,000 new customers per year) in APS' service territory, an integrated GIS-based job design application -- where the job sketch can be entered once up front, go through status changes from pending to as-built, with minimal GIS Operator intervention after the fact -- is the key to eliminating an extensive GIS backlog of new / revised data entry. While this would make the GIS data current and more useable for a GFCD and other applications, it has been an elusive goal, as the technology has been slow to evolve. Internally, CAD is ingrained for job sketch purposes. Therefore, we embarked on an Interim Job Design effort, trying to both bring productivity to the designer, as well as introducing GIS data into the CAD environment. The result has been two applications.

The first, GJST, takes data from our work management system and displays it geographically, based on (land) quarter section information that was entered into the work management system. This was done in a short amount of time, as the landbase and facilities data, as well as the desktop GIS functionality and look-and-feel, came directly from the GFCD prototype, which was programmed using the same technology. In fact, enhancements to the GJST user interface, as a result of working with a Customer Service team, will also benefit GFCD.

The second application, GetMap, actually has its starting point inside of GJST, where a designer would select ("rubber-band") the area they will be working in. The coordinates are captured, and behind the scene, all applicable GIS data is retrieved and appropriately layered. Then an AutoCAD Map session is able to work with that data and either continue the sketch, or save it for use in AutoCAD LT. This should make it easier to eventually post back into the GIS. By implementing more CAD design standards with this in mind, we should be able to speed this process even more. In the meantime, we expect to store the sketches in CAD form in the GIS or our Document Management System, so that GIS and pending CAD data are jointly viewable from both CAD and GIS. Again, these are interim steps until GIS-based job design is implementable at APS.

GFCD
This brings us to Graphical Feeder Configuration & Display (GFCD), which we previously learned has its origins with the DILBERT application and has since been a "clone and go" base for the rapid development of GJST (and we're sure, additional future applications). As one would expect, GFCD has extensive GIS display and navigation capabilities, as well as business functionality. We have divided this into four categories, as follows:

Basic Features/Rules, including user defined/configured zoom level, related layer visibility and symbol sizes, multi-map/function window environment, and sizeable map windows.
Map Manager Functions, including opening a child/zoomed-in map window of an opened map, set active map layer, and print map.
Map Navigation Functions, including pan, zoom, magnifying glass and reference map.
Business Functions, including identify and locate feature, locate address, display detailed switching cabinet, flash conductor, push pin/markup functions and feeder functions.

The latter two business functions deserve further discussion. Guests who have been in an Operations Center have been warned to not lean against the wallmaps because of all the colored pins that represent real-time conditions. GFCD has incorporated pushpin display and editing for conditions such as abnormal opens and closes, feeder indicators, flag conditions and life support. Figure 3 is a GFCD display that shows the pushpins.

Figure 3: Display from GFCD - push pins

Feeder configuration functions are at the heart of GFCD. Functionality includes capturing feeder trees, selecting and framing feeders, normal and closed switch changes, feeder tracing, and scenario planning ("what if" analysis). Figure 4 is a display showing multiple feeders. While it loses its effectiveness in this black and white version, you can imagine the value of the real, multi-color display.

Figure 4: Display from GFCD - multiple feeders

For further information of the functionality of GFCD, see (Olszewski, 1999) and (Olszewski and Robinson, 1999).

The architecture of GFCD has also evolved over time. The original DILBERT feeder display and analysis component was interactive GUI based on HUSH C++ wrappers for TCL/TK on Unix Xwindows platform. Technical details on the interface and feeder analysis tool can be found in (Hatmaker, 1998). This has been replaced by an NT C++ feeder navigation and analysis component, with an NT, ActiveX, Visual C++ GUI environment for invoking feeder building, analysis and display commands. There is a UNIX feeder server daemon with socket accepting connections for feeder tracing commands. Through a COM interface to the C++ ActiveX control, the desktop GFCD (Visual Basic with geographic objects) application requests the feeder functions. Data currently comes from a combination of the spatial database and related attribute tables. This will change as we migrate our GIS environment to the objectoriented, GeoDatabase technology.

Conclusions/lessons learned
There is a big difference between creating a useful tool to provide additional Operations functionality and actually planning to replace the paper wallmaps with an electronic version. There are two major things GFCD must do in order to work as a replacement for the wallmaps.

Model the opening and closing of switches, reconfigure the affected feeders and update that information in TCMS.
Visually represent the APS Metro electric model well enough to operate by.

Other major issues include the display technology (currently we have a dual monitor display), the need for 24x7 up time, and the accuracy/currency of the data -- given growth-driven backlog, and "temporary" emergency changes that aren't reflected in the model. Technology, resources and cultural issues need to be resolved for this vision to become a reality.

The "people" issue cannot be stressed enough. The paper wall maps have existed for a long, long time. Despite their limitations from a space and amount of available information standpoint, Operators are very familiar with them and in times of crisis, maps provide a comfort level that technology would envy. The upcoming parallel pilot we will be doing will help identify the extent of this issue (as well as highlight system/data deficiencies). The other people/culture issue to watch will be the willingness of the Distribution workforce, already with a full (overflowing?) plate, to take ownership of data integrity. Only by keeping the underlying GIS data current and accurate will GFCD and the other applications be of true value to the business.

Clearly, we still have a long way to go. However, we have also come a long way. The ability to rapidly build GIS applications (using GIS and rapidly in the same sentence seems strange!) and get into prototype/pilot mode by leveraging existing applications and data have already provided value to the business and positioned APS to significantly improve service to the customer.

References

Audley, J., April 1998, A Room With a Viewer, AM/FM International Conference XXI Proceedings, pages 67-73.
Hatmaker, Michael L., July, 1998, Rapid Application Deployment in the Open Development Environment, ESRI User Conference
Olszewski, M., July, 1999, Significantly Decreasing Application Costs & Managing Scope - The Graphical Feeder Case Study, ESRI User Conference
Olszewski, M and Robinson, J., October, 1999, Graphical Feeder Configuration & Display, ESRI Electric and Gas User Group