Real-Time Embedded Computing Systems Giorgio Buttazzo Scuola Superiore Sant’Anna, Pisa Computers everywhere Today, 98% of all processors in the planet are embedded in other objects:
Increasing complexity # functions in a cell phone 200 200 80 60 40 20 0 year 2010 1970 1980 1990 2000 ECU growth in a car # ECUs in a car 100 100 80 60 40 20 0 year 2010 1970 1980 1990 2000
Software in a car Car software controls almost everything: � Engine: g ignition, g , fuel p pressure, , water temperature, p , valve control, gear control, � Dashboard: engine status, message display, alarms � Diagnostic: failure signaling and prediction � Safety: ABS, ESC, EAL, CBC, TCS � Assistance: power steering, navigation, sleep sensors, parking, night vision, collision detection � Comfort: fan control, air conditioning, music, regulations: steer/lights/sits/mirrors/glasses… Software evolution in a car # Lines of code in a car 10 9 10 8 10 8 10 7 10 6 10 5 10 4 10 3 10 2 1980 1990 2000 2010
Software reliability Reliability does not only depend on the correctness of single instructions, but also on when they are executed: executed: input controller controller t Δ output t t t + Δ A correct action executed too late can be useless or even dangerous. Real-Time System A computing system that must guarantee bounded and predictable response times b d d d di t bl ti is called real-time system . Predictability of response times must be guaranteed in the worst-case scenario : in the worst-case scenario : � for each critical activity; � for all possible combination of events.
Outline 1. Basic concepts 2. Modeling real-time activities 3. Where timing constraints come from? 4. Real-time scheduling algorithms 5. Handling shared resources
A sample control application Mobile robot equipped with: � two actuated wheels; � two proximity sensors; � a mobile camera; � a wireless transceiver. Goal � Follow a path based on visual information; � Avoid obstacles; � Send system status every 20 ms. Control view visual ‐ based navigation 50 ms obstacle object avoidance recognition 10 ms visual vehicle tracking control 5 ms 20 ms feature motor extraction motor motor motor control control control control 1 ms 1 ms camera pan tilt US1 US2 mot_dx mot_sx
Software view periodic task buffer visual ‐ based obstacle navigation avoidance object recognition vehicle visual control tracking feature extraction motor control camera pan tilt US1 US2 mot_dx mot_sx Software structure OUTPUT OUTPUT INPUT task buffer
Real-Time System It is a system in which the correctness depends not only on the output values, but also on the time at which results are produced. t hi h lt d d (t) x RT system Environment t y (t+ Δ ) RTOS responsibilities The real-time operating system is responsible for: � activating periodic tasks at the beginning of each � activating periodic tasks at the beginning of each period; � deciding the execution order of tasks (scheduling); � solving possible timing conflicts during the access of shared resources (mutual exclusion); h d ( t l l i ) � manage the timely execution of asynchronous events (interrupts).
Real-Time ≠ Fast � A real-time system is not a fast system. � Speed is always relative to a specific environment. � Running faster is good, but does not guarantee a correct behavior guarantee a correct behavior. Speed vs. Predictability • The objective of a real-time system is to guarantee the timing behavior of each individual task. th ti i b h i f h i di id l t k • The objective of a fast system is to minimize the average response time of a task set. But … Don’t trust the average when you have to guarantee individual performance
Sources of non determinism � Architecture � cache, pipelining, interrupts, DMA , p p g, p , � Operating system � scheduling, synchronization, communication � Language � lack of explicit support for time lack of explicit support for time � Design methodologies � lack of analysis and verification techniques
Task � Sequence of instructions that in the absence of other activities is continuously executed by the processor until completion processor until completion. Task τ i activation time C i start time t a i s i f i computation i R i time The interval f i − a i is referred to as the finishing time task response time R i Ready queue In a single processor system more tasks can be ready to run, but only one can be in execution. � Ready tasks are kept in a ready queue, ordered by a scheduling policy. � The processor is assigned to the first task in the queue through a dispatching operation. Ready queue activation dispatching termination τ 3 τ 2 τ 1 CPU
Preemption It is a kernel mechanism that allows to suspend the running task in favor of a more important task. Ready queue activation dispatching termination τ 3 τ 2 τ 1 CPU preemption � Preemption allows reducing the response times of high priority tasks. � It can be temporarily disabled to ensure consistency of certain critical operations. Schedule It is a particular task execution sequence: Formally, given a task set Γ = { τ 1 , ..., τ n }, a schedule is a function σ : R + → N that associates an integer k to each interval of time [t, t+1) with the following meaning: k = 0 in [t, t+1) the processor is IDLE in [t, t+1) the processor executes τ k k > 0
Preemptive schedule priority τ 1 τ 2 τ 3 0 2 4 6 8 10 12 14 16 18 20 σ (t) 3 2 1 0 0 2 4 6 8 10 12 14 16 18 20 Task states priority running τ 1 running running τ 2 ready running running τ 3 ready 0 2 4 6 8 10 12 14 16 18 20 σ (t) 3 2 1 0 0 2 4 6 8 10 12 14 16 18 20
Task states BLOCKED BLOCKED signal wait dispatching activation termination READY READY RUNNING RUNNING preemption ACTIVE Real-Time Task � It is a task characterized by a timing constraint on its response time, called deadline: relative deadline D i τ i t a i s i f i d i absolute deadline response time R i response time R i ( d i = a i + R i ) ( d a + R ) A real ‐ time task τ i is said to be feasible if it completes within its absolute deadline, that is, if f i ≤ d i , o equivalently, if R i ≤ D i
Slack and Lateness D i τ i t a i s i f i d i R i slack i = d i - f i lateness L i = f i - d i D i τ i t a i s i d i f i R i Tasks and jobs A task running several times on different input data generates a sequence of instances (jobs): data generates a sequence of instances (jobs): Job 1 Job 2 Job 3 τ i,1 τ i,2 τ i,3 C i τ i t a i,1 a i,k a i,k+1
Periodic tasks input C i U i = U i T i computation time C i output utilization factor sync timer (period T i ) � A periodic task τ i generates an infinite sequence of p i g q jobs: τ i1 , τ i2 , …, τ ik (same code on different data): T i C i τ i Periodic task model τ i (C i , T i , D i ) job τ ik T i C i C a i,1 = Φ i a i,k a i,k+1 t task phase a i,k = Φ i + (k − 1) T i Φ + (k 1) T often D i = T i d i,k = a i,k + D i
Estimating C i is not easy � Each job operates on different data and can take different paths. ? � Even for the same data, computation time � Even for the same data computation time depends on the processor state (cache, prefetch queue, number of preemptions). loop ? # occurrencies ? execution time timer min max C i C i Predictability vs. Efficiency # occurrencies execution time min avg max C i C i C i C i estimate unsafe efficient safe
Predictability vs. Efficiency non ‐ RT task SOFT task HARD task efficiency predictability C i min avg max C i C i C i Support for periodic tasks task τ i while (condition) { while (condition) { wait_for_period(); } active active running τ i ready idle idle idle
The IDLE state signal wait BLOCKED terminate dispatching activate READY RUNNING preemption i wait_for_period wake_up IDLE Timer Jitter It is a measure of the time variation of a periodic event: a 1 t 1 a 2 t 2 a 3 a 4 t 3 max (t k – a k ) – min (t k – a k ) max (t k a k ) min (t k a k ) Absolute: Absolute: k k max | (t k – a k ) – (f k-1 – a k-1 ) | Relative: k
Types of Jitter Finishing ‐ time Jitter τ i τ i f i,1 f i,2 f i,3 Start ‐ time Jitter τ i s i,1 s i,2 s i,3 , , i,3 Completion ‐ time Jitter (I/O Jitter) τ i s i,1 f i,1 s i,2 f i,2 f i,3 s i,3
Timing constraints They can be explicit or implicit. • Explicit timing constraints Explicit timing constraints They are directly included in the system specifications. Examples – open the valve in 10 seconds – send the position within 40 ms – read the altimeter every 200 ms – acquire the camera every 20 ms Implicit timing constraints They do not appear in the system specification, but they need to be met to satisfy the performance y y p requirements. Example What is the time validity of a sensory data? ? t 0
Example: automatic braking v sensor visibility obstacle obstacle D D Dashboard Distribution human BRAKES Controls Unit emergency condition stop sensors checker 43 Worst-case reasoning acq. T s task Δ T s T b v obstacle in obstacle brake train the field detected pressed stopped 44
Recommend
More recommend
