also be scheduled in gaps smaller than T sd , as long as T c is not exceeded. This
approach is especially useful if the difference between the gap and T sd is small. If
this happens, then the problem is not able to schedule, and it is necessary to extend
T c . Of course, a diagnosis cycle is over when all units are tested.
If one wants to minimize performance losses when T c is not limited, every unit
except one gets a user task and the remaining one performs the asynchronous
testing.
Everything that was discussed above covered the first case where both the task
times and T c are known in advance. We want to discuss now case (2) where T c is
known but the task completing times are unknown. In this case, it is possible to test
all units of t i,j = 1…n if T c ! nT sd holds. This ensures that even in the case that all
tasks are diagnosed in the more time-consuming synchronous mode enough time is
available.
For case (2), the testing algorithm is as follows.
Tests are performed asynchronously as long as enough time is left to perform all
remaining tests synchronously, i.e., (n − i)T sd < (T c − T
* ) with T
* as the current
time and i the number of the currently executed task.
In case (3) where T c is not known and therefore unlimited and the task completion times are also not known, it is hard to optimize the system diagnosis due to
the lack of information. However, it is still possible to apply the here presented
approach.
Suppose that the system currently tests unit u i . Suppose now that unit u j completes a user task while u i is tested. By using the testing completion time which is
known, it is possible to find out whether it is worth waiting for the test to complete
or not.
Thus, if the remaining testing time for u i is less than (T u + T r ), it is worth for u j
to wait for the completion of u i and then perform an asynchronous test. Of course, if
u j finishes and no testing is currently ongoing, u j can immediately initiate its
asynchronous testing. In other cases, uj has to be tested synchronously. The situation gets worse when all units of the system are supposed to be tested synchronously, i.e., max(T c ) = NT sd .
Although the diagnosis period for the whole system in case (3) cannot be strictly
determined, the diagnosis process has a finite character, as over time, every task will
finish eventually and thus every unit will get the opportunity of to be tested
asynchronously.
One might also think of having tasks that are supposed to run permanently on
one CPU. For this purpose, it is sufficient to dedicate one CPU for this task and
periodically test it in the synchronous mode.
7.2.4 Extension of the Diagnostic Procedure
One of the constraints until now was the fact that all tasks are ready at t = 0, the
boot up time. In a real system, especially in control systems with specific task
7.2 Analysis of Checking Process
81
approach is especially useful if the difference between the gap and T sd is small. If
this happens, then the problem is not able to schedule, and it is necessary to extend
T c . Of course, a diagnosis cycle is over when all units are tested.
If one wants to minimize performance losses when T c is not limited, every unit
except one gets a user task and the remaining one performs the asynchronous
testing.
Everything that was discussed above covered the first case where both the task
times and T c are known in advance. We want to discuss now case (2) where T c is
known but the task completing times are unknown. In this case, it is possible to test
all units of t i,j = 1…n if T c ! nT sd holds. This ensures that even in the case that all
tasks are diagnosed in the more time-consuming synchronous mode enough time is
available.
For case (2), the testing algorithm is as follows.
Tests are performed asynchronously as long as enough time is left to perform all
remaining tests synchronously, i.e., (n − i)T sd < (T c − T
* ) with T
* as the current
time and i the number of the currently executed task.
In case (3) where T c is not known and therefore unlimited and the task completion times are also not known, it is hard to optimize the system diagnosis due to
the lack of information. However, it is still possible to apply the here presented
approach.
Suppose that the system currently tests unit u i . Suppose now that unit u j completes a user task while u i is tested. By using the testing completion time which is
known, it is possible to find out whether it is worth waiting for the test to complete
or not.
Thus, if the remaining testing time for u i is less than (T u + T r ), it is worth for u j
to wait for the completion of u i and then perform an asynchronous test. Of course, if
u j finishes and no testing is currently ongoing, u j can immediately initiate its
asynchronous testing. In other cases, uj has to be tested synchronously. The situation gets worse when all units of the system are supposed to be tested synchronously, i.e., max(T c ) = NT sd .
Although the diagnosis period for the whole system in case (3) cannot be strictly
determined, the diagnosis process has a finite character, as over time, every task will
finish eventually and thus every unit will get the opportunity of to be tested
asynchronously.
One might also think of having tasks that are supposed to run permanently on
one CPU. For this purpose, it is sufficient to dedicate one CPU for this task and
periodically test it in the synchronous mode.
7.2.4 Extension of the Diagnostic Procedure
One of the constraints until now was the fact that all tasks are ready at t = 0, the
boot up time. In a real system, especially in control systems with specific task
7.2 Analysis of Checking Process
81