Customer Information System (CIS) and
Distribution Transformer
Inventory System (DTIS)
The CIS and DTIS interfaces, in their earliest form, were created during the pilot application.
These interfaces are a simple flat file extract of data from two legacy information systems which
are on VSAM and DB2, respectively. The flat file is loaded into Oracle; then views and triggers
allow the information to be viewed in AM/FM with its respective graphical features. The major
advantage of this interface style is that AM/FM can utilize the information captured in the other
systems, without maintaining the data in both systems. The information is used for navigating to
the customer or transformer, tracing circuitry to obtain loads from the customer information,
mapping automatically the medical or critical customers, and displaying information about the
customer and transformer.
Customer Trouble Call System (CTCS)
The AM/FM data is also passed to the DB2 CTCS system. This interface currently uploads the
customer and its first protective device relationship from AM/FM to CTCS. Thus, whenever
new customers are added to the system, the information only has to be entered into AM/FM and
is automatically updated to CTCS. In the future stages of the integration, the entire electrical
path will be passed from AM/FM to CTCS, and CTCS will pass live outage information to
AM/FM, which will be displayed graphically for the dispatchers.
Engineering Analysis
The AM/FM data is passed to an Engineering Analysis system via an Oracle extract. The circuit
details, which are maintained in AM/FM, can then be utilized for analysis and design in the
engineering analysis system.
Customer Request Work Scheduling (CREWS)
The AM/FM interface with the CREWS system is by far the most complicated. New work is
passed to the CREWS system and these new jobs appear on AM/FM to be designed. The job is
designed in AM/FM graphically; at the same time, compatible construction units from CREWS
are picked to assist with the AM/FM attribute population, cost and labor estimates, and material
ordering. Once the design is completed in AM/FM, it advances through various stages in
CREWS (estimating, various approvals, scheduling, material ordering, closing). The work
sketch from the AM/FM design is used in the field, the as-builts are posted to the job, and then
the job is automatically made a part of AM/FM production database.
Rapid Application Development
There are numerous definitions and techniques for rapid application development (RAD). To
some people, rapid development consists of the application of a single pet tool or method. To
the hacker, rapid development is coding for 26 hours at a stretch. To the information engineer, it
is a combination of CASE tools, intensive user involvement, and tight time boxes. To the
vertical market programmer, it is rapid prototyping using the latest version of Visual Basic or
Delphi. To the manager desperate to shorten a schedule, it is whatever practice was highlighted
in the most recent issue of Business Week (McConnell, 1996).
The bottom line is that software development needs to be done much faster than in the past, and
a variety of ways are used to do this. This point is particularly true in the AM/FM/GIS industry
because of the constantly improving technology. The utility industry must also change its
approaches because of the increasing competitive environment. It is no longer sensible to spend
5-10 years gathering requirements, designing, coding, and testing a system before it is released to
the end user. By that time, the technology that has been implemented is out-dated, the systems
to which it has been integrated have changed, or the business processes have changed and then a
new project must start over again. The following discussion will highlight the two approaches
that First Energy has used to develop system interfaces, the benefits gained by bringing the
project to market in a shorter time, and the disadvantages of these approaches.
Staged delivery
Definition
The staged-delivery model involves giving software to the end-user in successively refined
stages; the software is not delivered at the end of the project in one fell swoop (McConnell,
1996). This model involves the development of the initial software concept, requirements
analysis, and architectural design once at the onset of the project. Then the detailed design,
coding, debugging, testing, and delivery phases are delivered to the end-user in stages.
A version of this model was used to develop the FirstEnergy interfaces between the AM/FM
system and the CIS, DTIS, CTCS and Engineering Analysis Systems. The next section will give
an example of how this model was used to develop the CIS interface, the benefits of this type of
implementation, and its drawbacks. See Figure 2.
