Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 of 14 1 /23 Flexibility Driven Scheduling and Mapping for Distributed Real-Time Systems Paul Pop, Petru Eles, Zebo Peng Department of Computer and Information.

Similar presentations


Presentation on theme: "1 of 14 1 /23 Flexibility Driven Scheduling and Mapping for Distributed Real-Time Systems Paul Pop, Petru Eles, Zebo Peng Department of Computer and Information."— Presentation transcript:

1 1 of 14 1 /23 Flexibility Driven Scheduling and Mapping for Distributed Real-Time Systems Paul Pop, Petru Eles, Zebo Peng Department of Computer and Information Science Linköpings universitet, Sweden

2 2 of 14 2 /23 Outline Introduction Incremental design process Mapping and scheduling Problem formulation Mapping strategy Experimental results Conclusions

3 3 of 14 3 /23 Introduction Characteristics: Incremental design process, engineering change; Distributed real-time embedded systems; Heterogeneous architectures; Fixed priority pre-emptive scheduling for processes; static cyclic scheduling for messages; Communications using a time-division multiple-access (TDMA) scheme: H. Kopetz, G. Grünsteidl. TTP-A Protocol for Fault-Tolerant Real-Time Systems. IEEE Computer ‘94. Contributions: Mapping and scheduling considered inside an incremental design process; Two design criteria (and their metrics) that drive our mapping strategies to solutions supporting an incremental design process; Two mapping algorithms. Message: Engineering change can be successfully addressed at system level.

4 4 of 14 4 /23 “Classic” Mapping and Scheduling I/O Interface Comm. Controller CPU RAM ROM ASIC S0S0 S1S1 S2S2 S3S3 S0S0 S1S1 S2S2 S3S3 TDMA Round Cycle of two rounds Slot

5 5 of 14 5 /23 Start from an already existing system with applications: In practice, very uncommon to start from scratch. Implement new functionality on this system (increment): As few as possible modifications of the existing applications, to reduce design and testing time; Plan for the next increment: It should be easy to add functionality in the future. Incremental Design Process

6 6 of 14 6 /23 Mapping and Scheduling No modifications are performed to the existing applications. Existing applications N-1 Map and schedule so that the future applications will have a chance to fit. Current applications N Do not exist yet at Version N! Future applications Version N+1

7 7 of 14 7 /23 Mapping and Scheduling Example Processor Bus Current appsFuture appsExisting applications P3P3 P4P4 m4m4 m5m5 P1P1 P2P2 m1m1 m2m2 m3m3

8 8 of 14 8 /23 Mapping and Scheduling Example, Cont. Processor Bus Current appsFuture appsExisting applications P3P3 P4P4 m4m4 m5m5 P1P1 P2P2 m1m1 m2m2 m3m3

9 9 of 14 9 /23 Mapping and Scheduling Example, Cont. Processor Bus Current appsFuture appsExisting applications P4P4 P3P3 m4m4 m5m5 P2P2 P1P1 m1m1 m2m2 m3m3

10 10 of 14 10 /23 Problem Formulation Input A set of existing applications modelled as process sets. A current application to be mapped. Each process in the application has its own period, priority and deadline. Each process has a potential set of nodes to be mapped to and a WCET. The system architecture is given. Output A mapping and scheduling of the current application, so that: Requirement a: constraints of the current application are satisfied and minimal modifications are performed to the existing applications. Requirement b: new future applications can be mapped on the resulted system.

11 11 of 14 11 /23 Mapping and Scheduling, Requirement a) Mapping and scheduling of the current application, so that: Constraints of the current application are satisfied and minimal modifications are performed to the existing applications. Subset selection problem S elect that subset  of existing applications which guarantees that the current application fits and the modification cost R(  ) is minimized:

12 12 of 14 12 /23 Characterizing Existing Applications R({  7 })=20, R({  3 })=50, R({  3,  7 })=70, R({  4,  7 })=90 (the inclusion of  4 triggers the inclusion of  7 ), R({  2,  3 })=120, R({  3,  4,  7 })=140, R({  1 })=150,.... The total number of possible subsets is 16. 11 22 44 55 66 77 33 88 99  10 11 22 44 55 66 77 33 88 99 150 70 50 20

13 13 of 14 13 /23 Mapping and Scheduling, Requirement b) Mapping and scheduling of the current application, so that: New future applications can be mapped on the resulted system. P4P4 m5m5 Design criteria reflect the degree to which a design meets the requirement b); Design metrics quantify the degree to which the criteria are met; Heuristics to improve the design metrics.

14 14 of 14 14 /23 Typical utilization factors U f =C/T Probability [%] Characterizing Future Applications  Smallest expected period T min  Expected necessary bandwidth b need Probability [%] Typical message sizes [bytes]

15 15 of 14 15 /23 Mapping and Scheduling: Processes Design criterion for processes: available utilization How well the available utilization of the current design alternative accommodate a family of future applications that are characterized as outlined before; Design metrics for the first design criterion C 1 P for processes How much of the largest future application (total available utilization), cannot be mapped on the current design alternative; Bin-packing algorithm using the best-fit policy: utilization factors of processes as objects to be packed, and the slack as containers. C 1 P =40%

16 16 of 14 16 /23 Mapping and Scheduling: Messages First design criterion for messages: slack sizes How well the slack sizes of the current design alternative accommodate a family of future applications that are characterized as outlined before; Tries to cluster the available slack: the best slack would be a contiguous slack. a) b) c) contiguous slack Design metrics for the first design criterion C 1 m for messages; How much of the largest future application (contiguous slack), cannot be mapped on the current design alternative; Bin-packing algorithm using the best-fit policy: processes as objects to be packed, and the slack as containers. C 1 m =0% C 1 m =75%

17 17 of 14 17 /23 Mapping and Scheduling: Messages, Cont. Second design criterion: slack distribution for messages Used for the reduction of design space exploration How well the slack of the current design alternative is distributed in time to accommodate the messages of a family of future applications; Tries to distribute the slack so that we periodically (T min ) have enough necessary bandwith b need for the most demanding future application. a) b) T min Design metrics for the second design criterion C 2 m is the sum of minimum periodic slack inside a T min period on each processor. C 2 m =0 < b need =40ms C 2 m =40 ms b need

18 18 of 14 18 /23 Mapping and Scheduling Strategy Initial mapping and scheduling Requirement a) Minimizing the modification cost R(  ), subset selection: Exhaustive Search (ES) Ad-Hoc Solution (AH) Subset Selection Heuristic (SH) Requirement b) Starting from a valid solution, heuristics to minimize the objective function: Ad-Hoc approach (AH), little support for incremental design. Simulated Annealing (SA), near optimal value for C. Mapping Heuristic (MH): Iteratively performs design transformations that improve the design; Examines only transformations with the highest potential to improve the design; Design transformations: moving a process to a different processor, moving a message to a different slack on the bus.

19 19 of 14 19 /23 Average Modification Cost R(  min ) How do the subset selection algorithms compare? existing applications: 400 Number of processes in the current application Experimental Results

20 20 of 14 20 /23 Avg. % Deviation from near optimal How does the quality (cost function) of the mapping heuristic (MH) compare to the ad-hoc approach (AM) and the simulated annealing (SA)? existing applications: 400 Number of processes in the current application Experimental Results

21 21 of 14 21 /23 Experimental Results, Cont. % of future applications mapped existing applications: 400, future application: 80 Number of processes in the current application Are the mapping strategies proposed facilitating the implementation of future applications? Existing application Current application Future application No modifications allowed

22 22 of 14 22 /23 Experimental Results, Cont. % of future applications mapped existing applications: 400, future application: 80 Number of processes in the current application Are the mapping strategies proposed facilitating the implementation of future applications? Existing application Current application Future application Modifications allowed

23 23 of 14 23 /23 Conclusions Distributed real-time embedded systems Fixed priority pre-emptive scheduling for processes Static cyclic scheduling for messages (TDMA) Mapping and scheduling considered inside an incremental design process Constraints of the current application are satisfied and minimal modifications are performed to the existing applications New future applications can be mapped on the resulted system Mapping strategy Design criteria+metrics which drive mapping strategies to solutions supporting an incremental design process Iterative improvement mapping algorithm; subset selection algorithm


Download ppt "1 of 14 1 /23 Flexibility Driven Scheduling and Mapping for Distributed Real-Time Systems Paul Pop, Petru Eles, Zebo Peng Department of Computer and Information."

Similar presentations


Ads by Google