Component- -based construction based construction - - requirements requirements Component Examples of existing frameworks: • Sequential functions with logical operators and delay operators for building circuits • Process algebras • Distributed algorithms define generic gl for a given property P e.g. token ring, clock synchronization … Pb: Find a set of glue operators meeting the following requirements: • Expressiveness (discussed later) • Incremental description • Correctness-by-construction 24
Component- -based construction based construction – – incremental description incremental description Component 1. Decomposition of gl gl_1 gl gl_2 C 1 ≅ C 1 C 2 C n C 2 C n 2. Flattening of terms gl2 gl ≅ gl1 c 2 c’ 2 c 2 c’ 2 c 1 c’ 1 c 1 c’ 1 Flattening can be achieved by introducing an idempotent operation ⊕ such that (GL, ⊕ ) is a commutative monoid and gl(gl’( C 1 ,C 2 ,.., C n )) ≅ gl ⊕ gl’( C 1 ,C 2 ,.., C n ) 25
Component- -based based construction construction - - Correctness Correctness by construction : by construction : Component compositionality compositionality ☺ gl Build correct systems ☺ ☺ from correct components gl ~ ~ sat P i c i sat gl(P 1 , ..,P n ) implies ∀ gl ∃ gl c n c 1 We need compositionality results about preservation of progress properties such as deadlock-freedom and liveness. 26
Component- -based based construction construction - - Correctness Correctness by construction : by construction : Component composability composability gl gl ☺ � Make the new without ☺ ☺ breaking the old gl gl’ sat P’ sat P and c 1 c n c 1 c n • We badly need composabilty results • Property stability phenomena are poorly understood, such as gl ⊕ gl’ - feature interaction sat P ∧ P’ implies c 1 c n - non composability of scheduling policies Property stability phenomena are poorly understood • feature interaction • non composability of scheduling algorithms 27
Component- -based construction based construction - - compositionality vs. composability compositionality vs. composability Component Layering/composability Integration/compositionality 28
Overview • Modeling real-time systems – The problem – Heterogeneity – Component-based construction • Interaction Models – Definition – Composition – Examples – Deadlock-freedom preservation • Timed systems – Definition – Examples Laser 2005 - Summer School on Software Engineering 29
Component-based modeling – The BIP framework Layered component model Scheduler: dynamic priority rules Interaction Model: Connectors + Interactions B E H A V I O R Composition (incremental description) PR1 ⊕ PR2 ⊕ PR12 PR1 PR2 IM1 IM1 IM1 ⊗ IM2 ⊗ IM12 IM2 || Laser 2005 - Summer School on Software Engineering 30
Interaction models Interaction models Connectors are maximal sets of compatible actions Interactions are subsets of connectors; they are defined by using typing (complete , incomplete ) : either they are maximal or they contain some complete interaction tick1 tick2 tick3 out1 in2 in3 Interactions: {tick1,tick2,tick3}, {out1}, {out1,in2}, {out1,in3}, {out1,in2, in3} Laser 2005 - Summer School on Software Engineering 31
Interaction nteraction models models - - examples examples I cl1,cl2 cl1 cl2 CN:{cl1,cl2} cl1 cl2 MI: ∅ out, in CN:{out,in} out in MI: {out} out in in1,out,in2 out in1 CN:{in1,out,in} out,in1 MI: {out} in1,in2 out,in2 in1 in2 in2 out Laser 2005 - Summer School on Software Engineering 32
Interaction models - definition Given a set of atomic components K with disjoint action vocabularies A i for i ∈ K, • A connector γ is a non empty subset of ∪ i ∈ K Ai such that | γ ∩ Ai| ≤ 1 • Interactions are non empty subsets of connectors • An interaction model im is a pair im=( Γ , ∆ ) such that − Γ is a set of non comparable connectors − ∆ is a set of minimal complete interactions with ∀δ∈∆ ∃γ ∈Γ. δ⊆γ. The interactions of im = Γ ∪{α | ∃δ∈∆.δ⊆ α⊆γ} γ 1 γ 2 δ 1 δ 2 δ 3 δ 4 Laser 2005 - Summer School on Software Engineering 33
Interaction models – – operational semantics operational semantics Interaction models CN: {put,get},{prod},{cons} MI: {prod},{cons} prod put get cons Operational Semantics × prod × cons put get {put, get} × × get put prod cons 34
Interaction models - - composition composition Interaction models CN[P,C]: {put,get} MI[P,C]: ∅ CN[P]: {put},{prod} CN[C]: {get}, {cons} MI[P]: {prod} MI[C]: {cons} ⎢⎢ prod put get cons CN: {put,get},{prod},{cons} MI: {prod},{cons} prod put get cons 35
Interaction models - - composition composition Interaction models a 3 a 4 a 1 a 2 a 5 a 6 a 7 a 8 a 9 a 10 K 1 K 2 a 11 a 12 IM[K 1 ,K 2 ]: CN[K 1 ,K 2 ] : {a 1 , a 2 , a 3 ,a 4 }, {a 11 , a 12 } MI[K 1 ,K 2 ] : {a 1 ,a 2 ,a 3 ,a 4 }, {a 11 } IM[K 2 ]: IM[K 1 ]: CN[K 2 ] : {a 3 , a 4 }, {a 7 , a 10 }, {a 8 , a 10 } CN[K 1 ] : {a 1 , a 2 }, {a 5 , a 9 },{a 6 , a 9 } MI[K 2 ] : a 10 MI[K 1 ] : a 5 , a 6 , a 11 ⎢⎢ a 3 a 4 a 10 a 1 a 2 a 9 K 2 K 1 a 7 a 8 a 12 a 5 a 6 a 11 36
Interaction models – – composition (2) composition (2) Interaction models IM[K 1 ,K 2 ]: CN[K 1 ,K 2 ] : {a 1 , a 2 , a 3 ,a 4 }, {a 11 , a 12 } MI[K 1 ,K 2 ] : {a 1 ,a 2 ,a 3 ,a 4 }, {a 11 } IM[K 2 ]: IM[K 1 ]: CN[K 2 ] : {a 3 , a 4 }, {a 7 , a 10 }, {a 8 , a 10 } CN[K 1 ] : {a 1 , a 2 }, {a 5 , a 9 },{a 6 , a 9 } MI[K 2 ] : a 10 MI[K 1 ] : a 5 , a 6 , a 11 ⎢⎢ a 3 a 4 a 10 a 1 a 2 a 9 K 2 K 1 a 7 a 8 a 12 a 5 a 6 a 11 IM[K 1 ∪ K 2 ] = IM[K 1 ] ⊗ IM[K 2 ] ⊗ IM[K 1 ,K 2 ] CN[K 1 ∪ K 2 ] = max CN[K 1 ] ∪ CN[K 2 ] ∪ CN[K 1 ,K 2 ] MI[K 1 ∪ K 2 ] = min MI[K 1 ] ∪ MI[K 2 ] ∪ MI[K 1 ,K 2 ] } a 1 a 2 a 9 a 3 a 4 a 10 a 5 a 6 a 11 a 7 a 8 a 12 K 1 ∪ K 2 37
Interaction models – – results results [ [Goessler Goessler Sifakis] Sifakis] Interaction models Incremental commutative composition encompassing blocking and non blocking interaction sender receiver1 out1 in1 receiver2 in2 = sender receiver1 sender receiver1 receiver2 receiver2 38
Interaction models - - mod8 counter mod8 counter Interaction models a0 a1 b0 b1 c0 c1 a0 a1 b0 b1 c0 c1 a1,b1,c0 a1,b1,c1 a1,b0 a1,b1 b1,c0 b1,c1 a1,c0 a1,c1 a0 a1 b0 b1 c0 c1 39
Interaction models- -mod8 counter(2) mod8 counter(2) Interaction models a0 a1 b0 b1 c0 c1 a0 a1 b0 b1 c0 c1 a0 {a1,b1,c1} a0 {a1,b0} b0 a1 b1 {a1,b1} {a1,b0} a0 a0 b1 a1 a0 b0 {a1,b1,c0} {a1,b0} a0 40
Interaction models - commitment protocol CN : {vote} ∪ {vote_i} i ∈ I , {commit} ∪ {commit_i} i ∈ I , {yes} ∪ {yes_i } i ∈ I MI: abort, no, no_i for i ∈ I vote yes commit vote_1 yes_1 commit_1 vote_1 vote yes_1 no_1 yes no commit_1 commit abort PROCESS_1 ARBITER Laser 2005 - Summer School on Software Engineering 41
Interaction models - commitment protocol (2) CN : {vote} ∪ {vote_i} i ∈ I , {commit} ∪ {commit_i} i ∈ I , {yes,yes_i } i ∈ I for i ∈ I MI: abort, no, no_i, abort_i for i ∈ I vote yes commit vote_1 yes_1 commit_1 vote yes vote_1 no yes_1 no_1 abort_1 commit abort commit_1 PROCESS_1 ARBITER Laser 2005 - Summer School on Software Engineering 42
Interaction models - - checking for deadlock checking for deadlock- -freedom freedom Interaction models For a given system (set of components + interaction model), its dependency graph is a bipartite labeled graph with Nodes N = Set of components ∪ Set of minimal interactions Edges E - ( α ,a,k) ∈ E if α is an interaction, a ∈α is an incomplete action of k - (k1,a1, α ) ∈ E if a1 ∈α is an action of k1 k1 a1 a a2 k k2 a3 {a,a1,a2,a3} k3 Blocking condition for an incomplete action a: Bl(a) = en(a) ∧ ¬ (en(a1) ∧ en(a2) ∧ en(a3) ) 43
Interaction models - - checking for deadlock checking for deadlock- -freedom (2) freedom (2) Interaction models Theorem 1 : A system is deadlock-free if its atomic components have no deadlocks and its dependency graph has a backward closed subgraph such that for all its circuits ω Bl ( ω ) = ∧ a ∈ω Inc( ω ) ∧ Bl(a) = false where Inc( ω )= ∧ k ∈ω Inc(k) with Inc(k) the set of the states of k from which only incomplete actions can be executed Inc(k1) a1 k1 a2 Bl(a2) Bl(a1) k4 k2 Inc(k2) Bl(a3) Inc(k4) Bl(a4) a4 a3 k3 Inc(k3) 44
Interaction models - checking for deadlock-freedom: example consumer 1 get 1 CN: {put,get 1 ,get 2 } producer put MI: {put,get 1 }, {put,get 2 } consumer 2 get 2 Laser 2005 - Summer School on Software Engineering 45
Interaction models - checking for deadlock-freedom: example get 1 n 1 : {put,get 1 } consumer 1 get 1 put put get 1 producer put get 2 put get 2 n 2 : {put, get 2 } consumer 2 get 2 ω 1 =( producer, n 1 , consumer 2 , n 2 ) Bl( ω 1 ) =false ω 2 =( producer, n 2 , consumer 1 , n 1 ) Bl( ω 2 ) =false ω 3 =( consumer 1 , n 1 ,consumer 2 , n 2 , ) Bl( ω 3 )=Inc( ω 3 ) ∧ en(get 1 ) ∧ ¬ (en(get 2 ) ∧ en(put)) ∧ en(get 2 ) ∧ ¬ (en(get 1 ) ∧ en(put)) =Inc( ω 3 ) ∧ en(get 1 ) ∧ en(get 2 ) ∧ ¬ en(put) Deadlock-freedom if Inc(producer) ∧¬ en(put) =false Laser 2005 - Summer School on Software Engineering 46
Interaction models - checking for individual deadlock-freedom Definition: A component of a system is individually deadlock-free if it can always perform some action Theorem2 : Sufficient condition for individual deadlock-freedom of a component k • k belongs to a backward closed subgraph of a dependency graph satisfying conditions of Theorem 1; • In any circuit of this subgraph, all its components are controllable with respect to their outputs i.e. it is always possible by executing complete interactions, to reach states enabling all the output actions of the component; • All the n-ary interactions for n>2 are strong synchronizations Laser 2005 - Summer School on Software Engineering 47
Interaction models - discussion • The distinction interaction model / behavior is crucial or the model construction methodology. Layered description => separation of concerns => associativity • Different from other approaches e.g. process calculi, which combine behavior composition operators and restriction/hiding operators at the same level. \a ⊕ \a’ ((P1||P2)\a ||P3)\a’ P1||P2||P3 • Framework encompassing strict and non strict synchronization Laser 2005 - Summer School on Software Engineering 48
Overview • Modeling real-time systems – The problem – Heterogeneity – Component-based construction • Interaction Models – Definition – Composition – Examples – Deadlock-freedom preservation • Timed systems – Definition – Examples Laser 2005 - Summer School on Software Engineering 49
Timed systems – from untimed to timed systems Methodology : UNTIMED • Avoid over-specification which P 1 P 2 ⎜⎜ may lead to inconsistency • Make explicit all the consequences of the constraints � on interactions Timing Constraints ⊕ • Define ⎜⎜ T so as to preserve properties such as well- � timedness, and deadlock- freedom TIMED ⎜⎜ T P 2 T P 1 T Laser 2005 - Summer School on Software Engineering 50
Timed systems – untimed systems : definition Untimed system: A set of transitions a, g, f s s’ where • S is a finite set of control states • A is a set of actions • → ⊆ S × A × S, a transition relation • X a set of variables Each transition is labeled with a guard and a transfer function Operational semantics: A set of transitions a (s,x) (s’,f(x)) where x is a valuation of X such that g(x)=true Laser 2005 - Summer School on Software Engineering 51
Timed Systems - definition Timed system: A set of transitions φ s φ s’ a, g, u, f s s’ where • u is an urgency condition such that u ⇒ g • Each control state s is labeled with a function φ s such that φ s (x,t) is the valuation of state variables when time progresses by t from state (s,x). Informal semantics: • Discrete transitions as for untimed systems • Notion of time progress: time can progress at s only if the urgency conditions of the transitions issued from s are false Laser 2005 - Summer School on Software Engineering 52
Timed Systems - a periodic process A periodic process of period T>0 and execution time E, (E ≤ T). wait t ≤ T-E t=T-E t=T t=T t:=0 sleep x:=0 exec (x=E) (x=E) t’=x’=1 at all states Laser 2005 - Summer School on Software Engineering 53
Timed Systems - definition φ s s bi b1 bi=(ai,gi,ui,fi) b2 s1 s2 si A state is a pair (s,x) where x is a valuation of X Discrete Transitions (s,x) - ai → (si,fi(x)/x) if gi(x)=true Time steps (s,x) - t → (s, φ s (x,t)) if ∀ t’<t tps( φ s (x, t’)) where tps = ¬( ∨ i ui) Time can progress as long as no urgency condition is true Laser 2005 - Summer School on Software Engineering 54
Timed Systems - relating urgency and time progress tp=x ≠ 5 ∧ (y ≤ 4 ∨ y>7) 3≤ x ≤ 5 4<y ≤ 7 3≤ x ≤ 5 4<y ≤ 7 x=5 4<y ≤ 7 a b a b Laser 2005 - Summer School on Software Engineering 55
Timed Systems – urgency types s s’ b b=(a,g,u,f) g : a may be executed u : a must be executed u ⇒ g Invariant: If a cannot be executed then time can progress at s g u=g eager ( ε ) u=g ↓ delayable ( δ ) u=false lazy ( λ ) Laser 2005 - Summer School on Software Engineering 56
Timed Systems: Urgency types Replace urgency conditions by urgency types preserved by restriction of guards g λ : lazy guard (u=false) g ε : eager guard (u=g) g δ : delayable guard (u=g ↓ ) Any TS can be transformed into an equivalent one with urgency types s s s a a a a a u ε ( g ∧¬ u , false) ( g ∧¬ u ) λ ( u,u) ( g,u ) s’ s’ s’ Laser 2005 - Summer School on Software Engineering 57
Timed Systems - a periodic process A periodic process of period T>0 and execution time E, (E ≤ T). (t=T ) ε t:=0 (t ≤ T-E) δ wait sleep x:=0 exec (x=E) ε t’=x’=1 at all states Laser 2005 - Summer School on Software Engineering 58
Timed systems – guard restriction TS’ TS s1 s1 g’ g u’ u restriction s2 s2 g’ ⇒ g u ⇒ u’ TS’ simulates TS Laser 2005 - Summer School on Software Engineering 59
Timed systems – guard restriction +liberal maximal urgency u = g g (g,u) (g,g) (g’,u’) g’ (g”,u”) (u,u) +urgent u’ u Laser 2005 - Summer School on Software Engineering 60
Timed Systems as transition systems Q : set of states → ⊆ Q × A × Q q -a → q’ untimed transition → ⊆ Q × R + × Q q -t → q’ time step Property (time additivity) q 1 -t 1 → q 2 and q 2 –t 2 → q 3 implies q 1 –t 1 +t 2 → q 3 A run is a maximal sequence of transitions from states q 0 q 1 … q i … such that q i - t i → q i +1 or q i - a i → q i +1 time [ q 0 , q i ] = Σ k ≤ i t k q 0 q 1 … q i … is time divergent if ∀ k ∈ N ∃ i time [ q 0 , q i ] > k Important : Well-timed systems (only time divergent runs !) Laser 2005 - Summer School on Software Engineering 61
Timed systems as transition systems - discrete vs. continuous a TIMEOUT[2]b : execute a within 2 otherwise execute b 2 2 1 a 1 b 0.5 a 0.5 b a 0.5 0.5 a a a time unit 1 time unit 0.5 2 t 2-t t-2 a t b a a a a a dense time Laser 2005 - Summer School on Software Engineering 62
Timed systems as transition systems - discrete vs. continuous a (bc TIMEOUT[1] AL2) TIMEOUT[1] AL1 for time unit 1 1 AL1 a possible abc within 0 1 b AL2 c Laser 2005 - Summer School on Software Engineering 63
Timed systems as transition systems - discrete vs. continuous a (bc TIMEOUT[1] AL2) TIMEOUT[1] AL1 for time unit 0.25 0.25 AL1 a a a a possible abc within 1.75 AL2 b b b AL2 b c c c c Laser 2005 - Summer School on Software Engineering 64
Timed systems as Transition Systems - discrete vs. continuous a (bc TIMEOUT[1] AL2) TIMEOUT[1] AL1 for dense time AL1 possible abc within <2 a a a a a AL2 b b b AL2 b c c c c Laser 2005 - Summer School on Software Engineering 65
Overview • Modeling real-time systems – The problem – Heterogeneity – Component-based construction • Interaction Models – Definition – Composition – Examples – Deadlock-freedom preservation • Timed systems – Definition – Examples Laser 2005 - Summer School on Software Engineering 66
Timed systems – from untimed to timed systems Methodology : UNTIMED • Avoid over-specification which P 1 P 2 ⎜⎜ may lead to inconsistency • Make explicit all the consequences of the constraints � on interactions Timing Constraints ⊕ • Define ⎜⎜ T so as to preserve properties such as well- � timedness, and deadlock- freedom TIMED ⎜⎜ T P 2 T P 1 T Laser 2005 - Summer School on Software Engineering 67
Scheduler modeling - example A periodic process of period T and completion time C sleep Actions a (u) a: arrive t=T (c) b: begin t:=0 (u) f: finish wait (c) p: preempt b (c) r: resume t ≤ T-E x:=0 p x<E x=E t’=x’=1 at all states f except stop (x’=0) use stop r x<E Laser 2005 - Summer School on Software Engineering 68
Overview (2) • Scheduler modeling – The role of schedulers – Control invariants – Scheduler specifications – Composability results • Timed systems with priorities – Definition – Composition of priorities – Correctness-by-construction results • Tools and applications – The IF toolset – The BIP framework • General Discussion Laser 2005 - Summer School on Software Engineering 69
Scheduler modeling - the role of schedulers A scheduler is a controller restricting access to resources by triggering controllable interactions so as to respect timing constraints (state predicates) K 0 =K SCH ∧ K POL • K SCH scheduling constraints (timing constraints on processes) • K POL scheduling policy Scheduler for K SCH ∧ K POL controllable interaction state Interactions requirem Timed Model QoS Processes Laser 2005 - Summer School on Software Engineering 70
Scheduler modeling - control invariants A control invariant K ⇒ K 0 u u K K 0 c t u ILLEGAL STATES • Control invariants are preserved by uncontrollable actions • It is possible to maintain the system in K by executing controllable actions Laser 2005 - Summer School on Software Engineering 71
Scheduler modeling - restriction by a constraint The restriction of TS by a constraint K is a timed system TS/K TS/K TS s1 s1 a c a c restriction g ∧ K ∧ pre 12 (K) g s2 s2 In TS/K, K holds right before and right after the execution of any controllable action If K is a control invariant of TS then TS/K, is the scheduled (controlled) system Laser 2005 - Summer School on Software Engineering 72
Scheduler modeling – controller synthesis There exists a scheduler maintaining K 0 if there exists a non empty control invariant K , K ⇒ K 0 For given K 0 , the maximal control invariant K, K ⇒ K 0 can be computed as the result of a synthesis semi- algorithm SYNTH(TS,K 0 ) = lim I {K i } where K i+1 = K i+1 ∧ contr-pre ( K i ) from K 0 All states from which TS can be led to K i no t contr-pre (K i ) matter how the c u environment behaves K i Laser 2005 - Summer School on Software Engineering 73
Scheduler modeling - invariants vs. control invariants Def: K is an invariant of TS if it is preserved by the transition relation (TS sat inv(K)) • Any invariant is a control invariant • K is a control invariant of TS if K is an invariant of TS/K, that is TS/K sat inv(K • TS u sat inv(K) implies TS/K sat inv(K) K’ K Laser 2005 - Summer School on Software Engineering 74
Scheduler modeling – composability of control invariants - Are control invariants preserved by conjunction? - Is it possible to apply a composition principle by computing control invariants ? Def: A control invariant K1 of TS is composable if for all constraints K2, K1 is a control invariant of TS/K2 • If K1 is composable and K2 is a control invariant of TS/K1 then TS/(K1 ∧ K2) sat inv (K1 ∧ K2) • K is composable iff TS u sat inv(K) Laser 2005 - Summer School on Software Engineering 75
Scheduler modeling – composability of control invariants s2 s1 (t2=5) t1=15 t2:=0 t1:=0 w2 w1 b1 b2 ∧¬ e2 ¬ e1 ∧ (t1 ≤ 10) (t2 ≤ 3) x1:=0 x2:=0 x1=5 x2=2 e2 e1 TS1 ∪ TS2 /K_mutex K_mutex = ¬ (e1 ∧ e2) is a composable control invariant of TS1 ∪ TS2 Laser 2005 - Summer School on Software Engineering 76
Scheduler modeling – composability of control invariants s2 s1 (t2=5) t1=15 t2:=0 t1:=0 w2 w1 b1 b2 ∧¬ e2 ¬ e1 ∧ (t1 ≤ 10) (t2 ≤ 3) x1:=0 x2:=0 x1=5 x2=2 e2 e1 TS1 ∪ TS2 /K_mutex K_df = K_df1 ∧ K_df2 is a control invariant of TS1 ∪ TS2 K_df is not a control invariant of TS1 ∪ TS2/K_mutex Laser 2005 - Summer School on Software Engineering 77
Scheduler modeling – the scheduling constraint K SCH The scheduling constraint K SCH relates timing constraints of 3 different kinds • from the execution platform e.g. execution times, latency times • from the external environment about arrival times of triggering events e.g. periodic tasks • user requirements e.g. QoS, which are timing constraints relating events of the real-time system and events of its environment e.g. deadlines, jitter Laser 2005 - Summer School on Software Engineering 78
Scheduler modeling – the scheduling constraint K SCH Each shared resource induces a Sleep partition {Sleep, Wait, Use}. arrive T min ≤ t ≤ T max t:=0 Wait Arrival time (t) begin Execution time (x) t ≤ D - E max x:=0 Deadline D Use t ≤ D finish E min ≤ x ≤ E max t ≤ D Laser 2005 - Summer School on Software Engineering 79
Scheduler modeling – the scheduling constraint K SCH K SCH = ∧ i K i SCH s a t=T where K i SCH expresses the property that no t:=0 timing constraint is violated in process i. w b t ≤ T- E For timelock-free process models with bounded guards, x:=0 x=E schedulability boils down to deadlock- f freedom of processes u K SCH = s ∧ (t ≤ T) ∨ w ∧ (t ≤ T-E) ∨ u ∧ (x ≤ E) Laser 2005 - Summer School on Software Engineering 80
Scheduler modeling – the scheduling policy K POL K POL is the conjunction of scheduling policies for the set R of shared resources K POL = ∧ r ∈ R K r CONF ∧ K r K r POL = K r POL where ADM • K r CONF says how conflicts for the acquisition of resource r are resolved e.g. EDF, RMS, LLF • K r ADM says which requests for r are considered by the scheduler at a state e.g. masking Laser 2005 - Summer School on Software Engineering 81
Scheduler modeling – the scheduling policy K POL K POL : scheduling policy K CONF : Conflict resolution K ADM : admission control r i r n r 1 r i r n r 1 K iADM K nADM K 1CONF K iCONF K nCONF K 1ADM Laser 2005 - Summer School on Software Engineering 82
Scheduler modeling – the scheduling policy K POL : example K POL for the Priority Ceiling Protocol Admission control: “Process P is eligible for resource r if the current priority of P is higher than the ceiling priority of any resource allocated to a process other than P” Conflict resolution: “ The CPU is allocated to the process with the highest current priority” Laser 2005 - Summer School on Software Engineering 83
Scheduler modeling – composability results • Any constraint K_pol is a composable control invariant that is, SYNTH(TS, K _pol ) = TS/ K_pol • Decomposition of the global synthesis problem SYNTH(TS, K _sched ∧ K _pol ) = SYNTH (TS/K _pol , K _sched ) • Reduction to verification of SYNTH(TS, K_sched) Choose a scheduling policy K _pol such that the 1. conflicts on controllable actions of TS/K _pol are resolved Check TS/K _pol sat inv (K_sched) 2. Laser 2005 - Summer School on Software Engineering 84
Composability results - application A scheduler design methodology supported by the Prometheus tool connected to Kronos K_ sced trace 1 K_ pol2 K_ pol1 trace2 K:= K_sched; while ¬ (TS/K sat inv(K) ) do choose K_pol; K:= K_sched ∧ K_pol od Laser 2005 - Summer School on Software Engineering 85
Overview (2) • Scheduler modeling – The role of schedulers – Control invariants – Scheduler specifications – Composability results • Timed systems with priorities – Definition – Composition of priorities – Correctness-by-construction results • Tools and applications – The IF toolset – The BIP framework • General Discussion Laser 2005 - Summer School on Software Engineering 86
Timed Systems with priorities - scheduling and priorities If K is a constraint characterizing a set of deadlock- free states of TS then there exists a set of priority rules pr such that pr(TS) preserves K For any control invariant K of TS there exists a set of dynamic priority rules pr such that the scheduled system TS/K = pr(TS) Any feasible scheduling policy K POL induces a restriction that can be described by priorities Laser 2005 - Summer School on Software Engineering 87
Timed Systems with priorities s a 2 a 1 g 1 g 2 〈 exec 1 exec 2 Priority Strengthened guard a 1 〈 0 a 2 g 1 ’ = g 1 ∧ ¬ g 2 a 1 〈 5 a 2 g 1 ’ = g 1 ∧ ¬〈5〉 g 2 g 1 ’ = g 1 ∧ ¬〈 ∞ 〉 g 2 a 1 〈 ∝ a 2 Notation: 〈 k 〉 g(X) = ∃ t ≤ k g(X+t) (= eventually g within time k) t ≤ k g(X+t) (= eventually g within time k) Laser 2005 - Summer School on Software Engineering 88
Timed Systems with priorities a 1 〈 k a 2 means that a 1 is disabled when a 2 will be enabled within time k Def: A priority order is a set of partial orders 〈 = { 〈 k ⎜ partial order on A } k ∈ R+ s.t. a 1 〈 k a 2 ∧ a 2 〈 m a 3 ⇒ a 1 〈 k+m a 3 (transitivity) 〈 s s g 1 ’ g n ’ g 1 g n a 1 a n a 1 a n sn s1 sn s1 ( ∧ ¬< k > g m ) g i ’=g i ∧ 〈 k ∈ 〈 ai 〈 k am Laser 2005 - Summer School on Software Engineering 89
Timed Systems with priorities A timed system with priorities is a pair (TS, pr) where pr is a set of priority rules pr = {C i , 〈 i } i with • {C i } i is a set of disjoint time invariant predicates • { 〈 i } i is a set of priority orders pr = { C i → 〈 i } i TS’ TS a k g i ’ a k g i ( ∧ g i ’ = g i ∧ ∧ C → 〈 ∈ pr ( C ⇒ ∧ ¬< k > g m ) ) 〈 k ∈ 〈 ai 〈 k am Activity Preservation Theorem: ◊∨ i g i = ◊∨ i g i ’ Laser 2005 - Summer School on Software Engineering 90
Timed Systems with priorities - fixed priority policy w1 ∧ w2 → b1 〈 k b2 for some k s1 s2 a1 a2 t1=T1 t2=T2 t1:=0 t2:=0 w1 w2 b2 b1 t2 ≤ T2-E2 t1 ≤ T1-E1 x2:=0 x1:=0 # x1=E1 x2=E2 e1 e2 f1 f2 Laser 2005 - Summer School on Software Engineering 91
Timed Systems with priorities - FIFO policy t1 ≤ t2 → b1 〈 0 b2 t2 ≤ t1 → b2 〈 0 b1 s1 s2 a1 a2 t1=T1 t2=T2 t1:=0 t2:=0 w1 w2 b2 b1 t2 ≤ T2-E2 t1 ≤ T1-E1 x2:=0 x1:=0 # x1=E1 x2=E2 e1 e2 f1 f2 Laser 2005 - Summer School on Software Engineering 92
Timed Systems with priorities - LLF policy L1 ≤ L2 → b2 〈 0 b1 L2 ≤ L1 → b1 〈 0 b2 where Li=Ti-Ei-ti, s1 s2 a1 a2 t1=T1 t2=T2 t1:=0 t2:=0 w1 w2 b2 b1 t2 ≤ T2-E2 t1 ≤ T1-E1 x2:=0 x1:=0 # x1=E1 x2=E2 e1 e2 f1 f2 Laser 2005 - Summer School on Software Engineering 93
Priority Systems - - Composition of priorities Composition of priorities Priority Systems pr2 pr1 ≠ pr1 pr2 b 〈 2 c a 〈 1 b c c b a c b b 〈 2 c a c a c a 〈 1 b 94
Priority Systems - - Composition of priorities Composition of priorities Priority Systems We take: pr2 pr1 ⊕ pr2 pr1 = pr1 ⊕ pr2 is the least priority containing pr1 ∪ pr2 Results : •The operation ⊕ is partial, associative and commutative • pr1(pr2(B)) ≠ pr1(pr2(B)) • pr1 ⊕ pr2(B) refines pr1 ∪ pr2(B) refines pr1(pr2(B)) • Priorities preserve deadlock-freedom 95
Timed Systems with priorities – mutual exclusion w1 ∧ e2 → b1 〈 ∞ f2 w2 ∧ e1 → b2 〈 ∞ f1 s1 s2 a1 a2 t1=T1 t2=T2 t1:=0 t2:=0 w1 w2 b2 b1 t2 ≤ T2-E2 t1 ≤ T1-E1 x2:=0 x1:=0 x1=E1 x2=E2 e1 e2 f1 f2 Idea: Give infinitely higher priority to the process using the resource 96
Timed Systems with priorities – mutual exclusion s1 s2 a1 a2 t1=T1 t2=T2 t1:=0 t2:=0 w1 w2 b2 b1 ( ¬ e1 ∨ x1 ≤ E1 ) ∧ t2 ≤ T2-E2 t1 ≤ T1-E1 ∧ ( ¬ e2 ∨ x2 ≤ E2) x2:=0 x1:=0 x1=E1 x2=E2 e1 e2 f1 f2 The behavior after application of mutual exclusion constraints 97
Timed Systems with priorities – mutual exclusion Mutex on R’ : b1 〈∞ f2 b2 〈∞ { f1, b1’} Mutex on R : b1’ 〈∞ { f2, b2 } b2’ 〈∞ f1 w2 w1 a2 a1 b1 b2’ s1 s2 R’ R f2 f1 b1’ b2 RR’ RR’ Risk of deadlock: The composition is not a priority order ! Laser 2005 - Summer School on Software Engineering 98
Timed Systems with priorities – mutual exclusion + FIFO policy t1 ≤ t2 → b1 〈 0 b2 t2 ≤ t1 → b2 〈 0 b1 w1 ∧ e2 → b1 〈 ∞ f2 w2 ∧ e1 → b2 〈 ∞ f1 s1 s2 a1 a2 t1=T1 t2=T2 t1:=0 t2:=0 w1 w2 b2 b1 t2 ≤ T2-C2 t1 ≤ T1-C1 x2:=0 x1:=0 x1=C1 x2=C2 e1 e2 f1 f2 99
The BIP framework -fixed priority preemptive scheduling (1) b i 〈 b j , r i 〈 r j , r i 〈 b j , b i 〈 r j (access to the resource – priority preserved by composition) {b i ,p j } 〈 f j , {r i ,p j } 〈 f j , n ≥ I > j ≥ 1 (non pre-emption by lower pty tasks) CN: {b i ,p j } {r i ,p j } for n ≥ i,j ≥ 1 MI: a i , f i , b i for n ≥ i ≥ 1 s j s 1 s i s n a j a 1 a i a n w j w 1 w i w n f j f 1 f i f n b j b i b 1 b n e j e 1 e i e n r j r 1 p j r i r n p 1 p i p i p n e j ’ e 1 ’ e i ’ e i ’ e n ’ Laser 2005 - Summer School on Software Engineering 100
Recommend
More recommend
