2. C'1 := C – ΓS ≤ 0;
If the server has a capacity at time t, it can be allocated to the request immediately.
3. C'2 := C'1 –
∑
d ≤dΓii ≤ 0 , where di is the deadline associated with Γi;
All capacities with deadlines not greater than d can be allocated to the request.
4. C'3 := C'2 –
∑
t<H+e<d ∆i − − ii d H e
' min( , ' )≤ 0, whereH :'=H
t/H
is the starting time of the current hyper period;The request can use all server capacity replenishments that take place during [t,d], but only during [ ,d], where is the time at which the replenishment oc-curs.
ei
H'+ H'+ei
In the actual implementation, rather than computing the sum first and then subtracting it from C, it is better to iteratively decrement C and stop as soon as the criterion is verified.
As we assume that C is small as compared to the execution times and periods of the peri-odic tasks, we suppose that one of the first criteria will yield a decision in many cases.
A practical approach to increase the probability that a request can be accepted is to give the communication tasks a higher priority than the main parts, but a lower priority than the exception parts. This means that the communication tasks can run not only under capaci-ties, but also during the times allocated for the main parts. The price to be paid for this improvement is losing the guarantee that main parts are completed as long as they do not exceed their specified resource demand. This may be acceptable for certain applications for the following reasons:
• The fact that main parts may not be completed does not raise a new systematic problem, but is already part of the underlying concept. So, the suggested approach has mainly a quantitative impact in that it reduces the probability that main parts are completed. In particular, a timely completion of the exception parts would still be guaranteed.
• The execution times of the communication tasks are small as compared to those of the application tasks. Hence, even if the same main part is preempted several times, this will not lead to a significant reduction of its allocated execution time. There-fore, the mentioned quantitative impact appears to be limited.
sensor fusion, the element filter should not start executing before the object filter has de-livered its results. The whole pipeline has a common period and deadline by which the final stage of the pipeline must have been finished and deliver its results.
One may question why not realizing all the stages in a single task, thus eliminating the dependencies from the task set. To understand why this is not appropriate for the kind of processing we consider, imagine that one of the first processing stages required signifi-cantly more execution time than was expected. It would consume the resources actually meant to execute its successor stages, and the scheduler would have no chance to prevent it from doing so. In the end, when the execution time allocated to the whole pipeline is con-sumed, processing may not have proceeded to the final stage so that no result may be available. Structuring the pipeline as a sequence of task pair’s, the expected-case execution time of the pipeline is distributed among the stages. TAFT ensures that each stage, from the first to the last, gets at least its allocated ECET. Thus, an intermediate stage requiring more than the allocated resources cannot “steal” the execution times allocated for the other stages in the pipeline.
In what follows, precedence constraints can be accommodated in TAFT-IPE. At first, we explain how precedence constraints are modeled and then show how task pairs with prece-dence constraints are scheduled.
5.5.1 Model
To model sets of task pairs with precedence constraints, we adapt a model presented in (Stankovic et al. 1998). We model the precedence constraints between instances of task pairs as an ordering relation ≺ on the set of instances, where for two task pair instances I and J, I ≺ J means that I must be finished before J is started. The conditions that a sched-ule must fulfill to be compliant with a precedence constraint are formalized in the follow-ing definition.
Definition 5-2. A schedule σ for a set I of task pair instances is compliant with the prece-dence constraint ≺ ⊆ I × I if and only if for any two instances Ji,Jj ∈ I, Ji ≺ Jj ⇒ fσ(Ji) <
sσ(Jj), where fσ(Ji) is the last point of time t at which runningσ(MPi,t) or runningσ(EPi,t), and sσ(Jj) is the first point of time t at which runningσ(MPj,t) or runningσ(EPj,t)
A pipeline Pi is modeled as a 3-tuple Pi = (Ti,≺i,Ti), where Ti is a set of periodic task pairs {τi,j = (Ti,Ci,j,Ei,j)}, ≺i a total order on Ti, and Ti the period of Pi. This means that
• At each time t = (k-1)Ti, k ≥ 1, and for each task τi,j in Ti, an instance τi,j,k is re-leased;
• The instances must be executed according to ≺'i := {(Ji,l,k,Ji,m,k) | k ≥ 1, τi,l ≺i τ i,m};
• All instances must finish by kTi.
Definition 5-3. A schedule σ for a set of n pipelines {Pi = (Ti,≺i,Ti) | i ∈ 1..n} is compliant with ≺i, i ∈ 1..n, if it is compliant with the precedence constraint
≺' := {(Ji,l,k, Ji,m,k) | i ∈ 1..n, τi,l ≺i τi,m, k ≥ 1}.
5.5.2 Extending TAFT-IPE
To ensure that TAFT-IPE produces schedules that are compliant with the precedence con-straint of a pipeline Pi, we assign priorities to the tasks of that pipeline according to the relation ≺i; that is, the highest priority is assigned to the first and the lowest priority to the last task w.r.t ≺i. These priorities are pipeline internal in that they are used only to dis-criminate between tasks belonging to the same pipeline. In TAFT-IPE, the pipeline-internal priorities impact how the highest priority entity and the task instance to run under a capacity are determined. For both, the pipeline-internal priorities of the instances are added as last criterion. As all pending task instances belonging to the same pipeline Pi
have the same deadline, this ensures that among these instances, the first instance w.r.t ≺i
takes precedence over all its successors. The schedulability for the resulting, modified TAFT-IPE is stated in the following theorem:
Theorem 5-3. For a given set {Pi = (Ti,≺i,Ti) | i ∈ 1..n} of pipelines, TAFT-IPE produces a schedule σ that is compliant with ≺i, i ∈ 1..n, and achieves timely completion of correct jobs and exception handling if
∑
= n ≤i i
i
T C
1
1, where
∑
∈
+
=
i j
j i j i
i C E
τ T , ,
C
Proof Neglecting the precedence constraints, TAFT-IPE produces a schedule that achieves timely completion of correct jobs and exception handling if the above condition holds be-cause
∑
∑ ∑
= ∈ =≤ + =
= n
i i
n i
i i
j i j i
T C T
E U C
j
i 1
1
,
, 1
i
, T
τ
.
Let σ' be this schedule. The schedule σ' can be transformed into the schedule σ produced by TAFT-IPE with precedence constraints by just exchanging the execution times of re-leased instances having the same deadline. Note furthermore, that the suggested priority assignment does not effect the ordering of the main and exception part of a single task pair.
Hence, the resulting schedule still guarantees completion of correct jobs and exception handling. It remains to show that σ is compliant with the precedence constraint. Consider two instances Ji,l,k ≺' Ji,m,k. At their release time, the main parts MPi,l,k and MPi,m,k of both instances are added to the pending queue for periodic instances. Since both have the same deadline, and MPi,l,k has the higher pipeline-internal priority, MPi,m,k is not started as long
as MPi,l,k is in the pending queue for periodic instances. If the scheduler removes MPi,l,k
from this queue, this has one of the following reasons:
1. MPi,l,k completed. In this case, the finishing time of Ji,l,k is smaller than the starting
time of Ji,m,k, and the constraint is fulfilled.
2. MPi,l,k became faulty. In this case, the exception part EPi,l,k of Ji,l,k is added to the
pending queue for periodic instances. Following the same reasoning as above,
MPi,m,k is not executed as long as EPi,l,k is pending. When EPi,l,k is removed from
the pending queue, it follows that either EPi,l,k or the faulty main part MPi,l,k com-pleted. In both cases, the finishing time of Ji,l,k is smaller than the starting time of
Ji,m,k and the constraint is fulfilled.
Actually, the algorithm can handle more general precedence relations than just total orders, but for the time being, we focus on those kinds of precedence constraints which are re-quired to model the kind of pipelined processing we have in mind. Furthermore, it is possi-ble to transform the combined deadline- and priority-based scheduling back to a pure dead-line-based scheduling (Stankovic et al. 1998).
6 Prototypes and Implementations
In this chapter, we present the prototypes of our two application scenarios. The first is a prototype of the shared spatial resource scenario and is intended to show the viability of our approach to the coordination of mobile embedded system. Furthermore, it allows gain-ing some first indications about the response times that can be achieved usgain-ing the commu-nication services of the middleware. The second is a prototype of the distributed sensor fusion scenario. As compared to the first prototype, it has the more demanding CPU load and hence was used to show the viability of our approach to the provision QoS in dynamic environments. It allows applying and evaluating TAFT in a real application, which exhibits unpredictable execution times and several kinds of application-inherent redundancy. Fi-nally, we present a modular implementation of the communication hardcore, which allows configuring protocol stacks at compile time. With this implementation, we want to show that the concept of modularity, which guided our architectural design and formal modeling, can be transformed into a modular, yet highly performant implementation.