Relaxing the Synchronous Approach for Mixed-Criticality Systems

Relaxing the Synchronous Approach for Mixed-Criticality

Systems

Eugene Yip, Matthew M Y Kuo,Partha S Roop, and David Broman

RTAS’14

Life

Mission

Non-critical

Mixed-Criticality Motivations

Hardware

Multi-processor, Multi-core, Multi-threaded, ...

Software

Task 1, Task 2, ... Task n

DO-178B Software Level

Failure Condition

A Catastrophic

B Hazardous

C Major

D Minor

E No effect

Different requirements: timing, security, safety. Criticality: Level of required assurance against failure.

Hard/soft/non-real-time

[Vestal 2007] Preemptive Scheduling of Multi-criticality Systems with Varying Degrees of Execution Time Assurance.[RTCA 1992] Software Considerations in Airborne Systems and Equipment Certification.

UAV Example

Nav(Life-critical)

Stability(Life-critical)

Logging(Non-critical)

Sharing(Non-critical)

Avoid(Mission-critical)

Video(Mission-critical)Input from

camera

Input from proximity

sensor

Input from position & orientation

sensors

Output to comms

Outputto flight surfacesInput from

comms

Related Work

• Vestal: Task WCETs more pessimistic at higher criticalities. Over provisioning of resources.

• Early-Release EDF: Low critical tasks have a maximum period and shorter desired periods.

• Zero-Slack QoS-based Resource Allocation Model: Tasks with lower utility degraded first (selecting longer periods).

[Vestal 2007] Preemptive Scheduling of Multi-criticality Systems with Varying Degrees of Execution Time Assurance.[Su et al. 2013] Scheduling Algorithms for Elastic Mixed-Criticality Tasks in Multicore Systems.[de Niz et al. 2012] On Resource Overbooking in an Unmanned Aerial Vehicle.

The Synchronous Approach

Task 1

j = f(i)

Task 2

k = g(j)

int i

Environment

int j int k

Task 1Task 2

Logical time1 2 3

Task 1Task 2

Task 1Task 2

Implementation takes physical

time to execute.Implementation takes physical time to tick.

• Formal semantics.• Formal verification.• SCADE used in Airbus.

Validate: WCET is always less than the duration of any tick.

[Benveniste et al. 2003] The Synchronous Languages: 12 Years Later.

Synchrony hypothesis: Executions complete

instantaneously.

Related Work

• Baruah’s static scheduling approach:– High and low criticality tasks.– Low-criticality tasks may be discarded.– Multi-rate synchronous tasks on uni-processor.– Single-rate synchronous tasks on multi-processor.

• Missing:– Multi-rate tasks on multi-processor.– Modelling of mission tasks that can tolerate

bounded deadline misses (soft real-time).[Baruah 2012] Semantics-Preserving Implementation of Multirate Mixed-Criticality Synchronous Programs.[Baruah 2013] Implementing Mixed-Criticality Synchronous Reactive Systems Upon Multiprocessor Platforms.

UAV Example

Nav(Life-critical)

4Hz


20Hz


10Hz


10Hz


10Hz – 20Hz

Video(Mission-critical)

10Hz – 25Hz

Input from camera


sensor


sensors

Output to comms


comms

Problem Statement

• Synchrony hypothesis requires:– All tasks to be hard real-time: No advantage in

prioritizing tasks based on criticality.– WCETs of all tasks for validation: Cannot include

(non-critical) tasks with unknown WCETs.– Enough resources to be provisioned for the worst-

case: Under-utilization of resources at runtime.

Contributions

• Relax the synchrony hypothesis to model mission critical tasks with frequency bounds.

• Address the communication between mission critical tasks.

• Propose an efficient scheduling of multi-rate, mixed-criticality, synchronous tasks on multi-processors.

• Benchmark showing better processor utilization than ER-EDF.

Talk Outline

• MC Task and Communication Model• Multiprocessor Scheduling Approach• Performance Evaluation and Discussions• Conclusions and Future Work

MC Task Model

• Program is a set of tasks: • Task’s level of criticality:

• Task’s release frequency:Life: (constant)Mission: (bound)Non-critical: (goal)

• Task’s computation time (WCET analysis):

[Wilhelm et al. 2008] The Worst-Case Execution-Time Problem - Overview of Methods and Survey of Tools.

MC Task Communication Model

• Instead of instantaneous communication...

• Use delayed communication:

Task B

Task A

r r+p

b a

Time

Time

Task B

Task A

r r+p

b1a1a0

b0

Tasks use values produced from the previous period. Delays due to data dependencies are avoided.

Data-dependencies limit schedulability and distribution. Delays difficult to analyze for distributed tasks.


• Oversampling:

• Undersampling:Time

Task B

Task A

r r+p

b1

r+2p

b2b0

r+3p r+4p

Time

Task B

Task A

r r+p

a1

r+2p

a2a0

r+3p r+4p

a4a3


• Lossless buffering:

– Data received in the same sequence as it is sent. Timing of when data is received varies at runtime.

– Maximum buffer size

Time

Task B

Task A

r r+p

a1

r+2p

a2a0

r+3p r+4p

a4a3

Related Work

• Lossless buffering:– Synchronous Data Flow and Rate-Based Execution.• Release of a task depends on receiving a minimum

amount of buffered data. • Buffer sizes depend on task scheduling order.

[Lee & Messerschmitt 1987] Synchronous Data Flow.[Goddard & Jeffay 2001] Managing Latency and Buffer Requirements in Processing Graph Chains.

Multiprocessor Task Schedulability

Notations for task utilization:1. 2. 3. 4.

Multiprocessor Task Schedulability

Schedulability: Given a set of homogenous processors , a task set is schedulable over processors if:

Multiprocessor Scheduling Approach

• Static scheduling:1. Allocate minimum processor time to life and

mission critical tasks to satisfy schedulability.2. Distribute slack fairly among mission critical tasks

to help improve their frequency.• Dynamic scheduling:

3. Give non-critical tasks the chance to execute and reach their goal frequency.

Time (ms)

Task D on processor 2

0 100

50

Static Scheduling

• Base period approach:– GCD of task periods.– Portion of allocated in the base period.– Slack accumulates at the end of each base period.

200

150

300

250

400

350

500

450

600

550

200

150

300

250

Task C on processor 1

0 100

50

Example:Task C Task D

Base period

[Caspi & Maler 2005] From Control Loops to Real-Time Programs.

Static Scheduling (ILP)

• : Base period (GCD). : Processors.: Min and max processor time each life and mission critical task needs in .

1. 2. 3.

4. Cost of delayed communication.

Cost of preempting a task. Solution exists

if the task set is schedulable.

Static scheduling (ILP)

Nav(Life-critical)

4Hz


20Hz


10Hz


10Hz


10Hz – 20Hz

Video(Mission-critical)

10Hz – 25Hz

Input from camera


sensor


sensors

Output to comms


comms

𝒙𝝉𝒏𝑡𝜏𝑚𝑖𝑛

Minimum allocated times:

Maximum allocated times:

Note, for life critical tasks.


• Allocate slack among mission critical tasks:– Additional constraints to guide slack allocation.– E.g., proportionate fairness or marginal utility.– Example: For any two tasks, the task with larger is

given proportionally more slack.

𝑥𝜏𝑚𝑎𝑥

𝑥𝜏 ′𝑚𝑎𝑥 ≤

𝒙𝝉𝒏

𝒙𝝉 ′𝒏′

[Lan et al. 2010] An Axiomatic Theory of Fairness in Network Resource Allocation.[Baruah et al. 1996] Proportionate Progress: A Notion of Fairness in Resource Allocation.[de Niz et al. 2012] On Resource Overbooking in an Unmanned Aerial Vehicle.


1. 2. 3.

4.

5. 6.


• Static scheduling:1. Allocate minimum processor time to life and

mission critical tasks to satisfy schedulability.2. Distribute slack fairly among mission critical tasks

to help improve their release frequency.• Dynamic scheduling:

3. Give non-critical and mission tasks the chance to reach their .

Dynamic Scheduling

Time (base period)1Processor

2 3

Statically scheduled life and mission

critical tasks.

Slack(Dynamic scheduling)

Execute non-critical tasks.

Dynamic scheduling:• Allow task migration.• Tasks execute until they complete or the base period expires.• Pick non-critical tasks that have received the least amount of slack.• Pick mission critical tasks with the least improvement in frequency.

Execute mission critical tasks.

Execute life critical tasks.

𝑓 𝜏𝑖𝑚𝑝𝑟𝑜𝑣𝑒=

𝑓 𝜏𝑎𝑣𝑔− 𝑓 𝜏𝑚𝑖𝑛

𝑓 𝜏𝑚𝑎𝑥− 𝑓 𝜏

𝑚𝑖𝑛

Performance Evaluation

• Compare against ER-EDF (the closest work):– High criticality task Life critical task– Low criticality task Mission critical task• Early release points spaced evenly by .• Tasks picked randomly for early release.

𝑟 𝑟+𝑝𝑘1𝑘2𝑘 3𝑘4

𝑟 𝑟+1

𝑓 𝑚𝑖𝑛𝑟+1

𝑓 𝑚𝑎𝑥

ER-EDF low criticality task

Proposed mission critical task

[Su et al. 2013] Scheduling Algorithms for Elastic Mixed-Criticality Tasks in Multicore Systems.


• Follow the simulation approach of ER-EDF. Generate random task sets:

• Divisors of randomly selected for and .



• Control the proportion of life and mission critical tasks generated.

• Control the “normalized system utilization”:• Estimated utilization expected at runtime.


where,


• Schedulability of the generated task sets:

20% 40% 60% 80% 100%0%

20%

40%

60%

80%

100%

prop(0.2)

prop(0.5)

prop(0.8)

Normalized System Utilization

Acc

epta

nce

Rat

io

• Each data point is the average of 10,000 random task sets.

• 4 processor system.• An average of 118.9 ILP

constraints for each task set. • ILP solver (Gurobi) allowed one

minute to solve and generate a static schedule.

• Less schedulable task sets generated when life and mission critical tasks are in equal proportions.

[Gurobi version 5.6] http://www.gurobi.com


• Proportion of life critical tasks varied:• U = 50%, N = 4, 1000 base periods.• Task’s actual execution time between and .

System Runtime Utilization

0% 20% 40% 60% 80% 100%0%

20%

40%

60%

80%

100%

ProposedER-EDFEDF

prop(life)

Syst

em R

untim

e U

tiliz

atio

n • Consistently higher utilization. • Utilization drops off because less

mission critical tasks are available to use the slack.



Overall Frequency Improvement of Mission Critical Tasks

0% 20% 40% 60% 80% 100%0%

20%

40%

60%

80%

100%ProposedER-EDF

prop(life)

Ove

rall

Freq

uenc

y Im

prov

emen

t

• Higher system utilization leads to higher frequency improvement.

• No improvement when there are no mission critical tasks.

𝑓 𝑚𝑖𝑠𝑠𝑖𝑜𝑛𝑖𝑚𝑝𝑟𝑜𝑣𝑒=

∑ ( 𝑓 𝜏𝑎𝑣𝑔− 𝑓 𝜏𝑚𝑖𝑛 )∑ ( 𝑓 𝜏𝑚𝑎𝑥− 𝑓 𝜏

𝑚𝑖𝑛)



Fairness Among Mission Critical Tasks

0% 20% 40% 60% 80% 100%0%

5%

10%

15%

20%

25%

30%

ProposedER-EDF

prop(life)

Fair

ness • Fairness heuristics performs

better when there are many mission critical tasks.

• Completely fair when only one mission critical task is generated.fair

unfair

fairness=∑|𝑓 𝜏𝑎𝑣𝑔𝑖𝑚𝑝𝑟𝑜𝑣𝑒− 𝑓 𝜏

𝑖𝑚𝑝𝑟𝑜𝑣𝑒|𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑀𝑖𝑠𝑠𝑖𝑜𝑛𝑇𝑎𝑠𝑘𝑠


• Proportion of non-critical tasks varied:• Remaining tasks: Equal proportions of life and

mission critical tasks.System Runtime Utilization Overall Frequency Improvement Fairness

Non-critical tasks use most of the slack.

10% 30% 50% 70% 90%0%

10%

20%

30%

40%

prop(non-critical)

Ove

rall

Freq

uenc

y Im

prov

emen

t

10% 30% 50% 70% 90%99.0%

99.2%

99.4%

99.6%

99.8%

100.0%

prop(non-critical)

Syst

em R

untim

e U

tiliz

atio

n

10% 30% 50% 70% 90%0%

10%

20%

30%

40%

prop(non-critical)

Fair

ness

Mission critical tasks already given slack in the static schedule and rarely picked during dynamic scheduling.

Discussions

• Proposed scheduling achieved:– Higher system utilization, frequency improvement,

and better fairness.• Proposed scheduling approach supports an

extra level of task criticality.• Base period scheduling incurs nearly twice the

number of preemptions than ER-EDF.• Solving ILP can be expensive. Can use solver to

find locally optimal solutions, like a heuristic.

Conclusions and Future Work

• Mission critical tasks (bounded deadline misses) for the synchronous task model.

• Lossless communication between multi-rate tasks.

• Scheduling on multi-processors to maximize system utilization with fairness.

• Future: Study a real system. Extend definition of criticality to include energy use. Develop improved fairness/utility heuristics.

Thank You

Questions?

MC Task Model


• Task’s release times:

Timer r+p r+2pLife-critical task

Deadline is the next release time.

Constant release frequency:

MC Task Model

Timer r+pmin r+pmax

Mission-critical task

Ideal next release time (and deadline).

Upper bound on deadline miss.

If a task completes between the bounds, then it is immediately released again.



Bounded release frequency:

r r+pmin r+pmax



MC Task Model

TimerNon-critical task

Ideal next release time.

No upper bound on deadline miss.

Goal release frequency:

r+p


• Traditional static scheduling approaches: Base period and hyper period.– Task C – Task D

Time (s)

Task D on process 2

Task C on process 1

0 0.1

0 0.25 0.5 0.75 1

0.2 0.3 0.4 0.5 0.6 0.7 0.8 10.9

Time (s)

Task D on process 2

Task C on process 1

0 0.1

0.05

0 0.1

0.05

Hyper period:Makespan = LCM of task periods.Longer schedules.Slack appears between task releases.

Base period:Makespan = GCD of task periods.Shorter schedules. More preemptions.Slack accumulates at the end of each base period (easier to track).

0.2

0.15 0.3

0.25 0.4

0.35 0.5

0.45 0.6

0.55

0.2

0.15 0.3

0.25

Obtaining a Static Schedule

Fairness Example

Task C Task D

• If processor only has 4 units of slack, then , 1, and 1 unit of slack left over.

• An inequality would allow task C to take the remaining unit of slack.

21

ILP Scalability

• Time for Gurobi to find the first (locally optimal) solution compared to the final (globally optimal) solution.

2 10 18 26 34 42 5010

100

1000

10000

100000First locally optimal Globally optimal

Number of Tasks

Solv

ing

Tim

e (S

econ

ds)

> 600• Generated 250 random task sets

containing 2 to 50 tasks (even numbered).

• U = 50%, N = 32, 50% life critical tasks.

• Quick to find the first solution.• Similar to using a heuristic.

Preemptions

• Normalized system utilization varied:• N = 4, 1000 base periods, 50% life critical tasks.• Task’s actual execution time between and .

10% 20% 30% 40% 50%0

2000

4000

6000

8000ProposedER-EDF-ILPEDF

Normalized System Utilization

Num

ber

of P

reem

ptio

ns

• Proposed approach is nearly twice that of EDF.

• Implementation determines the true cost.

Average Number of Preemptions on each Processor

Extra Levels of Criticality

• Refining the timing criticality of tasks:

• Or mix timing criticality with other kinds of criticalities (e.g., security, safety, and power).

Failure Condition DO-178B Software Level Task CriticalityCatastrophic A Life

Hazardous B Mission

Major C Mission

Minor D Mission

No effect E Non-Critical

Documents

Relaxing the Synchronous Approach for Mixed-Criticality Systems