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.