*"A mode of a real-time system is defined by the behavior of the system, described by a set of allowable functions and their performance attributes, and hence by a single schedule, containing a set of processes and their timing parameters"*.

Clearly, the definition of a mode depends upon the field of application and the level of abstraction considered. At the lower levels of abstraction of a real-time system, the notion of a single schedule is suitable to define a mode, since we are interested in applying schedulability analysis to guarantee the predictability of the real-time system. Nevertheless, the idea of schedule very often is a too low-level concept, and therefore devoid of meaning when addressing the end user application concerns. Therefore, as we are searching for a comprehensive definition of modes for real-time systems, we also associate our definition of modes with the idea of behavior. The behavior of the system is bounded to a restricted set of operations that it is allowed to perform when it executes in a specific mode. It constrains the actions that the system is not ready to deliver while in that mode. It also constrains the behavior that the system may exhibit. Unlike states, a mode does not limit its variable values directly. It may be regarded as the system's behavior resulting from its execution through a progression of states. Nevertheless, it is not always possible to map a group of states to a particular mode. Whereas in simple systems the modes and states can be more easily associated, in a complex real-time distributed system it may be difficult (and perhaps not necessary) to related both. Therefore it ensues, from the above definition of modes, that a change from a source mode A to a target mode B occurs in response to the need to change

MODE-CHANGE REQUEST (MCR)

Y

CHANGED

of five types of tasks (Fig. 1):

(T), or priority (P).

ABORTED

WHOLLY NEW

Fig. 1. Mode-Change Model (Pedro, 1999; Real & Crespo, 2004)

between tasks may or may not hold after the mode change.

mode that is no longer needed in the new mode.

x

T

OLD MODE MODE CHANGE NEW MODE

Schedulability Analysis of Mode Changes with Arbitrary Deadlines 51

Y

• Tasks are scheduled with time offsets during the mode change only. This time phasing

A *mode-change request (MCR)* is the event that triggers a transition from an old mode of operation to a new one. The window *x* is the phasing between the MCR and the activation of task *τi*. A MCR may not be preempted by another *MCR*. The mode-change model comprises

• *Old-mode completed tasks*, *τi*(*O*) : These tasks are released in the old mode, i.e. before the arrival of the *MCR*. They need to advance their execution into the transition window in order to finish execution. Old-mode completed tasks cannot be simply aborted as they would leave the system in an inconsistent state. Once they complete during the transition, there are no further releases. They are used to model the behavior of the system in the old

• *Old-mode aborted tasks*, *τi*(*A*): These tasks are also released prior to the MCR. They need to be immediately discarded after the *MCR* in order to release allocated resources back to the system. The behavior they implement is no longer needed in the new mode of operation. • *New-mode changed tasks*, *τi*(*C*) : These tasks are released during the transition, with an offset *Y* from the *MCR*. This class models the behavior that is changed in the new mode. Changed new-mode tasks have a modified timing parameter compared to their corresponding old-mode version, such as changed worst-case execution time (C), period

• *New-mode unchanged tasks*, *τi*(*U*) : These tasks are released during the transition window, with an offset *Z*, from the end of the period of their corresponding old-mode version. They model the behavior of the application that is not changed across the mode change and in the new mode. Their timing parameters are the same as the preceding old-mode version.

Z

UNCHANGED

COMPLETED

time

the system's functionality or adjust its performance. We adopt the following definition for a mode change of a uniprocessor system (Martins & Burns, 2008):

*"A mode change of a real-time system is defined as a change in the behavior exhibited by the system, accompanied by a change in the scheduling activity of the system."*

Many real-time systems in fact run a fixed task set. Processes executed in mutually exclusive modes are treated as if they could run at the same time, and grouped into a single schedule. Consequently, resources have to be allocated as if they could be requested at the same time, although this is an impossible scenario. This approach may be appropriate for simple real-time systems. However, for large and complex real-time systems this may result in significant reduction in efficiency of the system and sub-utilization of system resources. From a software engineering perspective, this approach denies the principles of modularization and separation of concerns, since it allows unrelated modes (and unrelated schedules) of a system to be treated and designed as if they were instead a single mode and schedule, although they may be logically independent, mutually exclusive or both.

### **3. Computational model and assumptions**

We shall consider a set of periodic or sporadic tasks *τ* = {*τ*1, *τ*2, ...*τi*, ..*τp*} per mode. Each task *τ<sup>i</sup>* is characterized by the tuple *Si* = {*Ti*, *Di*, *Ci*, *Pi*}, where: 1) *Ti* and *Di* are respectively the period of task *τ<sup>i</sup>* (or, if a sporadic task, the minimum inter-arrival time between successive tasks of the stream *i*) and the deadline; 2) *Ci* is the worst-case execution time (WCET) of the task *τi*. This value is deemed to contain the overheads due to context switching. Moreover, the values of *Ci*, *Di* and *Ti* are such that *Ci* < *Di* ≤ *Ti* . In subsection 5.2 we remove the restriction that *Di* ≤ *Ti* ; 3) *Pi* represents the priority of task *τ<sup>i</sup>* , assigned according to the Deadline Monotonic Scheduling algorithm.

Throughout this chapter, we use the notation *Ci*(*O*),*Ci*(*A*) and *Ci*(*N*) when referring to the worst-case computational time of an old-mode completed task, an aborted task, and a new-mode task, respectively. *τ<sup>i</sup>* denotes a task for which we are finding the worst-case response time (WCRT) and *τ<sup>j</sup>* denotes a higher-priority task. We use the term *steady-state analysis* to refer to the body of schedulability analysis of single-mode systems, where the task set is fixed and there are no mode changes. We also use the notation:


The mode-change model is based on the following assumptions:


4 Real Time System

the system's functionality or adjust its performance. We adopt the following definition for a

*"A mode change of a real-time system is defined as a change in the behavior exhibited by the system,*

Many real-time systems in fact run a fixed task set. Processes executed in mutually exclusive modes are treated as if they could run at the same time, and grouped into a single schedule. Consequently, resources have to be allocated as if they could be requested at the same time, although this is an impossible scenario. This approach may be appropriate for simple real-time systems. However, for large and complex real-time systems this may result in significant reduction in efficiency of the system and sub-utilization of system resources. From a software engineering perspective, this approach denies the principles of modularization and separation of concerns, since it allows unrelated modes (and unrelated schedules) of a system to be treated and designed as if they were instead a single mode and schedule, although they

We shall consider a set of periodic or sporadic tasks *τ* = {*τ*1, *τ*2, ...*τi*, ..*τp*} per mode. Each task *τ<sup>i</sup>* is characterized by the tuple *Si* = {*Ti*, *Di*, *Ci*, *Pi*}, where: 1) *Ti* and *Di* are respectively the period of task *τ<sup>i</sup>* (or, if a sporadic task, the minimum inter-arrival time between successive tasks of the stream *i*) and the deadline; 2) *Ci* is the worst-case execution time (WCET) of the task *τi*. This value is deemed to contain the overheads due to context switching. Moreover, the values of *Ci*, *Di* and *Ti* are such that *Ci* < *Di* ≤ *Ti* . In subsection 5.2 we remove the restriction that *Di* ≤ *Ti* ; 3) *Pi* represents the priority of task *τ<sup>i</sup>* , assigned according to the

Throughout this chapter, we use the notation *Ci*(*O*),*Ci*(*A*) and *Ci*(*N*) when referring to the worst-case computational time of an old-mode completed task, an aborted task, and a new-mode task, respectively. *τ<sup>i</sup>* denotes a task for which we are finding the worst-case response time (WCRT) and *τ<sup>j</sup>* denotes a higher-priority task. We use the term *steady-state analysis* to refer to the body of schedulability analysis of single-mode systems, where the task

• Tasks are not permitted to voluntarily suspend themselves during an invocation (so, for

• The worst-case response time of a generic task *τ<sup>i</sup>* (WCRT), denoted *Ri*, is the longest time ever taken by that *τ<sup>i</sup>* from the time it arrives until the time it completes its required

example, tasks are not allowed to execute internal Ada-like delay statements);

set is fixed and there are no mode changes. We also use the notation:

The mode-change model is based on the following assumptions:

• There are fixed task sets before and after the mode change;

• Tasks are executed in a uniprocessor system;

computation;

• ∀ *τj*(*O*) *hp τ<sup>i</sup>* : set of old-mode tasks *τ<sup>j</sup>* with priority higher than task *τi*; • ∀ *τj*(*A*) *hp τ<sup>i</sup>* : set of aborted tasks *τ<sup>j</sup>* with priority higher than task *τi*; • ∀ *τj*(*N*) *hp τ<sup>i</sup>* : set of new-mode tasks *τ<sup>j</sup>* with priority higher than task *τi*.

mode change of a uniprocessor system (Martins & Burns, 2008):

*accompanied by a change in the scheduling activity of the system."*

may be logically independent, mutually exclusive or both.

**3. Computational model and assumptions**

Deadline Monotonic Scheduling algorithm.

Fig. 1. Mode-Change Model (Pedro, 1999; Real & Crespo, 2004)

• Tasks are scheduled with time offsets during the mode change only. This time phasing between tasks may or may not hold after the mode change.

A *mode-change request (MCR)* is the event that triggers a transition from an old mode of operation to a new one. The window *x* is the phasing between the MCR and the activation of task *τi*. A MCR may not be preempted by another *MCR*. The mode-change model comprises of five types of tasks (Fig. 1):


the advantage of simplicity, and the fact that is does not require schedulability analysis. The disadvantage of this protocol is its poor promptness, with an even larger mode-change delay

Schedulability Analysis of Mode Changes with Arbitrary Deadlines 53

The *minimum single offset protocol* (without periodicity) (Real, 2000) applies an offset *Y* to all new mode tasks. The offset is the sum of the worst-case execution time of all old-mode tasks that have been released (but not completed) before the arrival of the *MCR*. This protocol also suffers from poor promptness, but incurs in less mode-change latency compared to the

The *minimum single offset protocol* (with periodicity) (Real, 2000) similarly applies an offset *Y* to all new mode tasks. The offset is large enough to accommodate the old mode tasks and all unchanged tasks that need to preserve their periodicity. The disadvantage of this protocol is poor promptness, which is worse than the previous protocol. The protocol is also synchronous

In the *asynchronous mode-change protocol with periodicity* presented by Tindell, Burns & Wellings (1992), old-mode tasks are allowed to complete their last activation upon the arrival of a *MCR*, but are no longer released during the mode change. The mode-change model does not include aborted tasks. Wholly new tasks are released after a sufficient offset Y after the MCR. New-mode changed tasks are released right after the end of the period of the corresponding old-mode task. Because only wholly new tasks can be introduced with an offset, the ability to

Pedro & Burns (1998) introduced an asynchronous protocol without periodicity, which included aborted tasks in the mode-change model. Considering that in this protocol all new-mode tasks can have offsets, it is relatively easy to find a schedulable transition. The schedulability analysis is relatively simplified compared to that of Tindell, Burns & Wellings (1992), since the number of time windows to analyze is lower than in the previous protocol. Real (2000) proposes an asynchronous protocol with periodicity that merges the advantages of the last two protocols. The mode-change model is similar to that of Pedro & Burns (1998). Nevertheless, an offset *Z* is introduced for unchanged tasks, relative to the end of the period of the corresponding old-mode task. An offset *Z* = 0 means that the unchanged task is introduced immediately after the end of the period of its corresponding old-mode version. The inclusion of this offset allows the desired periodicity for unchanged tasks. However, when the task set is unschedulable, it is possible to lose periodicity in order to gain schedulability by increasing

In the following subsection we review previous work on mode changes with deadlines less

We must find the WCRT for both old-mode tasks and new-mode tasks defined in the mode-change model. We first consider analysis for the old-mode task set. The analysis gives exact (both necessary and sufficient) bounds on the worst-case response time of each task.

maximum period offset protocol, since all the old-mode tasks execute only once.

than the idle time protocol.

and dispenses schedulability analysis.

make any transition schedulable is reduced.

**5. Schedulability analysis of mode changes**

than or equal to periods, before we relax this constraint.

**5.1 Mode changes with deadlines less than or equal to periods**

the value of *Z*.

• *Wholly new task*, *τi*(*W*) : These tasks are released during the transition window with an offset *Y*. They are used to model the behavior that is totally new, i.e. has no equivalent in the old-mode of operation.

With respect to the way tasks are executed across a mode change, they are classified as: 1)Tasks with mode-change periodicity: these tasks are executed across the mode change and maintain their activation pace, and 2) Tasks without mode-change periodicity: these tasks do not preserve their activation pace across a mode change.

The mode-change latency is usually an important performance criterion when dealing with mode changes. We often seek to minimize the latency since during the mode change the system may deliver only partial functionality at the expenses of more critical services. The mode change latency is defined as:

*"A window starting with the arrival of the mode-change request (MCR) and ending when the set of new-mode tasks have completed their first execution and the set of old-mode tasks have completed their last execution"*.

In the following section we review background work on schedulability analysis of mode changes using the fixed-priority preemptive scheduling approach.
