U.S. patent application number 14/079204 was filed with the patent office on 2014-09-11 for storm response optimization.
This patent application is currently assigned to SAS Institute Inc.. The applicant listed for this patent is SAS Institute Inc.. Invention is credited to Kathy Ball, Albert Hopping.
Application Number | 20140257913 14/079204 |
Document ID | / |
Family ID | 51488869 |
Filed Date | 2014-09-11 |
United States Patent
Application |
20140257913 |
Kind Code |
A1 |
Ball; Kathy ; et
al. |
September 11, 2014 |
STORM RESPONSE OPTIMIZATION
Abstract
A method of predicting equipment failures is provided.
Potentially-effected equipment located in a path projection for a
weather event is identified based on a current characteristic data
describing equipment supporting a service. A likelihood of failure
for each equipment of the identified potentially-effected equipment
is calculated by executing a failure prediction model with the
current characteristic data and weather event data describing
characteristics of the weather event. Equipment failures of the
identified potentially-effected equipment are predicted by
comparing the calculated likelihood of failure for each equipment
of the identified potentially-effected equipment to a predefined
threshold. Information identifying the predicted equipment failures
is output.
Inventors: |
Ball; Kathy; (Cary, NC)
; Hopping; Albert; (Raleigh, NC) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
SAS Institute Inc. |
Cary |
NC |
US |
|
|
Assignee: |
SAS Institute Inc.
Cary
NC
|
Family ID: |
51488869 |
Appl. No.: |
14/079204 |
Filed: |
November 13, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61774029 |
Mar 7, 2013 |
|
|
|
61775817 |
Mar 11, 2013 |
|
|
|
61825522 |
May 21, 2013 |
|
|
|
Current U.S.
Class: |
705/7.25 |
Current CPC
Class: |
G06Q 10/04 20130101;
G01C 21/343 20130101; G06Q 50/06 20130101; G06Q 10/0631
20130101 |
Class at
Publication: |
705/7.25 |
International
Class: |
G06Q 50/06 20060101
G06Q050/06; G06Q 10/04 20060101 G06Q010/04 |
Claims
1. A computer-readable medium having stored thereon
computer-readable instructions that when executed by a computing
device cause the computing device to: receive current
characteristic data of equipment supporting a service; receive
weather event data including a path projection for a weather event;
execute a failure prediction model with the received current
characteristic data and the received weather event data to define a
likelihood of failure of the equipment supporting the service; and
identify predicted equipment failures of the equipment supporting
the service by comparing the defined likelihood of failure of each
equipment of the equipment supporting the service to a predefined
threshold.
2. The computer-readable medium of claim 1, wherein the
computer-readable instructions further cause the computing device
to: receive data associated with second equipment supporting the
service, wherein the data includes previous weather event data and
characteristics of the second equipment supporting the service
during the previous weather event; determine characteristics
associated with a failure of a subset of the second equipment
during the previous weather event; and define the failure
prediction model based on the determined characteristics.
3. The computer-readable medium of claim 2, wherein the
characteristics of the second equipment are selected from the group
including a last equipment failure data, a last equipment service
date, an equipment type, an equipment age, and a last tree trimming
date associated with a location of the equipment.
4. The computer-readable medium of claim 2, wherein the previous
weather event data are selected from the group including a wind
speed, a rainfall rate, a snowfall rate, and a wind direction.
5. The computer-readable medium of claim 2, wherein the
characteristics of the second equipment are determined based on a
degree of correlation in predicting the failure of the subset of
the second equipment during the previous weather event.
6. The computer-readable medium of claim 1, wherein the
computer-readable instructions further cause the computing device
to indicate locations of the identified predicted equipment
failures on a map.
7. The computer-readable medium of claim 1, wherein the
computer-readable instructions further cause the computing device
to determine an event level classification based on the identified
predicted equipment failures, wherein the event level
classification is a measure of a severity of expected service
outages resulting from the identified predicted equipment
failures.
8. The computer-readable medium of claim 1, wherein the
computer-readable instructions further cause the computing device
to determine a staging location for a service outage responder
based on the identified predicted equipment failures.
9. The computer-readable medium of claim 1, wherein the
computer-readable instructions further cause the computing device
to determine an estimate of replacement equipment needed to respond
to the weather event based on the identified predicted equipment
failures.
10. The computer-readable medium of claim 1, wherein the
computer-readable instructions further cause the computing device
to receive outage data identifying a service outage source
location.
11. The computer-readable medium of claim 10, wherein the outage
data is defined by analyzing social media data.
12. The computer-readable medium of claim 10, wherein the
computer-readable instructions further cause the computing device
to indicate locations of the identified predicted equipment
failures on a map and to indicate the service outage source
location on the map.
13. The computer-readable medium of claim 10, wherein the
computer-readable instructions further cause the computing device
to determine an event level classification based on the identified
predicted equipment failures and the received outage data, wherein
the event level classification is a measure of a severity of
expected service outages resulting from the identified predicted
equipment failures.
14. The computer-readable medium of claim 10, wherein the
computer-readable instructions further cause the computing device
to determine an estimate of replacement equipment needed to respond
to the weather event based on the identified predicted equipment
failures and the received outage data.
15. The computer-readable medium of claim 10, wherein the
computer-readable instructions further cause the computing device
to determine service restoration time estimates based on the
received outage data.
16. The computer-readable medium of claim 1, wherein the
computer-readable instructions further cause the computing device
to: receive updated weather event data; execute the failure
prediction model with the received current characteristic data and
the received updated weather event data to define an updated
likelihood of failure of the equipment supporting the service; and
identify updated predicted equipment failures of the equipment
supporting the service based on the defined updated likelihood of
failure of the equipment supporting the service.
17. The computer-readable medium of claim 1, wherein the equipment
supporting the service and the second equipment supporting the
service include the same equipment.
18. The computer-readable medium of claim 1, wherein the failure
prediction model includes one or more mathematical models selected
from the group consisting of a regression model, a decision tree,
an ensemble model, and a neural network model.
19. A system comprising: a processor; and a computer-readable
medium operably coupled to the processor, the computer-readable
medium having computer-readable instructions stored thereon that,
when executed by the processor, cause the system to receive current
characteristic data of equipment supporting a service; receive
weather event data including a path projection for a weather event;
execute a failure prediction model with the received current
characteristic data and the received weather event data to define a
likelihood of failure of the equipment supporting the service; and
identify predicted equipment failures of the equipment supporting
the service by comparing the defined likelihood of failure of each
equipment of the equipment supporting the service to a predefined
threshold.
20. A method of predicting equipment failures, the method
comprising: identifying, by a first computing device,
potentially-effected equipment located in a path projection for a
weather event based on current characteristic data describing
equipment supporting a service, wherein the equipment is
land-based; calculating, by the first computing device, a
likelihood of failure for each equipment of the identified
potentially-effected equipment by executing a failure prediction
model with the current characteristic data and weather event data
describing characteristics of the weather event; and predicting
equipment failures of the identified potentially-effected equipment
by comparing the calculated likelihood of failure for each
equipment of the identified potentially-effected equipment to a
predefined threshold; and outputting information identifying the
predicted equipment failures.
21. The method of claim 20, wherein outputting the information
comprises indicating locations of the predicted equipment failures
on a map for presentation in a display.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present application claims priority under 35 U.S.C.
.sctn.119(e) to U.S. Provisional Patent Application No. 61/774,029
filed Mar. 7, 2013, to U.S. Provisional Patent Application No.
61/775,817 filed Mar. 11, 2013, and to U.S. Provisional Patent
Application No. 61/825,522 filed May 21, 2013, the entire contents
of which are all hereby incorporated by reference.
BACKGROUND
[0002] After a storm has passed and emergency repairs are complete,
a utility may be faced with the daunting task of restoring service,
such as power, water, gas, etc., to multiple customers. For
example, three days after Hurricane Irene struck the east coast and
after the initial emergency restorations, the state of
Massachusetts was faced with over 65,000 power outages and over
10,000 transformer failures.
SUMMARY
[0003] In an example embodiment, a method of predicting equipment
failures is provided. Potentially-effected equipment located in a
path projection for a weather event is identified based on a
current characteristic data describing equipment supporting a
service. A likelihood of failure for each equipment of the
identified potentially-effected equipment is calculated by
executing a failure prediction model with the current
characteristic data and weather event data describing
characteristics of the weather event. Equipment failures of the
identified potentially-effected equipment are predicted by
comparing the calculated likelihood of failure for each equipment
of the identified potentially-effected equipment to a predefined
threshold. Information identifying the predicted equipment failures
is output.
[0004] In another example embodiment, a computer-readable medium is
provided having stored thereon computer-readable instructions that
when executed by a computing device, cause the computing device to
perform the method of predicting equipment failures. Current
characteristic data of equipment supporting a service is received.
Weather event data including a path projection for a weather event
is received. A failure prediction model is executed with the
received current characteristic data and the received weather event
data to define a likelihood of failure of the equipment supporting
the service. Predicted equipment failures of the equipment
supporting the service are identified by comparing the defined
likelihood of failure of each equipment of the equipment supporting
the service to a predefined threshold.
[0005] In yet another example embodiment, a system is provided. The
system includes, but is not limited to, a processor and a
computer-readable medium operably coupled to the processor. The
computer-readable medium has instructions stored thereon that, when
executed by the processor, cause the system to perform the method
of predicting equipment failures.
[0006] Other principal features of the disclosed subject matter
will become apparent to those skilled in the art upon review of the
following drawings, the detailed description, and the appended
claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] Illustrative embodiments of the disclosed subject matter
will hereafter be described referring to the accompanying drawings,
wherein like numerals denote like elements.
[0008] FIG. 1 depicts a block diagram of a storm response system in
accordance with an illustrative embodiment.
[0009] FIG. 2 depicts a block diagram of a service outage planning
device of the storm response system of FIG. 1 in accordance with an
illustrative embodiment.
[0010] FIG. 3 depicts a block diagram of an event status device of
the storm response system of FIG. 1 in accordance with an
illustrative embodiment.
[0011] FIG. 4 depicts a block diagram of a service status device of
the storm response system of FIG. 1 in accordance with an
illustrative embodiment.
[0012] FIG. 5 depicts a block diagram of an event responder device
of the storm response system of FIG. 1 in accordance with an
illustrative embodiment.
[0013] FIG. 6 depicts a first flow diagram illustrating examples of
operations performed by the service outage planning device of FIG.
2 in accordance with an illustrative embodiment.
[0014] FIG. 7 depicts a second flow diagram illustrating examples
of operations performed by the service outage planning device of
FIG. 2 in accordance with an illustrative embodiment.
[0015] FIG. 8 depicts a third flow diagram illustrating examples of
operations performed by the service outage planning device of FIG.
2 in accordance with an illustrative embodiment.
[0016] FIG. 9 depicts a fourth flow diagram illustrating examples
of operations performed by the service outage planning device of
FIG. 2 in accordance with an illustrative embodiment.
DETAILED DESCRIPTION
[0017] Referring to FIG. 1, a block diagram of a storm response
system 100 is shown in accordance with an illustrative embodiment.
In an illustrative embodiment, storm response system 100 may
include a service outage planning system 102, an event status
system 104, a service status system 106, an event responder system
108, and a network 110. The components of storm response system 100
may be positioned in a single room or adjacent rooms, in a single
facility, and/or may be distributed geographically from one another
remote from one another. The components of storm response system
100 further may integrated. For example, storm response system 100
can complement an existing outage management system or remain
separate for storm optimization. Additionally, input that affects
customer restoration can be integrated into a customer information
system for improved communications with customers and crews.
[0018] Service outage planning system 102 receives event
information concerning an event, such as a weather event, as well
as service status information concerning a service status, such as
a provision of power, water, gas, etc. Service outage planning
system 102 plans for a response to the event and the event's effect
on provision of the service including assigning event responders to
restore the service when an outage occurs.
[0019] Network 110 supports communication between the components of
storm response system 100. Network 110 may include one or more
networks of the same or different types. Network 110 can be any
type of wired and/or wireless public or private network including a
cellular network, a local area network, a wide area network such as
the Internet, etc. Network 110 further may comprise sub-networks
and consist of any number of devices.
[0020] Service outage planning system 102 can include any number
and type of computing devices that may be organized into subnets.
The computing devices of service outage planning system 102 send
and receive signals through network 110 to/from another of the one
or more computing devices of event status system 104, service
status system 106, and/or event responder system 108. The one or
more computing devices of service outage planning system 102 may
include computers of any form factor such as a laptop, a desktop, a
smart phone, a personal digital assistant, an integrated messaging
device, a tablet computer, etc. though service outage planning
system 102 is represented as a server computing device in the
illustrative embodiment of FIG. 1. The one or more computing
devices of service outage planning system 102 may communicate using
various transmission media that may be wired and/or wireless as
understood by those skilled in the art.
[0021] Event status system 104 can include any number and type of
computing devices that may be organized into subnets. The computing
devices of event status system 104 may communicate signals through
network 110 with another of the one or more computing devices of
service outage planning system 102, service status system 106,
and/or event responder system 108. The one or more computing
devices of event status system 104 may include computers of any
form factor such as a laptop 112, a desktop 114, a smart phone 116,
a personal digital assistant, an integrated messaging device, a
tablet computer, etc. The one or more computing devices of event
status system 104 may communicate using various transmission media
that may be wired and/or wireless as understood by those skilled in
the art. Event status system 104 may monitor and provide updates
related to an event such as a weather event.
[0022] Service status system 106 can include any number and type of
computing devices that may be organized into subnets. The computing
devices of service status system 106 may communicate signals
through network 110 with another of the one or more computing
devices of service outage planning system 102, event status system
104, and/or event responder system 108. The one or more computing
devices of service status system 106 may include computers of any
form factor such as a laptop 118, a desktop 120, a smart phone 122,
a personal digital assistant, an integrated messaging device, a
tablet computer, etc. The one or more computing devices of service
status system 106 may communicate using various transmission media
that may be wired and/or wireless as understood by those skilled in
the art. Service status system 106 may monitor and provide updates
related to a status of provision of a service.
[0023] Event responder system 108 can include any number and type
of computing devices that may be organized into subnets. The
computing devices of event responder system 108 send and receive
signals through network 110 to/from another of the one or more
computing devices of service outage planning system 102, event
status system 104, and/or service status system 106. The one or
more computing devices of event responder system 108 may include
computers of any form factor such as a laptop 124, a desktop 126, a
smart phone 128, a personal digital assistant, an integrated
messaging device, a tablet computer, etc. The one or more computing
devices of event responder system 108 may communicate using various
transmission media that may be wired and/or wireless as understood
by those skilled in the art. Event responder system 108 may provide
communication related to a response to a service outage.
[0024] Referring to FIG. 2, a block diagram of service outage
planning system 102 is shown in accordance with an illustrative
embodiment. Service outage planning system 102 may include an input
interface 200, an output interface 202, a communication interface
204, a computer-readable medium 206, a processor 208, a keyboard
210, a mouse 212, a display 214, a speaker 216, a printer 218, and
a service outage planning application 220, and a database 222.
Fewer, different, and/or additional components may be incorporated
into service outage planning system 102.
[0025] Input interface 200 provides an interface for receiving
information from the user for entry into service outage planning
system 102 as understood by those skilled in the art. Input
interface 200 may interface with various input technologies
including, but not limited to, keyboard 210, mouse 212, display
214, a track ball, a keypad, one or more buttons, etc. to allow the
user to enter information into service outage planning system 102
or to make selections in a user interface displayed on display 214.
Display 214 may be a thin film transistor display, a light emitting
diode display, a liquid crystal display, or any of a variety of
different display types as understood by those skilled in the art.
The same interface may support both input interface 200 and output
interface 202. For example, a display comprising a touch screen
both allows user input and presents output to the user. Service
outage planning system 102 may have one or more input interfaces
that use the same or a different input interface technology.
Keyboard 210, mouse 212, display 214, etc. further may be
accessible by service outage planning system 102 through
communication interface 204.
[0026] Output interface 202 provides an interface for outputting
information for review by a user of service outage planning system
102. For example, output interface 202 may interface with various
output technologies including, but not limited to, display 214,
speaker 216, printer 218, etc. Service outage planning system 102
may have one or more output interfaces that use the same or a
different interface technology. Speaker 216, printer 218, etc.
further may be accessible by service outage planning system 102
through communication interface 204.
[0027] Communication interface 204 provides an interface for
receiving and transmitting data between devices using various
protocols, transmission technologies, and media as understood by
those skilled in the art. Communication interface 204 may support
communication using various transmission media that may be wired
and/or wireless. Service outage planning system 102 may have one or
more communication interfaces that use the same or a different
communication interface technology. For example, service outage
planning system 102 may support communication using an Ethernet
port, a Bluetooth antenna, a telephone jack, a USB port, etc. Data
and messages may be transferred between service outage planning
system 102 and event status system 104, service status system 106,
and/or event responder system 108 using communication interface
204.
[0028] Computer-readable medium 206 is an electronic holding place
or storage for information so the information can be accessed by
processor 208 as understood by those skilled in the art.
Computer-readable medium 206 can include, but is not limited to,
any type of random access memory (RAM), any type of read only
memory (ROM), any type of flash memory, etc. such as magnetic
storage devices (e.g., hard disk, floppy disk, magnetic strips, . .
. ), optical disks (e.g., compact disc (CD), digital versatile disc
(DVD), . . . ), smart cards, flash memory devices, cache memory,
etc. Service outage planning system 102 may have one or more
computer-readable media that use the same or a different memory
media technology. Service outage planning system 102 also may have
one or more drives that support the loading of a memory media such
as a CD or DVD.
[0029] Processor 208 executes instructions as understood by those
skilled in the art. The instructions may be carried out by a
special purpose computer, logic circuits, or hardware circuits.
Processor 208 may be implemented in hardware and/or in firmware.
Processor 208 executes an instruction, meaning it performs/controls
the operations called for by that instruction. Thus, the term
"execution" is the process of running an application or the
carrying out of the operation called for by an instruction. The
instructions may be written using one or more programming language,
scripting language, assembly language, etc. that may or may not be
compiled. Processor 208 operably couples with input interface 200,
with output interface 202, with communication interface 204, and
with computer-readable medium 206 to receive, to send, and to
process information. Processor 208 may retrieve a set of
instructions from a permanent memory device and copy the
instructions in an executable form to a temporary memory device
that is generally some form of RAM. Service outage planning system
102 may include a plurality of processors that use the same or a
different processing technology. For example, service outage
planning system 102 may include a plurality of central processing
units, a digital signal processor, etc.
[0030] Service outage planning application 220 performs operations
associated with receiving event information and service status
information and planning for a response to the event and the
event's effect on provision of the service including assigning
event responders to restore the service when an outage occurs. Some
or all of the operations described herein may be embodied in
service outage planning application 220. The operations may be
implemented using hardware, firmware, software, or any combination
of these. Referring to the example embodiment of FIG. 2, service
outage planning application 220 is implemented in software
(comprised of computer-readable and/or computer-executable
instructions) stored in computer-readable medium 206 and accessible
by processor 208 for execution of the instructions that embody the
operations of service outage planning application 220. Service
outage planning application 220 may be written using one or more
programming languages, assembly languages, scripting languages,
etc.
[0031] Service outage planning application 220 may be implemented
as a Web application. For example, service outage planning
application 220 may be configured to receive hypertext transport
protocol (HTTP) responses from other computing devices, such as
those associated with service outage planning system 102, and to
send HTTP requests. The HTTP responses may include web pages such
as hypertext markup language (HTML) documents and linked objects
generated in response to the HTTP requests. Each web page may be
identified by a uniform resource locator (URL) that includes the
location or address of the computing device that contains the
resource to be accessed in addition to the location of the resource
on that computing device. The type of file or resource depends on
the Internet application protocol such as the file transfer
protocol, HTTP, H.323, etc. The file accessed may be a simple text
file, an image file, an audio file, a video file, an executable, a
common gateway interface application, a Java applet, an extensible
markup language (XML) file, or any other type of file supported by
HTTP.
[0032] Service outage planning system 102 may include database 222
stored on computer-readable medium 206 or can access database 222
either through a direct connection or through network 110 using
communication interface 204. Database 222 is a data repository for
storm response system 100. For example, the data processed using
service outage planning application 220 may be stored in database
222. Database 222 may include a plurality of databases that may be
organized into multiple database tiers to improve data management
and access. Database 222 may be stored in one or more storage
locations distributed over network 110 and using the same or
different formats. Database 222 may utilize various database
technologies and a variety of formats as known to those skilled in
the art including a file system, a relational database, a system of
tables, a structured query language database, etc.
[0033] Referring to FIG. 3, a block diagram of an event status
device 300 of event status system 104 is shown in accordance with
an illustrative embodiment. Event status device 300 is an example
computing device of event status system 104. Event status device
300 may include an second input interface 302, a second output
interface 304, a second communication interface 306, a second
computer-readable medium 308, a second processor 310, a second
keyboard 312, a second mouse 314, a second display 316, a second
speaker 318, a second printer 320, and an event status application
322. Fewer, different, and/or additional components may be
incorporated into event status device 300.
[0034] Second input interface 302 provides the same or similar
functionality as that described with reference to input interface
200 of service outage planning system 102 though referring to event
status device 300 instead of service outage planning system 102.
Second output interface 304 provides the same or similar
functionality as that described with reference to output interface
202 of service outage planning system 102 though referring to event
status device 300 instead of service outage planning system 102.
Second communication interface 306 provides the same or similar
functionality as that described with reference to communication
interface 204 of service outage planning system 102 though
referring to event status device 300 instead of service outage
planning system 102. Data and messages may be transferred between
event status device 300 and service outage planning system 102
using second communication interface 306.
[0035] Second computer-readable medium 308 provides the same or
similar functionality as that described with reference to
computer-readable medium 206 of service outage planning system 102
though referring to event status device 300 instead of service
outage planning system 102. Second processor 310 provides the same
or similar functionality as that described with reference to
processor 208 of service outage planning system 102 though
referring to event status device 300 instead of service outage
planning system 102. Second keyboard 312 provides the same or
similar functionality as that described with reference to keyboard
210 of service outage planning system 102 though referring to event
status device 300 instead of service outage planning system 102.
Second mouse 314 provides the same or similar functionality as that
described with reference to mouse 212 of service outage planning
system 102 though referring to event status device 300 instead of
service outage planning system 102. Second display 316 provides the
same or similar functionality as that described with reference to
display 214 of service outage planning system 102 though referring
to event status device 300 instead of service outage planning
system 102. Second speaker 318 provides the same or similar
functionality as that described with reference to speaker 216 of
service outage planning system 102 though referring to event status
device 300 instead of service outage planning system 102. Second
printer 320 provides the same or similar functionality as that
described with reference to printer 218 of service outage planning
system 102 though referring to event status device 300 instead of
service outage planning system 102.
[0036] Event status application 322 performs operations associated
with monitoring a status of an event such as a weather event. For
example, event status application 322 may provide current weather
conditions and perform weather forecasting for a region. The region
may include a town, a city, a county, a state, a region, a country,
etc. Event status application 322 may further communicate
information related to the current weather conditions and weather
forecast to other devices such as to service outage planning system
102 either automatically or on demand. Some or all of the
operations described herein may be embodied in event status
application 322. The operations may be implemented using hardware,
firmware, software, or any combination of these methods. Referring
to the example embodiment of FIG. 4, event status application 322
is implemented in software (comprised of computer-readable and/or
computer-executable instructions) stored in second
computer-readable medium 308 and accessible by second processor 310
for execution of the instructions that embody the operations of
event status application 322. Event status application 322 may be
written using one or more programming languages, assembly
languages, scripting languages, etc.
[0037] Event status application 322 may be implemented as a Web
application. For example, event status application 322 may be
configured to receive HTTP responses from other computing devices,
such as those associated with service outage planning system 102,
and to send HTTP requests. The HTTP responses may include web pages
such as hypertext markup language (HTML) documents and linked
objects generated in response to the HTTP requests. Each web page
may be identified by a uniform resource locator (URL) that includes
the location or address of the computing device that contains the
resource to be accessed in addition to the location of the resource
on that computing device. The type of file or resource depends on
the Internet application protocol such as the file transfer
protocol, HTTP, H.323, etc. The file accessed may be a simple text
file, an image file, an audio file, a video file, an executable, a
common gateway interface application, a Java applet, an extensible
markup language (XML) file, or any other type of file supported by
HTTP.
[0038] Referring to FIG. 4, a block diagram of a service status
device 400 is shown in accordance with an illustrative embodiment.
Service status device 400 is an example computing device of service
status system 106. Service status device 400 may include a third
input interface 402, a third output interface 404, a third
communication interface 406, a third computer-readable medium 408,
a third processor 410, a third keyboard 412, a third mouse 414, a
third display 416, a third speaker 418, a third printer 420, and a
service status application 422. Fewer, different, and additional
components may be incorporated into service status device 400.
[0039] Third input interface 402 provides the same or similar
functionality as that described with reference to input interface
200 of service outage planning system 102 though referring to
service status device 400 instead of service outage planning system
102. Third output interface 404 provides the same or similar
functionality as that described with reference to output interface
202 of service outage planning system 102 though referring to
service status device 400 instead of service outage planning system
102. Third communication interface 406 provides the same or similar
functionality as that described with reference to communication
interface 204 of service outage planning system 102 though
referring to service status device 400 instead of service outage
planning system 102. Data and messages may be transferred between
service status device 400 and service outage planning system 102
using third communication interface 406.
[0040] Third computer-readable medium 408 provides the same or
similar functionality as that described with reference to
computer-readable medium 206 of service outage planning system 102
though referring to service status device 400 instead of service
outage planning system 102. Third processor 410 provides the same
or similar functionality as that described with reference to
processor 208 of service outage planning system 102 though
referring to service status device 400 instead of service outage
planning system 102. Third keyboard 412 provides the same or
similar functionality as that described with reference to keyboard
210 of service outage planning system 102 though referring to
service status device 400 instead of service outage planning system
102. Third mouse 414 provides the same or similar functionality as
that described with reference to mouse 212 of service outage
planning system 102 though referring to service status device 400
instead of service outage planning system 102. Third display 416
provides the same or similar functionality as that described with
reference to display 214 of service outage planning system 102
though referring to service status device 400 instead of service
outage planning system 102. Third speaker 418 provides the same or
similar functionality as that described with reference to speaker
216 of service outage planning system 102 though referring to
service status device 400 instead of service outage planning system
102. Third printer 420 provides the same or similar functionality
as that described with reference to printer 218 of service outage
planning system 102 though referring to service status device 400
instead of service outage planning system 102.
[0041] Service status application 422 performs operations
associated with monitoring a status of a service, such as a
provision of power, water, gas, etc. for a region. The region may
include a town, a city, a county, a state, a region, a country,
etc. Service status application 422 may further communicate
information related to the service status to other devices such as
to service outage planning system 102 either automatically or on
demand. Some or all of the operations described herein may be
embodied in service status application 422. The operations may be
implemented using hardware, firmware, software, or any combination
of these methods. Referring to the example embodiment of FIG. 4,
Service status application 422 is implemented in software
(comprised of computer-readable and/or computer-executable
instructions) stored in third computer-readable medium 408 and
accessible by third processor 410 for execution of the instructions
that embody the operations of service status application 322.
Service status application 422 may be written using one or more
programming languages, assembly languages, scripting languages,
etc.
[0042] Service status application 422 may be implemented as a Web
application. For example, service status application 422 may be
configured to receive HTTP responses from other computing devices,
such as those associated with service outage planning system 102,
and to send HTTP requests. The HTTP responses may include web pages
such as HTML documents and linked objects generated in response to
the HTTP requests. Each web page may be identified by a URL that
includes the location or address of the computing device that
contains the resource to be accessed in addition to the location of
the resource on that computing device. The type of file or resource
depends on the Internet application protocol. The file accessed may
be a simple text file, an image file, an audio file, a video file,
an executable, a common gateway interface application, a Java
applet, an XML file, or any other type of file supported by
HTTP.
[0043] Referring to FIG. 5, a block diagram of an event responder
device 500 is shown in accordance with an illustrative embodiment.
Event responder device 500 is an example computing device of event
responder system 108. Event responder device 500 may include a
fourth input interface 502, a fourth output interface 504, a fourth
communication interface 506, a fourth computer-readable medium 508,
a fourth processor 510, a fourth keyboard 512, a fourth mouse 514,
a fourth display 516, a fourth speaker 518, a fourth printer 520,
and an event responder application 522. Fewer, different, and
additional components may be incorporated into event responder
device 500.
[0044] Fourth input interface 502 provides the same or similar
functionality as that described with reference to input interface
200 of service outage planning system 102 though referring to event
responder device 500 instead of service outage planning system 102.
Fourth output interface 504 provides the same or similar
functionality as that described with reference to output interface
202 of service outage planning system 102 though referring to event
responder device 500 instead of service outage planning system 102.
Fourth communication interface 506 provides the same or similar
functionality as that described with reference to communication
interface 204 of service outage planning system 102 though
referring to event responder device 500 instead of service outage
planning system 102. Data and messages may be transferred between
event responder device 500 and service outage planning system 102
using fourth communication interface 506.
[0045] Fourth computer-readable medium 508 provides the same or
similar functionality as that described with reference to
computer-readable medium 206 of service outage planning system 102
though referring to event responder device 500 instead of service
outage planning system 102. Fourth processor 510 provides the same
or similar functionality as that described with reference to
processor 208 of service outage planning system 102 though
referring to event responder device 500 instead of service outage
planning system 102. Fourth keyboard 512 provides the same or
similar functionality as that described with reference to keyboard
210 of service outage planning system 102 though referring to event
responder device 500 instead of service outage planning system 102.
Fourth mouse 514 provides the same or similar functionality as that
described with reference to mouse 212 of service outage planning
system 102 though referring to event responder device 500 instead
of service outage planning system 102. Fourth display 516 provides
the same or similar functionality as that described with reference
to display 214 of service outage planning system 102 though
referring to event responder device 500 instead of service outage
planning system 102. Fourth speaker 518 provides the same or
similar functionality as that described with reference to speaker
216 of service outage planning system 102 though referring to event
responder device 500 instead of service outage planning system 102.
Fourth printer 520 provides the same or similar functionality as
that described with reference to printer 218 of service outage
planning system 102 though referring to event responder device 500
instead of service outage planning system 102.
[0046] Event responder application 522 performs operations
associated with supporting communication with event responder. For
example, a responder may send a communication to service outage
planning system 102 indicating completion of a repair, indicating a
delay in completion of a service repair and an estimated completion
time, etc. The responder further may receive a communication from
service outage planning system 102 indicating a route assignment
and/or an updated route assignment. A route assignment may indicate
one or more geographic locations at which a repair is to be
performed by the responder. A responder may include one or more
individuals with the same or different skills related to performing
the repair. For illustration, a repair is a response to correct a
service outage such as a power outage and the type of service may
include tree cutting, overhead line repair, underground line
repair, overhead transformer repair, underground transformer
repair, overhead transformer replacement, and underground
transformer replacement, etc. Other service outages may include a
gas outage, a water outage, etc.
[0047] Service outage planning application 220, event status
application 322, service status application 422, and/or event
responder application 522 may be the same or different applications
or part of an integrated, distributed application supporting some
or all of the same or additional types of functionality as
described herein. As an example, the functionality provided by
service outage planning application 220, event status application
322, service status application 422, and/or event responder
application 522 may be provided as part of processing associated
with SAS.RTM.OR, SAS.RTM.VA, SAS.RTM.EM, SAS.RTM.EG, SAS.RTM.Text
Analytics, etc. offered by SAS Institute Inc., the assignee of the
current application. Various levels of integration between the
components of storm response system 100 may be implemented without
limitation as understood by a person of skill in the art.
[0048] Referring to FIG. 6, example operations associated with
service outage planning application 220 are described. Additional,
fewer, or different operations may be performed depending on the
embodiment. The order of presentation of the operations of FIG. 6
is not intended to be limiting. A user can interact with one or
more user interface windows presented to the user in display 214
under control of service outage planning application 220 or through
a browser application in an order selectable by the user. Although
some of the operational flows are presented in sequence, the
various operations may be performed in various repetitions,
concurrently (in parallel), and/or in other orders than those that
are illustrated.
[0049] For example, a user may execute service outage planning
application 220, which causes presentation of a first user
interface window, which may include a plurality of menus and
selectors such as drop down menus, buttons, text boxes, hyperlinks,
etc. associated with service outage planning application 220 as
understood by a person of skill in the art. Service outage planning
application 220 controls the presentation of one or more additional
user interface windows that further may include menus and selectors
such as drop down menus, buttons, text boxes, hyperlinks,
additional windows, etc. based on user selections received by
service outage planning application 220.
[0050] As understood by a person of skill in the art, the user
interface windows are presented on display 214 under control of the
computer-readable and/or computer-executable instructions of
service outage planning application 220 executed by processor 208
of service outage planning system 102. As the user interacts with
the user interface windows presented under control of service
outage planning application 220, different user interface windows
may be presented to provide the user with various controls from
which the user may make selections or enter values associated with
various application controls. In response, as understood by a
person of skill in the art, service outage planning application 220
receives an indicator associated with an interaction by the user
with a user interface window. Based on the received indicator,
service outage planning application 220 performs one or more
additional operations.
[0051] In an operation 600, previous service outage data is
received. As an example, the previous service outage data may be
selected by a user using a user interface window and received by
service outage planning application 220. For example, the previous
service outage data may be stored in computer-readable medium 206
as a file and/or in database 222 and received by retrieving the
previous service outage data from the appropriate memory location
as understood by a person of skill in the art. For example, the
previous service outage data may be received from one or more
files, through one or more user interface windows, etc.
[0052] In an illustrative embodiment, the previous service outage
data is organized as a plurality of fields for a plurality of
records. Merely for illustration, the previous service outage data
may include service outage source location information such as a
town identifier, a latitude, a longitude, and an altitude, a type
of repair performed previously, a date of the outage, an indicator
of a cause of the outage (i.e., high wind, lightning, precipitation
amounts, flooding, lack of tree trimming, animals, vegetation,
vehicle collision, etc.), a last year trees were trimmed, equipment
performance data such as meter tampering events, transformer
loading, a type of transformer (overhead versus underground),
fuses, voltage and associated load information, previous outage
information from historical storms, etc. at each service outage
source location. In some cases a cause of the ouatage may be
indicated as "unknown". An example dataset may include from a few
to hundreds of fields or more and from a few to tens of thousands
of records or more without limitation.
[0053] In an operation 602, characteristics associated with the
failures are determined. For example, the previous service outage
data may be analyzed to identify the characteristics that correlate
with the failures. For illustration, the SAS Visual Analytics tool
may be used to narrow the list of parameters that are associated
with failures where the previous outage failure is the dependent
variable. In the SAS Visual Analytics tool, correlation analysis
may be performed on some or all of the parameters included in the
previous service outage data to determine the impact of the
parameters on predicting occurrence of an event. The SAS Visual
Analytics tool allows the users to see, via color coding, the
parameters with the strongest degrees of correlation. The user may
drill into the highly correlated parameters to obtain a regression
analysis and to identify a degree of fit of the parameter to the
regression curve.
[0054] In an operation 604, a failure prediction model is defined
based on the characteristics associated with the previous failures.
For example, the user can select the parameters with the highest
degree of correlation in predicting failures and provide those to
the SAS.RTM. Enterprise Guide.RTM. for Data Mining via Rapid
Predictive Modeler or other techniques. Results from the advanced
modeling may be stored and automatically brought into SAS.RTM.
Enterprise Miner for advanced modeling and scoring against the
remaining dataset. The result of this activity yields the failure
prediction model that best fits the data being analyzed, the
previous service outage data. Within the failure prediction model,
data from previous storms and their impact are included in the
model along with current operating conditions of the equipment.
Additional information is included such as tampering and other
previous outage information. The data is analyzed along with
maintenance related logs. Third party information such as weather
information and storm track are also included. The modeling takes
into account historical as well as predictive values in yielding an
overall predictive result. The data mining technique uses survival
analysis techniques such as mean residual life, mean time between
failures, mean time to failure criterion, etc. The failure
prediction model may be developed using catastrophic as well as
non-catastrophic failures in the determination of asset
failures.
[0055] In an operation 606, service characteristic data is
received. The service characteristic data describes the status or
state of the equipment and the environment in which the equipment
is located that supports provision of the service. As an example,
the service characteristic data may be selected by a user using a
user interface window and received by service outage planning
application 220. For example, the service characteristic data may
be stored in computer-readable medium 206 as a file and/or in
database 222 and received by retrieving the service characteristic
data from the appropriate memory location as understood by a person
of skill in the art. For example, the service characteristic data
may be received from one or more files, through one or more user
interface windows, etc.
[0056] In an illustrative embodiment, the service characteristic
data is organized as a plurality of fields for a plurality of
records. Merely for illustration, the service characteristic data
may include service location information such as a town identifier,
a latitude, a longitude, and an altitude, a list of one or more
repairs and a date the previous repair was performed at the service
location, a last year trees were trimmed, equipment performance
data such as meter tampering events, transformer loading, a type of
service location (overhead transformer, underground transformer,
overhead line, underground line, etc.), fuses, voltage and
associated load information, work order information including the
number of customers restored per work ticket, explanation of the
services need to conduct a repair, an estimate of a repair time, a
type of crew needed (i.e., tree crew and repair crew), and
potential equipment needed for repair, etc. at each service
location. Examples of service locations may be transformer
locations, overhead line locations, etc. In general, the service
characteristic data includes parameters similar to those included
in the outage data used to define the failure prediction model
because the service characteristic data is input to the failure
prediction model to determine if any of the service locations are
predicted to fail. An example dataset may include from a few to
hundreds of fields or more and from a few to tens of thousands of
records or more without limitation.
[0057] In an operation 608, event data is received. The event data
describes the current and predicted characteristics of the event.
For example, the event data is received from one or more devices of
event status system 104. As an example, the event data may be
selected by a user using a user interface window and received by
service outage planning application 220. For example, the event
data may be stored in computer-readable medium 206 as a file and/or
in database 222 and received by retrieving the event data from the
appropriate memory location as understood by a person of skill in
the art. For example, the event data may be received from one or
more files, through one or more user interface windows, etc.
[0058] In an illustrative embodiment, the event data is organized
as a plurality of fields for a plurality of records. Merely for
illustration, the event data may include current wind speed and
direction, rainfall rate, snowfall rate, total rainfall amount,
total snowfall amount, etc. and predicted wind speed and direction,
rainfall rate, snowfall rate, total rainfall amount, total snowfall
amount, etc. for a planning region. The planning region may include
a town, a city, a county, a state, a region, etc. An example
dataset may include from a few to hundreds of fields or more and
from a few to tens of thousands of records or more without
limitation.
[0059] In an operation 610, potentially-effected service equipment
is identified. For example, geographic information system mapping
software, such as that developed by ESRI of Redlands, Calif., may
be executed with the service location information obtained from the
received service characteristic data for the planning region. As
another example, the geographic information system mapping software
may be used to define a region expected to be effected by the event
within a certain probability. The geographic information that
defines the bounds of the event region may be used in combination
with the service location information to determine the service
locations within the geographic bounds of the event.
[0060] In an operation 612, the defined failure prediction model is
executed with the received service characteristic data for the
potentially-effected service equipment and with the received event
data.
[0061] In an operation 614, predicted equipment failures are
identified from the potentially-effected service equipment based on
execution of the defined failure prediction model. For example, the
defined failure prediction model may determine a probability of
failure and a probable cause of the failure for the
potentially-effected service equipment. Calculations by the defined
failure prediction model are based on competitive mathematical
models including, but not limited to, regression models, decision
trees, ensemble models, and neural networks. These models include
survival modeling looking at point estimation of hazards with
empirical and sensor data, reviews of survival hazards to quantify
survival, and uses covariates to account for time-series
information and repeating events. The models may include evaluation
of competing risks, left truncation, time windows, and survival for
one time as well as repeating events. The predicted equipment
failures may be identified as the service locations for which the
probability, or likelihood, of failure exceeds a predefined
threshold.
[0062] The locations of the predicted equipment failures may be
used to determine locations at which service outage responder crews
may be positioned to facilitate a response to the event. These
locations may be termed staging locations. For example, various
constraints may be defined to qualify acceptable staging locations
such as proximity to primary roads, type of terrain such as flat
and above a flood level, proximity to the predicted equipment
failures, etc. to determine the staging locations.
[0063] The number and type of predicted equipment failures may be
used to determine an estimate of a number and a type of replacement
equipment that may be needed to facilitate the response to the
event. For example, a predefined percentage of the predicted
equipment failures may be used to define the number and the type of
replacement equipment to order to facilitate the response to the
event. The number and type of predicted equipment failures may be
used to determine an event level classification that is a measure
of a severity of expected service outages resulting from the
identified predicted equipment failures.
[0064] In an operation 616, service outage prediction information
is output. For example, a predicted number, type, and location of
service equipment predicted to fail may be stored in
computer-readable medium 206 as a file and/or in database 222. The
predicted equipment failures may be output based on the probability
of failure, the parameter associated with causing the failure, etc.
The predicted failures may be output geographically on display 214
using a map to show the service locations. Different indicators may
be used, for example, based on the probability of failure, the
parameter associated with causing the failure, etc. The predicted
failures further may be output through communication interface 204
to responders, event planners, etc.
[0065] In an operation 618, a determination is made concerning
whether or not service outage information is identified. For
example, information is received from service status system 106
input using social media outlets such as Facebook, Twitter, etc.
The social media information may be monitored to identify service
outage information. As an example, users of service status system
106 may report service outages to others via social media. A
service provider can monitor the social media outlets daily to
capture text streams related to outage information. This
information may be captured, for example, using the SAS.RTM. Text
Miner tool and incorporated into the SAS.RTM. Enterprise Miner tool
with other outage data.
[0066] The text streams may be analyzed for various keywords that
generally include content such as utility name, line down and
street name, power outage at a given address, electrical fire,
sparking, etc. to automatically identify service outage locations.
This information may be accumulated and compared against existing
outage management information to supplement or complement existing
outage information. If the outage has not been identified within
the outage management system, an additional work ticket may be
generated for an unknown outage without a work ticker. Also,
additional information may be added to an existing work ticket to
improve service restoration at a known outage site. If service
outage information is identified, processing continues in an
operation 620. If service outage information is not identified,
processing continues in an operation 622.
[0067] In operation 620, outage information is output. For example,
the outage information may be stored in computer-readable medium
206 as a file and/or in database 222. Merely for illustration, the
outage information may include service outage source location
information (a town identifier, a latitude, a longitude, and/or an
altitude), a number of affected customers associated with each
service outage source location, and/or a type of repair to perform
at each service outage source location.
[0068] In an operation 622, a determination is made concerning
whether or not the event is complete. For example, the national
weather service may indicate that thunderstorms have moved out of
the area. If the event is complete, processing continues in an
operation 700 to respond to the event. If the event is not
complete, processing continues in operation 608.
[0069] Referring to FIG. 7, additional example operations
associated with service outage planning application 220 are
described. Additional, fewer, or different operations may be
performed depending on the embodiment. The order of presentation of
the operations of FIG. 7 is not intended to be limiting. Although
some of the operational flows are presented in sequence, the
various operations may be performed in various repetitions,
concurrently (in parallel), and/or in other orders than those that
are illustrated.
[0070] In an operation 700, outage data is received. The outage
data may be created as part of execution of operation 620. As an
example, the outage data may be selected by a user using a user
interface window and received by service outage planning
application 220. For example, the outage data may be stored in
computer-readable medium 206 as a file and/or in database 222 and
received by retrieving the outage data from the appropriate memory
location as understood by a person of skill in the art. For
example, the outage data may be received from one or more files,
through one or more user interface windows, etc.
[0071] In an illustrative embodiment, the outage data is organized
as a plurality of fields for a plurality of records. Merely for
illustration, the outage data may include service outage source
location information (a town identifier, a latitude, a longitude,
and/or an altitude), a number of affected customers associated with
each service outage source location, and a type of repair to
perform at each service outage source location. An example dataset
may include from a few to hundreds of fields or more and from a few
to tens of thousands of records or more without limitation. Of
course, an altitude may be assumed to be constant between the
service outage source locations.
[0072] In an operation 702, responder data is received. The
responder data may describe the characteristics of a plurality of
responders. As used herein, a responder may be associated with a
work crew that includes one or more individuals. As an example, the
responder data may be selected by a user using a user interface
window and received by service outage planning application 220. For
example, the responder data may be stored in computer-readable
medium 206 as a file and/or in database 222 and received by
retrieving the responder data from the appropriate memory location
as understood by a person of skill in the art. The responder data
may be received from different computer-readable media. For
example, the responder data may be received from one or more files,
through one or more user interface windows, etc.
[0073] In an illustrative embodiment, the responder data is
organized as a plurality of fields for a plurality of records.
Merely for illustration, the data may include a crew name, a crew
equipment type indicator, a crew skill indicator, a crew maximum
shift time, crew shift time data, a number of crew members in the
crew, an average number of years of experience of the crew members,
a maximum vehicle speed for the equipment associated with the crew,
etc. The crew equipment type indicator may indicate a type of
equipment such as a type of truck and/or equipment on the truck.
The crew skill indicator may indicate crew skills such as whether
or not the crew has underground line repair, aboveground line
repair, overhead transformer repair/replacement, underground
transformer repair/replacement, and/or tree cutting skills. In an
illustrative embodiment, crew equipment type indicator and crew
skill indicator are combined into a single indicator that indicates
whether or not the crew has both the personnel skills and the
equipment to perform different types of repair services. The crew
maximum shift time indicates the amount of time that the crew can
work, for example, in a 24-hour period. Crew shift time data may
further include any other shift timing requirements such as an
earliest start time, a latest stop time, a number of breaks and the
duration of each break, a time-off between work schedules, etc. An
example dataset may include from a few to hundreds of fields or
more and from a few to tens of thousands of records or more without
limitation. The outage data and the crew data may be stored in and
retrieved from the same or different memory storage locations.
[0074] In an operation 704, an estimated repair time, T.sub.R, is
identified. For example, a numerical value is received that
indicates a user selection of the value to be used for T.sub.R.
T.sub.R may be defined as a function of a type of repair to be
performed at each location, as a function of a crew experience
level, as a function of a crew size, as a function of a crew
equipment type, etc. A single value for T.sub.R may be identified,
a value may be identified for each service outage source location,
for each crew, etc. As an example, T.sub.R may be determined for
each service outage source location and stored with the outage
data.
[0075] The value of T.sub.R may be entered by the user using mouse
312, keyboard 310, display 314, etc. In an illustrative embodiment,
instead of receiving a user selection through a presented user
interface window, a default value for T.sub.R may be stored in
computer-readable medium 206 and received by retrieving the value
from the appropriate memory location as understood by a person of
skill in the art. For example, database 222 may include one or more
values for T.sub.R, for example, as a function of a type of repair
to be performed at each location, as a function of a crew
experience level, as a function of a crew size, as a function of a
crew equipment type, etc.
[0076] In an illustrative embodiment, an estimated repair time,
T.sub.R, is determined statistically using a probability function.
The probability function and parameters associated with defining
the probability distribution for T.sub.R may be entered and/or
selected by the user using, for example, a user interface window.
For example, the user may define a probability function by entering
the function in the use interface window. The probability function
and/or parameters may vary based on a characteristic of the repair,
of the crew, of the outage location, etc. For example, the
probability function may be defined/selected based on the type of
repair to perform at each service outage source location. As
another example, the probability function and/or parameters may be
defined/selected based on analysis of a dataset of actual repair
times based on the type of repair, for example, using a curve
fitting algorithm. Of course, a constant value is a type of
probability distribution.
[0077] In an operation 706, an estimated travel time, T.sub.T, is
identified. For example, a numerical value is received that
indicates a value to be used for T.sub.T between each pair of
service outage source locations. The value(s) of T.sub.T may be
identified by selecting a file where values are stored in
association with each pair of service outage source locations. Of
course, T.sub.T may be defined as a constant value or using a
probability function as discussed with reference to T.sub.R. A
value of T.sub.T may be calculated between each pair of service
outage source locations based on a distance D calculated between
the two locations and a travel speed v using T.sub.T=D/v.
[0078] For example, D may be calculated based on a straight-line
distance using the latitude, longitude, and altitude coordinates of
each pair of service outage source locations as understood by a
person of skill in the art. As another example, a geographic
information system may determine D as a shortest route determined
by traveling on existing roads as understood by a person of skill
in the art. As yet another example, a straight line calculation may
be used that includes a factor based on the curvature of the earth.
The roads used in determining the shortest route may be restricted
based on travel requirements for the crew equipment, based on
current road and weather conditions, etc. For example, if a bridge
is washed out or unable to support the weight of the crew
equipment, the road is not selected as part of the shortest route
determination.
[0079] v may be defined as a function of the type of road(s) to be
traversed to reach each location, as a function of a crew
experience level, as a function of a crew size, as a function of
the crew equipment, as a function of current weather conditions, as
a function of current road conditions, etc. Of course, v may be
defined as a constant value or using a probability function as
discussed with reference to T.sub.R.
[0080] In an operation 708, route assignments are determined. In an
illustrative embodiment, the service route assigned to each
responder of the plurality of responders includes a start location
as a first location and as a last location of the crew such that
the crews are deployed from and return to the same location. Of
course, in alternative embodiments, the last location of the crew
may be a different location than the start location. The start/end
location may be the same or different for each crew. For example,
the start/end location may be defined for each crew in the crew
data or a single start/end location may be defined and entered as
an input by the user using a user interface window and stored in
database 222. Of course, a first group of crews may be assigned a
first start/end location, a second group of crews may be assigned a
second start/end location, etc. The service route for each crew of
the plurality of crews identified in the crew data also includes at
least one location of the plurality of locations defined in the
outage data.
[0081] For example, route assignments may be determined as
described with reference to FIG. 8. FIG. 8 provides additional
example operations associated with service outage planning
application 220. Additional, fewer, or different operations may be
performed depending on the embodiment. The order of presentation of
the operations of FIG. 8 is not intended to be limiting. Although
some of the operational flows are presented in sequence, the
various operations may be performed in various repetitions,
concurrently (in parallel), and/or in other orders than those that
are illustrated.
[0082] In an operation 800, variables are created and initialized
for service outage planning application 220. A service outage
coverage area for which the crew is assigned, the starting time for
the outage metric, and the initial outage information. For example,
a coverage area may include a town, a city, a region, etc. Outage
plans are developed regionally by utility operation centers serving
towns, cities, or geographically bounded zones, which may be
segmented by feeder or substation boundaries.
[0083] In an operation 802, crew shift data is initialized. For
example, a large number of crews may be assigned to work in the
service outage coverage area though different groups of the crews
may be organized into different shifts. Utilities use internal and
external crews to restore power to customers after outages.
Information from each of the crews is collected in terms of the
numbers of hours available to work with consideration for union and
non-union work requirements. Additionally, the skill-set and types
of crews, such as a 2-person crew, a 3-person crew, etc. is
collected for outage planning and optimization. A crew shift model
may be initialized to identify the plurality of crews assigned to
each shift. The time is updated for start of shift, and the crews
are given a starting location. The skills of the crews may be
assigned to each crew.
[0084] In an operation 804, a number of customers restored per a
predefined time period for pairs of locations of the plurality of
locations is calculated based on the number of customers restored
by the repair, the estimated travel time, and the estimated repair
time. For example, the pairs of locations may be selected based on
current locations of the plurality of crews. If all of the crews
are initially located at the same start location, the pairs of
locations include each route from the start location to each other
location of the plurality of locations. The predefined time period
may be a minute, five minutes, ten minutes, twenty minutes, thirty
minutes, forty minutes, fifty minutes, an hour, etc. The predefined
time period may be entered and/or selected by the user using, for
example, a user interface window, may be stored in database 222,
etc. The predefined time period does not change the results. Its
selection is similar to selecting units of measure.
[0085] In an operation 806, a crew is selected from the plurality
of crews currently being assigned routes. If a crew shift is
indicated as complete, a next crew may be selected from the
plurality of crews currently being assigned routes.
[0086] In an operation 808, acceptable next locations are defined
for the selected crew from the pairs of locations identified in
operation 804. As locations are assigned to each crew, the current
crew location is updated. The pairs of locations that do not
include the current crew location may be removed from the
acceptable next locations for the selected crew. Each pair of the
pairs of locations that includes an endpoint location at which the
crew skill indicator for the selected crew does not satisfy the
type of repair to perform at the endpoint location may be removed
from the acceptable next locations for the selected crew.
Additionally, each pair of the pairs of locations that includes an
endpoint location for which a crew has already been assigned or for
which the service has been restored may be removed from the
acceptable next locations for the selected crew.
[0087] Additionally, each pair of the pairs of locations that
includes an endpoint location for which a maximum work time for the
selected crew is exceeded may be removed from the acceptable next
locations. For example, the estimated travel time to the endpoint
location is added to the estimated repair time associated with the
endpoint location. This additional value is added to the current
estimated work time for the selected crew. If this value exceeds
the maximum work time defined for the selected crew, the endpoint
location may be eliminated as an acceptable next location for the
crew. The remaining endpoint locations define acceptable next
locations for the selected crew based on the current location of
the selected crew.
[0088] In an operation 810, a determination is made concerning
whether or not only one next location of the acceptable next
locations is the end location defined for the crew. If only one
next location of the acceptable next locations is the end location
defined for the crew, processing continues in an operation 812. If
more than one next location of the acceptable next locations is the
last location defined for the crew, processing continues in an
operation 814.
[0089] In operation 812, a next location selected for the selected
crew is the end location, and a crew shift is indicated as
complete, for example, by setting a flag value to one or
"true".
[0090] In operation 814, a next location for the selected crew is
selected from the acceptable next locations based on the calculated
number of customers restored per the predefined time period. For
example, the acceptable next locations may be evaluated to
determine which next location maximizes the number of customers
restored per the predefined time period. To determine the next
outage location for a given crew, constraints are considered as
well as the potential number of customers restored while satisfying
the crew's availability to complete restoration and return to the
ending location such as the operations center within the allotted
time the crews are allowed to work. Skill set differentials may
also be considered as to the applicability of the crew to be able
to repair the task at that outage location. In an illustrative
embodiment, the allowable route with the highest number of
customers restored per the predefined time period is selected. In
another illustrative embodiment, the proximity of the destination
to outages requiring a crew skill may be considered. For example,
an optimization may be executed that maximizes the customers
restored per the predefined time period and minimizes the travel
time of skilled crews to outages requiring skilled crews to
essentially look ahead to the next outage for skilled crews.
[0091] In operation 816, a location of the selected crew is updated
as the selected next location. The location represents the current
crew location. Additionally, a shift work time may be updated based
on the estimated repair time for the selected next location and
based on the estimated travel time to the selected next location.
The current estimated work time for the selected crew may be
updated to include these values.
[0092] In an operation 818, a determination is made concerning
whether or not each crew of the plurality of crews for which the
crew shift is indicated as incomplete and for which routes are
being determined has been assigned a next location. If each crew
has been assigned a next location, processing continues in an
operation 520. If each crew has not been assigned a next location,
processing continues in operation 506 to select the next crew from
the plurality of crews.
[0093] In operation 820, a determination is made concerning whether
or not the crew shift is indicated as complete for each crew of the
plurality of crews for which routes are being determined. If the
crew shift is indicated as complete for each crew, processing
continues in an operation 522. If the crew shift is not indicated
as complete for each crew, processing continues in operation 504 to
re-calculate the number of customers restored per the predefined
time period for pairs of locations of the plurality of locations.
For example, the pairs of locations may be selected based on
current locations of the plurality of crews for which the shift is
incomplete. The pairs of locations may include each route from the
current locations of the plurality of crews to each other location
of the plurality of locations. Locations assigned to a crew in
operation 816 may not be included in the pairs of locations because
once a crew location has been assigned, another crew is not sent to
the same location.
[0094] In operation 822, a determination is made concerning whether
or not all of the service outages have been restored. If all of the
service outages have been restored, processing continues in an
operation 710 or in an operation 722. If all of the service outages
have not been restored, processing continues in operation 802 to
re-initialize the crew shift data, for example, with a differently
plurality of crews and/or a different shift start time.
[0095] As another example, route assignments may be determined as
described with reference to FIG. 9. FIG. 9 provides additional
example operations associated with service outage planning
application 220. Additional, fewer, or different operations may be
performed depending on the embodiment. The order of presentation of
the operations of FIG. 9 is not intended to be limiting. Although
some of the operational flows are presented in sequence, the
various operations may be performed in various repetitions,
concurrently (in parallel), and/or in other orders than those that
are illustrated.
[0096] Similar to operation 800, in an operation 900, the service
outage coverage area is initialized. Similar to operation 802, in
an operation 902, crew shift data is initialized. In the
illustrative embodiment of FIG. 9, the crew shift data may not be
defined with a crew skill indicator for one or more of the
plurality of crews.
[0097] Similar to operation 804, in an operation 904, the number of
customers restored per the predefined time period for pairs of
locations of the plurality of locations is calculated based on the
estimated travel time and the estimated repair time. Similar to
operation 806, in an operation 906, a crew is selected from the
plurality of crews currently being assigned routes.
[0098] Similar to operation 808, in an operation 908, acceptable
next locations are defined for the selected crew from the pairs of
locations identified in operation 904. The selected crew may not
have a defined crew skill indicator. If the crew skill indicator is
not defined for the selected crew, endpoint locations may not be
removed based on the comparison between the type of repair to
perform at the endpoint location and the crew skill indicator.
[0099] Similar to operation 810, in an operation 910, a
determination is made concerning whether or not only one next
location of the acceptable next locations is the end location
defined for the crew. If only one next location of the acceptable
next locations is the end location defined for the crew, processing
continues in an operation 912. If more than one next location of
the acceptable next locations is the last location defined for the
crew, processing continues in an operation 914.
[0100] Similar to operation 812, in operation 912, the next
location selected for the selected crew is the end location, and
the crew shift is indicated as complete. Similar to operation 814,
in operation 914, a next location for the selected crew is selected
from the acceptable next locations based on the calculated number
of customers restored per the predefined time period.
[0101] In an operation 916, a determination is made concerning
whether or not the crew skill indicator is defined for the selected
crew. If the crew skill indicator is not defined, processing
continues in an operation 918. If the crew skill indicator is
defined, processing continues in an operation 920. In operation
918, the crew skill indicator is defined for the selected crew
based on the type of repair to perform at the endpoint
location.
[0102] Similar to operation 816, in operation 920, a determination
is made concerning whether or not each crew of the plurality of
crews for which the crew shift is indicated as incomplete and for
which routes are being determined has been assigned a next
location. If each crew has been assigned a next location,
processing continues in an operation 924. If each crew has not been
assigned a next location, processing continues in operation 906 to
select the next crew from the plurality of crews.
[0103] Similar to operation 820, in operation 924, a determination
is made concerning whether or not the crew shift is indicated as
complete for each crew of the plurality of crews for which routes
are being determined. If the crew shift is indicated as complete
for each crew, processing continues in an operation 926. If the
crew shift is not indicated as complete for each crew, processing
continues in operation 604 to re-calculate the number of customers
restored per the predefined time period for pairs of locations of
the plurality of locations.
[0104] Similar to operation 822, in operation 926, a determination
is made concerning whether or not all of the service outages have
been restored. If all of the service outages have been restored,
processing continues in operation 710 or in operation 722. If all
of the service outages have not been restored, processing continues
in operation 902 to re-initialize the crew shift data, for example,
with a differently plurality of crews and/or a different shift
start time.
[0105] With continuing reference to FIG. 7, in operation 710, the
determined route assignments are evaluated and route assignments
selected. For example, the route assignments determined using the
operations described with reference to FIG. 8 or FIG. 9 may be
selected as the route assignments. As another example, the route
assignments determined using the operations described with
reference to FIG. 8 or FIG. 9 may be used as a pre-solution input
to an optimization algorithm to improve an upper bound for a
minimization problem. The solution from the optimization algorithm
may be selected as the route assignments.
[0106] As yet another example, the route assignments determined
after satisfaction of operation 820 of FIG. 8 or after satisfaction
of operation 924 of FIG. 9 may be used as a pre-solution input to
an optimization algorithm to improve an upper bound for a
minimization problem. The solution from the optimization algorithm
may be selected as the route assignments and remaining outages
assigned in an additional execution of the operations of FIG. 8 or
FIG. 9 for a next crew shift. For example, routes may be defined
for the same plurality of crews for a second day or after a minimum
rest for the plurality of crews has passed.
[0107] As another example, routes may be defined for a second
plurality of crews that is working a next shift. The second
plurality of crews may differ from the initial plurality of crews
by one or more crews.
[0108] As still another example, the route assignments determined
after satisfaction of operation 822 of FIG. 8 or after satisfaction
of operation 926 of FIG. 9 may be used as a pre-solution input to
an optimization algorithm to improve an upper bound for a
minimization problem. This ensures the heuristic solution as an
upper bound to customer outage time meaning the optimization can
only improve the results. Optimization time is reduced by providing
a pre-solution.
[0109] As an example optimization algorithm, a mixed integer linear
program (MILP) may be used to minimize a total customer time
without the service. As an example, SAS.RTM.OR includes an OPTMODEL
procedure that provides a framework for specifying and solving a
MILP. The MILP solver, available in the OPTMODEL procedure,
implements a linear program-based branch-and-bound algorithm that
solves the original problem by solving linear programming
relaxations of a sequence of smaller subproblems.
[0110] For illustration, route assignments may be determined by
minimizing
.SIGMA. j .di-elect cons. N t j C j subject to .SIGMA. v .di-elect
cons. V .SIGMA. j .di-elect cons. N x ijv .ltoreq. 1 , .A-inverted.
i .di-elect cons. N , i .noteq. n 0 ( 1 ) .SIGMA. j .di-elect cons.
N x n 0 jv .ltoreq. 1 , .A-inverted. v .di-elect cons. V , j
.noteq. n 0 ( 2 ) .SIGMA. i .di-elect cons. N x ijv - .SIGMA. i
.di-elect cons. N x jiv = 0 , .A-inverted. j .di-elect cons. N ,
.A-inverted. v .di-elect cons. V ( 3 ) x iiv = 0 , .A-inverted. i
.di-elect cons. N , .A-inverted. v .di-elect cons. V ( 4 ) rS js x
ijv .ltoreq. vS vs , .A-inverted. i .di-elect cons. N ,
.A-inverted. j .di-elect cons. N , .A-inverted. v .di-elect cons. V
, .A-inverted. s .di-elect cons. S , j .noteq. n 0 ( 5 ) t n 0 = 0
( 6 ) t i .gtoreq. 0 , .A-inverted. i .di-elect cons. N ( 7 ) Sh n
0 v .ltoreq. MaxSh v , .A-inverted. v .di-elect cons. V ( 8 ) t i +
T Tij + T R j - t j .ltoreq. P ( 1 - x ijv ) , .A-inverted. i
.di-elect cons. N , .A-inverted. j .di-elect cons. N , .A-inverted.
v .di-elect cons. V , j .noteq. n 0 ( 9 ) t i + T T in 0 - Sh n 0 v
.ltoreq. P ( 1 - x in 0 v ) , .A-inverted. i .di-elect cons. N ,
.A-inverted. v .di-elect cons. V ( 10 ) .SIGMA. v .di-elect cons. V
.SIGMA. i .di-elect cons. N x ijv .gtoreq. 1 - t j P , .A-inverted.
j .di-elect cons. N , j .noteq. n 0 ( 11 ) ##EQU00001##
[0111] where t.sub.n.sub.0 is a start time; N is a number of the
service outage source locations; V is the number of crews;
j=n.sub.0 is the start/end location; t.sub.i is a time elapsed
until service outage source location j is restored; C.sub.j is the
number of affected customers associated with service outage source
location j; x.sub.ijv=1 if the equipment of crew v travels from
service outage source location i to service outage source location
j, otherwise x.sub.ijv=0; rS.sub.js=1 if skill S is needed to
repair service outage source location j otherwise rS.sub.js=0;
vS.sub.vs=1 if the equipment/crew of crew v has skill s, otherwise
vS.sub.vs=0; Sh.sub.n.sub.0.sub.v is a total time for the shift of
crew v, T.sub.Tij is the travel time between service outage source
location i and service outage source location j, T.sub.R.sub.j is
the repair time for service outage source location j, MaxSh.sub.v
is a maximum shift time for crew v, and P is a time penalty for
service outage source locations that are not serviced.
[0112] If a customer is not served in the expected location, the
cumulative outage time continues until that customer is restored.
As a result, P may be zero for those customers since the cumulative
outage time acts effectively as a penalty in the optimization.
Conversely, a utility can assess a penalty for not restoring power
to specific types of customers or even specific customers. For
example, restoration of the service may be more critical for some
customers than others. As examples, P may be greater than zero for
customers like banks, prisons, hospitals, etc. for which
restoration should be performed as a higher priority. The value of
P may increase as the priority for restoration of the customer
increases relative to other customers. P may be defined for each
service outage source location.
[0113] Constraint (1) ensures that each service outage source
location is visited at most one time. Constraint (2) ensures the
crew equipment, such as the vehicle, travels at most one route.
Constraint (3) ensures the start/end location for each crew is the
same. Constraint (4) ensures the crew equipment, such as the
vehicle, does not travel to itself. Constraint (5) ensures the crew
equipment type indicator and/or crew skill indicator satisfies the
type of service to perform at each location. If crew v travels to
service outage source location j, crew v has the needed skills to
perform the service needed at service outage source location j.
Constraint (6) sets the start time at zero. Constraint (7) ensures
the elapsed time is positive. Constraint (8) ensures the crews work
within their shift time constraints. For example, constraint (8)
ensures that crews do not work "overtime". Constraints (9) and (10)
ensure t.sub.i is the elapsed time. Constraint (11) imposes a time
penalty for service outage source locations that are not serviced.
A greater or a fewer number of constraints may be applied in the
minimization.
[0114] A genetic algorithm optimization or other stochastic or
evolutionary optimization methods could be used. Additional
algorithms may also be used including: adding tree crews for outage
pre-work optimization to expedite power restoration and
incorporating transformer delivery and drop-off and total daily
outage restoration for safety tag-out procedures. A utility may
determine a maximum number of outages that the utility can address
in a day and flag these areas in their distribution system. A
safety tag-out is added to the distribution system signaling that
power is not flowing into the system and the crews can make repairs
in a safe fashion. If this is not done, the crews could be
electrocuted if power was still flowing in the areas to be
repaired.
[0115] In an operation 712, the determined route assignments are
output. For example, the determined route assignments are stored to
computer-readable medium 206/database 222. In addition or in the
alternative, the determined route assignments are presented in
display 214, for example, using SAS.RTM.VA. In addition or in the
alternative, the determined route assignment for each crew is sent
to the associated service outage planning system 102 using fourth
communication interface 506 and communication interface 204. In
addition or in the alternative, the determined route assignments
are printed using printer 218 and delivered to each crew. Service
restoration time estimates may be determined based on the route
assignments, estimated travel time between service outage
locations, and estimated repair time for each service outage
location.
[0116] In an operation 714, a determination is made concerning
whether or not updated crew data, updated outage data, updated
repair time data, and/or updated travel time data is received or
identified. For example, additional service outage source locations
may be reported, service outage source locations may be identified
as completed with a shorter or a longer repair time than estimated,
roads may be reopened, etc. Updated crew data may be received from
service outage planning system 102 using communication interface
204 and fourth communication interface 506. If updated data is
received, processing continues in an operation 716. If updated data
is not received, processing continues in operation 714 to await
receipt of updated data.
[0117] In operation 716, the appropriate data is updated. For
example, actual repair times are defined for service outage source
locations when the repair is completed. A remaining plurality of
service outage source locations may be determined based on the
updated data. A current crew location for each crew of the
plurality of crews may be determined from the updated data.
[0118] In an operation 718, the estimated travel time, T.sub.T,
identified in operation 706 may be updated.
[0119] Similar to operation 708, in an operation 720, updated route
assignments are determined. For example, a revised route for each
crew is determined using the updated data and the operations of
FIG. 8 or FIG. 9. The revised service route may be defined from the
current crew location for each crew of the plurality of crews. The
plurality of crews available to reroute may change based on
additional crews becoming available to work. The updated route
assignments may be determined when requested by a user,
periodically, when a predefined number of updates is received,
etc.
[0120] Similar to operation 710, in operation 722, the updated
route assignments are selected from the determined updated route
assignments. Similar to operation 708, in an operation 724, the
updated route assignments are output. In an operation 726, the
updated route assignments are sent to each crew. For example, the
revised route may be sent to a deployed crew using fourth
communication interface 506 and communication interface 204 if the
revised route assignment is different than the currently assigned
route. Processing continues in operation 714 to await receipt of
updated data.
[0121] The word "illustrative" is used herein to mean serving as an
example, instance, or illustration. Any aspect or design described
herein as "illustrative" is not necessarily to be construed as
preferred or advantageous over other aspects or designs. Further,
for the purposes of this disclosure and unless otherwise specified,
"a" or "an" means "one or more". Still further, using "and" or "or"
is intended to include "and/or" unless specifically indicated
otherwise. The illustrative embodiments may be implemented as a
method, apparatus, or article of manufacture using standard
programming and/or engineering techniques to produce software,
firmware, hardware, or any combination thereof to control a
computer to implement the disclosed embodiments.
[0122] The foregoing description of illustrative embodiments of the
disclosed subject matter has been presented for purposes of
illustration and of description. It is not intended to be
exhaustive or to limit the disclosed subject matter to the precise
form disclosed, and modifications and variations are possible in
light of the above teachings or may be acquired from practice of
the disclosed subject matter. The embodiments were chosen and
described in order to explain the principles of the disclosed
subject matter and as practical applications of the disclosed
subject matter to enable one skilled in the art to utilize the
disclosed subject matter in various embodiments and with various
modifications as suited to the particular use contemplated. It is
intended that the scope of the disclosed subject matter be defined
by the claims appended hereto and their equivalents.
* * * * *