850 likes | 1.02k Views
2. What is real" about real-time?. computer worlde.g., PCaverage response for user Interactiveoccasionally longer reaction: user annoyed computer controls speed of user computer time" . real worldIndustrial system, airplaneenvironment has own speedreaction too slow: deadline mis
E N D
1. 1 CS-684 (Spring 2009)Embedded Systems(Software) Krithi Ramamritham
Kavi Arya
IIT Bombay
2. 2 What is “real” about real-time? computer world
e.g., PC
average response for user
Interactive
occasionally longer
reaction: user annoyed
computer controls speed of user
“computer time” real world
Industrial system, airplane
environment has own speed
reaction too slow: deadline miss
reaction: damage, pot. loss of human life
computer must follow speed of environment
“real-time”
3. 3 A real-time system is a system that reacts to events in the environment by performing predefined actions
Real-Time Systems
4. 4 Distributed RT
5. 5 Functional Design & Mapping
6. 6 CLIENT SERVER Flight Avionics
7. 7
8. 8 Real-Time Systems: Properties of Interest
Safety: Nothing bad will happen.
Liveness: Something good will happen.
Timeliness: Things will happen on time -- by their deadlines, periodically, ....
9. 9 In a Real-Time System…. correct value delivered too late is incorrect
e.g., traffic light: light must be green when crossing, not enough before
Real-time:
(Timely) reactions to events as they occur, at their pace:(real-time) system (internal) time same time scale as environment (external) time
10. 10 Performance Metrics in Real-Time Systems Beyond minimizing response times and increasing the throughput:
achieve timeliness.
More precisely, how well can we predict that deadlines will be met?
11. 11 Types of RT Systems Dimensions along which real-time activities can be categorized:
how tight are the deadlines?
--deadlines are tight when
laxity (deadline -- computation time) is small.
how strict are the deadlines?
what is the value of executing an activity after its deadline?
what are the characteristics of environment? how static or dynamic must the system be?
12. 12 Hard, soft, firm Hard -- result useless or dangerousif deadline exceeded
13. 13 Examples Hard real time systems
Aircraft
Airport landing services
Nuclear Power Stations
Chemical Plants
Life support systems
Soft real time systems
Mutlimedia
Interactive video games
14. 14 Real-Time: Items and Terms Task
program, perform service, functionality
requires resources, e.g., execution time
Deadline
specified time for completion of, e.g., task
time interval or absolute point in time
value of result may depend on completion time
15. 15 Plan Special Characteristics of Real-Time Systems
Real-Time Constraints
Canonical Real-Time Applications
Scheduling in Real-time systems
Operating System Approaches
16. 16 Timing Constraints Real-time means to be in time --- how do we know something is “in time”?how do we express that?
Timing constraints are used to specify temporal correctness “finish assignment by 2pm”,
“be at station before train departs”.
A system is said to be (temporally) feasible, if it meets all specified timing constraints.
Timing constraints do not come out of thin air:design process identifies events, derives models, and finally specifies timing constraints
17. 17 Overall Picture…
18. 18 Periodic
activity occurs repeatedly
e.g., to monitor environment values, temperature, etc.
19. 19 Aperiodic
can occur any time
no arrival pattern given
20. 20 Sporadic
can occur any time, but
minimum time between arrivals
21. 21 Who initiates (triggers) actions? Example: Chemical process
controlled so that temperature stays below danger level
warning is triggered before danger point
…… so that cooling can still occur
Two possibilities:
action whenever temp raises above warn-- event triggered
look every fixed time interval;
action taken when temp above warn
-- time triggered
22. 22
23. 23
24. 24 ET vs TT Time triggered
Stable number of invocations
Event triggered
Only invoked when needed
High number of invocation and computation demands if value changes frequently
25. 25 Slow down the environment? Importance
which parts of the system are important?
importance can change over timee.g., fuel efficiency during emergency landing
Flow controlwho has control over speed of processing, who can slow partner down?
environment
computer system
RT: environment cannot be slowed down
26. 26 Other Issues to worry about Meet requirements -- some activities may run only:
after others have completed - precedence constraints
while others are not running - mutual exclusion
within certain times - temporal constraints
Scheduling
planning of activities, such that required timing is kept
Allocation
where should a task execute?
27. 27 Plan Special Characteristics of Real-Time Systems
Real-Time Constraints
Canonical Real-Time Application Coding
Scheduling in Real-time systems
Operating System Approaches
28. 28 A Typical Real time system
29. 29 Code for example
30. 30 Comment on code Code is by Polling device (temperature sensor)
Code is in form of infinite loop
No other tasks can be executed
Suitable for dedicated system or sub-system only
31. 31 Extended polling example
32. 32 Polling Problems
Arranging task priorities
Round robin is usual within a priority level
Urgent tasks are delayed
33. 33 Interrupt driven systems Advantages
Fast
Little delay for high priority tasks
Disadvantages
Programming
Code difficult to debug
Code difficult to maintain
34. 34 How can we monitor a sensor every 100 ms
35. 35 An alternative…
36. 36 Clock, interrupts, tasks
37. 37 CLIENT SERVER Flight Simulator
38. 38 CLIENT SERVER Time Periods to meet Timing Requirements
39. 39 CLIENT SERVER Time Periods to meet Timing Requirements…
40. 40 Time Periods to meet Timing Requirements…
41. 41 Plan Special Characteristics of Real-Time Systems
Real-Time Constraints
Canonical Real-Time Applications
Scheduling in Real-time systems
Operating System Approaches
42. 42 Why is scheduling important? Definition:
A real-time system is a system that reacts to events in the environment by performing predefined actions within specified time intervals.
43. 43 Schedulability analysis a.k.a. feasibility checking:
check whether tasks will meet their
timing constraints.
44. 44 Scheduling Paradigms Four scheduling paradigms emerge, depending on
whether a system performs schedulability analysis
if it does,
whether it is done statically or dynamically
whether the result of the analysis itself produces a schedule or plan according to which tasks are dispatched at run-time.
45. 45 1. Static Table-Driven Approaches Perform static schedulability analysis by checking if a schedule is derivable.
The resulting schedule (table) identifies the start times of each task.
Applicable to tasks that are periodic (or have been transformed into periodic tasks by well known techniques).
This is highly predictable but, highly inflexible.
Any change to the tasks and their characteristics may require a complete overhaul of the table.
46. 46 2.Static Priority Driven Preemptive approaches Tasks have -- systematically assigned -- static priorities.
Priorities take timing constraints into account:
e.g. rate-monotonic
the lower the period, the higher the priority.
Perform static schedulability analysis but no explicit schedule is constructed
RMA - Sum of task Utilizations <= ln 2.
Task utilization = computation-time / Period
At run-time, tasks are executed highest-priority-first, with preemptive-resume policy.
When resources are used, need to compute worst-case blocking times.
47. 47 Static Priorities: Rate Monotonic Analysis presented by Liu and Layland in 1973
Assumptions
Tasks are periodic with deadline equal to period.Release time of tasks is the period start time.
Tasks do not suspend themselves
Tasks have bounded execution time
Tasks are independent
Scheduling overhead negligible
48. 48 RMA: Design Time vs. Run Time At Design Time:
Tasks priorities are assigned according to their periods; shorter period means higher priority
49. 49 RMA: Design Time vs. Run Time Schedulability test
Task set is schedulable if
Very simple test, easy to implement.
Run-time
The ready task with the highest priority is executed.
50. 50 RMA: Example
taskset: t1, t2, t3, t4
t1 = (3, 1)
t2 = (6, 1)
t3 = (5, 1)
t4 = (10, 2)
The schedulability test:
1/3 + 1/6 + 1/5 + 2/10 = 4 (2(1/4) - 1) ?
0.9 < 0.75 ?
…. not schedulable
51. 51 RMA…
A schedulability test is
Sufficient:
there may exist tasksets that fail the test, but are schedulable
Necessary:
tasksets that fail are (definitely) not schedulable
The RMA schedulability test is sufficient, but not necessary.
When periods are harmonic,
i.e., multiples of each other, utilization can be 1.
52. 52 Exact RMA by Joseph and Pandya, based on critical instance analysis
(longest response time of task, when it is released at same time as all higher priority tasks)
53. 53 What is happening at the critical instance?
Let T1 be the highest priority task. Its response time
R1 = C1 since it cannot be preempted
What about T2 ?R2 = C2 + delays due to interruptions by T1.
Since T1 has higher priority, it has shorter period. That means it will interrupt T2 at least once, probably more often.
Assume T1 has half the period of T2, R2 = C2 + 2 x C1
54. 54 Exact RMA…. In general:
Rni denotes the nth iteration of the response time of task i
hp(i) is the set of tasks with higher priority as task i
55. 55 Example - Exact Analysis Let us look at our example, that failed the pure rate monotonic test, although we can schedule it
Exact analysis says so.
R1 = 1; easy
R3, second highest priority taskhp(t3) = T1 -- R3 = 2
56. 56 R2, third highest priority taskhp(t2) = {T1 ,T3 }R2 = 3
57. 57 R4, third lowest priority taskhp(t4) = {T1 ,T3 ,T2 }
R4 = 9
Response times of first instances of all tasks
< their periods
=> taskset feasible under RM scheduling
58. 58 3. Dynamic Planning based Approaches Feasibility is checked at run-time -- a dynamically arriving task is accepted only if it is feasible to meet its deadline.
Such a task is said to be guaranteed to meet its time constraints
One of the results of the feasibility analysis can be a schedule or plan that determines start times
Has the flexibility of dynamic approaches with some of the predictability of static approaches
If feasibility check is done sufficiently ahead of the deadline, time is available to take alternative actions.
59. 59 4. Dynamic Best-effort Approaches The system tries to do its best to meet deadlines.
But since no guarantees are provided, a task may be aborted during its execution.
Until the deadline arrives, or until the task finishes, whichever comes first, one does not know whether a timing constraint will be met.
Permits any reasonable scheduling approach, EDF, Highest-priority,…
60. 60 Cyclic scheduling Ubiquitous in large-scale dynamic real-time systems
e.g., space shuttle, LCA
Combination of both table-driven scheduling and priority scheduling.
Tasks are assigned one of a set of harmonic periods. (e.g., 10-80 msecs for the LCA)
Within each period, tasks are dispatched according to a table that just lists the order in which the tasks execute.
61. 61 Slightly more flexible than the table-driven approach
no start times are specified
In many actual applications, rather than making worse-case assumptions, confidence in a cyclic schedule is obtained by very elaborate and extensive simulations of typical scenarios.
62. 62 Plan Special Characteristics of Real-Time Systems
Real-Time Constraints
Canonical Real-Time Applications
Scheduling in Real-time systems
Operating System Approaches
63. 63 Real-Time Operating Systems Support process management and synchronization, memory management, interprocess communication, and I/O.
Three categories of real-time operating systems:
small, proprietary kernels.
e.g. VRTX32, pSOS, VxWorks
real-time extensions to commercial timesharing operatin systems.
e.g. RT-Linux, RT-NT
research kernels
e.g. MARS, ARTS, Spring, Polis
64. 64 Real-Time Applications Spectrum In our paper you will find a discussion and classification of the leading products complementing NT. An alternative to NT targeted at embedded applications is Windows CE.
For applications at the bottom of the spectrum, one may argue that a general purpose operating system designed to be highly responsive and with limited real-time capabilities could be used. In our paper you will find a discussion and classification of the leading products complementing NT. An alternative to NT targeted at embedded applications is Windows CE.
For applications at the bottom of the spectrum, one may argue that a general purpose operating system designed to be highly responsive and with limited real-time capabilities could be used.
65. 65 Real-Time Applications Spectrum In this work we are interested in evaluating NT “as is” for real-time uses. And determined how far up the spectrum we can push NT with no extensions.
With this in mind, the goals of this work are:In this work we are interested in evaluating NT “as is” for real-time uses. And determined how far up the spectrum we can push NT with no extensions.
With this in mind, the goals of this work are:
66. 66 Embedded (Commercial) Kernels Stripped down and optimized versions of timesharing operating systems.
Intended to be fast
a fast context switch,
external interrupts recognized quickly
the ability to lock code and data in memory
special sequential files that can accumulate data at a fast rate
67. 67 To deal with timing requirements
a real-time clock with special alarms and timeouts
bounded execution time for most primitives
real-time queuing disciplines such as earliest deadline first,
primitives to delay/suspend/resume execution
priority-driven best-effort scheduling mechanism or a table-driven mechanism.
Communication and synchronization via mailboxes, events, signals, and semaphores.
68. 68 Real-Time Extensions to General Purpose Operating Systems E.g., extending LINUX to RT-LINUX, NT to RT-NT
Advantage:
based on a set of familiar interfaces (standards) that speed development and facilitate portability.
Disadvantages
Too many basic and inappropriate underlying assumptions still exist.
69. 69 COTS OS -- for RT applications? Scheduling and priorities
Preemptive, priority-based scheduling non-degradable priorities priority adjustment
No priority inheritance
No priority tracking
Limited number of priorities
No explicit support for guaranteeing timing constraints P inheritance Among user processes/threads.
Priority tracking From user to system/network threads
Threads
Hidden protocol stack
P inheritance Among user processes/threads.
Priority tracking From user to system/network threads
Threads
Hidden protocol stack
70. 70 Thread Priority = Process class + level The priority of a thread is determined by the combination of the priority class of its process and the level of the thread.
The priority of a thread is determined by the combination of the priority class of its process and the level of the thread.
71. 71 Typical Scheduling Threads scheduled by executive.
Priority based preemptive scheduling. Priority based preemptive scheduling is used for user-level threads as well as for different types of task within the system. A simplified model of the levels that help prioritize the tasks that must be accomplished before less time-critical work is shown in this figure:
Interrupts are handled at the higher level.
Deferred procedure calls, which I will explain in the next slide occupied the next level.
All user level process are handled a the lowest level,
Priority based preemptive scheduling is used for user-level threads as well as for different types of task within the system. A simplified model of the levels that help prioritize the tasks that must be accomplished before less time-critical work is shown in this figure:
Interrupts are handled at the higher level.
Deferred procedure calls, which I will explain in the next slide occupied the next level.
All user level process are handled a the lowest level,
72. 72 COTS OS -- for RT applications? (contd.) Quick recognition of external events
Priority inversion due to Deferred Procedure Calls (DPC)
I/O management
Timers granularity and accuracy
High resolution counter with resolution of 0.8 ?sec.
Periodic and one shot timers with resolution of 1 msec.
Rich set of synchronization objects and communication mechanisms.
Object queues are FIFO
73. 73 Research Operating Systems
MARS – static scheduling
ARTS – static priority scheduling
Spring –dynamic guarantees
Polis – synthesizing OSs
74. 74 MARS -- TU, Vienna (Kopetz) Offers support for controlling a distributed application based entirely on time events (rather than asynchronous events) from the environment.
A priori static analysis to demonstrate that all the timing requirements are met.
75. 75 Uses flow control on the maximum number of events that the system handles.
Based on the time driven model -- assume everything is periodic.
Static table-driven scheduling approach
A hardware based clock synchronization algorithm
A TDMA-like protocol to guarantee timely message delivery
76. 76 ARTS -- CMU (Tokuda, et al) The ARTS kernel provides a distributed real-time computing environment.
Works in conjunction with the static priority driven preemptive scheduling paradigm.
Kernel is tied to various tools that a priori analyze schedulability.
77. 77 The kernel supports the notion of real-time objects and real-time threads.
Each real-time object is time encapsulated -- a time fence mechanism: The time fence provides a run time check that ensures that the slack time is greater than the worst case execution time for an object invocation
78. 78 SPRING – Umass. (Ramamritham & Stankovic) Real-time support for multiprocessors and distributed systems
Strives for a more flexible combination of off-line and on-line techniques
Safety-critical tasks are dealt with via static table-driven scheduling.
Dynamic planning based scheduling of tasks that arrive dynamically.
79. 79 Takes tasks' time and resource constraints into account and avoids the need to a priori compute worst case blocking times
Reflective kernel retains a significant amount of application semantics at run time – provides flexibility and graceful degradation.
80. 80 Distributed RT
81. 81 Environment
Input from the environment via data collected by sensors
Output to environment via actuators
Real-time systems “sees” and interacts with environment via sensors and actuators
82. 82 Real-time buses Central communication medium for (distributed) real-time system
Data protocol specific
Temporally predictable, at least time bounded, transmission
Synchronized (?sec)
Membership info (who is alive)
Fault tolerant
more than one physical network
no single point of failure
83. 83 Fieldbus connects sensors (actuators) with RTS (possibly via dedicated gateway nodes)
needs to collect data and time of observation
latency: time passed since event occurrence
84. 84 CAN control area networkvery popular, used, e.g., by automotive industry (Volvo)
sender intends to send - puts bit on channel
collisions resolved by priorities more TTP?more TTP?
85. 85 TDMA - TTP
time division multiple access - time triggered protocol
network time divided into slots
static assignment of slots to nodes
implicit flow control more TTP?more TTP?
86. 86 Summary Special Characteristics of Real-Time Systems
Real-Time Constraints
Canonical Real-Time Applications
Scheduling in Real-time systems
Operating System Approaches