Graphical Feeder Configuration & Display (GFCD)
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
