Schedulability Analysis of Mode Changes with Arbitrary Deadlines

Modern real-time systems are required to operate in complex applications and dynamically adapt to a wide range of changes in the environment. One strategy that allows the implementation of these systems in complex scenarios is the partitioning of their applications into modes of operation. Flexibility of operation is achieved by having the system execute in several modes of operation and undergo transitions between modes in response to external or internal events. A mode of operation can be seen as a specific configuration of the computational resources that is optimal for the operational phase that the system executes. As conditions in the environment change, resource allocations may become inadequate. Therefore, the systemmust reconfigure itself through amode change, reallocating its resources in an efficient manner. A classic example of modes lies in the area of aviation where most aircraft undergo at least three basic modes of operation: take-off, level-flight, and landing modes. Having the system designed with a single mode of operation does not explore the fact that some operations, and thus resource usage, are mutually exclusive. The allocation of all these resources, as if they could be needed at the same time, leads to inefficiency. More importantly, the resulting system is not scalable. The so called "all-modes-in-one" system is usually feasible for simple systems with limited functionality.


Introduction
Modern real-time systems are required to operate in complex applications and dynamically adapt to a wide range of changes in the environment.One strategy that allows the implementation of these systems in complex scenarios is the partitioning of their applications into modes of operation.Flexibility of operation is achieved by having the system execute in several modes of operation and undergo transitions between modes in response to external or internal events.A mode of operation can be seen as a specific configuration of the computational resources that is optimal for the operational phase that the system executes.As conditions in the environment change, resource allocations may become inadequate.Therefore, the system must reconfigure itself through a mode change, reallocating its resources in an efficient manner.A classic example of modes lies in the area of aviation where most aircraft undergo at least three basic modes of operation: take-off, level-flight, and landing modes.Having the system designed with a single mode of operation does not explore the fact that some operations, and thus resource usage, are mutually exclusive.The allocation of all these resources, as if they could be needed at the same time, leads to inefficiency.More importantly, the resulting system is not scalable.The so called "all-modes-in-one" system is usually feasible for simple systems with limited functionality.
Flexible modal real-time systems must guarantee by means of schedulability analysis that all tasks complete before their deadlines.Current literature in schedulability analysis for mode changes requires that all task deadlines are less than or equal to the tasks periods (Pedro & Burns, 1998;Real & Crespo, 2004).Allowing task deadlines to be less than task periods is useful for many real-time applications (Tindell et al., 1994).However, in some real-time applications an instance of a task is allowed to arrive before its previous invocation has finished.In such case the task can be delayed until its previous invocation terminates.
This chapter extends the current schedulability analysis associated with mode changes in static priority pre-emptive based scheduling.In particular, it derives analysis that includes tasks executing across a mode change with deadlines larger than their period (arbitrary deadlines).
The rest of this chapter is organized as follows: section 2 elaborates on the concept of modes.We include a number of current views of modes and provide a working definition.In section 3 we introduce the computational model and assumptions.In section 4 we address previous work on modes in real-time systems.The schedulability analysis of mode changes with arbitrary deadlines is then derived in section 5. Section 6 shows an example of the applicability analysis.Finally, in section 7 we present our concluding remarks.

Definition of modes
The discussion on the concept of modes of operation appears more comprehensively in the literature of human-computer interaction and human-automation interaction (aviation and cockpit design).Modes have been commonly associated with the idea of functions, states, behavior, and schedule, depending on the research field.In real-time systems, since most work involving modes focus on the schedulability analysis of mode changes, this discussion has been limited.
The most widespread notion of modes is related to functionality.One example is the work in safety-critical systems by Papadopoulos (1996): a mode is defined by the "set of active functions that the system is prepared to deliver while operating in that mode".As modes represent functions, they may be arranged hierarchically.This is due to the fact that functionality can be refined down to lower level functions, leading to a hierarchical graph of the functional space.Another example is given by Norman (1981): "Every control system that can perform a variety of functions has modes: the more functions, the more modes." In human-computer interaction and interfacing, modes are seen as special states.Howe (1997) remarks that "a mode is a general state, usually used with an adjective describing the state".They are states that are extended over time and with some specific activity being carried out.Interface modes are defined by Tesler (1981) as "a state of the user interface that lasts for a period of time.It is not associated with any particular (display) object and has no role other than to place an interpretation of operator input ".According to Poller & Garter (1984), modes are the application's interpretation of the user's input.Therefore, a mode change occurs whenever there is a change of the interpretation of the same inputs.
In human-automation interaction (e.g.aviation psychology and cockpit interface design), modes are described as behavior of a certain component of the system, such as the interface.In particular, Degani et al. (1999) describe a mode as the manner of behavior of a given system.A system may have multiple mutually exclusive ways of behaving.Each behavior is defined by the system's input, output, and states.A mode change consists of an evolution from one pattern of behavior to another as a function of time.Transitions between modes are triggered by events in the environment: the way such systems behave reflects the transformation of the environment (Degani & Kirlik, 1995).
In the literature of real-time systems modes have been regarded as a collection of tasks, or schedule (e.g.Real (2000); Tindell, Burns & Wellings (1992)).For Fohler (1994) a schedule is a set of processes or messages (literally a collection of objects), characterized by its inherent timing parameters.These objects may have access to a shared resource according to a pre-defined policy.A mode change is a change in the task set, by means of replacement, addition or removal of tasks.
In computer science in general, modes have been described by the executable code or program (downloaded or memory resident) that is active under execution.Therefore, any change in the executable code reflects a change in the operational mode.A mode has also been regarded as the configuration of the system during a particular phase of operation, meaning how different system resources may be physically or logically arranged.For example, as noted by Degani et al. (1999): "we define a mode as a machine configuration that corresponds to a unique behavior".A system may dynamically change its configuration in order to achieve a better performance.A classic example is load balancing in distributed systems, where reconfiguration is achieved through process migration.
From the definitions above, we can summarize the idea of a mode of operation as the system's behavior while executing a given schedule.The notion of behavior is used to address modes when dealing with the higher levels of abstraction of a real-time system, such as the application or the interface design.Function and performance are two fundamental components of the behavior of a real-time system.A real-time system delivers a function with a certain performance attribute attached to it.A change either in the functionality or in the performance of the system characterizes a change in behavior.A change in behavior is noticed by changing the performance level while keeping the functional set, or likewise by changing the functional set while keeping the systems' performance.Taking these remarks into consideration a mode can be comprehensively defined as follows (Martins & Burns, 2008): "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 49 Schedulability Analysis of Mode Changes with Arbitrary Deadlines www.intechopen.comthe 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.

Computational model and assumptions
We shall consider a set of periodic or sporadic tasks τ = {τ 1 , τ 2 , ...τ i ,..τ p } per mode.Each task τ i is characterized by the tuple S i = {T i , D i , C i , P i }, where: 1) T i and D i are respectively the period of task τ i (or, if a sporadic task, the minimum inter-arrival time between successive tasks of the stream i) and the deadline; 2) C i 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 C i , D i and T i are such that C i < D i ≤ T i .In subsection 5.2 we remove the restriction that D i ≤ T i ;3 )P i represents the priority of task τ i , assigned according to the Deadline Monotonic Scheduling algorithm.
Throughout this chapter, we use the notation C i(O) ,C i(A) and C i(N) when referring to the worst-case computational time of an old-mode completed task, an aborted task, and a new-mode task, respectively.τ i denotes a task for which we are finding the worst-case response time (WCRT) and τ j 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: • ∀ τ j(O) hp τ i : set of old-mode tasks τ j with priority higher than task τ i ; • ∀ τ j(A) hp τ i : set of aborted tasks τ j with priority higher than task τ i ; • ∀ τ j(N) hp τ i : set of new-mode tasks τ j with priority higher than task τ i .
The mode-change model is based on the following assumptions: • Tasks are executed in a uniprocessor system; • Tasks are not permitted to voluntarily suspend themselves during an invocation (so, for example, tasks are not allowed to execute internal Ada-like delay statements); • There are fixed task sets before and after the mode change; • The worst-case response time of a generic task τ i (WCRT), denoted R i , is the longest time ever taken by that τ i from the time it arrives until the time it completes its required computation;  (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): • 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 mode that is no longer needed in the new mode.
• 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 (T), or priority (P).
• 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.

51
Schedulability Analysis of Mode Changes with Arbitrary Deadlines www.intechopen.com • 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.

Background
A number of mode-change protocols have been proposed and classified into synchronous or asynchronous protocols.Synchronous mode-change protocols complete the old-mode tasks before any new task start execution.Synchronous protocols do not require schedulability analysis.On the other hand, asynchronous protocols allow new-mode tasks to begin execution while old-mode tasks are still running.Asynchronous protocols may reduce the mode-change latency, but may have reduced schedulability, since the processing load is larger.These protocols do require schedulability analysis, since old-mode tasks will interfere with the execution of new-mode tasks and vice-versa.
Two types of mode-change protocols can be defined regarding the way unchanged tasks are executed: 1) Protocols with periodicity are protocols where unchanged tasks preserve their activation pace or periodicity.Under these protocols, tasks are executed independently of the mode change in progress; 2) On the other hand, the activation of unchanged tasks may be delayed by protocols without periodicity.Their rate of activation is affected by the transition.The loss of periodicity may be necessary to guarantee the feasibility of the mode change or to preserve data consistency.
The idle time protocol (Tindell & Alonso, 1996) delays the execution of any MCR until an idle time, where there is no CPU load (activity).It is a simple, synchronous protocol.A mode change task detects the idle time and performs the mode change, by suspending all old mode tasks and activating the new mode ones.The disadvantage is the delay in waiting for the idle time, especially when there may be new-mode tasks with short deadlines waiting to be executed.
The maximum period offset protocol (Bailey, 1993) delays all tasks for the time corresponding to the period of the least frequent task in both modes.Being a synchronous protocol, it has 52 Real-Time Systems, Architecture, Scheduling, and Application 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 than the idle time protocol.
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 maximum period offset protocol, since all the old-mode tasks execute only once.
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 and dispenses schedulability analysis.
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 make any transition schedulable is reduced.
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 the value of Z.

Schedulability analysis of mode changes
In the following subsection we review previous work on mode changes with deadlines less than or equal to periods, before we relax this constraint.

Mode changes with deadlines less than or equal to periods
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.

53
Schedulability Analysis of Mode Changes with Arbitrary Deadlines www.intechopen.com

Analysis of old-mode tasks
Old-mode tasks suffer the interference from higher-priority aborted tasks before the mode change, and from higher-priority completed tasks before and after the mode change (Fig. 1).
During the mode change, old-mode tasks are also preempted by higher-priority new-mode tasks.Clearly, there is no interference from aborted tasks during the transition.We now show the interference terms for each type of task.
5.1.1.1Interference from higher-priority old-mode completed tasks Old-mode, higher-priority completed tasks τ j will interfere with task τ i mostly over the interval x.This interference extends to the mode-change window as the higher-priority tasks still run in order to complete their execution.The total interference is formulated as the ceiling function of x/T j as follows: 5.1.1.2Interference from higher-priority aborted tasks Aborted tasks will interfere over a lower-priority task τ i during the interval x.Within the interval x there is an integral number of periods T j of the higher-priority aborted task τ j , and therefore a set of instances that complete their execution.It is only the last release that runs across the MCR and has to be aborted.The interference from completed releases of task τ j before the MCR is given by: We also need to consider the amount of aborted execution time of a higher-priority task in the old mode: This occurs during the remaining time w rem , which is a fraction of the period of the aborted task preceding the MCR, and is given by: The remaining time w rem can be large enough to: 1) allow only a partial execution of the task τ j (equation ( 4)), since w rem < C j , or 2) accommodate an additional execution of the higher-priority aborted task (equation ( 5)), since w rem ≥ C j ): In the first case (eq.4), w rem < C j and the interference is the minimum value between C j and w rem , since there is only a partial execution of the aborted task (i.e.I hp(A)rem = min(w rem , C j ).

54
Real-Time Systems, Architecture, Scheduling, and Application www.intechopen.com In the second case ( eq. 5), w rem ≥ C j and there is another full execution of the task within w rem : it is not really necessary to abort the task.The remaining time is greater than C j but less than the period.Again the interference is the minimum value between C j and w rem .Once the task completes there is no further releases in the remaining time.Therefore, the amount of interference is C j .In any case, the partial interference is always the minimum of the intervals w rem and C j .Therefore, the amount of partial (or aborted) interference is given by: Combining both terms ( 6) and ( 2), the total interference from higher-priority aborted tasks is: 5.1.1.3Interference from higher-priority new-mode tasks Higher-priority new-mode tasks do not preserve their mode-change periodicity.The analysis must account for the fact that these tasks are released with an offset Y j from the MCR.Their interference interval is therefore reduced to w i − x − Y j and expressed as: 5.1.1.4Interference from higher-priority unchanged new-mode tasks As discussed in section 3, unchanged new-mode tasks preserve the mode-change periodicity.This term is derived by Real & Crespo (2004), and given by: Combining all the interference terms, we obtain the total interference suffered from the old-mode task τ i across the mode change: By adding the Worst-Case Execution Time (WCET) C i of the old-mode task being analyzed, we obtain the WCRT of task τ i as follows: The solution to equation ( 11) is obtained by forming a recurrence equation on w i , to find the smallest positive integer that satisfies it.Since many values of x give the same WCRT, the significant values of x are the ones that lead to new values for the ceiling and floor functions.The set of significant values x is the set of all positive values in the domain of w i (x) such that: where ǫ is the time quantum, which we assume to be 1 and R ss i is the steady-state WCRT of task τ i .

Analysis of new-mode tasks
In the worst-case scenario, all old-mode tasks are released momentarily before the mode change, thus sharing a critical instant with the window w i .The interference from higher-priority new-mode tasks upon a new-mode task τ i must account for the offset of the interfering task, during which there is no interference.The interference from unchanged new-mode tasks must account for the offset Z j , from the end of the period of the preceding old-mode version.The worst-case response time of a new-mode task across a mode change is given by: (Pedro & Burns, 1998;Real & Crespo, 2004) This equation must also be solved using recurrence relation as before.Considering that task τ i is released with an offset Y i after the mode change, then to obtain the value of R i window w i must be decreased by If the expression w i − C i(n) ≤ Y i holds, the amount of interference over new-mode task τ i is smaller than the value of its mode-change offset Y i .Therefore, the new-mode task τ i is released in the steady state after all old-mode tasks have completed.
We now turn to the analysis of tasks across a mode change with arbitrary deadlines.

56
Real-Time Systems, Architecture, Scheduling, and Application

Mode-changes with arbitrary deadlines
Lehoczky describes qualitative analysis which can determine the worst-case response time of a given task with such arbitrary deadlines (Lehoczky, 1990).Tindell et al. (1994) derived analysis from that of M. & Pandya (1986) and using the approach of Lehoczky, for static priority pre-emptive systems that permit tasks to have arbitrary deadlines, release jitter, and behave as sporadically periodic tasks.His analysis illustrates how using a window approach to finding worst-case response times for these tasks is an appropriate way of obtaining an analysis tailored to the behavior of real-time tasks.In single mode, steady-state systems, the busy period w i,q for a task τ i with arbitrary deadlines is calculated as follows (Tindell et al., 1994): Where the term I hp is the interference from higher-priority tasks, and q is the number of instances of task τ i during the busy period.Equation 15 is the basis to extend current analysis of mode changes to allow arbitrary deadlines.Therefore, for the analysis of mode changes with arbitrary deadlines, we need to: 1) review the notion of busy period in the light of mode changes, specifically the definition of the beginning and end of the busy period; 2) find the number of instances q of a task τ i to be analyzed, and 3) determine the amount of interference from higher-priority computation (I hp ), as follows: • Busy periods:Alevel-i busy period is defined as the maximum time for which a processor executes tasks of priority greater than or equal to the priority of task τ i .Lehoczky shows how the worst-case response time of a task τ i can be found by examining a number of busy periods, each starting at an arrival of task τ i (hence some multiple of T i before the current invocation of task τ i ).The busy period ends when a lower-priority task is able to begin execution.
To find the worst-case response time, all invocations of task τ i in this busy period must be examined.In Fig. 2 task τ i completes when the given busy period finishes, but arrives at some point in time after the start of the busy period.By knowing the width of the busy period and when the busy period starts (relative to arrival of task τ i ) then we can find the corresponding response time.The width of the busy period is equal to the higher-priority computation that is released in it.The WCRT of task τ i is the longest of the response times corresponding to each of the examined busy periods.In the next section we discuss the beginning and end of the busy period regarding a mode change.
• Number of instances to analyze: If a task has a WCRT greater than its period, then the possibility exists for a task to re-arrive before the previous invocation has completed.In this case we assume that the new arrival is deemed to have a lower priority, and is therefore delayed from executing until after the previous invocation terminates.Fig. 3 illustrates the response time of a task τ i , with its deadline larger than its period, executing across a mode change as an old-mode completed task.The MCR arrives during the execution of an arbitrary invocation of task τ i .To facilitate the analysis we assume, without loss of generality, that the MCR arrives while the third invocation of task τ i is under execution.In a busy period without a mode change, the 4 th and 5 th invocations are released and execute regularly.However, with the arrival of a MCR, the 4 th and the 5 th invocations do not need to be released anymore, according to the mode-change model.The cancellation of both the 4 th and the 5 th releases will shorten the length of the busy period, causing the lower-priority task (task low) to begin execution earlier.Therefore, we need to apply the Fig. 2. A level i busy period (Lehoczky, 1990), (Tindell et al., 1994) schedulability analysis only for the first three invocations.However, it is only the third invocation that needs to be analyzed using mode-change analysis.The first and second invocations can be analyzed using the steady-state equations derived by Tindell et al. (1994).
Clearly, other types of tasks such as wholly new and changed new-mode tasks may interfere with the execution of task τ i .While an invocation of T high may be delayed by a previous invocation, the number of instances of T high interfering with task τ i is not affected by the introduction of arbitrary deadlines.Therefore, the calculation of higher-priority computation under the assumption of arbitrary deadlines remains the same as the one from previous work (Real & Crespo, 2004).
We now look at the analysis of old-mode tasks.

Analysis of old-mode tasks
We begin by extending the notion of busy period for old-mode tasks: A level "i" busy period for an old-mode task across a mode change is defined as the maximum time for which a processor executes tasks of priority greater than or equal to the priority of task.A busy period begins at a time x before the arrival of a mode-change request (MCR).The busy period ends during the transition, with the completion of the last invocation q of task τ i before the steady-state new mode, when a lower-priority task is able to begin execution.From the definition of latency of mode changes (section 3), it follows that the end of the busy period falls inside the mode-change window.This is because task τ low is an old-mode completed and the mode change is not over until all the old-mode tasks have completed.
Consider the three instances of task τ i before the MCR in Fig. 3. Instances 1 and 2 are called the steady-mode instances, since they are released and completed before the MCR.W ea r e interested in finding the WCRT for the third instance, the old-mode completed instance, which runs across the MCR and executes through the mode change.When the old-mode completed invocation begins, the steady-mode invocations have already completed.Therefore, their schedulability is guaranteed by steady-state analysis (Audsley et al., 1993).
By defining the beginning and the end of the busy period as above we can reuse the work from Pedro & Burns (1998) and Real (2000) by including in their analysis the multiple WCETs introduced by the steady-mode releases (i.e.previous invocations of task τ i ) during window x.In our example, the third invocation is delayed by the first and second invocations.
There are no further releases of the old-mode completed task after the MCR, according to the mode-change protocol.As we increase the value of x in the analysis, more steady-state invocations of task τ i appear before the MCR, potentially delaying the old-mode completed task τ i .The impact of a mode change on the analysis of old-mode tasks is that there are less releases of task τ i to be analyzed than in steady-state analysis.The number of instances q of task τ i that need to be analyzed before the mode change is given by:

59
Schedulability Analysis of Mode Changes with Arbitrary Deadlines www.intechopen.comand it is only the last invocation that requires mode-change analysis.The interference suffered by the mode-changing task includes the types of tasks from the mode-change model, i.e. old-mode aborted, old-mode completed, new-mode changed, unchanged and wholly-new tasks as previously analyzed.Taking these remarks into consideration, the analysis of a mode-change for an old-mode task with arbitrary deadlines is given by: In single-mode, steady-state systems, windows for increasing values of q need to be determined.The sequence is finite, however, because the search can stop if a level i busy period is found which finishes before task τ i starts (i.e. the processor is released to process lower-priority tasks) -since the processor is executing lower priority tasks there can be no impact on task τ i from previous invocations of task τ i in busy periods starting earlier.The above iteration over increasing values of q can stop if: The response time corresponding to the window starting qT i before the current invocation of task τ i is therefore given by: Now, as mentioned above, the worst-case response time can occur at any one of these response times, and thus the WCRT is given by: In the analysis with arbitrary deadlines and single mode systems, windows for increasing values of q need to be determined; variable x is not present in the analysis.In the WCRT analysis of mode changes with deadlines less than or equal to periods we need to apply all significant values of x, and the analysis is not a function of q.Clearly, the analysis of tasks with arbitrary deadlines across a mode change is a function of both x and q, and q is limited by x (for old-mode tasks).

Analysis of new-mode tasks
A level i busy period for a new-mode task is defined as: The maximum time for which a processor executes tasks of priority greater than or equal to the priority of task τ i .A busy period begins with the arrival of a mode-change request MCR.It ends when a task with lower priority than τ i is able to begin execution during the mode-change window.
As seen in section 5.2, the pattern of interference from higher computation over τ i is not affected by the introduction of arbitrary deadlines.As with the analysis for old-mode tasks, the new-mode task is delayed by its previous invocations.Therefore, equation ( 13) is reformulated as follows: Unlike the analysis of old-mode tasks, which limits the number of busy periods to be examined by ⌈ x T i ⌉, in the analysis of new-mode tasks the of instances q to be inspected has no direct correlation with the beginning or end of the mode change.The above iteration over increasing values of q can stop if: The first qT of level i busy period falls before the current invocation of task τ i is released.
The response time corresponding to the given level i busy period starting time qt before the current invocation of task τ i is therefore given by: w i,q − qt.The response time can occur at any one of these response times, and thus the worst-case response time is given by: Where q = {0, 1, 2...}.This equation specifies an infinite number of busy periods.Only a finite number need to be examined because the search can stop if a level i busy period is found which finishes before the invocation of task τ i following the current one.The longest busy period that needs to be examined is bounded by the LCM of task periods.

Example
In this section we present an example of the mode change analysis based upon the Generic Avionics Platform (GAP) task set described by Locke et al. (1991).We consider the example of two modes of aircraft operation: Level flight and Defense Mode, described in tables 1 and 2 respectively (Pedro, 1999), and we analyze the schedulability of the transition from level-flight to defense mode.The level-flight mode contains four tasks which are not originally defined in the GAP set: auto − pilot, mission − advisor, fuelling − management and display − graphic − 2.
The task set used in the defense mode is the original task set defined (Locke et al., 1991), except that the Timer − Interrupt task has been removed.
Tasks printed in boldface in table 1 denote completed old-mode tasks that are replaced by the corresponding boldfaced wholly-new tasks in table 2 (e.g.Weapon − Release replaces Auto − Pilot).Tasks in the defense mode are carried out as new-mode changed tasks.Display − Hook − Update is an aborted task.In order to increase the schedulability of the task set, all new-mode tasks lose their periodicity during the transition. .Tasks with a lower value of P have a higher priority.All times are specified in milliseconds with a multiplication factor of 10.
The latency of the mode change is given by new-mode task τ 34(c) , which completes its first execution at time 21400 (i.e.R i (n)+Y i = 2140 ms) after the MCR.The worst-case response times of all tasks are less than the deadlines, and hence the task set is schedulable across the mode change.If task WCRT's are much less than their periods (i.e.R i << T i ) then the analysis will converge immediately for values of q = 0.There are no extra invocations (q = 1,2,3..) in the busy period.Task τ 13(O) is an exception: it has a period T 13 = 1100 and deadline D 13 = 1550 (D > T).Its WCRT is 1227 and it occurs when the task arrives at time x = 801 before the MCR.In the worst-case, τ 13(O) is delayed by one single invocation (i.e.q = 1) before the MCR, but it is still able to meet its deadline.

Summary and discussion
Before we discuss the schedulability analysis of tasks across a mode change, we must define what a mode of operation is in real-time systems and what a mode change from a source to a target mode represents.In the first part of this chapter we have surveyed the literature and presented a number of views on the notion of modes, before formulating our definition for real-time systems.
The second focus of this work was on guaranteeing hard real-time tasks with arbitrary deadlines that execute through a mode change.Original work on schedulability analysis for real-time tasks across mode changes assumes that all task have deadlines less than or equal to their periods.This work relaxed this constraint, by allowing tasks to have arbitrary deadlines.
It also showed the generality of the analysis presented by Tindell et al. (1994) on arbitrary deadlines: when proper busy periods are considered, schedulability analysis for fixed-priority preemptive systems is amenable to extensions such as the one presented in this chapter.From another perspective, the schedulability results of mode changes by Pedro & Burns (1998) and Real & Crespo (2004) can be extended to allow for arbitrary deadlines without major modifications to their original analysis.
In order to introduce arbitrary deadlines in the schedulability analysis of mode changes of Pedro & Burns (1998) and Real & Crespo (2004) we had to consider: 1) The definition of busy periods in the light of mode changes; 2) The amount of higher-priority computation; 3) The number of instances q of the task being analyzed τ i , and 4) The delays from earlier invocations of task τ i .Therefore, we introduced the following modifications to the original analysis: but assumes a fixed message set with one single mode of operation.Before we tackle the schedulability analysis of messages across a mode change in a CAN bus, we need to be familiar with the schedulability analysis of mode changes with arbitrary deadlines, such as the one derived in this chapter.

55Schedulability
Analysis of Mode Changes with Arbitrary Deadlines www.intechopen.com

Table 1 .
Task Set Description in Aircraft Level-Flight Mode schedulability analysis for the mode change from the level-flight mode to the defense mode.Each column represents the period T, deadline D, WCET C, priority P, the worst-case arrival time for an old-mode task x, the steady-state response time for a task in the old mode R ss i(O) , the WCRT of a task during the mode change R i(mc) and the steady-state WCRT of a new-mode task R ss i(N)

Table 3 .
Feasibility Analysis of GAP Task Set Across a Mode Change 63 Schedulability Analysis of Mode Changes with Arbitrary Deadlines www.intechopen.com