Adaptive and dynamic behaviour is seen as one of the key characteristics of the modern real-time systems. The fixed priority preemptive scheduling is usually used in such real-time systems but it is inflexible in its purest form. Provided that in a task set deemed feasible by schedulability analysis all hard jobs must always complete within their deadlines, it is inevitable that the processor and other resources will be under-utilised at run-time. This occurs for many reasons, including jobs not taking worst case execution paths, sporadic jobs not arriving at their maximum rate and hardware speed-ups such as caching and pipelining, which could not be predicted by worst-case execution time analysis. Furthermore, generally, with modern processors it is becoming increasingly difficult to produce tight upper bounds on the worst-case execution times of real-time tasks without incorporating excessive pessimism [39].
The resources not required at run-time are usually termed as spare capac- ity [40]. Such spare resources instead could be profitably exploited by other jobs, either hard or soft. Davis has classified the spare capacity within a real-time sys- tem into the three following groups [41]:
• Extra capacity: it is the capacity which is not allocated for real-time tasks during the design phase. This can be identified off-line.
• Gain time: it is the processor time guaranteed to a task off-line but not required at run-time. It is produced when the real-time task instances execute in less than their worst-case execution time estimations. This may only be reclaimed at run-time since it depends on the actual executions of tasks [41].
• Spare time: it is the capacity produced in situations in which sporadic tasks do not arrive at their maximum rate.
Most flexible scheduling algorithms are mainly focused on reclaiming the extra capacity of the system, usually called slack time. Only a few research approaches have discussed how to reclaim gain time [40, 42, 43]. Both strategies
allow to increase the amount of jobs scheduled. However, the former approaches are performed offline while the latter check if there is spare capacity at run-time. Schedulability tests provide no indication of the extent to which the WCET estimates of tasks of feasible systems may be increased without causing dead- lines to be missed. Punnekkat et al. provided a general approach to the sensi- tivity analysis of task sets regardless of the priority assignment algorithm that is used [44]. In this domain, sensitivity analysis refers to the study of the per- missible changes of temporal task characteristics which still lead to a feasible task set. Such approach aids system developers in incorporating changes to the system while ensuring that the schedulabitity guarantees remain intact. Most of metrics consider changes in the WCETs [45].
With regard to this, it is important the definition of critical scaling factor α∗. In particular, given a task set in which it is possible to identify spare CPU capacity prior to runtime and where each task τi could be represented as below:
τi = hPi, Cii
then the critical scaling factor α∗ is the largest possible factor for each task’s worst case execution time Ciabove which some task instance will miss its deadline
at the critical instant phasing. Conversely the task set remains schedulable for all α ≤ α∗. Katcher et al. utilise the concept of scaling factor α∗ to increase the utilisation factor of each task within a task set as follow [46]:
∀τi ∈ τ. n X i=1 α∗ ·Ci Pi
However, to increase the overall system load till the maximum point at which it remains schedulable, it is possible also to consider the maximum permissible change in the WCET of just a single task or of one module contained in one or more tasks.
On the other hand, the online method reclaims the gain time collection at runtime. The gain time is defined by noting that an invocation of task τi will
produce a job jithat very likely will have an execution time et(ji) smaller than the
WCET. Therefore, the gain time refers to the difference between the execution time actually used by a job and the execution time budget that was allocated. The most important property of any scheme for exploiting the gain time is that the schedulability of hard tasks must not be affected. A number of mechanisms exist that can make this gain time available for usage by other jobs without affecting the schedulability. The gain time is defined as follows:
gi = Ci − et(ji)
where et(ji) is the execution time of job ji and Ci is the related assigned
time threshold. At runtime, it is likely that many jobs will complete in less than their optimistic execution time threshold estimates. In a fixed priority scheme such unused resource will become available to background or lower priority tasks. The gain time gi is added to the execution time budget of the next lower priority
active job, i.e., the next job in the ready queue. It is worth to note that gi can
never be negative. Passing the gain time from one job to another makes less likely that jobs requiring more execution time than expected will actually exceed their execution time budgets.