7.5 Hardware Reconfiguration Outlook
Until now, we assumed a single processor system. The here introduced reconfiguration principles are extendable to cover multiprocessor systems or even multiple
systems.
Especially for multiprocessor systems, the single point of failures, the processor,
and T-logic LMU could be removed by using a TLMU per processor with its own
attached memory. If one of the processors fails, the other processor could reconfigure the TLMU to disable and exclude the other processor from the working set.
If the two TLMUs are connected, the memories of the just disabled processor
could be reconfigured to be used by the working second processor, doubling in fact
the available resource of that processor.
From the current perspective, it is not feasible to apply this reconfiguration
principle further to multiple systems, as the high-speed interconnection between the
systems seems problematic. On a diagnostic level, i.e., one system diagnoses and
reconfigures another, this approach is very well applicable.
7.6 Summary
We showed that software-based checks can indeed be used to detect malfunctions
and permanent faults.
For malfunctions, however, the overhead is quite significant, as duplicate execution of the task is needed to detect discrepancies between the program runs.
For permanent faults, however, the software-based checking can be very useful,
under the assumption that the tests can reliably detect permanent faults.
This is most often the case, as software can check the predefined behavior of the
hardware.
Then we showed, for the detection of permanent faults, how to efficiently
schedule the tests with almost no interference with ongoing tasks.
We proposed to define tests on a tasks basis, where the tests include only the
hardware that the respective task used to minimize test execution time. Tests should
be performed according to the principle of growing core, where the most critical
systems are checked first.
We also introduced several algorithms (T1, T2) for real-time systems with
several CPUs and non-interruptible tasks and T3 for time-sharing systems.
Synchronous and asynchronous testing are used with asynchronous testing being
the preferred choice, as the test does not interfere with its task.
For background tasks, e.g., services that do not finish, we propose to schedule
the test regularly when there is no other test ongoing. We therefore proved that
testing hardware even with software-based tests can be done efficiently without, in
most cases, interfering with ongoing tasks by using processor idle time in a clever
way.
108
7 Testing, Checking, and Hardware Syndrome
Until now, we assumed a single processor system. The here introduced reconfiguration principles are extendable to cover multiprocessor systems or even multiple
systems.
Especially for multiprocessor systems, the single point of failures, the processor,
and T-logic LMU could be removed by using a TLMU per processor with its own
attached memory. If one of the processors fails, the other processor could reconfigure the TLMU to disable and exclude the other processor from the working set.
If the two TLMUs are connected, the memories of the just disabled processor
could be reconfigured to be used by the working second processor, doubling in fact
the available resource of that processor.
From the current perspective, it is not feasible to apply this reconfiguration
principle further to multiple systems, as the high-speed interconnection between the
systems seems problematic. On a diagnostic level, i.e., one system diagnoses and
reconfigures another, this approach is very well applicable.
7.6 Summary
We showed that software-based checks can indeed be used to detect malfunctions
and permanent faults.
For malfunctions, however, the overhead is quite significant, as duplicate execution of the task is needed to detect discrepancies between the program runs.
For permanent faults, however, the software-based checking can be very useful,
under the assumption that the tests can reliably detect permanent faults.
This is most often the case, as software can check the predefined behavior of the
hardware.
Then we showed, for the detection of permanent faults, how to efficiently
schedule the tests with almost no interference with ongoing tasks.
We proposed to define tests on a tasks basis, where the tests include only the
hardware that the respective task used to minimize test execution time. Tests should
be performed according to the principle of growing core, where the most critical
systems are checked first.
We also introduced several algorithms (T1, T2) for real-time systems with
several CPUs and non-interruptible tasks and T3 for time-sharing systems.
Synchronous and asynchronous testing are used with asynchronous testing being
the preferred choice, as the test does not interfere with its task.
For background tasks, e.g., services that do not finish, we propose to schedule
the test regularly when there is no other test ongoing. We therefore proved that
testing hardware even with software-based tests can be done efficiently without, in
most cases, interfering with ongoing tasks by using processor idle time in a clever
way.
108
7 Testing, Checking, and Hardware Syndrome