If background tasks are present in the system, i.e., tasks with a deadline of 1, one
synchronous tests should be scheduled for every T c cycle at an arbitrary point in
time where no other test is running.
7.2.6 FT Scheduling
Scheduling in the event of faults is challenging, as the system must immediately
diagnose the fault and define further actions that depend on the diagnosis outcome.
As faults can happen at any point in time, and cannot be predicted, dynamic
scheduling is required to have the necessary flexibility in the system to react on the
fault.
Static scheduling would not allow interrupting the currently running tasks and
performing system diagnostic.
Before we introduce a scheduling algorithm that combines tasks and tests in the
event of faults, we introduce some general guidelines we want to follow. Note that
we assume a rate monotonic scheduling algorithm. This algorithm also includes the
steps of GAFT. To illustrate the whole process, we first want to describe the process
in words as it is shown below:
1. In case of a manifestation of fault, the process on the processor with the least
critical load (idle, or the task with lowest priority) is preempted and the diagnostic routines are loaded.
2. If the fault affects hardware that is not in use, ignore the fault if the preempted
process in Point 1 was a real-time task. If one processor does not run a
real-time-critical task, the system can use this processor to execute further
actions (Point 4). If the hardware is affected that is in use, continue at Point 4.
Otherwise, continue processing and delay the fault handling until later.
3. Perform GAFT steps B–E on one of the processors.
4. GAFT Steps F–J: Tasks that use the affected hardware and are running since the
last hardware check are considered as faulty, and recovery actions must be
undertaken (see Chap. 9, Sect. 9.1). If the remaining execution time is not
sufficient to execute recovered tasks before their respective deadline, consider
executing alternate versions, depending on their execution times.
5. Reschedule tasks. Continue processing.
Now, as seen above, the tests are scheduled by the scheduler and executed by one
of the processors. If a test found a fault in the system, the test invokes the fault
monitor, which then in turn informs the scheduler and performs the above described
actions. After doing this, the scheduler can reschedule the tasks and continue
processing. For a detailed description of the recovery, see Chap. 9, Sect. 9.1.
7.2 Analysis of Checking Process
87
synchronous tests should be scheduled for every T c cycle at an arbitrary point in
time where no other test is running.
7.2.6 FT Scheduling
Scheduling in the event of faults is challenging, as the system must immediately
diagnose the fault and define further actions that depend on the diagnosis outcome.
As faults can happen at any point in time, and cannot be predicted, dynamic
scheduling is required to have the necessary flexibility in the system to react on the
fault.
Static scheduling would not allow interrupting the currently running tasks and
performing system diagnostic.
Before we introduce a scheduling algorithm that combines tasks and tests in the
event of faults, we introduce some general guidelines we want to follow. Note that
we assume a rate monotonic scheduling algorithm. This algorithm also includes the
steps of GAFT. To illustrate the whole process, we first want to describe the process
in words as it is shown below:
1. In case of a manifestation of fault, the process on the processor with the least
critical load (idle, or the task with lowest priority) is preempted and the diagnostic routines are loaded.
2. If the fault affects hardware that is not in use, ignore the fault if the preempted
process in Point 1 was a real-time task. If one processor does not run a
real-time-critical task, the system can use this processor to execute further
actions (Point 4). If the hardware is affected that is in use, continue at Point 4.
Otherwise, continue processing and delay the fault handling until later.
3. Perform GAFT steps B–E on one of the processors.
4. GAFT Steps F–J: Tasks that use the affected hardware and are running since the
last hardware check are considered as faulty, and recovery actions must be
undertaken (see Chap. 9, Sect. 9.1). If the remaining execution time is not
sufficient to execute recovered tasks before their respective deadline, consider
executing alternate versions, depending on their execution times.
5. Reschedule tasks. Continue processing.
Now, as seen above, the tests are scheduled by the scheduler and executed by one
of the processors. If a test found a fault in the system, the test invokes the fault
monitor, which then in turn informs the scheduler and performs the above described
actions. After doing this, the scheduler can reschedule the tasks and continue
processing. For a detailed description of the recovery, see Chap. 9, Sect. 9.1.
7.2 Analysis of Checking Process
87