1. RT Operating Systems & Scheduling
“ delivers the results of processing in a given time span”
Georgio Butazzo, “Predictable scheduling Algorithms and applications”, 3rd edition
3/16

2. Mars Rover Pathfinder deadlines missed in 1997 prob = priority inversion
VxWorks RTOS kernel
A few days into mission, Pathfinder sporadically missing deadlines
Watchdog timer generated system resets  loss of data.
Reason: xxxxxx
T1 information bus manager
T2 communication task
T3 meteorological data collection
Mutex controlled shared information bus
priorities ?
Blocked
The Mars Pathfinder mission was widely proclaimed as "flawless" in the early days after its July 4th, 1997 landing on the Martian surface. Successes included its unconventional "landing" -- bouncing onto the Martian surface surrounded by airbags, deploying the Sojourner rover, and gathering and transmitting voluminous data back to Earth, including the panoramic pictures that were such a hit on the Web. But a few days into the mission, not long after Pathfinder started gathering meteorological data, the spacecraft began experiencing total system resets, each resulting in losses of data. The press reported these failures in terms such as "software glitches" and "the computer was trying to do too many things at once".
This week at the IEEE Real-Time Systems Symposium I heard a fascinating keynote address by David Wilner, Chief Technical Officer of Wind River Systems. Wind River makes VxWorks, the real-time embedded systems kernel that was used in the Mars Pathfinder mission. In his talk, he explained in detail the actual software problems that caused the total system resets of the Pathfinder spacecraft, how they were diagnosed, and how they were solved. I wanted to share his story with each of you.
VxWorks provides preemptive priority scheduling of threads. Tasks on the Pathfinder spacecraft were executed as threads with priorities that were assigned in the usual manner reflecting the relative urgency of these tasks.
Pathfinder contained an "information bus", which you can think of as a shared memory area used for passing information between different components of the spacecraft. A bus management task ran frequently with high priority to move certain kinds of data in and out of the information bus. Access to the bus was synchronized with mutual exclusion locks (mutexes).
The meteorological data gathering task ran as an infrequent, low priority thread, and used the information bus to publish its data. When publishing its data, it would acquire a mutex, do writes to the bus, and release the mutex. If an interrupt caused the information bus thread to be scheduled while this mutex was held, and if the information bus thread then attempted to acquire this same mutex in order to retrieve published data, this would cause it to block on the mutex, waiting until the meteorological thread released the mutex before it could continue. The spacecraft also contained a communications task that ran with medium priority.
Most of the time this combination worked fine. However, very infrequently it was possible for an interrupt to occur that caused the (medium priority) communications task to be scheduled during the short interval while the (high priority) information bus thread was blocked waiting for the (low priority) meteorological data thread. In this case, the long-running communications task, having higher priority than the meteorological task, would prevent it from running, consequently preventing the blocked information bus task from running. After some time had passed, a watchdog timer would go off, notice that the data bus task had not been executed for some time, conclude that something had gone drastically wrong, and initiate a total system reset.
3/16

3. Characteristics of RTOS
Determinism: delay till acknowledging event
Responsiveness: time to service complete
response time = Determinism + responsiveness
User control: priority
Reliability: failure can cause loss of life or $$$$$.
Fail-soft operation: but with reduced service level
Rover – Mars, spacecraft, industrial control, flight control,..
RTOS: RT Linux, VxWorks (intel), Windows CE, QNX – Neutrino, LynxOS, tinyOS
General purpose OS  Min response time, Max throughput  fairness
3/1

4. Scheduling review : FCFS – FIFO
First­come, first­served (FCFS)
1st task that arrives executed first, followed by 2nd, 3rd..etc …
FCFS process may wait long time ex:
Process Total Run Time
P seconds
P seconds
P seconds
P1 12 sec.
P2 3sec
P3 8 sec
arrival order: P1,
P2, P3
arrival order: P2,
P3, P1 P2
P3 8 sec
P1 12 sec.
3/16

5. Example: Non-preemptive FCFS review
3/16

6. Round Robin - review
Sequential Process execution – timer generated fixed time slice
predetermined static order
Task executes till slice expires or complete
Interrupts generated by timer at time slice intervals
Context saved during switch
3/16

7. Real-Time Scheduling Policies goal: ensure predictability
EDF (Earliest Deadline First), RMS (Rate-Monotonic Scheduling)
Static table-driven
Suitable for periodic tasks/earliest-deadline first scheduling
Requires Static analysis of feasible schedule
Static priority-driven preemptive  RMS
Static analysis  priority
priority-driven scheduler
Dynamic - (evaluate priorities on the fly)
schedule using previously scheduled tasks and new arrival
 new one is accepted if all tasks meets constraints
Dynamic best effort
No feasibility analysis is performed
Assigned a priority to the new arrival  then apply earliest deadline first
System tries to meet all deadlines and aborts any started process whose deadline is missed
3/16

8. Modeling RT Scheduling for analysis
Periodic task (T)
period
Deadline
processing time /
Execution time
Processing
time of T
Deadline of T
Period of T
Task’s CPU utilization:
Ui = Ci Ti
Ci = task (execution time)
CPU utilization U = U1 + U Un < 1
processor utilization factor
3/16

9. System Model – Assumptions
Periodic tasks without precedence
tasks are assumed mutually independent
No OS overhead – simplified view
metrics:
Guarantee miss ratio = 0 (hard real-time)
Guarantee Probability(missed deadline) < X% (firm real-time)
Minimize miss ratio (firm real-time)
Minimize tardiness; maximize usefulness (soft real-time)
3/16

10. Real time scheduling: Periodic system model - fyi
Timing constraints of a periodic task ti is specified by (s, e, D, p)
si-(scheduled) Starting Time of Task i
ei-Processing time of i
fi-Finish time of i
Di-Deadline of i
pi-Period of i
ri-Rate of i = (1/pi)
3/16

11. Preemptive Scheduling
Threads assigned priorities
statically assigned (constant )
or dynamically assigned ( variable)
Shortest­Job­First
Preemptive scheduling:
highest priority task executes
Can preempt lower priority task
3/16

12. Preemptive Scheduling Example
3 tasks; eg Aircraft navigation
Task 3 : High priority, gathers accelerometer data / 5ms
Task 2 : Medium, collect gyro data & take action every 40 ms
Task 1 : Low priority, display update, built in test
Accelerometer update
Gyro update
Display update
3/16

13. Preemptive Scheduling Problems
resources hogged by high priority task
Starves low priority tasks
Priority inversion:
High priority task blocked By lower priority task !
3/16

14. RTOS Scheduling: Rate Monotonic Scheduling - RMS
Assume n tasks invoked periodically with: FYI
periods T1, … ,Tn (real-time constraints)
worst-case execution times (WCET) C1, … ,Cn
assumes no mutexes, semaphores, or blocking I/O
no precedence constraints
fixed priorities
preemptive scheduling
smallest period  highest priority
Theorem: If any priority assignment yields a feasible schedule, then priorities ordered by period (smallest period has highest priority) also yields a feasible schedule.
RMS is optimal in the sense of feasibility.
every task completes once within its designated period
3/16

15. Periodic Real-time task set P=period
The start time of a new instance of a job is the deadline of the last instance
3/16

16. RMS example 1: Two tasks with different periods
Non-preemptive schedule not feasible. C1 T1 C2 T2
Some Task (2) will not finish within its period .
3/16

17. RMS example 1: use preemptiveC1 T1 C2 T2
Preemptive scheduling with higher priority for T2
3/16

18. RMS example 1: preemptiveC1 C1
preempted
Preemptive schedule red task assigned higher priority - feasible. blue task takes longer.
3/16

19. RMS: task Alignment C1 T1
Completion time of lower priority task worst when it starts with higher priority tasks.
sufficient to consider worst case: All tasks start at same time.
Theorem: Worst-case phasing of a task occurs when it arrives simultaneously with all its higher priority tasks.
Theorem: for a set of independent, periodic tasks,
if each task meets its first deadline, with worst-case task phasing, the deadline will always be met.
3/16

20. Rate Monotonic Analysis (RMA): analyzing schedule feasibility
equations to analyze tasks.
applies to independent, periodic tasks, but - extended to address
priority inversion ;
task interactions
aperiodic tasks
Focus :periodic tasks using
UB (utilization Bound)
& RT (response time) tests
RMA is a mathematical approach for analyzing real-time tasks to determine their schedulability. Again, the original theory was only able to analyze independent, periodic tasks. However, the basic theory has been extended to analyze cases that include inversion, task interactions, and aperiodic tasks.
In this tutorial, we will first introduce the mechanics of the analysis based on the original RMS theory assumptions, which are very restrictive. We will then systematically relax the assumptions and extend the basic theory.
Remember that the analysis can be done on systems that are scheduled by other algorithms. Again, this is the strength in rate monotonic theory. The analysis can be applied to any system, providing insight to its timing behavior. From now on, our focus is on rate monotonic analysis (RMA) of systems, which may or may not use the rate monotonic scheduling (RMS) algorithm.
In this tutorial we will cover priority inversion.
3/16 8

21. RMS UB-Utilization Bound Test
UB test: n independent periodic tasks scheduled by RMS will always meet its deadlines, for all task phasings, if
U(1) = 1.0 U(4) = U(7) = 0.728
U(2) = U(5) = U(8) = 0.724
U(3) = U(6) = U(9) = 0.720
guaranteed schedulable if utilization less than bound
Excess CPU time used for non-critical tasks
< U(n) = n( )
C Cn / n
T Tn
We say a set of tasks is schedulable if the task set is guaranteed to meet all its deadlines. The utilization bound test says that a task set is schedulable if its total utilization is less than a certain bound, called the Liu & Leyland bound. The utilization bound test provides the basic formula underlying the theory. More complex formulas provide better bounds. This test is the application of a theorem,
The utilization bound test assumes that:
1. The processor always executes the highest priority task.
2. Task priorities are assigned according to rate monotonic policy.
3. Tasks do not synchronize with each other.
4. Each task’s deadline is at the end of its period.
5. Tasks do not suspend themselves in the middle of computations.
The test takes into account the preemption time and execution time for each task under a worst-case combination of periods and execution times. As the number of tasks goes to infinity, the bound approaches ln(2) = 0.693; in other words, any number of independent periodic tasks will meet their deadlines if the total system utilization is under 69%
For a harmonic task set (in which the period of each task is a multiple of all higher-frequency tasks), the utilization bound is 1.0 for all task sets.
3/16 6

22. UB Test: Example 1 3 tasks C T U
Task t1 20
100
0.200
Task t2 40
150
0.267
Task t3
350
0.286
Ui = Ci Ti
Since we are interested in worst-case behavior, tasks utilizations are always rounded up. For example, U2 = 40/150 = becomes .267 and U3 = 100/350 = becomes .286.
In this example, since the total utilization is under the bound for three tasks, all tasks are guaranteed to meet their deadlines, even under worst-case conditions. An additional 24.7% CPU capacity is available for lower-priority tasks that have no deadline.
Remember that there are several assumptions associated with the utilization bound test:
Zero context switch overhead.
Deadlines are at end of period.
No interrupts are used.
Priorities are assigned in rate monotonic order.
Tasks do not interact with one another.
Tasks do not suspend themselves.
Total utilization U = = .753 < U(3) = .779
UB test : task set above schedulable
3/16 7

23. Example 1 Timeline note: execution schedule – not unique
100
200
300
400
Highest frequency t 1 t 2
lowest frequency
This is the timeline for the periodic tasks of the sample problem (shown on the previous page), in which tasks are lined up in worst-case phasing (i.e. all task are ready to execute at time t=0).
Timelines show one possible execution schedule and provide a graphical view of schedule analysis. We will draw timelines according to the following conventions:
Tasks are arranged and numbered in rate monotonic order, highest frequency at the top.
We assume Liu and Leyland “worst-case” phasing, where all tasks start at time t=0.
Execution time for t1 is plotted on its line.
Execution time for t2 is then plotted on its line, accommodating preemption from t1’s execution; then this process is repeated for remaining tasks.
If any task is preempted, its execution time block is divided with a hole in the middle representing the preemption (e.g. t3) t 3
Scheduling Points
3/16 8

24. Example 2: UB Analyze: schedulable,  Draw timeline.
Ui = Ci Ti
Given:
C T U
Task t1:
Task t2:
Task t3:
Analyze: schedulable,  Draw timeline.
What is total utilization if C3 = 2 ?
Since we are interested in worst-case behavior, tasks utilizations are always rounded up. For example, U2 = 40/150 = becomes .267 and U3 = 100/350 = becomes .286.
In this example, since the total utilization is under the bound for three tasks, all tasks are guaranteed to meet their deadlines, even under worst-case conditions. An additional 24.7% CPU capacity is available for lower-priority tasks that have no deadline.
Remember that there are several assumptions associated with the utilization bound test:
Zero context switch overhead.
Deadlines are at end of period.
No interrupts are used.
Priorities are assigned in rate monotonic order.
Tasks do not interact with one another.
Tasks do not suspend themselves.
3/16 7

25. Solution: Example 2 UB Test
a. total utilization? = .69 b. Is task set schedulable? Yes: .69 < U(3) = .779 c. Draw the timeline. 5 10 15 20
Task t1
Task t3
Task t2
This is the timeline for the periodic tasks of the sample problem (shown on the previous page), in which tasks are lined up in worst-case phasing (i.e. all task are ready to execute at time t=0).
Timelines show one possible execution schedule and provide a graphical view of schedule analysis. We will draw timelines according to the following conventions:
Tasks are arranged and numbered in rate monotonic order, highest frequency at the top.
We assume Liu and Leyland “worst-case” phasing, where all tasks start at time t=0.
Execution time for t1 is plotted on its line.
Execution time for t2 is then plotted on its line, accommodating preemption from t1’s execution; then this process is repeated for remaining tasks.
If any task is preempted, its execution time block is divided with a hole in the middle representing the preemption (e.g. t3)
d. total utilization if C3 = 2 ?
= .79 > U(3) = .779
3/16 8

26. UB test conservative RT  (Response Time a. k
UB test conservative RT  (Response Time a.k.a completion time) More Precise Test
UB  3 outcomes:
0 < U < U(n)  Success
U(n) < U <  Inconclusive
1.00 < U  Overload
RT Response  more precise
The results of applying the UB test can be:
0<U<u(n) success, task set is schedulable
U9n)<U<1.0 inconclusive, task set may or may not be schedulable
1.0 < U overload, task set exceeds capacity
When the UB test is inconclusive, a more precise test can be applied.
The previous schedulability test (utilization bound test) is very conservative. Schedulable system utilization can often exceed 90%. In fact, for tasks with harmonic periods, where each period is evenly divisible into all longer periods (e.g. 100 ms, 200 ms, 800 ms, 1600 ms), the utilization bound is 100%.
3/16 9

27. RT Test å Interference term form higher priority tasks
Response time (RT) or Completion Time test: let a = response time of task i. :::: computed by the following formula:
Test terminates when a = a
Task i is schedulable if its response time is before its deadline: a < Ti n a
n+1 C i n T j 1 = - å +
where a
n+1 n n
test repeated for every task ti if required
i.e. the value of i will change depending upon the task you are looking at
Stop test once current iteration yields a value of an+1 beyond the deadline (else, you may never terminate).
The ‘square bracketish’  ‘ceiling’ function, NOT brackets
Ceiling function ::: smallest following integer, eg ceiling(1.4) = 2
3/16

28. Example 1b using RT; t1 20  40
Applying to examle I; if compute time of t1 20  40;
Is task set schedulable?
C T U
Task t1:
Task t2:
Task t3:
0.4 40
Utilization of T1 & T2 : < U(2) = 0.828
first two tasks schedulable by UB test
When 3rd task added, Utilization : > U(3) = 0.779
UB inconclusive
apply RT test ONLY for task 3 ( T1 , T2 schedulable)
The following data is the same as the sample problem. However, we have changed C1 from 20 to 40 to illustrate the use of the RT test.
Task t1: C1 = 40; T1 = 100; U1 = 0.4
Task t2: C2 = 40; T2 = 150; U2 = 0.267
Task t3: C3 = 100; T3 = 350; U3 = 0.286
Utilization of first two tasks: = .667 < U(2) = .828
Total utilization: = .953 > U(3) = .779
When we change C1 from 20 to 40, CPU utilization changes. Since the utilization of the first two tasks is under the utilization bound of the UB test, these tasks will always meet their deadlines. When the third task is considered, the total utilization is above the utilization bound (Liu & Leyland), so we must look further to see if the third task can nonetheless meet its deadline.
We will now apply the response time test to task t3
3/16 11

29. Applying RT for task 3
RT test :does t3 meets its first deadline: i = 3 a0 C j 1 = å 2 3 + 40
100
180 a1 C i a0 T j 1 = - å + 3 2
100
180 40 ( )
150 + 80
260 =
To apply the RT test, we do two steps
Use the iterative formula to compute the first response time W3 of t3.
Compare W3 to the first deadline for t3, namely T3.
If W3 < T3, then t3 is schedulable according to the RT test.
We start with an initial guess W3 = 0. This is labeled as the “zero-ith” iteration W3(0) = 0. To compute the first iteration, W3(1), we use the iteration formula with n = 0.
Substitute 0 for W3(0). All the terms in the summation drop out, so the first iteration is
W3(1) = C3 = 100.
Next we apply the formula with n=1 and n=2, and compute, respectively, W3(2) and W3(3). Since each successive iteration is different, the computation has not yet converged and we must continue. C T U T1 40
100
0.40 T2
150
0.267 T3
350
0.286
3/16 12

30. Example 1b: Applying RT for task 3c2 a1 T j C 1 = 2 å +
100
260
(40)
150
= 300 a3 c3 a2 T j C 1 = 2 å +
100
300
(40)
150
= 300 a3 a2
300
Done! =
Task t3 schedulable using RT
We continue by applying the iteration formula for n=3 and n=4.
Finally, the computed value for W3(5) is the same as W3(4).
W3(5) = W3(4) = 300.
The iteration has converged, and the first response time for t3 is
W3 = 300.
This must be compared to the first deadline for t3.
We have W3 < T3 since 300 < 350.
So t3 is schedulable using the response time test. C T U T1 40
100
0.40 T2
150
0.267 T3
350
0.286 a3 =
300
< T3 =
350
Task 3 response time < its period
3/16 13

31. Timeline Example 1b using RT
Task t1: C1 = T1 = 100
Task t2: C2 = T2 = 150
Task t3: C3 = T3 = 350
Task T1 compute time
Increased 20  40 t 2 3
100
200
300 1 20 10 60 40
This slide illustrates an alternate version of the response time test based on scheduling points. Again, the test is being applied only to t3.
A scheduling point is a point in time when new work arrives; the beginning of a new period for some task in the task set. This version of the CT test checks to see if there exists a scheduling point (at or before the deadline of t3) at which all work initiated up to that point has been completed. Since the workload includes the compute time of t3 as well as all higher-priority tasks, if the work is completed, then t3 has met its deadline.
In this graphical representation of task execution under worst-case phasing, we can see that, when all tasks are ready to execute at t=0, task t3 cannot begin execution until t=80. As t3 tries to complete its work it gets preempted at the next scheduling point at t=100, where t1 introduces more work. Each time t3 resumes its work it is preempted before completion, until t=300. In this example, task t3 completes all its work at exactly the fourth scheduling point. It completes all its work before its first deadline at t=350, and is therefore schedulable.
The reason for introducing two ways to find the response time is that the iteration formula is easier to program, while the scheduling points are easier to visualize t 3
completes at t = 300
3/16 14

32. Exercise 2: Applying UB & RT Test
Task t1: C1 = 1 T1 = 4 Task t2: C2 = 2 T2 = 6 Task t3: C3 = 2 T3 = 10 a) Apply UB test b) Draw timeline c) Apply RT test
Since we are interested in worst-case behavior, tasks utilizations are always rounded up. For example, U2 = 40/150 = becomes .267 and U3 = 100/350 = becomes .286.
In this example, since the total utilization is under the bound for three tasks, all tasks are guaranteed to meet their deadlines, even under worst-case conditions. An additional 24.7% CPU capacity is available for lower-priority tasks that have no deadline.
Remember that there are several assumptions associated with the utilization bound test:
Zero context switch overhead.
Deadlines are at end of period.
No interrupts are used.
Priorities are assigned in rate monotonic order.
Tasks do not interact with one another.
Tasks do not suspend themselves.
3/16 7

33. Solution: Applying UB & RT Tests
a) UB test
t1 and t2 OK -- no change from previous exercise
= .79 > ==> Test inconclusive for t3
b) Timeline
Task t1: C1 = 1 T1 = 4
Task t2: C2 = 2 T2 = 6
Task t3: C3 = 2 T3 = 10 5 10 15 20
Task t1
Task t2
Task t3
This is the timeline for the periodic tasks of the sample problem (shown on the previous page), in which tasks are lined up in worst-case phasing (i.e. all task are ready to execute at time t=0).
Timelines show one possible execution schedule and provide a graphical view of schedule analysis. We will draw timelines according to the following conventions:
Tasks are arranged and numbered in rate monotonic order, highest frequency at the top.
We assume Liu and Leyland “worst-case” phasing, where all tasks start at time t=0.
Execution time for t1 is plotted on its line.
Execution time for t2 is then plotted on its line, accommodating preemption from t1’s execution; then this process is repeated for remaining tasks.
If any task is preempted, its execution time block is divided with a hole in the middle representing the preemption (e.g. t3)
All work completed at t = 6
3/16 8

34. c) Applying RT Test for (i=3)C j 1 = å 2 + 5 a 1 C 3 T j = 2 å + 5 4 6
= 6 a 2 C 3 1 T j = å + 6 4
= 6
Done
3/16 8

35. Example 1c : Applying RT
same problem as example 1, increase t1 20  45; is task set schedulable?
C T U
Task t1:
Task t2:
Task t3:
0.45 45
Utilization of first two tasks: < U(2) = 0.828
first two tasks schedulable by UB test
The following data is the same as the sample problem. However, we have changed C1 from 20 to 40 to illustrate the use of the RT test.
Task t1: C1 = 40; T1 = 100; U1 = 0.4
Task t2: C2 = 40; T2 = 150; U2 = 0.267
Task t3: C3 = 100; T3 = 350; U3 = 0.286
Utilization of first two tasks: = .667 < U(2) = .828
Total utilization: = .953 > U(3) = .779
When we change C1 from 20 to 40, CPU utilization changes. Since the utilization of the first two tasks is under the utilization bound of the UB test, these tasks will always meet their deadlines. When the third task is considered, the total utilization is above the utilization bound (Liu & Leyland), so we must look further to see if the third task can nonetheless meet its deadline.
We will now apply the response time test to task t3
3/16 11

36. Example 1c: Applying RT for i=3
Task t1: C1 = T1 = 100
Task t2: C2 = T2 = 150
Task t3: C3 = T3 = 350
RT test used to determine if t3 meets its first deadline: i = 3 3 a C j 1 = å 2 3 + 45 40
100
185 a 1 C i T j = - å + 3 2
100
185 45 ( )
150 40 + 90 80
270 =
To apply the RT test, we do two steps
Use the iterative formula to compute the first response time W3 of t3.
Compare W3 to the first deadline for t3, namely T3.
If W3 < T3, then t3 is schedulable according to the RT test.
We start with an initial guess W3 = 0. This is labeled as the “zero-ith” iteration W3(0) = 0. To compute the first iteration, W3(1), we use the iteration formula with n = 0.
Substitute 0 for W3(0). All the terms in the summation drop out, so the first iteration is
W3(1) = C3 = 100.
Next we apply the formula with n=1 and n=2, and compute, respectively, W3(2) and W3(3). Since each successive iteration is different, the computation has not yet converged and we must continue. a 2 C 3 1 T j = å +
100
270
(45)
150
(40)
= 315
a3 GT 350 a 3 C 2 T j 1 = å +
100
315
(45)
150
(40)
= 400
STOP
3/16
Not sched 12

37. Summary of schedule analysis
UB test: simple - conservative.
RT test: more precise - more complicated.
UB and RT tests assumptions:
single processor
Periodic tasks - non interacting
Deadlines always at end of period
no interrupts
Rate-monotonic priorities are assigned
zero context switch overhead
3/16

38. Scheduling: Larger Problem Space –fyi more in RTOS scheduling III
Uni-processor vs multiprocessor vs distributed system
Periodic – sporadic - aperiodic tasks
Independent - interdependent tasks
Preemptive - non-preemptive
Tick scheduling / event-driven scheduling
Static (at design time) vs dynamic (at run-time)
Off-line (pre-computed schedule), on-line (scheduling decision at runtime)
Handle transient overloads
Support Fault tolerance
3/16