Prediction Engine

The Responder Prediction Engine uses outage information to determine the potential source of an outage and consolidates downstream unconfirmed incidents as appropriate. Incidents are consolidated to an upstream device (or rolled up) according to the configuration settings determined by an administrator in the Miner.Responder.PredictionServices.exe.config file. A fault device may have one of three confirmation statuses:

Unconfirmed: All devices have a default status of Unconfirmed. The Prediction Engine predicts only on unconfirmed outages.
Probable: An Unconfirmed device is escalated to Probable after a set amount of time (configurable). Prediction does not consider Probable devices. The Prediction Engine assumes that the user set the incident's status to Confirmed or Probable purposely and does not modify that setting.
Confirmed: A device receives a status of Confirmed only if the dispatcher sets the field. The Prediction Engine does not consider Confirmed incidents when rolling up incidents.

The Prediction Engine impacts outages in two ways. It escalates Unconfirmed devices to Probable status and rolls up incidents based on the thresholds set in the configuration file.

Probable

During configuration an administrator determines the amount of time before incidents are assigned a Probable status. Once this time has expired (e.g., 15 minutes), the incident is assigned a status of Probable. Note that devices with a Probable status are not considered by the Prediction Engine for roll-up. However, a manual incident (created by a Dispatcher) will roll-up downstream Probable incidents.

There are two settings in the Miner.Responder.PredictionServices.exe.config file that determine when an incident is elevated to a Probable status.

probableStateCandidateElevationTime: This value (in minutes) determines the amount of time after which an Unconfirmed incident may be elevated to Probable.
probableStatePollingFrequency: This value (in minutes) determines the frequency at which the Prediction Engine looks for Unconfirmed incidents whose probableStateCandidateElevationTime value has expired. Any unconfirmed incidents with this value expired are elevated to Probable status.

Roll-Up

The Prediction Engine evaluates incidents, predicts which device may be out, and rolls all unconfirmed incidents upstream to the predicted outage device.

For example, an incident is created, either manually by the dispatcher or automatically by the Prediction Engine as it processes a customer call:

Additional outages occur in the same neighborhood:

Eventually the number of customers with incidents exceeds a percentage set by the administrator during configuration. At this point, the Prediction Engine predicts that the common transformer is most likely malfunctioning. An incident is created on the transformer and the individual incidents previously created for the service points are rolled into one. Any customer call records associated with the previous service point incidents are also rolled into the new incident.

When multiple incidents are rolled-up into a single incident, the Owner field on the new incident is set to <Unassigned>. The exception is when the individual incidents have the same owner. Then that owner is assigned to the rolled up incident.

This concept does not apply just to service points and customer calls. When the incident rolls up to the transformer, additional transformers may be experiencing problems on the same feeder. Responder's Prediction Engine evaluates the outages on all devices and locates a common upstream device when the outage percentage (set by the administrator) for downstream devices is exceeded. In the example below, two of the transformers had unconfirmed incidents, so the incident rolled up to the fuse. The third incident was confirmed. Therefore, Prediction did not roll it into the incident on the fuse.

Prediction and Tags: Prediction will not roll up an incident to a device that has a tag. The user will also not be able to consolidate to a device that has a tag. The following error indicates that a tag on the device is preventing Prediction from rolling up to it.

Prediction on Multiple Levels: Prediction can roll up incidents all the way to the breaker. However, Prediction has been engineered to ensure devices are predicted upon only if there exists a strong likelihood that device is out.

Consider, for example, a fuse that has two transformers. XFR1 has five service points and XFR2 has two service points. If four out of the five service points on XFR1 call in to report outages, the incident is rolled up to XFR1. If Prediction considered only the child transformers when evaluating the fuse, it might roll the incident up to the fuse. Instead, Prediction considers the load points as well. Since the outage load points are all under a single transformer, the incident remains on the transformer and is not rolled up to the fuse.

Prediction considers that the second transformer has no reported load points out and does not roll the incident up to the fuse.

Responder does not predict on non-protective devices (e.g., switches). Incidents may be placed on them, however.
Responder will not predict to a device that does not have the FDRMGRPROTECTIVE or TRANSFORMER model name.
Responder prediction does not currently support loop or multifeed situations.

Past Calls and Confirmed Restored Devices:

Assume the case that a confirmed incident (transformer) is cancelled downstream of a confirmed restored device. The cancelled incident has calls assigned, which the user elects to reassign when prompted. These past calls cannot be assigned to the fuse as their received date/time is before the outage time on the fuse. In this case, new single premise incidents will be created for the reassigned past calls. The Prediction Engine will not predict on these new incidents to the upstream confirmed restored device unless new calls are received.

Enhanced Prediction Engine

At 10.2.1c, Responder prediction was enhanced to change how processing is performed. Rather than using the previous ‘call stewing’ logic that involved waiting a configurable amount of time before processing calls, all calls that come into the Responder database are immediately eligible for processing. Each Prediction Service operates on a thread that looks for new calls after a configurable wait time (callStewPollingFrequency="00:00:20" is the setting, making this default to 20 seconds). Any call that is selected for processing is first analyzed to see if it can be subsumed by an existing incident or used as part of a Prediction with all other calls that exist on the system. If it cannot be subsumed or created higher up in the network as a Predicted incident, then a Single Premise Incident is created.

All call processing issues that Call Stew was intended to address have been fixed. At version 10.2.1c, call processing is handled more efficiently than in prior releases, i.e., you do not have to insert an artificial wait time in the form of Call Stew.