**Handling Overload Conditions in Real-Time Systems**

Giorgio C. Buttazzo *Scuola Superiore Sant'Anna Italy*

### **1. Introduction**

This chapter deals with the problem of handling overload conditions, that is, those critical situations in which the computational demand requested by the application exceeds the processor capacity (Buttazzo, 2011). If not properly handled, an overload can cause an abrupt performance degradation, or even a system crash. Therefore, a real-time system should be designed to anticipate and tolerate unexpected overload situations through specific kernel mechanisms.

Overload conditions can occur for different causes, including bad system design, simultaneous arrival of events, operating system exceptions, malfunctioning of input devices, and unpredicted variations of the environmental conditions.

In the following, we consider a set of *n* periodic or sporadic tasks, Γ = {*τ*1,..., *τn*}, each characterized by a worst-case execution time (WCET) *Ci*, a relative deadline *Di*, and a period (or minimum inter-arrival time) *Ti*. Each task *τ<sup>i</sup>* is initially activated at time Φ*<sup>i</sup>* (denoted as the task phase) and generates an infinite sequence of jobs *τi*,*<sup>k</sup>* (*k* = 1, 2, . . .). If a task *τ<sup>i</sup>* is periodic, a generic job *τi*,*<sup>k</sup>* is regularly activated at time *ri*,*<sup>k</sup>* = Φ*<sup>i</sup>* + (*k* − 1)*Ti*. In general, the activation time of job *τi*,*k*+<sup>1</sup> is:

⎧ ⎨ ⎩ *ri*,*k*+<sup>1</sup> = *ri*,*<sup>k</sup>* + *Ti* if *τ<sup>i</sup>* is periodic *ri*,*k*+<sup>1</sup> ≥ *ri*,*<sup>k</sup>* + *Ti* if *τ<sup>i</sup>* is sporadic *ri*,*k*+<sup>1</sup> > *ri*,*<sup>k</sup>* if *τ<sup>i</sup>* is aperiodic.

Also, each job *τi*,*<sup>k</sup>* is characterized by an absolute deadline *di*,*<sup>k</sup>* = *ri*,*<sup>k</sup>* + *Di*. For a set of periodic tasks, the *hyperperiod H* denotes the minimum interval of time after which the schedule repeats itself. For a set of periodic tasks synchronously activated at time *t* = 0 (Φ*<sup>i</sup>* = 0, for all *i*), the hyperperiod is equal to the least common multiple of all the periods, that is *H* = lcm(*T*1,..., *Tn*).

In a real-time system, the computational load depends on the temporal characteristics of the executing activities. For example, for a set of *n* periodic tasks, the system load is equivalent to the processor utilization factor (Liu & Layland, 1973):

$$
\delta U = \sum\_{i=1}^{\mathcal{V}} \frac{\mathcal{C}\_i}{T\_i}. \tag{1}
$$

in Real-Time Systems 3

Handling Overload Conditions in Real-Time Systems 151

Note that, while the overload is a condition related to the processor, the overrun is a condition related to a single job. A job overrun does not necessarily cause an overload. However, a large unexpected overrun or a sequence of overruns on multiple jobs can cause very unpredictable

• **Transient overload due to task overruns**. This type of overload is due to periodic or aperiodic tasks that sporadically execute (or are activated) more than expected. Under fixed priority scheduling, an overrun in a task *τ<sup>i</sup>* does not affect tasks with higher priority, but any of the lower priority task could miss its deadline. Under the Earliest Deadline First (EDF) scheduling algorithm (Liu & Layland, 1973), a task overrun can potentially affect all the other tasks in the system. Figure 2 shows an example of an execution overrun under EDF scheduling. In this example, task *τ*<sup>3</sup> experiences an overrun of 7 units of time (shown

0 2 4 6 8 10 12 14 16 18

• **Permanent overload in periodic task systems**. This type of overload occurs when the total utilization of the periodic task set is greater than one. This can happen either because the execution requirement of the task set was not correctly estimated, or because of some unexpected activation of new periodic tasks, or because some of the current tasks increased their activation rate to react to some change in the environment. In such a situation, tasks start accumulating in the system's queues (which tend to become longer and longer, if the overload persists), and their response times tend to increase indefinitely. Figure 3 shows the effect of a permanent overload condition in a Rate Monotonic schedule, where computation times are *Ci*: (2, 3, 2), and periods are *Ti*: (4, 6, 8). Note that, since *Up* = 1.25,

If not properly handled, task overruns can cause serious problems in the real-time system, jeopardizing the guarantee performed for the critical tasks and causing an abrupt performance

To prevent an overrun to introducing unbounded delays on tasks' execution, the system could either decide to abort the current job experiencing the overrun or let it continue with a lower priority. The first solution is not safe, because the job could be in a critical section when aborted, thus leaving a shared resource with inconsistent data (very dangerous). The second solution is much more flexible, since the degree of interference caused by the overrun on the

deadline miss

deadline miss

(*execution overrun*).

effects on the system, if not properly handled.

τ 1

τ 2

τ 3

**2. Handling transient overloads**

degradation.

In this chapter, two types of overload conditions will be analyzed:

in light gray), since its expected execution time was *C*<sup>3</sup> = 3.

Fig. 2. Effect of an execution overrun in an EDF schedule.

*τ*<sup>2</sup> misses its deadline and *τ*<sup>3</sup> can never execute.

time (*activation overrun*), or because the job computation time exceeds its expected value

A value *U* > 1 means that the total computation time requested by the task set in the *hyperperiod* exceeds the available time on the processor (i.e, the length *H*); therefore, the task set cannot be scheduled by any algorithm.

For a generic set of real-time jobs that can be dynamically activated, the system load varies at each job activation and it is a function of the current time and the job deadlines. In general, if there are *n* active jobs at time *t*, with absolute deadlines *d*1, *d*2,..., *dn*, the *instantaneous load ρ*(*t*) can be defined as follows (Buttazzo & Stankovic, 1995):

$$\rho(t) = \max\_{i} \left\{ \frac{\sum\_{k \le d\_l} c\_k(t)}{d\_i - t} \right\},\tag{2}$$

where *ck*(*t*) denotes the remaining worst-case computation time of the *k*-th job. Figure 1 shows how the instantaneous load varies as a function of time for a set of three real-time jobs {*J*1, *J*2, *J*3} having activation times (*ri*: 3, 1, 2), computation times (*Ci*: 2, 3, 1), and relative deadlines (*Di*: 3, 6, 7).

Fig. 1. Instantaneous load as a function of time for a set of three real-time jobs.

When dealing with computational load, it is important to distinguish between overload and overrun:


2 Will-be-set-by-IN-TECH

A value *U* > 1 means that the total computation time requested by the task set in the *hyperperiod* exceeds the available time on the processor (i.e, the length *H*); therefore, the task

For a generic set of real-time jobs that can be dynamically activated, the system load varies at each job activation and it is a function of the current time and the job deadlines. In general, if there are *n* active jobs at time *t*, with absolute deadlines *d*1, *d*2,..., *dn*, the *instantaneous load*

> ⎧ ⎪⎨

∑ *dk*≤*di* *ck*(*t*)

⎫ ⎪⎬

⎪⎭ , (2)

t

*di* − *t*

⎪⎩

where *ck*(*t*) denotes the remaining worst-case computation time of the *k*-th job. Figure 1 shows how the instantaneous load varies as a function of time for a set of three real-time jobs {*J*1, *J*2, *J*3} having activation times (*ri*: 3, 1, 2), computation times (*Ci*: 2, 3, 1), and relative

02468 1 3 5 7 10 9

0 1 2 4 357 6 8 9 10

When dealing with computational load, it is important to distinguish between overload and

• A computing system is said to experience an **overload** when the computation time demanded by the task set in a certain interval of time exceeds the available processing

• A task is said to experience an **overrun** when it exceeds its expected utilization. An overrun may occur either because the next job is activated before its expected arrival

Fig. 1. Instantaneous load as a function of time for a set of three real-time jobs.

set cannot be scheduled by any algorithm.

deadlines (*Di*: 3, 6, 7).

J1

J2

J3

0.2

0.0

time in the same interval.

overrun:

0.4

0.6

0.8

1.0

ρ (t)

*ρ*(*t*) can be defined as follows (Buttazzo & Stankovic, 1995):

*ρ*(*t*) = max *i*

time (*activation overrun*), or because the job computation time exceeds its expected value (*execution overrun*).

Note that, while the overload is a condition related to the processor, the overrun is a condition related to a single job. A job overrun does not necessarily cause an overload. However, a large unexpected overrun or a sequence of overruns on multiple jobs can cause very unpredictable effects on the system, if not properly handled.

In this chapter, two types of overload conditions will be analyzed:

• **Transient overload due to task overruns**. This type of overload is due to periodic or aperiodic tasks that sporadically execute (or are activated) more than expected. Under fixed priority scheduling, an overrun in a task *τ<sup>i</sup>* does not affect tasks with higher priority, but any of the lower priority task could miss its deadline. Under the Earliest Deadline First (EDF) scheduling algorithm (Liu & Layland, 1973), a task overrun can potentially affect all the other tasks in the system. Figure 2 shows an example of an execution overrun under EDF scheduling. In this example, task *τ*<sup>3</sup> experiences an overrun of 7 units of time (shown in light gray), since its expected execution time was *C*<sup>3</sup> = 3.

Fig. 2. Effect of an execution overrun in an EDF schedule.

• **Permanent overload in periodic task systems**. This type of overload occurs when the total utilization of the periodic task set is greater than one. This can happen either because the execution requirement of the task set was not correctly estimated, or because of some unexpected activation of new periodic tasks, or because some of the current tasks increased their activation rate to react to some change in the environment. In such a situation, tasks start accumulating in the system's queues (which tend to become longer and longer, if the overload persists), and their response times tend to increase indefinitely. Figure 3 shows the effect of a permanent overload condition in a Rate Monotonic schedule, where computation times are *Ci*: (2, 3, 2), and periods are *Ti*: (4, 6, 8). Note that, since *Up* = 1.25, *τ*<sup>2</sup> misses its deadline and *τ*<sup>3</sup> can never execute.

#### **2. Handling transient overloads**

If not properly handled, task overruns can cause serious problems in the real-time system, jeopardizing the guarantee performed for the critical tasks and causing an abrupt performance degradation.

To prevent an overrun to introducing unbounded delays on tasks' execution, the system could either decide to abort the current job experiencing the overrun or let it continue with a lower priority. The first solution is not safe, because the job could be in a critical section when aborted, thus leaving a shared resource with inconsistent data (very dangerous). The second solution is much more flexible, since the degree of interference caused by the overrun on the

in Real-Time Systems 5

Handling Overload Conditions in Real-Time Systems 153

1. When a job *τi*,*<sup>j</sup>* arrives, if *qs* ≥ (*ds* − *ri*,*j*)*Us*, it is assigned a server deadline *ds* = *ri*,*<sup>j</sup>* + *Ps* and *qs* is recharged at the maximum value *Qs*, otherwise the job is served with the current

2. When *qs* = 0, the server budget is recharged at the maximum value *Qs* and the server deadline is postponed at *ds* = *ds* + *Ps*. Note that there are no finite intervals of time in

As shown in (Abeni & Buttazzo, 2004), if a task *τ<sup>i</sup>* is handled by a CBS with bandwidth *Us*, it will never demand more than *Us*, independently of the actual execution time of its jobs. As a consequence, possible overruns occurring in the served task do not create extra interference

To properly implement temporal protection, however, each task *τ<sup>i</sup>* with variable computation

(*τ*<sup>1</sup> and *τ*2) are served by two dedicated CBSs with bandwidth *Us*<sup>1</sup> = 0.15 and *Us*<sup>2</sup> = 0.1, a group of two tasks (*τ*3, *τ*4) is handled by a single CBS with bandwidth *Us*<sup>3</sup> = 0.25, and three hard periodic tasks (*τ*5, *τ*6, *τ*7) with utilization *Up* = 0.5 are directly scheduled by EDF, without server intercession, since their execution times are not subject to large variations. In this example, the total processor bandwidth is shared among the tasks as shown in Figure 5.

, so that it cannot interfere

CPU

. Figure 4 illustrates an example in which two tasks

EDF

Us2 = 0.1

*Up* + *Us*<sup>1</sup> + *Us*<sup>2</sup> + *Us*<sup>3</sup> ≤ 1. (3)

Us3 = 0.25

= 0.15

Us1

The properties of the CBS guarantee that the set of hard periodic tasks (with utilization *Up*) is

**HARD tasks**

time should be handled by a dedicated CBS with bandwidth *Usi*

Us1 = 0.15

Us2 = 0.1

Us3 = 0.25

CBS <sup>1</sup>

CBS <sup>3</sup>

Fig. 4. Achieving temporal protection using the CBS mechanism.

deadline using the current budget.

which the budget is equal to zero.

in the other tasks, but only affect *τi*.

τ 1

τ 3 τ 4

τ 5 τ 6 τ 7

with the rest of the tasks for more than *Usi*

<sup>τ</sup> <sup>2</sup> CBS <sup>2</sup>

Fig. 5. Bandwidth allocation for a set of task.

schedulable by EDF if and only if

Fig. 3. Example of a permanent overload under Rate Monotonic: *τ*<sup>2</sup> misses its deadline and *τ*<sup>3</sup> can never execute.

other tasks can be tuned acting on the priority assigned to the "faulty" task for executing the remaining computation. Such a solution can be efficiently implemented through the resource reservation approach, which is a general kernel technique for limiting the inter-task interference and isolating the temporal behavior of a task subset.

#### **2.1 Resource reservation**

Resource reservation is a general technique used in real-time systems for limiting the effects of overruns in tasks with variable computation times. According to this method, each task is assigned a fraction of the processor bandwidth, just enough to satisfy its timing constraints. The kernel, however, must prevent each task to consume more than the requested amount to protect the other tasks in the systems (temporal protection). In this way, a task receiving a fraction *Ui* of the total processor bandwidth behaves as it were executing alone on a slower processor with a speed equal to *Ui* times the full speed. The advantage of this method is that each task can be guaranteed in isolation, independently of the behavior of the other tasks.

A resource reservation technique for fixed priority scheduling was first presented by Mercer, Savage and Tokuda (Mercer et al., 1994). According to this method, a task *τ<sup>i</sup>* is handled by a server, which is a kernel mechanism capable of controlling the execution of the task assigned to it through a pair of parameters (*Qs*, *Ps*) (denoted as a CPU *capacity reserve*). The server enables *τ<sup>i</sup>* to execute for *Qs* units of time every *Ps*. In this case, the bandwidth reserved to the task is *Us* = *Qs*/*Ps*. When the task consumes its reserved quantum *Qs*, it is blocked until the next period, if the reservation is hard, or it is scheduled in background as a non real-time task, if the reservation is soft. If the task is not finished, it is assigned another time quantum *Qs* at the beginning of the next period and it is scheduled as a real-time task until the budget expires, and so on. In this way, the execution of *τ<sup>i</sup>* is *reshaped* to be more uniform along the timeline, so avoiding long intervals of time in which *τ<sup>i</sup>* prevents other tasks to run.

Under EDF scheduling, resource reservation can be efficiently implemented through the Constant Bandwidth Server (CBS) (Abeni & Buttazzo, 1998; 2004), which is a service mechanism also controlled by two parameters, (*Qs*, *Ps*), where *Qs* is the *server maximum budget* and *Ps* is the *server period*. The ratio *Us* = *Qs*/*Ps* is denoted as the *server bandwidth*. At each instant, two state variables are maintained: the server deadline *ds* and the actual server budget *qs*. Each job handled by a server is scheduled using the current server deadline and whenever the server executes a job, the budget *qs* is decreased by the same amount. At the beginning *ds* = *qs* = 0. Since a job is not activated while the previous one is active, the CBS algorithm can be formally defined as follows:

4 Will-be-set-by-IN-TECH

deadline miss

0 2 4 6 8 10 12 14 16 18

Fig. 3. Example of a permanent overload under Rate Monotonic: *τ*<sup>2</sup> misses its deadline and

other tasks can be tuned acting on the priority assigned to the "faulty" task for executing the remaining computation. Such a solution can be efficiently implemented through the resource reservation approach, which is a general kernel technique for limiting the inter-task

Resource reservation is a general technique used in real-time systems for limiting the effects of overruns in tasks with variable computation times. According to this method, each task is assigned a fraction of the processor bandwidth, just enough to satisfy its timing constraints. The kernel, however, must prevent each task to consume more than the requested amount to protect the other tasks in the systems (temporal protection). In this way, a task receiving a fraction *Ui* of the total processor bandwidth behaves as it were executing alone on a slower processor with a speed equal to *Ui* times the full speed. The advantage of this method is that each task can be guaranteed in isolation, independently of the behavior of the other tasks. A resource reservation technique for fixed priority scheduling was first presented by Mercer, Savage and Tokuda (Mercer et al., 1994). According to this method, a task *τ<sup>i</sup>* is handled by a server, which is a kernel mechanism capable of controlling the execution of the task assigned to it through a pair of parameters (*Qs*, *Ps*) (denoted as a CPU *capacity reserve*). The server enables *τ<sup>i</sup>* to execute for *Qs* units of time every *Ps*. In this case, the bandwidth reserved to the task is *Us* = *Qs*/*Ps*. When the task consumes its reserved quantum *Qs*, it is blocked until the next period, if the reservation is hard, or it is scheduled in background as a non real-time task, if the reservation is soft. If the task is not finished, it is assigned another time quantum *Qs* at the beginning of the next period and it is scheduled as a real-time task until the budget expires, and so on. In this way, the execution of *τ<sup>i</sup>* is *reshaped* to be more uniform along the

timeline, so avoiding long intervals of time in which *τ<sup>i</sup>* prevents other tasks to run.

Under EDF scheduling, resource reservation can be efficiently implemented through the Constant Bandwidth Server (CBS) (Abeni & Buttazzo, 1998; 2004), which is a service mechanism also controlled by two parameters, (*Qs*, *Ps*), where *Qs* is the *server maximum budget* and *Ps* is the *server period*. The ratio *Us* = *Qs*/*Ps* is denoted as the *server bandwidth*. At each instant, two state variables are maintained: the server deadline *ds* and the actual server budget *qs*. Each job handled by a server is scheduled using the current server deadline and whenever the server executes a job, the budget *qs* is decreased by the same amount. At the beginning *ds* = *qs* = 0. Since a job is not activated while the previous one is active, the CBS algorithm

interference and isolating the temporal behavior of a task subset.

τ 1

τ 2

τ 3

*τ*<sup>3</sup> can never execute.

**2.1 Resource reservation**

can be formally defined as follows:


As shown in (Abeni & Buttazzo, 2004), if a task *τ<sup>i</sup>* is handled by a CBS with bandwidth *Us*, it will never demand more than *Us*, independently of the actual execution time of its jobs. As a consequence, possible overruns occurring in the served task do not create extra interference in the other tasks, but only affect *τi*.

To properly implement temporal protection, however, each task *τ<sup>i</sup>* with variable computation time should be handled by a dedicated CBS with bandwidth *Usi* , so that it cannot interfere with the rest of the tasks for more than *Usi* . Figure 4 illustrates an example in which two tasks (*τ*<sup>1</sup> and *τ*2) are served by two dedicated CBSs with bandwidth *Us*<sup>1</sup> = 0.15 and *Us*<sup>2</sup> = 0.1, a group of two tasks (*τ*3, *τ*4) is handled by a single CBS with bandwidth *Us*<sup>3</sup> = 0.25, and three hard periodic tasks (*τ*5, *τ*6, *τ*7) with utilization *Up* = 0.5 are directly scheduled by EDF, without server intercession, since their execution times are not subject to large variations. In this example, the total processor bandwidth is shared among the tasks as shown in Figure 5.

Fig. 4. Achieving temporal protection using the CBS mechanism.

Fig. 5. Bandwidth allocation for a set of task.

The properties of the CBS guarantee that the set of hard periodic tasks (with utilization *Up*) is schedulable by EDF if and only if

$$\mathcal{U}\_p + \mathcal{U}\_{\mathfrak{s}\_1} + \mathcal{U}\_{\mathfrak{s}\_2} + \mathcal{U}\_{\mathfrak{s}\_3} \le 1. \tag{3}$$

in Real-Time Systems 7

Handling Overload Conditions in Real-Time Systems 155

*αk*

*t*

*<sup>t</sup>* (5)

*α<sup>k</sup>* = *Qk*/*Tk* (7) Δ*<sup>k</sup>* = 2(*Tk* − *Qk*). (8)

. (6)

. (9)

0

Δ*k*

Fig. 6. A reservation implemented by a static partition of intervals.

every period), then the effective bandwidth of reservation *Rk* is

Expressing *Qk* and *Tk* as a function of *α<sup>k</sup>* and Δ*<sup>k</sup>* we have

Hence,

*α*eff

*<sup>k</sup>* <sup>=</sup> *<sup>Q</sup>* <sup>−</sup> *<sup>σ</sup> Tk*

> *α*eff *<sup>k</sup>* = *α<sup>k</sup>* +

*α<sup>k</sup>* = lim *t*→∞

Δ*<sup>k</sup>* = sup *t*≥0

*Zk*(*t*)

*<sup>t</sup>* <sup>−</sup> *Zk*(*t*) *αk*

If a reservation is implemented using a periodic server with unspecified priority that allocates a budget *Qk* every period *Tk*, then the supply function is the one illustrated in Figure 7, where

It is worth observing that reservations with smaller delays are able to serve tasks with shorter deadlines, providing better responsiveness. However, small delays can only be achieved with servers with a small period, condition for which the context switch overhead cannot be neglected. If *σ* is the runtime overhead due to a context switch (subtracted from the budget

> = *α<sup>k</sup>* <sup>1</sup> <sup>−</sup> *<sup>σ</sup> Qk* .

2(1 − *αk*)

2(1 − *αk*)

2*σ*(1 − *αk*) Δ*k*

.

*Qk* <sup>=</sup> *<sup>α</sup>k*Δ*<sup>k</sup>*

*Pk* <sup>=</sup> <sup>Δ</sup>*<sup>k</sup>*

*Zk*(*t*)

Note that if condition (3) holds, the set of hard periodic tasks is always guaranteed to use 50% of the processor, independently of the execution times of the other tasks. Also observe that *τ*<sup>3</sup> and *τ*<sup>4</sup> are not isolated with respect to each other (i.e., one can steals processor time from the other), but they cannot interfere with the other tasks for more than one-fourth of the total processor bandwidth.

The CBS version presented in this book is meant for handling soft reservations. In fact, when the budget is exhausted, it is always replenished at its full value and the server deadline is postponed (i.e., the server is always active). As a consequence, a served task can execute more than *Qs* in each period *Ps*, if there are no other tasks in the system. However, the CBS can be easily modified to enforce hard reservations, just by postponing the budget replenishment to the server deadline.

### **2.2 Schedulability analysis**

Although a reservation *Rk* is typically implemented using a server characterized by a budget *Qk* and a period *Tk*, there are cases in which temporal isolation can be achieved by executing tasks in a static partition of disjoint time slots.

To characterize a bandwidth reservation independently on the specific implementation, Mok et al. (Mok et al., 2001) introduced the concept of *bounded delay partition* that describes a reservation *Rk* by two parameters: a bandwidth *α<sup>k</sup>* and a delay Δ*k*. The bandwidth *α<sup>k</sup>* measures the fraction of resource that is assigned to the served tasks, whereas the delay Δ*<sup>k</sup>* represents the longest interval of time in which the resource is not available. In general, the minimum service provided by a resource can be precisely described by its *supply function* (Lipari & Bini, 2003; Shin & Lee, 2003), representing the minimum amount of time the resource can provide in a given interval of time.

**Definition 1.** *Given a reservation, the* supply function *Zk*(*t*) *is the minimum amount of time provided by the reservation in every time interval of length t* ≥ 0*.*

The supply function can be defined for many kinds of reservations, as static time partitions (Feng & Mok, 2002; Mok et al., 2001), periodic servers (Lipari & Bini, 2003; Shin & Lee, 2003), or periodic servers with arbitrary deadline (Easwaran et al., 2007). Consider, for example, that processing time is provided only in the intervals [0,3], [6,8], and [9,10], with a period of 12 units. In this case, the minimum service occurs when the resource is requested at the beginning of the longest idle interval; hence, the supply function is the one depicted in Figure 6.

For this example we have *α<sup>k</sup>* = 0.5 and Δ*<sup>k</sup>* = 3. Once the bandwidth and the delay are computed, the supply function of a resource reservation can be lower bounded by the following *supply bound function*:

$$\mathsf{sfd}\_{k}(t) \stackrel{\text{def}}{=} \max\{0, \,\alpha\_{k}(t-\Delta\_{k})\}.\tag{4}$$

represented by the dashed line in Figure 6. The advantage of using such a lower bound instead of the exact *Zk*(*t*) is that a reservation can be expressed with just two parameters. In general, for a given supply function *Zk*(*t*), the bandwidth *α<sup>k</sup>* and the delay Δ*<sup>k</sup>* can be formally defined as follows:

6 Will-be-set-by-IN-TECH

Note that if condition (3) holds, the set of hard periodic tasks is always guaranteed to use 50% of the processor, independently of the execution times of the other tasks. Also observe that *τ*<sup>3</sup> and *τ*<sup>4</sup> are not isolated with respect to each other (i.e., one can steals processor time from the other), but they cannot interfere with the other tasks for more than one-fourth of the total

The CBS version presented in this book is meant for handling soft reservations. In fact, when the budget is exhausted, it is always replenished at its full value and the server deadline is postponed (i.e., the server is always active). As a consequence, a served task can execute more than *Qs* in each period *Ps*, if there are no other tasks in the system. However, the CBS can be easily modified to enforce hard reservations, just by postponing the budget replenishment to

Although a reservation *Rk* is typically implemented using a server characterized by a budget *Qk* and a period *Tk*, there are cases in which temporal isolation can be achieved by executing

To characterize a bandwidth reservation independently on the specific implementation, Mok et al. (Mok et al., 2001) introduced the concept of *bounded delay partition* that describes a reservation *Rk* by two parameters: a bandwidth *α<sup>k</sup>* and a delay Δ*k*. The bandwidth *α<sup>k</sup>* measures the fraction of resource that is assigned to the served tasks, whereas the delay Δ*<sup>k</sup>* represents the longest interval of time in which the resource is not available. In general, the minimum service provided by a resource can be precisely described by its *supply function* (Lipari & Bini, 2003; Shin & Lee, 2003), representing the minimum amount of time the

**Definition 1.** *Given a reservation, the* supply function *Zk*(*t*) *is the minimum amount of time*

The supply function can be defined for many kinds of reservations, as static time partitions (Feng & Mok, 2002; Mok et al., 2001), periodic servers (Lipari & Bini, 2003; Shin & Lee, 2003), or periodic servers with arbitrary deadline (Easwaran et al., 2007). Consider, for example, that processing time is provided only in the intervals [0,3], [6,8], and [9,10], with a period of 12 units. In this case, the minimum service occurs when the resource is requested at the beginning of the longest idle interval; hence, the supply function is the one depicted in

For this example we have *α<sup>k</sup>* = 0.5 and Δ*<sup>k</sup>* = 3. Once the bandwidth and the delay are computed, the supply function of a resource reservation can be lower bounded by the

represented by the dashed line in Figure 6. The advantage of using such a lower bound instead of the exact *Zk*(*t*) is that a reservation can be expressed with just two parameters. In general, for a given supply function *Zk*(*t*), the bandwidth *α<sup>k</sup>* and the delay Δ*<sup>k</sup>* can be formally defined

= max{0, *α<sup>k</sup>* (*t* − Δ*k*)}. (4)

sbf *<sup>k</sup>*(*t*) def

processor bandwidth.

the server deadline.

Figure 6.

as follows:

following *supply bound function*:

**2.2 Schedulability analysis**

tasks in a static partition of disjoint time slots.

resource can provide in a given interval of time.

*provided by the reservation in every time interval of length t* ≥ 0*.*

Fig. 6. A reservation implemented by a static partition of intervals.

$$\mu\_k = \lim\_{t \to \infty} \frac{Z\_k(t)}{t} \tag{5}$$

$$\Delta\_k = \sup\_{t \ge 0} \left\{ t - \frac{Z\_k(t)}{\alpha\_k} \right\}. \tag{6}$$

If a reservation is implemented using a periodic server with unspecified priority that allocates a budget *Qk* every period *Tk*, then the supply function is the one illustrated in Figure 7, where

$$
\mathfrak{a}\_k = \mathbb{Q}\_k / T\_k \tag{7}
$$

$$
\Delta\_k = \mathcal{Z}(T\_k - Q\_k). \tag{8}
$$

It is worth observing that reservations with smaller delays are able to serve tasks with shorter deadlines, providing better responsiveness. However, small delays can only be achieved with servers with a small period, condition for which the context switch overhead cannot be neglected. If *σ* is the runtime overhead due to a context switch (subtracted from the budget every period), then the effective bandwidth of reservation *Rk* is

$$
\mathfrak{a}\_k^{\text{eff}} = \frac{Q - \sigma}{T\_k} = \mathfrak{a}\_k \left( 1 - \frac{\sigma}{Q\_k} \right).
$$

Expressing *Qk* and *Tk* as a function of *α<sup>k</sup>* and Δ*<sup>k</sup>* we have

$$Q\_k = \frac{\alpha\_k \Delta\_k}{2(1 - \alpha\_k)}$$

$$P\_k = \frac{\Delta\_k}{2(1 - \alpha\_k)}.$$

Hence,

$$
\alpha\_k^{\text{eff}} = \alpha\_k + \frac{2\sigma(1 - \alpha\_k)}{\Delta\_k}.\tag{9}
$$

in Real-Time Systems 9

Handling Overload Conditions in Real-Time Systems 157

**Theorem 3** (Bertogna et al., 2009)**.** *A set of preemptive periodic tasks with utilization Up and relative deadlines less than or equal to periods can be scheduled by EDF, under a reservation characterized by a*

D = {*dk* | *dk* ≤ min[*H*, max(*Dmax*, *L*∗)]}

Although resource reservation is essential for achieving predictability in the presence of tasks with variable execution times, the overall system performance becomes quite dependent on a correct bandwidth allocation. In fact, if the CPU bandwidth allocated to a task is much less than its average requested value, the task may slow down too much, degrading the system's performance. On the other hand, if the allocated bandwidth is much greater than the actual needs, the system will run with low efficiency, wasting the available resources. This problem can be solved by using capacity sharing mechanisms that can transfer unused budgets to the

Capacity sharing algorithms have been developed both under fixed priority servers (Bernat et al., December 5-8, 2004; Bernat & Burns, 2002) and dynamic priority servers (Caccamo et al., 2000). For example, the CASH algorithm (Caccamo et al., 2005) extends CBS to include a slack reclamation. When a server becomes idle with residual budget, the slack is inserted in a queue of spare budgets (CASH queue) ordered by server deadlines. Whenever a new server is scheduled for execution, it first uses any CASH budget whose deadline is less than or equal

The bandwidth inheritance (BWI) algorithm (Lamastra et al., December 3-6, 2001) applies the idea of priority inheritance to CPU resources in CBS, allowing a blocking low-priority process to steal resources from a blocked higher priority process. IRIS (Marzario et al., 2004) enhances CBS with fairer slack reclaiming, so slack is not reclaimed until all current jobs have been serviced and the processor is idle. BACKSLASH (Lin & Brandt, December 5U8, 2005) is ˝ another algorithm that enhances the efficiency of the reclaiming mechanism under EDF.

Wrong reservations can also be handled through feedback scheduling. If the operating system is able to monitor the actual execution time *ei*,*<sup>k</sup>* of each task instance, the actual maximum

*<sup>i</sup>* = max

*<sup>i</sup>* = *C*ˆ

value in a feedback loop to adapt the reservation bandwidth allocated to the task according to the actual needs. If more reservations are adapted online, we must ensure that the overall allocated bandwidth does not exceed the processor utilization; hence, a form of global feedback adaptation is required to prevent an overload condition. Similar approaches to

*<sup>k</sup>* {*ei*,*k*}

*<sup>i</sup>*/*Ti*. Hence, *U*ˆ

*<sup>i</sup>* can be used as a reference

computation time of a task *τ<sup>i</sup>* can be estimated (in a moving window) as

*C*ˆ

*α<sup>k</sup>* − *Up*

*<sup>L</sup>*<sup>∗</sup> <sup>=</sup> *<sup>α</sup>k*Δ*<sup>k</sup>* <sup>+</sup> <sup>∑</sup>*<sup>n</sup>*

∀*t* ∈ D dbf(*t*) ≤ max[0, *αk*(*t* − Δ*k*)]. (14)

.

*<sup>i</sup>*=1(*Ti* − *Di*)*Ui*

*supply function Zk*(*t*) = max[0, *αk*(*t* − Δ*k*)]*, if Up* < *α<sup>k</sup> and*

*where*

*and*

to its own.

**2.3 Handling wrong reservations**

reservations that need more bandwidth.

and the actual requested bandwidth as *U*ˆ

Fig. 7. A reservation implemented by a periodic server.

Within a reservation, the schedulability analysis of a task set under fixed priorities can be performed through the following Theorem (Bini et al., 2009):

**Theorem 1** (Bini et al., 2009)**.** *A set of preemptive periodic tasks with relative deadlines less than or equal to periods can be scheduled by a fixed priority algorithm, under a reservation characterized by a supply function Zk*(*t*)*, if and only if*

$$\forall i = 1, \ldots, n \quad \exists t \in (0, D\_i] : \mathcal{W}\_i(t) \le Z\_k(t). \tag{10}$$

*where Wi*(*t*) *represents the Level-i workload, computed as follows:*

$$\mathcal{W}\_i(t) = \mathbb{C}\_i + \sum\_{h:\mathcal{P}\_h > P\_i} \left\lceil \frac{t}{T\_h} \right\rceil \mathcal{C}\_h. \tag{11}$$

Similarly, the schedulability analysis of a task set under EDF can be performed using the following theorem (Bini et al., 2009):

**Theorem 2** (Bini et al., 2009)**.** *A set of preemptive periodic tasks with utilization Up and relative deadlines less than or equal to periods can be scheduled by EDF, under a reservation characterized by a supply function Zk*(*t*)*, if and only if Up* < *α<sup>k</sup> and*

$$\forall t > 0 \quad \mathsf{dbf}(t) \le Z\_k(t). \tag{12}$$

*where* dbf(*t*) *is the Demand Bound Function (Baruah et al., 1990) defined as*

$$\mathbf{dbf}(t) \stackrel{\text{def}}{=} \sum\_{i=1}^{n} \left\lfloor \frac{t + T\_i - D\_i}{T\_i} \right\rfloor \mathbf{C}\_i. \tag{13}$$

In the specific case in which *Zk*(*t*) is lower bounded by the supply bound function, the test becomes only sufficient and the set of testing points can be better restricted as stated in the following theorem (Bertogna et al., 2009):

**Theorem 3** (Bertogna et al., 2009)**.** *A set of preemptive periodic tasks with utilization Up and relative deadlines less than or equal to periods can be scheduled by EDF, under a reservation characterized by a supply function Zk*(*t*) = max[0, *αk*(*t* − Δ*k*)]*, if Up* < *α<sup>k</sup> and*

$$\forall t \in \mathcal{D} \quad \mathsf{dbf}(t) \le \max[0, \varkappa\_k(t - \Delta\_k)].\tag{14}$$

*where*

8 Will-be-set-by-IN-TECH

Within a reservation, the schedulability analysis of a task set under fixed priorities can be

**Theorem 1** (Bini et al., 2009)**.** *A set of preemptive periodic tasks with relative deadlines less than or equal to periods can be scheduled by a fixed priority algorithm, under a reservation characterized by a*

*h*:*Ph*>*Pi*

Similarly, the schedulability analysis of a task set under EDF can be performed using the

**Theorem 2** (Bini et al., 2009)**.** *A set of preemptive periodic tasks with utilization Up and relative deadlines less than or equal to periods can be scheduled by EDF, under a reservation characterized by a*

In the specific case in which *Zk*(*t*) is lower bounded by the supply bound function, the test becomes only sufficient and the set of testing points can be better restricted as stated in the

 *<sup>t</sup>* <sup>+</sup> *Ti* <sup>−</sup> *Di Ti*

 *t Th* 

*Wi*(*t*) = *Ci* + ∑

*where* dbf(*t*) *is the Demand Bound Function (Baruah et al., 1990) defined as*

dbf(*t*) def = *n* ∑ *i*=1

Δ *t*

∀*i* = 1, . . . , *n* ∃*t* ∈ (0, *Di*] : *Wi*(*t*) ≤ *Zk*(*t*). (10)

∀*t* > 0 dbf(*t*) ≤ *Zk*(*t*). (12)

*Ch*. (11)

*Ci*. (13)

*α*

0

*supply function Zk*(*t*)*, if and only if*

following theorem (Bini et al., 2009):

*supply function Zk*(*t*)*, if and only if Up* < *α<sup>k</sup> and*

following theorem (Bertogna et al., 2009):

2(*P* − *Q*) Fig. 7. A reservation implemented by a periodic server.

performed through the following Theorem (Bini et al., 2009):

*where Wi*(*t*) *represents the Level-i workload, computed as follows:*

Q

Q

2Q

3Q

*Z*(*t*)

$$\mathcal{D} = \{d\_k \mid d\_k \le \min[H\_\prime \max(D\_{\max\prime} L^\*)]\}$$

*and*

$$L^\* = \frac{\alpha\_k \Delta\_k + \sum\_{i=1}^n (T\_i - D\_i) \mathcal{U}\_i}{\alpha\_k - \mathcal{U}\_p}.$$

#### **2.3 Handling wrong reservations**

Although resource reservation is essential for achieving predictability in the presence of tasks with variable execution times, the overall system performance becomes quite dependent on a correct bandwidth allocation. In fact, if the CPU bandwidth allocated to a task is much less than its average requested value, the task may slow down too much, degrading the system's performance. On the other hand, if the allocated bandwidth is much greater than the actual needs, the system will run with low efficiency, wasting the available resources. This problem can be solved by using capacity sharing mechanisms that can transfer unused budgets to the reservations that need more bandwidth.

Capacity sharing algorithms have been developed both under fixed priority servers (Bernat et al., December 5-8, 2004; Bernat & Burns, 2002) and dynamic priority servers (Caccamo et al., 2000). For example, the CASH algorithm (Caccamo et al., 2005) extends CBS to include a slack reclamation. When a server becomes idle with residual budget, the slack is inserted in a queue of spare budgets (CASH queue) ordered by server deadlines. Whenever a new server is scheduled for execution, it first uses any CASH budget whose deadline is less than or equal to its own.

The bandwidth inheritance (BWI) algorithm (Lamastra et al., December 3-6, 2001) applies the idea of priority inheritance to CPU resources in CBS, allowing a blocking low-priority process to steal resources from a blocked higher priority process. IRIS (Marzario et al., 2004) enhances CBS with fairer slack reclaiming, so slack is not reclaimed until all current jobs have been serviced and the processor is idle. BACKSLASH (Lin & Brandt, December 5U8, 2005) is ˝ another algorithm that enhances the efficiency of the reclaiming mechanism under EDF.

Wrong reservations can also be handled through feedback scheduling. If the operating system is able to monitor the actual execution time *ei*,*<sup>k</sup>* of each task instance, the actual maximum computation time of a task *τ<sup>i</sup>* can be estimated (in a moving window) as

$$
\hat{C}\_i = \max\_k \{ e\_{i,k} \}
$$

and the actual requested bandwidth as *U*ˆ *<sup>i</sup>* = *C*ˆ *<sup>i</sup>*/*Ti*. Hence, *U*ˆ *<sup>i</sup>* can be used as a reference value in a feedback loop to adapt the reservation bandwidth allocated to the task according to the actual needs. If more reservations are adapted online, we must ensure that the overall allocated bandwidth does not exceed the processor utilization; hence, a form of global feedback adaptation is required to prevent an overload condition. Similar approaches to

in Real-Time Systems 11

Handling Overload Conditions in Real-Time Systems 159

where *Ci* is the worst-case computation time, *Ti* its period, *Di* its relative deadline (assumed to be equal to the period), and *Si* a skip parameter, 2 ≤ *Si* ≤ ∞, expressing the minimum distance between two consecutive skips. For example, if *Si* = 5 the task can skip one instance every five. When *Si* = ∞ no skips are allowed and *τ<sup>i</sup>* is equivalent to a hard periodic task. The skip parameter can be viewed as a *Quality of Service* (QoS) metric (the higher *Si*, the better the

Using the terminology introduced by Koren and Shasha (Koren & Shasha, 1995), every job of a periodic task can be *red* or *blue*: a red job must be completed within its deadline, whereas a blue job can be aborted at any time. To meet the constraint imposed by the skip parameter *Si*,

The authors showed that making optimal use of skips is NP-hard and presented two algorithms (one working under Rate Monotonic and one under EDF) that exploit skips to schedule slightly overloaded systems. In general, these algorithms are not optimal, but they

**Definition 2.** *A system is* deeply-red *if all tasks are synchronously activated and the first Si* − 1

Koren and Shasha showed that the worst case for a periodic skippable task set occurs when tasks are deeply-red. For this reason, the feasibility tests are derived under this condition, so that, if a task set is schedulable under the deeply-red condition, it is also schedulable in any

The feasibility analysis of a set of firm tasks can be performed through the Processor Demand Criterion (Baruah et al., 1990) under the deeply-red condition, assuming that in the worst case all blue jobs are aborted. In such a worst-case scenario, the processor demand of *τ<sup>i</sup>* due to the red jobs in an interval [0, *t*] can be obtained as the difference between the demand of all the

> *Ti* − *t TiSi*

*Ci*. (15)

*Ci* <sup>≤</sup> *<sup>t</sup>*. (16)

≤ 1. (17)

each scheduling algorithm must have the following characteristics: • if a blue job is skipped, then the next *Si* − 1 jobs must be red. • if a blue job completes successfully, the next job is also blue.

dbf*skip*

when the utilization factor due to the red jobs is greater than one.

∀*t* ≥ 0

*<sup>i</sup>* (*t*) = *<sup>t</sup>*

*n* ∑ *i*=1

*n* ∑ *i*=1

Hence, the feasibility of the task set can be verified through the following theorem. **Theorem 4** (Koren and Shasha, 1995)**.** *A set of firm periodic tasks is schedulable by EDF if*

> *t Ti* − *t TiSi*

A necessary condition can be easily derived by observing that a schedule is certainly infeasible

**Theorem 5** (Koren and Shasha, 1995)**.** *Necessary condition for the schedulability of a set of firm*

*Ci*(*Si* − 1) *TiSi*

become optimal under a particular condition, called the *deeply-red* condition.

quality of service).

*instances of every task τ<sup>i</sup> are red.*

**3.1.1 Schedulability analysis**

jobs and the demand of the blue jobs:

other situation.

*periodic tasks is that*

achieve adaptive reservations have been proposed by Abeni and Buttazzo (Abeni & Buttazzo, May 30 - June 1, 2001) and by Palopoli et al. (Palopoli et al., December 3-5, 2002).

#### **3. Handling permanent overloads**

This section presents some methodologies for handling permanent overload conditions occurring in periodic task systems when the total processor utilization exceeds one. Basically, there are three methods to reduce the load:


#### **3.1 Job skipping**

The computational load of a set of periodic tasks can be reduced by properly *skipping* a few jobs in the task set, in such a way that the remaining jobs can be scheduled within their deadlines. This approach is suitable for real-time applications characterized by soft or firm deadlines, such as those typically found in multimedia systems, where skipping a video frame once in a while is better than processing it with a long delay. Even in certain control applications, the sporadic skip of some job can be tolerated when the controlled systems is characterized by a high inertia.

To understand how job skipping can make an overloaded system schedulable, consider the following example, consisting of two tasks, with computation times *C*<sup>1</sup> = 2 and *C*<sup>2</sup> = 8 and periods *T*<sup>1</sup> = 4 and *T*<sup>2</sup> = 12. Since the processor utilization factor is *Up* = 14/12 > 1, the system is under a permanent overload, and the tasks cannot be scheduled within their deadlines. Nevertheless, Figure 8 shows that skipping a job every three in task *τ*<sup>1</sup> the overload can be resolved and all the remaining jobs can be scheduled within their deadlines.

Fig. 8. Overload condition resolved by skipping one job every three in task *τ*1.

In order to control the overall system load, it is important to derive the relation between the number of skips (i.e., the number of aborted jobs per task) and the total computational demand. In 1995, Koren and Shasha (Koren & Shasha, 1995) proposed a new task model (known as the *firm* periodic model) suited to be handled by this technique. According to this model, each periodic task *τ<sup>i</sup>* is characterized by the following parameters:

$$\pi\_i(\mathbf{C}\_{i\nu}T\_{i\nu}D\_{i\nu}S\_i)$$

10 Will-be-set-by-IN-TECH

achieve adaptive reservations have been proposed by Abeni and Buttazzo (Abeni & Buttazzo,

This section presents some methodologies for handling permanent overload conditions occurring in periodic task systems when the total processor utilization exceeds one. Basically,

• **Job skipping.** This method reduces the total load by properly skipping (i.e., aborting) some job execution in the periodic tasks, in such a way that a minimum number of jobs per

• **Period adaptation.** According to this approach, the load is reduced by enlarging task periods to suitable values, so that the total workload can be kept below a desired threshold. • **Service adaptation.** According to this method, the load is reduced by decreasing the computational requirements of the tasks, trading predictability with quality of service.

The computational load of a set of periodic tasks can be reduced by properly *skipping* a few jobs in the task set, in such a way that the remaining jobs can be scheduled within their deadlines. This approach is suitable for real-time applications characterized by soft or firm deadlines, such as those typically found in multimedia systems, where skipping a video frame once in a while is better than processing it with a long delay. Even in certain control applications, the sporadic skip of some job can be tolerated when the controlled systems is

To understand how job skipping can make an overloaded system schedulable, consider the following example, consisting of two tasks, with computation times *C*<sup>1</sup> = 2 and *C*<sup>2</sup> = 8 and periods *T*<sup>1</sup> = 4 and *T*<sup>2</sup> = 12. Since the processor utilization factor is *Up* = 14/12 > 1, the system is under a permanent overload, and the tasks cannot be scheduled within their deadlines. Nevertheless, Figure 8 shows that skipping a job every three in task *τ*<sup>1</sup> the overload

0 2 4 6 8 10 12 14 16 18 20 22 24 26

In order to control the overall system load, it is important to derive the relation between the number of skips (i.e., the number of aborted jobs per task) and the total computational demand. In 1995, Koren and Shasha (Koren & Shasha, 1995) proposed a new task model (known as the *firm* periodic model) suited to be handled by this technique. According to this

*τi*(*Ci*, *Ti*, *Di*, *Si*)

0 2 4 6 8 10 12 14 16 18 20 22 24 26

skip skip

can be resolved and all the remaining jobs can be scheduled within their deadlines.

Fig. 8. Overload condition resolved by skipping one job every three in task *τ*1.

model, each periodic task *τ<sup>i</sup>* is characterized by the following parameters:

May 30 - June 1, 2001) and by Palopoli et al. (Palopoli et al., December 3-5, 2002).

task is guaranteed to execute within their timing constraints.

**3. Handling permanent overloads**

**3.1 Job skipping**

τ 1

τ 2

characterized by a high inertia.

there are three methods to reduce the load:

where *Ci* is the worst-case computation time, *Ti* its period, *Di* its relative deadline (assumed to be equal to the period), and *Si* a skip parameter, 2 ≤ *Si* ≤ ∞, expressing the minimum distance between two consecutive skips. For example, if *Si* = 5 the task can skip one instance every five. When *Si* = ∞ no skips are allowed and *τ<sup>i</sup>* is equivalent to a hard periodic task. The skip parameter can be viewed as a *Quality of Service* (QoS) metric (the higher *Si*, the better the quality of service).

Using the terminology introduced by Koren and Shasha (Koren & Shasha, 1995), every job of a periodic task can be *red* or *blue*: a red job must be completed within its deadline, whereas a blue job can be aborted at any time. To meet the constraint imposed by the skip parameter *Si*, each scheduling algorithm must have the following characteristics:


The authors showed that making optimal use of skips is NP-hard and presented two algorithms (one working under Rate Monotonic and one under EDF) that exploit skips to schedule slightly overloaded systems. In general, these algorithms are not optimal, but they become optimal under a particular condition, called the *deeply-red* condition.

**Definition 2.** *A system is* deeply-red *if all tasks are synchronously activated and the first Si* − 1 *instances of every task τ<sup>i</sup> are red.*

Koren and Shasha showed that the worst case for a periodic skippable task set occurs when tasks are deeply-red. For this reason, the feasibility tests are derived under this condition, so that, if a task set is schedulable under the deeply-red condition, it is also schedulable in any other situation.

#### **3.1.1 Schedulability analysis**

The feasibility analysis of a set of firm tasks can be performed through the Processor Demand Criterion (Baruah et al., 1990) under the deeply-red condition, assuming that in the worst case all blue jobs are aborted. In such a worst-case scenario, the processor demand of *τ<sup>i</sup>* due to the red jobs in an interval [0, *t*] can be obtained as the difference between the demand of all the jobs and the demand of the blue jobs:

$$\mathbf{dbf}\_{i}^{\text{skip}}(t) = \left( \left\lfloor \frac{t}{T\_i} \right\rfloor - \left\lfloor \frac{t}{T\_i S\_i} \right\rfloor \right) \mathbf{C}\_i. \tag{15}$$

Hence, the feasibility of the task set can be verified through the following theorem.

**Theorem 4** (Koren and Shasha, 1995)**.** *A set of firm periodic tasks is schedulable by EDF if*

$$\forall t \ge 0 \qquad \sum\_{i=1}^{n} \left( \left\lfloor \frac{t}{T\_i} \right\rfloor - \left\lfloor \frac{t}{T\_i S\_i} \right\rfloor \right) \mathbb{C}\_i \le t. \tag{16}$$

A necessary condition can be easily derived by observing that a schedule is certainly infeasible when the utilization factor due to the red jobs is greater than one.

**Theorem 5** (Koren and Shasha, 1995)**.** *Necessary condition for the schedulability of a set of firm periodic tasks is that*

$$\sum\_{i=1}^{n} \frac{\mathbb{C}\_{i}(\mathbb{S}\_{i} - 1)}{T\_{i}\mathbb{S}\_{i}} \le 1. \tag{17}$$

in Real-Time Systems 13

Handling Overload Conditions in Real-Time Systems 161

⎧ ⎨ ⎩ ∑*i* � *<sup>t</sup> Ti* � *Ci*

> �� ≤ � *t Ti* � .

The bandwidth saved by skips can also be exploited by an aperiodic server to advance the

There are several real-time applications in which timing constraints are not rigid, but depend on the system state. The possibility of varying tasks' rates increases the flexibility of the system in handling overload conditions, providing a more general admission control mechanism. For example, if the total utilization of the task set is greater than one, the system could reduce the utilizations of some tasks (by increasing their periods in a controlled fashion) to decrease the

The elastic model presented in this section (originally introduced Buttazzo et al. (Buttazzo et al., 1998) and later extended by the same authors to deal with resource constraints (Buttazzo et al., 2002)), provides a novel theoretical framework for flexible workload management in

The basic idea behind the elastic model is to consider each task as flexible as a spring with a given rigidity coefficient and length constraints. In particular, the utilization of a task is treated as an elastic parameter, whose value can be modified by changing the period within a specified range. Each task is characterized by four parameters: a computation time *Ci*, a

specifies the flexibility of the task to vary its utilization for adapting the system to a new feasible rate configuration. The greater *Ei*, the more elastic the task. Thus, an elastic task is

*<sup>i</sup>* , *<sup>T</sup>max*

In the following, *Ti* denotes the actual period of task *τi*, which is constrained to be in the

range. Any variation, however, is subject to an *elastic guarantee* and is accepted only if there is

It is worth noting that the elastic model is more general than the classical Liu and Layland's task model (Liu & Layland, 1973), so it does not prevent a user from defining hard real-time

period, independently of its elastic coefficient. A task with *Ei* = 0 can arbitrarily vary its period within its specified range, but it cannot be varied by the system during load

*<sup>i</sup>* , *Ei*).

*<sup>i</sup>* ]. Any task can vary its period according to its needs within the specified

*τi*(*Ci*, *Tmin*

*<sup>i</sup>* , and an elastic coefficient *Ei* ≥ 0, which

*<sup>i</sup>* is equivalent to a hard real-time task with fixed

*<sup>i</sup>* , a maximum period *<sup>T</sup>max*

a feasible schedule in which all the other periods are within their range.

*<sup>i</sup>* <sup>=</sup> *<sup>T</sup>min*

*t*

⎫ ⎬ ⎭ .

*Up* = max *t*≥0

�� *t Ti* � − � *t TiSi*

(18) (setting *Si* = ∞), *Up* can also be defined as

*<sup>p</sup>* ≤ *Up* because

execution of aperiodic tasks.

**3.2 Period adaptation**

real-time applications.

**3.2.1 The elastic model**

minimum period *Tmin*

*<sup>i</sup>* , *<sup>T</sup>max*

tasks. In fact, a task having *Tmax*

denoted as

range [*Tmin*

reconfigurations.

Thus, *Uskip*

total load.

To better clarify the concepts mentioned above, consider the task set shown in Figure 9 and the corresponding feasible schedule, obtained by EDF. Note that the processor utilization factor is greater than 1 (*Up* = 1.25), but both conditions (16) and (17) are satisfied.

Fig. 9. A set of firm periodic tasks schedulable by EDF.

If skips are permitted in the periodic task set, the spare time saved by rejecting the blue instances can be reallocated for other purposes. For example, for scheduling slightly overloaded systems or for advancing the execution of soft aperiodic requests.

Unfortunately, the spare time has a "granular" distribution and cannot be reclaimed at any time. Nevertheless, it can be shown that skipping blue instances still produces a bandwidth saving in the periodic schedule. Caccamo and Buttazzo (Caccamo & Buttazzo, 1997) identified the amount of bandwidth saved by skips using a simple parameter, the *equivalent utilization factor Uskip <sup>p</sup>* , which can be defined as

$$\mathcal{U}\_p^{skip} = \max\_{t \ge 0} \left\{ \frac{\sum\_i \text{dbf}\_i^{skip}(t)}{t} \right\} \tag{18}$$

where dbf*skip <sup>i</sup>* (*t*) is given in Equation (15).

Using this definition, the schedulability of a deeply-red skippable task set can be also verified using the following theorem (Caccamo & Buttazzo, 1997):

**Theorem 6** (Caccamo and Buttazzo, 1997)**.** *A set* Γ *of deeply-red skippable periodic tasks is schedulable by EDF if*

$$
\mathcal{U}\_p^{skip} \le 1.
$$

Note that the *Uskip <sup>p</sup>* factor represents the net bandwidth really used by periodic tasks, under the deeply-red condition. It is easy to show that *Uskip <sup>p</sup>* ≤ *Up*. In fact, according to Equation (18) (setting *Si* = ∞), *Up* can also be defined as

$$\mathcal{U}\_p = \max\_{t \ge 0} \left\{ \frac{\sum\_{i} \left\lfloor \frac{t}{T\_i} \right\rfloor C\_i}{t} \right\}.$$

Thus, *Uskip <sup>p</sup>* ≤ *Up* because

12 Will-be-set-by-IN-TECH

To better clarify the concepts mentioned above, consider the task set shown in Figure 9 and the corresponding feasible schedule, obtained by EDF. Note that the processor utilization factor

> **Task** *Ci Ti Di Si τ*<sup>1</sup> 1 3 3 4 *τ*<sup>2</sup> 2 4 4 3 *τ*<sup>3</sup> 5 12 12 ∞

skip skip

15

0 9 3 6 12 18 21 24 27

skip

0 24

If skips are permitted in the periodic task set, the spare time saved by rejecting the blue instances can be reallocated for other purposes. For example, for scheduling slightly

Unfortunately, the spare time has a "granular" distribution and cannot be reclaimed at any time. Nevertheless, it can be shown that skipping blue instances still produces a bandwidth saving in the periodic schedule. Caccamo and Buttazzo (Caccamo & Buttazzo, 1997) identified the amount of bandwidth saved by skips using a simple parameter, the *equivalent utilization*

Using this definition, the schedulability of a deeply-red skippable task set can be also verified

**Theorem 6** (Caccamo and Buttazzo, 1997)**.** *A set* Γ *of deeply-red skippable periodic tasks is*

*Uskip <sup>p</sup>* ≤ 1.

<sup>∑</sup>*<sup>i</sup>* dbf*skip <sup>i</sup>* (*t*) *t*

*<sup>p</sup>* factor represents the net bandwidth really used by periodic tasks, under

*<sup>p</sup>* ≤ *Up*. In fact, according to Equation

(18)

0 4 8 12 16 20 24

12

overloaded systems or for advancing the execution of soft aperiodic requests.

*Uskip <sup>p</sup>* = max *t*≥0

Fig. 9. A set of firm periodic tasks schedulable by EDF.

*<sup>p</sup>* , which can be defined as

*<sup>i</sup>* (*t*) is given in Equation (15).

using the following theorem (Caccamo & Buttazzo, 1997):

the deeply-red condition. It is easy to show that *Uskip*

is greater than 1 (*Up* = 1.25), but both conditions (16) and (17) are satisfied.

skip

1

τ

3τ

*factor Uskip*

where dbf*skip*

*schedulable by EDF if*

Note that the *Uskip*

2τ

$$\left( \left\lfloor \frac{t}{T\_i} \right\rfloor - \left\lfloor \frac{t}{T\_i S\_i} \right\rfloor \right) \le \left\lfloor \frac{t}{T\_i} \right\rfloor.$$

The bandwidth saved by skips can also be exploited by an aperiodic server to advance the execution of aperiodic tasks.

#### **3.2 Period adaptation**

There are several real-time applications in which timing constraints are not rigid, but depend on the system state. The possibility of varying tasks' rates increases the flexibility of the system in handling overload conditions, providing a more general admission control mechanism. For example, if the total utilization of the task set is greater than one, the system could reduce the utilizations of some tasks (by increasing their periods in a controlled fashion) to decrease the total load.

The elastic model presented in this section (originally introduced Buttazzo et al. (Buttazzo et al., 1998) and later extended by the same authors to deal with resource constraints (Buttazzo et al., 2002)), provides a novel theoretical framework for flexible workload management in real-time applications.

#### **3.2.1 The elastic model**

The basic idea behind the elastic model is to consider each task as flexible as a spring with a given rigidity coefficient and length constraints. In particular, the utilization of a task is treated as an elastic parameter, whose value can be modified by changing the period within a specified range. Each task is characterized by four parameters: a computation time *Ci*, a minimum period *Tmin <sup>i</sup>* , a maximum period *<sup>T</sup>max <sup>i</sup>* , and an elastic coefficient *Ei* ≥ 0, which specifies the flexibility of the task to vary its utilization for adapting the system to a new feasible rate configuration. The greater *Ei*, the more elastic the task. Thus, an elastic task is denoted as

$$
\pi\_i(C\_{i\nu} \, T\_i^{\min} \, \_\prime T\_i^{\max} \, \_\prime E\_i) \, .
$$

In the following, *Ti* denotes the actual period of task *τi*, which is constrained to be in the range [*Tmin <sup>i</sup>* , *<sup>T</sup>max <sup>i</sup>* ]. Any task can vary its period according to its needs within the specified range. Any variation, however, is subject to an *elastic guarantee* and is accepted only if there is a feasible schedule in which all the other periods are within their range.

It is worth noting that the elastic model is more general than the classical Liu and Layland's task model (Liu & Layland, 1973), so it does not prevent a user from defining hard real-time tasks. In fact, a task having *Tmax <sup>i</sup>* <sup>=</sup> *<sup>T</sup>min <sup>i</sup>* is equivalent to a hard real-time task with fixed period, independently of its elastic coefficient. A task with *Ei* = 0 can arbitrarily vary its period within its specified range, but it cannot be varied by the system during load reconfigurations.

in Real-Time Systems 15

Handling Overload Conditions in Real-Time Systems 163

x 10 x 20 x 30 x 40

Fig. 10. Springs with minimum length constraints (a); during compression, spring *S*<sup>2</sup> reaches

*Umax*

*Umin*

x 1−min x 3−min x 4−min x 2−min

x 1 x 2 x 3 x 4

*Umax <sup>v</sup>* = ∑ *τi*∈Γ*<sup>v</sup>*

> *Uf* = ∑ *τi*∈Γ*<sup>f</sup>*

> > *Ev* = ∑ *τi*∈Γ*<sup>v</sup>*

recomputed), and Equation (20) applied again to the tasks in Γ*v*. If there is a feasible solution, that is, if *Umin* ≤ *Ud*, the iterative process ends when each value *Ui* computed by Equation (20)

All tasks' utilizations that have been compressed to cope with an overload situation can return

The elastic compression algorithm can be efficiently implemented on top of a real-time kernel as a routine (elastic manager) that is activated every time a new task is created, terminated, or there is a request for a period change. When activated, the elastic manager computes the new

To avoid any deadline miss during the transition phase, it is crucial to ensure that all the periods are modified at opportune time instants. In particular, the period of a task *τ<sup>i</sup>* can be increased at any time, but can only be reduced at the next job activation. An earlier instant at which a period can be safely reduced without causing any deadline miss in the transition phase has been computed by Buttazzo et al. (Buttazzo et al., 2002) and later improved by

If the elastic coefficients are set equal to task nominal utilizations, elastic compression has the effect of a simple rescaling, where all the periods are increased by the same percentage. In

its minimum length and cannot be compressed any further (b).

*<sup>i</sup>* (so that *Ui* <sup>=</sup> *<sup>U</sup>min*

is greater than or equal to its corresponding minimum *Umin*

toward their nominal values when the overload is over.

a set Γ of *n* elastic tasks up to a desired utilization *Ud* is shown in Figure 11.

periods according to the compression algorithm and modifies them atomically.

L0

F

*<sup>i</sup>* (21)

*<sup>i</sup>* (22)

*Ei*. (23)

*<sup>i</sup>* . The algorithm for compressing

*<sup>i</sup>* , then the period of those tasks has to be fixed at its

*<sup>i</sup>* ), sets Γ *<sup>f</sup>* and Γ*<sup>v</sup>* must be updated (hence, *Uf* and *Ev*

L

L

Ld Lmax L0

(a)

(b)

If there are tasks for which *Ui* < *Umin*

Guangming (Guangming, 2009).

**3.2.2 Period rescaling**

maximum value *Tmax*

where

Under the elastic model, given a set of *n* periodic tasks with utilization *Up* > 1, the objective of the elastic guarantee is to compress tasks' utilization factors to achieve a new desired utilization *Ud* ≤ 1 such that all the periods are within their ranges.

The following definitions are also used in this section:

$$\begin{aligned} \mathcal{U}\_i^{\min} &= \mathcal{C}\_i / T\_i^{\max}; \\ \mathcal{U}\_{\min} &= \sum\_{i=1}^n \mathcal{U}\_i^{\min}; \\ \mathcal{U}\_i^{\max} &= \mathcal{C}\_i / T\_i^{\min}; \\ \mathcal{U}\_{\max} &= \sum\_{i=1}^n \mathcal{U}\_i^{\max}. \end{aligned}$$

Clearly, a solution can always be found if *Umin* ≤ *Ud*; hence, this condition has to be verified a priori.

To understand how an elastic guarantee is performed in this model, it is convenient to compare an elastic task *τ<sup>i</sup>* having utilization *Ui* and elasticity *Ei* with a linear spring *Si* characterized by a length *xi* and a rigidity coefficient *ki*, equivalent to the inverse of the task's elasticity (*ki* = 1/*Ei*). In this comparison, the nominal length *xi*<sup>0</sup> of the spring is equivalent to *Umax <sup>i</sup>* , whereas the minimum length *<sup>x</sup>min <sup>i</sup>* is equivalent to *<sup>U</sup>min <sup>i</sup>* . Hence, a set of *n* periodic tasks with total utilization factor *Up* = ∑*<sup>n</sup> <sup>i</sup>*=<sup>1</sup> *Ui* can be viewed as a sequence of *n* springs with total length *L* = ∑*<sup>n</sup> <sup>i</sup>*=<sup>1</sup> *xi*.

In the special case in which *Umin <sup>i</sup>* = 0 for all tasks, the compressed task utilizations can be derived by solving a set of *n* spring linear equations, under the constraint that ∑*<sup>n</sup> <sup>i</sup>*=<sup>1</sup> *Ui* = *Ud*. The resulting expression is:

$$\forall i \quad \mathcal{U}\_i = \mathcal{U}\_i^{\max} - (\mathcal{U}\_{\max} - \mathcal{U}\_d) \frac{E\_i}{E\_s}. \tag{19}$$

where *Es* = ∑*<sup>n</sup> <sup>i</sup>*=<sup>1</sup> *Ei*.

If each spring has a length constraint, in the sense that its length cannot be less than a minimum value *xmin <sup>i</sup>* , the problem of finding the values *xi* requires an iterative solution. In fact, if during compression one or more springs reach their minimum length, the additional compression force will only deform the remaining springs. Such a situation is depicted in Figure 10.

Thus, at each instant, the set Γ can be divided into two subsets: a set Γ *<sup>f</sup>* of fixed springs having minimum length (equivalent to tasks that reached their minimum utilization with the maximum period), and a set Γ*<sup>v</sup>* of variable springs that can still be compressed. If *Umax <sup>v</sup>* is the sum of the maximum utilizations of tasks in Γ*v*, and *Uf* is the total utilization factor of tasks in Γ *<sup>f</sup>* , then, to achieve a desired utilization *Ud* ≤ 1, each task has to be compressed up to the following utilization:

$$\forall \tau\_{\dot{\imath}} \in \Gamma\_{\upsilon} \quad \mathcal{U}\_{\dot{\imath}} = \mathcal{U}\_{\dot{\imath}}^{\max} - (\mathcal{U}\_{\upsilon}^{\max} - \mathcal{U}\_{d} + \mathcal{U}\_{f}) \frac{E\_{\dot{\imath}}}{E\_{\upsilon}} \tag{20}$$

Fig. 10. Springs with minimum length constraints (a); during compression, spring *S*<sup>2</sup> reaches its minimum length and cannot be compressed any further (b).

where

14 Will-be-set-by-IN-TECH

Under the elastic model, given a set of *n* periodic tasks with utilization *Up* > 1, the objective of the elastic guarantee is to compress tasks' utilization factors to achieve a new desired

*<sup>i</sup>* <sup>=</sup> *Ci*/*Tmax*

*n* ∑ *i*=1

*<sup>i</sup>* <sup>=</sup> *Ci*/*Tmin*

Clearly, a solution can always be found if *Umin* ≤ *Ud*; hence, this condition has to be verified

To understand how an elastic guarantee is performed in this model, it is convenient to compare an elastic task *τ<sup>i</sup>* having utilization *Ui* and elasticity *Ei* with a linear spring *Si* characterized by a length *xi* and a rigidity coefficient *ki*, equivalent to the inverse of the task's elasticity (*ki* = 1/*Ei*). In this comparison, the nominal length *xi*<sup>0</sup> of the spring is equivalent

*n* ∑ *i*=1 *<sup>i</sup>* ;

*<sup>i</sup>* ;

*<sup>i</sup>* is equivalent to *<sup>U</sup>min*

*<sup>i</sup>* − (*Umax* − *Ud*)

*<sup>i</sup>* , the problem of finding the values *xi* requires an iterative solution. In

*<sup>v</sup>* − *Ud* + *Uf*)

*Ei Ev*

If each spring has a length constraint, in the sense that its length cannot be less than a

fact, if during compression one or more springs reach their minimum length, the additional compression force will only deform the remaining springs. Such a situation is depicted in

Thus, at each instant, the set Γ can be divided into two subsets: a set Γ *<sup>f</sup>* of fixed springs having minimum length (equivalent to tasks that reached their minimum utilization with the maximum period), and a set Γ*<sup>v</sup>* of variable springs that can still be compressed. If *Umax*

sum of the maximum utilizations of tasks in Γ*v*, and *Uf* is the total utilization factor of tasks in Γ *<sup>f</sup>* , then, to achieve a desired utilization *Ud* ≤ 1, each task has to be compressed up to the

*<sup>i</sup>* <sup>−</sup> (*Umax*

*<sup>i</sup>* . Hence, a set of *n* periodic

. (19)

*<sup>i</sup>*=<sup>1</sup> *Ui* = *Ud*.

*<sup>v</sup>* is the

(20)

*<sup>i</sup>*=<sup>1</sup> *Ui* can be viewed as a sequence of *n* springs with

*<sup>i</sup>* = 0 for all tasks, the compressed task utilizations can be

*Ei Es*

*Umax <sup>i</sup>* .

*Umin <sup>i</sup>* ;

utilization *Ud* ≤ 1 such that all the periods are within their ranges.

*Umin*

*Umax*

*Umin* =

*Umax* =

derived by solving a set of *n* spring linear equations, under the constraint that ∑*<sup>n</sup>*

<sup>∀</sup>*i Ui* <sup>=</sup> *<sup>U</sup>max*

<sup>∀</sup>*τ<sup>i</sup>* <sup>∈</sup> <sup>Γ</sup>*<sup>v</sup> Ui* <sup>=</sup> *<sup>U</sup>max*

The following definitions are also used in this section:

*<sup>i</sup>* , whereas the minimum length *<sup>x</sup>min*

tasks with total utilization factor *Up* = ∑*<sup>n</sup>*

*<sup>i</sup>*=<sup>1</sup> *xi*.

In the special case in which *Umin*

*<sup>i</sup>*=<sup>1</sup> *Ei*.

The resulting expression is:

a priori.

to *Umax*

total length *L* = ∑*<sup>n</sup>*

where *Es* = ∑*<sup>n</sup>*

Figure 10.

minimum value *xmin*

following utilization:

$$\mathcal{U}^{\max}\_{\upsilon} = \sum\_{\tau\_l \in \Gamma\_{\upsilon}} \mathcal{U}^{\max}\_{l} \tag{21}$$

$$\mathcal{U}\_f = \sum\_{\tau\_l \in \Gamma\_f} \mathcal{U}\_i^{\min} \tag{22}$$

$$E\_{\overline{\nu}} = \sum\_{\pi\_i \in \Gamma\_{\overline{\nu}}} E\_i. \tag{23}$$

If there are tasks for which *Ui* < *Umin <sup>i</sup>* , then the period of those tasks has to be fixed at its maximum value *Tmax <sup>i</sup>* (so that *Ui* <sup>=</sup> *<sup>U</sup>min <sup>i</sup>* ), sets Γ *<sup>f</sup>* and Γ*<sup>v</sup>* must be updated (hence, *Uf* and *Ev* recomputed), and Equation (20) applied again to the tasks in Γ*v*. If there is a feasible solution, that is, if *Umin* ≤ *Ud*, the iterative process ends when each value *Ui* computed by Equation (20) is greater than or equal to its corresponding minimum *Umin <sup>i</sup>* . The algorithm for compressing a set Γ of *n* elastic tasks up to a desired utilization *Ud* is shown in Figure 11.

All tasks' utilizations that have been compressed to cope with an overload situation can return toward their nominal values when the overload is over.

The elastic compression algorithm can be efficiently implemented on top of a real-time kernel as a routine (elastic manager) that is activated every time a new task is created, terminated, or there is a request for a period change. When activated, the elastic manager computes the new periods according to the compression algorithm and modifies them atomically.

To avoid any deadline miss during the transition phase, it is crucial to ensure that all the periods are modified at opportune time instants. In particular, the period of a task *τ<sup>i</sup>* can be increased at any time, but can only be reduced at the next job activation. An earlier instant at which a period can be safely reduced without causing any deadline miss in the transition phase has been computed by Buttazzo et al. (Buttazzo et al., 2002) and later improved by Guangming (Guangming, 2009).

#### **3.2.2 Period rescaling**

If the elastic coefficients are set equal to task nominal utilizations, elastic compression has the effect of a simple rescaling, where all the periods are increased by the same percentage. In

in Real-Time Systems 17

Handling Overload Conditions in Real-Time Systems 165

order to work correctly, however, period rescaling must be uniformly applied to all the tasks,

*<sup>i</sup>* , Equation (20) becomes:

*Umax i Umax*

*Umax Ud*

<sup>=</sup> *<sup>U</sup>max i Umax Ud*

. (24)

*<sup>v</sup>* = *Umax*.

*<sup>i</sup>* ). However,

without restrictions on the maximum period. This means having *Uf* = 0 and *Umax*

*<sup>i</sup>* − (*Umax* − *Ud*)

*Ti* = *Tmin i*

This means that in overload situations (*Umax* > 1) the compression algorithm causes all task

*<sup>η</sup>* <sup>=</sup> *Umax Ud* .

> <sup>=</sup> <sup>1</sup> *η*

If a maximum period needs to be defined for some task, an online guarantee test can easily be performed before compression to check whether all the new periods are less than or equal to

By deciding to apply period rescaling, we lose the freedom of choosing the elastic coefficients,

this technique has the advantage of leaving the task periods ordered as in the nominal configuration, which simplifies the compression algorithm in the presence of resource constraints and enables its usage in fixed priority systems, where priorities are typically

A third method for coping with a permanent overload condition is to reduce the load by decreasing the task computation times. This can be done only if the tasks have been originally designed to trade performance with computational requirements. When tasks use some incremental algorithm to produce approximated results, the precision of results is related to the number of iterations, and thus with the computation time. In this case, an overload condition can be handled by reducing the quality of results, aborting the remaining

The concept of imprecise and approximate computation has emerged as a new approach to increasing flexibility in dynamic scheduling by trading computation accuracy with timing requirements. If processing time is not enough to produce high-quality results within the deadlines, there could be enough time for producing approximate results with a lower quality. This concept has been formalized by many authors (Lin et al., 1987; Liu et al., 1987; 1991; 1994;

<sup>∀</sup>*<sup>i</sup>* <sup>=</sup> 1, . . . , *<sup>n</sup> <sup>η</sup>Tmin*

since they must be set equal to task maximum utilizations (*Ei* = *Umax*

*Umax* <sup>=</sup> *Ud*

*<sup>i</sup>* <sup>≤</sup> *<sup>T</sup>max <sup>i</sup>* .

*Umax*

*Umax* = *Ud*

Note that after compression is performed, the total processor utilization becomes

*Ci ηTmin i*

Under this assumption, by setting *Ei* = *Umax*

periods to be increased by a common scale factor

*U* =

*n* ∑ *i*=1 *Ci Ti* = *n* ∑ *i*=1

the maximum value. This can be done in *O*(*n*) by testing whether

computation if the quality of the current results is acceptable.

from which we have

as desired.

assigned based on periods.

**3.3 Service adaptation**

<sup>∀</sup>*i Ui* <sup>=</sup> *<sup>U</sup>max*

**Algorithm**: Elastic\_compression(Γ,*Ud*) **Input**: A task set Γ and a desired utilization *Ud* ≤ 1 **Output**: A task set with modified periods such that *Up* = *Ud* **begin** (1) *Umin* := ∑*<sup>n</sup> <sup>i</sup>*=<sup>1</sup> *Ci*/*Tmax <sup>i</sup>* ; (2) **if** (*Ud* < *Umin*) return(INFEASIBLE); (3) **for** (*i* := 1 **to** *n*) *Umax <sup>i</sup>* :<sup>=</sup> *Ci*/*Tmin <sup>i</sup>* ; (4) **do** (5) *Uf* := 0; *Umax <sup>v</sup>* := 0; *Ev* := 0; (6) **for** (*i* := 1 **to** *n*) **do** (7) **if** ((*Ei* == 0) or (*Ti* == *Tmax <sup>i</sup>* )) **then** (8) *Uf* := *Uf* + *Umin <sup>i</sup>* ; (9) **else** (10) *Ev* := *Ev* + *Ei*; (11) *Umax <sup>v</sup>* := *Umax <sup>v</sup>* + *Umax <sup>i</sup>* ; (12) **end** (13) **end** (14) *ok* := 1; (15) **for** (*each τ<sup>i</sup>* ∈ Γ*v*) **do** (16) **if** ((*Ei* > 0) and (*Ti* < *Tmax <sup>i</sup>* )) **then** (17) *Ui* := *Umax <sup>i</sup>* <sup>−</sup> (*Umax <sup>v</sup>* − *Ud* + *Uf*)*Ei*/*Ev*; (18) *Ti* := *Ci*/*Ui*; (19) **if** (*Ti* > *Tmax <sup>i</sup>* ) **then** (20) *Ti* := *Tmax <sup>i</sup>* ; (21) *ok* := 0; (22) **end** (23) **end** (24) **end** (25) **while** (*ok* == 0); (26) return(FEASIBLE); **end**

Fig. 11. Algorithm for compressing a set of elastic tasks.

order to work correctly, however, period rescaling must be uniformly applied to all the tasks, without restrictions on the maximum period. This means having *Uf* = 0 and *Umax <sup>v</sup>* = *Umax*. Under this assumption, by setting *Ei* = *Umax <sup>i</sup>* , Equation (20) becomes:

$$\forall i \quad \mathcal{U}\_i = \mathcal{U}\_i^{\max} - (\mathcal{U}\_{\max} - \mathcal{U}\_d) \frac{\mathcal{U}\_i^{\max}}{\mathcal{U}\_{\max}} = \frac{\mathcal{U}\_i^{\max}}{\mathcal{U}\_{\max}} \mathcal{U}\_d$$

from which we have

16 Will-be-set-by-IN-TECH

**Output**: A task set with modified periods such that *Up* = *Ud*

*<sup>i</sup>* :<sup>=</sup> *Ci*/*Tmin*

*<sup>v</sup>* := 0; *Ev* := 0;

*<sup>v</sup>* := *Umax*

*<sup>i</sup>* ;

*<sup>i</sup>* ;

*<sup>v</sup>* + *Umax <sup>i</sup>* ;

*<sup>i</sup>* <sup>−</sup> (*Umax*

*<sup>i</sup>* ) **then**

*<sup>i</sup>* ;

*<sup>i</sup>* )) **then**

*<sup>i</sup>* )) **then**

*<sup>v</sup>* − *Ud* + *Uf*)*Ei*/*Ev*;

**Algorithm**: Elastic\_compression(Γ,*Ud*)

*<sup>i</sup>*=<sup>1</sup> *Ci*/*Tmax <sup>i</sup>* ;

(2) **if** (*Ud* < *Umin*) return(INFEASIBLE);

(7) **if** ((*Ei* == 0) or (*Ti* == *Tmax*

(8) *Uf* := *Uf* + *Umin*

(10) *Ev* := *Ev* + *Ei*;

(15) **for** (*each τ<sup>i</sup>* ∈ Γ*v*) **do**

(17) *Ui* := *Umax*

(18) *Ti* := *Ci*/*Ui*; (19) **if** (*Ti* > *Tmax*

(20) *Ti* := *Tmax*

(21) *ok* := 0;

(22) **end** (23) **end** (24) **end**

(25) **while** (*ok* == 0); (26) return(FEASIBLE);

Fig. 11. Algorithm for compressing a set of elastic tasks.

**end**

(16) **if** ((*Ei* > 0) and (*Ti* < *Tmax*

**begin**

(4) **do**

(1) *Umin* := ∑*<sup>n</sup>*

(3) **for** (*i* := 1 **to** *n*) *Umax*

(5) *Uf* := 0; *Umax*

(11) *Umax*

(9) **else**

(12) **end** (13) **end**

(14) *ok* := 1;

(6) **for** (*i* := 1 **to** *n*) **do**

**Input**: A task set Γ and a desired utilization *Ud* ≤ 1

$$T\_i = T\_i^{\min} \frac{\mathcal{U}\_{\max}}{\mathcal{U}\_d}. \tag{24}$$

This means that in overload situations (*Umax* > 1) the compression algorithm causes all task periods to be increased by a common scale factor

$$
\eta = \frac{U\_{\max}}{U\_d}.
$$

Note that after compression is performed, the total processor utilization becomes

$$\mathcal{U} = \sum\_{i=1}^{n} \frac{\mathbb{C}\_{i}}{T\_{i}} = \sum\_{i=1}^{n} \frac{\mathbb{C}\_{i}}{\eta \, T\_{i}^{\min}} = \frac{1}{\eta} \mathcal{U}\_{\max} = \frac{\mathcal{U}\_{d}}{\mathcal{U}\_{\max}} \mathcal{U}\_{\max} = \mathcal{U}\_{d}$$

as desired.

If a maximum period needs to be defined for some task, an online guarantee test can easily be performed before compression to check whether all the new periods are less than or equal to the maximum value. This can be done in *O*(*n*) by testing whether

$$\forall i = 1, \dots, n \quad \eta T\_i^{\min} \le T\_i^{\max}.$$

By deciding to apply period rescaling, we lose the freedom of choosing the elastic coefficients, since they must be set equal to task maximum utilizations (*Ei* = *Umax <sup>i</sup>* ). However, this technique has the advantage of leaving the task periods ordered as in the nominal configuration, which simplifies the compression algorithm in the presence of resource constraints and enables its usage in fixed priority systems, where priorities are typically assigned based on periods.

#### **3.3 Service adaptation**

A third method for coping with a permanent overload condition is to reduce the load by decreasing the task computation times. This can be done only if the tasks have been originally designed to trade performance with computational requirements. When tasks use some incremental algorithm to produce approximated results, the precision of results is related to the number of iterations, and thus with the computation time. In this case, an overload condition can be handled by reducing the quality of results, aborting the remaining computation if the quality of the current results is acceptable.

The concept of imprecise and approximate computation has emerged as a new approach to increasing flexibility in dynamic scheduling by trading computation accuracy with timing requirements. If processing time is not enough to produce high-quality results within the deadlines, there could be enough time for producing approximate results with a lower quality. This concept has been formalized by many authors (Lin et al., 1987; Liu et al., 1987; 1991; 1994;

in Real-Time Systems 19

Handling Overload Conditions in Real-Time Systems 167

Finally, if an algorithm cannot be executed in an incremental fashion or it cannot be aborted at any time, a task can be provided with multiple versions, each characterized by a different

This section describes two real-world applications to illustrate how the presented techniques can be used to prevent the negative effects of the overload. The first example considers a multimedia system and shows how resource reservation can isolate the timing behavior of concurrent applications characterized by highly variable execution times, preventing a performance degradation due to a reciprocal interference. The second example illustrates how to handle a permanent overload in a robot system that activates a new task to cope with

Let us consider a multimedia device, like a cell phone, in which a phone call, a video player, and a web browser can be concurrently executed, so that a user can simultaneously make a phone call while watching a video and downloading a file from the web. These applications are characterized by a highly variable computational demand and share common resources (e.g., processor, memory, touch screen, audio codec, and graphic display). They are briefly

• **Phone call** (*A*1). This application consists at least of two periodic activities, executed with a period of 20 ms. A task is in charge of receiving the incoming audio signal, decoding it, and transferring the packets to the speaker buffer for reproduction. The processing time of this task can vary from 1 ms (during silence) up to 3 ms. The second task is responsible for sampling the voice from the microphone, performing data encoding, speech enhancement, and packet transmission through the modem. The processing time of this task can vary from 5 ms (during silence) up to 10 ms. Hence, overall, this application requires a processor

• **Video player** (*A*2). The MPEG standard adopted for video compression is characterized by highly variable execution times. For instance, Figure 12 shows the typical distribution of frame decoding times for an MPEG player decoding a specific video on a given platform (Abeni & Buttazzo, 2000; Isovic et al., 2005). Note that the processing time of this task can vary from 6 ms to 30 ms, with an average decoding time of about 12 ms. If using the PAL standard, the frame rate is set to 25 frames per second, meaning that each frame has to be processed every 40 ms. Therefore, running an MPEG player requires an average processor bandwidth of 30%, which can reach 75% in peak load conditions. • **Web browser** (*A*3). This activity is also characterized by high load variations. In fact, when loading a web page, there is a peak processing load to parse the input, taking about one second. Then, a request is submitted to the server for sending a separate content, like images and layout files. At this time, the processing pauses for about another second while waiting for the new input. When full data arrive, there is another peak load, since they should be processed (decoded/parsed and rendered) as quickly as possible (this phase

Note that, each of the considered applications is typically implemented as a set of tasks with different priorities. Hence, when they are concurrently executed on the same processor,

*<sup>i</sup>* can be used to select the task

*i* .

quality of performance and execution time. Then, the value *C*

**4.1 Resource reservation in multimedia systems**

bandwidth that can vary from 30% to 65%.

takes a few seconds depending on the content).

**4. Two case studies**

obstacle avoidance.

described below.

version having the computation time closer to, but smaller than *C*

Natarajan, 1995; Shih et al., 1991) and specific techniques have been developed for designing programs that can produce partial results.

In a real-time system that supports imprecise computation, every task *τ<sup>i</sup>* is decomposed into a *mandatory* subtask *Mi* and an *optional* subtask *Oi*. The mandatory subtask is the portion of the computation that must be done in order to produce a result of acceptable quality, whereas the optional subtask refines this result (Shih et al., 1989). Both subtasks have the same activation time *ri* and the same deadline *di* as the original task *τi*; however, *Oi* becomes ready for execution when *Mi* is completed. If *Ci* is the worst-case computation time associated with the task, subtasks *Mi* and *Oi* have computation times *mi* and *oi*, such that *mi* + *oi* = *Ci*. In order to guarantee a minimum level of performance, *Mi* must be completed within its deadline, whereas *Oi* can be left incomplete, if necessary, at the expense of the quality of the result produced by the task.

It is worth noting that the task model used in traditional real-time systems is a special case of the one adopted for imprecise computation. In fact, a hard task corresponds to a task with no optional part (*oi* = 0), whereas a soft task is equivalent to a task with no mandatory part (*mi* = 0).

In systems that support imprecise computation, the *error �<sup>i</sup>* in the result produced by *τ<sup>i</sup>* (or simply the error of *τi*) is defined as the length of the portion of *Oi* discarded in the schedule. If *σ<sup>i</sup>* is the total processor time assigned to *Oi* by the scheduler, the error of task *τ<sup>i</sup>* is equal to

$$
\mathfrak{e}\_i = \mathfrak{o}\_i - \sigma\_i.
$$

The *average error �* on the task set is defined as

$$\overline{\epsilon} = \sum\_{i=1}^{n} w\_i \epsilon\_{i\prime}$$

where *wi* is the relative importance of *τ<sup>i</sup>* in the task set. An error *�<sup>i</sup>* > 0 means that a portion of subtask *Oi* has been discarded in the schedule at the expense of the quality of the result produced by task *τi*, but for the benefit of other mandatory subtasks that can complete within their deadlines.

In this model, a schedule is said to be *feasible* if every mandatory subtask *Mi* is completed within its deadline. A schedule is said to be *precise* if the average error *�* on the task set is zero. In a precise schedule, all mandatory and optional subtasks are completed within their deadlines.

For a set of periodic tasks, the problem of deciding the best level of quality compatible with a given load condition can be solved by associating each optional part of a task a reward function *Ri*(*σi*), which indicates the reward accrued by the task when it receives *σ<sup>i</sup>* units of service beyond its mandatory portion. This problem has been addressed by Aydin et al. (Aydin et al., 2001), who presented an optimal algorithm that maximizes the weighted average of the rewards over the task set.

Note that in the absence of a reward function, the problem can easily be solved by using a compression algorithm like the elastic approach. In fact, once, the new task utilizations *U*� *i* are computed, the new computation times *C*� *<sup>i</sup>* that lead to a given desired load can easily be computed from the periods as

$$\mathbf{C}'\_{i} = T\_{i} \mathbf{U}'\_{i}.$$

Finally, if an algorithm cannot be executed in an incremental fashion or it cannot be aborted at any time, a task can be provided with multiple versions, each characterized by a different quality of performance and execution time. Then, the value *C <sup>i</sup>* can be used to select the task version having the computation time closer to, but smaller than *C i* .
