Prediction Services Configuration

The prediction services configuration file (Miner.Responder.PredictionServices.exe.config) is an XML file that must be configured to use Responder's prediction services. You may edit the file by opening it in an XML application (such as XML Spy) or by opening it in a simple text editor (such as Notepad). Miner.Responder.PredictionServices.exe.config is installed in: Program Files(x86)\Miner and Miner\Responder\Server\.

Do not edit XML files using a word processing program such as WordPad or Microsoft Word as it may corrupt your configuration file.

The information below includes optional configuration steps very similar to the Data Services configuration. The configuration in these five steps is not required, but it may improve the performance of your Data Services, especially if you have a large number of users. In later required steps, you'll determine how your Prediction Engine will formulate predictions.

Optional XML Configuration

Add the following XML:

	Copy Code
<miner.responder.server.configuration default="ConfigurationName"> <multicast group="239.254.000.006" port="6679" ttl="2"/> <database> <connectionString>Data Source=instance name;Min Pool Size=2;User ID=Responder user ID;Password=Responder password</connectionString> <providerFactoryClass type="Miner.Data.Access.ProviderFactories.OracleProviderFactory, Miner.Data.Access"/> <syntaxClass type="Miner.Data.Access.OracleDataSyntax, Miner.Data.Access"/> <schemaConfigurationFile>DatabaseSchemaConfig.xml</schemaConfigurationFile> </database> <geodatabase> <server>geodatabase server name</server> <instance>geodatabase server instance</instance> <database>SQL server database name</database> <user>GIS user ID for the database owner</user> <password>GIS user password</password> <version>version name</version> <dataset>dataset name</dataset> <network>geometric network name</network> </geodatabase> </configuration>

Copy Code

<miner.responder.server.configuration default="ConfigurationName">
    <multicast group="239.254.000.006" port="6679" ttl="2"/>
    <database>
      <connectionString>Data Source=instance name;Min Pool Size=2;User ID=Responder user ID;Password=Responder password</connectionString>
      <providerFactoryClass type="Miner.Data.Access.ProviderFactories.OracleProviderFactory, Miner.Data.Access"/>
      <syntaxClass type="Miner.Data.Access.OracleDataSyntax, Miner.Data.Access"/>
      <schemaConfigurationFile>DatabaseSchemaConfig.xml</schemaConfigurationFile>
    </database>
    <geodatabase>
      <server>geodatabase server name</server>
      <instance>geodatabase server instance</instance>
      <database>SQL server database name</database>
      <user>GIS user ID for the database owner</user>
      <password>GIS user password</password>
      <version>version name</version>
      <dataset>dataset name</dataset>
      <network>geometric network name</network>
    </geodatabase>
</configuration>

First, you will set up a <configuration> section for each database to which you need to connect. You will need to modify the following attributes:

configuration name: This is a unique name that identifies this specific connection.
connectionstring: This is the connection information to the Responder server. Enter the server name, user and password necessary to connect to it.

Min Pool Size: This optional attribute in the connection string sets the minimum number of pooled database connections. When the number of pooled connections exceeds the Min Pool Size setting any idle connections will be disconnected without falling below that Min Pool Size threshold. Recommended Min Pool Size setting for Prediction Services: 2

geodatabase: The <geodatabase> section contains connection information to the server that hosts the geodatabase. Inlude the server name and instance. If you're using a SQLServer, enter the database name. Also include the user name and password to login as well as the version, dataset and network.

You can set up additional connections to different database servers. Just copy the XML from step 2 and modify it for another server.
Next, identify the connection to enable. Add the following XML:

	Copy Code
<miner.responder.server.configuration default="ConfigurationName">

Set the name attribute to match the configuration name to enable.

Required Prediction Settings

You can configure prediction settings once server information has been configured. Look for the following XML:

	Copy Code
<PredictionThresholdInfo probableStatePollingFrequency="00:20:00" callStewPollingFrequency="00:00:20"> <ThresholdInfo mode="default" bothThresholdsMustPass="false" predictOnConfirmedIncidents="false" probableStateCandidateElevationTime="01:00:00"> <CallThreshold> <ThresholdRange> <lo>0</lo> <hi>3</hi> <threshold>0.65</threshold> </ThresholdRange> <ThresholdRange> <lo>4</lo> <hi>5</hi> <threshold>0.39</threshold> </ThresholdRange> <ThresholdRange> <lo>6</lo> <hi>7</hi> <threshold>0.28</threshold> </ThresholdRange> <ThresholdRange> <lo>8</lo> <hi>max</hi> <threshold>0.15</threshold> </ThresholdRange> </CallThreshold> <ImmediateChildThreshold> <ThresholdRange> <lo>0</lo> <hi>3</hi> <threshold>0.65</threshold> </ThresholdRange> <ThresholdRange> <lo>4</lo> <hi>5</hi> <threshold>0.39</threshold> </ThresholdRange> <ThresholdRange> <lo>6</lo> <hi>7</hi> <threshold>0.28</threshold> </ThresholdRange> <ThresholdRange> <lo>8</lo> <hi>10</hi> <threshold>0.19</threshold> </ThresholdRange> <ThresholdRange> <lo>11</lo> <hi>max</hi> <threshold>0.1</threshold> </ThresholdRange> </ImmediateChildThreshold> </ThresholdInfo> </PredictionThresholdInfo>

Copy Code

<PredictionThresholdInfo probableStatePollingFrequency="00:20:00" callStewPollingFrequency="00:00:20">
  <ThresholdInfo mode="default" bothThresholdsMustPass="false" predictOnConfirmedIncidents="false"
        probableStateCandidateElevationTime="01:00:00">
    <CallThreshold>
      <ThresholdRange>
        <lo>0</lo>
        <hi>3</hi>
        <threshold>0.65</threshold>
      </ThresholdRange>
      <ThresholdRange>
        <lo>4</lo>
        <hi>5</hi>
        <threshold>0.39</threshold>
      </ThresholdRange>
      <ThresholdRange>
        <lo>6</lo>
        <hi>7</hi>
        <threshold>0.28</threshold>
      </ThresholdRange>
      <ThresholdRange>
        <lo>8</lo>
        <hi>max</hi>
        <threshold>0.15</threshold>
      </ThresholdRange>
    </CallThreshold>
    <ImmediateChildThreshold>
      <ThresholdRange>
        <lo>0</lo>
        <hi>3</hi>
        <threshold>0.65</threshold>
      </ThresholdRange>
      <ThresholdRange>
        <lo>4</lo>
        <hi>5</hi>
        <threshold>0.39</threshold>
      </ThresholdRange>
      <ThresholdRange>
        <lo>6</lo>
        <hi>7</hi>
        <threshold>0.28</threshold>
      </ThresholdRange>
      <ThresholdRange>
        <lo>8</lo>
        <hi>10</hi>
        <threshold>0.19</threshold>
      </ThresholdRange>
      <ThresholdRange>
        <lo>11</lo>
        <hi>max</hi>
        <threshold>0.1</threshold>
      </ThresholdRange>
    </ImmediateChildThreshold>
  </ThresholdInfo>
</PredictionThresholdInfo>

Once you've located the above XML in your Miner.Responder.PredictionServices.exe.config file, you may need to modify the following values:

In the PredictionThresholdInfo tag, the probableStatePollingFrequency attribute allows you to determine the frequency with which the Prediction Engine "polls" the Unconfirmed incidents and escalates them to Probable if their elevation time has expired.
In the ThresholdInfo tag, the Mode attribute corresponds to your prediction mode (e.g., night, storm, day). You may establish multiple modes and assign varying prediction thresholds for each.
In the ThresholdInfo tag, the bothThresholdsMustPass attribute allows you to determine whether both criteria must be met or just one before predicting an outage. If this value is set to True, the call threshold as well as the immediate child threshold must be exceeded before Responder will predict an outage on the common device. If you're using Enhanced Prediction, it's important that this value be set to False. By default, this value is False.
In the ThresholdInfo tag, the predictOnConfirmedIncidents attribute allows you to determine how confirmed devices are treated during prediction. For example, an incident is placed (via a customer call) on a B phase service point downstream of an ABC transformer that has a confirmed incident on its A phase. If this attribute value is set to True, Responder may predict that the transformer has both A and B phases out. If this attribute is set to False, Responder will not consider the transformer during prediction and instead analyze the next upstream device. This setting applies to all incidents that have not been closed (they may be restored, however). Additionally, the predictOnConfirmedIncidents attribute will impact incidents when a fault is restored with a past time of restoration and customer calls have been received since the time of restoration. For example, a three-phase transformer has its A phase restored in Responder Explorer at 7pm, but its time of restoration is 6pm (its B and C phases are still confirmed out). Between 6:14pm and 6:36pm, three calls are received from load points downstream of the transformer on its A phase. When the transformer is restored, these calls are re-submitted and single-premise incidents created. If this value is set to True, the transformer may be predicted out as soon as it is restored. If this value is set to False, prediction will skip over the confirmed fault device (the transformer) and look for the next unconfirmed device upstream.
In the ThresholdInfo tag, the probableStateCandidateElevationTime attribute determines the amount of time after which an Unconfirmed incident is elevated to Probable. In the example above, an Unconfirmed incident is elevated to Probable after one hour.

Take careful consideration when setting the probableStateCandidateElevationTime value. This value determines the amount of time after which an unconfirmed incident is set to Probable. Probable incidents are NOT rolled up as part of the prediction process. Setting the probableStateCandidateElevationTime too low may set incidents to Probable too soon and prevent calls from rolling up to a suspected device.

The CallThreshold tag allows you to set thresholds on the number of customer calls that must be received before the associated device is determined faulty. The <lo> and <hi> values for the ThresholdRange sections represent the number of total downstream customers for a device. In the example below, the CallThreshold/ThresholdRange is from 0 to 10 customers. This should not be confused with the number of loadpoints, which may be more or less. The threshold of .49 means that more than 49% of the customers must have calls for the threshold to be met.
The ImmediateChildThreshold tag allows you to set thresholds on the number of downstream devices (must be immediate children) that are out before the incident is rolled up to the common device. A ThresholdRange from 0 to 3 refers to 0 to 3 immediate children. A threshold of .65 (65%) means that at least two children must have outages for the device to be considered out.

Save and close Miner.Responder.PredictionServices.exe.config.

It is important to note that prediction will not occur on a device if it has only one child. This is because prediction assumes the lowest possible device is responsible, and there is no additional information to help determine if the lower or upper device is likely to be out.

You may run diagnostics to test the database and geometric network connections. This service also allows you to enable a particular prediction mode.

If you choose to start the Responder Services (e.g., Prediction Services) using the Responder Windows Service, you may log off of the machine. The Responder Services will continue to run until stopped. If you run Responder Services using the individual executable files (e.g., Miner.Responder.PredictionServices.exe), you must remain logged on to the server. Logging off will stop the Responder Services.