In addition, the system must create recovery points that can then be used to roll
back program execution to eliminate the effects of the fault and resume
communication.
We believe that this step of recovery point creation is also part of GAFT as a
separate (concurrent) process to the standard GAFT process. Recovery point creation can either be triggered by an interrupt (for example, timer) or triggered by
software. Figure 4.2 shows an adapted version of GAFT that explicitly includes the
two steps such as software reconfiguration and recovery point creation.
Now, for every step in GAFT, some kind of redundancy is needed. Table 4.1
presents a framework of how to design the individual steps. Table 4.2 presents
concrete examples of implementation.
Incomplete checking and uncertainty in the pattern of fault behavior are attributed possible hardware fault latency. In this case, even prearranged recovery points
(RP) created during program execution might be damaged, as they may already
contain corrupted data. This might be caused by a hardware fault (permanent or
malfunction) and its consequences.
Thus, even several steps of recovery would not be enough to achieve a correct
(at least consistent) state of hardware and software to continue the execution. A
special phase of GAFT (step H in GAFT Table 4.1) is used to locate the correct RP,
or to create a new correct state based on trusted historical application data, which is
in case of a flight control system, the stored data in the Flight Data Memory. In the
worst case, the system could be rebooted and reinitialized.
Note that the state of the software might even in the case of hardware malfunction be damaged, which means that the step H in GAFT (Table 4.1) is required
PERIODICALLY DO
Create recovery point
END
IF error is detected THEN
Determine the type of fault;
IF the fault is permanent THEN
Locate the faulty component;
Reconfigure the hardware by excluding the faulty unit;
END;
IF the fault affected the software
Locate correct state from which possible to continue;
Recover the system from preliminary stored correct
state;
IF hardware has been reconfigured THEN
Reconfigure software;
END;
END;
END;
Fig. 4.2 Generalization of GAFT
28
4 Generalized Algorithm of Fault Tolerance (GAFT)
back program execution to eliminate the effects of the fault and resume
communication.
We believe that this step of recovery point creation is also part of GAFT as a
separate (concurrent) process to the standard GAFT process. Recovery point creation can either be triggered by an interrupt (for example, timer) or triggered by
software. Figure 4.2 shows an adapted version of GAFT that explicitly includes the
two steps such as software reconfiguration and recovery point creation.
Now, for every step in GAFT, some kind of redundancy is needed. Table 4.1
presents a framework of how to design the individual steps. Table 4.2 presents
concrete examples of implementation.
Incomplete checking and uncertainty in the pattern of fault behavior are attributed possible hardware fault latency. In this case, even prearranged recovery points
(RP) created during program execution might be damaged, as they may already
contain corrupted data. This might be caused by a hardware fault (permanent or
malfunction) and its consequences.
Thus, even several steps of recovery would not be enough to achieve a correct
(at least consistent) state of hardware and software to continue the execution. A
special phase of GAFT (step H in GAFT Table 4.1) is used to locate the correct RP,
or to create a new correct state based on trusted historical application data, which is
in case of a flight control system, the stored data in the Flight Data Memory. In the
worst case, the system could be rebooted and reinitialized.
Note that the state of the software might even in the case of hardware malfunction be damaged, which means that the step H in GAFT (Table 4.1) is required
PERIODICALLY DO
Create recovery point
END
IF error is detected THEN
Determine the type of fault;
IF the fault is permanent THEN
Locate the faulty component;
Reconfigure the hardware by excluding the faulty unit;
END;
IF the fault affected the software
Locate correct state from which possible to continue;
Recover the system from preliminary stored correct
state;
IF hardware has been reconfigured THEN
Reconfigure software;
END;
END;
END;
Fig. 4.2 Generalization of GAFT
28
4 Generalized Algorithm of Fault Tolerance (GAFT)