Automatic Parameter Derivations in k2U Framework
Abstract
We have recently developed a general schedulability test framework, called , which can be applied to deal with a large variety of task models that have been widely studied in realtime embedded systems. The framework provides several means for the users to convert arbitrary schedulability tests (regardless of platforms and task models) into polynomialtime tests with closed mathematical expressions. However, the applicability (as well as the performance) of the framework relies on the users to index the tasks properly and define certain constant parameters.
This report describes how to automatically index the tasks properly and derive those parameters. We will cover several typical schedulability tests in realtime systems to explain how to systematically and automatically derive those parameters required by the framework. This automation significantly empowers the framework to handle a wide range of classes of realtime execution platforms and task models, including uniprocessor scheduling, multiprocessor scheduling, selfsuspending task systems, realtime tasks with arrival jitter, services and virtualizations with bounded delays, etc.
1 Introduction
To analyze the worstcase response time or to ensure the timeliness of the system, for each of individual task and platform models, researchers tend to develop dedicated techniques that result in schedulability tests with different time/space complexity and accuracy of the analysis. A very widely adopted case is the schedulability test of a (constraineddeadline) sporadic realtime task under fixedpriority scheduling in uniprocessor systems, in which the timedemand analysis (TDA) developed in [5] can be adopted. That is, if
(1) 
then task is schedulable under the fixedpriority scheduling algorithm, where is the set of tasks with higher priority than , , , and represent ’s relative deadline, worstcase execution time, and period, respectively. TDA requires pseudopolynomialtime complexity to check the time points that lie in for Eq. (1). The utilization of a sporadic task is defined as .
However, it is not always necessary to test all possible time points to derive a safe worstcase response time or to provide sufficient schedulability tests. The general and key concept to obtain sufficient schedulability tests in in [3] and in [2] is to test only a subset of such points for verifying the schedulability. Traditional fixedpriority schedulability tests often have pseudopolynomialtime (or even higher) complexity. The idea implemented in the and frameworks is to provide a general point schedulability test, which only needs to test points under any fixedpriority scheduling when checking schedulability of the task with the highest priority in the system. Suppose that there are higher priority tasks, indexed as , than task . The success of the framework is based on a point effective schedulability test, defined as follows:
Definition 1 (Chen et al. [3]).
A point effective schedulability test is a sufficient schedulability test of a fixedpriority scheduling policy, that verifies the existence of with such that
(2) 
where , , , and are dependent upon the setting of the task models and task .
The framework [3] assumes that the corresponding coefficients and in Definition 1 are given. How to derive them depends on the task models, the platform models, and the scheduling policies. Provided that these coefficients , , , for every higher priority task are given, the framework can find the worstcase assignments of the values for the higherpriority tasks .
Although several applications were adopted to demonstrate the power and the coverage of the framework, we were not able to provide an automatic procedure to construct the required coefficients and in Definition 1 in [3]. Instead, we stated in [3] as follows:
The choice of good parameters and affects the quality of the resulting schedulability bounds. ….. However, deriving the good settings of and is actually not the focus of this paper. The framework does not care how the parameters and are obtained. The framework simply derives the bounds according to the given parameters and , regardless of the settings of and . The correctness of the settings of and is not verified by the framework.
Contributions: This report explains how to automatically derive those parameters needed in the framework. We will cover several typical schedulability tests in realtime systems to explain how to systematically and automatically derive those parameters required by the framework. This automation significantly empowers the framework to handle a wide range of classes of realtime execution platforms and task models, including uniprocessor scheduling, multiprocessor scheduling, selfsuspending task systems, realtime tasks with arrival jitter, services and virtualizations with bounded delays, etc. More precisely, if the corresponding (exponential time or pseudopolynomialtime) schedulability test is in one of the classes provided in this report, the derivations of the hyperbolicform schedulability tests, utilizationbased analysis, etc. can be automatically constructed.
Given an arbitrary schedulability test, there are many ways to define a corresponding kpoint effective schedulability test. The constructions of the coefficients in this report may not be the best choices. All the constructions in this report follow the same design philosophy: We first identify the tasks that can release at least one more job at time in the schedulability test and define the effective test point of such a task at its last release before . There may be other more effective constructions for different schedulability tests. These opportunities are not explored in this report.
Organizations. The rest of this report is organized as follows:

The basic terminologies and models are presented in Section 2.

We will present three classes of applicable schedulability tests, which can allow automatic parameter derivations:

Constant inflation in Section 3.1: This class covers a wide range of applications in which the workload of a higherpriority task may have a constant inflation to quantify the additional workload in the analysis window.

Boundeddelayed service in Section 3.2: This class covers a wide range of applications in which the computation service provided to the task system can be lower bounded by a constant slope with a constant offset.

Arrival jitter in Section 3.3: This class covers a wide range of applications in which a higherpriority task may have arrival jitter in the analysis window.

Please note that we will not specifically explain how to use the framework in this report. Please refer to [3] for details. However, for completeness the key lemmas in [3] will be summarized in Section 2.
2 Models and Terminologies
2.1 Basic Task and Scheduling Models
This report will introduce the simplest settings by using the ordinary sporadic realtime task model, even though the frameworks target at more general task models. We define the terminologies here for completeness. A sporadic task is released repeatedly, with each such invocation called a job. The job of , denoted , is released at time and has an absolute deadline at time . Each job of any task is assumed to have as its worstcase execution time. The response time of a job is defined as its finishing time minus its release time. Associated with each task are a period , which specifies the minimum time between two consecutive job releases of , and a deadline , which specifies the relative deadline of each such job, i.e., . The worstcase response time of a task is the maximum response time among all its jobs. The utilization of a task is defined as .
A sporadic task system is said to be an implicitdeadline task system if holds for each . A sporadic task system is said to be a constraineddeadline task system if holds for each . Otherwise, such a sporadic task system is an arbitrarydeadline task system.
A task is said schedulable by a scheduling policy if all of its jobs can finish before their absolute deadlines, i.e., the worstcase response time of the task is no more than its relative deadline. A task system is said schedulable by a scheduling policy if all the tasks in the task system are schedulable. A schedulability test is to provide sufficient conditions to ensure the feasibility of the resulting schedule by a scheduling policy.
Throughout the report, we will focus on fixedpriority scheduling. That is, each task is associated with a priority level. We will only present the schedulability test of a certain task , that is under analysis. For notational brevity, in the framework presentation, we will implicitly assume that there are tasks, says with higherpriority than task . These higherpriority tasks are assumed to be schedulable before we test task . We will use to denote the set of these higher priority tasks, when their orderings do not matter. Moreover, we only consider the cases when , since is usually trivial.
Note that different task models may have different terminologies regarding to and . Here, we implicitly assume that is always . The definition of can be very dependent upon the task systems.
2.2 Properties of
By using the property defined in Definition 1, we can have the following lemmas in the framework [3]. All the proofs of the following lemmas are in [3].
Lemma 1 (Chen et al. [3]).
For a given point effective schedulability test of a scheduling algorithm, defined in Definition 1, in which and , and for any , task is schedulable by the scheduling algorithm if the following condition holds
(3) 
Lemma 2 (Chen et al. [3]).
For a given point effective schedulability test of a scheduling algorithm, defined in Definition 1, in which and and for any , task is schedulable by the scheduling algorithm if
(4) 
3 Classes of Applicable Schedulability Tests
We will present three classes of applicable schedulability tests, which can allow automatic parameter derivations:

Constant inflation: This class covers a wide range of applications in which the workload of a higherpriority task may have a constant inflation to quantify the additional workload in the analysis window.

Bounded delayed service: This class covers a wide range of applications in which the computation service provided to the task system can be lower bounded by a constant slope with a constant offset.

Arrival jitter: This class covers a wide range of applications in which a higherpriority task may have arrival jitter in the analysis window.
3.1 Constant Inflation
Suppose that the schedulability test is as follows:
(7) 
where and . We now classify the task set into two subsets:

consists of the higherpriority tasks with periods smaller than .

consists of the higherpriority tasks with periods greater than or equal to .
Therefore, we can rewrite Eq. (7) to
(8) 
where is defined as .
Theorem 1.
Proof.
Let be , where is an integer. By the definition of , we know that . We index the tasks in according to nondecreasing . We assume that there are tasks in for notational brevity.
Therefore, the lefthand side of Eq. (8) at time upper bounded by
(9) 
where the inequality comes from in our index rule, and comes from the setting that . That is, the test in Eq. (8) can be safely rewritten as
Therefore, we can conclude the compatibility of the test with the framework by setting and . Due to the fact that , we also know that and . This concludes the proof. ∎
Corollary 1.
3.1.1 Applications
This class of schedulability tests in Eq. (7) covers quite a lot of cases in both uniprocessor and multiprocessor systems.
In uniprocessor systems:

Burstyinterference [7]: This is a known case in which and is set to a constant to reflect the bursty interference for the first job in the analysis window in Eq. (7). It is shown in [7] that this can be used to model the schedulability analysis of deferrable servers and selfsuspending task systems (by setting to , where is the maximum selfsuspending time of task ).
In multiprocessor systems with processors and constrained deadline task sets:
3.2 Bounded Delay Services
We now discuss another class of schedulability tests by considering bounded services. In the class of the schedulability tests in Eq. (7), the righthand side of the inequality is always . Here, in this subsection, we will change the righthand side of Eq. (7) to , where is defined to quantify the minimum service provided by the system in any interval length (after the normalization for the schedulability test of task ). We will consider the following schedulability test for verifying the schedulability of task :
(12) 
where and are constants. We will specifically consider two types of :

Segmented service curves: An example of such a case is the time division multiple access (TDMA) arbitrary policy [9, 12] to provide fixed time slots with total amount of service in every TDMA cycle length . In this case, we consider that
(13) where and are specified as constants. Note that the setting of in Eq. (13) is an approximation of the original TDMA service curve, to be discussed later.

Bounded delay service curves: The service provided by the system is lower bounded by a constant slope when , where and are specified as constants. Specifically, in this case,
(14)
Figure 1 provides an example for the above two cases. We will discuss how these two bounds in Eq. (13) and Eq. (14) are related to TMDA and other hierarchical scheduling policies.
3.2.1 Segmented service curve: in Eq. (13)
For Eq. (12), in which is defined in Eq. (13), the schedulability test of task is as follows:
(15) 
where , , , and are constants with . The above test can be reorganized as
(16) 
The above test can be imagined as if there is a virtual higherpriority task with period and execution time . In this formulation, the virtual task does not have any inflation. If , we can further set as , and the schedulability test of task becomes
(17) 
3.2.2 Bounded delay service curve: in Eq. (14)
For Eq. (12), in which is defined in Eq. (14), the schedulability test of task is as follows:
(18) 
where , , , and are constants. This can be rewritten as
(19) 
It is also clear that for any , the above inequality never holds when . Therefore, we can change the boundary condition from to safely. That is, we have
(20) 
With the above reformulation, the test is similar to that in Eq. (7), where in Eq. (7) is defined as , and in Eq. (7) is defined as . Therefore, this case is now reduced to the same case in Eq. (7). We can directly use Theorem 1 for this class of schedulability tests.
3.2.3 Applications for TDMA
Suppose that the system provides a time division multiple access (TDMA) policy to serve an implicitdeadline sporadic task system with a TDMA cycle and a slot length . The bandwidth of the TDMA is . As shown in [11], the service provided by the TDMA policy in an interval length is at least . The service curve can still be lowerbounded by ignoring the term , which leads to , as a segmented service curve described in Eq. (13). Another way is to use a linear approximation [12], as a bounded delay service curve in Eq. (14), to quantify the lower bound on the service provided by the TDMA. It can be imagined that the service starts when with utilization . Therefore, the service provided by the TDMA in an interval length is lower bounded by .
These two different approximations and the original TDMA service curve are all presented in Figure 1. By adopting the segmented service curve, the schedulability test for task can be described by Eq. (15) with and . By the result in Sec. 3.2.1, we can directly conclude that and for under RM scheduling, and, hence, the schedulability test of task if is
(21) 
Therefore, if , we can conclude that the utilization bound is . This bound is identical to the result presented by Sha [9] when .
If , the virtual task created in Sec. 3.2.1 should be part of defined in Sec. 3.1. Therefore, the schedulability test of task if is
(22) 
If when , we can conclude that task is schedulable under RM scheduling if .
For the case with the bounded delay service curve, we can use Eq. (18) with , , , and . This results in the following schedulability test by using Corollary 1 for RM scheduling
(23) 
Therefore, if is negligible, i.e., the TDMA cycle is extremely shorter than , then, we can conclude a utilization bound of , which dominates . However, if is very close to , then the test in Eq. (21) is better.
Note that the above treatment can be easily extended to handle deferrable servers, sporadic servers, polling servers, and constraineddeadline task systems. Extending the analysis to multiprocessor systems is also possible if the schedulability test can be written as Eq. (18).
3.3 Arrival Jitter
Suppose that the schedulability test is as follows:
(24) 
where and . Note that if is an integer, then this is a special case of Eq. (7). We will first focus on the cases when is not an integer. We again classify the task set into two subsets:

consists of the higherpriority tasks with equal to .

is .
Therefore, we can rewrite Eq. (24) to
(25) 
where is defined as .
Theorem 2.
Proof.
By the definition of and , we know that is an integer with . By following the same procedure in the proof of Theorem 1, the lefthand side in Eq. (25) at time is upper bounded by whether
(26) 
where the last equality comes from the setting that .
It is not difficult to see that and are both decreasing functions with respect to if . Therefore, we know that and since is an integer. We therefore conclude the proof. ∎
The above analysis may be improved by further annotating to enforce if is very close to .
Corollary 2.
Suppose that we classify the task set into two subsets:

consists of the higherpriority tasks with less than or equal to .

is .
Then, for each task , we have and for the schedulability test in Eq. (25), where is defined as .
Proof.
This is identical to the proof of Theorem 2 by using the fact for a task in defined in this corollary. ∎
The quantification of the arrival jitter in Eq. (24) assumes an upper bounded jitter for each task . In many cases, the higherpriority tasks have independent jitter terms. Putting the arrival jitter of task to is sometimes over pessimistic. For the rest of this section, suppose that the schedulability test is as follows:
(27) 
where and for every . We again classify the task set into two subsets:

consists of the higherpriority tasks with equal to .

is .
Therefore, we can rewrite Eq. (27) to
(28) 
where is defined as