1. Composability and Schedulability of Real-Time Applications 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 state estimator state estimator state estimator    air traffic control flight management flight control air data navigation virtual plant operator-system interface physical plant from sensors responses commands sampling rates may be minutes or even hours sampling rates may be secs. or msecs. Control Subsystem/Application: set timer to interrupt periodically with period T; at each timer interrupt do 1.do analog-to-digital conversion to get input sample y; 2.compute control output u; 3.output u and do digital-to-analog conversion; od Control Subsystem/Application: set timer to interrupt periodically with period T; at each timer interrupt do 1.do analog-to-digital conversion to get input sample y; 2.compute control output u; 3.output u and do digital-to-analog conversion; od 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. 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. time Background – Prior Work– Our Results– Open Questions

8. 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. time Background – Prior Work– Our Results– Open Questions

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

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

11. (e i ) 0 pipi 2p i 3p i 4p i  i = (e i,d i,p i ) time A Formal Model: Sporadic Task Model Relative Deadline Period Worst case Execution Requirement 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/p i (greater number  greater priority); schedule the job with greatest priority. Background – Prior Work– Our Results– Open Questions

13. Scheduling Algorithms  i = (e i,d i,p i )  1 = (2, 4, 4) =  2 = (3, 7, 7) =  EDF 22 0 12345 6 7 8 time 11 22 0 12345 6 7 8 11 RM Background – Prior Work– Our Results– Open Questions

14. 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. <P,,A><P,,A> Y,  is schedulable by A on P. Schedulability Test N,  is not schedulable by A on P. Background – Prior Work– Our Results– Open Questions

15. Known Verification Techniques 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,  i = (e i,d i,p i ) Background – Prior Work– Our Results– Open Questions

16. Traditional Real-Time System Design Approach: 1.Determine, for every process of every system application, temporal requirements (i.e., period, execution time, etc.). 2.Specify each process in a task model (e.g., sporadic task model). 3.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. Common Platform Traditional Real-Time System Design state estimator state estimator state estimator    air traffic control flight management flight control air data navigation virtual plant operator-system interface physical plant from sensors responses commands Consider our air-traffic control example… 11 22 33 44 55 All subsystems validated together Background – Prior Work– Our Results– Open Questions

18. Traditional Real-Time System Design Drawbacks: 1.All tasks in the system need to be validated together and known to system designer, a priori. Monolithic system design. 2.Each application on shared platform must use same scheduling algorithm. 3.Temporally-bad behavior of one task may affect other tasks. Violation of System Design Principles: Encapsulation, Abstraction, & Dynamic Extensibility. Modularity & Hierarchical Design. Fault-containment. 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. Multiple independently-developed, real- time applications co-execute upon shared platform: CPU global scheduler A1:A1: Local Scheduler 1111 2222 3333 Real-Time Open Environments A2:A2: Local Scheduler 1111 2222 Aq:Aq: Local Scheduler 1111 2222 … I1I1 I2I2 IqIq Roughly speaking, A 1, A 2, …, A q are composable if A 1 ’s server Background – Prior Work– Our Results– Open Questions

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

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

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

24. Real-Time Open Environment Design Approach (for an application): 1.Determine, for every process of application, temporal requirements. 2.Specify each process in a task model (e.g., sporadic task model). 3.Define server interface for application. 4.Verify temporal correctness of all tasks in application server using schedulability analysis techniques. Approach (system-wide): 1.Verify temporal correctness of all applications via composability test. Focus of Remainder of talk 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. CPU global scheduler A1:A1: Local Scheduler 1111 2222 3333 A2:A2: Local Scheduler 1111 2222 Aq:Aq: Local Scheduler 1111 2222 … R1R1R1R1 R2R2R2R2 RmRmRmRm … EDF R 1 R 2 Each resource could be device or global data structure. RM EDF Static I1I1 I2I2 IqIq Executed non- preemptively 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. A1:A1: Local Scheduler 1111 2222 3333 A2:A2: Local Scheduler 1111 2222 Aq:Aq: Local Scheduler 1111 2222 … R 1 R 2 RM EDF Static I1I1 I2I2 IqIq Interface I i for each Application Server A i :  i : “speed” of server.  i : maximum delay tolerable.  i : maximum non- preemptive resource lock.  i : length of shortest relative deadline in A i. I i  Background – Prior Work– Our Results– Open Questions

27. Prior Work [Deng & Liu, 1997] introduced real-time open environments. Two-level hierarchy. EDF Global Scheduler. Global resources. Drawbacks: 1.Only two levels possible. 2.Composability test provably non-optimal in the presence of global resources. I i  Theorem: Applications A 1, A 2, …, A q are composable if, 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. CPU global scheduler A1:A1: Local Scheduler 1111 2222 3333 A2:A2: Local Scheduler 1111 2222 Aq:Aq: Local Scheduler 1111 2222 … R1R1R1R1 R2R2R2R2 RmRmRmRm … R 1 R 2 I1I1 I2I2 IqIq Executed non- preemptively 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. CPU global scheduler A1:A1: Local Scheduler 2222 3333 A2:A2: Local Scheduler 1111 2222 Aq:Aq: Local Scheduler 1111 … R1R1R1R1 R2R2R2R2 RmRmRmRm … EDF or RM R 1 R 2 RM EDF Static I1I1 I2I2 A1’A1’ IqIq R 1 Aq’Aq’ EDF 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:A1: Local Scheduler 2222 3333 A2:A2: Local Scheduler 1111 2222 Aq:Aq: Local Scheduler 1111 … R 1 R 2 RM EDF Static I1I1 I2I2 A1’A1’ IqIq R 1 Aq’Aq’ EDF RM Interface I i for each Application Server A i :  i : “speed” of server.  i : maximum delay tolerable.  i : maximum non- preemptive resource lock.  i : length of shortest relative deadline in A i. I i  Background – Prior Work– Our Results– Open Questions

31. Prior Work [Feng & Mok, 2002] Bounded- Delay Resource Partition. Unlimited hierarchal levels. EDF or RM Global Scheduler. Global resources. Drawbacks: 1.Composability test provably non-optimal in the presence of global resources. I i  Theorem: Applications A 1, A 2, …, A q are composable (without resources) if, Background – Prior Work– Our Results– Open Questions

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

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

34. Our results: Goals 1. Obtain optimal behavior in the presence of global resources. 2. Derive effective composability test. 3. Derive effective schedulability test for applications. Design an open environment server framework to: 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. CPU global scheduler A1:A1: Local Scheduler 2222 3333 A2:A2: Local Scheduler 1111 2222 Aq:Aq: Local Scheduler 1111 … R1R1R1R1 R2R2R2R2 RmRmRmRm … EDF R 1 R 2 RM EDF Static I1I1 I2I2 A1’A1’ IqIq R 1 Aq’Aq’ EDF RM Allow for preemptive execution, if needed. 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: Local Scheduler 2222 3333 A2:A2: Local Scheduler 1111 2222 Aq:Aq: Local Scheduler 1111 … R 1 R 2 RM EDF Static I1I1 I2I2 A1’A1’ IqIq R 1 Aq’Aq’ EDF RM Interface I i for each Application Server A i :  i : “speed” of server.  i : maximum delay tolerable. H i : maximum preemptive resource-holding time. I i  Background – Prior Work– Our Results– Open Questions

37. Our Results: Bounded-Delay Resource Open Environment (BROE) Server I i  Server Rules: 1. Each server maintains budget, replenishment period, and current deadline. Similar to sporadic task. “Normal” replenishment period: Maximum Budget: i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 I i  Server Rules: 1. Each server maintains budget, replenishment period, and current deadline. 2. If server is executing budget is decremented at rate 1/  i. Budget time 0 Background – Prior Work– Our Results– Open Questions

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

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

41. Our results: Goals 1. 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 A i 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 I i  executing on a unit-speed processor. Design an open environment server framework to: Background – Prior Work– Our Results– Open Questions

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

43. Our results: Goals 1. Obtain optimal behavior in the presence of global resources. 2. Derive effective composability test. 3. Derive effective schedulability test for applications. Theorem: An application A i comprised of sporadic tasks will always meet all deadlines when scheduled by EDF on a BROE Server with interface I i , if and only if for all t > 0, Design an open environment server framework to: 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?