**3.2 Servers**

We consider a set of servers Σ, where each server *σ<sup>i</sup>* ∈ Σ is specified by a tuple (*i*, Π*i*, Θ*i*), where *i* is the priority (smaller *i* means higher priority), Π*<sup>i</sup>* is its replenishment period and Θ*<sup>i</sup>* is its capacity. During runtime, its available budget *β<sup>i</sup>* may vary. Every Π*<sup>i</sup>* time units *β<sup>i</sup>* is replenished to Θ*i*. When a server is running, every time unit its available budget *β<sup>i</sup>* is decremented by one.

The mapping of tasks to servers is given by *γ*(*σi*) ⊆ Γ which defines the set of tasks mapped to server *σi*. We assume that each task is mapped to exactly one server. A task *τ<sup>j</sup>* ∈ *γ*(*σi*) which is mapped to server *σ<sup>i</sup>* can execute only when *β<sup>i</sup>* > 0.

## **3.2.1 Deferrable server**

The deferrable server Strosnider et al. (1995) is bandwidth preserving. This means that when a server is switched out because none of its tasks are ready, it will preserve its budget to handle tasks which may become ready later. A deferrable server can be in one of the states shown in Figure 1. A server in the *running* state is said to be *active*, and in either *ready*, *waiting* or *depleted* state is said to be *inactive*. A change from inactive to active or vice-versa is accompanied by the server being *switched in* or *switched out*, respectively.

Fig. 1. State transition diagram for the deferrable server. The replenishment transitions from the Ready, Running and Waiting states pointing to the same state are not shown.

A server *σ<sup>i</sup>* is created in the waiting state, with *β<sup>i</sup>* = Θ*i*. When it is dispatched by the scheduler it moves to running state. A running server may become inactive for one of three reasons:


12 5 3 0 7

One of our requirements is for long event interarrival times with respect to time representation. In other words, given *d* as the largest value that can be represented for a fixed bit-length time representation, we want to be able to express events which are *kd* time

For an *n*-bit time representation, the maximum interval between two consecutive events in the queue is 2*<sup>n</sup>* <sup>−</sup> 1 time units2. Using *<sup>k</sup>* events, we can therefore represent event interarrival time of at most *<sup>k</sup>*(2*<sup>n</sup>* <sup>−</sup> <sup>1</sup>). RELTEQ improves this interval even further and allows for an *arbitrarily long interval* between *any* two events by inserting "dummy" events, as shown in Figure 3.

4 5 **Legend:**

<sup>2</sup>n+10

Fig. 3. Example of (a) an overflowing relative event time (b) RELTEQ inserting a dummy

If *t* represents the event time of the last event in the queue, then an event *ei* with a time larger than 2*<sup>n</sup>* <sup>−</sup> 1 relative to *<sup>t</sup>* can be inserted by first inserting dummy events with time 2*<sup>n</sup>* <sup>−</sup> 1 at the end of the queue until the remaining relative time of *ei* is smaller or equal to 2*<sup>n</sup>* <sup>−</sup> 1.

In general, dummy events act as placeholders in queues and can be assigned any time in the

A RELTEQ *event* is specified by the tuple (*kind*, *time*, *data*). The *kind* field identifies the event kind, e.g. a delay or the arrival of a periodic task. *time* is the event time. *data* points to additional data that may be required to handle the event and depends on the event kind. For example, a delay event will point to the task which is to be resumed after the delay event expires. Decrementing an event means decrementing its event time and incrementing an event means incrementing its event time. We will use a dot notation to represent individual fields

A RELTEQ *queue* is a list of RELTEQ events. *Head(qi)* represents the head event in queue *qi*.

<sup>2</sup> With *<sup>n</sup>* bits we can represent 2*<sup>n</sup>* distinct numbers. Since we start at 0, the largest one is 2*<sup>n</sup>* <sup>−</sup> 1.

dummy event <sup>4</sup> <sup>5</sup> <sup>2</sup>n-1 <sup>11</sup>

990 1007 1010 1010 1017

now

(a)

(b)

interval [0, 2*<sup>n</sup>* <sup>−</sup> <sup>1</sup>].

**4.2 RELTEQ data structures**

Fig. 2. Example of the RELTEQ event queue.

**Unbounded interarrival time between events**

event with time 2*<sup>n</sup>* <sup>−</sup> 1 to handle the overflow.

in the data structures, e.g. *ei*.*time* is the event time of event *ei*.

units apart, for some parameter *k* > 1.

1002 absolute time

event time

event

<sup>e</sup><sup>1</sup> <sup>e</sup><sup>2</sup> <sup>e</sup><sup>3</sup> <sup>e</sup><sup>4</sup> <sup>e</sup><sup>5</sup>

An Efficient Hierarchical Scheduling Framework for the Automotive Domain 75

When a depleted server is replenished it moves to the ready state and becomes eligible to run. A waiting server may be woken up by a newly arrived periodic task or a delay event.
