Understanding Storm Management Calculations
Storm Management enables you to analyze restoration times during high volume outage periods, such as those that occur during and following ice storms, thunderstorms, hurricanes, and other widespread disturbances. It can provide estimated assessment and restoration times for every outage in the system. It calculates estimates by periodically simulating the entire restoration process, taking into account the dynamically changing outage predictions and crew resource allocation. These restoration estimates can be used to manage workloads and prioritize crew assignments.
This section provides a detailed explanation of the algorithms and data Storm Management uses to create estimates. It includes the following topics:
How Storm Management Works
Storm Management has two basic modes of operation – non-storm and storm mode. The estimate calculation algorithm for each mode is fundamentally the same. For example, both modes use historical averages and simulated restoration calculation/analysis of all unrestored events in the system for the estimate calculation algorithm. However, non-storm mode does not attempt to make crew backlog calculations, making its analysis much simpler.
Historical Averages
The estimate calculation algorithm uses the following historical average minutes data that applies to the different parts of the restoration process:
• Average travel time for an assessment crew: how long it takes a crew that is going out to assess the event to arrive onsite, once en route.
• Average assessment time: how long it takes a crew to assess the event, once onsite.
• Average travel time for a repair crew: how long it takes a crew that is going out to repair the event to arrive onsite, once en route.
• Average repair time: how long it takes a crew to repair/restore the event, once onsite.
• Average cleanup time: how long it takes before a crew is ready to move on to their next assignment, once the repair/restoration is complete.
The historical average minutes can be broken down by various factors for further granularity of data:
• Control Zone. The area the event is in (for example, urban versus rural) may have an affect on how long it takes crews to arrive, and thus you may use different travel times for different control zones.
Note: One of the levels in the control zone hierarchy is designated as the control zone level at which the historical average minutes data is associated. This control zone level is herein referred to as the simulation level. For example, if the second level in the control zone hierarchy – the Region level – was the designated simulation level, that would imply that each region would have its own, possibly unique, set of historical average minutes.
• Outage Type. The type of outage (for example, service outages, breaker lockouts, and so on) dictates how long it is going to take for repair/restoration, so, consequently, you may use different repair/restore times for different types of outages.
• Shift. The time of day (for example, afternoon rush hour versus middle of the night) may have an affect on how long it takes crews to arrive, and/or perform the assessment or repair/restoration, and, therefore, you may use different travel, assessment, and repair/restore times for different shifts.
• Day Type. The type of day (weekday versus weekend versus holiday) may have an affect on how long it takes crews to arrive, and thus you may use different travel times for different day types.
• Season. The time of year (for example, winter versus summer) may have an affect on how long it takes crews to arrive, and/or perform the assessment or repair/restoration, and thus you may use different travel, assessment, and repair/restore times for seasons.
• Storm Type. Particular weather conditions (for example, ice) may have an affect on how long it takes crews to arrive, and/or perform the assessment or repair/restoration, and thus you may use different travel, assessment, and repair/restore times for different types of storms.
Simulation
To generate estimates, the trouble analysis engine periodically goes through a simulated restoration calculation/analysis of all unrestored events in the system. Any events eligible to be assigned an estimated assessment and restoration time by Storm Management (that is, the events are of a type that Storm Management is configured to recognize, and they have not been given a manually-entered estimated restoration time from a crew/dispatcher) are sorted in priority order (part of the Storm Management configuration). Then, starting at the top of that list, the simulation begins. The event at the top of the list is examined. The mode of operation that the control zone in which the event resides is checked in order to determine which version of the algorithm is being applied to calculate the Estimated Restoration Time (ERT). The appropriate set of historical average minutes for the event is looked up, using the various characteristics such as control zone, outage type, storm type, and when the assessment and repair/restoration is projected to begin. Those historical averages are then used by the calculation of the appropriate algorithm to generate an estimated assessment time and estimated restoration time for the event.
The raw ERT value generated by the simulated restoration calculation can be further refined before becoming event's estimated restoration time.
If configuration rule ‘ertAggregationPolicy' is set to LATEST, then all events estimated by Storm Management of the same type and at or under the same control zone at the aggregation level, are given the same ERT. That ERT is the latest Storm Management calculated ERT among these events. After aggregation, if configuration rule ‘stormmanEstimateRounding' is enabled, the ERT value can be rounded.
Once an event has been given its estimates by the Storm Management simulation, it is removed from that priority-sorted list, and then the next event on the list is analyzed in the same manner, and the process continues until the last event on the list is removed. When the next simulation period occurs, the process starts over again. And when it does, the previously calculated estimates for many events may change, due to factors such as some previously unrestored events now being restored, new events of varying priority appearing, crews arriving onsite at various events, some events being given manually-entered estimated restoration times, no crew yet arriving onsite, or to various parameters on the Storm Management window being modified since the last iteration.
Storm Management Window
Because the engine that generates the estimated assessment and restoration times for each event is a separate process, you do not need to have a Storm Management window open in order for the estimates to be calculated. The main purpose of the Storm Management window is to enable you to monitor and analyze the estimates from overall control zone perspective, and to manipulate several of the parameters that are used to generate the estimates.
Given that it's not required to have a Storm Management window open to generate the estimates, after each periodic calculation of the estimates, the results are not pushed out to the Storm Management windows by the engine. Instead, each Storm Management window that's open has its own timer that it uses to periodically retrieve the latest information from the engine automatically.
Non-Storm Mode Algorithm
For an event that resides in a control zone that is operating under non-storm mode, the calculation of its estimated assessment and estimated restoration times is as follows:
• Look up the historical average values that pertain to an event with its characteristics.
• Verify whether or not an assessment has already been made for the event (if JOBS.ACT_ASSESS_TIME is non-null).
If assessment has been made:
• The repair time assessment provided (JOBS.EST_REPAIR_MINUTES) will be used in the calculation rather than the historical Repair average.
• Verify whether or not a crew is currently onsite for this event.
• If a crew is onsite:
• Check the crew type to verify whether or not this type of crew is one that can repair this event.
• If crew can repair:
• It is assumed that the crew that's onsite is there to perform the repair. The historical Travel to Repair average will not be used in the calculation. The actual repair time assessment (JOBS.EST_REPAIR_MINUTES) is added to the time at which the crew arrived onsite to generate the estimated restoration time (ERT) for the event.
• If crew cannot repair:
• It is assumed that the onsite crew is there to perform the assessment, and another crew must be sent out to perform the repair. The historical Travel to Repair average and the actual repair time assessment are added to the time at which the repair time assessment was provided (JOBS.ACT_ASSESS_TIME) to generate the estimated restoration time (ERT) for the event.
• If a crew is not onsite:
• The historical Travel to Repair average and the actual repair time assessment are added to the time at which the repair time assessment was provided (JOBS.ACT_ASSESS_TIME) to generate the estimated restoration time (ERT) for the event.
If no assessment has yet been made:
• Verify whether or not a crew is currently onsite for this event.
• If a crew is onsite:
• Check the crew type to verify whether or not this type of crew is one that can both assess and repair this event.
• If the crew type cannot perform both tasks:
• Verify if the crew type can repair this event.
• If crew can repair:
• It is assumed that the crew that's onsite is there to perform the repair. The historical Travel to Repair average will not be used in the calculation. The historical Repair average is added to the time at which the crew arrived onsite to generate the estimated restoration time (ERT) for the event.
• If crew cannot repair:
• It is assumed that the crew that's onsite is there to perform the assessment. The historical Assess average is added to the time at which the crew arrived onsite to generate the estimated Assessment time (EAT). The historical Travel to Repair and historical Repair averages are added to the estimated Assessment time to generate the estimated restoration time (ERT) for the event.
• If crew type can perform both tasks:
• Verify whether or not assessment is required for this event (if Travel to Assess and Assess averages are both 0, assessment is not required).
• If assessment is not required:
• It is assumed that the crew that's onsite is there to perform the repair. The historical Travel to Repair average will not be used in the calculation. The historical Repair average is added to the time at which the crew arrived onsite to generate the estimated restoration time (ERT) for the event.
• If assessment is required:
• It is assumed that the crew that's onsite is there to perform the assessment. The historical Assess average is added to the time at which the crew arrived onsite to generate the estimated assessment time (EAT). The historical Travel to Repair and historical Repair averages are added to the estimated assessment time to generate the estimated restoration time (ERT) for the event.
• If a crew is not onsite:
• Verify whether or not assessment is required for this event (if Travel to Assess and Assess averages are both 0, assessment is not required).
• If assessment is not required:
• No estimated assessment time (EAT) needs to be calculated. This historical Travel to Repair and historical Repair averages are added to the simulation to generate the estimated restoration time (ERT) for the event.
• If assessment is required:
• The historical Travel to Assess and historical Assess averages are added to the simulation to generate the estimated assessment time (EAT) for the event. The historical Travel to Repair and historical Repair averages are added to the estimated assessment time to generate the estimated restoration time (ERT) for the event.
Non-Storm Mode Algorithm Flow Chart
In summary, for an event that's in a control zone operating under non-storm mode:
• Estimated assessment time equals:
• The simulation iteration start time.
plus (+)
• The historical average number of minutes it takes an assessment crew to arrive onsite.
plus (+)
• The historical average number of minutes it takes a crew to perform assessment once onsite.
• Estimated restoration time equals:
• The estimated assessment time.
plus (+)+
• The historical average number of minutes it takes a repair crew to arrive onsite.
plus (+)
• The historical average number of minutes it takes a crew to repair once onsite.
Exceptions:
If a crew that can perform assessment is already onsite:
• Estimated assessment time equals:
• The time at which the assessment crew arrived onsite
plus (+)
• The historical average number of minutes it takes a crew to perform assessment once onsite.
If an event has an actual assessment provided and no repair crew is yet onsite:
• Estimated restoration time equals:
• The time at which the actual assessment was provided +
• the historical average number of minutes it takes a repair crew to arrive onsite +
• the actual number of minutes it will take to repair, per the assessment
If an event has an actual assessment provided and a repair crew is already onsite:
• Estimated restoration time equals:
• The time at which the repair crew arrived onsite.
plus (+)
• The actual number of minutes it will take to repair, per the assessment.
If an event does not require assessment and no repair crew is yet onsite:
• Estimated restoration time equals:
• The time the simulation iteration started.
plus (+)
• The historical average number of minutes it takes a repair crew to arrive onsite.
plus (+)
• The historical average number of minutes it takes a crew to repair once onsite.
Note: When the historical averages are applied to the calculation, the average that applies to the conditions at the time the particular step is projected to begin is used, not the average that applies to the conditions at the time the simulation iteration began. For example, Shift A has a particular average value for repair, and Shift B has a different average value for repair. The simulation iteration is in Shift A, but the calculated estimated assessment time falls in Shift B. When calculating the estimated restoration time, the historical average value for repair that pertains to Shift B will be used, not that of Shift A, because the repair isn't projected to begin until sometime during Shift B.
Storm Mode Algorithm
The algorithm for estimate calculation in storm mode is similar to that of non-storm mode, except that in storm mode the data entered into the Crew Information table on the Storm Management window is taken into consideration and used as the known crew resource allocation. At the start of each simulation, the algorithm assembles a crew availability list from the Crew Information table and uses that to keep track of when the next available crews are projected to be ready as the calculation progresses.
For an event that resides in a control zone that is operating under storm mode, the calculation of its estimated assessment and estimated restoration times is as follows:
• Look up the historical average values that pertain to an event with its characteristics
• Verify whether or not an assessment has already been made for the event (if JOBS.ACT_ASSESS_TIME is non-null)
If assessment has been made:
• The repair time assessment provided (JOBS.EST_REPAIR_MINUTES) will be used in the calculation rather than the historical Repair average
• Verify whether or not a crew is currently onsite for this event
• If a crew is onsite:
• Check the crew type to verify whether or not this type of crew is one that can repair this event
• If crew can repair:
• It is assumed that the crew that's onsite is there to perform the repair. The historical Travel to Repair average will not be used in the calculation. The actual repair time assessment (JOBS.EST_REPAIR_MINUTES) is added to the time at which the crew arrived onsite to generate the estimated restoration time (ERT) for the event
• If crew cannot repair:
• It is assumed that the onsite crew is there to perform the assessment, and another crew must be sent out to perform the repair. The historical Travel to Repair average and the actual repair time assessment are added to the time at which the first crew that is eligible to repair this event will become available to generate the estimated restoration time (ERT) for the event
• If a crew is not onsite:
• The historical Travel to Repair average and the actual repair time assessment are added to the time at which the first crew that is eligible to repair this event will become available to generate the estimated restoration time (ERT) for the event. The historical Clean average is added to the ERT and used as the time at which that eligible crew is available to be used for another event in the simulation.
If no assessment has yet been made:
• Verify whether or not a crew is currently onsite for this event
• If a crew is onsite:
• Check the crew type to verify whether or not this type of crew is one that can both assess and repair this event
• If the crew type cannot perform both tasks:
• Verify if the crew type can repair this event
• If crew can repair:
• It is assumed that the crew that's onsite is there to perform the repair. The historical Travel to Repair average will not be used in the calculation. The historical Repair average is added to the time at which the crew arrived onsite to generate the estimated restoration time (ERT) for the event
• If crew cannot repair:
• It is assumed that the crew that's onsite is there to perform the assessment. The historical Assess average is added to the time at which the crew arrived onsite to generate the estimated assessment time (EAT). The historical Travel to Repair and historical Repair averages are added to the time at which the first crew that is eligible to repair this event will become available to generate the estimated restoration time (ERT) for the event. The historical Clean average is added to the ERT and used as the time at which that eligible crew is available to be used for another event in the simulation.
• If crew type can perform both tasks:
• Verify whether or not assessment is required for this event (if Travel to Assess and Assess averages are both 0, assessment is not required)
• If assessment is not required:
• It is assumed that the crew that's onsite is there to perform the repair. The historical Travel to Repair average will not be used in the calculation. The historical Repair average is added to the time at which the crew arrived onsite to generate the estimated restoration time (ERT) for the event
• If assessment is required:
• It is assumed that the crew that's onsite is there to perform the assessment. The historical Assess average is added to the time at which the crew arrived onsite to generate the estimated assessment time (EAT). The historical Travel to Repair and historical Repair averages are added to time at which the first crew that is eligible to repair this event will become available to generate the estimated restoration time (ERT) for the event
• If a crew is not onsite:
• Verify whether or not assessment is required for this event (if Travel to Assess and Assess averages are both 0, assessment is not required)
• If assessment is not required:
• No estimated assessment time (EAT) needs to be calculated. The historical Travel to Repair and historical Repair averages are added to the time at which the first crew that is eligible to repair this event will become available to generate the estimated restoration time (ERT) for the event. The historical Clean average is added to the ERT and used as the time at which that eligible crew is available to be used for another event in the simulation.
• If assessment is required:
• The historical Travel to Assess and historical Assess averages are added to the time at which the first crew that is eligible to assess this event will become available to generate the estimated assessment time (EAT) for the event. The EAT is used as the time at which that eligible assessment crew is available to be used for another event in the simulation. The historical Travel to Repair and historical Repair averages are added to the time at which the first crew that is eligible to repair this event will become available to generate the estimated restoration time (ERT) for the event. The historical Clean average is added to the ERT and used as the time at which that eligible repair crew is available to be used for another event in the simulation.
Storm Mode Algorithm Flow Chart
The yellow boxes indicate where the storm mode algorithm differs from the non-storm mode algorithm.
In summary, for an event that's in a control zone operating under storm mode:
• Estimated assessment time equals:
• The time the first crew that is eligible to assess the event will become available.
plus (+)
• The historical average number of minutes it takes an assessment crew to arrive onsite.
plus (+)
• The historical average number of minutes it takes a crew to perform assessment once onsite.
• Estimated restoration time equals:
• The time at which the first crew that's eligible to repair the event will become available after the estimated assessment time.
plus (+)
• The historical average number of minutes it takes a repair crew to arrive onsite.
plus (+)
• The historical average number of minutes it takes a crew to repair once onsite.
Exceptions:
If a crew that can perform assessment is already onsite:
• Estimated assessment time equals:
• The time at which the assessment crew arrived onsite.
plus (+)
• The historical average number of minutes it takes a crew to perform assessment once onsite.
If an event has an actual assessment provided and no repair crew is yet onsite:
• Estimated restoration time equals:
• The time at which the first crew that's eligible to repair the event will become available after the actual assessment time
plus (+)
• The historical average number of minutes it takes a repair crew to arrive onsite.
plus (+)
• The actual number of minutes it will take to repair, per the assessment.
If an event has an actual assessment provided and a repair crew is already onsite.
• Estimated restoration time equals:
• The time at which the repair crew arrived onsite.
plus (+)
• The actual number of minutes it will take to repair, per the assessment .
If an event does not require assessment and no repair crew is yet onsite:
• Estimated restoration time equals:
• The time at which the first crew that's eligible to repair the event will become available after the time at which the simulation iteration started.
plus (+)
• The historical average number of minutes it takes a repair crew to arrive onsite.
plus (+)
• The historical average number of minutes it takes a crew to repair once onsite.
Notes:
• When the historical averages are applied to the calculation, the average that applies to the conditions at the time the particular step is projected to begin is used, not the average that applies to the conditions at the time the simulation iteration began. For example, Shift A has a particular average value for repair, and Shift B has a different average value for repair. The simulation iteration is in Shift A, but the calculated estimated assessment time falls in Shift B. When calculating the estimated restoration time, the historical average value for repair that pertains to Shift B will be used, not that of Shift A, because the repair isn't projected to begin until sometime during Shift B.
• If the algorithm finds that the calculated estimated assessment time or estimated restoration time would fall beyond the end of the shift of the first eligible crew by more than 60 minutes, it will go back and recalculate the estimate using a different crew other than the one that was originally chosen. The algorithm cannot split work for a single event between multiple shifts of the same crew or between multiple crews. As a consequence, if amount of work required for an event is more than the longest available shift of any crew capable of performing the work then the algorithm will not be able to provide a meaningful ERT for the event. At this point, the algorithm will use "default nominal crew" as a fall back mechanism in order to proceed. This is an artificial crew that can perform any work and not limited by shift restrictions. ERTs generated through use of "default nominal crew" are of no practical value and a warning is written into JMService log file each time this occurs.