Introduction

In recent years, power utilities have had major concerns about the issue of
managing outages — especially unplanned ones caused by acts of nature —
and major equipment failures. In response to this concern, there have been a
variety of products relating to outage management systems (OMS) and packages
offered by providers.

Industry marketing studies continue to report that OMS — as well as distribution
management systems (DMS) will continue to grow in importance, as power delivery
system reliability becomes a competitive factor and as reliability-performance
measures are increasingly scrutinized by public utility commissions. These findings
have been reported in North American and international electric power SCADA,
DMS and distribution automation segments:

“One of the issues facing potential new users of outage management software
is the ‘stand-alone’ versus the ‘integrated’ nature of the application. Unlike
many other utility applications, outage management is totally reliant on external
linkages to customer information system, SCADA/DMS systems and service dispatching-crew
scheduling operations. The need for OMS suppliers to combine elements of the
real-time SCADA system with transaction-oriented and event-driven information
systems is critical. The need for OMS to be geographically driven is yet another
consideration.”¹

A successful OMS implementation needs strong interdepartmental coordination.
No single business unit is responsible for OMS. A coordinated inter-department
project team seems to be the best way to undertake these enterprise-type programs
and projects.
In the next sections of this paper, the enterprise application integration (EAI)
technology adapted in the City Public Service of San Antonio (CPS) is described
— after its enterprise project is presented — in addition to a brief
background for enterprise solutions that emphasize technologies and standards.
Then, different business processes for outages from different sources are described
and the OMS role in these processes is identified. Finally the available tools
to the System Operator (SO) are listed, and the improvements in system performance
are highlighted.

Re-Engineering CPS’ Enterprise Systems

CPS has been engaged in a very ambitious effort to re-engineer its entire enterprise
systems, from billing systems to OMS. It is accomplishing this enormous effort
by acquiring new applications such as mySAP Utilities (SAP AG), which includes
Financials, Materials Management, Customer Care, and Work Management components.
In addition, a work management information system (Logica) and a distribution
management system (Siemens) were selected. Logica’s WMIS is closely tied to
the SAP product and the Siemens DMS is closely tied to the SCADA system, which
is also from Siemens.

CPS has also contracted for upgrades to existing legacy applications for GIS
(Bentley Systems) and MDS (MDSI Inc.). Many homegrown legacy applications have
been targeted for integration as well. The integrated systems are scheduled
to be operational by the first quarter of 2002.

Background: Technologies and Standards

Throughout the industry, enterprise integration has taken on a whole new importance.
In a fast moving deregulated environment, it is important for companies to be
responsive to changing market conditions that occur due to regulation changes,
new business opportunities and market movements that can’t be anticipated today.
This technology separates the various layers and makes them independent of each
other, providing the ability to change systems much faster and more effectively
with fewer problems.

Several projects started in the mid-1990s began to address the need for a standardized
method to exchange information, including the Electric Power Research Institute’s
Control Center Application Programming Interface project²,
a National Rural Electrical Cooperative Association Inventory Management system,
the EPRI Customer Interface project known as CS2000, and the Kansas City Power
and Light control center integration project. Fundamentally, these projects
have focused on the same basic issue of integrating process information with
corporate information using standardized and extendible methodologies.

While these U.S. projects have progressed, the need for a standard integration
technique has also been acknowledged within international standards bodies such
as the International Electrotechnical Committee, Technical Committee 57, and
the Object Management Group. In particular, the Utility Integration Bus is being
designed for submission to the Control Center Application Program Interface
(CCAPI) working group, International Electrotechnical Commission (IEC), and
Object Management Group (OMG) for consideration.^3-7

Why EAI?

As previously mentioned, there are multiple departments/divisions in the power
utility dealing with the outages. During an outage lifecycle, these entities
are performing various tasks. Some of them are:
1. Call-taker or Customer Service Representative enters the order
2. Order processing in the Customer Information System
3. SO groups and studies the order, generates the switching procedures and identifies
the required repair works
4. Dispatcher receives the work orders and assign them to field crew
5. Field crew obtains clearance, drives to the site, performs the required work
and then reports the status to the dispatcher/supervisor
6. Dispatcher/supervisor sorts the orders and reports them to CIS
7. CSR calls back to the customer

Power utilities deploy different automation systems to cover some of these steps.
However, the daily operations need these islands of automation coupled. Since
there is no single vendor offering a global solution for all utility needs,
the need for a flexible and easy-to-use interface system among these islands
of automation is inevitable.

The heart of this integration strategy is EAI. By definition, EAI stands for
“bringing together multiple applications to automate enterprise level business
processes.” In other words, it bridges disparate applications for comprehensive
enterprise-wide solutions. EAI is not a database, a middleware, an application
server, nor a workflow application. However, all of these functions are involved
in an EAI solution. The immediate advantages of implementing EAI technology
can be listed as:

1. Avoid multiple interfaces between an application and the rest of them by
implementing only one interface per application;
2. De-couple application upgrade (or possibly replacement) from the enterprise
upgrade;
3. Isolate applications from the data structure and format of other applications.
These can translate into reduced maintenance cost and efforts enterprise-wide
and provide greater flexibility to add new applications or replace the existing
ones, even on gradual basis.

EAI Solution for CPS Enterprise

In the first stage of the CPS enterprise project, CPS carefully identified
business processes and system requirements by working with consultants and vendors
for the re-engineering effort referred to as Business Information System. In
parallel, Siemens conducted a study for the integration of legacy applications
involved in outages, identifying middleware products as the most effective way
of tying all of the new and existing applications at CPS. Figure 1 presents
the overall architecture adopted for CPS enterprise project as the results of
these efforts.

Figure 1 – The CPS EAI Environment

A typical EAI environment consists of many legacy and new applications, component
adapters and enterprise servers. An enterprise server hosts a common message
bus. This server may also include data translation and data transformation software.
Data translation and transformation software makes applications independent
from each other. In the CPS project, MQSeries server is used as the common bus.
MQSeries Integrator is the data translation and transformation software.

A component adapter is a piece of software that bridges the gap between legacy
application and an MQSeries Server. Typically, a component adapter runs on the
application server, and may use the legacy application data exchange techniques
to interface with the application. Adapters use MQSeries APIs to exchange the
data with MQSeries Server. MQSeries client APIs is used in this project.

XML is used as the data format between the component adapters. XML is chosen
because it’s universally accepted and easy to understand. It’s also easy for
any data translation software to map one XML structure to another. For all outgoing
data, component adapters convert the legacy application data to XML format.
Reverse process is done for the incoming data. MQSeries Integrator is used for
any XML transformation if needed.
The use of proper middleware tools and XML helps an EAI environment to achieve
a seamless integration of any heterogeneous applications.

Outage Related Business Processes

Outage related business processes are divided into the three major categories:
trouble call, SCADA-recognized outages, and planned outages. These categories
are described in the following text.

Trouble Call Business Process

Figure 2 presents the business process for the outages recognized by trouble
calls.

A customer calls through IVR or CSR to reach the customer information system.
After filtering the calls for repeated calls or known outages (if any), a call
notification or trouble ticket (TT) is issued and sent to OMS. OMS either groups
the new TT with existing outage records by using DMS applications or creates
a new order request (OR).

Provisions are provided to the SO to receive the alarm and associate it to the
OR and the circuit diagram (including the geographic location). OMS provides
the probable cause of outage by identifying the upstream disconnecting device(s)
that might be opened/tripped.

Figure 2 – Business Process for Trouble Calls

The fully integrated OMS/SCADA/DMS system provides a user friendly and flexible
environment to the SO to create switching procedures that isolate the faulty
segment and restore the power. Also, simulation tools are available to study
the effects of generated switching procedures on the network.

The SO creates the job requests necessary to rectify the outage (including job
types/codes). Each job request, with the coordination of the WMS through Plant
Maintenance, is translated to a work order which is sent to a mobile data system.
The dispatcher schedules the work and assigns field crew to perform the job
requested by the SO.

Crew ID, work status, and estimated time to repair are part of the data provided
by MDS to OMS. The SO monitors the status of each work order, creates new job
requests if necessary, and closes the OR when satisfied. OMS automatically sends
messages to CIS whenever there is a change in the energization status of parts
of the network, estimated time to repair, or OR status. CIS is capable of initiating
callbacks (if necessary/required) based on the information provided by OMS.

Business Process for SCADA-Recognized Outages

The trouble call business process is designed in such a way that it can cover
SCADA recognized outages as well. The only difference is in the creation of
the OR. After SCADA identified de-energized segment(s) in the network, OMS creates
an OR and sends the message to CIS identifying the de-energized transformers.
Afterwards receiving new trouble calls are treated as in the previous business
process.

Business Process for Planned Outage

The planned outage business process is divided in two phases: planning, and
execution. In the planning phase, the WMS identifies the list of transformers
to be maintained for specific period and sends the message to OMS via plant
maintenance. The SO studies the list by using DMS applications and, if necessary,
modify the list and generate the switching procedures to perform the maintenance
work. OMS sends the message back tothe plant manager with the modifications.
Affected customers will be notified by letters or called sometime prior to the
execution phase.
In the execution phase, the switching procedure(s) will be performed by the
SO through SCADA, or field crew similar to the trouble call business process.
The rest of the activities will be similar to the trouble call business process.

Achievements

The main features provided to the SO by these business processes in general,
and OMS capabilities in particular can be summarized as:
1. Group trouble calls and identify the problem area
2. Monitor all activities related to the outage during its lifecycle
3. Generate switching procedures and study their effects
4. Perform part of switching procedures via SCADA (if possible)
5. Generate job requests necessary for isolation, repair, or restoration
6. Close the OR
7. Calculate and update the reliability indices
8. Generate reports for current outages or closed ones in different levels of
the network in different time frames

The integrated OMS/SCADA/DMS performs a number of tasks automatically after
receiving the trouble calls (or SCADA events): grouping the call, associating
the call to an existing OR or creating a new one, and identifying the de-energized
sections and probable problem area.

Also, OMS provides a user-friendly environment for the SO to create the switching
procedures and job requests and send them with a minimal number of steps. This
provides the SO the opportunity to monitor the overall outage situation and
all activities around it with minimal intervention/operation. Consequently,
the SO will be able to handle multiple OR’s simultaneously during crisis events,
such as major storms. OMS provides a sorting mechanism to assist the SO in concentrating
on OR’s with specific criteria (e.g., the number of critical customers affected,
lost power, etc.).

Conclusion

Making use of the latest enterprise tools such as MQ Series Integrator with
XML, Siemens is using industry standards (or de-facto standards) to create an
efficient, timely, full integration with the CPS enterprise. This strategy helps
to reduce development effort and costs with fewer errors. Placing integration
processing in a central location also reduces future maintenance costs. This
strategy permits future changes to the system that can be handled in the middleware
rather than rewriting point-to-point interfaces. The net result for the SO is
to work with an integrated system that provides a full picture of all tasks
relevant to outages with minimal work.

Footnotes

1 “Automation Perspectives,” Chuck Newton, Transmission & Distribution
World, May 2001, p16.
2 EPRI Control center Application Program Interfaces Task Force, kemeconsulting.com/epriapi/downloads/
3 “Open Applications Group Common Middleware API Specification, Version 1.0,”
August 1999.
4 “IEC 61968-1 Interface Architecture and General Requirements”
5 “IEC 61970 Energy Management System Application Program Interface,” September,
1999.
6 “Utility Integration Bus (UIB) White Paper, Version 1.2,” November 1998.
7 “Introducing The First Part of A new Standard For System Interfaces For Distribution
Management Systems (DMS),” E. Lambert, W.D. Wilson, Paper 3-23, 15th Int. Conf.
On Electricity Distribution (CIRED), June 1998.