Permanent faults, however, cannot be detected with the comparison scheme
alone, as they might affect both executions of P. In other words, the scenario in
Fig. 7.2 can only detect permanent faults whereas the scenario in Fig. 7.3 can only
detect malfunctions.
The combined power to detect malfunctions and permanent faults is illustrated in
Fig. 7.4 where C is used to detect malfunctions and T to detect permanent faults.
Assuming that C triggers an error but T does not, it is clear that a malfunction
occurred. Another run of program P with comparison to the previous two runs can
identify the run where the malfunction occurred.
In the following analysis, we concentrate on the detection of permanent faults
only and use only T in the analysis. The detection of malfunctions can be considered as included in the following analysis if the double execution of P with
following C as a whole is treated as task P in the following analysis.
A testing phase is required initially at boot up time to guarantee the correctness
of the hardware and also a periodic test before and after the execution of a program.
The applied tests might vary in depth (coverage), type of faults and the set of the
tested hardware.
Every hardware component has typically at least one assigned test but might also
have more than one that could differ on the implementation level.
Software-based tests need a processor and memory for the test execution even if
a peripheral device is tested. In order to guarantee that faults in other hardware
components (that are not subject of the current test itself) do not have an influence
on the outcome of the test, the order of the tests must follow the principle of
growing core:
If a test of a hardware component u i has implicit dependencies on another hardware component u j , the test of u j must be executed first.
If the resources needed by a task are known in advance, it is sufficient to run
after the execution only the testing procedures of the accessed hardware resources
(selective testing), again by using the principle of growing core.
This way, the system stays fully operational even in the case of present faults in
some hardware components that are not in use. Spare components can be used for
the relocation of programs that were running on faulty hardware components. Sure
the state of a system should be reflected somewhere for convenience of timely
decision if required.
Fig. 7.4 Program repetition and hardware test detect both types of faults
7.1 Hardware-Checking Process
73
alone, as they might affect both executions of P. In other words, the scenario in
Fig. 7.2 can only detect permanent faults whereas the scenario in Fig. 7.3 can only
detect malfunctions.
The combined power to detect malfunctions and permanent faults is illustrated in
Fig. 7.4 where C is used to detect malfunctions and T to detect permanent faults.
Assuming that C triggers an error but T does not, it is clear that a malfunction
occurred. Another run of program P with comparison to the previous two runs can
identify the run where the malfunction occurred.
In the following analysis, we concentrate on the detection of permanent faults
only and use only T in the analysis. The detection of malfunctions can be considered as included in the following analysis if the double execution of P with
following C as a whole is treated as task P in the following analysis.
A testing phase is required initially at boot up time to guarantee the correctness
of the hardware and also a periodic test before and after the execution of a program.
The applied tests might vary in depth (coverage), type of faults and the set of the
tested hardware.
Every hardware component has typically at least one assigned test but might also
have more than one that could differ on the implementation level.
Software-based tests need a processor and memory for the test execution even if
a peripheral device is tested. In order to guarantee that faults in other hardware
components (that are not subject of the current test itself) do not have an influence
on the outcome of the test, the order of the tests must follow the principle of
growing core:
If a test of a hardware component u i has implicit dependencies on another hardware component u j , the test of u j must be executed first.
If the resources needed by a task are known in advance, it is sufficient to run
after the execution only the testing procedures of the accessed hardware resources
(selective testing), again by using the principle of growing core.
This way, the system stays fully operational even in the case of present faults in
some hardware components that are not in use. Spare components can be used for
the relocation of programs that were running on faulty hardware components. Sure
the state of a system should be reflected somewhere for convenience of timely
decision if required.
Fig. 7.4 Program repetition and hardware test detect both types of faults
7.1 Hardware-Checking Process
73