Real-Time Systems v3.pptx

Real-Time Systems
Predictability and Scheduling
Luís Miguel Pinho

Real-Time Systems
March 2013
Real-Time Systems - Predictability and Scheduling 2
 Used to refer to systems where the timing requirements
of the applications are as important (or more) as other
functional requirements
 The system is said to be correct, if it provides the correct
functional result, at the correct time instant
 Examples:
 Airplane control systems
 Medical equipment
 Automotive software
 Industrial control
 Telecommunications (routers, …)
 Consumer electronics (mobile phones, set-top-boxes, …)
 Usually embedded, and often critical
 Interacts with its environment
 Highly critical when human lifes at stake

Real-Time Systems
March 2013
 In order to provide a correct (time and value) result,
the system needs to:
 Provide a functional correct algorithm
 Control resource consumption of the different applications
 Isolate critical and non-critical activities
 Guarantee timing requirements of applications
 Using specific CPU scheduling techniques
 That is what we will talk about

Real-Time Scheduling
March 2013
 The scheduling techniques for real-time systems
range
I. Static approaches where the schedule is built a priori
II. Hybrid approaches where all characteristics where
known a priori but te schedule is created in run-time
III. Fully dynamic approaches, which only provide best
effort guarantees
IV. Complex approaches, integrating some of the above
 But where the critical applications are scheduled with static
approaches
 And isolation is guaranteed
 We will briefly refer to (1) and (III) and mainly talk of
(II)

March 2013
 In general, a scheduling scheme provides two
features:
 An algorithm for ordering the use of system resources (in
particular the CPUs)
 A means of predicting the worst-case behavior of the
system when the scheduling algorithm is applied
 The prediction can then be used to confirm the temporal
requirements of the application
 In Real-Time Systems it is important to derive the
worst-case conditions
 To validate if, in the worst-case, the system will fail a
deadline

March 2013
 One of the most important concepts is that of the
Deadline (D)
 It is the time instant where the result should be delivered
 Lack of delivery has different meanings depending of the
criticality of the activity
Value
Time
D
Time
D
Time
D
Hard Real-Time
-The Value is infinetively
negative after the
deadline
- Critical to the system
correct behavior
Value Value
Firm Real-Time
-The Value is zero after
the deadline
- Not critical to the
system correct behavior
Soft Real-Time
-The Value decreases
after the deadline
- Not critical to the
system correct behavior

March 2013
 A simple model
 The application is assumed to consist of a fixed set of activities
(named tasks)
 All activities are periodic, with known periods
 Each period there is a new job of the task
 The activities are completely independent of each other
 All system's overheads, context-switching times and so on are
ignored (i.e, assumed to have zero cost)
 All activities have a deadline equal to their period (that is, each
one must complete before it is next released)
 All activities have a fixed worst-case execution time
 Very restrictive model
 More accurate models exist but not in the context of this course

March 2013
 On the a priori assumptions
 Context switches and overheads are usually incorporated
in the exectution time of tasks
 Caches, pipelines are usually ignored
 In Critical systems they are switched off
 In other systems, measurable “worst-case” values are used
 Worst-case execution time of tasks
 In critical systems it is calculated by inspecting object code
 Loops and conditions are always with their worst-case
 In other systems measurable “worst-case” values are used
 In soft real-time, average values may be used
 Task periods
 Tasks may be not periodic in nature: in this case (sporadic or
aperiodic), the worst-cast inter-arrival time is used

March 2013
 An example
 An airplane control system has the following tasks:
 A periodic task responsible for controling the pitch, roll and yaw
of the airplane, which has to execute every 60 ms. It takes 20
ms to execute and must output the results in 40 ms
 A sporadic alarm task, that when occurring must be handled in
20 ms, taking 5 ms to execute.
 A periodic logger task, which writes the log of events to the
black-box, with a period of 100 ms and an execution time of 50
ms
C (ms) T (ms) D (ms)
Control 20 60 40
Alarm 5 - 20
Logger 50 100 -

March 2013
 A simple model of a periodic task (ti)
Time
Di: Deadline
Ti: Period (or
minimum inter-arrival
time)
Ri: Response
Time
Ci: Worst-Case
Execution Time
Execution end
Job
i,k
Job i,k+1
Activitation
Instant

March 2013
 When several tasks share the CPU
Time
Wait
Pre-empted Pre-empted
R3: Response
Time
R1: Response
Time
R2: Response
Time
Interference from
higher-priority
Ready but not
executing
Executing
Increasing
priority
(importance)
 
k
i
L
k
i r
R ,
...
1
max



March 2013
 When several tasks share the CPU
Time
Deadline miss!
R3 > D3
Ready but not
executing
Executing
R3: Response
Time
D3
Increasing
priority
(importance)

March 2013
 Cyclic Executive
 In the simplest solution, a hard real-time systems can be
implemented with a cyclic executive
 Tasks are designed as a set of functions
 Functions are mapped onto a set of minor cycles that constitute the complete
schedule (or major cycle)
 The difficulty of incorporating tasks with long periods; the major
cycle time is the maximum period that can be accommodated
without secondary schedules
 Non-periodic tasks are difficult to incorporate
 The cyclic executive is difficult to construct and difficult to maintain
 it is a NP-hard problem
 Any “task” with a sizable computation time will need to be split into
a fixed number of fixed sized functions
 this may cut across the structure of the code from a software engineering
perspective, and hence may be error-prone

March 2013
 Manually constructed Time Frame or Schedule
 Completely deterministic execution
 Schedule repeatedly executed every X * T ms
major
cycle
X
frames
minor
cycle
T ms
T ms

March 2013
Time
Task 2 (C = 2 , T = 8)
Task 1 (C = 1 , T = 4) What are the minor and major cycle?
Task 3 ( C = 3 , T =
12)
- Minor cycle time is the HCF [highest common factor] of periods
- Major cycle time is the LCM [least common multiple] of periods
4
0 8 12 16
In this case, periods are 4,8,12 => HCF = 4; LCM = 24
20 24
CPU utilization is: %
75
12
3
8
2
4
1





 
i
i
i
T
C
U

March 2013
 More flexible schemes
 These are based in determining tasks’ characteristics
offline (pre-run-time) but allowing the actual execution of
tasks to be determined online (during execution)
 There are pre-emptive and non-pre-emptive versions of
these
 In a preemptive scheme, if necessary there will be an immediate
switch to the new task
 With non-preemption, the currently executing task will be
allowed to complete before the other executes
 Most important
 Hybrid schemes: Fixed-Priority Scheduling
 Dynamic schemes: Earliest-Deadline First

March 2013
 Fixed-Priority Scheduling (FPS)
 This is the most widely used approach and is the main focus of
this class
 Each task has a fixed priority which is determined offline (pre-
run-time)
 The tasks are executed in the order determined by their priority
(subject to periods)
 In real-time systems, the “priority” of a task is derived from its
temporal requirements, not its importance to the correct
functioning or integrity of the system
 Two basic approaches exist (proven to be optimal) to assign
priorities:
 Rate Monotonic (RM): the smallest the period, the highest the priority
 Deadline Monotonic (DM): the smallest the (relative) deadline, the
highest the priority
 When deadlines equal periods, both are the same

March 2013
 Earliest Deadline First (EDF)
 The runnable tasks are executed in the order determined
by their absolute deadlines
 The next task to run is always the one with the shortest
(nearest) deadline
 Although it is usual to know the relative deadlines of each
process (e.g. 25ms after release), the absolute deadlines
are computed at run time and hence the scheme is
described as dynamic
 It allows better utilization in the system, although in
overloads there is an unpredictably issue
 No way to know which task gets a deadline miss – in FPS is
always the lowest priority one

March 2013
Time
Absolute
Deadline
Relative Deadline
0 …
D = 10
D = 5

March 2013
 FPS Example
C (ms) T (ms) D (ms)
Control 20 60 40
Alarm 5 70 20
Logger 50 100 100
Priority
3
2
1
Priority
2
3
1
Rate
Monotonic
Deadline
Monotonic
Deadline Monotonic is optimal if Deadlines are different from Periods
They are only different on assigning priorities – during execution the rule
is always the same

March 2013
 FPS Example
C (ms) T (ms) D (ms) Priority Arrival
instant
Control 20 60 40 2 0
Alarm 5 70 20 3 15
Logger 50 100 100 1 5
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 05 10 …

March 2013
 FPS Example
instant
Control 20 60 40 2 0
Alarm 5 70 20 3 0
Logger 50 100 100 1 0
When there are no blocking factors (resource sharing or non-pre-
emption), the worst-case behaviour is when all arrive at zero (critical
instant)
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 05 10 …

March 2013
 FPS Example
instant
Control 20 60 40 2 0
Alarm 5 70 20 3 0
Logger 50 100 100 1 0
If it was non-pre-emptive
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 05 10 …

March 2013
 EDF Example
instant
Control 20 60 40 - 0
Alarm 5 70 20 - 25
Logger 50 100 100 - 5
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 05 10 …

March 2013
 EDF Example
instant
Control 20 60 40 - 0
Alarm 5 65 20 - 25
Logger 50 100 100 - 5
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 05 10 …

March 2013
 Analysing schedulability
 Whatever the scheuling algorithm used, it is necessary to
verify if the system is schedulable, that is, all tasks will
meet their deadlines
 Basically, i  Ri  Di
 There are mainly two types of tests to determine
schedulability
 Based on the utilization of the processor
 Based on calculating all response times

March 2013
 Utilization based tests
 In the simpler cases
 Pre-emptive systems
 When Deadlines equal Periods
 The utilization of the system is the sum of each task
utilization
 If U > 1  The system is never schedulable, since CPU utilization is
higher than 100%
 


i
i
i
T
C
U
U

March 2013
 For pre-emptive FPS (D=T)
higher than 100%
 If  The system is schedulable
 Between these values no conclusion can be made
 This is a necessary, but not sufficient test
 
1
2 /
1

 n
n
U

March 2013

1/3
1
:
3(2 1) 78%
84%>78%
n
i
i i
Teste Baseado naUtilização
C
U
T

 
 

March 2013
3
2
1
R1=
3
R2=13
C (ms) T=D(ms) U(Ci/Ti)
1
2 10 0,20
2
9 15 0,60
3
1 25 0,04
U ( Ci / Ti )= 84%
R3=14

March 2013
higher than 100%
 If  The system is schedulable
 Between these values no conclusion can be made
 This is a necessary, but not sufficient test
 For pre-emptive EDF (D=T)
higher than 100%
 If U  1  The system is always schedulable
 
1
2 /
1

 n
n
U

March 2013
 Response-time analysis
 Simple utilization based tests are only applicable to a
simple model (pre-emptive, D=T)
 These tests are also pessimistic
 There are systems that fail in the test but that nevertheless are
schedulable
 The optimal necessary and sufficient test is to derive all
tasks’ response times and compare to the deadline
i  Ri  Di

March 2013
 To derive the response times it is necessary to determine
the critical instant
 We have seen that in a non-blocking pre-emptive system this is
all tasks released at t=0
 In the other cases, the critical instant is different per task
 E.g. for non-preemptive fixed priority it is the instant where just
before the task (and all others of higher priority) being released, the
maximum blocking task in the system gets the CPU
Higher priority but needs to wait
-First for the blocking task
-Then for the other higher priority tasks

March 2013
 Example
 For task t1
t2 just released

March 2013
 Example
 For task t2
t3 just released
and
t1 simultaneously

March 2013
 The time graph can be used to calculate response-times
 However, it can be very complex and error-prone
 There are methods to do that
 For all scheduling methods
 We will only cover for fixed-priority systems
 Basically, we have to iteratively determine how many
higher priority tasks occur while the task we are
calculating executes

- Basically, there are 2 executions of t1 and 1 execution of t2 during the
execution of t3
March 2013
There are 2 jobs of task 1
while task 3 is executing
There is 1 job of task 2
while task 3 is executing
Task 3 executes during C3






1
3
T
R






2
3
T
R
- Interference of t1 is 1
*
1
3
C
T
R






Interference of t2 is 2
2
3
*C
T
R






2
2
3
1
1
3
3
3 *
* C
T
R
C
T
R
C
R 














+ + C3

March 2013
2
2
3
1
1
3
3
3 *
* C
T
R
C
T
R
C
R 















 









)
(
*
i
hp
j
j
j
i
i
i C
T
R
C
R
hp(i) is the set of tasks with higher priority than
task i

The same term (Ri) is
on both sides of the
equation
We have to solve it with
recurrence (iterative
process)

March 2013














)
(
1
0
*
i
hp
j
j
j
n
i
n
i
i
C
T
R
C
R
C
R
i
i
The first iteration is
response time equals
execution time
Then the equation is
iteratively applied
It stops when it
converges
or when response
times are greater than
deadlines
n
n
i
i
R
R 
1
i
i
D
Rn

1

41
 Example
C (ms) T=D (ms)
1
1 6
2
12 130
3
5 140
Time interval to
analyse
t3
t2
t1
0 5 10 15 20
1
3
1
3
0
6
5
5
3
3
C
C
R
C
R











Add one job of t1
March 2013
Real-Time Systems - Predictability and Scheduling

18
12
1
1
1
5
130
5
6
5
5
2
1
3
1
3
0
3
3

























C
C
C
R
C
R
42
 Example
C (ms) T=D (ms)
1
1 6
2
12 130
3
5 140
t3
t2
t1
0 5 10 15 20
Add one job of t2
March 2013

t3
t2
t1
 Example
43
0 5 10 15 20
20
12
1
1
3
5
130
18
6
18
18
2
1
3
2
1
3
3
























C
C
C
R
R
C (ms) T=D (ms)
1
1 6
2
12 130
3
5 140
43
March 2013

21
12
1
1
4
5
130
20
6
20
20
2
1
3
3
2
3
3
























C
C
C
R
R
t3
t2
t1
 Example
44
0 5 10 15 20
C (ms) T=D (ms)
1
1 6
2
12 130
3
5 140
44
March 2013

t3
t2
t1
 Example
45
0 5 10 15 20
C (ms) T=D (ms)
1
1 6
2
12 130
3
5 140
21
12
1
1
4
5
130
21
6
21
21
2
1
3
4
3
3
3
























C
C
C
R
R
45
March 2013

t3
t2
t1
 Example
46
0 5 10 15 20
C (ms) T=D (ms)
1
1 6
2
12 130
3
5 140
21
12
1
1
4
5
130
21
6
21
21
2
1
3
4
3
3
3
























C
C
C
R
R
Converged:
R3 = 21 ms
46
March 2013

March 2013
 Example
21
12
1
1
4
5
130
21
6
21
21
12
1
1
4
5
130
20
6
20
20
12
1
1
3
5
130
18
6
18
18
12
1
1
1
5
130
5
6
5
5
2
1
3
4
2
1
3
3
2
1
3
2
2
1
3
1
3
0
3
3
3
3
3
































































































C
C
C
R
C
C
C
R
C
C
C
R
C
C
C
R
C
R

March 2013
 Response-time analysis for non-preemptive
 In this case, higher-priority tasks only interfere if they
arrive before a task ti starts
 Iteration in the equation is only with Interference
 However we need to add blocking (Bi) of a lower priority
task
 A task ti will, in the worst-case, need to wait for the “biggest” of
the lower-priority tasks:
 Response-time:
i
i
i
i
hp
j
j
j
n
i
n
i
C
I
R
C
T
I
B
I i











 


)
(
1
*
)
(
max
)
(
j
i
lp
j
i C
B


i
i B
I 
0

 What about resource sharing?
 Let’s revisit the model
 Set of n dependent tasks (1, 2, 3, …n).
 Most systems, tasks share resources apart the
processor
 Memory areas
 Network
 …
 Synchnronisation mechanisms such as locks are
used to manage shared resources
49
March 2013

C
(ms)
T=D
(ms)
Priority Arrival
instant (ms)
Execution
sequence
1 5 17 3 1 EEVVV
2 5 15 2 5 EEEEQQ
3 7 35 1 0 VVVEQQE
E E
0 5 10 15 20
V V
3
2
1
Request lock
V
Release
V V
V
 Example
E E E
E
Request lock
Q Q
E Q Q E
Release
50
Request lock
March 2013

 Priority Inversion
51
March 2013
C
(ms)
T=D
(ms)
Priority Arrival
instant (ms)
Execution
sequence
1 5 17 3 3 EEVVV
2 5 15 2 2 EEEEQQ
3 7 35 1 0 VVVEQQE
3
2
1
E E
E
V V
Request lock
E E E
E
Request lock
Q Q Release
V
Release
V V
V
E Q Q E
Priority Inversion
A higher priority task (1) waits for a lower priority task (3) while
middle periodic tasks are allowed to execute.

 Priority Inversion
 If no rule is applied in sharing resources, it is not possible
to determine maximum blocking time
E E
E
E E E
E
0 5 10 15 20
V V
3
2
1
V
V V
V
Q Q
Priority Inversion
4
E E E E E E E E E E
E
25
52
March 2013

 Avoiding priority inversion
 To solve this problem (priority inversion with
undetermined duration) several protocols are used to
manage shared resources
 Most important ones
 PIP - Priority Inheritance Protocol
 Allows several blocking periods but guarantees maximum blocking
period
 PCP - Priority Ceiling Protocol
 Allows only one blocking period but introduces unnecessary blocking
 IPCP - Immediate Priority Ceiling Protocol
 Also known as PCE - Priority Ceiling Emulation
 Same as before, but simpler to implement
 Also prevents deadlocks
 We will focus on the first and last ones
53
March 2013

 Piorirty Inheritance Protocol
 When a higher pririty task is blocked in a shared resource, the
lower priotity task executing in the resource “inherits” the higher
priority while executing there
E E
E
0 5 10 15 20
V V
3
2
1
V
Tempo (ms)
3 inherits 1 priority
54
March 2013

 Piorirty Inheritance Protocol
 When a higher pririty task is blocked in a shared resource, the
lower priotity task executing in the resource “inherits” the higher
priority while executing there
E E
E
0 5 10 15 20
V V
3
2
1
V
Tempo (ms)
3 inherits 1 priority
55
March 2013
E E E
E
V V
V
Q Q
E Q Q E
2 no longer blocks 1

0 5 10 15 20
V V V
Tempo (ms)
3 executs with resource V
ceiling priority
3
2
1
56
March 2013
 Immediate Priority Ceiling Protocol
 Resources are given a priority which is equal to the highest
priority of the tasks that can use the resource (ceiling) – this is
determined before execution
 When executing in the resource tasks execute with the priority of
the resource (ceiling)
2 does not execute because
3 is with a higher priority
E E V V
V
E E E
E
Q Q
E Q Q E
The only problem is that t3
blocks t2 even if it was not
necessary

March 2013
 When there is blocking (due to sharing resources)
 Determining Bi is per task
 Dependent of the actual protocol used, but in any case:
 We need to determine which resources can be used
simultaneously by tasks with lower priority than ti and tasks with
equal or higher priority that ti (including ti itself)
i
i
i
i
hp
j
j
j
n
i
i
n
i
B
C
R
C
T
R
B
C
R i












 


0
)
(
1
* A blocking term needs to be
added to pre-emptive
Response-time analysis

 With PIP, it is possible to know the maximum
blocking
 
 









cases
other
,
,
ask
priority t
lowest
the
is
,
0
1
K
k
k
i
C
i
k
use
i
B
Where use(k,i) is one if resource k is used by a task with higher or
equal priority than task i (or task i)
AND
resource k is also used by at least one lower priority task than task i
If not, use(k,i) is zero
Note that this means that there could be several blocking periods (one
per resource)
58
March 2013

 PIP Example:
59
March 2013
C
(ms)
T=D
(ms)
Priority Arrival
instant (ms)
Execution
sequence
1 5 17 3 3 EEVVV
2 5 15 2 2 EEEEQQ
3 7 35 1 1 VVVEQQE
   
   
1
2
3
,1 ,1 0 2 1 3 3
,2 ,2 1 2 1 3 5
0
Q V
Q V
B use Q C use V C
B use Q C use V C
B
        
        

3
C
2; V
Q 

C

 With IPCP, it is possible to know the maximum
blocking
Where use(k,i) is one if resource k is used by a task with higher or
equal priority than task i (or task i)
AND
resource k is also used by at least one lower priority task than task i
If not, use(k,i) is zero
Note that now there is a max function, not a sum: only one
blocking period
60
March 2013
 
 








s
other task
,
,
max
ask
priority t
lowest
the
is
case
,
0
1
k
K
k
i
C
i
k
use
i
B

 IPCP Example:
   
   
   
   
1
2
3
max ,1 , ,1 max 0 2,1 3 3
max ,2 , ,2 max 1 2,1 3 3
0
Q V
Q V
B use Q C use V C
B use Q C use V C
B
      
      

3
C
2; V
Q 

C
61
March 2013
C
(ms)
T=D
(ms)
Priority Arrival
instant (ms)
Execution
sequence
1 5 17 3 3 EEVVV
2 5 15 2 2 EEEEQQ
3 7 35 1 1 VVVEQQE

Real-Time Systems
March 2013
 There is much more
 Open, dynamic systems
 Other scheduling and resource management schemes
 Specific operating systems (VxWorks, RT-Linux, …)
 Specific languages (Ada, RT-Java, …)
 Specific middleware (RT-Corba, DDS, …)
 We focused only on the fundamental, base,
knowledge of this scientific area

Real-Time Systems v3.pptx

Recommended

Recommended

More Related Content

Similar to Real-Time Systems v3.pptx

Similar to Real-Time Systems v3.pptx (20)

Recently uploaded

Recently uploaded (20)

Real-Time Systems v3.pptx