Defending Event-Triggered Systems against Out-of-Envelope Environments

TL;DR

Time-triggered designs are argued to be immune to out-of-envelope disruption, but the paper shows that event-triggered systems can be defended against such conditions. It introduces an importance-based feasibility model, inspired by mixed-criticality scheduling, to decide which events to internalize when the environment violates assumptions. A defense architecture using vectored interrupt controllers, per-line priorities, and masking is proposed to prevent interrupt storms while preserving processing of important alarms. The discussion highlights limitations, open questions, and avenues for hardware-assisted implementations and potential network-level extensions.

Abstract

The design of real-time systems is based on assumptions about environmental conditions in which they will operate. We call this their safe operational envelope. Violation of these assumptions, i.e., out-of-envelope environments, can jeopardize timeliness and safety of real-time systems, e.g., by overwhelming them with interrupt storms. A long-lasting debate has been going on over which design paradigm, the time- or event-triggered, is more robust against such behavior. In this work, we investigate the claim that time-triggered systems are immune against out-of-envelope behavior and how event-triggered systems can be constructed to defend against being overwhelmed by interrupt showers. We introduce importance (independently of priority and criticality) as a means to express which tasks should still be scheduled in case environmental design assumptions cease to hold, draw parallels to mixed-criticality scheduling, and demonstrate how event-triggered systems can defend against out-of-envelope behavior.

Figures (3)

• Figure 1: Internalization and scheduling options for a task, which deviates from the assumed envelope. Both events need to be internalized and generate top-half overheads. Depending on the kind of task, out of envelope behavior can be addressed by releasing all jobs for this event (option 1) or by informing an already running job (option 2), e.g., by invoking an exception handler in this task.
• Figure 2: Example showing that importance-monotonic scheduling is not optimal. The low-importance task $\tau_l$ misses its deadline, even in normal situations (left), whereas both jobs of it can meet their deadline if the first one is higher prioritized than the high-importance task $\tau_h$ (middle). Even if $\tau_h$ is released outside the anticipated envelope (up to $n_h = 2$ events within $W_h = T_h$ in this example), $\tau_h$ meets all deadlines, at the cost of the less important second job of $\tau_l$.
• Figure 3: Example showing how the interrupt priority level may prevent internalizing some of the events that have no consequence for scheduling. In the figure, three tasks ($\tau_A, \tau_B, \tau_C$) and their events ($E_A, E_B, E_C$) are shown that may preempt the currently running task $\tau_{\mathit{current}}$. We set the interrupt priority level to below the importance of the least important task ($\tau_B$) that may still preempt $\tau_{\mathit{current}}$. This way, $\tau_C$, whose event importance $I_C$ is lower than or equal to the interrupt priority level gets masked. However, the event $E_A$ of task $\tau_A$ remains enabled, since $\tau_A$ is more important than $\tau_B$ (although less important than $\tau_{\mathit{current}}$).

Theorems & Definitions (1)

• Definition 1: Out-of-Envelope Feasibility