Analysis and Synthesis of Communication-Intensive Heterogeneous Real-Time Systems Paul Pop Computer and Information Science Dept. Linköpings universitet 1 of 14 1
Outline � Introduction � System-level design and modeling � Conditional process graph � The system platform � Time-driven vs. event-driven systems Communication-intensive heterogeneous real-time systems � � Time-driven systems � Scheduling and bus access optimization � Incremental mapping � Event-driven systems � Schedulability analysis and bus access optimization � Incremental mapping � Multi-Cluster Systems � Schedulability analysis and bus access optimization � Frame packing Summary of contributions � 2 of 14 2
Embedded Systems General purpose systems Embedded systems Microprocessor market shares 99% 1% Communication-intensive heterogeneous real-time systems 3 of 14 3
Embedded Systems Characteristics � Dedicated functionality (not general purpose computers) � Embedded into a host system � Complex architectures � Embedded systems design constraints � Correct functionality � Performance, timing constraints: real-time systems � Development cost, unit cost, size, power, flexibility, time-to- prototype, time-to-market, maintainability, correctness, safety, etc. � Difficult to design, analyze and implement � System-level design � Reuse and flexibility 4 of 14 4
System-Level Design System specification In this thesis System-level Scheduling � design tasks Bus access optimization � Mapping � Software Hardware model model Software Hardware generation synthesis Software Hardware blocks blocks Prototype Fabrication 5 of 14 5
Application Modeling #1 P 0 P 1 P 11 P 1 P 11 D D P 2 P 3 P 2 P 3 C C C P 12 P 13 P 12 P 13 P 6 P 6 K K P 4 P 5 P 4 P 5 P 14 P 16 P 14 P 16 P 8 P 9 P 15 P 8 P 9 P 15 P 7 P 7 P 17 P 17 P 10 P 10 � First processor � Second processor � ASIC P 18 6 of 14 6
Application Modeling #2 Subgraph corresponding to P 0 P 0 D ∧ C ∧ K P 1 P 11 P 1 P 11 P 1 P 11 D D P 2 P 3 P 2 P 3 P 2 P 3 C C C P 12 P 12 P 13 P 12 P 13 P 6 P 6 P 6 K K P 4 P 5 P 4 P 5 P 14 P 16 P 14 P 16 P 14 P 16 P 8 P 9 P 8 P 9 P 15 P 8 P 9 P 15 P 7 P 7 P 17 P 17 P 10 P 17 P 10 P 10 � First processor � Second processor � ASIC P 18 P 18 7 of 14 7
Hardware Platform Cluster: ... one network I/O Interface RAM ... Gateway ROM CPU ASIC Comm. controller ... Time Triggered Protocol ( TTP ) Controller Area Network ( CAN ) Bus access scheme: � Priority bus, collision avoidance � time-division multiple-access (TDMA) Highest priority message � Schedule table located in each TTP � wins the contention controller: message descriptor list (MEDL) Priorities encoded in the frame identifier � S 0 S 1 S 2 S G S 0 S 1 S 2 S G Slot TDMA Round Cycle of two rounds 8 of 14 8
Distributed Safety-Critical Applications � Distributed applications ... � On a single cluster � On several clusters � Motivation � Reduce costs: use resources efficiently ... � Requirements: close to sensors/ actuators � Distributed applications are difficult to... � Analyze (e.g., guaranteeing timing constraints) � Design (e.g., efficient implementation) 9 of 14 9
Event-Driven vs. Time-Driven Systems Event-driven systems � � Activation of processes is done at the occurrence of significant events � Scheduling event-triggered activities � Fixed-priority preemptive scheduling � Response time analysis: calculate worst-case response times for each process � Schedulability test: response times smaller than the deadlines Time-driven systems � � Activation of processes is done at predefined points in time � Scheduling time-triggered activities � Static cyclic non-preemptive scheduling � Building a schedule table: static cyclic scheduling (e.g., list scheduling) 10 10 of 14
Outline Introduction � � System-level design and modeling � Conditional process graph � The system platform � Time-triggered vs. event-triggered Communication-intensive heterogeneous real-time systems � � Time-driven systems � Scheduling and bus access optimization � Incremental mapping � Event-driven systems � Schedulability analysis and bus access optimization � Incremental mapping � Multi-Cluster Systems � Schedulability analysis and bus access optimization � Frame packing Summary of contributions � 11 11 of 14
Scheduling and Bus Access Optimization � Input � Safety-critical application: set of conditional process graphs � The worst-case execution time of each process � The size of each messages � The system architecture and mapping are given � Output � Time-driven systems � Design implementation � Single-cluster architecture such that the application is schedulable � Time-triggered protocol and execution delay is minimized � Non-preemptive static cyclic scheduling � Local schedule tables for each node � The sequence and size of the slots in a TDMA round Communication infrastructure � The MEDL (schedule table for messages) for each parameters TTP controller Time-driven systems 12 12 of 14
Scheduling and Optimization Example P 1 P 4 P 3 P 2 24 ms m 3 m 4 S 1 S 0 m 1 m 2 Round 1 Round 2 Round 3 Round 4 Round 5 P 1 P 1 P 1 P 4 m 1 m 2 P 3 22 ms P 2 m 3 m 4 m 1 S 0 S 1 m 2 Round 1 Round 2 Round 3 Round 4 P 2 P 3 P 2 P 3 P 4 P 1 m 3 m 4 20 ms P 3 P 2 P 4 P 4 m 3 m 4 m 1 m 2 S 0 S 1 Round 1 Round 2 Round 3 Time-driven systems 13 13 of 14
Scheduling and Optimization Strategy List scheduling based algorithm � � The scheduling algorithm has to take into consideration the TTP � Priority function for the list scheduling Bus access optimization heuristics � � Greedy heuristic, two variants � Greedy 1 tries all possible slot lengths � Greedy 2 uses feedback from the scheduling algorithm � Simulated Annealing � Produces near-optimal solutions in a very large time � Cannot be used inside a design space exploration loop � Used as the baseline for comparisons � Straightforward solution � Finds a schedulable application � Does not consider the optimization of the design Time-driven systems 14 14 of 14
Can We Improve the Schedules? Cost function: schedule length 60 Average Percentage Deviation [%] 50 � Case study 40 Straightforward solution � Vehicle cruise controller 30 Greedy 1 � Used throughout the thesis Greedy 2 20 Baseline: Simulated Annealing 10 0 80 160 240 320 400 Number of processes Time-driven systems 15 15 of 14
“Classic” Mapping and Scheduling Example N 1 N 2 P 3 P 4 P 2 P 1 P 1 N 1 P 4 P 3 P 2 N 2 m 3 m 4 S 1 S 0 m 1 m 2 Bus Round 1 Round 2 Round 3 Round 4 Round 5 Time-driven systems 16 16 of 14
Incremental Design Process � 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 Time-driven systems 17 17 of 14
Incremental Mapping and Scheduling Future Do not exist yet at Version N! applications Map and schedule so that the Current Version N+1 future applications applications will have a chance to fit N Minimal modifications Existing N-1 are performed to applications the existing applications Time-driven systems 18 18 of 14
Incremental Mapping and Scheduling Input � � A set of existing applications modeled using process graphs � A current application to be mapped modeled using process graphs � Each process graph in an application has its own period and deadline � Each process has a potential set of nodes to be mapped on and a WCET � Characteristics of the future applications � The system architecture is given Output � � A mapping and scheduling of the current application, such 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 Time-driven systems 19 19 of 14
Mapping and Scheduling Example Future application Current application Existing application The future application (a) does not fit! (b) Time-driven systems 20 20 of 14
Mapping and Scheduling Strategies � Design optimization problem � Design criteria reflect the degree to which a design supports an incremental design process � Design metrics quantify the degree to which the criteria are met � Heuristics to improve the design metrics � Ad-hoc approach � Little support for incremental design � Mapping Heuristic � Iteratively performs design transformations that improve the design Time-driven systems 21 21 of 14
Can We Support Incremental Design? Are the mapping strategies proposed facilitating the implementation of future applications? 100 % of future applications mapped 90 MH Future 80 application AH 70 60 Current 50 application 40 30 Existing 20 application 10 0 40 80 160 240 Number of processes in the current application existing applications: 400, future application: 80 Time-driven systems 22 22 of 14
Recommend
More recommend
