IT606 Embedded Systems Software RealTime Support Krithi Ramamritham

IT-606 Embedded Systems (Software) Real-Time Support Krithi Ramamritham Kavi Arya IIT Bombay © Krithi Ramamritham / Kavi Arya 1

Functional Design & Mapping F 2 F 5 Source: Ian Phillips, ARM F 4 VSIA 2001 F 3 (F 2) Architectural Design HW 1 (F 5) (F 3) (F 4) HW 2 HW 3 HW 4 Thread F 1 Functional Design RTOS/Drivers Hardware Interface © Krithi Ramamritham / Kavi Arya 2

What is “real” about real-time? computer world real world § Industrial system, airplane § environment has own speed § reaction too slow: deadline miss § occasionally longer § reaction: damage, pot. reaction: user annoyed loss of human life § computer controls § computer must follow speed of user speed of environment § “real-time” § “computer time” § e. g. , PC § average response for user § Interactive © Krithi Ramamritham / Kavi Arya 3

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

Flight Avionics CLIENT SERVER Constraints on responses to pilot inputs, aircraft state updates © Krithi Ramamritham / Kavi Arya 5

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) 6 © Krithi Ramamritham / Kavi Arya

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, . . © Krithi Ramamritham / Kavi Arya 7

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? © Krithi Ramamritham / Kavi Arya 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? © Krithi Ramamritham / Kavi Arya 10

Hard, soft, firm • Hard -- result useless or dangerous if deadline exceeded value hard soft • Soft -- result of some lower value if deadline exceeded time - Firm -- If value drops to zero at deadline + • © Krithi Ramamritham / Kavi Arya deadline (dl) 11

Examples • Hard real time systems – Aircraft – Airport landing services – Nuclear Power Stations – Chemical Plants – Life support systems © Krithi Ramamritham / Kavi Arya • Soft real time systems – Mutlimedia – Interactive video games 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 © Krithi Ramamritham / Kavi Arya 13

Plan • Special Characteristics of Real-Time Systems • Real-Time Constraints • Canonical Real-Time Applications • Scheduling in Real-time systems • Operating System Approaches © Krithi Ramamritham / Kavi Arya 14

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 2 pm”, “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 © Krithi Ramamritham / Kavi Arya 15

Overall Picture… © Krithi Ramamritham / Kavi Arya 16

• Periodic – activity occurs repeatedly – e. g. , to monitor environment values, temperature, etc. period time periodic © Krithi Ramamritham / Kavi Arya 17

• Aperiodic – can occur any time – no arrival pattern given time aperiodic © Krithi Ramamritham / Kavi Arya 18

• Sporadic – can occur any time, but – minimum time between arrivals mint time sporadic © Krithi Ramamritham / Kavi Arya 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 © Krithi Ramamritham / Kavi Arya 20

t TT time ET © Krithi Ramamritham / Kavi Arya 21

t TT time ET © Krithi Ramamritham / Kavi Arya 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 © Krithi Ramamritham / Kavi Arya 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? © Krithi Ramamritham / Kavi Arya 25

Plan • Special Characteristics of Real. Time Systems • Real-Time Constraints • Canonical Real-Time Application Coding • Scheduling in Real-time systems • Operating System Approaches © Krithi Ramamritham / Kavi Arya 26

A Typical Real time system Temperature sensor Input port CPU Memory Heater © Krithi Ramamritham / Kavi Arya Output port 27

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 } © Krithi Ramamritham / Kavi Arya 28

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 subsystem only © Krithi Ramamritham / Kavi Arya 29

Extended polling example Temperature Sensor 1 Conceptual link Heater 2 Temperature Sensor 2 Computer Temperature Sensor 3 Temperature Sensor 4 © Krithi Ramamritham / Kavi Arya Heater 1 Heater 3 Heater 4 Task 1 Task 2 Task 3 Task 4 30

Polling • Problems – Arranging task priorities – Round robin is usual within a priority level – Urgent tasks are delayed © Krithi Ramamritham / Kavi Arya 31

Interrupt driven systems • Advantages – Fast – Little delay for high priority tasks • Disadvantages – Programming – Code difficult to debug – Code difficult to maintain © Krithi Ramamritham / Kavi Arya 32

How can we monitor a sensor every 100 ms Initiate a task T 1 to handle the sensor T 1: Loop {Do sensor task T 2 Schedule T 2 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. © Krithi Ramamritham / Kavi Arya 33

An alternative… Initiate a task to handle the sensor T 1: Do sensor task T 2 Repeat {Schedule T 2 for n * 100 ms n: =n+1} There are some subtleties here. . . © Krithi Ramamritham / Kavi Arya 34

Clock, interrupts, tasks Clock Interrupts Processor Examines Job/Task queue Task 1 Task 2 Task 3 Task 4 Tasks schedule events using the clock. . . © Krithi Ramamritham / Kavi Arya 35

Plan • Special Characteristics of Real. Time Systems • Real-Time Constraints • Canonical Real-Time Applications • Scheduling in Real-time systems • Operating System Approaches © Krithi Ramamritham / Kavi Arya 40

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. © Krithi Ramamritham / Kavi Arya 41

Schedulability analysis a. k. a. feasibility checking: check whether tasks will meet their timing constraints. © Krithi Ramamritham / Kavi Arya 42

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. © Krithi Ramamritham / Kavi Arya 43

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. © Krithi Ramamritham / Kavi Arya 44

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-priorityfirst, with preemptive-resume policy. • When resources are used, need to compute worst-case blocking times. © Krithi Ramamritham / Kavi Arya 45

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 © Krithi Ramamritham / Kavi Arya 46

RMA: Design Time vs. Run Time At Design Time: Tasks priorities are assigned according to their periods; shorter period means higher priority © Krithi Ramamritham / Kavi Arya 47

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. © Krithi Ramamritham / Kavi Arya 48

RMA: Example taskset: t 1, t 2, t 3, t 4 t 1 = (3, 1) t 2 = (6, 1) t 3 = (5, 1) t 4 = (10, 2) The schedulability test: 1/3 + 1/6 + 1/5 + 2/10 ≤ 4 (2(1/4) - 1) ? 0. 9 < 0. 75 ? …. not schedulable © Krithi Ramamritham / Kavi Arya 49

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. © Krithi Ramamritham / Kavi Arya 50

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) © Krithi Ramamritham / Kavi Arya 51

What is happening at the critical instance? • Let T 1 be the highest priority task. Its response time R 1 = C 1 since it cannot be preempted • What about T 2 ? R 2 = C 2 + delays due to interruptions by T 1. Since T 1 has higher priority, it has shorter period. That means it will interrupt T 2 at least once, probably more often. Assume T 1 has half the period of T 2, R 2 = C 2 + 2 x C 1 © Krithi Ramamritham / Kavi Arya 52

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 © Krithi Ramamritham / Kavi Arya 53

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. • R 1 = 1; easy • R 3, second highest priority task hp(t 3) = T 1 © Krithi Ramamritham / Kavi Arya 54

• R 2, third highest priority task hp(t 2) = {T 1 , T 3 } R 2 = 3 © Krithi Ramamritham / Kavi Arya 55

• R 4, third lowest priority task hp(t 4) = {T 1 , T 3 , T 2 } R 4 = 9 Response times of first instances of all tasks < their periods => taskset feasible under RM scheduling © Krithi Ramamritham / Kavi Arya 56

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. © Krithi Ramamritham / Kavi Arya 57

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, … © Krithi Ramamritham / Kavi Arya 58

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. © Krithi Ramamritham / Kavi Arya 59

• 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. © Krithi Ramamritham / Kavi Arya 60

Plan • Special Characteristics of Real-Time Systems • Real-Time Constraints • Canonical Real-Time Applications • Scheduling in Real-time systems • Operating System Approaches © Krithi Ramamritham / Kavi Arya 61

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. VRTX 32, p. SOS, Vx. Works – real-time extensions to commercial timesharing operatin systems. • e. g. RT-Linux, RT-NT – research kernels e. g. MARS, ARTS, Spring, Polis © Krithi Ramamritham / Kavi Arya 62

Real-Time Applications Spectrum Hard Soft © Krithi Ramamritham / Kavi Arya Real-Time Operating System General-Purpose Operating System Vx. Works, Lynx, QNX, . . . Intime, Hyper. Kernel, RTX Windows CE Linux, NT 63

Real-Time Applications Spectrum Hard Real-Time Operating System Vx. Works, Lynx, QNX, . . . Intime, Hyper. Kernel, RTX Windows CE Linux, NT Soft © Krithi Ramamritham / Kavi Arya General-Purpose Operating System 64

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 © Krithi Ramamritham / Kavi Arya 65

• 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. © Krithi Ramamritham / Kavi Arya 66

Real-Time Extensions to General Purpose Operating Systems E. g. , extending LINUX to RT-LINUX, NT to RTNT • 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. © Krithi Ramamritham / Kavi Arya 67

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 © Krithi Ramamritham / Kavi Arya 68

Thread Priority = Process class + level 26 25 24 23 22 Time-critical Highest Above Normal Below Normal Lowest 16 Idle 31 15 Time-critical 15 14 13 12 11 High class Normal class Thread Level Dynamic classes 11 10 9 8 7 Idle class © Krithi Ramamritham / Kavi Arya Real-time class 6 5 4 3 2 1 Idle 69

Typical Scheduling • Threads scheduled by executive. • Priority based preemptive scheduling. Interrupts Deferred Procedure Calls (DPC) System and user-level threads © Krithi Ramamritham / Kavi Arya 70

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 © Krithi Ramamritham / Kavi Arya 71

Research Operating Systems • • MARS – static scheduling ARTS – static priority scheduling Spring –dynamic guarantees Polis – synthesizing OSs © Krithi Ramamritham / Kavi Arya 72

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. © Krithi Ramamritham / Kavi Arya 73

• 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 © Krithi Ramamritham / Kavi Arya 74

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. © Krithi Ramamritham / Kavi Arya 75

• 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 © Krithi Ramamritham / Kavi Arya 76

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 tabledriven scheduling. – Dynamic planning based scheduling of tasks that arrive dynamically. © Krithi Ramamritham / Kavi Arya 77

• 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. © Krithi Ramamritham / Kavi Arya 78

Distributed RT © Krithi Ramamritham / Kavi Arya 79

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 © Krithi Ramamritham / Kavi Arya 80

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 © Krithi Ramamritham / Kavi Arya 81

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 © Krithi Ramamritham / Kavi Arya 82

CAN control area network very popular, used, e. g. , by automotive industry (Volvo) – sender intends to send - puts bit on channel – collisions resolved by priorities © Krithi Ramamritham / Kavi Arya 83

TDMA - TTP time division multiple access - time triggered protocol – network time divided into slots – static assignment of slots to nodes – implicit flow control © Krithi Ramamritham / Kavi Arya 84

Summary • Special Characteristics of Real-Time Systems • Real-Time Constraints • Canonical Real-Time Applications • Scheduling in Real-time systems • Operating System Approaches © Krithi Ramamritham / Kavi Arya 85