1 / 110

IT-606 Embedded Systems (Software)

IT-606 Embedded Systems (Software). Krithi Ramamritham S. Ramesh Kavi Arya KReSIT/ IIT Bombay. Real-Time Support. F2. Functional Design. F5. F1. F4. F3. (F2). Architectural Design. Thread. (F5). HW1. HW2. HW3. HW4. (F3). (F4). RTOS/Drivers. Hardware Interface.

gen
Télécharger la présentation

IT-606 Embedded Systems (Software)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. IT-606Embedded Systems(Software) Krithi Ramamritham S. Ramesh Kavi Arya KReSIT/ IIT Bombay Real-Time Support

  2. F2 FunctionalDesign F5 F1 F4 F3 (F2) ArchitecturalDesign Thread (F5) HW1 HW2 HW3 HW4 (F3) (F4) RTOS/Drivers Hardware Interface Functional Design & Mapping Source:Ian Phillips, ARM VSIA 2001

  3. 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” What is “real” about real-time?

  4. I/O - data event time Real-time computing system action I/O - data Real-Time Systems A real-time system is a system that reacts to events in the environment by performing predefined actions within specified time intervals.

  5. Flight Avionics CLIENT SERVER Constraints on responses to pilot inputs, aircraft state updates

  6. Constraints: • Keep plastic at proper temperature (liquid, but not boiling) • Control injector solenoid (make sure that the motion of the piston reaches the end of its travel)

  7. 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, ....

  8. 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?

  9. 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?

  10. value hard soft time + deadline (dl) Hard, soft, firm • Hard -- result useless or dangerousif deadline exceeded • Soft -- result of some - lower value if deadline exceeded - • Firm -- If value drops to zero at deadline

  11. Hard real time systems Aircraft Airport landing services Nuclear Power Stations Chemical Plants Life support systems Soft real time systems Mutlimedia Interactive video games Examples

  12. 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

  13. Plan • Special Characteristics of Real-Time Systems • Real-Time Constraints • Canonical Real-Time Applications • Scheduling in Real-time systems • Operating System Approaches

  14. Timing Constraints Real-time means to be in time --- how do we know something is “in time”?how do we express that? • Timing constraintsare used to specify temporalcorrectness “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

  15. Overall Picture…

  16. time periodic • Periodic • activity occurs repeatedly • e.g., to monitor environment values, temperature, etc. period

  17. time • Aperiodic • can occur any time • no arrival pattern given aperiodic aperiodic

  18. time • Sporadic • can occur any time, but • minimum time between arrivals mint sporadic

  19. 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

  20. t time TT ET

  21. t time TT ET

  22. 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

  23. 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?

  24. Plan • Special Characteristics of Real-Time Systems • Real-Time Constraints • Canonical Real-Time Application Coding • Scheduling in Real-time systems • Operating System Approaches

  25. A Typical Real time system Temperature sensor Input port CPU Memory Output port Heater

  26. Code for example While true do { read temperature sensor if temperature too high then turn off heater else if temperature too low then turn on heater else nothing }

  27. 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

  28. Extended polling example Heater 1 Conceptual link Temperature Sensor 1 Task 1 Heater 2 Temperature Sensor 2 Task 2 Computer Heater 3 Task 3 Temperature Sensor 3 Temperature Sensor 4 Heater 4 Task 4

  29. Polling • Problems • Arranging task priorities • Round robin is usual within a priority level • Urgent tasks are delayed

  30. Interrupt driven systems • Advantages • Fast • Little delay for high priority tasks • Disadvantages • Programming • Code difficult to debug • Code difficult to maintain

  31. How can we monitor a sensor every 100 ms Initiate a task T1 to handle the sensor T1: Loop {Do sensor task T2 Schedule T2 for +100 ms } Note that the time could be relative (as here) or could be an actual time - there would be slight differences between the methods, due to the additional time to execute the code.

  32. An alternative… Initiate a task to handle the sensor T1 T1: Do sensor task T2 Repeat {Schedule T2 for n * 100 ms n:=n+1} There are some subtleties here...

  33. Clock, interrupts, tasks Interrupts Clock Processor Examines Job/Task queue Task 1 Task 3 Task 2 Task 4 Tasks schedule events using the clock...

  34. Plan • Special Characteristics of Real-Time Systems • Real-Time Constraints • Canonical Real-Time Applications • Scheduling in Real-time systems • Operating System Approaches

  35. 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.

  36. Schedulability analysis a.k.a. feasibility checking: check whether tasks will meet their timing constraints.

  37. 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.

  38. 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.

  39. 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.

  40. 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

  41. RMA: Design Time vs. Run Time At Design Time: Tasks priorities are assigned according to their periods; shorter period means higher priority

  42. 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.

  43. 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

  44. 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.

  45. 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)

  46. 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

  47. 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

  48. 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) = T1R3 = 2

  49. R2, third highest priority taskhp(t2) = {T1 ,T3 }R2 = 3

  50. 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

More Related