Quality of Service Scheduling in the Firm Real-Time Systems

(Software Open Components on the Shelf for Embedded Real-Time Applications) . This project aims to provide efﬁcient services to real-time applications (Silly et al., 2007). It enriches real-time Linux variants with enhanced real-time facilities.

A real-time monitoring system must provide updated data within strict time constraints. It is essential to have an efficient real-time scheduling of all the periodic sampling tasks.

Scheduling issue
Such a real-time system is often operated in environments that are subject to significant uncertainties. Some parameters such as emergency events, asynchronous demands from external devices (e.g. base station requests for statistical computations on sampled data) or 192 Real-Time Systems, Architecture, Scheduling, and Application www.intechopen.com Quality of Service Scheduling in the Firm Real-Time Systems 3 even energy starvation cannot be accurately characterized at design time. The occurrence of such situations will temporarily make the system overloaded (i.e. the processing power required to handle all the tasks will exceed the system capacity). The scheduling will then consist in determining the sequence of execution of sampling tasks in order to provide the best QoS.
The scheduling will play a significant role because of its ability to guarantee an acceptable sampling rate for all the tasks. The scheduler aims to gracefully degrade the QoS (i.e. sampling rate) to a lower but still acceptable level -e.g. a recording at 15 values per minute instead of 30 values per minute for wind speed -in such an overload situation. The execution of some (least important) tasks will be skipped. For instance, it will be less harmful to an air quality surveillance system to skip one wind speed record than to interrupt the transmission of the carbon dioxide level. Given this observation, one gets a better understanding of the real-time CPU scheduling flexibility needed in such applications.
In this chapter, we address the problem of the dynamic scheduling of periodic tasks with firm constraints. The scope of this study concerns maximizing the actual QoS of periodic tasks i.e. the ratio of instances which complete before deadline.

Scheduling skippable periodic tasks 2.1 Related work
Different approaches have been proposed in order to specify firm real-time systems. In (Hamdaoui & Ramanathan, 1995), the concept of (m,k)-firm deadlines permits us to model tasks that have to meet m deadlines every k consecutive instances. The Distance-Based Priority (DBP) scheme increases the priority of a job in danger of missing more than m deadlines over a sliding window of k instances for service. In order to specify a task that tolerates x deadlines missed over a finite range or window among y consecutive instances, a windowed lost rate is also proposed in (West & Poellabauer, 2000). In (Bernat et al., 2001), the authors describe a more general specification of the distribution of met and lost deadlines. Virtual Deadline Scheduling (VDS)  and Dynamic Window-Constrained Scheduling (DWCS)  are other existing schedulers provably superior to DBP for a number of specific and non-trivial situations.
The notion of skip factor is presented in (Koren & Shasha, 1995). The skip factor of a task equal to s means that the task will have one instance skipped out of s. It is a specific case of the (m,k)-firm model with m = k − 1. Skipping some task instances then permits us to transform an overload situation into an underload one. Making optimal use of skips has been proved to be an NP-hard problem. (m,k)-hard schedulers are presented in (Bernat & Burns, 1997). Most of these approaches require off-line feasibility tests to ensure a predictable service.
Scheduling hybrid task sets composed of skippable periodic and soft aperiodic tasks has been studied in (Buttazzo & Caccamo, 1999;Caccamo & Buttazzo, 1997). A scheduling algorithm based on a variant of Earliest Deadline First (EDF) exploits skips under the Total Bandwith Server (TBS). In our previous work (Marchand & Silly-Chetto, 2005;2006), we make use of the same approach with the Earliest Deadline as Late as possible server (EDL). These results led us to propose a raw version of the Red tasks as Late as Possible (RLP) algorithm (idle time schedule based on red tasks only) (Marchand, 2006;Marchand & Chetto, 2008).

193
Quality of Service Scheduling in the Firm Real-Time Systems

www.intechopen.com
In contrast, tasks with soft real-time constraints still have a value even when completing after their deadlines. In this case, task overruns can cause overload situations that may be managed by overrun handling mechanisms such as Overrun Server Method (OSM) (Tia et al., 1995), CApacity SHaring (CASH) (Caccamo et al., 2000) or Randomized Dropping (RD) (Bello & Kim, 2007). A more complete survey on overrun handling approaches in soft real-time systems can be found in (Asiaban et al. , 2009).

The skip-over model
Each periodic task T i is characterized by a worst-case computation time c i , a period p i ,a relative deadline equal to its period and a skip factor s i -which gives the tolerance of this task to missing deadlines -2 ≤ s i ≤ ∞. Every periodic task instance can be either red or blue under the terminology introduced in (Koren & Shasha, 1995). A red instance must complete before its deadline; a blue instance can be aborted at any time. The operational specification of a skippable periodic task T i is composed of four characteristics: (1) the distance between two consecutive skips must be at least s i periods, (2) if a blue instance is skipped, then the next s i − 1 instances are necessarily red, (3) if a blue instance completes successfully, the next instance is also blue and (4) the first s i − 1 instances are red. The assumption s i ≥ 2 implies that, if a blue instance is skipped, then the next one must be red. The assumption s i = ∞ signifies that no skip is authorized for task T i . Skips permit us to schedule systems that might otherwise be overloaded. The system is overloaded since U p = ∑ n i=1 c i p i = 4 6 + 1 2 = 1.17 as shown in Figure 2. Allowing T 2 to skip one instance over three enables us to produce a feasible schedule. ✲ ✲ 6 6 6 6 6 6 6 6 6 6 6 6 6 6 0 6 12 18 024681 0 1 2 1 4 1 6 1 8 T 1 (4, 6, ∞)  (Liu &Layland, 1973) show that a task set {T i (c i , p i );1 ≤ i ≤ n} is schedulable if and only if its cumulative processor utilization (ignoring skips) is not greater than 1, i.e., (1) (Koren & Shasha, 1995) prove that the problem of determining whether a set of periodic occasionally skippable tasks is schedulable, is NP-hard. However, they prove the following necessary schedulability condition for a given set  (Caccamo & Buttazzo, 1997) introduce the notion of equivalent utilization factor defined as follows.
DEFINITION 1. Given a set Γ = {T i (p i , c i , s i )} of n skippable periodic tasks, the equivalent utilization factor is defined as: They also provide a sufficient condition in (Caccamo & Buttazzo, 1998) for guaranteeing a feasible schedule of a set of skippable tasks:

RTO (Red Tasks Only)
The first algorithm called Red Task Only (RTO) (Koren & Shasha, 1995) always rejects the blue instances whereas the red ones are scheduled according to EDF. Deadline ties are broken in favor of the task with the earliest release time. Generally speaking, RTO is not optimal. However, it becomes optimal under the particular deeply red task model where all tasks are synchronously activated and the first s i − 1 instances of every task T i are red. The scheduling decision runs in the worst-case in O(n 2 ) where all the n tasks are released simultaneously. Figure 3 depicts a RTO schedule for the task set T = {T 0 , T 1 , T 2 , T 3 }. Table 1 gives the characteristics of T . Tasks have uniform skip factor s i = 2. The total processor utilization U p = ∑ c i p i is equal to 1.19. The equivalent processor utilization U * p is equal to 0.79. This consequently guarantees the feasibility of the task set under minimal QoS.
Task T 0 T 1 T 2 T 3 c i 4 6 9 4 p i 36 24 18 12 The schedule produced by RTO exhibits the lowest acceptable QoS level for the task set . All blue instances are systematically rejected every s i periods for each task.

BWP (Blue When Possible)
The second scheduling algorithm called Blue When Possible (BWP) algorithm (Koren & Shasha, 1995) is an improvement of RTO. Blue instances can execute only if there are no red ready instances. Deadline ties are still broken in favor of the task with the earliest release time. BWP improves RTO in that it offers a higher QoS resulting from the successful completions of blue instances.   Figure 4 illustrates a BWP schedule for the task set T (see Table 1).
As can be seen, BWP increases the total number of task instances that complete successfully. Five deadlines of blue instances are missed at instants t = 24 (task T 3 ), t = 36 (task T 2 ), t = 48 (tasks T 1 and T 3 ) and t = 72 (task T 3 ). In contrast, all deadlines of blue instances are missed under RTO which represents a total of seven instances.

CPU idle times determination under EDL
The basic foundation of our scheduling approach for enhancing the QoS of skippable periodic tasks relies on the Earliest Deadline as Late as possible (EDL) algorithm (Chetto & Chetto, 1989). Thus, we will review the fundamental properties of this algorithm. Such an approach is known as Slack Stealing since it makes any spare processing time available as soon as possible.
In doing so, it effectively steals slack from the hard deadline periodic tasks. A means of determining the maximum amount of slack which may be stolen without jeopardizing the hard timing constraints is thus key to the operation of the EDL algorithm. We described in Chetto & Chetto (1989) how the slack available at any current time can be found. This is done by mapping out the processor schedule produced by EDL for the periodic tasks from the current time up to the end of the current hyperperiod (the least common multiple of task periods). This schedule is constructed dynamically whenever necessary. It is computed from a static EDL schedule constructed off-line and memorized by means of the following two vectors: • K, called static deadline vector. K represents the instants from 0 to the end of the first hyperperiod -at which idle times occur -and is constructed from the distinct deadlines of periodic tasks.

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

www.intechopen.com
Quality of Service Scheduling in the Firm Real-Time Systems 7 • D, called static idle time vector. D represents the lengths of the idle times which start at instants of K.
The dynamic EDL schedule is updated at run-time from the static one. It takes into account the execution of the current ready tasks. It is described by means of the following two vectors: • K t , called dynamic deadline vector. K t represents the instants k i from t in the current hyperperiod at which idle times occur. • D t , called dynamic idle time vector. D t represents the lengths of the idle times that start at instants k i given by K t .
Assume now that, given the task set T = {T 1 (3, 10, 10); T 2 (3, 6, 6)}, we want to compute idle times from instant t = 5 while tasks have been processed by EDF from 0 to t. The resulting schedule is depicted in Figure 5. Note that f EDL = 1 if the processor is idle at t, 0 otherwise. Next, tasks are scheduled as late as possible according to EDL from time t = 5 to the end of the hyperperiod. Nonzero idle times resulting from the computation of vectors K t and D t appear at times t = 5, t = 6, t = 12 and t = 20. Chetto & Chetto (1989) showed that the EDL schedule computation can be efficiently used for improving the service of aperiodic tasks. By definition, soft aperiodic requests must not compromise the guarantees given for periodic tasks and should be completed as soon as possible. No acceptance test is performed for soft aperiodic requests; they are served on a best-effort basis within the computed idle times, the goal being to minimize their response times. Concerning hard aperiodic tasks, each task is subject to an acceptance-rejection test upon arrival. Hard aperiodic tasks can indeed easily be admitted or rejected on the basis of the knowledge of idle times localization.
In the next sections, we are first interested in using EDL to build a schedule on the red instances only so as to execute the blue instances as soon as possible in the remaining EDL idle times (see section 3.2 The RLP algorithm). In a second phase, EDL will allow us to derive a test for deciding on-line whether a blue instance can be accepted for execution or not (see section 3.3 The RLP/T algorithm).

The RLP algorithm
BWP executes blue instances in background beside red ones. Processor time is often wasted due to the abortion of uncompleted blue instances that have reached their deadlines. Figure 4 shows that task T 2 is aborted at time t = 36. This leads to 8 units of wasted processor time.

Algorithm description
The Red tasks as Late as Possible (RLP) algorithm (Marchand & Chetto, 2008) brings forward the execution of blue instances so as to enhance the actual QoS (i.e., the total number of successful executions). From this perspective, RLP runs as follows: • if no blue instance waits for execution, red instances execute as soon as possible according to the EDF scheduling rule. • else (i.e. at least one blue instance is ready for execution), blue instances execute as soon as possible according to EDF scheduling (note that it could be according to any other scheduling heuristic), and red instances are processed as late as possible according to EDL. Figure 6 gives the pseudo-code of the RLP algorithm. RLP maintains three task lists which are sorted in increasing order of deadline: waiting list, red ready list and blue ready list.
• waiting list: list of instances waiting for their next release, • red ready list: list of red instances ready for execution, • blue ready list : list of blue instances ready for execution.
At every instant t, the scheduler performs the following actions: 1. it updates all the three lists: instances may be released or aborted according to their current state (i.e. waiting or ready red/blue instances), 2. if t belongs to an EDL idle time, it selects the first instance in the blue ready list for execution. Otherwise it selects the first instance in the red ready list.
The main idea of this approach is to take advantage of the slack of red instances. The determination of the latest start time for every red instance requires preliminary construction of the schedule by a variant of the EDL algorithm taking skips into account (Marchand & Silly-Chetto, 2006). We assume in the EDL schedule established at time τ that the instance following immediately a blue one -which is part of the current periodic instance set at time τ -is red. Indeed, none of the blue instances is guaranteed to complete within its deadline.
We proved in (Silly, 1999) that the online computation of the slack time is required only at instants which corresponds to the arrival of a request while no other is already present on the machine. The EDL sequence is constructed here not only when a blue instance is released -and no other one was already present -but also after a blue task completion, if blue tasks remain in the system. The next task instance of the completed blue task has then to be considered as a blue one. Note that blue instances are executed in the EDL idle times with the same importance as red instances, contrary to BWP which always assigns higher priority to red instances.

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

www.intechopen.com
Quality of Service Scheduling in the Firm Real-Time Systems 9 Algorithm RLP(t : current time) begin /*checking blue ready list in order to abort tasks*/ while (task=next(blue ready list)=not(∅)) if (task→release time+task→critical delay<t) break endif Pull task from blue ready list task→release time+= task→period task→current skip value=1 Put task into waiting list endwhile /*checking waiting list in order to release tasks*/ while (task=next(waiting list)=not(∅)) if (task→release time>t) break endif if ((task→current skip value < task→max skip value) and (f_EDL(t)=0)) /*red task release*/ Pull task from waiting list Put task into red ready list else if (blue ready list=∅) Compute EDL_schedule endif if (f_EDL(t)!=0) /*blue task release*/ Pull task from waiting list Put task into blue ready list endif endif task→current skip value+=1 endwhile if ((blue ready list=not(∅)) and (f_EDL(t)!=0)) /*checking red ready list in order to suspend task*/ while (task=next(red ready list)=not(∅)) Pull task from red ready list Put task into waiting list endwhile endif end

Illustrative example
Consider the periodic task set T defined in Table 1. The relating RLP scheduling is illustrated in Figure 7. The number of deadline misses has been reduced to four. Missed deadlines occur at instants t = 36 (task T 3 ), t = 54 (task T 2 ) and t = 72 (tasks T 1 and T 3 ). Observe that the first blue instance T 2 which failed to complete within its deadline under BWP scheduling (see Figure 4)

Algorithm description
The Red tasks as Late as Possible with blue acceptance Test (RLP/T) algorithm (Marchand & Chetto, 2008) is an improvement of RLP designed to maximize even more the actual QoS.
RLP/T runs as follows: red instances enter the system directly at their arrival time whereas blue instances integrate the system upon acceptance. A blue instance is scheduled as soon as possible together with red ones once accepted. All the ready instances are of the same importance. Deadline ties are broken in favor of the task with the earliest release time.
Processor idle times are computed according to the EDL strategy once a new blue instance is released. We assume that the instance immediately following a blue instance is also blue in the EDL schedule established at time τ. All blue instances previously accepted at τ are guaranteed by the schedulability test. It ensures there are enough idle times to accommodate the new blue instance within its deadline, as described hereafter.

Acceptance test of blue instances under RLP/T
The question we ask now can be formulated as follows: "Given any occurring blue instance B, can B be accepted?". B will be accepted provided a valid schedule exists, i.e. a schedule in which B will complete within its deadline while all periodic instances previously accepted will still meet their deadlines. Let τ be the current time which coincides with the release of a blue instance B. B(r, c, d) is characterized by its release time r, its execution time c and its deadline d, with r + c ≤ d. We assume that the system supports several uncompleted blue instances at time τ previously accepted. Let's denote by B(τ)={B i (c i (τ), d i ), i=1 to blue(τ)}, the blue instance set at time τ. The value c i (τ) is called dynamic execution time and represents the remaining execution time of B i at τ. B(τ) is ordered such that i < j implies d i ≤ d j .
Theorem 2 presents the acceptance test of blue instances within a system involving RLP skippable tasks. This test is based on theoretical results established in (Silly- Chetto et al., 1990) for the acceptance of sporadic requests that occur in a system composed of non-skippable periodic tasks.

THEOREM 2. Instance B is accepted if and only if, for every instance
It defines the maximum units of time during which B i could be delayed without violating its deadline. Ω EDL T (τ) (τ, d i ) denotes the total units of time that the processor is idle in the time interval [τ, d i ]. The total computation time required by blue instances within [τ, d i ] is given by ∑ i j=1 c j (τ). The acceptance test is based on the computation of EDL idle times which gives the slack of any blue instances. Then, this slack is compared to zero. The acceptance test runs in O(⌊ R p ⌋n + blue(τ)) in the worst-case, where n is the number of periodic tasks, R is the longest deadline and p is the shortest period. blue(τ) denotes the number of blue instances at time τ whose deadline is greater or equal to the deadline of B i . A specific updating of additional data structures with slack tables may reduce the complexity to O(n + blue(τ)) as proved in (Tia et al., 1994). Figure 8 gives an illustration of RLP/T scheduling for the periodic task set T defined in Table 1. Clearly, RLP/T improves on both RLP and BWP. Only three deadline violations relative to blue instances are observed: at instants t = 36 (task T 3 ), t = 54 (task T 2 ) and t = 72 (task T 3 ). The acceptance test contributes to compensating for the time wasted in starting the execution of blue instances which are not able to complete before deadline. The blue instance T 2 released at time t = 36 is aborted at time t = 54 -8 units of time were indeed wastedin the RLP case (see Figure 7). This rejection performed with RLP/T permits us to save time recovered for the successful completion of the blue instance T 1 released at time t = 48.

Performance analysis 4.1 Simulation details
We report part of a performance analysis composed of three simulation experiments in order to evaluate RLP/T with respect to RTO, BWP and RLP.
We successively measure: • the QoS (i.e. the ratio of instances that complete within their deadline), • the CPU wasted time ratio (i.e. the percentage of useless processing time),

201
Quality of Service Scheduling in the Firm Real-Time Systems • the CPU idle time ratio (i.e. the percentage of time during which the processor is not processing any task).
We make the processor utilization U p vary. The simulator generates 50 sets of periodic tasks. Each set contains 10 tasks with a least common multiple of periods equal to 3360 time units. The tasks have a uniform skip factor s i . Worst-case computation times depend on U p . Deadlines are equal to periods and greater than or equal to computation times. Simulations have been processed over 10 hyperperiods. Figure 9 depicts the simulation results for s i =2. The results are given for an actual computation time (ACET) equal to 100% and 75% of the worst-case computation time (WCET) respectively. Let us recall that the tasks have variable actual computation times assumed to be less than an estimated worst-case computation time. The assumption that a task consumes its WCET in every activation is not necessarily true. This implies that the actual CPU utilization never exceeds the estimated one used in the schedulability test. BWP and RLP outperform RTO -for which the QoS is constant and minimal -for any processor workload. Both BWP and RLP succeed in completing all blue instances that respectively execute after and before red instances for Up ≤ 1. RLP and BWP give almost the same performances under overload. Nevertheless, RLP/T provides a significant improvement in performance compared with RLP. The QoS observed for BWP, RLP and RLP/T is higher for a given processor utilization when the task's computation time is less than the task's worst-case execution time. As the amount of time given by WCET − ACET is not used by each instance, additional CPU time permits us to successfully complete a higher number of instances.

Experiment 1
Moreover, note that BWP and RLP outperform RLP/T for low overloads with ACET=0.75* WCET. This comes from the admission test in RLP/T which uses WCET values and not ACET ones. Consequently, RLP/T rejects instances that after all could have been accepted on the basis of their ACET. This is exactly what we observe for U p equal to 130%: RLP/T temporarily offers lower performances than BWP and RLP. Note that this phenomenon is no longer observable once the skip factors are higher (e.g. s i = 6).
Finally, other tests (Marchand, 2006) -not reported here -show that the higher the skip factor is, the more significant the advantage of RLP/T over the other scheduling algorithms.

Experiment 2
We study here the CPU time wasted in incomplete executions of blue instances. The simulation results for s i = 2 and s i = 6 are depicted in Figure 10. The wasted CPU time is equal to zero for RTO since all red instances execute successfully. It is also equal to zero under RLP/T for any CPU utilization. This is due to the admission test that prevents from the abortion of blue instances. A blue instance is accepted if and only if it can complete before deadline.
The wasted CPU time is always positive under BWP and RLP once the system is overloaded (U p > 1). BWP and RLP involve the largest wasted CPU time -24% et 26% respectively -for U p = 115% and s i = 2. The BWP and RLP curves present a decline beyond that load. More red instances have to be executed under high overload. Less available CPU time is consequently available for the execution of blue instances.
Additional results reported in (Marchand, 2006) show that wasted CPU time is all the less significant as skip factors grow.

Experiment 3
Finally, we study the CPU idle time ratio given by the percentage of time during which the processor is not processing any task. This measure quantifies the ability to face a dynamic processing surplus (e.g. the arrival of an aperiodic task). Simulation results for s i = 2 and s i = 6 are presented in Figure 11.
(a) s i = 2 (b) s i = 6 Fig. 11. CPU idle time for low and high skips We note that the CPU idle time ratio under RTO is the highest one compared with all strategies. This ratio declines in a linear fashion according to U p . It varies from 55% for U p = 90% to 10% for U p = 180% and s i = 2. Note the singular points of the curves s i = 2 and s i = 6: when U p = 100% idle time ratios are respectively equal to 1 2 = 50% and 1 6 = 16.7% which correspond exactly to the skip factors.
Idle time ratios are identical and positive -e.g. idle time = 10% for U p = 90% -when U p < 100% under BWP, RLP and RLP/T. They decline in a linear fashion until reaching a zero value for U p = 100%.
Results differ for overloaded systems (U p > 100%). RLP involves no CPU idle time whatever the skip factors are. We observe that BWP involves a low idle time ratio only under low skip ratios. RLP/T clearly appears as the most efficient strategy, still offering idle time under light overloads. For example, the idle time ratio under RLP/T for s i = 2 and U p = 115% is equal to 9%. RLP/T gives a low and still positive idle time ratio even when the system is highly overloaded.
In summary, RLP/T proves to be the most suitable scheduling strategy to cope with transient overloads while providing the highest Quality of Service.

CLEOPATRE components have been prototyped under Linux/RTAI (Real-Time Application
Interface) (Racciu & Mantegazza, 2006) and distributed under the LGPL license. The LGPL allows proprietary code to be linked to the GNU C library, glibc. When a program is linked with a library -whether statically or using a shared library -the combination of the two is legally speaking a combined work, a derivative of the original library. Companies do not have to release the source to code that which has been dynamically linked to an LGPLed library. This makes the use of such codes much more attractive.
The CLEOPATRE library offers selectable COTS (Commercial-Off-The-Shelf) components dedicated to dynamic scheduling, aperiodic task servicing, resource control access, fault-tolerance and QoS scheduling. An additional task named TCL (Task Control Logic) interfaces all the CLEOPATRE components and has the highest priority. It has been added as a dynamic module in $RTAI D I R/modules/TCL.o and interfaces with the legacy RTAI scheduler defined in $RTAI D I R/modules/rtai_sched.o, as depicted in Figure 12.
The CLEOPATRE interface is totally independent from the RTAI core layer. It can be directly used with Xenomai -which supports the RTAI API -and easily adapted to any other real-time Linux extension.

Overheads and footprints
The memory and disk footprints of the operating system turn out to be key issues for embedded real-time applications as well as the time overhead incurred by the operating system itself. Table 2 gives the footprints for the schedulers provided by CLEOPATRE. The smallest footprint of an application using a QoS scheduler comes to 52.4 KB in memory (65.2 KB on hard disk). This corresponds to the total load due to RTAI, the TCL task and the RTO scheduler. On the contrary, the greatest footprint corresponds to the RLP/T scheduler (i.e. 60.9 KB in memory and 75.3 KB on hard disk). Any QoS scheduler, including RLP/T scheduler, easily fits into the flash memory of an embedded system.
We conducted experiments to obtain a quantitative evaluation of the overhead led by the QoS schedulers. We measured the overhead for various numbers of tasks (5, 10, 15, 20,...) with all periods equal to 10 milliseconds. Periods are harmonic with a hyperperiod equal to 3360 timer ticks. The measurements were performed over a period of 1000 seconds on a computer system with a 400 MHz Pentium II processor with 384 Mo RAM. Figure 13 shows the resulting overhead.

Fig. 13. Dynamic overhead of the QoS schedulers
The average overhead led by the QoS schedulers scales with the number of installed tasks. BWP exhibits an average execution time that is substantially higher than the RTO. This comes from the management of blue instances under BWP. The curve obtained for RLP and RLP/T mainly comes from the amount of time spent on the EDL schedule (performed only when a blue instance is released or completed). As a matter of fact, we observe that overhead is closely related to efficiency. An interesting feature of the component approach lies in that the selected scheduler can be tuned to balance performance versus complexity, and thus easily conforms to implementation requirements.

Summary
While it is imperative that all time constraints -generally expressed in terms of deadlines -are met in hard real-time systems, firm real-time systems do not have as stringent timeliness requirements since they allow for some degree of miss ratio. Video reception and multimedia-oriented mobile applications are typical firm real-time applications that require the need for a suitable real-time scheduler which represents the central key service in any operating system. The proliferation of these applications has motivated many research efforts over the last twenty years in order to produce a scheduling framework that explicitly addresses their specific requirements and improves the global Quality of Service.
A firm real-time system is typically characterized by dynamic changes in workloads (tasks have variable actual execution times). It consequently needs a scheduler able to handle possible overload situations and to allow the system to achieve graceful degradation by skipping some tasks. The scheduler has to supply a dynamic mechanism that determines on-line the task to be shed from the system. Multimedia systems are typically systems in which performance is sensitive to the distribution of skips: if skips occur for several consecutive instances of the same task, then the system performance may be totally unacceptable leading to some form of instability. To overcome the shortcoming of the Quality of Service metrics only based on the average rate of dropped tasks, Koren and Shasha proposed the skip-over model in which a periodic task with a skip factor of s is allowed to have one instance skipped out of s consecutive instances (Koren & Shasha, 1995).
In this chapter, we have considered the skip-over model where independant tasks run periodically on a uni-processor architecture and can be preempted at any time. Additionally, they have a skip factor. We described two on-line scheduling algorithms respectively named RLP and RLP/T, the latter being based on an admission control mechanism. The results of an experimental study indicate that improvements with both RLP and RLP/T are quite significant compared with the two basic algorithms introduced by Koren and Shasha. We have integrated all the QoS schedulers presented in this chapter as software components which are part of the CLEOPATRE open-source library. We have performed their evaluation under a real-time Linux-based operating system, namely Linux/RTAI. The observed overheads and footprints enabled us to state their ability to be used even for embedded applications with severe memory and timeliness requirements.

QoS and energy harvesting
Many embedded systems work in insecure or remote sites (e.g. wireless intelligent sensors).
The new generation of these systems will be smaller and more energy efficient while still offering sufficient performance. A typical example is data farming where sensors are spread over an area to supervise the environment and send collected data for further processing to a base station. Sensors are deployed and then must stay operational for a long period of time, in the range of months or even years.
One way to prolong the lifetime of such autonomous systems is to harvest the required energy from the environment. Energy Harvesting is defined as the process of capturing energy from one or more natural energy sources accumulating it and storing it for later use (Priya & Inman, 2009). Energy harvesting from a natural source where a remote application is deployed and where energy is inexhaustible appears as an attractive alternative to inconvenient traditional batteries. Energy harvesting with solar panels is one of the most popular technologies. Nowadays, many real life applications using energy harvesting are operational. Wireless sensor network systems, including ZigBee systems, benefit from this technology.
A wireless sensor has timing constraints that must be satisfied and consume only as much energy as the energy harvester can collect from the environment. But the harvested energy is highly dependent on the environment and the power drained from most environmental energy sources is not constant over time. Consequently, energy consumption coming from the execution of tasks should be continuously adjusted in order to maximize the Quality of Service and not only to minimize the energy consumption. The main challenge of research is to provide an energy-aware scheduling algorithm that will schedule tasks so as to consider jointly two kinds of constraints: time (i.e. deadlines) and energy availability.
To address the above problem, we proposed in a recent paper (El Ghor et al., 2011) an efficient scheduling algorithm called EDeg which is based on both the energy stored and the energy estimated to be harvested in the future. We performed a series of experiments based on the rate of missed deadlines in order to compare EDeg with other scheduling methods. Experimental results show that EDeg significantly outperforms the classical greedy schedulers, including EDF.
We are now extending this scheduling strategy to the skip-over model. The objective is to reduce the rate of missed deadlines when the system lacks either time or energy, by taking into account skip factors. To summarize, our current work focuses on the same problem studied in this chapter but considers the specific issue of real-time energy harvesting systems.

QoS and multicore systems
While real-time applications are becoming more and more concurrent and complex, the drive toward multicore systems seems inevitable. Multicore processors solve the problem of heat that has been slowing processor growth in the past while providing increased performance. We propose in a recent paper (Abdallah et al., 2011) to tackle the problem of distributing skippable periodic tasks over such platforms. Our contribution is twofold. First, we design a schedulability test for multicore task sets under QoS constraints. Second, based on this test, we propose new partitioned scheduling heuristics to assign tasks with QoS constraints to processors so as to minimize the number of processors used. In conclusion, this new line of investigation extends the work presented in this chapter to multicore platforms.