completion and are called periodically by the scheduler. Three tasks are running,
each with its own test (the green boxes) at the end of the task execution.
The test only checks the condition of hardware resources the respective process
needs, which results in different test execution times. The task execution is only
considered as successful if the test at the end of the task is successful.
If the test failed, the task is re-executed by using the same input data set as in the
first try. Difficulties arise if the task performs I/O on hardware devices or communicates with other tasks, which we discuss in Chap. 8.
7.2 Analysis of Checking Process
Applications are nowadays so complex that they tend to saturate the computing
system they are running on, which limits diagnosis possibilities. Especially in
multiprocessor systems, a high interest arises to test some hardware units when
other hardware units execute tasks. This approach has been called the Sliding
Dropping Diagnosis (SDD) [5].
Multiprocessor architectures fit very well the scheme of concurrent softwarebased checking. In principle, two SDD types can be distinguished, namely, synchronous and asynchronous. An example: The CTSS Operating System for the
CRAY-1 [1] supports synchronous SDD with interruption of user task for testing
hardware. Periodically every 15 min, all tasks are interrupted and the diagnostic
routines are executed. These routines are “invisible” from the user tasks point of
view, as the entire system is stopped while the tests are executed.
The Synapse N+1 [2] fault-tolerant operating system serves as an example for
asynchronous SDD. The OS implements a self-loading algorithm to schedule tasks
for processors. The same algorithm can be applied for SDD too, as diagnostics
routines could be loaded as tasks and run on free processors. The actions required
for the implementation of the synchronous SDD mode are as follows:
– Unloading the current state of the currently running user process from some
hardware parts to load diagnostic routines (RAM in a multiprocessor OS is an
example of such a hardware unit).
– Loading and initialization of the diagnostic routines.
– Execution of the diagnostic process.
– Unloading the diagnostic routines and perform actions in case of found faults. If
high priority interrupts occur during testing, some temporary data might be
needed to continue the testing after processing the interrupt.
– Reloading of the user process to continue.
As asynchronous SDD does not interrupt running processes, but is allocated on free
processors; only steps 2–4 are required for asynchronous SDD. It is important to see
that the task unloading time is much higher than a task switch time, as the resources
occupied by this task must be released, which might also involve moving the code
7.1 Hardware-Checking Process
75
each with its own test (the green boxes) at the end of the task execution.
The test only checks the condition of hardware resources the respective process
needs, which results in different test execution times. The task execution is only
considered as successful if the test at the end of the task is successful.
If the test failed, the task is re-executed by using the same input data set as in the
first try. Difficulties arise if the task performs I/O on hardware devices or communicates with other tasks, which we discuss in Chap. 8.
7.2 Analysis of Checking Process
Applications are nowadays so complex that they tend to saturate the computing
system they are running on, which limits diagnosis possibilities. Especially in
multiprocessor systems, a high interest arises to test some hardware units when
other hardware units execute tasks. This approach has been called the Sliding
Dropping Diagnosis (SDD) [5].
Multiprocessor architectures fit very well the scheme of concurrent softwarebased checking. In principle, two SDD types can be distinguished, namely, synchronous and asynchronous. An example: The CTSS Operating System for the
CRAY-1 [1] supports synchronous SDD with interruption of user task for testing
hardware. Periodically every 15 min, all tasks are interrupted and the diagnostic
routines are executed. These routines are “invisible” from the user tasks point of
view, as the entire system is stopped while the tests are executed.
The Synapse N+1 [2] fault-tolerant operating system serves as an example for
asynchronous SDD. The OS implements a self-loading algorithm to schedule tasks
for processors. The same algorithm can be applied for SDD too, as diagnostics
routines could be loaded as tasks and run on free processors. The actions required
for the implementation of the synchronous SDD mode are as follows:
– Unloading the current state of the currently running user process from some
hardware parts to load diagnostic routines (RAM in a multiprocessor OS is an
example of such a hardware unit).
– Loading and initialization of the diagnostic routines.
– Execution of the diagnostic process.
– Unloading the diagnostic routines and perform actions in case of found faults. If
high priority interrupts occur during testing, some temporary data might be
needed to continue the testing after processing the interrupt.
– Reloading of the user process to continue.
As asynchronous SDD does not interrupt running processes, but is allocated on free
processors; only steps 2–4 are required for asynchronous SDD. It is important to see
that the task unloading time is much higher than a task switch time, as the resources
occupied by this task must be released, which might also involve moving the code
7.1 Hardware-Checking Process
75