1 / 46

Integrated Real-Time Systems

Integrated Real-Time Systems. Vibhooti Verma M.Tech . (CSE) 05305016. Advisor: Prof. Krithi Ramamritham. Outline. Introduction Focus of the Work and Motivation Contributions SParK/SCOS: System Requirements SParK: System Architecture SParK: Design Issues Scheduling

elpida
Download Presentation

Integrated Real-Time Systems

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. Integrated Real-Time Systems VibhootiVerma M.Tech. (CSE) 05305016 Advisor: Prof. KrithiRamamritham

  2. Outline • Introduction • Focus of the Work and Motivation • Contributions • SParK/SCOS: System Requirements • SParK: System Architecture • SParK: Design Issues • Scheduling • Two-level Static cycle and RM based priority scheduling • Partition Inversion and Solution • Virtual Aperiodic Partition • Interrupt handling • Virtual Interrupt Partition • Timer Virtualization • I/O Virtualization • CPU Virtualization • Memory Virtualization and Inter- Partition Communication • Implementation • Conclusions and Further Work

  3. Introduction to Integrated Real-Time Systems (IRTS) • Applications with different levels of criticality • Hard real-time, Soft real-time, Non real-time • Tasks with different arrival patterns • Aperiodic, Periodic • Strong Partitioning • Spatial and Temporal partitioning • A Typical System:

  4. Focus of Our Work • Design and development of a Strongly Partitioned real-time Kernel(SParK) which can host multiple RTOS (one of them being Safety Critical Operating System (SCOS) Motivation • Fault Containment • Easy Verification and Validation • Application Specific Operating System • Local Schedulability Analysis • Efficient Utilization of Resources

  5. Contributions • Identified system components and proposed system architecture • Designed SParK ensuring strong partitioning based on virtualization concepts • Proposed Rate Monotonic based partition scheduler to achieve temporal partitioning • Identified the problem of Partition Inversion and proposed solution for the same • Adopted Virtual Interrupt Partition to avoid deadline miss due to interrupt storm • Implemented in Stand-Alone RTLinux: • Two-level static cyclic scheduler • Two-level dynamic scheduler • Interrupt Server • Priority Inheritance • Serial Port driver

  6. Outline • Introduction • Focus of the Work and Motivation • Contributions • SParK/SCOS: System Requirements • SParK: System Architecture • SParK: Design Issues • Scheduling • Two-level Static cycle and RM based priority scheduling • Partition Inversion and Solution • Virtual Aperiodic Partition • Interrupt handling • Virtual Interrupt Partition • Timer Virtualization • I/O Virtualization • CPU Virtualization • Memory Virtualization and Inter- Partition Communication • Implementation • Conclusions and Further Work

  7. SParK: Requirements • Strongly partitioned architecture • Temporal and Spatial partitioning • Fault Containment and Isolation • Multiplex system resources among different partitions • Support partitions with different RTOS • Provide Inter-Partition Communication mechanism • Guarantee Interrupts to meet their deadlines • Simple design • Diskless system • Full Predictability

  8. SCOS: Requirements • Interface to hardware • Task Management and priority based scheduling • Inter-task communication • Interrupt Management • Memory management with protection • Timer Services • I/O Services • Scalable, Portable • Support for embedded diskless target environment (ROMable)

  9. Outline • Introduction • Focus of the Work and Motivation • Contributions • SParK/SCOS: System Requirements • SParK: System Architecture • SParK: Design Issues • Scheduling • Two-level Static cycle and RM based priority scheduling • Partition Inversion and Solution • Virtual Aperiodic Partition • Interrupt handling • Virtual Interrupt Partition • Timer Virtualization • I/O Virtualization • CPU Virtualization • Memory Virtualization and Inter- Partition Communication • Implementation • Conclusions and Further Work

  10. SParK: System Architecture • Salient Features • SParK layer between RTOS and Hardware • Virtual Aperiodic Partition (VAP) • Virtual Interrupt Partition (VIP) • Virtual Device Partition (VDP)

  11. Virtualization and SParK • Similarities • Running multiple OS(RTOS) • Spatial Partitioning • Isolation and Fault containment • VMM (SParK) acts as resource manager • VMM (SParK) gives an illusion to guest OS that they have exclusive access to resources • Differences • Temporal partitioning • Inter-partition communication • Interrupt Guarantees without affecting tasks

  12. Outline • Introduction • Focus of the Work and Motivation • Contributions • SParK/SCOS: System Requirements • SParK: System Architecture • SParK: Design Issues • Scheduling • Two-level Static cycle and RM based priority scheduling • Partition Inversion and Solution • Virtual Aperiodic Partition • Interrupt handling • Virtual Interrupt Partition • Timer Virtualization • I/O Virtualization • CPU Virtualization • Memory Virtualization and Inter- Partition Communication • Implementation • Conclusions and Further Work

  13. Scheduling: Issues • Ensuring temporal partitioning • All real-time tasks of all the partitions should meet their deadlines. • Mechanism to handle Partition Inversion • Minimizing partition switch overhead • Handling aperiodic tasks • Ensuring ‘n’ out of ‘m’ interrupts without affecting other tasks

  14. Scheduling: Approach • Two-level hierarchical scheduler • Lower level scheduler schedules partitions • Upper level scheduler schedules tasks within the partition • Lower level scheduler can adopt • Static cycle scheduling • RM based priority scheduling (proposed) • EDF based Dynamic Open environment scheduling • Upper level can have any fixed priority scheduling

  15. Scheduling: Techniques • SPIRIT’s Cyclic Scheduling [1] • Non-preemptable sections not handled in original algorithm, proposed solution for same and modified schedulability bounds • Separate partition for aperiodic tasks • Open Environment ‘s Dynamic-Priority-Driven (EDF) Scheduling [2] • CBS and TBS for partition scheduling • Handling Aperiodic tasks not clear • Handling Blocking factor with TBS only • RM Based Priority Scheduling • Handles non-preemtable section • Modified schedulability bounds to account for non-preemptable sections • Least priority partition for aperiodic tasks

  16. Outline • Introduction • Focus of the Work and Motivation • Contributions • SParK/SCOS: System Requirements • SParK: System Architecture • SParK: Design Issues • Scheduling • Two-level Static cycle and RM based priority scheduling • Partition Inversion and Solution • Virtual Aperiodic Partition • Interrupt handling • Virtual Interrupt Partition • Timer Virtualization • I/O Virtualization • CPU Virtualization • Memory Virtualization and Inter- Partition Communication • Implementation • Conclusions and Further Work

  17. Static Cycle Driven Scheduling Algorithm at lower level • Allocates capacity and cycle time for every partition • Creates a static schedule, uses Unique and Harmonic cycle approach • Separate VAP with dynamic slot shifting to provide better responsiveness to aperiodic tasks

  18. Schedulability Condition • If a partition has ‘n’ tasks with computation time Cj, deadline Dj and period Pj, and assigned processor capacity , then a task is schedulable if Inactivity period of a task is Minimum activity period of a partition is A Partition is schedulable if: 1.It is schedulable at processor of speed 2.Partition cycle

  19. Example: Static cycle scheduling of partitions

  20. Partition Inversion • Definition: scenario where a scheduled partition gets blocked due to locks held by other partition(s) • Our solution: Let the partition finish all of its CS before partition switch

  21. Partition Inversion: Modified Schedulability Bounds • Maximum duration to complete a partition Pk’s critical section Unique Partition cycle approach: every partition gets scheduled exactly once hence modified schedulability bounds

  22. RM based Preemptive Priority scheduling (RMSParK) • If there are ‘m’ partitions with feasible for ith partition then all partitions are schedulable if Where, lower the , higher the priority

  23. Handling Partition Inversion in RMSParK Partition preemption: 1)Budget exhaustation 2)Arrival of higher priority partition • Current partition has to let other partitions finish their critical sections: • When it is scheduled for the first time in its period • When other higher priority partition preempts it and starts executing Using RMA exact analysis for partition scheduling taking blocking into account: • If Pn is highest priority partition otherwise Generalized formula for ith response time of a nth partition

  24. Infinite Partition Inversion

  25. Outline • Introduction • Focus of the Work and Motivation • Contributions • SParK/SCOS: System Requirements • SParK: System Architecture • SParK: Design Issues • Scheduling • Two-level Static cycle and RM based priority scheduling • Partition Inversion and Solution • Virtual Aperiodic Partition • Interrupt handling • Virtual Interrupt Partition • Timer Virtualization • I/O Virtualization • CPU Virtualization • Memory Virtualization and Inter- Partition Communication • Implementation • Conclusions and Further Work

  26. Interrupt Handling • Requirement: To guarantee min. ‘n’ number of interrupts, in a particular partition will be served with bounded delay at any given point of time • Proposed Approach: Virtual Interrupt Partition(VIP) • Separate partition which is assigned processor capacity and partition cycle according to interrupt characteristics • Interrupts are served when VIP has budget otherwise deferred till next replenishment • Static Cycle Scheduling • RM based priority scheduling

  27. Timer Virtualization • Issues • Maintaining time in deactivated partition • Guest RTOSs sharing same timer device demand different timer resolution

  28. Timer Virtualization • Our Approach: Paravirtualization • No virtual interrupt generation for deactivated partition • Update real time in guest RTOS when scheduled • Timer interrupt delivery to active partition • Sudden increase in time but fine if tasks are schedulable • Simple with lesser overhead

  29. Outline • Introduction • Focus of the Work and Motivation • Contributions • SParK/SCOS: System Requirements • SParK: System Architecture • SParK: Design Issues • Scheduling • Two-level Static cycle and RM based priority scheduling • Partition Inversion and Solution • Virtual Aperiodic Partition • Interrupt handling • Virtual Interrupt Partition • Timer Virtualization • CPU Virtualization • I/O Virtualization • Memory Virtualization and Inter- Partition Communication • Implementation • Conclusions and Further Work

  30. CPU Virtualization • Challenges • Non –virtualizable CPU architecture • Instructions which do not trap when run in unprivileged mode (POPF) • Unprivileged instructions let the CPU access privileged state • Techniques • Full Virtualization • On-fly binary translation • Paravirtualization • Replacement of problematic instruction

  31. CPU Virtualization • Our Approach: Paravirtualization • Emulation for privileged instruction in SParK for guest RTOS • Replacement of non-virtualizable instruction by hypercalls • Trap source Identification • Memory Location Trekking • SParK in ring 0 and Guest OS in ring 1 and user application in ring 3

  32. I/O Virtualization • Issues • One device, multiple drivers results in inconsistent device state • Device driver’s location • If in SParK, fault containment violated • If in guest RTOS, mechanism to service other partition's • Accounting time for device access • I/O virtualization technique should also ensure • Fault Containment • Isolation • Responsiveness • Unmodified Device Driver Reuse • SParK’s simplicity

  33. I/O Virtualization • Our Approach: Split Driver Architecture

  34. Memory Virtualization • Issues • Spatial Partition among partitions • No interference to SParK • Architecture specific • Our Approach • Static memory allocation using segmentation at compile time for all the partition

  35. Inter-partition Communication • Issues • Safe communication mechanism to satisfy isolation among partitions. • Minimum SParK’s involvement to reduce overhead • Our Approach • Asynchronous notification through event channel • Shared page for data transfer and information of grated page kept in SParK • Budget accounted on requesting partition

  36. Outline • Introduction • Focus of the Work and Motivation • Contributions • SParK/SCOS: System Requirements • SParK: System Architecture • SParK: Design Issues • Scheduling • Two-level Static cycle and RM based priority scheduling • Partition Inversion and Solution • Virtual Aperiodic Partition • Interrupt handling • Virtual Interrupt Partition • Timer Virtualization • CPU Virtualization • I/O Virtualization • Memory Virtualization and Inter- Partition Communication • Implementation • Conclusions and Further Work

  37. Implementation • Priority inheritance (changes in synchronization primitives) • Serial Port Driver • Interrupt Server • Two-level Hierarchical scheduling • Static Cycle Driven • Budget Lending • Dynamic EDF based

  38. Outline • Introduction • Focus of the Work and Motivation • Contributions • SParK/SCOS: System Requirements • SParK: System Architecture • SParK: Design Issues • Scheduling • Two-level Static cycle and RM based priority scheduling • Partition Inversion and Solution • Virtual Aperiodic Partition • Interrupt handling • Virtual Interrupt Partition • Timer Virtualization • CPU Virtualization • I/O Virtualization • Memory Virtualization and Inter- Partition Communication • Implementation • Conclusions and Further Work

  39. Conclusion • We presented complete design of SParK • We proposed: • Modifications in virtual machine techniques for virtualizing resources to meet real-time constraints • RM based preemptive priority partition scheduling • Modifications in integrated real-time scheduling algorithms to consider non-preemptable section • Virtual Interrupt Partition • Virtual Aperiodic Partition • We implemented in SARTL • Two-level static cyclic scheduler • Two-level dynamic scheduler • Interrupt Server • Priority Inheritance • Serial Port driver

  40. Future Work • Look into architecture specific issues for memory allocation and other hardware initialization • Implementation of various hypercalls to act as interface between guest RTOS and SParK • Porting guest RTOS to SParK by replacing problematic instructions in it by appropriate hypercalls • Front-end device drivers for guest RTOSs • Ethernet driver for Stand-Alone RTLinux towards building SCOS • Prototype Implementation of SParK

  41. References • Daeyoung Kim. Strongly Partitioned System Architecture For Integration Of Real-Time Applications. PhD thesis, UNIVERSITY OF FLORIDA, 2001 • Zhong Deng, Jane W.-S. Liu, Lynn Zhang, Seri Mouna, and Alban Frei. An open environment for real-time applications. Real-Time Systems, 16(2-3):155{185, 1999 • Mendel Rosenblum and Tal Garnkel. Virtual machine monitors: Current technology and future trends. IEE Computer Magazine, May 2005 • Tullio Facchinetti, Giorgio Buttazzo, Mauro Marinoni, and Giacomo Guidi. Non-preemptive interrupt scheduling for safe reuse of legacy drivers in real-time systems. In ECRTS '05, pages 98-105, Washington, DC, USA, 2005. IEEE Computer Society • Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, and Andrew Wareld. Xen and the art of virtualization. In SOSP '03, pages 164{177, New York, NY, USA, 2003. ACM Press

  42. Timer Virtualization • Full Virtualization: • Virtual interrupt generation • VM Time tracker • Fast Catchup • Time synchronization tool when fast catchup is impossible

  43. I/O Virtualization

  44. VM Environment Vs SParK

  45. Comparison of RTOS

  46. Comparison of various scheduling policies

More Related