Realtime Systems

Characterization

K i z h e p p a tt V i p i n
When airbag is late!!
Failed Systems Can Bankrupt you (also kill)
 Modelling

How do we test our system before we build it?

We can’t test a aeroplane “real-time” navigation

system for first time after we build it!!
(A plane costs much more than a melon!!)

So we need models!! Models for systems, tasks

environment....
 Why do we need models?

It is a way of abstraction

We don’t want irrelevant information to clutter our analysis when we

study how to schedule applications on a processor or tasks can meet
deadlines

We are not interested in who is the manufacturer of the processor

which runs the application or the specific details of the application

A good RT model abstracts irrelevant information and helps us to

focus on the timing properties and resource requirement of the
system and allocation of tasks to these resources

Models help us to analyse, simulate and emulate the

target system and application
 Models

A model is a simplification of reality (Taub)

but remember

All models are wrong, but some are useful!! (George Box)
 Elements of Reference Model

A reference model for RTS has 3 elements

1. A resource model : Describes the system resources

available to the applications

2. A workload model : Describes the applications

supported by the system

Do you have a
3. Algorithms: How the application uses the problem?
resources at run time
Yes No

Continue as usual Continue as usual

Resource Model
 Processors (P)
The term processor in our RTS model is used not only to describe any
microprocessor

Every active resource in the system will be considered as a processor

It means the execution time of the real-time job will be a function of the
speed of the processor

Microprocessors, transmission links, disks, database servers etc. are all

considered as processors

Every job must have one or more processor in order to execute and
progress towards completion

Two processors are of same type if they are functionally identical and
can be interchangeably used (Eg: cores of a multicore processor)
 Resources ( ρ )
A job may need some resources in addition to processor in order to
make progress

But how long a job takes to complete does not depend on the speed of
the resources it use

Such passive elements are called resources (Eg: memory, sequence

numbers, mutexes etc.)

The speed of the resource can be abstracted as the speed of the

processor to simplify the model

A resource that can be shared by a finite number of x jobs is modelled as

a resource that has x units (Eg: Sequence numbers used in
communication)
 Plentiful Resources
If no job is ever prevented from execution due to the lack of a resource,
we call it plentiful resource (Eg: Memory)

Some elements can be modelled as both resource and processor

depending upon the abstraction (modelling level)

An I/O bus can be modelled as resource by taking the I/O speed into the
processor speed but it can be also modelled as a processor if we want
to study the performance of an arbitration scheme
Workload Model
 Jobs and Tasks
A job is defined as a unit of work that requires processor time and other
resources

A set of related jobs that execute to support a function of a system is

called a task

For example reading the voltage value from the ADC and converting it to
temperature data can be considered as a job. Logging the data along
with the time stamp in a database can be another job. When
temperature exceeds a threshold value, sending a signal to the alarm
system can be another job. Sending an alert message to the user when
temperature is dangerously high can be another job. All these jobs
together forms the temperature monitoring system task.
 Characterization of a Job J i
If the system executes a single task, the Ji represents the i th job it needs
to execute

Each job Ji is characterized by

→ Temporal parameters (Timing constraints)

→ Functional Parameters (Intrinsic properties)
→ Resource Parameters (Resource requirements)
→ Interconnection Parameters (Dependence on other jobs)
Temporal Parameters
 Release Time (r i)
It is the instance at which the job becomes available for execution

A job can be scheduled and executed any time at or after its release time

Eg: In the previous temperature monitoring system, if the processor

reads the temperature value every 100ms and if the first temperature
value is read at 30ms after power-up, the release time of kth temperature
reading job is 30+100*k ms.
 Deadline
The deadline of a job is the instant of time by which the execution is
required to be completed.

For out example case, temperature comparison should be completed

before next temperature reading

A job has no deadline if its deadline is infinity

The length of time from the release time of the job to the instant when it
completes is called the response time

The maximum allowable response time of a job is called its relative

deadline (Di). For our example thus 100ms is the relative deadline
 Deadline
The sum of release time and relative deadline is defined as absolute
deadline (di)
di = ri + Di
It should be thought like if release time gets delayed, relative deadline reduces if the absolute deadline is fixed

The time interval (ri,di] between the release time and absolute deadline of
the job Ji is called its feasible interval
Feasible Interval

Relative Deadline Di

Response Time

ri - ri+

Release Completion time Absolute

time r Deadline di
 Jittered and Sporadic Release Time
In many cases we do not know the actual release time, only its range [ri ,
-

r i+ ]

This range is called the jitter in ri or release-time jitter

If jitter is negligibly small, we can ignore it and say that job has a fixed
release time

The release time of jobs which are not known until the event occurs is
called sporadic release time

The model of such systems gives the probability distribution A(x) of the
release time
 Execution Time (e i)
ei is the amount of time required to complete the execution of Ji when it
executes alone and has all the resources it requires

It depends on the complexity of job and speed of processor(s)

Structure of the job such as conditional branches and architecture of the

processor such as cache and pipelines can effect execution time

The actual execution time of a job is unknown until it is completed

We can determine the maximum and minimum execution time [ei ,

- ei ]
+

In most HRT applications, execution time specifically means maximum

execution time
 Why do we go for the overkill?
Using max execution time may lead to
under utilization

But due to 2 main reasons we use it in

HRT systems

1. Many HRT systems are safety critical.

They are designed in such a way that
their execution time is kept at
minimum

2. HRT portion of the system is often

small. Timing requirement for the rest
of the system are soft
 Periodic Task Model
Deterministic workload model

Jobs are executed repeatedly in regular or

semiregular intervals

Each periodic task (Ti) is a sequence of jobs

The period pi of periodic task Ti is the

minimum length of all the time intervals
between release times of consecutive jobs
in Ti

Higher the jitter, less accurate is this model

 Periodic Task Model

1 2 3 4 5 6 7 8 9 10 11 12 13

Period = 2
 Phase(ϕ i), Hyper-period(H) and Utilization (U)
The release time ri,1 of first job Ji,1 is called the phase of task Ti

Different tasks can have different phases or they may be in phase

Hyper-period(H) is the LCM of pi for i=1,2,..n for a system executing n tasks

𝒆𝒊
The ratio ui = is called the utilization ratio of task Ti
𝒑𝒊
The total utilization U of all the tasks is the sum of utilization of individual
tasks

The relative deadline for each job is the period of the corresponding task
Di = p i ∀ i
 Periodic Task Notation
A periodic task is described by phase Фi, period pi, execution time ei, and
relative deadline Di

Usually a 4-tuple (Фi, pi, ei, Di) is used

If not given, default values for phase (Фi = 0) and or deadline (pi = Di) are
used

T1 = (1, 10, 3, 6) => Ф1 = 1, p1 = 10, e1 = 3, D1 = 6

J1,1 is released at r1,1 = 1, deadline is at d1,1 = 7
J1,2 is released at r1,2 = 11, deadline is at d1,2 = 17
T2 = (10, 3, 6) => Ф2 = 0, p2 = 10, e2 = 3, D2 = 6
T3 = (10, 3) => Ф3 = 0, p3 = 10, e3 = 3, D3 = 10
 Aperiodic and Sporadic Tasks
Tasks whose release times are not known a priori

They are usually event driven

Each aperiodic and sporadic task is a stream of aperiodic or sporadic jobs

Aperiodic task has jobs which have either soft deadlines or no deadlines

Sporadic task has jobs with hard deadlines

Interconnection Parameters
 Precedence Constraints
Jobs are said to have precedence constraint if they are constrained to
execute in some order

Ji < Jk
Represents Ji is immediate predecessor of Jk

Jobs are independent if they can be executed in any order

 Precedence Graph
A directed graph G=(J,<) representing precedence constraints

Each vertex represents a job in J

There is a directed edge from Ji to Jk when Ji is immediate predecessor of

Jk
(0,7] (2,9] (4,11] (6,13] (8,15]
Independent Jobs

(2,5] (5,8] (8,11] (11,14] (14,17]

Precedence Graph
Precedence Graph
J1

J2 J3 J4

J5 J6

J7

J8
 Data Dependency and Task Graph
Data generated by one task might be required by another

This cannot be captured by precedence graph and here we need a task

graph which is a form of extended data precedence graph

(0,5] (4,8] (5,20]

branch join
(0,6]

(2,10]

2/3 1/2
 Temporal Dependency
Temporal distance → Difference between completion time of two jobs

Jobs have temporal distance constraint if their temporal distance must

not be more than some finite value

(0,5] (4,8] (5,20]

branch join
(0,6]

Temporal-dependency edge
(2,10]

2/3 1/2
 AND/OR Precedence
AND Precedence → Constraint that a job which must wait for all its
predecessors to complete to begin execution
Represented as unfilled circles
OR Precedence → Constraint that a job can start execution before all its
predecessors complete execution
Represent as squares
(0,5] (4,8] (5,20]

branch join
(0,6]

(2,10]

2/3 1/2
 Conditional branches
Only one successor is executed
Represented by filled circle
Every branch job will have an associated join job

(0,5] (4,8] (5,20]

branch join
(0,6]

(2,10]

2/3 1/2
Functional Parameters
 Preemptivity
A job is pre-emptive if execution can be suspended at any time and can
be resumed from the point of suspension

A job may be pre-empted by other jobs

Non-pre-emptive → Must be executed from start to completion without

interruption

Pre-emption requires context switching

nonpreemptable is a constraint

Will affect the scheduling algorithm

 Criticality
Criticality of a job is a positive number that indicates how critical that job
is with respect to other jobs

Also represented with priority, weight

5-tuple function (Фi, pi, ei, Di ,wi )

Used during scheduling

Some algorithms also use weighted average response time and

weighted average tardiness also to schedule jobs
 Optional Execution
Not all part of jobs is equally important

An optional job or a portion of optional job completes late or does not

complete at all does not affect severely the system performance

May degrade system performance

During transient overload, may choose to discard optional jobs

 Laxity and Usefulness Function
Laxity type indicates whether timing constraints are soft or hard

Usually represented by a usefulness function

HRT → Better never, than late

SRT → Better late than never
Resource Parameters
 Pre-emptively of resources
Once a non-preemptive resource is allocated to a job other jobs needing
it should wait until the job completes its use
 Resource Graph
Describes configuration of resources

A vertex Ri for every processor/resource in the system

The attributes of the vertex are resource parameters (resource type,

numbers)

Edges in the graph represents relationship among the resourses