1. Real-Time Embedded Systems Assist. dr. Barbara Koroušić Seljak Barbara.Korousic@ijs.si (01) 4773-363

2. Jožef Stefan International Postgraduate School2 Course synopsis Fall semester: Fall semester: Basics of real-time and embedded systems Basics of real-time and embedded systems Embedded systems modeling Embedded systems modeling Software and program design concepts Software and program design concepts Operating systems for real-time applications Operating systems for real-time applications

3. Jožef Stefan International Postgraduate School3 Course synopsis Spring semester: Spring semester: Designing and developing embedded systems Designing and developing embedded systems Implementation and performance issues Implementation and performance issues

4. Jožef Stefan International Postgraduate School4 Benefits? Learn about...... challenges and approaches in real-time embedded system design... challenges and approaches in real-time embedded system design … performance estimation of real-time embedded systems … performance estimation of real-time embedded systems... current research areas... current research areas

5. Jožef Stefan International Postgraduate School5 Basics of real-time and embedded systems 1. Real-time systems

6. Jožef Stefan International Postgraduate School6 Real-time (RT) systems Categories of computer systems: Categories of computer systems: Batch: has no operational deadline from event to system response; Batch: has no operational deadline from event to system response; Interactive on-line: quick response is longed- for, but not required; Interactive on-line: quick response is longed- for, but not required; Real-time: system response is required within a predefined timescale, otherwise the system wont work properly. Real-time: system response is required within a predefined timescale, otherwise the system wont work properly.

7. Jožef Stefan International Postgraduate School7 Characteristics of a batch system The user pre-processes all programs and information at a local site, and at some convenient time these jobs are passed to a remote computer. When all jobs are finished, the results are transmitted back to the originating site. The user pre-processes all programs and information at a local site, and at some convenient time these jobs are passed to a remote computer. When all jobs are finished, the results are transmitted back to the originating site.

8. Jožef Stefan International Postgraduate School8 Characteristics of an on-line system Normally, access to such a system is made using computer-based remote terminals, and all transactions are handled by the central computer in a time- sliced fashion. Normally, access to such a system is made using computer-based remote terminals, and all transactions are handled by the central computer in a time- sliced fashion. These systems are widely used in banking, holiday booking and mail-order systems. Their response time depends on the amount of activity.

9. Jožef Stefan International Postgraduate School9 Characteristics of a RT system A control computer detects events triggered by sensors, and responds over actuators within predefined time bounds. A control computer detects events triggered by sensors, and responds over actuators within predefined time bounds.

10. Jožef Stefan International Postgraduate School10 History of real-time computing The term real-time derives from its use in early simulation. The term real-time derives from its use in early simulation. Originally, this term referred to a simulation that proceeded at a rate that matched that of the real process it was simulating. Originally, this term referred to a simulation that proceeded at a rate that matched that of the real process it was simulating.

11. Jožef Stefan International Postgraduate School11 RT Applications Execution time Deadlines SW size SW complexity Hard real-time & fast Hard real-time & slow Soft real-time & fast Soft real-time & slow Low weighting; High weighting

12. Jožef Stefan International Postgraduate School12 Hard RT Applications Critical deadlines Critical deadlines Usually, low SW complexity Usually, low SW complexity Example: airbag deployment system in motor vehicles Example: airbag deployment system in motor vehicles fast system – late deployment defeats the whole purpose of airbag protection time value hard deadline

13. Jožef Stefan International Postgraduate School13 Soft RT Applications Deadlines are not critical Deadlines are not critical Usually, more complex and large SW; man- machine interface Usually, more complex and large SW; man- machine interface Examples: factory Examples: factory automation system, automation system, barcode recognition barcode recognition system system fast/slow system – if fast/slow operator response is required time value soft deadline

14. Jožef Stefan International Postgraduate School14 Basics of real-time and embedded systems 1. Real-time systems 2. Embedded systems

15. Jožef Stefan International Postgraduate School15 Categories of RT systems Categories of computing systems: Categories of computing systems: General-purpose computing systems; General-purpose computing systems; Embedded systems (ESs). Embedded systems (ESs). RT systems may be general-purpose or embedded systems. RT systems may be general-purpose or embedded systems. We are going to discuss RT embedded systems. We are going to discuss RT embedded systems.

16. Jožef Stefan International Postgraduate School16 Characteristics of general-purpose systems Broad class of applications; Broad class of applications; Programmable by the end user; Programmable by the end user; Faster is better. Faster is better. Criteria: Criteria: Cost, Cost, performance (average speed); performance (average speed); Examples: personal computers, laptops, mainframes, servers. Examples: personal computers, laptops, mainframes, servers.

17. Jožef Stefan International Postgraduate School17 What is an ES? An embedded system is an electronic component within a physical system. An embedded system is an electronic component within a physical system. sensors / actuators man-machine interface embedded system (a combination of tailored HW & SW) external process reactive & time-constrained environment

18. Jožef Stefan International Postgraduate School18 Characteristics of ESs Single-functioned: Single-functioned: A single system-tailored task or a very small number of related tasks are executed repeatedly; A single system-tailored task or a very small number of related tasks are executed repeatedly; Minimal end-user intervention; Minimal end-user intervention; Tightly constrained: Tightly constrained: Low cost, low power, small size, easy-to-use, etc; Low cost, low power, small size, easy-to-use, etc; Reactive & real-time: Reactive & real-time: Continually reacts to events in the systems physical environment; Continually reacts to events in the systems physical environment; Must perform certain tasks in real-time on a physical platform. Must perform certain tasks in real-time on a physical platform.

19. Jožef Stefan International Postgraduate School19 Examples of ESs in common environments (1)

20. Jožef Stefan International Postgraduate School20 Examples of ESs in common environments (2)

21. Jožef Stefan International Postgraduate School21 Short list of embedded applications Consumer electronics (MP3 players, smart clothes, wearable devices) Consumer electronics (MP3 players, smart clothes, wearable devices) Home appliances (microwave owens, home security system) Home appliances (microwave owens, home security system) Office automation (modems, printers, scanners) Office automation (modems, printers, scanners) Business equipment (intruder alarm systems, POS terminals) Business equipment (intruder alarm systems, POS terminals) Automobiles (fuel injection, anti-lock brakes) Automobiles (fuel injection, anti-lock brakes) Aircrafts, satellites, trains, submarines (navigation systems) Aircrafts, satellites, trains, submarines (navigation systems) Medicine (life-support systems, medical devices) Medicine (life-support systems, medical devices) Telecommunication (network switches/routers, cell phones) Telecommunication (network switches/routers, cell phones) Automation systems (monitors, robots) Automation systems (monitors, robots)

22. Jožef Stefan International Postgraduate School22 Microprocessor and semiconductor chips trends

23. Jožef Stefan International Postgraduate School23 Brief history of ESs (1) Late 1940s: MIT Whirlwind computer was designed for real- time operations: Late 1940s: MIT Whirlwind computer was designed for real- time operations: Originally designed to control an aircraft simulator; Originally designed to control an aircraft simulator; In the 1960s: In the 1960s: The first recognizably ES was the Apollo Guidance Computer (MIT Instrumentation Laboratory); The first recognizably ES was the Apollo Guidance Computer (MIT Instrumentation Laboratory); By the end of the 80s: By the end of the 80s: ESs were the norm rather than the exception for almost all electronics devices (microcontrollers, I 2 C). ESs were the norm rather than the exception for almost all electronics devices (microcontrollers, I 2 C). Whirlwind computer Apollo Guidance computer Intel 4004

24. Jožef Stefan International Postgraduate School24 Brief history of ESs (2) Todays complex ESs are based on networks of distributed microprocessors that run many off-the- shelf operating systems and communicate through wired and wireless buses, LANs and WANs; A high-end automobile may have 100 microprocessors: 4-bit microcontrollers check seat belts; microcontrollers run dashboard devices; 16/32-bit microprocessor controls engine.

25. Jožef Stefan International Postgraduate School25 Brief history of ESs (3) What do we expect from high-performance ESs today? What do we expect from high-performance ESs today? Giga-ops of computing power; Giga-ops of computing power; For example, cell phones that use SW-radio techniques will need to deliver at least 10 billion operations per second; For example, cell phones that use SW-radio techniques will need to deliver at least 10 billion operations per second; Multimedia applications. Multimedia applications. It is difficult to achieve this performance level in the face of real-time and low power or other constraints. It is difficult to achieve this performance level in the face of real-time and low power or other constraints.

26. Jožef Stefan International Postgraduate School26 Few statistical facts General-purpose computers: General-purpose computers: Millions of units produced per year. Millions of units produced per year. Embedded systems: Embedded systems: Billions of units produced yearly (VDC Report, 2006). Billions of units produced yearly (VDC Report, 2006). More than 98% of processors applied today are in ESs. More than 98% of processors applied today are in ESs. Mean age of embedded developers: 39,6. Mean age of embedded developers: 39,6.

27. Jožef Stefan International Postgraduate School27 Students StudentResearch area 1. Student 1 2. Student 2 3. Student 3 4. Student 4 5. Student 5 6. Student 6 7. Student 7

28. Jožef Stefan International Postgraduate School28 ESs modeling Challenges: Challenges: 1.Technological: build an embedded system of predictable functionality and quality (performance & robustness) considering the systems constraints;

29. Jožef Stefan International Postgraduate School29 How to satisfy the technological challenge? Computing methods algorithms reuse Execution constraints CPU speed memory power HW failure rates Systems reaction constraints performance (deadlines, jitter, throughput) robustness (security, safety, availability)

30. Jožef Stefan International Postgraduate School30 Hardware design? Computing methods algorithms reuse Execution constraints CPU speed memory power HW failure rates Systems reaction constraints performance (deadlines, jitter, throughput) robustness (security, safety, availability) new computer architectures (open & flexible multi-core SoC)

31. Jožef Stefan International Postgraduate School31 Software design? Computing methods algorithms reuse Execution constraints CPU speed memory power HW failure rates Systems reaction constraints performance (deadlines, jitter, throughput) robustness (security, safety, availability) new software architectures (1-2 million lines of code)

32. Jožef Stefan International Postgraduate School32 Control design? Computing methods algorithms reuse Execution constraints CPU speed memory power HW failure rates Systems reaction constraints performance (deadlines, jitter, throughput) robustness (security, safety, availability) novel system-level analysis, modeling methods and tools

33. Jožef Stefan International Postgraduate School33 HW/SW Codesign! Computing methods algorithms reuse Execution constraints CPU speed memory power HW failure rates Systems reaction constraints performance (deadlines, jitter, throughput) robustness (security, safety, availability) Design, validation & maintenance processes need to support the high-performance HW & communication technologies!

34. Jožef Stefan International Postgraduate School34 HW/SW Co-design Approach In the past, HW and SW design technologies were very different. In the past, HW and SW design technologies were very different. Today, synthesis approaches enable a unified view of HW and SW: Today, synthesis approaches enable a unified view of HW and SW: Design of HW and SW can start from behavioral (system-level) description in sequential program model; Design of HW and SW can start from behavioral (system-level) description in sequential program model; Electronic System Level Design. Electronic System Level Design. Co-specification Problem analysis Requirement specifications HW/SW partitioning Co-synthesis SWHW Interface System Integration Co-simulation Co-verification C code VHDL code SystemC code

35. Jožef Stefan International Postgraduate School35 The Co-design Ladder (Vahid&Givargis, 2002) Compilers(1960s,1970s) Assemblers, linkers (1950s, 1960s) Behavioral synthesis (1990s, 2000s) RT synthesis (1980s, 1990s) Logic synthesis (1970s, 1980s) Assembly instructions Machine instructions Logic gates Logic equations/FSMs Register transfers Sequential program codes (e.g., C, VHDL, SystemC) Traditional program on a programmable processor VLSI, ASIC, or PLD implementation SW HW

36. Jožef Stefan International Postgraduate School36 Embedded Systems Design Challenge Design goal: Design goal: Construct a system with desired functionality. Construct a system with desired functionality. Key design challenge: Key design challenge: Simultaneously optimize numerous design metrics: Simultaneously optimize numerous design metrics: Time-to-prototype Time-to-prototype Time-to-market Time-to-market Maintainability Maintainability Correctness, reliability, safety, etc. Correctness, reliability, safety, etc. 8 months

37. Jožef Stefan International Postgraduate School37 ESs modeling Challenges: Challenges: 1.Technological: build an embedded system of predictable functionality and quality (performance & robustness) considering the systems constraints; 2.Scientific: integrate Electrical Engineering and Computer Science methodologies.

38. Jožef Stefan International Postgraduate School38 How to satisfy the scientific challenge? Electrical engineering Differential equations Differential equations Linear algebra Linear algebra Probability theory Probability theory Sythesis Sythesis Theories of estimation Theories of estimation Theories of robustness Theories of robustness Computer science Logic Discrete structures Automata theory Theories of correctness Verification Lets take down the cultural wall between the two fields!

39. Jožef Stefan International Postgraduate School39 Modeling (1) Main steps of the ESs design: 1. Definition of systems constraints / requirements; 2. Derivation of an abstract system, i.e. a model; 3. Automatic generation of a system.

40. Jožef Stefan International Postgraduate School40 Modeling (2) However, we cannot separate computation (SW) from physicality (platform & environment)! SW design a program a code a compiler generates model HW design a HW description a circuit a computer-aided design tool synthesizes model

41. Jožef Stefan International Postgraduate School41 Analytical modeling (1) Analytical model is a simulation, based on an abstract systems representation, which: Analytical model is a simulation, based on an abstract systems representation, which: attempts to find analytical (equation-based) solutions to problems that enable the prediction of the systems behavior from a set of parameters and initial conditions. attempts to find analytical (equation-based) solutions to problems that enable the prediction of the systems behavior from a set of parameters and initial conditions.

42. Jožef Stefan International Postgraduate School42 Analytical modeling (2) Types of analytical models : Types of analytical models : algorithm-based (language-based: Ada, RT-Java / synthesis-based: VHDL, Verilog), algorithm-based (language-based: Ada, RT-Java / synthesis-based: VHDL, Verilog), equation-based (MATLAB/Simulink) equation-based (MATLAB/Simulink) object-oriented, object-oriented, dynamic simulation, dynamic simulation, implementation platform independent (model- based); implementation platform independent (model- based); ANSYS. ANSYS.

43. Jožef Stefan International Postgraduate School43 Analytical modeling (3) Building blocks : Building blocks : types: transistors, logic gates, functional components (adders), architectural components (processors); types: transistors, logic gates, functional components (adders), architectural components (processors); structure changes: deterministic, or probabilistic; structure changes: deterministic, or probabilistic; composition: interconnected, inherently parallel, determined by data flows; composition: interconnected, inherently parallel, determined by data flows; formal semantics: transfer functions, typically specified by equations; formal semantics: transfer functions, typically specified by equations; Examples Examples: netlists, dataflow diagrams, and other notations for describing systems structure.

44. Jožef Stefan International Postgraduate School44 Analytical modeling (4) Embedded MATLAB: Embedded MATLAB: automatic code generation of C and C++ objects, optimized for ESs. automatic code generation of C and C++ objects, optimized for ESs.

45. Jožef Stefan International Postgraduate School45 Computational modeling (1) Computational model is a computer program, or a network of computers, which attempts to simulate an abstract model of a particular system: Computational model is a computer program, or a network of computers, which attempts to simulate an abstract model of a particular system: simulation is combined with the reality of actual events; simulation is combined with the reality of actual events; solutions to the problem are machine-based. solutions to the problem are machine-based.

46. Jožef Stefan International Postgraduate School46 Computational modeling (2) Types of computational models : Types of computational models : machine-based (RT/UML, AADL) machine-based (RT/UML, AADL) object-oriented, object-oriented, dynamic simulation, dynamic simulation, more generic (execution semantics independent) – model-based. more generic (execution semantics independent) – model-based.

47. Jožef Stefan International Postgraduate School47 Computational modeling (3) Building blocks: Building blocks: types: objects, threads; types: objects, threads; structure changes: dynamically; structure changes: dynamically; composition: sequential, determined by control flows; composition: sequential, determined by control flows; formal semantics: abstract machine (virtual machine / automaton); formal semantics: abstract machine (virtual machine / automaton); Examples Examples: programs, state machines, and other notations for describing system dynamics.

48. Jožef Stefan International Postgraduate School48 Computational modeling (4) Be realistic about the UML: Be realistic about the UML: Lack of analytical tools for computational models to deal with physical constraints; Lack of analytical tools for computational models to deal with physical constraints; Generally, code is still individually designed, not automatically generated. Generally, code is still individually designed, not automatically generated.

49. Jožef Stefan International Postgraduate School49 Analytical vs. computational modeling Analytical modeling Computational modeling Concurrency + / naturally deals with concurrency - Physical constraints +- Nondeterminism - / struggles with partial & incremental specifications + / supports nondeterministic abstraction hierarchies Computational complexity - + / rich theory Analytical & synthesis techniques +- Automatic generation of a system + + / directly executable models

50. Jožef Stefan International Postgraduate School50 Software and program design concepts SW Prototyping SW Prototyping

51. Jožef Stefan International Postgraduate School51 What do we want in our SW? Correctness: the static property that a program is consistent with its specification; Reliability: the extend to which a program can be expected to perform its intended function with required precision; Safety: the extend to which a program is concerned with the consequences of failure. dependable SW correct reliable safe is We wish that our SW is dependable, is delivered on time and is done within budget!

52. Jožef Stefan International Postgraduate School52 How to achieve this? (1) 1. Develop a clear statement of systems requirements. 2. Ensure that the design solution is capable of achieving this. 3. Organize the development so that the project is manageable. 4. Organize the development so that timescales can be met. 5. Make sure that the design can be managed without major rewrites. 6. Design for testability. 7. Minimize risks by using tried and trusted methods. 8. Ensure that safety is given its correct priority. 9. Make sure that the project doesnt completely rely on particular individual. 10. Produce a maintainable design. 11. ?

53. Jožef Stefan International Postgraduate School53 How to achieve this? (2) Systems requirements What its supposed to do function Dos and donts constraints How it fits in with its environment interfaces How well it must do it performance real-world interfacesSW world interfaces man-machineplantOSsdatabases functionalnon-functionalnon-functionalnon-functional

54. Jožef Stefan International Postgraduate School54 How to achieve this? (3) virtual prototyping

55. Jožef Stefan International Postgraduate School55 OSs for RT Applications Basics of RTOSs; Basics of RTOSs;

56. Jožef Stefan International Postgraduate School56 Role of OSs Typical OS configuration: Typical OS configuration: OS is an organized collection of SW extensions of HW that serve as: OS is an organized collection of SW extensions of HW that serve as: control routines for operating a computer; control routines for operating a computer; an environment for execution of programs. an environment for execution of programs. Typical embedded configuration: HW OS User programs HW User programs including RTOS components

57. Jožef Stefan International Postgraduate School57 OS hierarchy Typical OS configuration: Typical OS configuration: Typical embedded configuration: OS kernel gives us control over the resources: No background processes; Bounded number of tasks; OS kernel gives us control over timing by allowing: Manipulation of task priorities; Choice of scheduling options. HW OS Kernel File & Disk Control OS User Interface Shell Application program Application program Application program HW OS Kernel Application program interfaces OS Executive Real-world interfaces

58. Jožef Stefan International Postgraduate School58 Terminology: tasks & functions (1) A task is a process that repeats itself: A task is a process that repeats itself: Loop forever; Loop forever; Essential building block of real-time SW systems; Essential building block of real-time SW systems; A job is an instance of a task. A job is an instance of a task. A function is a procedure that is called. It runs, then exits and may return a value. A function is a procedure that is called. It runs, then exits and may return a value. while(1) { get_data(); process_data(); } loop functions a task with a real-time purpose

59. Jožef Stefan International Postgraduate School59 Terminology: tasks & functions (2) Periodic tasks: Periodic tasks: Time-driven: characteristics are known a priori; Time-driven: characteristics are known a priori; Task t i is characterized by (T i, C i ); Task t i is characterized by (T i, C i ); For example, task monitoring temperature of a patient. For example, task monitoring temperature of a patient. Aperiodic tasks: Aperiodic tasks: Event-driven: characteristics are not known a priori; Event-driven: characteristics are not known a priori; Task t i is characterized by (C i, D i ) and some probabilistic profile for arrival patterns (e.g. Poisson model); Task t i is characterized by (C i, D i ) and some probabilistic profile for arrival patterns (e.g. Poisson model); For example, task activated upon detecting change in patients condition. For example, task activated upon detecting change in patients condition. Sporadic Tasks: Sporadic Tasks: Aperiodic tasks with known minimum inter-arrival time (T i, C i ). Aperiodic tasks with known minimum inter-arrival time (T i, C i ).

60. Jožef Stefan International Postgraduate School60 Terminology: tasks & functions (3) Tasks parameters: Tasks parameters: Release time: the time when a job is ready; Release time: the time when a job is ready; Computation time: usually Worst-Case Execution Time (C i ); Computation time: usually Worst-Case Execution Time (C i ); Deadline: the time when a job should be ready (D i ); Deadline: the time when a job should be ready (D i ); Period: Period or minimum interarrival time; Period: Period or minimum interarrival time; Priority: static or dynamic; Priority: static or dynamic; Blocking time: worst-case; Blocking time: worst-case; Response time (latency): the time difference between the release time of a job and the completition time of the job. Response time (latency): the time difference between the release time of a job and the completition time of the job.

61. Jožef Stefan International Postgraduate School61 Terminology: Processes & Threads In traditional multitasking OSs, processes are typically independent, carry considerable state information, have separate address spaces, and interact only through system-provided inter-process communication mechanisms. In traditional multitasking OSs, processes are typically independent, carry considerable state information, have separate address spaces, and interact only through system-provided inter-process communication mechanisms. Multiple threads, on the other hand, typically share the state information of a single process, and share memory and other resources directly. Multiple threads, on the other hand, typically share the state information of a single process, and share memory and other resources directly. Context switching between threads in the same process is typically faster than context switching between processes. Context switching between threads in the same process is typically faster than context switching between processes. thread (of execution) isa way for A thread (of execution) is a way for a program to fork (or split) itself into two or more (pseudo-)simultaneously running tasks.

62. Jožef Stefan International Postgraduate School62 Basic RTOS kernel functions Task scheduler: to determine which task will run next in a multitasking system; Task scheduler: to determine which task will run next in a multitasking system; Task dispatcher: to perform necessary book-keeping to start a task; Task dispatcher: to perform necessary book-keeping to start a task; Control of shared resources: to support intertask communication. Control of shared resources: to support intertask communication.

63. Jožef Stefan International Postgraduate School63 OSs for RT Applications Basics of RTOSs; Basics of RTOSs; Scheduling modeling assumptions. Scheduling modeling assumptions.

64. Jožef Stefan International Postgraduate School64 RTOS kernel design strategies (1) Simple options: Simple options: 1. Pooled loop systems: A single and repetative instruction tests a flag that indicates whether or not an event has occured; A single and repetative instruction tests a flag that indicates whether or not an event has occured; No scheduling and intertask communication needed; No scheduling and intertask communication needed; Processor is dedicated to handling the data channel. Processor is dedicated to handling the data channel. 2. Interrupt-driven systems: Processing continues until interrupted by external events; Processing continues until interrupted by external events; After interrupt has been serviced, processing resumes where it left off. After interrupt has been serviced, processing resumes where it left off.

65. Jožef Stefan International Postgraduate School65 Interrupt handling An interrupt is a SW or HW signal to the processor, An interrupt is a SW or HW signal to the processor, indicating that something urgent has happened: indicating that something urgent has happened: Current task wants to sleep or get I/O; Current task wants to sleep or get I/O; Scheduler wants to run a different task now; Scheduler wants to run a different task now; Sensors detect external events; Sensors detect external events; Interrupts can be: Interrupts can be: prioritized, prioritized, disabled, disabled, masked. masked. interrupts ISR Processor must check for interrupts very frequently.

66. Jožef Stefan International Postgraduate School66 RTOS kernel design strategies (2) Extended options: Extended options: 1. Multitasking 2. Foreground / background systems 3. Full featured RTOSs

67. Jožef Stefan International Postgraduate School67 Multitasking (1) Separate tasks share one or more processors. Separate tasks share one or more processors. Each task executes within its own context: Each task executes within its own context: Owns CPU; Owns CPU; Sees its own variables; Sees its own variables; May be interrupted; May be interrupted; Tasks may interact to execute as a whole program. Tasks may interact to execute as a whole program.

68. Jožef Stefan International Postgraduate School68 Multitasking (2) Ways to implement multitasking: Ways to implement multitasking: Cyclic Executive (statically ordered tasks / threads) Cyclic Executive (statically ordered tasks / threads) Round Robin (each task is assigned a fixed time slice) Round Robin (each task is assigned a fixed time slice) These ways are not perfect: These ways are not perfect: High priority tasks hog resources and starve low priority tasks; High priority tasks hog resources and starve low priority tasks; Low priority tasks share a resource with high priority tasks and block high priority tasks. Low priority tasks share a resource with high priority tasks and block high priority tasks. How does a RTOS deal with some of these issues? How does a RTOS deal with some of these issues? Rate Monotonic / Earliest Deadline Systems Rate Monotonic / Earliest Deadline Systems Priority Inheritance Priority Inheritance

69. Jožef Stefan International Postgraduate School69 Rate Monotonic systems (Liu & Layland, 1973) General characteristics: General characteristics: Priority-based pre-emptive static scheduling; Priority-based pre-emptive static scheduling; Highest-priority ready task runs first; Highest-priority ready task runs first; Task priority P is set according to its periodicity T p : P=1/ T p ; Task priority P is set according to its periodicity T p : P=1/ T p ; Tasks are equally important; Tasks are equally important; SCHED_FIFO (POSIX) SCHED_FIFO (POSIX) Cons: It cannot deal with aperiodic tasks; Task deadline and period are considered to be synonymous; Task worst-case execution time is constant; Tasks are independent, i.e. non-interacting. Pros: Zero context-switch time; Task set scheduled using RMS is guaranteed to be feasible provided its utilization does not exceed 0.693 (full utilization).

70. Jožef Stefan International Postgraduate School70 Rate Monotonic systems (2) Utilization: The percentage of available processor time spent executing tasks (U t ); The lowest utilization figure U for n tasks is U=n(2 1/n -1).task execution time (ms) deadline / period (ms) 118 225 3210 U t =1/8+2/5+2/10=0.725 U= 3(2 1/3 -1)=0.78 Since U t < U... the system is schedulable!

71. Jožef Stefan International Postgraduate School71 Earliest Deadline First (EDF) General characteristics: General characteristics: Priority-based pre- emptive dynamic scheduling; Priority-based pre- emptive dynamic scheduling; Highest-priority ready task runs first; Highest-priority ready task runs first; Task priority P is set according to its due time T g : P=1/ T g ; Task priority P is set according to its due time T g : P=1/ T g ; Tasks are equally important; Tasks are equally important; Cons: Tasks priorities need to be recalculated at every timer interrupt; Task set scheduled using EDF is guaranteed to be feasible even if its utilization is 1. Pros: Task may miss its deadline.

72. Jožef Stefan International Postgraduate School72 Foreground / background systems Most common hybrid solution for embedded applications. Most common hybrid solution for embedded applications. Involve interrupt-driven (foreground) & non-interrupt-driven (background) processes: Involve interrupt-driven (foreground) & non-interrupt-driven (background) processes: Anything non-time-critical should be in background. Anything non-time-critical should be in background.

73. Jožef Stefan International Postgraduate School73 OSs for RT Applications Basics of RTOSs; Basics of RTOSs; Scheduling modeling assumptions; Scheduling modeling assumptions; Interprocess communication. Interprocess communication.

74. Jožef Stefan International Postgraduate School74 Priority inversion Problem: Problem: Task T 1 of high priority and task T 3 of low priority share a resource; Task T 1 of high priority and task T 3 of low priority share a resource; Task T 1 is blocked when task T 3 runs (priority inversion); Task T 1 is blocked when task T 3 runs (priority inversion); Task T 1 will be blocked for longer if task T 2 of medium priority comes along to keep task T 3 from finishing; Task T 1 will be blocked for longer if task T 2 of medium priority comes along to keep task T 3 from finishing; Solution: A good RTOS would sense this condition and temporarily promote task T 3 to the high priority of task T 1 (priority inheritance).

75. Jožef Stefan International Postgraduate School75 How to overcome priority inversion? Problem: Problem: Solution (priority ceiling protocol): T3T3 T3T3 T3T3 T2T2 T1T1 T1T1 time priority low high T 1 is blocked because T 3 has the resource T 2 can block T 3, which also keeps T 1 waiting T 3 inherits T 1 s priority so it can finish and then T 1 can have the resource time low high T3T3 T3T3 T3T3 T2T2 T1T1 T1T1 priority

76. Jožef Stefan International Postgraduate School76 OSs for RT Applications Basics of RTOSs. Basics of RTOSs. Scheduling modeling assumptions. Scheduling modeling assumptions. Interprocess communication. Interprocess communication. Power management. Power management.

77. Jožef Stefan International Postgraduate School77 Power optimization Power management: Power management: determines how system resources are going to be used to satisfy the power consumptions requirement. determines how system resources are going to be used to satisfy the power consumptions requirement. RTOS may reduce power by shutting down units: RTOS may reduce power by shutting down units: Entering and leaving the power-down mode requires both, energy and time. Entering and leaving the power-down mode requires both, energy and time.

78. Jožef Stefan International Postgraduate School78 Power management policies (1) Request-driven: Request-driven: Power up once request is received; Power up once request is received; Con: Adds delay to response. Con: Adds delay to response. Predictive shutdown: Due time to next request is predicted; Pro: May start up in advance of request in anticipation of a new request; Con: If prediction is wrong, an additional delay may be incured while starting up.

79. Jožef Stefan International Postgraduate School79 Power management policies (2) Probabilistic shutdown: Probabilistic shutdown: Assume service requests are probabilistic; Assume service requests are probabilistic; Optimize expected values: Optimize expected values: power consumption; power consumption; response time. response time. Simple probabilistic: shut down after time T on, turn back on after waiting for T off. Simple probabilistic: shut down after time T on, turn back on after waiting for T off.

80. Jožef Stefan International Postgraduate School80 Advanced Configuration and Power Interface ACPI (open standard for power management services). ACPI (open standard for power management services). Hardware platform device drivers ACPI BIOS RTOS kernel application power management

81. Jožef Stefan International Postgraduate School81 OSs for RT Applications Basics of RTOSs. Basics of RTOSs. Scheduling modeling assumptions. Scheduling modeling assumptions. Interprocess communication. Interprocess communication. Power management. Power management. Examples of commercial RTOSs. Examples of commercial RTOSs.

82. Jožef Stefan International Postgraduate School82 Examples of commercial RTOSs (1) RTOSs: VxWorks (VRTX), QNX, LynxOS, eCos, DeltaOS, PSX, embOS,... RTOSs: VxWorks (VRTX), QNX, LynxOS, eCos, DeltaOS, PSX, embOS,... satisfy the standard Real-Time POSIX 1003.1 (pre- emptive fixed-priority scheduling, synchronization methods, task scheduling options). satisfy the standard Real-Time POSIX 1003.1 (pre- emptive fixed-priority scheduling, synchronization methods, task scheduling options). Because people love general-purpose OSs: Because people love general-purpose OSs: RTLinux (FSMLabs), RTLinux (FSMLabs), Linux/RT (TimeSys), Linux/RT (TimeSys), Windows CE,... Windows CE,...

83. Jožef Stefan International Postgraduate School83 Examples of commercial RTOSs (2) LynxOS: LynxOS: Microkernel architecture that provides scheduling, interrupt & synchronization support Microkernel architecture that provides scheduling, interrupt & synchronization support Real-time POSIX support Real-time POSIX support Easy transition from Linux Easy transition from Linux VxWorks: Monolithic kernel (reduces run-time overhead, but has an increased kernel size compared to microkernel designs) Real-time POSIX support Common in industry: Mars mission Honda ASIMO robot Switces MRI scanners Car engine control systems

84. Jožef Stefan International Postgraduate School84 Examples of commercial RTOSs (3) RTLinux: RTLinux: Dual-kernel approach: Dual-kernel approach: Makes Linux a low- priority pre-emptable thread running on a separate RTLinux kernel; Makes Linux a low- priority pre-emptable thread running on a separate RTLinux kernel; Tradeoff between determinism of pure RTOSs and flexibility of GPOSs. Tradeoff between determinism of pure RTOSs and flexibility of GPOSs. Periodic tasks only. Periodic tasks only.

85. Jožef Stefan International Postgraduate School85 Open Issues - Multi-criteria Optimization Problems (1) HW/SW partitioning: HW/SW partitioning: By evolutionary algorithms & genetic algorithms, Lothar Thiele, ETH. By evolutionary algorithms & genetic algorithms, Lothar Thiele, ETH.

86. Jožef Stefan International Postgraduate School86 Open Issues - Multi-criteria Optimization Problems (2) Configurable processor technology Tensilica ( http://www.tensilica.com ): Configurable processor technology Tensilica ( http://www.tensilica.com ): http://www.tensilica.com fitting the processor to the algorithm; fitting the processor to the algorithm;

87. Jožef Stefan International Postgraduate School87 EU Technological platform ARTEMIS

88. Jožef Stefan International Postgraduate School88 Organization (1) Consultation: JSI / room S6D, (01) 4773- 363, barbara.korousic@ijs.si Consultation: JSI / room S6D, (01) 4773- 363, barbara.korousic@ijs.si Next lecture: 4 th March, 2008 Next lecture: 4 th March, 2008 Web page (course material): csd.ijs.si/korousic/korousic.html Web page (course material): csd.ijs.si/korousic/korousic.html

89. Jožef Stefan International Postgraduate School89 Organization (2) References: References: J. Cooling, Software Engineering for Real-Time Systems, Addison-Wesley, 2003; J. Cooling, Software Engineering for Real-Time Systems, Addison-Wesley, 2003; F. Vahid, T.Givargis, Embedded System Design – A Unified Hardware/Software Introduction, Wiley, 2002; F. Vahid, T.Givargis, Embedded System Design – A Unified Hardware/Software Introduction, Wiley, 2002; IEEE Computer, Vol. 40, No. 10, October 2007; IEEE Computer, Vol. 40, No. 10, October 2007; http://www.echelon.com/solutions/industrial/appstories/ http://www.echelon.com/solutions/industrial/appstories/ http://www.echelon.com/solutions/industrial/appstories/ http://www.mathworks.fr/products/simulink/demos.html ?file=/products/demos/wt/spacecraft.html http://www.mathworks.fr/products/simulink/demos.html ?file=/products/demos/wt/spacecraft.html http://www.mathworks.fr/products/simulink/demos.html ?file=/products/demos/wt/spacecraft.html http://www.mathworks.fr/products/simulink/demos.html ?file=/products/demos/wt/spacecraft.html

90. Jožef Stefan International Postgraduate School90 Organization (3) Course material: slide copies, books, papers Course material: slide copies, books, papers Exam: seminar work OR oral exam Exam: seminar work OR oral exam May, June, September May, June, September