640 likes | 1.13k Views
scheduling theory for mixed-criticality systems. Sanjoy Baruah The University of North Carolina at Chapel Hill. scheduling theory for mixed-criticality systems. The efficient allocation of limited resources in order to optimize specified global objectives. scheduling theory
E N D
scheduling theory for mixed-criticality systems Sanjoy Baruah The University of North Carolina at Chapel Hill
scheduling theory for mixed-criticality systems The efficient allocation of limited resources in order to optimize specified global objectives
scheduling theory for mixed-criticality systems The efficient allocation of limited resources in order to optimize specified global objectives Functionalities of different degrees of importance co-exist on a shared platform
The trend towards mixed-criticality systems ensures the continued relevance of real-time scheduling theory to the discipline of Real-Time Computing • OUTLINE of presentation • Scheduling theory and real-time systems • Why mixed-criticality systems? • Scheduling theory and mixed-criticality systems • An illustrative example
Safety-critical systems should be correct and have efficient implementations. • Real-time systems: origins in defense and aerospace • safety-critical: correctness matters • resource-constrained platforms: need efficient implementation • In the beginning… • safety-critical systems were simple • implemented as simple software, on predictable processors • Real-time systems became more complex • new abstractions were needed • -which details to hide?
Safety-critical systems should be correct and have efficient implementations. • The increasing prominence of safety-critical infrastructure • - automotive systems; avionics; medical devices • - cyber-physical systems: intelligent highways; next-generation ATC; smart grid Correctness considerations remain paramount… … but are more difficult to ensure • Efficiency considerations matter less • - computing capacity plentiful and inexpensive (Moore’s Law)
Safety-critical systems should be correct and have efficient implementations. Most current design techniques focus more on correctness than on efficiency. Design techniques to facilitate provable correctness • the synchrony hypothesis • models for timed execution: synchronous reactive; logical execution time; timed automata; etc. • model-based design Difficult to implement efficiently on advanced platforms Current practice: over-provision computing resources
system specifications platform resources Safety-critical systems should be correct and have efficient implementations. Most current design techniques focus more on correctness than on efficiency. It is necessary to reintegrate efficiency considerations. The window of scarcity impossible to implement window of scarcity easy to implement
platform resources Safety-critical systems should be correct and have efficient implementations. Most current design techniques focus more on correctness than on efficiency. It is necessary to reintegrate efficiency considerations. The window of scarcity Current practice System model (with correctness proof) an implementation easy to implement
platform resources Safety-critical systems should be correct and have efficient implementations. Most current design techniques focus more on correctness than on efficiency. It is necessary to reintegrate efficiency considerations. logarithmic scale scheduling penalty Scheduling penalty increases with system complexity scheduling penalty Current practice ≈
platform resources Size, Weight, and Power Safety-critical systems should be correct and have efficient implementations. Most current design techniques focus more on correctness than on efficiency. It is necessary to reintegrate efficiency considerations. The narrative thus far: scheduling penalty Scheduling penalty increases with system complexity - In the beginning, efficiency mattered - greater dollar cost - Over time, correctness became more important - Scheduling theory ; formal methods This penalty matters more: SWaP considerations - Today efficiency matters again ≈ - Platform size and weight - Energy considerations - Environmental concerns - Thermal considerations - Limitations on mobility
Modern safety-critical systems - are very complex Need significant resource over-provisioning - are implemented upon non-deterministic platforms - need rigorous correctness proofs Example: x := a + b on the Motorola PowerPC 755 - Best case: 3 cycles - Worst case: 321 cycles (In the 1990’s: the Motorola 64K had best case = worst case = 20 cycles) Example: resource reservation in avionics applications
Modern safety-critical systems - are very complex Need significant resource over-provisioning - are implemented upon non-deterministic platforms - need rigorous correctness proofs Example: x := a + b on the Motorola PowerPC 755 - Best case: 3 cycles - Worst case: 321 cycles (In the 1990’s: the Motorola 64K had best case = worst case = 20 cycles) Example: resource reservation in avionics applications
Mixed Criticalities Modern safety-critical systems - are very complex Need significant resource over-provisioning - are implemented upon non-deterministic platforms - need rigorous correctness proofs Resource over-provisioning leads to inefficient resource usage at run-time Integrated Computing Environments: functionalities of different criticalities upon a shared platform - use resource over-provisioning to validate critical functionalities at high levels of assurance - design-time resource reclamation to validate non-critical functionalities at lower levels of assurance
(e) d r time Models of real-time systems RT System:Jobsexecuting on aspecifiedplatform Job J = (release time, execution requirement, deadline) execution requirement scheduling window Recurrent tasks • - finite (a priori known) number of them • - generate the jobs
0 10 20 5 15 The Liu & Layland (LL) sporadic task model Task = (C,T) • worst-case execution requirement • minimum inter-arrival separation (“period”) Jobs • first job arrives at any time • successive arrivals T time units apart • each job has execution requirement ≤ C • each job has a deadline T time units after its arrival Example: =(2,5) (≤2) execution requirement (≤2) (≤2) (≤2) (≤2) time
0 10 20 5 15 The Liu & Layland (LL) sporadic task model Task = (C,T) • worst-case execution requirement • minimum inter-arrival separation (“period”) Jobs • first job arrives at any time • successive arrivals T time units apart • each job has execution requirement ≤ C • each job has a deadline T time units after its arrival Example: =(2,5) What is a job? - Where do the execution requirements come from? What is a sporadic task? - How do we determine the periods? (2) (2) (2) (2) (2) time
Worst-Case Execution Time (WCET) Jobs model code Execution requirement: execution duration for the code Determining the execution durations: WCET-analysistools WCET-analysis tool Executable Code WCET Target architecture
Worst-Case Execution Time (WCET) Wilhelm et al. (2008). The worst-case execution time problem: overview of methods and survey of tools. ACM Transactions On Embedded Computer Systems 7(3) Histogram of (actual) execution times of a single piece of code time
Worst-Case Execution Time (WCET) The greater the level of assurance sought, the larger the bound - A very conservative tool may use static analysis - A more optimistic tool may be measurement-based WCET tools typically determine upper bounds time - hard/ impossible to determine WCET
Worst-Case Execution Time (WCET) E.g., x = a + bon the PPC-755 - best case: 3 cycles - worst case: 321 cycles Adequate for analyzing non-safety-critical functionalities time - may be extremely unlikely WCET
Worst-Case Execution Time (WCET) WCET-analysis tools determine upper bounds on maximum execution time Different tools are more or less conservative Conservative tools compute bounds at higher levels of assurance - Needed to validate critical functionalities Less conservative tools often give smaller WCET values - Suffice for validating non-critical functionalities WCET-analysis tool Executable Code WCET Target architecture
The multiple-WCET mixed-criticality scheduling problem Given a collection of jobs, each job characterized as critical or not, and twoWCET values Determine a single scheduling strategy - If each job executes for ≤ its smaller WCET, then all the jobs complete by their deadlines - If each job executes for ≤ its larger WCET, then all the critical jobs complete by their deadlines Steve Vestal. Preemptive scheduling of multi-criticality systems with varying degrees of execution time assurance. RTSS 2007
An additional factor: CPU speeds may change Advanced hardware features - detect if signals are late at the circuit level; recover by delaying next clock tick GALS:Globally Asynchronous Locally Synchronous - locally synchronous modules that communicate asynchronously - local clocks may be paused, stretched, or data-driven clock frequency s slb time
The variable proc.-speed mixed-criticality scheduling problem Given a collection of jobs, each job characterized as critical or not, a single WCET value, and two processor speeds: s and slb Determine a single scheduling strategy - If processor speed remains ≥ s, then all the jobs complete by their deadlines - If processor speed remains ≥ slb, then all the critical jobs complete by their deadlines
0 10 20 5 15 The Liu & Layland (LL) sporadic task model Task = (C,T) • worst-case execution requirement • minimum inter-arrival separation (“period”) Jobs • first job arrives at any time • successive arrivals T time units apart • each job has execution requirement ≤ C • each job has a deadline T time units after its arrival Example: =(2,5) Models the execution of a piece of code What is a job? - Where do the execution requirements come from? What is a sporadic task? - How do we determine the periods? Determined by WCET tools (2) (2) (2) (2) (2)
The Liu & Layland (LL) sporadic task model Task i = (Ci,Ti) • Models repeatedly executed code • Ci: maximum execution duration of the code • Ti (the “period” parameter) - determined using WCET tools : (fixed) duration between executions -time-triggered periodic tasks -event-triggered sporadic tasks : minimum duration between executions must be estimated -more pessimistic (smaller) periods for validating safety-critical functions -less conservative (larger) periods for validating non-critical functions
The multiple-period mixed-criticality scheduling problem Given a collection of sporadic tasks, each task characterized as critical or not, a single WCET value, and two period parameters Determine a single scheduling strategy - If successive jobs of each task arrive ≥ its larger period apart, then all jobs complete by their deadlines - If successive jobs of each task arrive ≥ its smaller period apart, then all critical tasks’ jobs complete by their deadlines
Mixed-criticalityscheduling The big picture Scheduling theory is applied to models … that are conservative performance penalties due to being conservative are increasing Critical and non-critical functions co-exist in mixed-criticality systems MC scheduling: two independent analyses of a single system 1. Validate safety-critical functionalities using conservative approximations 2. Validate all functionalities using less pessimistic approximations Multiple dimensions to such modeling - upper bound on the execution time of code - lower bound on the processor speed - lower bound on duration between external interrupts - … - … - …
Mixed-criticality scheduling: An example
Example: Scheduling analysis of a mixed-criticality system Collection of independent jobs, on a varying-speed preemptive processor • Jobs: • critical or not • release time • worst-case execution requirement • deadline • Processor: • minimum speed 1 • maximum speed unbounded • Desired run-time behavior: • all critical jobs must meet deadlines • all remaining jobs should meet deadlines
Example: Scheduling analysis of a mixed-criticality system Collection of independent jobs, on a varying-speed preemptive processor • Jobs: • critical or not • release time • worst-case execution requirement • deadline • Processor: • minimum speed 1 • maximum speed unbounded SYSTEM DESIGNER CERTIFICATION AUTHORITY Testing-based validation Prior proof of correctness - EDF optimal for meeting all deadlines Must prove that all critical jobs will complete on time, assuming speed-1 processor - extensive testing of EDF: no deadline miss (WCET estimations are not needed) - WCET estimates are needed Observation: EDF acceptable iff all the jobs, with (pessimistic) WCET’s, are shown feasible on a speed-1 processor
Example: Scheduling analysis of a mixed-criticality system job critical? ai ci di J1 Y 0 3 4 J1 Y time J2 Y 1 1 3 J2 Y J3 N 0 ? ? J3 N 0 1 2 3 4 Necessary: critical jobs must be feasible on a minimum speed processor
Example: Scheduling analysis of a mixed-criticality system job critical? ai ci di J1 Y 0 3 4 J2 Y 1 1 3 J3 N 0 ? ? 0 1 2 3 4 Necessary: critical jobs must be feasible on a minimum speed processor Processor speed 1
Example: Scheduling analysis of a mixed-criticality system job critical? ai ci di J1 Y 0 3 4 J2 Y 1 1 3 J3 N 0 ? ? 0 1 2 3 4 On a faster processor (with unknown speed variation) Would like to also complete the non-critical job[s] Processor speed 1
Example: Scheduling analysis of a mixed-criticality system job critical? ai ci di (< 2 units) (> 1 unit) J1 Y 0 3 4 J2 Y 1 1 3 J3 N 0 ? ? 0 1 2 3 4 On a faster processor (with unknown speed variation) Would like to also complete the non-critical job[s] Processor speed - if d3 ≥ 4, EDF is fine 1
Example: Scheduling analysis of a mixed-criticality system job critical? ai ci di (2 units) (1 unit) J1 Y 0 3 4 J2 Y 1 1 3 J3 N 0 ? ? 0 1 2 3 4 On a faster processor (with unknown speed variation) Would like to also complete the non-critical job[s] Processor speed - if d3 =1: 1
Example: Scheduling analysis of a mixed-criticality system job critical? ai ci di (2 units) (1 unit) J1 Y 0 3 4 (1 unit) J2 Y 1 1 3 J3 N ? ? ? 0 1 2 3 4 On a faster processor (with unknown speed variation) Would like to also complete the non-critical job[s] Processor speed - if d3 =2: 1
Example: Scheduling analysis of a mixed-criticality system Algorithm for scheduling a mixed-criticality collection of independent jobs on a varying-speed preemptive processor PRIOR TO RUN-TIME 1. Construct a scheduling table of the critical jobs on a minimum-speed processor, with all execution occurring as late as possible 2. Partition the time-line into disjoint intervals, according to (all) jobs’ release dates and deadlines DURING RUN-TIME within each interval 1. Execute all critical jobs’ executions assigned to that interval in the scheduling table 2. Execute non-critical jobs according to EDF 3. Execute critical jobs according to EDF
Example: Scheduling analysis of a mixed-criticality system Algorithm for scheduling a mixed-criticality collection of independent jobs on a varying-speed preemptive processor PRIOR TO RUN-TIME • Run-time complexity: • O(n2) prior to run-time • Same as EDF during run-time 1. Construct a scheduling table of the critical jobs on a minimum-speed processor, with all execution occurring as late as possible 2. Partition the time-line into disjoint intervals, according to (all) jobs’ release dates and deadlines • OPTIMALITY property: • always completes all critical jobs (on a minimum-speed processor) • If any such on-line algorithm completes all non-critical jobs, does so, too DURING RUN-TIME within each interval 1. Execute all critical jobs’ executions assigned to that interval in the scheduling table 2. Execute non-critical jobs according to EDF 3. Execute critical jobs according to EDF
Mixed-criticality scheduling: why and what? Efficiency matters once more scheduling theoryis important, again Scheduling theory is applied to models … that are conservative - platforms increasingly unpredictable resource under-utilizationincreases Mixed-criticality systems: Critical and non-critical functions co-exist - traditionally, non-critical functions execute in the background MC scheduling: provide performance guarantees to non-critical functions, too Two independent analyses 1. Validate safety-critical functionalities using conservative models 2. Validate all functionalities using less pessimistic models
Left unsaid… The certification angle More than two criticality levels - DO 178B (avionics) – 5 design assurancelevels - ISO 26262 (automotive) – 4 automotive safety integritylevels Non-CPU resources - memory, bandwidth, etc. - security Other analytical approaches - probabilistic analysis - model-checking