Co-Design Techniques for Fault-Tolerant Real-Time Systems using Imperfect Fault Detectors

To meet the reliability requirements of safety-critical embedded systems, fault tolerance techniques such as active redundancy are widely adopted. Fault-tolerant system design using active redundancy is a very challenging task that involves solving two major problems, namely finding the optimal utilization of temporal and/or spatial redundancy and the scheduling of tasks (including replicas) under timing constraints. Over the past decades, a lot of research efforts have been devoted to this field. To cope with the high problem complexity, many state-of-the-art studies make simplifying assumptions on the fault models and modes. Perfect fail-silent behavior is one assumption that is often used in literature. It is assumed that all faults are detected within a certain time interval and that the fault detection overhead is contained in the tasks’ Worst-Case Execution Times (WCETs), e.g., in faulttolerant task scheduling [1, 2, 3, 4, 5], in reliability-aware energy management [6, 7, 8] and in error-aware system design [9, 10]. With this assumption, each task will produce either a correct output or no output at all. Although fail-silence is a highly desirable property, it is difficult to implement in practice. The prerequisite is the existence of a perfect fault detector that achieves 100% coverage under the given fault hypothesis. In the previous study [11], we have explained the major problems of this assumption. On the one hand, this assumption is very impractical; on the other hand, even if it is implementable, using perfect fault detection is often a suboptimal design decision, due to the fact that good fault detectors usually come with high timing overheads [12, 13]. Actually, when active redundancy is concerned, there is a tradeoff about whether the available resources should be spent on implementing better fault detection or realizing more redundancy. We have developed new analysis and optimization techniques to tackle these issues. Experimental results show that certain designs involving imperfect fault detectors combined with task replication can outperform other designs assuming perfect fault detection. So far, only software-implemented fault detection is considered. However, as shown in [10], fault detection could also be implemented in hardware to reduce the time overhead, e.g. using on-chip reconfigurable FPGA fabric. This not only contributes to reducing the schedule length but also allows more options for redundancy. Unfortunately, hardware fault detection increases the overall system cost. In particular, the on-chip resources are often not sufficient to implement hardware fault detectors for all tasks. Hence, it is a major design decision to select which fault detector to implement for each task and where to implement them. In Figure 1 we show an example scenario extended from the motivating example of [11]. Figure 1a depicts the schedule using the perfect detector (it is assumed that perfect fault detection incurs 300% timing overhead). Figure 1b is another possible schedule, in which the task is replicated twice and the remaining time (200% task execution time in this case) is used to implement two partial fault detectors. Figures 1c and 1d show two similar schedules with higher number of replications. Figure 2 compares the reliability of those schedules, in terms of the probability of detectable (DUF in the figure) and undetectable (SDC in the figure) faults. As it can be seen, the design with perfect fault detection can detect all faults. However, only detecting the faults is often not sufficient, e.g. for fail-operational applications. When multiple replicas of the same task are available, we have another mean of fault detection, that is, to compare the output from different instances (voting). Actually, certain faults might even be corrected, e.g. a single faulty input out of three inputs will be masked by voting. In this case, the schedule with partial fault detectors might have higher reliability (see [11]). Figure 1e depicts one schedule that has not been considered so far. In this schedule, the fault detector is implemented in hardware to reduce the timing overhead. This allows us to schedule two instances of the task, both