Version: 10.1

Resource Center Home

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 (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 to just 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 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. Because the outage load points are all under a single transformer, the incident remains on the transformer and it not rolled up to the fuRespose.

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

If you choose to use the enhanced Prediction Engine, note that the Probable status and prediction functionality work the same. The difference between the original Prediction Engine and the enhanced Prediction Engine is in how calls are processed.

• Original: A single-premise incident is created for each call received. After the incidents are created, the Prediction Engine evaluates them and rolls them up accordingly.
• Enhanced: Calls are held for a configurable amount of time before the Prediction Engine processes them. When the Prediction Engine processes the top call in the list, it considers all calls (processed and unprocessed). This allows the engine to add calls regarding the same fault to a single incident without creating separate incidents for each call. The next section describes how this call processing works.

 

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

Responder Prediction offers some enhancements that may speed call processing for environments with large call volume. By default, Responder is set up to use the enhanced Prediction Engine functionality. If you wish to use the original Prediction Engine functionality, see the following section for information about disabling the enhancements.

The enhanced Prediction Engine functionality changes the way calls are handled. Originally, when a call came in, Responder would immediately process the call by adding it to an existing incident or creating a new single premise incident. Because only one call could be handled at a time, performance could be slowed if the utility encountered heavy call volumes.

With the enhanced Prediction Engine functionality, Prediction looks for an upstream incident. If it doesn't find one, the call is held for a configurable amount of time. When the Prediction Engine processes a call, it determines whether the call can be added to an existing incident or it must create a new incident. At this time, the Prediction Engine considers all calls (processed and unprocessed). For example, several customers on the same transformer call to report no power. When the Prediction Engine processes the first call, it considers all other unprocessed calls and adds those calls associated with the same outage into the incident. This means several calls are processed and added to a single incident rather than creating incidents on multiple service points before rolling them up to the transformer.

When configuring Prediction (Miner.Responder.PredictionServices.exe.config), it is important to note that the CallThreshold and bothThresholdsMustPass settings are now more important. The CallThreshold should be set to predict the same as or quicker than the ImmediateChildThreshold. If you set CallThreshold to predict slower than the ImmediateChildThreshold, then calls will often result in single premise incidents which will be rolled up by the ImmediateChildThreshold, which causes slower performance. If incidents can be consolidated and rolled up based on the call threshold (before creating a multitude of single premise incidents), performance will be faster.

The bothThresholdsMustPass setting is also important when configuring Prediction. This setting determines whether both the CallThreshold and the ImmediateChildThreshold values must be considered before rolling up an incident. When this is set to False (recommended), incidents can be rolled up based on the CallThreshold and prevent the need to create single premise incidents before rolling up to a consolidated incident. This means faster performance. If this value is set to True, each call (CallThreshold) must result in a single premise incident (ImmediateChildThreshold) in order to meet both thresholds and roll the incidents into a single consolidated incident. This means slower performance. By default, this value is set to False.

Enhanced Prediction Engine uses the Calls tab in Responder Explorer to display calls, both processed and unprocessed. A dispatcher can right-click an unprocessed call (or multiple unprocessed calls) and select Analyze Call(s) to send the call to the Prediction Engine before the wait time has expired.

 

Disable Prediction Enhancements

By default, the Prediction Engine enhancements are enabled. If you do not wish to use this Responder functionality, follow the steps below the disable the enhancements.

1. On the Responder Server, browse to and open Miner.Responder.PredictionServices.exe.config.
2. Look for the following XML. To disable the Prediction Engine enhancements, set the callStewPollingFrequency and callStewCookTime values to 00:00:00. These values are discussed on the Prediction Services Configuration page.

	Copy Code
<PredictionThresholdInfo probableStatePollingFrequency="00:01:00" callStewPollingFrequency="00:00:00" callStewCookTime="00:10:00">

3. Save and close Miner.Responder.PredictionServices.exe.config.
4. On the Responder Server, browse to and open SubmitRulesConfig.xml.
5. Look for the following XML and remove the comment marks to enable this submit rule. When this rule is enabled, an incoming call is processed immediately, resulting in a single-premise incident for every customer call.

	Copy Code
<!--<b:RuleClass Key="" Type="Miner.Responder.Processors.SubmitRules.Post.CallWithLocation, Miner.Responder.Processors"/>-->

6. Also in the SubmitRulesConfig.xml file, look for the following XML and comment out these lines. These are the submit rules that hold calls for the specified amount of time before processing.

	Copy Code
<b:RuleClass Key="" Type="Miner.Responder.Processors.SubmitRules.Post.CallWithLocationForEP, Miner.Responder.Processors"/> <b:RuleClass Key="" Type="Miner.Responder.Processors.SubmitRules.Post.CallWithLocationAndHazardsForEP, Miner.Responder.Processors"/>

7. Save and close SubmitRulesConfig.xml. You may also remove the Calls tab from Responder Explorer. If you disable Enhanced Prediction, the Calls tab will display all calls associated with active incidents (there will be no processed calls). If you wish to remove the Calls tab, follow the steps below.
8. Create a custom layout file that removes the Calls tab from Responder Explorer. You can do this by copying the following XML into a text file.

	Copy Code
<?xml version="1.0" encoding="us-ascii"?> <LayoutData xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" layoutFormat="2"> <MainWindow /> <RemoveObjects> <RemoveObject objectType="MdiWindow" key="Calls" /> </RemoveObjects> </LayoutData>

9. Name this text file in the following format: xxx.custom.layout. For example: RemoveCallsTab.custom.layout.
10. Save this file to the following directory: \Program Files\Miner and Miner\Responder\Client\addons\Miner.Responder.Explorer.

 

---

Send Comment to documentation@schneider-electric.com