Learn about recovery examples

Example 1: Realtime mode with zero-day recovery time

The figure below depicts a scenario in which the interface has been shut down for eight days. Recovery time is set to zero days, the interface cache time is two days, and recovery start time is not set.

With these settings, the interface recovers events for the past two days (the duration of the cache time parameter, which is larger than the recovery time parameter). As a result of downtime, three event frames are not created, and must be backfilled using recovery mode.

Example 2: Realtime mode with four-day recovery time

In the scenario below, the interface has been shut down for eight days, recovery time is set to four days, the interface cache time is two days, and recovery start time has not been set.

In this example, the interface recovers events for the past four days (the duration of the cache time parameter, which is larger than the recovery time parameter). As a result of downtime, two event frames are not created, and the event spanning into the recovery time is not created. To backfill the missing history, you must use recovery mode.

Example 3: Realtime mode with four-day recovery time, in-progress batch with ABTO

In the scenario pictured below, the interface has been shut down for nine days. Recovery time is set to four days, the interface cache time is two days, abandoned batch timeout is set to two days, and recovery start time has not been set, so the interface is running in Realtime mode.

In this example, the interface recovers events for the past four days, the duration of the recovery time parameter (which is larger than the cache time parameter). Two event frames were not created, due to the interface downtime. Additionally, the event that was in progress when the interface was shut down has been closed with an incorrect end time, because the two-day abandoned batch timeout expired. To fix the end time based on the active point data and create the two missing events, run the interface in recovery mode and specify an end time that includes the ABTO Closed event.

Example 4: Realtime mode with ten-day recovery time

In the scenario below, the interface has been shut down for eight days. Recovery time is set to ten days, the interface cache time is two days, and recovery start time has not been set, so the interface is running in Realtime mode.

In this example, the interface recovers events for the past ten days, the duration of the recovery time parameter (which is larger than the cache time parameter). All events that occurred during the downtime are recovered, because the recovery time spans the interface downtime.

Example 5: Recovery mode, recovery time = 4 days, recovery start time = 9 days ago

In the scenario below, the interface has been shut down for eight days. Recovery time is set to four days, the interface cache time is two days, and recovery start time has been set to include the preceding nine days.

The interface recovers events for the past nine days, recovering all events that occurred during the downtime, then starts active data collection.

Example 6: Recovery mode, historical recovery backfilling

In this example, no event frame exists in the PI AF database. The batch active tags are not repeating. There is one tag event for active, then one to close.

PI EFGen recovers data from 8/15/2012 04:00:00 through 08/17/2012 10:00:00, scanning the batch active tag data back to the RST - ABTO time since no event frames are found in the PI AF database between RST and RET.

The event frames will be recorded in the PI AF Database as follows:

• Batch 5 - Found with a start and end time

• Excursion E1 - Found with a start and end time

• Excursion E2 - Found with a start and end time

• Excursion E3 - Not found

• Batch 2 - Not found

• Batch 1 - Found with just a start time and set to running

• Batch 4 - Not Found

• Downtime D1 - Not Found

• Downtime D2 - Found with a start time and set to running

  

  Note: While setting the end times (RET) has not traditionally been critical in batch recovery, it is critical in PI EFGen 4.1 to set end times and to make sure that they do not overlie an existing event frame on a unit. To recover and close Batch 1, the RET must be after the end time of Batch 1 but before the start time of Batch 4 (assuming batch 4 already exists). If RET is after the start time of existing Batch 4, Batch 1 will not be recovered.

Example 7: Recovery mode, recovery start time = 3 days ago

In the scenario pictured below, the interface has been shut down for one day. Recovery start time has been set to include the preceding three days.

The interface locates the most recent procedure start time after the recovery start time. The interface then recovers all events that occurred since that time, and then starts active data collection.

Example 8: Recovery mode, recovery time = 3 days

In the scenario pictured below, the interface has been shut down for one day. Recovery time is set to three days. Cache time is set to two days.

The interface locates the most recent procedure start time after the current time minus recovery time. The interface then recovers all events that occurred since that time, and then starts active data collection.

Example 9: Recovery mode, cache time = 3 days, recovery time = 2 days

In the scenario pictured below, the interface has been shut down for one day. Recovery time is set to two days. Cache time is set to three days.

The interface locates the most recent procedure start time after the current time minus the cache time. The interface then recovers all events that occurred since that time, and then starts active data collection.