1 / 48

Composability and Schedulability of Real-Time Applications in Open Environments

Composability and Schedulability of Real-Time Applications in Open Environments. Nathan Fisher Department of Computer Science Wayne State University. Outline. Background : Real-Time Systems. Scheduling Algorithms. Open Environments. Prior Work . Our Results :

theresa
Télécharger la présentation

Composability and Schedulability of Real-Time Applications in Open Environments

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. Composability and Schedulability of Real-TimeApplications in Open Environments Nathan Fisher Department of Computer Science Wayne State University

  2. Outline • Background: • Real-Time Systems. • Scheduling Algorithms. • Open Environments. • Prior Work. • Our Results: • Framework for real-time applications in an open environments. • Validation Tests: Composability & Schedulability • Open Questions & Summary. • “Shameless” Plugs.

  3. What is a Real-Time System? • System Correctness: • Logical. • Temporal. • Predictability is more important than performance. Do all system computations satisfy associated temporal constraints? Background– Prior Work– Our Results– Open Questions

  4. Examples of Real-Time Systems • Real-Time System Examples: • Safety Critical: • Avionic control, power plants, automotive, medical devices, robotics … • Consumer Electronics: • Cellular phones, MP3 players, digital video devices,… • Networking: • Multimedia streams, QoS constraints, network processing,… • … Background– Prior Work– Our Results– Open Questions

  5. Example: Air Traffic-Flight Control sampling rates may be minutes or even hours commands responses operator-system interface  state estimator air traffic control from sensors • Control Subsystem/Application: • set timer to interrupt periodically with period T; • at each timer interrupt do • do analog-to-digital conversion to get input sample y; • compute control outputu; • output u and do digital-to-analog conversion; • od virtual plant navigation  flight management state estimator virtual plant  flight control state estimator sampling rates may be secs. or msecs. air data physical plant Background– Prior Work– Our Results– Open Questions

  6. Modeling a Real-Time System • Processing platform. • Uniprocessor. • Unit speed: • (one unit of execution) per (one unit of time). Background– Prior Work– Our Results– Open Questions

  7. time Modeling a Real-Time System • Processing platform. • Real-Time workload: • Job: basic unit of work. • Characterized by: • Arrival-time. • Deadline. • Worst-case execution time. • Preemptable. Background– Prior Work– Our Results– Open Questions

  8. time Modeling a Real-Time System • Processing platform. • Real-Time workload: • Job: basic unit of work. • Characterized by: • Arrival-time. • Deadline. • Worst-case execution time. • Preemptable. • Tasks: Recurrent set of jobs. Background– Prior Work– Our Results– Open Questions

  9. Period: invocation interval. Job: control invocation. time 40 10 20 30 0 Task A Tasks: Recurrent Jobs Task A • Control-Subsystem Process A: • set timer to interrupt periodically with period pA; • at each timer interrupt do • do analog-to-digital conversion to get input sample y; • compute control outputu; • output u and do digital-to-analog conversion; • od Period = 15 Background– Prior Work– Our Results– Open Questions

  10. time time 40 40 10 10 20 20 30 30 0 0 Task A Task B Tasks: Recurrent Jobs Task A Task B • Control-Subsystem Process A: • set timer to interrupt periodically with period pA; • at each timer interrupt do • do analog-to-digital conversion to get input sample y; • compute control outputu; • output u and do digital-to-analog conversion; • od • Control-Subsystem Process B: • set timer ….period pb • at each timer interrupt do • ….. • od Period = 30 Period = 15 Background– Prior Work– Our Results– Open Questions

  11. (ei) (ei) (ei) (ei) (ei) 0 2pi 4pi pi 3pi A Formal Model: Sporadic Task Model Worst case Execution Requirement Period Relative Deadline i = (ei,di,pi) time Task Systems of n tasks:  = {1,…, n} Background– Prior Work– Our Results– Open Questions

  12. Modeling a Real-Time System • Processing platform. • Real-time workload. • Scheduling algorithm: • Earliest-Deadline-First (EDF): schedule the job with the nearest absolute deadline. • Rate-Monotonic (RM): assign each task i priority equal to 1/pi (greater number  greater priority); schedule the job with greatest priority. Background– Prior Work– Our Results– Open Questions

  13. 2 2 Scheduling Algorithms i = (ei,di,pi) 1= (2, 4, 4) =  2= (3, 7, 7) = 1 1 EDF 7 8 6 0 1 2 3 4 5 time RM 7 8 6 0 1 2 3 4 5 Background– Prior Work– Our Results– Open Questions time

  14. Y,  is schedulable by A on P. N,  is not schedulable by A on P. Verification of a Real-Time System • Given a real-time system specified by: • Processing platform: P. • Real-time workload: . • Scheduling Algorithm: A. • Schedulability Analysis: determine whether all jobs generated by task system  meet all deadlines on P when scheduled according to A. Schedulability Test <P,,A> Background– Prior Work– Our Results– Open Questions

  15. Known Verification Techniques i = (ei,di,pi) For EDF-scheduled systems: For RM-scheduled systems: Theorem: Task system  will always meet all deadlines on a uniprocessor platform when scheduled by EDF, if and only if for all t > 0, Theorem: Task system  will always meet all deadlines on a uniprocessor platform when scheduled by RM, if and only if for all i and integers k>0, Background– Prior Work– Our Results– Open Questions

  16. Traditional Real-Time System Design Approach: • Determine, for every process of every system application, temporal requirements (i.e., period, execution time, etc.). • Specify each process in a task model (e.g., sporadic task model). • Verify temporal correctness of all tasks using schedulability analysis techniques. Assumption: All processes of all real-time applications have been developed together and are known by the system designer. Background– Prior Work– Our Results– Open Questions

  17. Traditional Real-Time System Design commands responses Consider our air-traffic control example… operator-system interface  All subsystems validated together state estimator air traffic control from sensors virtual plant navigation Common Platform  flight management state estimator 1 2 3 virtual plant  4 5 flight control state estimator air data physical plant Background– Prior Work– Our Results– Open Questions

  18. Traditional Real-Time System Design • Violation of System Design Principles: • Encapsulation, Abstraction, & Dynamic Extensibility. • Modularity & Hierarchical Design. • Fault-containment. Drawbacks: • All tasks in the system need to be validated together and known to system designer, a priori. • Monolithic system design. • Each application on shared platform must use same scheduling algorithm. • Temporally-bad behavior of one task may affect other tasks. Solution? Background– Prior Work– Our Results– Open Questions

  19. Real-Time Open Environments • Framework for composing real-time applications: • Each application may be independently developed and verified. • Each application runs inside a server which has local scheduler. • Single interface expresses temporal requirements of application’s server which is scheduled by global scheduler. • System uses composability test to determine whether applications can be co-executed on same platform. Background– Prior Work– Our Results– Open Questions

  20. Real-Time Open Environments A1’s server Multiple independently-developed, real-time applications co-execute upon shared platform: I1 A1: 1 global scheduler Local Scheduler 2 CPU A2: 1 I2 3 Local Scheduler 2 … Iq Aq: 1 Local Scheduler Roughly speaking, A1, A2, …, Aq are composable if 2 Background– Prior Work– Our Results– Open Questions

  21. Traditional Real-Time System Design commands responses operator-system interface  state estimator air traffic control from sensors virtual plant navigation Common Platform  flight management state estimator 1 2 3 A1 virtual plant  4 5 A2 flight control state estimator air data physical plant Background– Prior Work– Our Results– Open Questions

  22. Real-Time Open Environment Design Approach (for an application): • Determine, for every process of application, temporal requirements. • Specify each process in a task model (e.g., sporadic task model). • Define server interface for application. • Verify temporal correctness of all tasks in application server using schedulability analysis techniques. Approach (system-wide): • Verify temporal correctness of all applications via composability test. Background– Prior Work– Our Results– Open Questions

  23. Traditional Real-Time System Design • Adherence to System Design Principles: • Encapsulation, Abstraction, & Dynamic Extensibility. • Modularity & Hierarchical Design. • Fault-containment. Advantages: • Application’s temporal constraints may be validated independently and need not be known a priori. • Component-based design. • Service-oriented design. • Each application on shared platform may use different scheduling algorithm. • Application servers isolate temporally-bad behavior of an application. Background– Prior Work– Our Results– Open Questions

  24. Real-Time Open Environment Design Focus of Remainder of talk Approach (for an application): • Determine, for every process of application, temporal requirements. • Specify each process in a task model (e.g., sporadic task model). • Define server interface for application. • Verify temporal correctness of all tasks in application server using schedulability analysis techniques. Approach (system-wide): • Verify temporal correctness of all applications via composability test. Background– Prior Work– Our Results– Open Questions

  25. Prior Work • [Deng & Liu, 1997] introduced real-time open environments. • Two-level hierarchy. • EDF Global Scheduler. • Global resources. R1 Executed non-preemptively I1 R1 A1: 1 RM global scheduler Local Scheduler R2 2 CPU … R1 R2 Rm A2: 1 R1 I2 3 Local Scheduler EDF 2 EDF … Iq Aq: 1 R2 Each resource could be device or global data structure. Local Scheduler 2 Static Background – Prior Work– Our Results– Open Questions

  26. Prior Work • [Deng & Liu, 1997] introduced real-time open environments. • Two-level hierarchy. • EDF Global Scheduler. • Global resources. R1 I1 R1 A1: 1 RM Interface Ii for each Application Server Ai: • i: “speed” of server. • i: maximum delay tolerable. • i: maximum non-preemptive resource lock. • i: length of shortest relative deadline in Ai. Local Scheduler R2 2 A2: 1 R1 I2 3 Local Scheduler 2 EDF … Iq Aq: 1 R2 Local Scheduler 2 Ii < i, i, i, i> Static Background – Prior Work– Our Results– Open Questions

  27. Prior Work Ii < i, i, i, i> • [Deng & Liu, 1997] introduced real-time open environments. • Two-level hierarchy. • EDF Global Scheduler. • Global resources. Theorem: Applications A1, A2, …, Aq are composable if, Drawbacks: • Only two levels possible. • Composability test provably non-optimal in the presence of global resources. Background – Prior Work– Our Results– Open Questions

  28. Prior Work • [Feng & Mok, 2002] Bounded-Delay Resource Partition. • Unlimited hierarchal levels. • EDF or RM Global Scheduler. • Global resources. R1 Executed non-preemptively I1 R1 A1: 1 global scheduler Local Scheduler R2 2 CPU … R1 R2 Rm A2: 1 R1 I2 3 Local Scheduler 2 … Iq Aq: 1 R2 Local Scheduler 2 Background – Prior Work– Our Results– Open Questions

  29. Prior Work • [Feng & Mok, 2002] Bounded-Delay Resource Partition. • Unlimited hierarchal levels. • EDF or RM Global Scheduler. • Global resources. A1’ R1 EDF I1 R1 A1: RM global scheduler Local Scheduler R2 2 CPU … R1 R2 Rm A2: 1 R1 I2 3 Local Scheduler EDF or RM 2 EDF … Iq Aq: 1 R2 Local Scheduler Aq’ Static RM Background – Prior Work– Our Results– Open Questions

  30. Prior Work • [Feng & Mok, 2002] Bounded-Delay Resource Partition. • Unlimited hierarchal levels. • EDF or RM Global Scheduler. • Global resources. A1’ R1 EDF I1 R1 A1: RM Interface Ii for each Application Server Ai: • i: “speed” of server. • i: maximum delay tolerable. • i: maximum non-preemptive resource lock. • i: length of shortest relative deadline in Ai. Local Scheduler R2 2 A2: 1 R1 I2 3 Local Scheduler 2 EDF … Iq Aq: 1 R2 Local Scheduler Ii < i, i, i > Aq’ Static RM Background – Prior Work– Our Results– Open Questions

  31. Prior Work Ii < i, i, i > • [Feng & Mok, 2002] Bounded-Delay Resource Partition. • Unlimited hierarchal levels. • EDF or RM Global Scheduler. • Global resources. Theorem: Applications A1, A2, …, Aq are composable (without resources) if, Drawbacks: • Composability test provably non-optimal in the presence of global resources. Background – Prior Work– Our Results– Open Questions

  32. Prior Work Drawback: Resource-Sharing Composability test provably non-optimal in the presence of global resources. Resource unlocked. Resource locked. Deadline miss! Non-optimality at application level. Ai 1 EDF 2 7 8 9 6 0 1 2 3 4 5 time 1= (2, 3, 3) =  i = (ei,di,pi) 2= (3, 9, 9) = R1 Background – Prior Work– Our Results– Open Questions

  33. Prior Work Drawback: Resource-Sharing Composability test provably non-optimal in the presence of global resources. Also, on the system-wide level, an application can unnecessarily block another application. Background – Prior Work– Our Results– Open Questions

  34. Our results: Goals Design an open environment server framework to: • Obtain optimal behavior in the presence of global resources. • Derive effective composability test. • Derive effective schedulability test for applications. Background – Prior Work– Our Results– Open Questions

  35. Our Results: Bounded-Delay Resource Open Environment (BROE) Server • [Fisher, Bertogna, & Baruah, 2007] • Unlimited hierarchal levels. • EDF Global Scheduler. • Global resources. A1: A1’ R1 EDF Local Scheduler 2 R1 RM Allow for preemptive execution, if needed. I1 3 R2 global scheduler A2: 1 R1 CPU Local Scheduler … R1 R2 Rm 2 EDF I2 … EDF Aq: 1 R2 Local Scheduler Iq Aq’ Static RM Background – Prior Work– Our Results– Open Questions

  36. Our Results: Bounded-Delay Resource Open Environment (BROE) Server • [Fisher, Bertogna, & Baruah, 2007] • Unlimited hierarchal levels. • EDF Global Scheduler. • Global resources. A1: A1’ R1 EDF Local Scheduler 2 R1 RM I1 3 R2 Interface Ii for each Application Server Ai: • i: “speed” of server. • i: maximum delay tolerable. • Hi: maximum preemptive resource-holding time. A2: 1 R1 Local Scheduler 2 EDF I2 … Aq: 1 R2 Local Scheduler Iq Ii  < i, i, Hi > Aq’ Static RM Background – Prior Work– Our Results– Open Questions

  37. Our Results: Bounded-Delay Resource Open Environment (BROE) Server Server Rules: • Each server maintains budget, replenishmentperiod, and current deadline. • Similar to sporadic task. • “Normal” replenishment period: • Maximum Budget: Ii  < i, i, Hi > i For all intervals of size t > i, execution over interval should be at least (t-i ) i Background – Prior Work– Our Results– Open Questions

  38. Our Results: Bounded-Delay Resource Open Environment (BROE) Server Server Rules: • Each server maintains budget, replenishmentperiod, and current deadline. • If server is executing budget is decremented at rate 1/i. Ii  < i, i, Hi > Budget 0 time Background – Prior Work– Our Results– Open Questions

  39. Our Results: Bounded-Delay Resource Open Environment (BROE) Server Server Rules: • Each server maintains budget, replenishmentperiod, and current deadline. • If server is executing budget is decremented at rate 1/i. • If task of Ai requests resource when Ei < Hi, then defer execution and update replenishment time & next deadline: Ii  < i, i, Hi > i Task requests Rj, but Ei < Hi Access to Rj is granted here Execution over interval > (t- i)i Background – Prior Work– Our Results– Open Questions

  40. Our results: Goals Design an open environment server framework to: • Obtain optimal behavior in the presence of global resources. • Derive effective composability test. • Derive effective schedulability test for applications. Background – Prior Work– Our Results– Open Questions

  41. Our results: Goals Design an open environment server framework to: • Obtain optimal behavior in the presence of global resources. • BROE-Server Properties: • Executing resources preemptively reduces deadline misses within an application. • Deferring an application’s execution of resources prevents blocking between applications. Theorem: If application Ai has been validated independently on processor of speed i and each job completes i prior to its deadline, then it will meet all deadlines on BROE server with interface Ii  < i, i, Hi > executing on a unit-speed processor. Background – Prior Work– Our Results– Open Questions

  42. Our results: Goals Design an open environment server framework to: • Obtain optimal behavior in the presence of global resources. • Derive effective composability test. Theorem: Applications A1, A2, …, Aq under BROE servers are composable on a unit-speed processor if, Background – Prior Work– Our Results– Open Questions

  43. Our results: Goals Design an open environment server framework to: • Obtain optimal behavior in the presence of global resources. • Derive effective composability test. • Derive effective schedulability test for applications. Theorem: An application Ai comprised of sporadic tasks will always meet all deadlines when scheduled by EDF on a BROE Server with interface Ii  < i, i, Hi > , if and only if for all t > 0, Background – Prior Work– Our Results– Open Questions

  44. Interesting Open Questionss • Interface Selection: • What is optimal selection of interface for an application? • What if system designer can lie about interfaces? Can we design mechanisms to induce truthful interfaces? • Multiprocessor/Multicore Open Evironments? • Implementation: • Operating system integration. • AUTOSAR: Automotive Open System Architecture. Optimization Theory Game Theory Parallel & Distributed Systems Background – Prior Work– Our Results– Open Questions

  45. Summary • Traditional real-time analysis violates many software engineering principles. • Real-time Open Environments: • Composability of real-time applications. • Encapsulation, modularity, & fault containment. • Our contribution: • BROE Server. • Optimal under shared resources. • Effective composability & schedulability tests. • PhD thesis topics abound!

  46. “Shameless” Plugs • Winter 2008: Real-Time Systems (CSC 7991) • Topics: • Schedulability analysis, • Resource-sharing, • OS issues, • and much more! • Workload: • 4 Assignments. • Semester-long Project.

  47. “Shameless” Plugs • Open GRA positions for Ph.D. Students: • Theoretical & Implementation problems. • Lots of interesting/relevant open problems. • Travel the world: • Upcoming Real-Time & Distributed Systems Conferences: • Guadeloupe, French West Indies. • Kolkata, India. • Prague, Czech Republic. • Dublin, Ireland. • …

  48. Thank You! Questions?

More Related