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
1.
Scheduling theory and real-time systems
2.
Why mixed-criticality systems?
3.
Scheduling theory and mixed-criticality systems
4.
An illustrative example
A history Lesson…
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
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
system
specifications
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
Current practice
platform resources
Scheduling penalty increases with
system complexity
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
- In the beginning, efficiency mattered
system complexity
- greater dollar cost
- Over time, correctness became more important
This penalty matters more: SWaP
considerations
- Scheduling theory ; formal methods
- Today efficiency matters again
- Platform size and weight
- Energy considerations
- Environmental concerns
- Thermal considerations
- Limitations on mobility
platform resources
Why Mixed Criticalities?
Modern safety-critical systems
- are very complex
- are implemented upon non-deterministic platforms
- need rigorous correctness proofs
Need significant resource
over-provisioning
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
- are implemented upon non-deterministic platforms
- need rigorous correctness proofs
Need significant resource
over-provisioning
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
- are implemented upon non-deterministic platforms
- need rigorous correctness proofs
Need significant resource
over-provisioning
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
Scheduling theory for mixed-criticality
systems
Models of real-time systems
RT System: Jobs executing on a specified platform
Job J = (release time, execution requirement, deadline)
execution requirement
(e)
d
r
scheduling window
Recurrent tasks
- finite (a priori known) number of them
- generate the jobs
time
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)
execution requirement
(≤2)
(≤2)
(≤2)
(≤2)
(≤2)
time
0
5
10
15
20
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
What
is a job?arrivals  T time units apart
- each job has execution requirement ≤ C
- Where do the execution requirements come from?
- each job has a deadline T time units after its arrival
What is a sporadic task?
- How do we determine the periods?
Example:  =(2,5)
(2)
(2)
(2)
(2)
(2)
time
0
5
10
15
20
Worst-Case Execution Time (WCET)
Jobs model code
Execution requirement: execution duration for the code
Determining the execution durations: WCET-analysis tools
Executable
Code
WCETanalysis
tool
Target architecture
WCET
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
WCET - hard/ impossible to determine
Worst-Case Execution Time (WCET)
E.g., x = a + b on the PPC-755
- best case:
3 cycles
- worst case: 321 cycles
Adequate for analyzing non-safetycritical functionalities
time
WCET - may be extremely unlikely
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
Executable
Code
WCETanalysis
tool
Target architecture
WCET
The multiple-WCET mixed-criticality scheduling problem
Given a collection of jobs, each job characterized as critical or not, and two
WCET 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
clock frequency
- locally synchronous modules that communicate asynchronously
- local clocks may be paused, stretched, or data-driven
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
The Liu & Layland (LL) sporadic task model
Task  = (C,T)
-
worst-case execution requirement
minimum inter-arrival separation (“period”)
Jobs
Models the execution of a piece of code
- first job arrives at any time
- successive
What
is a job?arrivals  T time units apart
- each job has execution requirement ≤ C
- Where do the execution requirements come from?
- each job has a deadline T time units after its arrival
What is a sporadic task?
Determined by WCET tools
- How do we determine the periods?
Example:  =(2,5)
(2)
(2)
0
5
(2)
10
(2)
(2)
15
20
The Liu & Layland (LL) sporadic task model
Task i = (Ci,Ti)
Models repeatedly executed code
Ci: maximum execution duration of the code
- determined using WCET tools
Ti (the “period” parameter)
-time-triggered periodic tasks : (fixed) duration between executions
-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-criticality
The
big picture scheduling
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
- extensive testing of EDF: no deadline miss
(WCET estimations are not needed)
processor
- 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
J2
Y
1
1
3
J3
N
0
?
?
Necessary: critical jobs must
be feasible on a minimum speed
processor
time
0
1
2
3
4
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
Processor speed
Necessary: critical jobs must
be feasible on a minimum speed
processor
1
1
2
3
4
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
Would like to also complete
the non-critical job[s]
Processor speed
On a faster processor (with
unknown speed variation)
1
1
2
3
4
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
?
?
(> 1 unit)
0
Would like to also complete
the non-critical job[s]
- if d3 ≥ 4, EDF is fine
Processor speed
On a faster processor (with
unknown speed variation)
1
1
(< 2 units)
2
3
4
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
- if d3 =1:
Processor speed
On a faster processor (with
unknown speed variation)
Would like to also complete
the non-critical job[s]
(2 units)
(1 unit)
1
1
2
3
4
Example: Scheduling analysis of a mixed-criticality system
job critical? ai
J1
Y
0
ci
3
di
4
J2
Y
1
1
3
J3
N
?
?
?
(1 unit)
0
- if d3 =2:
Processor speed
On a faster processor (with
unknown speed variation)
Would like to also complete
the non-critical job[s]
(2 units)
(1 unit)
1
1
2
3
4
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-TIMEcomplexity:
- O(n2)table
prioroftothe
run-time
1. Construct a scheduling
critical jobs on a minimum-speed
processor, with all-execution
as late
as possible
Same as occurring
EDF during
run-time
2. Partition the time-line into disjoint intervals, according to (all) jobs’
release dates and deadlines
OPTIMALITY property:
DURING
RUN-TIME
eachjobs
interval
- always
completes within
all critical
(on a minimum-speed processor)
- If anyallsuch
on-line
non-critical
does so,table
too
1. Execute
critical
jobs’algorithm
executionscompletes
assigned toall
that
interval in jobs,
the scheduling
2. Execute non-critical jobs according to EDF
3. Execute critical jobs according to EDF
The Summing Up
Mixed-criticality scheduling: why and what?
Efficiency matters once more
scheduling theory is important, again
Scheduling theory is applied to models … that are conservative
- platforms increasingly unpredictable
resource under-utilization increases
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 assurance levels
- ISO 26262 (automotive) – 4 automotive safety integrity levels
Non-CPU resources
- memory, bandwidth, etc.
- security
Other analytical approaches
- probabilistic analysis
- model-checking