Schedulability Analysis as Evidence? Bjrn Brandenburg Max Planck - - PowerPoint PPT Presentation
Schedulability Analysis as Evidence? Bjrn Brandenburg Max Planck Institute for Software Systems (MPI-SWS) 1 Schedulability Analysis as Evidence? Can safety case rely on schedulability analysis? Safety Case Argument Evidence
Björn Brandenburg Max Planck Institute for Software Systems (MPI-SWS)
1
Can safety case rely on schedulability analysis? Safety Case ← Argument ← Evidence ← Methodology
2
Can safety case rely on schedulability analysis? Safety Case ← Argument ← Evidence ← Methodology “Is the methodology agreed as effective?” -- Philippa Ryan
3
Can safety case rely on schedulability analysis? Safety Case ← Argument ← Evidence ← Methodology “Is the methodology agreed as effective?” -- Philippa Ryan
3
Can safety case rely on schedulability analysis? Safety Case ← Argument ← Evidence ← Methodology “Is the methodology agreed as effective?” -- Philippa Ryan
3
It’s been peer-reviewed — should it be deemed effective?
Let’s take a look at the history of real-time scheduling…
4
It’s been peer-reviewed — should it be deemed effective?
Let’s take a look at the history of real-time scheduling…
4
Liu & Layland (1973)
schedulability test revisited”, Information Processing Letters, 73(5):157–161, 2000.
5
Liu & Layland (1973)
schedulability test revisited”, Information Processing Letters, 73(5):157–161, 2000.
5
Response-Time Analysis (RTA) — deceptively simple
854 (rev. 2), Dep. of Computer Science, TU Dortmund, March 2017.
6
Response-Time Analysis (RTA) — deceptively simple
854 (rev. 2), Dep. of Computer Science, TU Dortmund, March 2017.
6
Response-Time Analysis (RTA) — deceptively simple
854 (rev. 2), Dep. of Computer Science, TU Dortmund, March 2017.
6
Response-Time Analysis (RTA) — deceptively simple
854 (rev. 2), Dep. of Computer Science, TU Dortmund, March 2017.
6
Response-Time Analysis (RTA) — deceptively simple
854 (rev. 2), Dep. of Computer Science, TU Dortmund, March 2017.
6
Multiprocessor Priority Ceiling Protocol (1990):
in blocking time analyses under multiprocessor synchronization
[MPCP analysis (+others) assumes wrong critical instant]
algorithm for self-suspending tasks. Leibniz Transactions on Embedded Systems, 4(1), 2017. [Period enforcer incompatible with locking protocols / existing analyses]
7
Multiprocessor Priority Ceiling Protocol (1990):
in blocking time analyses under multiprocessor synchronization
[MPCP analysis (+others) assumes wrong critical instant]
algorithm for self-suspending tasks. Leibniz Transactions on Embedded Systems, 4(1), 2017. [Period enforcer incompatible with locking protocols / existing analyses]
7
Multiprocessor Priority Ceiling Protocol (1990):
in blocking time analyses under multiprocessor synchronization
[MPCP analysis (+others) assumes wrong critical instant]
algorithm for self-suspending tasks. Leibniz Transactions on Embedded Systems, 4(1), 2017. [Period enforcer incompatible with locking protocols / existing analyses]
7
Scheduling with Arbitrary Processor Affinities
the Linux Push and Pull Scheduler with Arbitrary Processor Affinities.
[incorrect over-generalization: proposed reduction technique works only for a few, not all global schedulability tests]
➔ got past (at least) six reviewers! ➔ unrealistic and unreasonable to expect reviewers to determine correctness
8
Scheduling with Arbitrary Processor Affinities
the Linux Push and Pull Scheduler with Arbitrary Processor Affinities.
[incorrect over-generalization: proposed reduction technique works only for a few, not all global schedulability tests]
➔ got past (at least) six reviewers! ➔ unrealistic and unreasonable to expect reviewers to determine correctness
8
Scheduling with Arbitrary Processor Affinities
the Linux Push and Pull Scheduler with Arbitrary Processor Affinities.
[incorrect over-generalization: proposed reduction technique works only for a few, not all global schedulability tests]
➔ got past (at least) six reviewers! ➔ unrealistic and unreasonable to expect reviewers to determine correctness
8
…so what can we do?
How to make complex schedulability analysis trustworthy?
➔ increasing model fidelity & complexity ➔ increasing proof sophistication & non-obvious correctness criteria
9
…so what can we do?
How to make complex schedulability analysis trustworthy?
➔ increasing model fidelity & complexity ➔ increasing proof sophistication & non-obvious correctness criteria
9
…so what can we do?
How to make complex schedulability analysis trustworthy?
➔ increasing model fidelity & complexity ➔ increasing proof sophistication & non-obvious correctness criteria
9
10
An open-source effort to formally verify the core of real-time scheduling theory, with the help of the Coq proof assistant.
machine-checked proofs, which rules out human error!
11
An open-source effort to formally verify the core of real-time scheduling theory, with the help of the Coq proof assistant.
machine-checked proofs, which rules out human error!
11
An open-source effort to formally verify the core of real-time scheduling theory, with the help of the Coq proof assistant.
machine-checked proofs, which rules out human error!
11
An open-source effort to formally verify the core of real-time scheduling theory, with the help of the Coq proof assistant.
machine-checked proofs, which rules out human error!
11
➔ schedulability analysis as evidence
checked ➔ avoid errors in new results.
12
➔ schedulability analysis as evidence
checked ➔ avoid errors in new results.
12
➔ schedulability analysis as evidence
checked ➔ avoid errors in new results.
12
➔ schedulability analysis as evidence
checked ➔ avoid errors in new results.
12
➔ schedulability analysis as evidence
checked ➔ avoid errors in new results.
12
➔ schedulability analysis as evidence
checked ➔ avoid errors in new results.
12
resource limits ➔ human intelligence is the bottleneck, not machine resources
➔ but will also not allow you to construct false “proofs”
➔ Coq is a proof assistant, not an automatic theorem prover
13
resource limits ➔ human intelligence is the bottleneck, not machine resources
➔ but will also not allow you to construct false “proofs”
➔ Coq is a proof assistant, not an automatic theorem prover
13
resource limits ➔ human intelligence is the bottleneck, not machine resources
➔ but will also not allow you to construct false “proofs”
➔ Coq is a proof assistant, not an automatic theorem prover
13
resource limits ➔ human intelligence is the bottleneck, not machine resources
➔ but will also not allow you to construct false “proofs”
➔ Coq is a proof assistant, not an automatic theorem prover
13
service, job completion, response-time bounds, … ➔ goal: as simple and tasteful as possible
, where , then is a response-time bound.” ➔ focus: primarily soundness
assembly code” to construct a proof tree in basic logic. ➔ the payoff: machine-checked, thus guaranteed correct
14
service, job completion, response-time bounds, … ➔ goal: as simple and tasteful as possible
, where , then is a response-time bound.” ➔ focus: primarily soundness
assembly code” to construct a proof tree in basic logic. ➔ the payoff: machine-checked, thus guaranteed correct
14
service, job completion, response-time bounds, … ➔ goal: as simple and tasteful as possible
, where , then is a response-time bound.” ➔ focus: primarily soundness
assembly code” to construct a proof tree in basic logic. ➔ the payoff: machine-checked, thus guaranteed correct
14
service, job completion, response-time bounds, … ➔ goal: as simple and tasteful as possible
, where , then is a response-time bound.” ➔ focus: primarily soundness
assembly code” to construct a proof tree in basic logic. ➔ the payoff: machine-checked, thus guaranteed correct
14
service, job completion, response-time bounds, … ➔ goal: as simple and tasteful as possible
, where , then is a response-time bound.” ➔ focus: primarily soundness
assembly code” to construct a proof tree in basic logic. ➔ the payoff: machine-checked, thus guaranteed correct
14
Goal: Short, Obvious, and Natural Definitions
(* Consider any uniprocessor schedule. *) Variable sched: schedule Job. (* Let j be any job. *) Variable j: Job. (* First, we define whether a job j is scheduled at time t, ... *) Definition scheduled_at (t: time) := sched t == Some j.
15
(* ...which also yields the instantaneous service received by job j at time t (i.e., either 0 or 1). *) Definition service_at (t: time) : time := scheduled_at t. (* Based on the notion of instantaneous service, we define the cumulative service received by job j during any interval [t1, t2). *) Definition service_during (t1 t2: time) := \sum_(t1 <= t < t2) service_at t.
16
(* Consider any uniprocessor schedule. *) Variable sched: schedule Job. (* Let j be any job that is to be scheduled. *) Variable j: Job. Lemma service_at_most_one: ∀ t, service_at sched j t <= 1.
Goal: natural, explicit, readable, as short as sensible.
17
(* ...which implies that the cumulative service received by job j in any interval of length delta is at most delta. *) Lemma cumulative_service_le_delta: ∀ t delta, service_during sched j t (t + delta) <= delta.
18
NOTE: proof scripts are not intended for human consumption.
Lemma cumulative_service_le_delta: ∀ t delta, service_during sched j t (t + delta) <= delta. Proof. unfold service_during; intros t delta. apply leq_trans with (n := \sum_(t <= t0 < t + delta) 1); last by simpl_sum_const; rewrite addKn leqnn. by apply leq_sum; intros t0 _; apply leq_b1. Qed.
19
How could analysis still be unsound?
➔ highly unlikely, but not impossible ➔ proof checking kernel: small, simple, widely used
➔ possible in principle, but... ➔ …ruled out in Prosa by development process
➔ readable specification + community review!
20
How could analysis still be unsound?
➔ highly unlikely, but not impossible ➔ proof checking kernel: small, simple, widely used
➔ possible in principle, but... ➔ …ruled out in Prosa by development process
➔ readable specification + community review!
20
How could analysis still be unsound?
➔ highly unlikely, but not impossible ➔ proof checking kernel: small, simple, widely used
➔ possible in principle, but... ➔ …ruled out in Prosa by development process
➔ readable specification + community review!
20
How could analysis still be unsound?
➔ highly unlikely, but not impossible ➔ proof checking kernel: small, simple, widely used
➔ possible in principle, but... ➔ …ruled out in Prosa by development process
➔ readable specification + community review!
20
Learn more at: prosa.mpi-sws.org
… or propose a better way to obtain bullet-proof analysis!
21