When the MLR algorithm is applied to this scenario, we get the sequence m…
mm…m…mm…, again by comparing the respective CSi and CSi’.
By analyzing the CS and CS’ match and mismatch sequences, we can identify
the different stages of the MLR algorithm.
To eliminate the detected fault e 2 the recovery is recursively done, starting from
the last recovery point until the first … m mm … transition is found. The program
execution is then resumed, as the fault e 2 is now eliminated.
The detection of e 1 can happen anytime, even after the detection of e 2 . In the
given example the detection of e 1 occurs after the elimination of e 2 and triggers a
new recovery process.
As e 2 is already completely eliminated, the CSi and CSi’ second match–mismatch sequence does no longer exist and therefore the CSi and CSi’ comparisons
match. The MLR process can thus successfully recover from e 1 .
In other words, several successively occurring faults do not affect the correctness
of the MLR algorithm as long as the fault manifestation do not overlap in time, i.e.,
at least one recovery point exists between the fault manifestations.
If no recovery point was generated between the two fault manifestations,
recovery is also successful, but the two faults are no longer distinguishable. From
the system point of view, it just recovered from one fault.
9.2.4 Hardware Support for the MLR Algorithm
A possible implementation with hardware support of the MLR algorithm must
fulfill the following requirements:
– Any hardware-based checking means must be maskable. This is needed for the
generation of an RP and its CS in the program segment where the fault is
detected.
Fig. 9.5 Permanent HW fault elimination, case (c)
150
9 Recovery: Searching and Monitoring …
mm…m…mm…, again by comparing the respective CSi and CSi’.
By analyzing the CS and CS’ match and mismatch sequences, we can identify
the different stages of the MLR algorithm.
To eliminate the detected fault e 2 the recovery is recursively done, starting from
the last recovery point until the first … m mm … transition is found. The program
execution is then resumed, as the fault e 2 is now eliminated.
The detection of e 1 can happen anytime, even after the detection of e 2 . In the
given example the detection of e 1 occurs after the elimination of e 2 and triggers a
new recovery process.
As e 2 is already completely eliminated, the CSi and CSi’ second match–mismatch sequence does no longer exist and therefore the CSi and CSi’ comparisons
match. The MLR process can thus successfully recover from e 1 .
In other words, several successively occurring faults do not affect the correctness
of the MLR algorithm as long as the fault manifestation do not overlap in time, i.e.,
at least one recovery point exists between the fault manifestations.
If no recovery point was generated between the two fault manifestations,
recovery is also successful, but the two faults are no longer distinguishable. From
the system point of view, it just recovered from one fault.
9.2.4 Hardware Support for the MLR Algorithm
A possible implementation with hardware support of the MLR algorithm must
fulfill the following requirements:
– Any hardware-based checking means must be maskable. This is needed for the
generation of an RP and its CS in the program segment where the fault is
detected.
Fig. 9.5 Permanent HW fault elimination, case (c)
150
9 Recovery: Searching and Monitoring …