An Outage Restoration Management System for Power Distribution Networks
Authors: Saeed Monemi, Ph.D.
Michael S. Moore, Ph.D.
Jianfeng Wang
Abstract
This paper will present a fault management system
being developed for power distribution networks, called the Outage Restoration
Management System (ORMS). The ORMS
employs an advanced diagnostics reasoning algorithm to determine the location
of faulty components during electrical outages. The diagnostics results are presented to the user in graphical
form to aid in planning repair actions. The ORMS algorithm is implemented as an
OLE/DCOM component, and has been integrated with several standard Commercial
Off The Shelf (COTS) systems commonly used in electrical utilities, including
an Esri Geographic Information System (GIS), an Interactive Voice Response
system (IVR / trouble call system), a System Control And Data Acquisition
system (SCADA), and a Customer Information System (CIS). We will show how this fault management
system 1) provides accurate and relevant diagnostics results, and 2) can easily
be integrated with other system components used in utilities.
Introduction
Diagnosis of a system is the task of identifying failed parts that are responsible for the discrepancies between the observed and correct behavior of the system. The reason to perform diagnosis is to find faulty components and provide support for system repair that the system can be restored to its normal operation. By applying knowledge about the general electrical network domain, the design information and properties of the devices, and past experience with these electrical networks, we can greatly reduce the complexity of the diagnosis task. Specifically, because of the structure of electrical networks, we can formulate the diagnosis algorithm as a hierarchical diagnosis of its sub-networks. The most difficult problem in diagnosis of large networks, scaling in the fault hypothesis space, can be handled by using an advanced graph-based mathematical abstraction called Binary Decision Diagrams (BDD) to reduce the search space. The following will provide a very brief description of a diagnosis algorithm we have developed that utilizes these techniques, and the corresponding implementation of this algorithm in the ORMS.
The Utility Environment
Utilities tend to have similar concerns with respect to information technology. Most utilities depend upon computer systems for managing their maps using some kind of GIS systems. Many have SCADA systems for remotely managing sub-stations and main switches. Most have IVR systems that automatically log the calls of customers reporting outages. The difficulties come when these systems have to work together, for example in the control room during an outage. A dispatcher watches the trouble call and SCADA systems, and coordinates the repair actions of the crews. The dispatcher is actually performing much of the work of integrating and fusing information together and, and manually synthesizes the solutions. It is possible to support these tasks with systems designed to perform the integration and fusion automatically. The solution synthesis can also be supported with appropriate tools. However, some small utilities do not have the resources available to develop such systems internally. Hiring consultants to develop custom solutions to solve these problems is extremely expensive. Not only is initial cost high, but also the cost of maintaining, upgrading, and evolving custom software is out of the reach of many small utilities. The result is that many of the processes, such as fault diagnosis, repair coordination, and resource allocation are done manually by experienced staff.
The problems of improving the fault diagnosis
capabilities, and in general integrating the available data systems together in
support of important decision making processes need to be solved in a
cost-effective and general way.
Utilities need be able to use and maintain these systems more
independently and inexpensively, especially in light of the current more
competitive environment.
We have developed a system,
called the Integrated Distribution Management System (IDMS), which is designed
to provide diagnostics support, and eventually other decision support
tools. This system addresses two of the
major concerns being faced by utilities, effective diagnostics, and
maintainable and evolvable integration.
Integrated
Distribution Management System
The IDMS provides both decision support tools and
the integration required to make them work in a utility environment. One underlying requirement for the design
was that the components and the integration code itself should be developed
with standard, published interfaces.
This approach should produce so-called open systems, which are
much less expensive to integrate, maintain, and evolve. Toward this goal, and to avoid re-inventing
the wheel, we were obliged to use as many COTS components as possible, and
concentrate on making the integration code independent of which components were
chosen, so that a utility would not become locked into using a particular
vendor’s solutions because of large integration costs.
The Overall System Architecture of the IDMS is made
up of four major sub-systems, 1) Data Systems, 2) GIS & FM
Systems, 3) Decision Support Systems, and 4) the Integration
Framework (IF). The following
sections will describe each component in detail. Refer to Figure 1.
1. Data Systems
The Data Systems provide
additional information about the network configuration, the customers, and the
health and fault status of the circuit.
The status information can be thought of as instrumentation of the circuit. For example, a SCADA system will provide
remote monitoring of currents, voltages, and switch positions of various remote
circuit components (direct measurements).
An IVR (trouble call) system will field customer phone calls and log
service outages (observations of customers).
A customer information database contains address and contact information
of customers, service location, and billing information (additional information
about the network and customers) that can be used in matching phone numbers of
trouble calls to locations in the electrical network. Refer to Figure 2.
Figure 2. A typical data systems for an electric
utility
2. GIS & FM Systems
These systems are usually present in utilities, in varying forms. A GIS system contains a model of the circuit topology, i.e. where components are, how they are inter-connected, and some service, or customer information. Since a major goal was to promote open systems concepts, the IDMS integration framework was designed to work with GIS systems which store the circuit topology information in a standard format, such as a commercially available database (SQL Server, Oracle, Sybase, etc), or in files with either a published format or with standard access drivers available (OLEDB, ODBC, etc). Facility Management (FM) systems are used to design, maintain, control, and generally manage the network. Examples of these are work order management systems, which are used to update the GIS model as the circuit is extended and maintained, and load engineering analysis packages. Refer to Figure 3.
Figure 3. A
typical GIS and FM systems for an electric utility
3. The IDMS Integration Framework
The IDMS employs Model
Integrated Computing (MIC) technology, namely the Mutigraph Architecture (MGA)
to create a flexible, reconfiguration, and extensible framework with which the
data from the GIS system and the Data Sources are integrated with the
ORMS. The Integration Framework can
also provide integration for other decision support tools.
Model Integrated
Computing
Model-Integrated Computing (MIC) is an approach to developing systems that directly addresses the problems of system integration and evolution by providing rich, domain-specific modeling environments including model analysis and model-based program synthesis tools. This technology is used to create and evolve integrated, multiple-aspect models using concepts, relations, and model composition principles routinely used in the specific field, to facilitate systems/software engineering analysis of the models, and to automatically synthesize applications from the models.
The MultiGraph
Architecture
The MultiGraph Architecture (MGA) is a MIC technology that has evolved during the last decade as a software framework and infrastructure for system integration and synthesis. MGA includes generic, customizable tools for constructing domain specific modeling, analysis, and program synthesis environments. The technology has matured in major applications developed for the government and private industry, including fault detection, isolation and recovery systems for aerospace applications, on-line problem solving environments for the chemical manufacturing industry, high-performance parallel instrumentation systems, embedded simulators for turbine and rocket engine testing, and manufacturing execution systems.
The GME Model
Editor
The MGA includes a configuration Graphical Modeling Environment (GME) that includes facilities for model building and transformation [12]. For the Integration Framework, we configured the GME to build models in a language we designed called IDMS.
The
IDMS Modeling Paradigm
The role of the IDMS models in the Integration
Framework is to act as a repository for meta-information describing all
available data source in the system, how they can be related, and how these
meta-relations will be used by the data consumers in the system, namely the
ORMS. For this reason, the IDMS
modeling paradigm, or language, contains “Data Source” models, which describe
all available data sources, their tables, fields, and keys, etc. Note that one assumption the Integration
Framework makes about the data sources it can communicate with is that they are
relational. In addition to data source
models, the IDMS paradigm contains “IDMS Configuration Models”, which contain
“Query Models”. The query models
describe how the various data from the data sources can be composed to meet
requests for data.
To ease the task of building the IDMS data source
models, we implemented a special model interpreter that can automatically
import the database schema information from any OLEDB compliant database (e.g.
Oracle, SQLServer, Sybase, Access, formatted text files, and most commercial
databases). This interpreter imports
the tables, fields, and foreign key information. Thus, the models themselves are actually almost completely
automatically generated.
The
IDMS Integration Engine
The IDMS Integration Engine is the component which
actually perform the requests for data, and thus provides integration between ORMS
and other information system components
For instance, the ORMS client must obtain trouble
calls from the Integration Framework to update the ORMS and diagnose an
outage. The ORMS client calls an
OLE/DCOM interface function of the Integration Engine with the identifier
“GetTroubleCalls”, which returns the data as an OLEDB record set object. The actual query performed by the
Integration Engine will join the outages table from the IVR system,
which includes phone numbers, with the customers table from the CIS,
which contains transformer numbers, with the transformers table in the
GIS database, which contains transformer identifiers and map locations. The ORMS client uses the information
returned by the call to the Integration Framework to identify the customer
trouble calls in the circuit. However,
the ORMS client code is absolutely independent of the data location, source, or
format.
Model
Transformation
The IDMS models are transformed into the IDMS
configuration database, which includes configuration tables read in by the
Integration Engine, and other system components. When data sources change (system components are removed,
replaced, or added, or data formats change) the models can be updated and the
integration configuration is “resynthesized” from the models automatically.
Refer to Figure 4.
Figure 4. The Integration Framework designed for an electric utility
4. Outage
Restoration Management Systems (ORMS)
An outage is a sustained connectivity loss in the distribution network circuit. Outages may result from any of the following conditions:
§
Storm,
lightning, high wind, birds, etc.
§
An
equipment failure
§
The
normal fault clearing action of a breaker or other protective device
§
The
operation of a sectionalizer device
§
Planned
outage
§
The
deliberate cutting of a line by a crew in order to manually isolate a fault
The ORMS is the component of the
IDMS which performs the analysis of the current outage. This is illustrated in Figure
5. It uses the GIS data as a model of the network topology. It obtains information about the health and
status of the network from other systems, such as incoming trouble calls from
an IVR system, voltage and current reading from a SCADA system. The results of the analysis are hypothesis
as to what faults in the distribution network equipment are causing the
outages. These faults are referenced
back to specific components in the GIS maps, and shown to the user in a
graphical user interface. The outage
information can and also be fed into decision support tools to help the
operators analyze various courses of action toward repair in a timely fashion.
Figure
5. The Decision Support Systems for an
electric utility
Diagnostics
In decision support tool the most needed and relevant
ingredients is a diagnostic system that would provide queues to the operators
about where the faulted components are in the electrical network distribution
during outages.
The requirements of a diagnostics algorithm to be
used for utilities are:
1)
it
must function well using reasonable resources (a standard PC or workstation),
2)
it
should have the ability to detect multiple non-interacting faults within a
sub-station circuit within reasonable response time (10s of seconds),
3)
it
should be able to take advantage of any instrumentation available (SCADA,
trouble calls, etc),
4)
it
should provide accurate results (few false alarms), and,
5)
it
should be able to pinpoint faults at any level in the network (sub-station,
feeder, section, lateral, tap) in any type of component (switch, line,
transformer, fuse).
We found that most algorithms currently in use were
lacking in the ability to provide accurate and relevant results. One algorithm we evaluated that was in use
in a small utility was a tracing algorithm designed to identify a single fault
per sub-station circuit, and was not able to take advantage of SCADA
measurements, which can prove extremely useful in utility network diagnosis, as
will be shown. No diagnostic systems we
found would perform the functionality required with the resources available.
The IDMS was designed around the need for improved
diagnostics capabilities, and the flexible, extensible integration to support
it. We have developed a new diagnostics algorithm
tailored specifically for diagnosing power distribution networks. It encompasses both a wealth of domain
knowledge obtained through years of work within the power distribution industry
and a scientific approach gained from extensive study of the general
diagnostics domain. The following will
explain why the diagnosis of faults in electrical distribution networks poses a
unique problem, and then will present the ORMS algorithm.
The Structure of Electrical
Distribution Networks
A typical Electrical
Distribution Networks (EDN) consists of various types of electrical components,
interconnected by electrical lines. Power is input to the networks from high
voltage transmission lines at sub-stations. The power is eventually consumed, at a lower
voltage, by customers, or loads. When
viewed in this way, an electrical distribution network forms a tree topology,
with the sub-stations at the roots of the tree, and the loads at the
leaves. This is illustrated in Figure 6.
Furthermore, the networks
have a hierarchical structure, as will be explained in the following. Sub-stations have several switches/circuit breakers on their
outputs, which distribute power through feeder
lines. Feeders, or trunk lines, lead
away from the sub-stations, and distribute power into the different service
areas. Along the feeder line, there are
switches that can be used to isolate parts of the circuit, but otherwise the
feeders travel all the way through the service area. In some cases, the ends of feeder lines meet at switches that are
nominally configured to be open, but which can be closed during outages to
reconfigure the feeder circuits and temporarily restore power to areas during
outages. This practice is commonly
known as back feeding. Throughout the feeder’s length are places
where section lines branch off,
normally connected by a switch.
Attached to the section lines are lateral
lines, usually with a protection device such as a fuse at the
junction. Attached to the laterals are
transformers, which also include protection devices, and distribute power to
customers through taps, or service lines.The hierarchical tree
structure and the common use of protection devices are each of great importance
to the design of a diagnostics algorithm.
These properties allow the assumptions that 1) there will be no cycles
in the fault dependency graph, and 2) faults will be localized (will not
cascade). This enables us to reduce the
task of diagnosing a fault to locating the area in which the fault originated,
since we are assuming faults do not cascade due to the presence of correctly
placed and configured protection devices.
As an example, assume
several of the customers on a lateral line report an outage. A quick check determines that there have
been no outage calls from any customers on the adjacent lateral lines on the
same section line, so these lines are assumed to have power. This information leads to an assumption that
something near the root of the first lateral line has failed. Experience says that probably the fuse is
open, since it is the protection device nearest that location. Since we assume that faults do not cascade,
the actual cause of the fuse opening
was an event somewhere between the fuse and the next protection device
downstream (the first transformer, in this case), probably a shorted lateral
line. Thus, the event that caused the
fuse to open necessarily occurred somewhere near the fuse. Therefore, identifying that the fuse is open
is sufficient information to direct a lineman to the area to quickly find the
cause, repair it, and replace the fuse.
Instrumentation of
Electrical Distribution Networks
Another unique property of
EDNs poses a challenge to diagnosis of faults, and has to do with the way in
which they are usually instrumented.
It is common for even small
utilities to have a SCADA system, which is used to remotely monitor and control
sub-station breakers, and sometimes switches in the feeder and section
lines. Depending upon the amount of
SCADA enabled devices in the circuit; the voltage, current, and status
measurements from the SCADA system provide a certain level of instrumentation
of the circuit. These devices tend to
reside mainly in the sub-stations and in the feeder lines, closer to the top of
the network tree.
Another more indirect form
of instrumentation that is available is the observations of the customers.
During outages, some customers will call the utility to report the loss of
power. Most utilities have an IVR
system that tracks customer calls and stores the information in a database. This information can be extremely useful in
evaluating problems. We can consider
these calls to be instrumentation of the circuit, but with a significant
caveat. The sensors (people who could report outages) are not dependable, since
not everyone calls in when his or her power is out. A customer may assume that, since his neighbor’s lights are out,
the entire neighborhood is probably out, so the utility must already know about
it. Also, at any given time, a varying
percentage of customers are not at home, especially during working hours. Thus, the information provided by the IVR
system must be treated less as instrumentation of the circuit than as hints as
to which parts of the circuit may be out.
The trouble call data, if used as a direct indicator of which customers
are out, will result in “false negative” readings (customers which are marked
as OK, but which are actually out). If
a customer does not call in, it is incorrect to assume that the power is on.
One conclusion that can be
made from these observations is that EDNs are quite under instrumented, from
the point of view of diagnostics. The
dependable measurements that do exist (SCADA data) tend to be near the root of
the network tree. The trouble calls
provide information about the leaves of the tree, but this information is
incomplete, and can result in false negative indications. The distribution of the “sensors” throughout
the networks also works against us, since they are mainly clustered near the
root of the tree and at the leaves, leaving out many of the hierarchy levels of
the network.
The ORMS Diagnostics
Algorithm
We developed a new algorithm
specifically for EDNs. This diagnostics
algorithm is able to produce the desired level of diagnosis with a reasonable
amount of computational resources.
The algorithm takes a novel
approach toward diagnosis, in that:
1)
it
incorporates SCADA measurements, if available, in addition to customer trouble
calls,
2)
it
exploits the hierarchical tree structure of EDNs,
3)
it
applies domain knowledge in selecting particular components from sets suspected
of being faulty
4)
it
uses an advanced mathematical technique based on BDD to deal with the
combinatorial explosion in the size of the fault hypothesis space.
The resulting algorithm is
able to diagnose multiple, non-interacting faults in large EDNs very quickly,
given reasonable resources.
The following sections will
explain the ORMS diagnostics algorithm in detail.
Method
An EDN will have several
sub-stations, each responsible for distributing power to a service area. Given a particular switching configuration
for the feeders, each sub-station represents an independent sub-circuit, from
the point of view of fault management.
Thus, we can reduce the task of diagnosing the entire utility network to
diagnosing each of the sub-station circuits separately.
In the following discussion,
we will concentrate on diagnosing starting at the sub-station, since the
network faults are the composition of the sub-station level faults. Noting that the SCADA information provides
measurements near the root of the network tree, that first step taken in the
diagnosis algorithm should be to determine if there are any faults in SCADA
enabled components. If a SCADA
measurement tells us that a component is faulted, there is no use in reasoning
about any trouble calls coming from customers served by that component. Thus, the algorithm first marks the
customers of each faulted SCADA component as being out so that further trouble
calls from that set of customers will be blocked. This is the easy step.
The difficulty lies in reasoning about trouble calls that cannot be
explained by a fault in a SCADA enabled component.
Consider a situation in a
sub-station circuit where N customers call in and report an outage, but
there are no apparent faults in the SCADA enabled components in that
circuit. The simplest approach would be
to trace back in the circuit from each trouble call, and select one circuit
component from the set formed by taking the intersection of the sub-circuit
components. This approach makes the
assumption that a single faulted component is causing all N trouble
calls. However, in certain conditions,
such as bad weather, it is possible, even likely, that the N trouble
calls could be attributed to 2, 3, or more separate faults in the sub-station
circuit. This is especially true if the
trouble calls are dispersed throughout the circuit. An astute dispatcher may be able to identify multiple faults by
viewing the service area map with the trouble calls highlighted. If the trouble calls show up as clustered
groups on the map, the operator may assume that they are caused by separate
faults, one for each cluster. With this
observation, the dispatcher then ignores the single fault reported by the
simple circuit-tracing algorithm, and performs a manual analysis to figure out
how many faults there are, and which components are causing them.
The approach taken by the
ORMS algorithm does not make the single fault assumption of simple tracing
algorithms. It automates the manual
analysis mentioned above, and considers the possibility that in the presence of
N trouble calls, the number of faults could be 1, 2, up to and
including N. The algorithm
constructs fault hypothesis sets containing N or fewer components that
1) could completely explain the N trouble calls observed, and 2) contain
a minimal set of components, in that if any component were removed from the
set, it would no longer completely explain the observed trouble calls. The fault hypothesis sets are then ranked,
and the highest-ranking set is chosen.
Challenges
The difficult tasks in the
fore mentioned approach are:
1)
Finding
an efficiently programmable mathematical formalism to use in generating the
hypothesis sets.
2)
Dealing
with the combinatorial size of the hypothesis space.
3)
Evaluating
the relative “likelihoods” of the resulting hypothesis sets.
Algorithm
The
algorithm consists of two levels, one which traverses the circuit topology from
the top down (from the substations to the loads), the other which traverses
from the bottom up (from the loads to the substations). The top down traversal identifies outages
related to higher-level SCADA-enabled devices.
The bottom up traversal performs an analysis of outages related to
customer calls that are not explained by the top down traversal. This approach reduces the overall amount of
processing required perform the diagnostic reasoning under normal
circumstances, since it first rules out calls that can be assocaited with
measurable devices. These levels are
described in the following section.
Conclusion
As the size of the power network system grows and
the number of trouble calls increases, the set of generated hypotheses becomes
larger. This scaling issue has presented a problem and therefore a challenge to
the energy distribution network industries to localize faulty components. We have developed an algorithm that employs
both electrical utility domain knowledge and advanced mathematical techniques
to generate and analyze the fault hypothesis sets efficiently. We have implemented this algorithm in a
system called the ORMS, which as a result, is able to quickly diagnose large
utility networks.
The ORMS is part of a larger, component based system
called IDMS. The IDMS employs MIC
technology, developed at Vanderbilt ISIS, to provide the integration between
the ORMS and the other utility software, such as the GIS, IVR, CIS, and SCADA
systems. MIC allows the integration
between these components to be maintained via a high-level graphical user
interface, and requires no software engineering expertise. This enables the IDMS to be integrated and
maintained by the utility domain experts who use it.
The IDMS provide a platform on which can be built a
flexible and cost-effectively extensible suite of decision support tools for
electric utilities. The diagnostics component, the ORMS, is capable of
efficiently identifying faulty components during power outages. The ORMS
algorithm is implemented as an OLE/DCOM component, and has been integrated with
several standard COTS systems commonly used in electrical utilities.
The ORMS diagnostic engine is capable of efficiently
diagnosing faults in energy distribution networks. It can locate not only a single fault, but also multiple faults
(non-interacting faults within a single feeder). It is able to locate and
identify any faulty electrical components, including conductors. The diagnosis
is fast and accurate, and takes advantage of any available data. The ORMS has
been received well among engineers in the energy distribution industry.
References
[1] S. Monemi, “Fault Management Systems in Energy Distribution Network Environments”, Ph. D. Dissertation, Vanderbilt University, Dec. 1999.
[2] G. Karsai and A. Ledeczi, “ A Graphical Modeling Environment for the Multigraph Architecture”, ISIS, Vanderbilt University, Manual ver. 0.5, Nashville, TN, 1998.
[3] M. Moore, S. Monemi, and J. Wangl, “Diagnostics and Integration in Electric Utilities,” Proceedings of the IEEE 2000 Rural Electric Power Conference, Louisville, KY, May 2000.
Author Information
Saeed
Sean Monemi, Ph.D.
Senior
Research Associate
Vanderbilt
University - ISIS
Box
2157, Station B
Nashville,
TN 37235
Telephone:
615-343-7555
Facsimile:
615-343-7440
E-mail:
monemi@isis.vanderbilt.edu