Restart-Based Fault-Tolerance: System Design and Schedulability Analysis

TL;DR

This paper presents a fault-tolerance system design for embedded safety-critical systems using restart-based recovery and schedulability analysis to ensure timing constraints despite faults.

Contribution

It introduces a restart-based fault-tolerance approach with schedulability analysis for safety-critical embedded systems, enabling fault recovery without full software verification.

Findings

Schedulability results for four restart-tolerant task models.

Simulation shows effective fault recovery with minimal timing disruption.

System design ensures safety-critical task deadlines are met during faults.

Abstract

Embedded systems in safety-critical environments are continuously required to deliver more performance and functionality, while expected to provide verified safety guarantees. Nonetheless, platform-wide software verification (required for safety) is often expensive. Therefore, design methods that enable utilization of components such as real-time operating systems (RTOS), without requiring their correctness to guarantee safety, is necessary. In this paper, we propose a design approach to deploy safe-by-design embedded systems. To attain this goal, we rely on a small core of verified software to handle faults in applications and RTOS and recover from them while ensuring that timing constraints of safety-critical tasks are always satisfied. Faults are detected by monitoring the application timing and fault-recovery is achieved via full platform restart and software reload, enabled by the short restart time of embedded systems. Schedulability analysis is used to ensure that the timing constraints of critical plant control tasks are always satisfied in spite of faults and consequent restarts. We derive schedulability results for four restart-tolerant task models. We use a simulator to evaluate and compare the performance of the considered scheduling models.

Equations

$$t_{next}=\min_{i\leq c_{n}}\bigg{(}\lfloor(t-\phi_{i})/T_{i}\rfloor T_{i}+\phi_{i}+\mathcal{\hat{R}}_{i}\bigg{)}.$$

$$R_{i}^{(k+1)}=C_{i}+\sum_{\tau_{j}\in hp(\pi_{i})}\bigg{\lceil}\frac{R_{i}^{(k)}}{T_{j}}\bigg{\rceil}C_{j}+\mathcal{O}_{i}^{p}$$

$$\mathcal{O}_{i}^{p}=\left\{\begin{array}[]{lr}C_{r}+\sum_{\tau_{j}\in hp(\pi_{i})\cup\{\tau_{i}\}}C_{j}&i\leq n_{c}\\ 0&i>n_{c}\end{array}\right.$$

$$L_i^{(q)}=B_i+C_i+\sum _{j\in hp({\pi }_i)}\lceil L_i^{(q-1)}/T_j\rceil C_j+{\mathcal{O}}_i^{np}$$

$$R_i=\underset{k\in [1,K_i]}{\max }\{F_{i,k}-(k-1)T_i\}$$

$$F_{i,k}=S_{i,k}+C_i$$

$$S^{(k+1)}_{i,k}=B_{i}+\sum_{\tau_{j}\in hp(\pi_{i})}\left(\bigg{\lfloor}\frac{S_{i,k}^{(k)}}{T_{j}}\bigg{\rfloor}+1\right)C_{j}+\mathcal{O}_{i}^{np}$$

$$\mathcal{O}_{i}^{np}=\left\{\begin{array}[]{lr}C_{r}+max\left\{\{C_{j}\mid j\in hp(\pi_{i})\}\cup C_{i}\right\}&i\leq n_{c}\\ 0&i>n_{c}\end{array}\right.$$

$$R_i=\underset{k\in [1,K_i]}{\max }\{F_{i,k}-(k-1)T_i\}$$

$$F_{i,k}=S_{i,k}+Q_i$$

$$S_{i,k}^{(q+1)}=B_{i}+(k-1)C_{i}+C_{i}-Q_{i}\\ +\sum_{\tau_{j}\in hp(\tau_{i})}\left(\bigg{\lfloor}\frac{S_{i,k}^{(q)}}{T_{j}}\bigg{\rfloor}+1\right)C_{j}+\mathcal{O}_{i}^{npe}$$

$$B_i=\underset{{\tau }_k\in lp({\pi }_i)}{\max }\{Q_k\}.$$

$$\mathcal{O}_{i}^{npe}=\left\{\begin{array}[]{lr}C_{r}+\mathcal{WCWE}(i)&i\leq n_{c}\\ 0&i>n_{c}\end{array}\right.$$

$$\mathcal{WCWE}(i)=C_{i}+max\bigg{(}0,\mathcal{WCWE}(i-1)-Q_{i}\bigg{)}$$

$$Q_{i}=min\big{\{}min\{\beta_{j}\mid j\in hp(\pi_{i})\},C_{i}\big{\}}$$

$$\mathcal{W}\mathcal{C}\mathcal{W}\mathcal{E}(i)=C_i+\max \{\mathcal{W}\mathcal{C}\mathcal{W}\mathcal{C}(j)\mid {\tau }_j\in hp({\lambda }_i)\}$$

$${\mathcal{O}}_i^{pt,s}=C_r+\max \{\mathcal{W}\mathcal{C}\mathcal{W}\mathcal{E}(j)\mid {\tau }_j\in hp({\pi }_i)\}$$

$$R_{i}=\max_{k\in[1,K_{i}]}\bigg{\{}\max\{F^{s}_{i,k},F^{f}_{i,k}\}-(k-1)T_{i}\bigg{\}}$$

$$B_i=\underset{j}{\max }\{C_j\mid {\pi }_j<{\pi }_i\le {\lambda }_j\}$$

$$S_{i,k}^{(q)}=B_{i}+(k-1)C_{i}+\\ \sum_{j\in hp(\pi_{i})}\bigg{(}1+\bigg{\lfloor}\frac{S_{i,k}^{(q-1)}}{T_{j}}\bigg{\rfloor}\bigg{)}C_{j}+\mathcal{O}^{pt,s}_{i}$$

$$F_{i,k}^{(q)}=S_{i,k}+C_{i}+\\ \sum_{j\in hp(\lambda_{i})}\left(\bigg{\lceil}\frac{F^{(q-1)}_{i,k}}{T_{j}}\bigg{\rceil}-\left(1+\bigg{\lfloor}\frac{S_{i,k}}{T_{j}}\bigg{\rfloor}\right)\right)C_{j}+\mathcal{O}^{pt,f}_{i}$$

Full text

In this paper, we propose a design approach to deploy safe-by-design embedded systems. To attain this goal, we rely on a small core of verified software to handle faults in applications and RTOS and recover from them while ensuring that timing constraints of safety-critical tasks are always satisfied. Faults are detected by monitoring the application timing and fault-recovery is achieved via full platform restart and software reload, enabled by the short restart time of embedded systems. Schedulability analysis is used to ensure that the timing constraints of critical plant control tasks are always satisfied in spite of faults and consequent restarts. We derive schedulability results for four restart-tolerant task models. We use a simulator to evaluate and compare the performance of the considered scheduling models.

I Introduction

Embedded controllers with smart capabilities are being increasingly used to implement safety-critical cyber-physical systems (SC-CPS). In fact, modern medical devices, avionic and automotive systems, to name a few, are required to deliver increasingly high performance without trading off in robustness and assurance. Unfortunately, satisfying the increasing demand for smart capabilities and high performance means deploying increasingly complex systems. Even seemingly simple embedded control systems often contain a multitasking real-time kernel, support networking, utilize open source libraries [1], and a number of specialized hardware components (GPUs, DSPs, DMAs, etc.). As systems increase in complexity, however, the cost of formally verifying their correctness can easily explode.

Testing alone is insufficient to guarantee the correctness of safety-critical systems, and unverified software may violate system safety in multiple ways, for instance: (i) the control application may contain unsafe logic that guides the system towards hazardous states; (ii) the logic may be correct but incorrectly implemented thereby creating unsafe commands at runtime (application-level faults); (iii) even with logically safe, correctly implemented control applications, faults in underlying software layers (e.g. RTOS and device drivers) can prevent the correct execution of the controller and jeopardize system safety (system-level faults). Due to the limited feasibility and high cost of platform-wide formal verification, we take a different approach. Specifically, we propose a software/hardware co-design methodology to deploy SC-CPS that (i) provide strong safety guarantees; and (ii) can utilize unverified software components to implement complex safety-critical functionalities.

Our approach relies on a key observation: by performing careful boot-sequence optimization, many embedded platforms and RTOS utilized in automotive industry, avionics, and manufacturing can be entirely restarted within a very short period of time. Restarting a computing system and reloading a fresh image of all the software (i.e., RTOS, and applications) from a read-only source appears to be an effective approach to recover from unexpected faults. Thus, we propose the following: as soon as a fault that disrupts the execution of critical components is detected, the entire system is restarted. After a restart, all the safety-critical applications that were impacted by the restart are re-executed. If restart and re-execution of critical tasks can be performed fast enough, i.e. such that timing constraints are always met in spite of task re-executions, the physical system will remain oblivious to and will not be impacted by the occurrence of faults.

The effectiveness of the proposed restart-based recovery relies on timely detection of faults to trigger a restart. Since detecting logical faults in complex control applications can be challenging, we utilize Simplex Architecture [2, 3, 4] to construct control software. Under Simplex, each control application is divided into three tasks; safety controller, complex controller, and decision module. And, safety of the system relies solely on timely execution of the safety controller tasks. From a scheduling perspective, safety is guaranteed if safety controller tasks have enough CPU cycles to re-execute and finish before their deadlines in spite of restarts. In this paper, we analyze the conditions for a periodic task set to be schedulable in the presence of restarts and re-executions. We assume that when a restart occurs, the task instance executing on the CPU and any of the tasks that were preempted before their completion will need to re-execute after the restart. In particular, we make the following contributions:

• •

We propose a Simplex Architecture that can be recovered via restarts and implemented on a single processing unit;

• •

We derive the response time analysis under fixed-priority with fully preemptive and fully non-preemptive disciplines in presence of restart-based recovery and discuss pros and cons of each one;

• •

We propose response time analysis of fixed-priority scheduling in presence of restarts for tasks with preemption thresholds [5] and non-preemptive ending intervals [6] to improve feasibility of task sets;

II Background on Simplex Design

Our proposed approach is designed for the control tasks that are constructed following Simplex verified design guidelines [2, 3, 4]. In the following, we review Simplex design concepts which are essential for the understanding the methodology of this paper. The goal of original Simplex approach is to design controllers, such that the faults in controller software do not cause the physical plant to violate its safety conditions.

• Definition

States of the physical plant that do not violate any of the safety conditions are referred to as admissible states. The physical subsystem is assumed safe as long it is in an admissible state. Likewise those that violate the constraints are referred to as inadmissible states.

Under Simplex Architecture, each controlled physical process/component requires a safety controller, a complex controller, and a decision module. In the following, we define properties of each component.

• Definition

Safety Controller is a controller for which a subset of the admissible states called recoverable states exists with the following property; If the safety controller starts controlling the plant from one of those states, all future states will remain admissible. The set of recoverable states is denoted by $\mathcal{R}$. Safety controller is formally verified i.e., it does not contain logical or implementation errors.

• Definition

Complex Controller is the main controller task of the system that drives the plant towards mission set points. However, it is unverified i.e., it may contain unsafe logic or implementation bugs. As a result, it may generate commands that force the plant into inadmissible states.

• Definition

Decision Module includes a switching logic that can determine if the physical plant will remain safe (stay within the admissible states) if the control output of complex controller is applied to it.

There are multiple approaches to design a verified safety controller and decision module. The first proposed way is based on solving linear matrix inequalities [7], which has been used to design Simplex systems as complicated as automated landing maneuvers for an F-16 [8]. According to this approach, safety controller is designed by approximating the system with linear dynamics in the form: $\dot{x}=Ax+Bu$, for state vector $x$ and input vector $u$. In this approach, safety constraints are expressed as linear constraints in the form of linear matrix inequalities. These constraints, along with the linear dynamics for the system, are the inputs to a convex optimization problem that produces both linear proportional controller gains $K$, as well as a positive-definite matrix $P$. The resulting linear-state feedback controller, $u=Kx$, yields closed-loop dynamics in the form of $\dot{x}=(A+BK)x$. Given a state $x$, when the input $Kx$ is used, the $P$ matrix defines a Lyapunov potential function $(x^{T}Px)$ with a negative-definite derivative. As a result, the stability of the physical plant is guaranteed using Lyapunov’s direct or indirect methods. Furthermore, matrix $P$ defines an ellipsoid in the state space where all safety constraints are satisfied when $x^{T}Px<1$. If sensors’ and actuators’ saturation points were provided as constraints, the states inside the ellipsoid can be reached using control commands within the sensor/actuator limits.

In this way, when the gains $K$ define the safety controller, the ellipsoid of states $x^{T}Px<1$ is the set of recoverable states $\mathcal{R}$. This ellipsoid is used to determine the proper switching logic of the decision module. As long as the system remains inside the ellipsoid, any unverified, complex controller can be used. If the state approaches the boundary of the ellipsoid, control can be switched to the safety controller which will drive the system towards the equilibrium point where $x^{T}Px=0$.

An alternative approach for constructing a verified safety controller and decision module is proposed in [9]. Here, safety controller is constructed similar to the above approach [7]. However, a novel switching logic is proposed for decision module to decide about the safety of complex controller commands. Intuitively, this check is examining what happens if the complex controller is used for a single control interval of time, and then the safety controller is used thereafter. If the reachable states contain an inadmissible state (either before the switch or after), then the complex controller cannot be used for one more control interval. Assuming the system starts in a recoverable state, this guarantees it will remain in the recoverable set for all time.

A system that adheres to this architecture is guaranteed to remain safe only if safety controller and decision module execute correctly. In this way, the safety premise is valid only if safety controller and decision module execute in every control cycle. Original Simplex design, only protects the plant from faults in the complex controller. For instance, if a fault in the RTOS crashes the safety controller or decision module, safety of the physical plant will get violated.

III System Model and Assumptions

In this section we formalize the considered system and task model, and discuss the assumptions under which our methodology is applicable.

III-A Periodic Tasks

We consider a task set $\mathcal{T}$ composed of $n$ periodic tasks $\tau_{1}\ldots\tau_{n}$ executed on a uniprocessor under fixed priority scheduling. Each task $\tau_{i}$ is assigned a priority level $\pi_{i}$. We will implicitly index tasks in decreasing priority order, i.e.,, $\tau_{i}$ has higher priority than $\tau_{k}$ if $i<k$. Each periodic task $\tau_{i}$ is expressed as a tuple $(C_{i},T_{i},D_{i},\phi_{i})$, where $C_{i}$ is the worst-case execution time (WCET), $T_{i}$ is the period, $D_{i}$ is the relative deadline of each task instance, and $\phi_{i}$ is the phase (the release time of the first instance). The following relation holds: $C_{i}\leq D_{i}\leq T_{i}$. Whenever $D_{i}=T_{i}$ and $\phi_{i}=0$, we simply express tasks parameters as $(C_{i},T_{i})$. Each instance of a periodic task is called job and $\tau_{i,k}$ denotes the $k$-th job of task $\tau_{i}$. Finally, $hp(\pi_{i})$ and $lp(\pi_{i})$ refer to the set of tasks with higher or lower priority than $\pi_{i}$ i.e., $hp(\pi_{i})=\{\tau_{j}\mid\pi_{i}<\pi_{j}\}$ and $lp(\pi_{i})=\{\tau_{j}\mid\pi_{i}>\pi_{j}\}$. We indicate with $T_{r}$ the minimum inter-arrival time of faults and consequent restarts; while $C_{r}$ refers to the time required to restart the system.

III-B Critical and Non-Critical Workload

It is common practice to execute multiple controllers for different processes of physical plant on a single processing unit. In this work, we use the Simplex Architecture [2, 3, 4] to implement each controller. As a result, three periodic tasks are associated with every controller: (i) a safety controller (SC) task, (ii) a complex controller (CC) task, and (iii) a decision module (DM) task. In typical designs, the three tasks that compose the same controller have the same period, deadline, and release time.

Remark 1**.**

SC’s control command is sent to the actuator buffer immediately before the termination of that job instance. Hence, the timely execution of SC tasks is necessary and sufficient for the safety of the physical plant.

As a result, out of the three tasks, SC must execute first and write its output to the actuator command buffer. Conversely, DM needs to execute last, after the output of CC is available, to decide if it is safe to replace SC’s command which is already in the actuator buffer. Hence, the priorities of the controller tasks need to be in the following order111We assume enough priority levels to assign distinct priorities.: $\pi(DM)<\pi(CC)<\pi(SC)$. Note that, the precedence constraint that SC, CC and DM tasks must execute in this order can be enforced through the proposed priority ordering if self-suspension and blocking on resources are excluded and if the scheduler is work-conserving. We consider fixed priority scheduling, which is work-conserving and we assume SC, CC and DM tasks do not self-suspend. Moreover, tasks controlling different components are independent; SC, CC and DM tasks for the same component share sensors and actuator channels. Sensors are read-only resources, do not require locking/synchronization and therefore cannot cause blocking. A given SC task, may only share actuator channels with the corresponding DM task. However, SC jobs execute before DM jobs and do not self-suspend, hence DM cannot acquire a resource before SC has finished its execution.

The set of all the SC tasks on the system is called critical workload. All the CC and DM tasks are referred as non-critical workload. Safety is guaranteed if and only if all the critical tasks complete before their deadlines. Whereas, execution of non-critical tasks is not crucial for safety; these tasks are said to be mission-critical but not safety-critical. We assume that the first $n_{c}$ tasks of $\mathcal{T}$ are critical. Notice that with this indexing strategy, any critical task has a higher priority than any non-critical task.

III-C Fault Model

In this paper, we consider two types of fault for the system; application-level faults and system-level faults. We make the following assumptions about the faults that our system safely handles:

A1

The original image of the system software is stored on a read-only memory unit (e.g.,, E2PROM). This content is unmodifiable at runtime.

A2

Application faults may only occur in the unverified workload (i.e., all the application-level processes on the system except SC and DM tasks).

A3

SC and DM tasks are independently verified and fault-free. They might, however, fail silently (no output is generated) due to faults in software layers or other applications on which they depend.

A4

We only consider system- and application-level faults that cause SC and DM tasks to fail silently but do not change their logic or alter their output.

A5

Faults do not alter sensor readings.

A6

Once SC or CC tasks have send their outputs to the actuators, the output is unaffected by system restart. As such, a task does not need to be re-executed if it has completed correctly before a restart.

A7

Re-executing a task even if it has completed correctly does not negatively impact system safety.

A8

Monitoring and initializer tasks (Section IV) are independently verified and fault-free. We assume that system faults can only cause silent failures in these tasks (no output or correct output).

A9

$T_{r}$ is larger than the least common multiple (hyper-period222Length of the hyper-period can be significantly reduced if the control tasks have harmonic periods.) of critical tasks, i.e. $T_{r}>\text{LCM}\{T_{k}\mid k\leq n_{c}\}$

III-D Scheduler State Preservation and Absolute Time

In order to know what tasks were preempted, executing, or completed after a restart occurs, it is fundamental to carry a minimum amount of data across restarts. As such, our architecture requires the existence of a small block of non-volatile memory (NVM). We also require the presence of a monotonic clock unit (CLK) as an external device. CLK is used to derive the absolute time after a system restart. Since we assume periodic tasks, the information provided by CLK is enough to determine the last release time of each task. Whenever a critical task is completed, the completion timestamp obtained from CLK is written to NVM, overwriting the previous value for the same task. We assume that a timestamp update in NVM write can be performed in a transactional manner.

III-E Recovery Model

The recovery action we assume in this paper is to restart the entire system, reload all the software (RTOS and applications) from a read-only storage unit, and re-execute all the jobs that were released but not completed at the time of restart. The priority of a re-executing instance is the same as the priority of the original job. Within $C_{r}$ time units, the system (RTOS and applications) reloads from a read-only image, and re-execution is initiated as needed. Figure 1 depicts how restart and task re-execution affect the scheduling of 3 real-time tasks ($\tau_{1},\tau_{2},\text{and}\tau_{3}$). When the restart happens at $t=10-\epsilon$, $\tau_{1}$ was still running. Moreover, $\tau_{2}$ and $\tau_{3}$ were preempted at time $t=9$ and $t=8$, respectively. Hence all the three task will need to be re-executed after the restart.

System restart is triggered only after a fault is detected. The following definition of fault is used throughout this paper:

• Critical Fault:

any system misbehavior that leads to a non-timely execution of any of the critical tasks.

It follows that (i) the absence of critical faults guarantees that every critical task completes on time; that (ii) the timely completion of all the critical tasks ensures system safety by Assumptions A3-A7; and that (iii) being able to detect all critical faults and re-execute critical tasks by their deadline is enough to ensure timely completion of critical tasks in spite of restarts. We discuss critical fault detection in Section IV; and we analyze system schedulability in spite of critical faults in Section V and VI. Since handling critical faults is necessary and sufficient (Remark 1) for safety, in the rest of this paper, the term fault is used to refer to critical faults.

III-F RBR-Feasibility

A task set $\mathcal{T}$ is said to be feasible under restart based recovery (RBR-Feasible) if the following two conditions are satisfied; *(i) *there exists a schedule such that all jobs of all the critical tasks, or their potential re-executions, can complete successfully before their respective deadlines, even in the presence of a system-wide restart, occurring at any arbitrary time during execution. *(ii) *All jobs, including instances of non-critical tasks, can complete before their deadlines when no restart is performed.

IV Fault Detection and Task Re-execution

As described in the previous section, a successful fault-detection approach must be able to detect any fault before the deadline of a critical task is missed, and to trigger the recovery procedure. Another key requirement is being able to correctly re-execute critical jobs that were affected by a restart.

Fault detection with watchdog (WD) timer: to explain the detection mechanism, we rely on the concept of ideal worst-case response time, i.e. the worst-case response time of a task when there are no restarts (and no re-executions) in the system. We use $\mathcal{\hat{R}}_{i}$ to denote the ideal worst-case response time of $\tau_{i}$. $\mathcal{\hat{R}}_{i}$ can be derived using traditional response-time analysis, or with the analysis proposed in Section V and VI by imposing all the overhead terms $O^{x}_{y}=0$.

If no faults occur in the system, every instance of $\tau_{i}$ is expected to finish its execution within at most $\mathcal{\hat{R}}_{i}$ time units after its arrival time. This can be checked at runtime with a monitoring task. Recall that each critical job records its completion timestamp $t^{comp}_{i}$ to NVM. The monitoring task checks the latest timestamp for $\tau_{i}$ at time instants $kT_{i}+\mathcal{\hat{R}}_{i}$. If $t^{comp}_{i}<kT_{i}$ it means that $\tau_{i}$ has not completed by its ideal worst-case response time. Hence, a restart needs to be triggered. A single WD can be used to always ensure a system reset if any of the critical tasks does not complete by its ideal worst-case response time. The following steps are performed:

Determine the next checkpoint instant $t_{next}$ and checked critical task $\tau_{i}$ as follows:

[TABLE]

In other words, $t_{next}$ captures the earliest instant of time that corresponds to the elapsing of the ideal worst-case response time of some critical task $\tau_{i}$; 2. 2.

Set the WD to restart the system after $t-t_{next}+\epsilon$ time units; 3. 3.

Terminate and set wake-up time at $t_{next}$; 4. 4.

At wake-up, check if $\tau_{i}$ completed correctly: if $t^{comp}_{i}$ obtained from NVM satisfies $t^{comp}_{i}\geq\lfloor(t-\phi_{i})/T_{i}\rfloor T_{i}+\phi_{i}$, then acknowledge the WD so that it does not trigger a reset. Otherwise, do nothing, causing a WD-induced reset after $\epsilon$ time units. 5. 5.

Continue from Step 1 above.

Notice that this simple solution utilizes only one WD timer, and handles all the silent failures. The advantage of using hardware WD timers is that if any faults in the OS or other applications, prevent the time monitor task from execution, the WD which is already set, will expire and restart the system.

To determine which tasks to execute after a restart, we propose the following. Immediately after the reboot completes, a initializer task calculates the latest release time of each task $\tau_{i}$ using $\lfloor(t-\phi_{i})/T_{i}\rfloor T_{i}+\phi_{i}$ where $t$ is the current time retrieved from CLK. Next, it retrieves the last recorded completion time of the task, $t^{comp}_{i}$, from NVM. If $t^{comp}_{i}<\lfloor(t-\phi_{i})/T_{i}\rfloor T_{i}+\phi_{i}$, then the task needs to be executed, and is added to the list of ready tasks. It is possible that a task completed its execution prior to the restart, but was not able to record the completion time due to the restart. In this case, the task will be executed again which does not impact the safety due to Assumption A7.

V RBR-Feasibility Analysis

As mentioned in Section IV, re-execution of jobs impacted by a restart must not cause any other job to miss a deadline. Also, re-executed jobs need to meet their deadlines as well. The goal of this section is to present a set of sufficient conditions to reason about the feasibility of a given task set $\mathcal{T}$ in presence of restarts (RBR-feasibility). In particular, in Sections V-A and V-B, we present a methodology that provides a sufficient condition for exact RBR-Feasibility analysis of preemptive and non-preemptive task sets.

Definition: Length of level-$i$ preemption chain at time $t$ is defined as sum of the executed portions of all the tasks that are in the preempted or running state, and have a priority greater than or equal to $\pi_{i}$ at $t$. Longest level-$i$ preemption chain is the preemption chain that has the longest length over all the possible level-$i$ preemption chains.

For instance, consider a fully preemptive task set with four tasks; $C_{1}$ = 1, $T_{1}=5$, $C_{2}$ = 3, $T_{2}=10$, $C_{3}$ = 2, $T_{3}=12$, $C_{4}$ = 4, $T_{3}=15$, and $\pi_{4}<\pi_{3}<\pi_{2}<\pi_{1}$. For this task set, the longest level-$3$ and level-$4$ preemption chains are 6 and 10, respectively.

V-A Fully Preemptive Task Set

Under fully preemptive scheme, as soon as a higher priority task is ready, it preempts any lower priority tasks running on the processor. To calculate the worst-case response time of task $\tau_{i}$, we have to consider the case where the restart incurs the longest delay on finishing time of the job. For a fully preemptive task set, this occurs when every task $\tau_{k}$ for $k\in\{2,\ldots,i\}$ is preempted immediately prior to its completion by $\tau_{k-1}$ and system restarts right before the completion of $\tau_{1}$. In other words, when tasks $\tau_{1}$ to $\tau_{i}$ form the longest level-i preemption chain. An example of this case is depicted in Figure 1. In this case, the restart and consequent re-execution causes a deadline miss at $t=22$. The example uses only integer numbers for task parameters, hence tasks can be preempted only up to 1 unit of time before their completion. In the rest of the paper, we discuss our result assuming that tasks’ WCETs are real numbers.

Theorem 1 provides RBR-feasibility conditions for a fully preemptive task set $\mathcal{T}$, under fixed priority scheduling.

Theorem 1**.**

A set of preemptive periodic tasks $\mathcal{T}$ is RBR-Feasible under fixed priority algorithm if the response time $R_{i}$ of each task $\tau_{i}$ satisfies the condition: $\forall\tau_{i}\in\mathcal{T},R_{i}\leq D_{i}$. $R_{i}$ is obtained for the smallest value of $k$ for which we have $R_{i}^{(k+1)}=R_{i}^{(k)}$.

[TABLE]

where the restart overhead $\mathcal{O}_{i}^{p}$ on response time is

[TABLE]

Proof.

First, note that Equation 2 without the overhead term $\mathcal{O}_{i}^{p}$, corresponds to the classic response time of a task under fully preemptive fixed priority scheduling [10]. The additional overhead term represents the worst-case interference on the task instance under analysis introduced by restart time and the re-execution of the preempted tasks. We need to show that the overhead term can be computed using Equation 3. Consider the scenario in which every task $\tau_{k}$ is preempted by $\tau_{k-1}$ after executing for $\delta_{i}$ time units where $k\in\{2,...,i\}$. And, a restart occurs after $\tau_{1}$ executed for $\delta_{1}$ time units. Due to the restart, all the tasks have to re-execute and the earliest time $\tau_{i}$ can finish its execution is $C_{r}+\delta_{i}+...+\delta_{1}+C_{i}+...+C_{1}$. Hence, it is obvious that the later each preemption or the restart in $\tau_{1}$ occurs, the more delay it creates for $\tau_{i}$. Once a task has completed, it no longer needs to be re-executed. Therefore, the maximum delay of each task is felt immediately prior to the task’s completion instant. Thus, the overhead is maximized when each $\tau_{k}$ is preempted by $\tau_{k-1}$ for $k\in\{2,..,i\}$ and restart occurs immediately before the end of $\tau_{1}$. ∎

As seen in this section, the worst-case overhead of restart-based recovery in fully preemptive setting occurs when system restarts at the end of longest preemption chain. Therefore, to reduce the overhead of restarting, length of the longest preemption chain must be reduced. In order to reduce this effect we investigate the non-preemptive setting in the following section.

V-B Fully Non-Preemptive Task set

Under this model, jobs are not preempted until their execution terminates. At every termination point, the scheduler selects the task with the highest priority amongst all the ready tasks to execute. The main advantage of non-preemptive task set is that at most one task instance can be affected by restart at any instant of time.

Authors in [11] showed that in non-preemptive scheduling, the largest response time of a task does not necessarily occur in the first job after the critical instant. In some cases, the high-priority jobs activated during the non-preemptive execution of $\tau_{i}$’s first instance are pushed ahead to successive jobs, which then may experience a higher interference. Due to this phenomenon, the response time analysis for a task cannot be limited to its first job, activated at the critical instant, as done in preemptive scheduling, but it must be performed for multiple jobs, until the processor finishes executing tasks with priority higher than or equal to $\pi_{i}$. Hence, the response time of a task needs to be computed within the longest Level-$i$ Active Period, defined as follows [12, 13].

Definition: The Level-$i$ Active Period $L_{i}$ is an interval $[a,b)$ such that the amount of processing that still needs to be performed at time $t$ due to jobs with priority higher than or equal to $\pi_{i}$, released strictly before $t$, is positive for all $t\in(a,b)$ and null in $a$ and $b$. It can be computed using the following iterative relation:

[TABLE]

Here, $\mathcal{O}_{i}^{np}$ is the maximum overhead of restart on the response time of a task. In the following we describe how to calculate this value. $L_{i}$ is the smallest value for which $L_{i}^{(q)}=L_{i}^{(q-1)}$. This indicates that the response time of task $\tau_{i}$ must be computed for all jobs $\tau_{i,k}$ with $k\in[1,K_{i}]$ where $K_{i}=\lceil L_{i}/T_{i}\rceil$.

Theorem 2 describes the sufficient conditions under which a fault and the subsequent restart do not compromise the timely execution of the critical workload under fully non-preemptive scheduling. Notice that, as mentioned earlier, it is assumed that the schedule is resumed with the highest priority active job after restart.

Theorem 2**.**

A set of non-preemptive periodic tasks is RBR-feasible under fixed-priority if the response time $R_{i}$ of each task $\tau_{i}$, calculated through following relation, satisfies the condition: $\forall\tau_{i}\in\mathcal{T};R_{i}\leq D_{i}$.

[TABLE]

where $F_{i,k}$ is the finishing time of job $\tau_{i,k}$ given by

[TABLE]

Here, $S_{i,k}$ is the start time of job $\tau_{i,k}$, obtained for the smallest value that satisfies $S_{i,k}^{(q+1)}=S_{i,k}^{(q)}$ in the following relation

[TABLE]

In Equation 7, term $B_{i}$ is the blocking from low priority tasks and is calculated as $B_{i}=\max_{\tau_{j}\in lp{(\pi_{i})}}{\{C_{j}\}}.$ The term $\mathcal{O}_{i}^{np}$ represents the overhead on task execution introduced by restarts and is calculated as follows:

[TABLE]

Proof.

Equation 7 and 6, without the restart overhead term $\mathcal{O}_{i}^{np}$, are proposed in [12, 13] to calculate the worst-case start time and response time of a task under non-preemptive setting.

We need to show that the overhead term can be computed using Equation 8. Under non-preemptive discipline, restart only impacts a single task executing on the CPU at the instant of restart. There are two possible scenarios that may result in the worst-case restart delay on finish time of task $\tau_{i}$. First, when $\tau_{i}$ is waiting for the higher priority tasks to finish their execution, a restart can occur during the execution of one of the higher priority tasks $\tau_{j}$ and delay the start time $\tau_{i}$ by $C_{r}+C_{j}$. Alternatively, a restart can occur infinitesimal time prior to the completion of $\tau_{i}$ and cause an overhead of $C_{r}+C_{i}$. Hence, the worst-case delay due to a restart is caused by the task with the longest execution time among the task itself and the tasks with higher priority (Equation 8). The restart overhead is not included in the response-time of non-critical tasks ($\mathcal{O}_{i}^{np}=0$ for $i>n_{c}$). ∎

Unfortunately, under non-preemptive scheduling, blocking time due to low priority tasks, may cause higher priority tasks with short deadlines to be non-schedulable. As a result, when preemptions are disabled, there exist task sets with arbitrary low utilization that despite having the lowest restart overhead, are not RBR-Feasible. Figure 2 uses the same task parameters as in Figure 1. The plot shows that the considered task system is not schedulable under fully non-preemptive scheduling when a restart is triggered at $t=5-\epsilon$.

VI Limited Preemptions

In the previous section, we analyzed the RBR-Feasibility of task sets under fully preemptive and fully non-preemptive scheduling. Under full preemption, restarts can cause a significant overhead because the longest preemption chain can contains all the tasks. On the other hand, under non-preemptive scheduling, the restart overhead is minimum. However, due to additional blocking on higher priority tasks, some task sets, even with low utilization, are not schedulable.

In this section we discuss two alternative models with limited preemption. Limited preemption models are suitable for restart-based recovery since they enable the necessary preemptions for the schedulability of the task set, but avoid many unnecessary preemptions that occur in fully preemptive scheduling. Consequently, they induce lower restarting overhead and exhibit higher schedulability.

VI-A Preemptive tasks with Non-Preemptive Ending

As seen in the previous sections, reducing the number and length of preempted tasks in the longest preemption chain, can reduce the overhead of restarting and increase the RBR-Feasibility of task sets. On the other hand, preventing preemptions entirely is not desirable since it can impact feasibility of the high priority tasks with short deadlines. As a result, we consider a hybrid preemption model in which, a job once executed for longer than $C_{i}-Q_{i}$ time units, switches to non-preemptive mode and continues to execute until its termination point. Such a model allows a job that has mostly completed to terminate, instead of being preempted by a higher priority task. $Q_{i}$ is called the size of non-preemptive ending interval of $\tau_{i}$ and $Q_{i}\leq C_{i}$. The model we utilize in this section, is a special case of the model proposed in [6] which aims to decrease the preemption overhead due to context switch in real-time operating systems. In Figure 3, we consider a task set with the same parameters as in Figure 1, where in addition task $\tau_{3}$ has a non-preemptive region of length $Q_{3}=1$. The preemption chain that caused the system in Figure 1 to be non-schedulable cannot occur and the instance of the task becomes schedulable under restarts. With the same setup, Figure 4 considers the case when a reset occurs at $t=9-\epsilon$.

VI-A1 RBR-Feasibility Analysis

Theorem 3 provides the RBR-feasibility conditions of a task-set with non-preemptive ending intervals. In this theorem, $S_{i,k}$ represents the worst case start time of the non-preemptive region of the re-executed instance of job $\tau_{i,k}$. Similarly, $F_{i,k}$ is used to represent the worst-case finish time. The arrival time of instance $k$ of task $\tau_{i,k}$ is $(k-1)T_{i}$.

Theorem 3**.**

A set of periodic tasks $\mathcal{T}$ with non-preemptive ending regions of length $Q_{i}$, is RBR-Feasible under a fixed priority algorithm if the worst-case response time $R_{i}$ of each task $\tau_{i}$, calculated from Equation 9, satisfies the condition: $\forall\tau_{i}\in\mathcal{T},R_{i}\leq D_{i}$.

[TABLE]

where

[TABLE]

and $S_{i,k}$ is obtained for the smallest value of $q$ for which we have $S_{i,k}^{(q+1)}=S_{i,k}^{(q)}$ in the following

[TABLE]

Here, the term $B_{i}$ is the blocking from low priority tasks and is calculated by

[TABLE]

$\mathcal{O}_{i}^{npe}$* is the maximum overhead of the restart on the response time and is calculated as follows:*

[TABLE]

where $\mathcal{WCWE}(i)$ is the worst-case amount of the execution that may be wasted due to the restarts. It is given by the following where $\mathcal{WCWE}(1)=C_{1}$ and

[TABLE]

$K_{i}$* in Equation 9 can be computed from Equation 4 by using $\mathcal{O}_{i}^{npe}$ instead of $\mathcal{O}_{i}^{np}$.*

Proof.

Authors in [5] show that the worst-case response time of task $\tau_{i}$ is the maximum difference between the worst case finish time and the arrival time of the jobs that arrive within the level-$i$ active period (Equation 9).

Hence, we must compute the worst-case finish time of job $\tau_{i,k}$ in the presence of restarts. When a restart occurs during the execution of $\tau_{i,k}$ or while it is in preempted state, $\tau_{i,k}$ needs to re-execute. Therefore, the finish time of the $\tau_{i,k}$ is when the re-executed instance completes. As a result, to obtain the worst-case finish time of $\tau_{i,k}$, we calculate the response time of each instance when a restart with longest overhead has impacted that instance. We break down the worst-case finish time of $\tau_{i,k}$ into two intervals: the worst-case start time of the non-preemptive region of the re-executed job and the length of the non-preemptive region, $Q_{i}$ (Equation 10). $S_{i,k}$ in Equation 10, is the worst-case start time of non-preemptive region of job $\tau_{i,k}$ which can be iteratively obtained from Equation 11. Equation 11 is an extension of the start time computation from [13]. In the presence of non-preemptive regions, an additional blocking factor $B_{i}$ must be considered for each task $\tau_{i}$, equal to the longest non-preemptive region of the lower priority tasks. Therefore, the maximum blocking time that $\tau_{i}$ may experience is $B_{i}=\max_{\tau_{j}\in lp{(\pi_{i})}}{\{Q_{j}\}}$. $B_{i}$ is added to the worst-case start time of the task in Equation 11.

For a task $\tau_{i}$ with the non-preemptive region of size $Q_{i}$, there are two cases that may lead to the worst-case wasted time. First case is when the system restarts immediately prior to the completion of $\tau_{i}$, in which case the wasted time is $C_{i}$. Second case occurs when $\tau_{i}$ is preempted immediately before the non-preemptive region begins (i.e., at $C_{i}-Q_{i}$) by the higher priority task $\tau_{i-1}$. In this case, the wasted execution is $C_{i}-Q_{i}$ plus the maximum amount of the execution of the higher priority tasks that may be wasted due to the restarts (i.e., $\mathcal{WCWE}(i-1)$). The worst-case wasted execution is the maximum of these two values i.e., $\mathcal{WCWE}(i)=max(C_{i},C_{i}-Q_{i}+\mathcal{WCWE}(i-1))=C_{i}+max(0,\mathcal{WCWE}(i-1)-Q_{i})$. Similarly, $\mathcal{WCWE}(i-1)$ can be computed recursively. ∎

VI-A2 Optimal Size of Non-Preemptive Regions

RBR-Feasibility of a taskset depends on the choice of $Q_{i}$s for the tasks. In this section, we present an approach to determine the size of non-preemptive regions $Q_{i}$ for the tasks to maximize the RBR-Feasibility of the task set.

First, we introduce the the notion of blocking tolerance of a task $\beta_{i}$. $\beta_{i}$ is the maximum time units that task $\tau_{i}$ may be blocked by the lower priority tasks, while it can still meet its deadline. Algorithm 1, uses binary search and the response time analysis of task (from Theorem 3) to find $\beta_{i}$ for a task $\tau_{i}$.

In Algorithm 1, $R_{i,B_{i}=middle}$ is computed as described in Theorem 3 (Equation 9), where instead of using the $B_{i}$ from Equation 12, the blocking time is set to the value of $middle$.

Note that, if Algorithm 1 cannot find a $\beta_{i}$ for task $\tau_{i}$, this task is not schedulable at all. This indicates that there is not any selection of $Q_{i}$s that would make $\mathcal{T}$ RBR-Feasible.

Given that task $\tau_{1}$ has the highest priority, it may not be preempted by any other task; hence we set $Q_{1}=C_{1}$. The next theorem shows how to drive optimal $Q_{i}$ for the rest of the tasks in $\mathcal{T}$. The results are optimal, meaning that if there is at least one set of $Q_{i}$s under which $\mathcal{T}$ is RBR-Feasible, it will find them.

Theorem 4**.**

The optimal set of non-preemptive interval $Q_{i}$s of tasks $\tau_{i}$ for $2\leq i\leq n$ is given by:

[TABLE]

assuming that $\beta_{j}\geq 0$ for $j\in hp(\pi_{i})$.

Proof.

Increasing the length of $Q_{i}$ for a task reduces the response time in two ways. First, from Equation 11, increasing $Q_{i}$ reduces the start time of the job $S_{i,k}$ which reduces the finish time and consequently the response time of $\tau_{i}$. Second, from Equation 14, increasing $Q_{i}$ reduces the restart overhead $\mathcal{O}^{npe}_{i}$ on the task and lower priority tasks which in turn reduces the response time. Thus $Q_{i}$ may increase as much as possible up to the worst-case execution time $C_{i}$; $Q_{i}\leq C_{i}$. However, the choice of $Q_{i}$ must not make any of the higher priority tasks unschedulable. As a result, $Q_{i}$ must be smaller than the smallest blocking tolerance of all the tasks with higher priority than $\pi_{i}$; $Q_{i}\leq min\{\beta_{j}|j\in hp(\pi_{i})\}$. Combining these two conditions results in the relation of Equation 15. ∎

VI-B Preemption Thresholds

In the previous section, we discussed non-preemptive endings as a way to reduce the length of the longest preemption chain and decrease the overhead of restarts. In this section, we discuss an alternative approach to reduce the number of tasks in the longest preemption chain and thus reduce the overhead of restart-based recovery.

To achieve this goal, we use the notion of preemption thresholds which has been proposed in [5]. According to this model, each task $\tau_{i}$ is assigned a nominal priority $\pi_{i}$ and a preemption threshold $\lambda_{i}\geq\pi_{i}$. In this case, $\tau_{i}$ can be preempted by $\tau_{h}$ only if $\pi_{h}>\lambda_{i}$. At activation time, priority of $\tau_{i}$ is set to the nominal value $\pi_{i}$. The nominal priority is maintained as long as the task is kept in the ready queue. During this interval, the execution of $\tau_{i}$ can be delayed by all tasks with priority $\pi_{h}>\pi_{i}$, and by at most one lower priority task with threshold $\lambda_{l}\geq\pi_{i}$. When all such tasks complete, $\tau_{i}$ is dispatched for execution, and its priority is raised to $\lambda_{i}$. During execution, $\tau_{i}$ can be preempted by tasks with priority $\pi_{h}>\lambda_{i}$. When $\tau_{i}$ is preempted, its priority is kept at $\lambda_{i}$.

Restarts may increase the response time of $\tau_{i,k}$ in one of two ways; A restart may occur after the arrival of the job but before it has started, delaying its start time $S_{i,k}$. Alternatively, the system can be restarted after the job has started. We use $\mathcal{O}^{pt,s}_{i}$ to denote the worst-case overhead of a restart that occurs before the start time of a job in task sets with preemption thresholds. And, $\mathcal{O}^{pt,f}_{i}$ is used to represent the worst-case overhead of a restart that occurs after the start time of a job in task sets with preemption thresholds.

In Figure 5, we consider a task set with the same parameters as in Figure 1 where in addition $\tau_{2}$ and $\tau_{3}$ have a preemption threshold equal to $\lambda_{2}=1$ and $\lambda_{3}=2$, respectively. This assignment is effective to prevent a long preemption chain, and the jobs do not miss their deadline when the restart occurs at $t=7-\epsilon$. Notice that, the task set is still not RBR-Feasible since if the restart occurs at $t=9-\epsilon$, some job will miss the deadline, as shown in Figure 6.

Theorem 5**.**

For a task set with preemption thresholds under fixed priority, the worst-case overhead of a restart that occurs after the start of the job $\tau_{i,k}$ is $\mathcal{O}^{pt,f}_{i}=C_{r}+\mathcal{WCWE}(i)$ where

[TABLE]

Here, $\mathcal{WCWC}(1)=C_{1}$.

Proof.

After a job $\tau_{i,k}$ starts, its priority is raised to $\lambda_{i}$. In this case, the restart will create the worst-case overhead if it occurs at the end of longest preemption chain that includes $\tau_{i}$ and any subset of the tasks with $\pi_{h}>\lambda_{i}$. Equation 16 uses a recursive relation to calculate the length of longest preemption chain consisting of $\tau_{i}$ and all the tasks with $\pi_{h}>\lambda_{i}$. ∎

Theorem 6**.**

For a task set with preemption thresholds under fixed priority, a restart occurring before the start time of a job $\tau_{i,k}$, can cause the worst-case overhead of

[TABLE]

where $\mathcal{WCWE}(j)$ can be computed from Equation 16.

Proof.

Start time of a task can be delayed by a restart impacting any of the tasks with priority higher than $\pi_{i}$. Equation 17 recursively finds the longest possible preemption chain consisting of any subset of tasks with $\pi_{h}>\pi_{i}$. ∎

Due to the assumption of one fault per hyper-period, each job may be impacted by at most one of $\mathcal{O}^{pt,f}_{i}$ or $\mathcal{O}^{pt,s}_{i}$, but not both at the same time. Hence, we compute the finish time of the task once assuming that the restart occurs before the start time i.e., $\mathcal{O}^{pt,f}_{i}=0$, and another time assuming it occurs after the start time i.e., $\mathcal{O}^{pt,s}_{i}=0$. Finish time in these two cases is referred respectively by $F^{s}_{i,k}$ (restart before the start time) and $F^{f}_{i,k}$ (restart after the start time).

We expand the response time analysis of tasks with preemption thresholds from [5], considering the overhead of restarting. In the following, $S_{i,k}$ and $F_{i,k}$ represent the worst case start time and finish time of job $\tau_{i,k}$. And, the arrival time of $\tau_{i,k}$ is $(k-1)T_{i}$. The worst-case response time of task $\tau_{i}$ is given by:

[TABLE]

Here, $K_{i}$ can be obtained from Equation 4 by using $max(\mathcal{O}^{pt,f}_{i},\mathcal{O}^{pt,s}_{i})$ instead of $\mathcal{O}^{np}_{i}$. A task $\tau_{i}$ can be blocked only by lower priority tasks that cannot be preempted by it, that is:

[TABLE]

To compute finish time, $S_{i,k}$ is computed iteratively using the following equation [5]:

[TABLE]

Once the job starts executing, only the tasks with higher priority than $\lambda_{i}$ can preempt it. Hence, the $F_{i,k}$ can be derived from the following:

[TABLE]

Task set $\mathcal{T}$ is considered RBR-Feasible if $\forall\tau_{i}\in\mathcal{T},R_{i}\leq T_{i}$.

RBR-Feasibility of a task set depends on the choice of $\lambda_{i}$s for the tasks. In this paper, we use a genetic algorithm to find a set of preemption thresholds to achieve RBR-Feasibility of the task-set. Although this algorithm can be further improved to find the optimal threshold assignments, the proposed genetic algorithm achieves acceptable performance, as we show in Section VII.

VII Evaluation

In this section, we compare and evaluate the four fault-tolerant scheduling strategies discussed in this paper. In order to evaluate the practical feasibility of our approach, we have also performed a preliminary proof-of-concept implementation on commercial hardware (i.MX7D platform) for an actual 3 degree-of-freedom helicopter. We tested logical faults, application faults and system-level faults and demonstrated that the physical system remained within the admissible region. Due to space constraints, we omit the description and evaluation of our implementation and refer to [14] for additional details.

VII-A Evaluating Performance of Scheduling Schemes

In this section, we evaluate the performance of four fault-tolerant scheduling schemes that are discussed in this paper. For each data point in the experiments, 500 task sets with the specified utilization and number of tasks are generated. Then, RBR-feasibility of the task sets are evaluated under four discussed schemes; fully preemptive, fully non-preemptive, non-preemptive ending intervals, and preemption thresholds. In order to evaluate performance of the scheduling schemes, all the tasks in the analysis are assumed to be part of the critical workload. Priorities of the tasks are assigned according to the periods, so a task with shorter period has a higher priority.

The experiments are performed with two sets of parameters for the periods of the task sets. In the first set of experiments (Figure 7), task sets are generated with periods in the range of 10 to 1000 time units. In the second set (Figure 8), tasks have a period in the range of 900 to 1000 time units. As a result, tasks in the first experiment have more diverse set of periods than the second one.

As shown in Figure 7(a) and 8(a), all the task sets with utilization less than $50\%$ are RBR-feasible under preemptive scheduling. This observation is consistent with the results of [15] which considers preemptive task sets under rate monotonic scheduling with a recovery strategy similar to ours (re-executing all the unfinished tasks), and shows that all the task sets with utilization under $50\%$ are schedulable.

Moreover, a comparison between Figure 7(a) and 8(a) reveals that fully preemptive setting performs better when tasks in the task set have diverse rates. To understand this effect, we must notice that the longest preemption chain for a task in preemptive setting, consists of the execution time of all the tasks with a higher priority. Therefore, under this scheduling strategy, tasks with low priority are the bottleneck for RBR-feasibility analysis. When the diversity of the periods is increased, lower priority tasks, on average, have much longer periods. As a result, they have a larger slack to tolerate the overhead of restarts compared to the lower priority tasks in task sets with less diverse periods. Hence, more task sets are RBR-feasible when a larger range of periods is considered.

On the contrary, when tasks have more diverse periods, non-preemptive setting performs worse (Figure 7(b) and 8(b)). This is because, with diverse periods, tasks with shorter periods (and higher priorities) experience longer blocking times due to low priority tasks with long execution times.

As the figures show, scheduling with preemption thresholds and non-preemptive intervals in both experiments yield better performance than preemptive and non-preemptive schemes. This effect is expected because the flexibility of these schemes allows them to decrease the overhead of restarts by increasing the non-preemptive regions, or by increasing the preemption thresholds while maintaining the feasibility of the task sets. Tasks under these disciplines exhibit less blocking and lower restart overhead.

Preemption thresholds and non-preemptive endings in general demonstrate comparable performance. However, in task sets with very small number of tasks (2-10 task), scheduling using non-preemptive ending intervals performs slightly better than preemption thresholds. This is due to the fact that, with small number of tasks, the granularity of the latter approach is limited because few choices can be made on the tasks’ preemption thresholds. Whereas, the length of non-preemptive intervals can be selected with a finer granularity and is not impacted by the number of tasks.

VIII Related Work

Most of the previous work on Simplex Architecture [2, 16, 3, 4, 17] has focused on design of the switching logic of DM or the SC, assuming that the underlying RTOS, libraries and middle-ware will correctly execute the SC and DM. Often however, these underlying software layers are unverified and may contain bugs. Unfortunately, Simplex-based systems are not guaranteed to behave correctly in presence of system-level faults. System-Level Simplex and its variants [18, 19, 20] run SC and DM as bare-metal applications on an isolated, dedicated hardware unit. By doing so, the critical components are protected from the faults in the OS or middle-ware of the complex subsystem. However, exercising this design on most multi-core platforms is challenging. The majority of commercial multi-core platforms are not designed to achieve strong inter-core fault isolation due to the high-degree of hardware resource sharing. For instance, a fault occurring in a core with the highest privilege level may compromise power and clock configuration of the entire platform. To achieve full isolation and independence, one has to utilize two separate boards/systems. Our design enables the system to safely tolerate and recover from application-level and system-level faults that cause silent failures in SC and DM without utilizing additional hardware.

The notion of restarting as a means of recovery from faults and improving system availability was previously studied in the literature. Most of the previous work, however, target traditional non-safety-critical computing systems such as servers and switches. Authors in [21] introduce recursively restartable systems as a design paradigm for highly available systems. Earlier literature [22, 23] illustrates the concept of micro-reboot which consists of having fine-grain rebootable components and trying to restart them from the smallest component to the biggest one in the presence of faults. The works in [24, 25, 26] focus on failure and fault modeling and try to find an optimal rejuvenation strategy for various non safety-critical systems.

In the context of safety-critical CPS, authors in [27] propose the procedures to design a base controller that enables the entire computing system to be safely restarted at run-time. Base Controller keeps the system inside a subset of safety region by updating the actuator input at least once after every system restart. In [19], which is variation of System-Level Simplex, authors propose that the complex subsystem can be restarted upon the occurrence of faults. In this design, safe restarting is possible because the back up controller runs on a dedicated processing unit and is not impacted by the restarts in the complex subsystem.

One way to achieve fault-tolerance in real-time systems is to use time redundancy. Using time redundancy, whenever a fault leads to an error, and the error is detected, the faulty task is either re-executed or a different logic (recovery block) is executed to recover from the error. It is necessary that such recovery strategy does not cause any deadline misses in the task set. Fault tolerant scheduling has been extensively studied in the literature. Hereby we briefly survey those works that are more closely related. A feasibility check algorithm under multiple faults, assuming EDF scheduling for aperiodic preemptive tasks is proposed in [28]. An exact schedulability tests using checkpointing for task sets under fully preemptive model and transient fault that affects one task is proposed in [29]. This analysis is further extended in [30] for the case of multiple faults as well as for the case where the priority of a critical task’s recovery block is increased. In [31], authors propose the exact feasibility test for fixed-priority scheduling of a periodic task set to tolerate multiple transient faults on uniprocessor. In [32] an approach is presented to schedule under fixed priority-driven preemptive scheduling at least one of the two versions of the task; simple version with reliable timing or complex version with potentially faulty. Authors in [15] consider a similar fault model to ours, where the recovery action is to re-execute all the partially executed tasks at the instant of the fault detection i.e., executing task and all the preempted tasks. This work only considers preemptive task sets under rate monotonic and shows that single faults with a minimum inter-arrival time of largest period in the task set can be recovered if the processor utilization is less than or equal to $50\%$. In [33], the authors investigate the feasibility of task sets under fault bursts with preemptive scheduling. Similar to our work, the recovery action is to re-execute the faulty job along with all the partially completed (preempted) jobs at the time of fault detection. Most of these works are only applicable to transient faults (e.g., faults that occur due to radiation or short-lived HW malfunctions) that impact the task and do not consider faults affecting the underlying system. Additionally, most of these works assume that an online fault detection or acceptance test mechanism exists. While this assumption is valid for detecting transient faults or timing faults, detecting complex system-level faults or logical faults is non-trivial. Additionally, to the best of our knowledge, our paper is the first one to provide the sufficient feasibility condition in the presence of faults under the preemption threshold model and task sets with non-preemptive ending intervals.

IX Conclusion

Restarting is considered a reliable way to recover traditional computing systems from complex software faults. However, restarting safety-critical CPS is challenging. In this work we propose a restart-based fault-tolerance approach and analyze feasibility conditions under various schedulability schemes. We analyze the performance of these strategies for various task sets. This approach enables us to provide formal safety guarantees in the presence of software faults in the application-layer as well as system-layer faults utilizing only one commercial off-the-shelf processor.