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.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority under 35 U.S.C. §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

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

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.

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.

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.

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

Illustrative embodiments of the disclosed subject matter will hereafter be described referring to the accompanying drawings, wherein like numerals denote like elements.

FIG. 1 depicts a block diagram of a storm response system in accordance with an illustrative embodiment.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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®OR, SAS®VA, SAS®EM, SAS®EG, SAS®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.

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.

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.

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.

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.

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.

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.

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® Enterprise Guide® for Data Mining via Rapid Predictive Modeler or other techniques. Results from the advanced modeling may be stored and automatically brought into SAS® 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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® Text Miner tool and incorporated into the SAS® Enterprise Miner tool with other outage data.

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.

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.

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.

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.

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.

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.

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.

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.

In an operation 704, an estimated repair time, T_R, is identified. For example, a numerical value is received that indicates a user selection of the value to be used for T_R. T_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_R may be identified, a value may be identified for each service outage source location, for each crew, etc. As an example, T_R may be determined for each service outage source location and stored with the outage data.

The value of T_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_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_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.

In an illustrative embodiment, an estimated repair time, T_R, is determined statistically using a probability function. The probability function and parameters associated with defining the probability distribution for T_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.

In an operation 706, an estimated travel time, T_T, is identified. For example, a numerical value is received that indicates a value to be used for T_T between each pair of service outage source locations. The value(s) of T_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_T may be defined as a constant value or using a probability function as discussed with reference to T_R. A value of T_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_T=D/v.

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.

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_R.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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”.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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®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.

For illustration, route assignments may be determined by minimizing

$\begin{array}{cc}{\Sigma }_{j\in N}t_jC_j\mathrm{subject}\mathrm{to}{\Sigma }_{v\in V}{\Sigma }_{j\in N}x_{\mathrm{ijv}}\le 1,{\forall }_i\in N,i\ne n_0& \left(1\right)\\ {\Sigma }_{j\in N}x_{n_0\mathrm{jv}}\le 1,{\forall }_v\in V,j\ne n_0& \left(2\right)\\ {\Sigma }_{i\in N}x_{\mathrm{ijv}}-{\Sigma }_{i\in N}x_{\mathrm{jiv}}=0,{\forall }_j\in N,{\forall }_v\in V& \left(3\right)\\ x_{\mathrm{iiv}}=0,{\forall }_i\in N,{\forall }_v\in V& \left(4\right)\\ {\mathrm{rS}}_{\mathrm{js}}x_{\mathrm{ijv}}\le {\mathrm{vS}}_{\mathrm{vs}},{\forall }_i\in N,{\forall }_j\in N,{\forall }_v\in V,{\forall }_s\in S,j\ne n_0& \left(5\right)\\ t_{n_0}=0& \left(6\right)\\ t_i\ge 0,{\forall }_i\in N& \left(7\right)\\ {\mathrm{Sh}}_{n_0v}\le {\mathrm{MaxSh}}_v,{\forall }_v\in V& \left(8\right)\\ t_i+T_{\mathrm{Tij}}+T_{R_j}-t_j\le P\left(1-x_{\mathrm{ijv}}\right),{\forall }_i\in N,{\forall }_j\in N,{\forall }_v\in V,j\ne n_0& \left(9\right)\\ t_i+T_{T_{{\mathrm{in}}_0}}-{\mathrm{Sh}}_{n_0v}\le P\left(1-x_{{\mathrm{in}}_0v}\right),{\forall }_i\in N,{\forall }_v\in V& \left(10\right)\\ {\Sigma }_{v\in V}{\Sigma }_{i\in N}x_{\mathrm{ijv}}\ge 1-\frac{t_j}{P},{\forall }_j\in N,j\ne n_0& \left(11\right)\end{array}$

where t_n0 is a start time; N is a number of the service outage source locations; V is the number of crews; j=n₀ is the start/end location; t_i is a time elapsed until service outage source location j is restored; C_j is the number of affected customers associated with service outage source location j; x_ijv=1 if the equipment of crew v travels from service outage source location i to service outage source location j, otherwise x_ijv=0; rS_js=1 if skill S is needed to repair service outage source location j otherwise rS_js=0; vS_vs=1 if the equipment/crew of crew v has skill s, otherwise vS_vs=0; Sh_n0v is a total time for the shift of crew v, T_Tij is the travel time between service outage source location i and service outage source location j, T_Rj is the repair time for service outage source location j, MaxSh_v is a maximum shift time for crew v, and P is a time penalty for service outage source locations that are not serviced.

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.

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_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.

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.

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®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.

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.

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.

In an operation 718, the estimated travel time, T_T, identified in operation 706 may be updated.

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.

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.

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.

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.

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.