Scheduling Elastic Applications in Compositional Real-Time Systems

—Many real-time applications have functional behaviour that requires variability in timing properties at run-time. The elastic task model provides a convenient mechanism to specify and encapsulate such variability and enables the modiﬁcation of an application’s periods during run-time to keep the application schedulable. Additionally, reservation-based scheduling techniques were proposed for the same purpose of taming unpredictability of timing variations, but with a diﬀerent solution, i.e., by providing the spatial and temporal isolation for executing independent applications on the same hardware. In this paper, we combine the two approaches by proposing a two-level adaptive scheduling framework which is based on the elastic task model and the compositional framework based on the periodic resource model. The proposed framework minimises the number of requests for bandwidth adaption at the reservation (system) level and primarily enables schedulability by accounting for the application’s elasticity by adjusting the periods. The motivation for this design choice is to rather localise the eﬀect of the modiﬁcations within the application, without necessarily aﬀecting all the applications at the system level compared to the changes made at the application level. The evaluation results show that the local application changes may often be enough to solve the problem of variability, signiﬁcantly reducing the number of bandwidth adjustments, and therefore reducing the potential negative impact on all the applications of a system.


I. INTRODUCTION
Many industrial real-time systems such as robot controllers have real-time requirements that are flexible to variability in execution times of the tasks, and the frequency of the task invocations [1].For instance, Simon et al. [2] provided a feedback-based scheduling algorithm for computed torque control of an industrial arm, where the frequency of the dynamic compensation tasks, such as that of gravity and Coriolis compensation, was regularly adapted to meet both the control objectives as well as the schedulability of the system tasks.Buttazzo et al. [3] proposed the elastic task model to capture such dynamic behaviour of the tasks where the schedulability of the system is managed by adapting the frequencies of the tasks.Recently, modern system architectures based on fog and cloud computing concepts have been proposed to improve the performance of robots [4], [5].A key idea behind such architectures is to exploit the improved computation capabilities offered by the processors by executing independent applications on the same hardware, e.g., running multiple instances of the robot controller software to control different robots on the same processor.Since the execution of independent applications requires temporal and spatial isolation, the concepts of virtualization and hierarchical scheduling, based on reservations, provide the necessary infrastructure to enable such a requirement.While there exist many solutions to schedule adaptive tasks of independent applications in a hierarchical scheduling approach [6], [7], [8], [9], most of them focus on modifying the reservation parameters according to the application demands, rather than adapting the application behaviour to a fixed reservation bandwidth.A disadvantage of modifying the reservation parameters according to the application demands is that the performance of another independent application co-executing on the same processor may be unnecessarily affected.By making the applications adapt to a fixed reservation bandwidth, we can limit the impact on other applications running on the same processor.However, there may be instances where the local adaptation of the application can fail, e.g., due to insufficient bandwidth, compelling a bandwidth modification.Therefore, to meet the aforementioned requirements, we propose a two-layered adaptive approach to schedule applications specified according to the elastic task model within the compositional real-time framework based on the periodic resource model [10].Concretely, we address the following questions: Q1 Given an application with elastic tasks, what is a feasible bandwidth reservation according to the periodic resource model?Q2 Given a fixed bandwidth reservation according to the periodic resource model, how can the elastic application adapt its frequencies to remain schedulable?Q3 Given an elastic application, can a schedulable reservation be found if the application requests for a modified bandwidth reservation?
We address Q1 by assuming that an application specifies initial desired frequencies for each of its tasks and then uses those values to identify a feasible bandwidth.We address Q2 by modifying the application task frequencies whenever there is an overload or an application's task requests a different frequency such that the application satisfies the schedulability conditions under the periodic resource model.We address Q3 978-1-7281-2989-1/21/$31.00 ©2021 IEEE by checking if the system-level schedulability is satisfied for the modified bandwidth reservation.
We provide the system model and discuss the necessary background on elastic tasks and the periodic resource model in Section II, followed by the proposed solution in Section III.We present the evaluation of our approach in Section IV and the related work in Section V. Finally, Section VI concludes the paper.

II. PROPOSED SYSTEM MODEL
This section presents the system model of the two-level compositional scheduling framework for uniprocessor systems.At the application level, we consider a real-time application specified according to the elastic task model with implicit deadlines(See Section.II-A).We assume that each application provides a local scheduler, based on either fixed-priority preemptive scheduling implementing Rate Monotonic (RM) priority assignment or dynamic-priority preemptive scheduling implementing the Earliest Deadline First (EDF) policy.At the system level, we assume that the CPU resource is made available to each application according to the Periodic Resource Model (PRM) [10](See Section.II-B).

A. The Basic Elastic Task Model
Buttazzo et al. [3], [11] proposed the elastic task model for applications whose tasks can have an adaptive temporal behaviour to address overload situations as well as requests for starting new tasks or modifying the task periods.Under this model, whenever there is an overload or a task requests a new period, the utilization of the remaining tasks is adjusted to keep the overall application's utilization under an upperbound value for a given scheduling algorithm.For example, if the application tasks are scheduled according to EDF, then the application utilization bound is set to 1 and the utilization values of the individual tasks are adjusted accordingly.While the elastic task model can be applied to applications that have computation time variability as well as period variability, in this paper, we will only consider applications with period variability.
Formally, we define an elastic application as a set of elastic tasks = { , , , , }, where is the Worst-Case Execution Time (WCET) of the task .and specify the minimum and the maximum inter-arrival time between consecutive jobs of .
represents the desired period of .The elastic co-efficient represents the flexibility of to change.For instance, can be defined to be in the range [0, 1], where = 0 indicates that the = = and that this task's period cannot be modified, and = 1 indicates that the task's period can be modified to take up values upto its maximum period.We use (without any postscript) to indicate the current inter-arrival time of .An example of an elastic taskset is shown in the Table I. while the task 1 can execute at its maximum period, the task 5 can only execute at its desired period.
The utilization of a task is given by = .Further, the minimum and maximum utilization of each task is represented .If a task requests for a change in its current period, its desired utilization is updated.An elastic application is said to be schedulable if ≤ , where is the utilization upper-bound for a given scheduling algorithm.It is assumed that the deadline is elastic-implicit.i.e., the relative deadline of each job of an elastic task is equal to its current period at runtime.

Elastic Compression Algorithm:
At runtime, if a task exceeds its execution time or requests for a change in its period, the application is made schedulable by modifying the periods of the application's tasks to accommodate the new values and ensuring that the total utilization of the application's tasks is below the schedulable utilization bound.This is done according to the original task compression algorithm proposed by Buttazzo et al. [3] and is reproduced here as Algorithm 1.It takes as input the elastic application and the maximum schedulable utilization bound.It computes the minimum utilization of the taskset and compares it to the schedulable utilization bound.If the minimum utilization of the elastic application exceeds the schedulable utilization bound, it immediately exits and returns a failure.Otherwise, it iterates through each task of the application and depending on the elastic coefficients and the current period of each task, it separates the tasks into two disjoint sets and .The set contains all the tasks whose utilization values are fixed, i.e., the tasks with elastic coefficients set to 0 and tasks executing with their maximum period values.The set contains the remaining tasks whose utilization can be varied.Further, represents the sum of the utilization of the tasks in , while represents the sum of the elastic coefficients of tasks in .For each task in , its utilization value is scaled according to the ratio of the elastic coefficient and the sum of all the coefficients in (Line 21).A new task period is then assigned to the task.If the new task period exceeds the value, it is set equal to .If this happens, the task is added to the set and the process is repeated.The algorithm returns a feasible taskset if either all the tasks have reached their maximum period or if all the tasks' periods have been updated such that they are schedulable.We use this algorithm as a part of our proposed solution (Section III).return Feasible 31: end function

B. Periodic Resource Model
Lee et al. [10] proposed the compositional scheduling framework based on the periodic resource model to support the development of component-based hierarchical software systems.In this framework, the computational resource is described as a periodic resource model Γ(Θ, Π), where Θ is the periodic resource allocation time and Π is the resource period.Essentially, the periodic resource Γ provides an application with Θ time units of CPU time every Π time units.The worst case resource supply of the periodic resource model is shown in Fig. 1.The utilization of the resource supply is defined as Γ = Θ Π .Generating the Resource Supply Parameters: we use the method described in Section.6 of [10] to generate the resource supply parameters Θ and Π, such that an application , modeled as a set of periodic tasks with implicit deadlines, where each task modeled as = { , } is schedulable (under EDF or RM scheduling policy).According to the compositional framework, Given the smallest period of the application, , the application is schedulable under RM scheduling policy if the resource supply utilization satisfies Eq. (1) (Eq.23 in [10]). where, Similarly, the application is schedulable under EDF scheduling policy if the resource supply utilization satisfies Eq. (3) (Eq.21 in [10]). where, Schedulable Utilization Bounds: Since the main goal of the our solution is to minimize the modifications of the resource supply parameters once they have been defined, we rely on the schedulable utilization bounds defined in the Section 5 of [10] to keep the application schedulable by changing the application utilization rather than changing the resource supply utilization.Accordingly, an application is schedulable under RM policy, if the application utilization is less than or equal to the utilization bound ( , ) as defined in Eq. (5) (Eq.16 in [10]).
( , Similarly, an application is schedulable under EDF policy, if the application utilization is less than or equal to the utilization bound ( ) as defined in Eq. ( 6)(Eq.13 in [10]). where To schedule an elastic application in a hierarchical scheduling framework based on the periodic resource model, we propose a two-layered adaptive scheduling mechanism that first attempts to adapt the utilization of the tasks at the application level and if this adaptation fails, it attempts to reallocate available spare resource capacity at the system level.The different components of the proposed framework along with the data flow between them are shown in Fig. 2. At the application level, it consists of an independent application defined according to the elastic task model, an elastic manager that implements the task compression algorithm of Buttazzo et al. [3].and a local scheduler implementing either the RM scheduling policy or the EDF scheduling policy.At the system level, the Global Compositional Scheduling Resource (GCSR) manager provides the necessary interface for communicating with the different applications and the functional support for serving requests of new bandwidth resource allocations from the individual applications.The functional behaviour of the GCSR manager is supported by the OS or the hypervisor kernel.At the application level, whenever there is an overload situation or an elastic task requests for a new period, the elastic manager will try to modify and update the periods of the rest of the tasks to keep the application schedulable using the Algorithm 1.If the resource supply is insufficient for the current demand, the elastic manager generates a new sufficient resource supply interface and requests the GCSR manager for updating the resource supply parameters.The GCSR manager will accept the request and responds successfully(i.e., assign new resource supply parameters) if the global system schedulability is preserved with the updated parameters.The elastic manager will then re-adjust the periods based on the updated resource supply parameters.

A. Initial Desired Resource Supply
In the proposed framework, we first find the suitable resource supply Γ(Θ, Π) for the application considering the parameters ( , ).We choose as , the desired periods for each task.For example, in Table I, The values under the column represent the initial desired periods of the application tasks.We assume that such a taskset is feasible.Next, depending on the scheduling algorithm, we find the resource supply utilization bound necessary to keep the application tasks schedulable according to Eq. ( 1) and Eq.(3).While there exist fully polynomial time solutions to find approximate bandwidth allocations for the periodic resource model, e.g., [12], we use the approach proposed by Lee et al. [10] in this paper.We assume that Γ(Θ, Π) is schedulable at the system level.Note that if Γ(Θ, Π) is not schedulable at the system level, then the application will have to modify its initial desired periods or the resource supply of the other corunning applications will have to be modified.In our approach, we reject an application if the initial resource supply is not schedulable.

B. Runtime Adaptation
Under worst-case conditions, the resource supply provided according to PRM can result in a no supply interval of duration 2(Π − Θ) (see Fig. 1).Therefore, once the application is executing, whenever a task requests for a new period , we need to consider two different scenarios depending on the value of .If is greater than the no supply duration, we can adapt the tasks utilization at the application level without changing the resource supply parameters.If is less than or equal to the no supply duration, we need to adapt the resource supply at the system level.
a) Application level Adaptation: From Eq. ( 5) and Eq. ( 6), it is easy to see that the utilization bound to keep the application tasks schedulable remains constant as long as remains unchanged.When the requested period is greater than or equal to , it implies that the resource supply parameters do not have to be changed since the current remains unchanged.As a consequence, and based on the sustainability property of the utilization tests [13], the elastic manager can find a schedulable period reassignment by ensuring that the modified application utilization remains below the schedulable utilization bound as shown in Eq. (7) or Eq.(8).Note that the periodic supply resource utilization Γ remains constant under application level adaptation.b) System Level Adaptation : At runtime, if a task requests for a new period that is less than , then it is not guaranteed that the existing resource supply Γ can provide sufficient CPU time for the application tasks to remain schedulable.This is because the schedulable utilization bound (for both EDF and RM scheduling policy) is a function of the minimum period of the taskset and since we are now reducing the minimum period, it may so happen that the will have its arrival and deadline in the no supply interval of duration 2(Π − Θ) in the worst case (see Fig. 1).Therefore, whenever a task makes a request of less than , the elastic manager will generate new resource supply parameters and request the GCSR manager to update the resource supply according to the new parameters so that the application remains schedulable.If the GCSR manager rejects the request, then the elastic manager will not be able to satisfy the application request and it is then up to the application to decide how it needs to proceed.If the resource supply parameters are updated, the next request for a period change will be handled based on the updated resource supply parameters.While it is possible to apply the elastic task compression algorithm at the system level to modify the resource supply utilization to accommodate the requests from the different applications, it requires modifications of the resource supply of the co-running applications which in turn can trigger application level modifications.To avoid this, we require some spare capacity to be made available at the system level so that it can be distributed among the different applications whenever required.Although we do not propose any particular method in this paper for the distribution of the spare capacity, the methods in [14], [15] are particularly well suited for the spare capacity distribution.c) PRM Elastic Scheduler: We now discuss how the elastic manager and the GCSR manager work together to adapt the application as well as system resources to maintain schedulability.The pseudo-code is presented in Algorithm 2. The functional behaviour is split between the elastic manager and the GCSR manager.The Elastic manager takes as input the request for and if is greater than or equal to the of the application, it uses the elastic compression algorithm to find a feasible period reassignment.Before it calls the task compression algorithm, it modifies the period parameter of the task from to .The task compression algorithm then takes as input the updated taskset parameters and the current resource supply utilization Γ to adapt the periods of the tasks to keep the application schedulable.If is less than of the application, it sets the value equal to .It then generates the new resource supply parameters via the GET_RESOURCE_INTERFACE function.This function takes as input the updated taskset parameters and the value satisfying Eq. ( 2) or Eq. ( 4).It then finds the resource supply utilization bound according to Eq. ( 5) or Eq. ( 6).It uses this value to find a solution according to the approach given in [10].The Elastic manager requests the GCSR manager to modify its resource supply parameters via the REQUEST_RESOURCE_UPDATE function.The GCSR manager tries to allocate resources from the spare capacity while maintaining system schedulability.It returns success if the requested resource supply parameters can be accommodated or returns failure along with the maximum resource supply utilization that it can provide.In case of failure, it is up to the application to decide on how to handle this failure.

IV. EVALUATION
We evaluate the performance of the proposed framework in the context of EDF scheduling.To demonstrate the advantages of the proposed method, we generated 900 random tasksets with each taskset consisting of 10, 20 or 30 tasks.For each taskset, we set the initial desired utilization equal to 0.25, 0.5, and 0.75.The utilization for each task was then was derived using the algorithm proposed by Griffin et al. [16].The initial desired periods were chosen at random from a normal distribution in the range [10,100].The WCET values were set as = * .The minimum and maximum periods for each of the tasks were assigned as a function of the initial desired period, i.e., to fix the minimum period, we subtracted a random percentage in the range  from the desired period.Similarly, for the maximum period, we added a random percentage in the range  to the desired period.We assigned random integer values from a normal distribution n the range [0-10] as the elastic coefficients of the tasks.For each taskset, we then derived a periodic resource interface for the initial desired periods according to the algorithm in [10].
We set up the experiments according to the different configurations of the number of tasks and the total desired utilization , i.e., each configuration was defined as a pair(N,U).For each configuration, 100 random tasksets were generated.For each configuration and a random taskset, we requested a change in the desired period 100 times.For each new period request, we assigned the new period values chosen from a uniform distribution within their defined period ranges.For each configuration, we counted the number of times the elastic manager was able to modify the utilization such that the application remains schedulable.If the elastic manager failed to find a feasible solution, it would adapt the interface Algorithm 2 PRM Elastic Scheduler Γ ← FIND_UTILIZATION_BOUND( ) Γ(Θ , Π ) ← FIND_SOLUTION( , , Γ ) ← REQUEST_RESOURCE_UPDATE(Γ(Θ , Π )) ← TASK_COMPRESS( , Γ ) end if

29:
end if 30: return 31: end function bandwidth 1 .The task requesting for a new period was chosen at random for each of the new period request.Fig. 3 shows the distribution of requests between the elastic manager and the GCSR manager for 300 different configurations with N equal to 10 and the total utilization set to 0.25, 0.5, and 0.75.We can observe that the elastic manager was able to successfully handle a significantly large percentage of the new period requests locally.For lower utilization values, the percentage of requests handled locally was less than the percentage for the higher utilization.Fig. 4 shows the distribution of the requests between the elastic manager and the GCSR manager for 300 configurations with equal to 20 and the total utilization set to 0.25, 0.5, and 0.75.Similar to the previous observations, the elastic manager was able to successfully handle a large percentage of the requests locally, while for lower utilization values, the percentage was less than the percentage for higher utilization.For the remaining 300 configurations, we set equal to 30 and the total utilization was set to 0.25, 0.5, and 0.75.In this case, the elastic manager was able to successfully handle a higher percentage of requests at lower utilization values when compared to higher utilization tasksets.This is shown in Fig. 5. Here, even when compared to the lower number of tasks with the same total utilization, there are more requests for system-level bandwidth adaptation.
In another experiment, we modified the range of the minimum and maximum periods of the taskset from the initial [10,50] percent values to [10,100] percent.When the difference between the initial desired period and the minimum and maximum periods is increased, fewer requests were handled at the application level compared to the system level.As shown in Fig. 6, for the configuration of 10 tasks and utilization set to 0.25, more than 70% of the requests are for bandwidth adaptation when the difference between the minimum and maximum periods was changed to [10,100] percent from  percent.Another significant observation is that for certain configurations and tasksets, all of the 100 new period requests could either be handled locally by the elastic manager or handled only at the system level by the GCSR manager.This can be observed in Fig. 7.This indicates that the approach based on setting the initial resource supply according to the initial desired periods can have a considerable impact on the number of requests that need bandwidth adaptations.

V. RELATED WORK
The concept of elastic tasks was introduced by Buttazzo et al. [3] to model applications whose computational demands can occasionally exceed the available capacity by allowing the application to modify the demand by changing the frequency of its jobs through an elastic coefficient.This was extended to address resource sharing within the elastic task model in [11].Chantem et al. [17], [18] reformulated the problem as a quadratic optimization problem and showed that the original elastic tasks compression algorithm was indeed a solution to solving a quadratic problem.Tian et al. [19] extended the modified problem to include a "Quality-of-Control" metric as a part of the objective function of the quadratic optimization problem.More recently, Orr et al. [20], [21] provided algorithms to schedule sequential elastic tasks on multiprocessor systems and further extended the concept of the elastic task to federated DAG-based parallel task systems in [22], [23].Beccari et al. [24], [25] provided alternative algorithms to schedule similar applications by expressing the task period ranges in a linear programming formulation.
Hierarchical scheduling of applications was encapsulated in compositional real-time scheduling framework by Lee et al. [10].In this framework, the computational demand of an application was abstracted with a single demand interface as a pair of capacity and period and the resource supply server was abstracted as a periodic resource model where each server was guaranteed a reserved capacity Θ every Π time units.Easwaran et al. [26] extended the periodic resource model to include the deadline parameter, where each server was guaranteed a reserved capacity Θ within time units, in every time interval Π. Dewan et al. [27], [12] provided algorithms to find an approximate allocation of bandwidth for a set of periodic and sporadic tasks under the periodic resource  model.Khalilzad et al. [6] proposed an adaptive hierarchical scheduling model to accommodate the adaptive behaviour of the periodic and sporadic tasks by changing the bandwidth allocation.In contrast, this paper assumes that a bandwidth allocated for a server under the periodic resource model remains constant and that the workload within the server can be adapted according to the elastic task model.However, if the elastic assignment fails, a request for a new bandwidth allocation will be made.We note that the proposed solution does not take into account possible bandwidth reclamation or mixed-criticality-based approaches to assign new bandwidths if no schedulable allocation can be made.Instead, we leave it to the individual application to handle such failures.

VI. CONCLUSION
Many real-time applications designed to accommodate their behaviour at run-time depend upon user configuration or the physical environment in which they operate.Further, for open real-time systems, the applications can be developed independently and can be run on the same hardware.To accommodate such adaptive behaviour and minimize the impact of an individual application's variability in its timing and resource demands, we proposed a two-level scheduling framework based on the periodic resource model and the elastic task model.We provided a mechanism based on the utilization tests to enable the execution of the elastic applications in a compositional real-time system.Further, by combining the application-level adaptation along with the system-level bandwidth modifications, we have shown that a large percentage of task modifications can be handled by the framework at the application level.If the local adaptation fails, the system-level reallocation provides an additional mechanism to support the scheduling of elastic applications.However, for some cases, if both the levels fail to find a schedulable modification, it is up to the application to handle such failures.Overall, our combined approach improves the number of applicationlevel variations that can be handled without affecting the property of independence of other co-running applications of the same processor.In future work, we intend to investigate techniques related to mixed-criticality and compositional realtime systems to reallocate resources at the system level.

VII. ACKNOWLEDGEMENT
The research leading to these results has received funding from the European Union's Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No. 764785, FORA-Fog Computing for Robotics and Industrial Automation, and by the Swedish Knowledge Foundation (KKS) under the FIESTA project.

Fig. 1 .
Fig. 1.Resource supply of a Periodic Resource Model.

Fig. 2 .
Fig. 2. Data Flow Between The Adaptive Scheduling Framework Components.

Fig. 6 .
Fig. 6.Percentage of requests handled by Elastic and GCSR manager for different intervals between the minimum and the maximum periods.