Component-based Modeling of Real-Time Systems LASER 2005 Joseph - - PowerPoint PPT Presentation

▶
component based modeling of real time systems
SMART_READER_LITE
LIVE PREVIEW

Component-based Modeling of Real-Time Systems LASER 2005 Joseph - - PowerPoint PPT Presentation

Sep 23, 2023 167 likes •1.98k views

Component-based Modeling of Real-Time Systems LASER 2005 Joseph Sifakis VERIMAG sifakis@imag.fr In collaboration with Gregor Goessler (INRIA) Ananda Basu, Marius Bozga, Susanne Graf (Verimag ) Laser 2005 - Summer School on Software

slide-1
SLIDE 1

Laser 2005 - Summer School on Software Engineering 1

Component-based Modeling

  • f Real-Time Systems

LASER 2005

Joseph Sifakis VERIMAG

sifakis@imag.fr In collaboration with Gregor Goessler (INRIA) Ananda Basu, Marius Bozga, Susanne Graf (Verimag)

slide-2
SLIDE 2

Laser 2005 - Summer School on Software Engineering 2

Modeling real-time systems - motivation Modeling plays a central role in systems engineering

  • Can profitably replace experimentation on actual systems
  • Can provide a basis for rigorous system development and implementation

(model-based approaches).

Modeling real-time systems

  • Raises hard problems about concepts, languages and their semantics e.g.

What is an architecture? What is a scheduler? How synchronous and asynchronous systems are related?

  • Requires a deep understanding of basic system design issues such as

development methodologies (combination of techniques and tools, refinement) and architecture design principles.

slide-3
SLIDE 3

Model Model-

  • based Development

based Development

Move from physical prototypes to virtual prototypes (models) with obvious advantages : minimize costs, flexibility, genericity, formal validation is a possibility

Validation Tools Modeling Environment

Modeling and validation environments for complex real-time systems

  • Libraries of Components
  • ex. HW, SW, Models of continuous dynamic systems
  • Languages and tools for assembling components

Synthesize embedded software from domain-specific models

  • ex. Matlab, SystemC, UML, SDL.

Laser 2005 - Summer School on Software Engineering 3

slide-4
SLIDE 4

Laser 2005 - Summer School on Software Engineering 4

Modeling real-time systems - objectives Provide a rigorous and general framework for modeling,

  • Based on a general concept of architecture as a means to organize

computation (behavior, interaction, control)

  • Encompassing heterogeneous description, specific styles and paradigms, e.g.

synchronous and asynchronous execution heterogeneous interaction (strong, weak, event-driven, state- driven) architecture styles e.g. client-server, blackboard architecture

  • Equipped with rules for correctness-by-construction wrt. generic properties

such as deadlock-freedom, liveness, safety.

  • Providing a basis for automated support for component integration and

generation of glue code meeting given requirements

slide-5
SLIDE 5

Laser 2005 - Summer School on Software Engineering 5

Overview

  • Modeling real-time systems

– The problem – Heterogeneity – Component-based construction

  • Interaction Models

– Definition – Composition – Examples – Deadlock-freedom preservation

  • Timed systems

– Definition – Examples

slide-6
SLIDE 6

Laser 2005 - Summer School on Software Engineering 6

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
slide-7
SLIDE 7

Laser 2005 - Summer School on Software Engineering 7

Modeling real-time systems - our approach Environment

Application SW RTOS

HW

stimuli response Real-time system Thesis : A Timed Model of a RT system can be obtained by “composing” its application SW with timing constraints induced by both its execution and its external environment

slide-8
SLIDE 8

Laser 2005 - Summer School on Software Engineering 8

Modeling real-time systems - our approach Application SW Timed model DESCRIPTION Reactive machine

(untimed)

TIME

Reference to physical (external) time

TRIGGERING

Timeouts to control waiting times

ACTIONS

No assumption about Execution Times Platform-independence

TO(5)

?e

Assumptions about Execution Times Platform-dependence

?e [0,6] !e [0,4]

Reactive machine + External Environment + Execution Platform Quantitative (internal) time Consistency pbs - timelocks Timing constraints on interactions

slide-9
SLIDE 9

Laser 2005 - Summer School on Software Engineering 9

Modeling real-time systems - our approach

Composition/Synthesis Application SW Platform Timed Model Environment Timed Model User Requirements System Timed Model Code Generation Implementation Analysis Diagnostics

Component-based modeling

slide-10
SLIDE 10

Laser 2005 - Summer School on Software Engineering 10

Modeling real-time systems – Taxys (1) Environment

Esterel+C

DSP

Event handler

tin tout

Deadline constraint

tout - tin<D

Throughput constraint: no buffer overflow

slide-11
SLIDE 11

Laser 2005 - Summer School on Software Engineering 11

Modeling real-time systems – Taxys (2)

Machine Description C Code

ESTEREL + C Data

Target Machine executable code SAXO-RT SAXO IF/KRONOS

Timing Diagnostics

Environment Timed Model Event Handler Timed Model

  • Exec. Times

Timed (instrumented) C Code

C2TimedC

slide-12
SLIDE 12

Laser 2005 - Summer School on Software Engineering 12

Modeling real-time systems – Taxys(3)

Application = ESTEREL + Pragmas Instrumented C Code SAXO-RT Event Handler IF/KRONOS Timing Diagnostics

Exec.Times

QoS requ.

Environment = ESTEREL + Pragmas Instrumented C Code SAXO-RT

KRONOS Algorithms and Data Structures

Target Machine Executable Code SAXO

slide-13
SLIDE 13

Laser 2005 - Summer School on Software Engineering 13

Overview

  • Modeling real-time systems

– The problem – Heterogeneity – Component-based construction

  • Interaction Models

– Definition – Composition – Examples – Deadlock-freedom preservation

  • Timed systems

– Definition – Examples

slide-14
SLIDE 14

Laser 2005 - Summer School on Software Engineering 14

Heterogeneity – Abstraction Levels integration abstraction

Model Model

(requirements) (requirements)

Application Application Software Software Execution Platform System System

slide-15
SLIDE 15

Laser 2005 - Summer School on Software Engineering 15

Heterogeneity - from application SW to implementation

Application SW

CORBA DSP µcontroller RTOS OSEK TTA CAN

Lustre ADA SDL RT- Java Esterel UML

C C++

Matlab/Simulink

Implementation

slide-16
SLIDE 16

Laser 2005 - Summer School on Software Engineering 16

Heterogeneity - from application SW to implementation

Application SW

Functional properties - logical abstract time High level structuring constructs and primitives Simplifying synchrony assumptions wrt environment

Implementation

Non functional properties, involving time and quantities Task coordination, scheduling, resource management, Execution times, interaction delays, latency abstraction refinement

slide-17
SLIDE 17

Laser 2005 - Summer School on Software Engineering 17

Heterogeneity - synchronous vs. asynchronous execution Application SW

Implementation

Component- based approaches

  • Non interruptible

execution steps

  • Usually, single task,

single processor

  • «Everybody gets

something » Synchronous Lustre, Esterel Statecharts

  • Event triggered
  • Multi-tasking
  • RTOS
  • Usually, static

Priorities

  • «Winner takes all »

Asynchronous ADA, SDL

slide-18
SLIDE 18

Laser 2005 - Summer School on Software Engineering 18

Heterogeneity - interaction Interactions can be

  • strict (CSP) or non strict (SDL, Esterel)
  • atomic (CSP, Esterel) or non atomic (SDL)
  • binary (point to point as in CCS, SDL) or n-ary in general

Task1 Task2 Sem p1 v1 p2 v2 p v stage1

  • ut1

in1 stage2 in2

  • ut2
slide-19
SLIDE 19

Laser 2005 - Summer School on Software Engineering 19

Heterogeneity - example A: Atomic interaction B: Blocking interaction Synchronous Computation Asynchronous Computation A B nonA B A nonB nonA nonB Lotos CSP Java UML SDL UML Matlab/Simulink VHDL/SystemC Statecharts

slide-20
SLIDE 20

Laser 2005 - Summer School on Software Engineering 20

Overview

  • Modeling real-time systems

– The problem – Heterogeneity – Component-based construction

  • Interaction Models

– Definition – Composition – Examples – Deadlock-freedom preservation

  • Timed systems

– Definition – Examples

slide-21
SLIDE 21

21

Component Component-

  • based construction

based construction -

  • components

components Build systems by composition of components Components are building blocks composed of behavior and interface Behavior is a transition system Interface hides irrelevant internal behavior and provides some adequate abstraction for composition and re-use, e.g. set of action names (ports) and associated variables

prod put put x=1 y:=0 in x

  • ut

y x=1 y:=1

slide-22
SLIDE 22

22

Component Component-

  • based construction

based construction – – formal framework formal framework Pb:Build a component C satisfying a given property P, from

  • C0 a set of atomic components
  • GL ={gl1, …, gli, …} a set of glue operators on components

c1 c’1

gl1

c2 c’2

gl12

sat P

gl2

  • Components are terms of an algebra of terms (C, ≅ )

generated from C0 by using operators from GL

  • ≅ is a congruence compatible with operational semantics
slide-23
SLIDE 23

23

Component Component-

  • based construction

based construction – – formal framework formal framework Glue operators transform sets of components into components

B1

gl

B2 Bn

Operational Semantics

B

Glue operators

  • model mechanisms used for communication and control

such as protocols, controllers, buses

  • restrict the behavior of their arguments, that is

gl(C1 ,C2 ,.., Cn)| A1 refines C1

slide-24
SLIDE 24

24

Component Component-

  • based construction

based construction -

  • requirements

requirements Examples of existing frameworks:

  • Sequential functions with logical operators and delay
  • perators 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
slide-25
SLIDE 25

25

Component Component-

  • based construction

based construction – – incremental description incremental description

≅

gl C1 C2 Cn gl_2 C1 C2 gl_1

  • 1. Decomposition of gl

Cn

≅

c1 c’1

gl1

c2 c’2

gl2

  • 2. Flattening of terms

c1 c’1 c2 c’2

gl

Flattening can be achieved by introducing an idempotent

  • peration ⊕ such that (GL, ⊕) is a commutative monoid and

gl(gl’(C1 ,C2 ,.., Cn)) ≅ gl⊕gl’(C1 ,C2 ,.., Cn )

slide-26
SLIDE 26

26

Component Component-

  • based

based construction construction -

  • Correctness

Correctness by construction : by construction : compositionality compositionality

☺ ☺

gl

☺

Build correct systems from correct components

ci

sat gl(P1, ..,Pn)

gl

c1 cn sat Pi implies ∀gl ∃gl

~ ~

We need compositionality results about preservation of progress properties such as deadlock-freedom and liveness.

slide-27
SLIDE 27

Component Component-

  • based

based construction construction -

  • Correctness

Correctness by construction : by construction : composability composability Make the new without breaking the old

☺

gl

☺ ☺

gl

  • We badly need composabilty results
  • Property stability phenomena are poorly understood, such as
  • feature interaction
  • non composability of scheduling policies

and implies sat P

gl

c1 cn sat P’

gl’

c1 cn sat P∧P’

gl ⊕ gl’

c1 cn Property stability phenomena are poorly understood

  • feature interaction
  • non composability of scheduling algorithms

27

slide-28
SLIDE 28

28

Component Component-

  • based construction

based construction -

  • compositionality vs. composability

compositionality vs. composability

Integration/compositionality Layering/composability

slide-29
SLIDE 29

Laser 2005 - Summer School on Software Engineering 29

Overview

  • Modeling real-time systems

– The problem – Heterogeneity – Component-based construction

  • Interaction Models

– Definition – Composition – Examples – Deadlock-freedom preservation

  • Timed systems

– Definition – Examples

slide-30
SLIDE 30

Laser 2005 - Summer School on Software Engineering 30

Component-based modeling – The BIP framework

Layered component model Interaction Model: Connectors + Interactions Scheduler: dynamic priority rules

B E H A V I O R

Composition (incremental description)

||

PR2 IM2 PR1 IM1 IM1 IM1 ⊗ IM2 ⊗ IM12 PR1 ⊕ PR2 ⊕ PR12

slide-31
SLIDE 31

Laser 2005 - Summer School on Software Engineering 31

Interaction models Interaction models Connectors are maximal sets of compatible actions

tick1 tick2 tick3

  • ut1

in2 in3

Interactions are subsets of connectors; they are defined by using typing (complete , incomplete ) : either they are maximal or they contain some complete interaction Interactions: {tick1,tick2,tick3}, {out1}, {out1,in2}, {out1,in3}, {out1,in2, in3}

slide-32
SLIDE 32

Laser 2005 - Summer School on Software Engineering 32

I Interaction nteraction models models -

  • examples

examples

cl1,cl2 cl2 cl1

  • ut, in

in

  • ut
  • ut,in1

in1 in1,in2 in2

  • ut,in2
  • ut

in1,out,in2 cl1 cl2

  • ut

in

  • ut

in1 in2 CN:{cl1,cl2} MI: ∅ CN:{out,in} MI: {out} CN:{in1,out,in} MI: {out}

slide-33
SLIDE 33

Laser 2005 - Summer School on Software Engineering 33

Interaction models - definition Given a set of atomic components K with disjoint action vocabularies Ai 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

slide-34
SLIDE 34

34

Interaction models Interaction models – – operational semantics

  • perational semantics

prod put CN: {put,get},{prod},{cons} MI: {prod},{cons} get cons Operational Semantics {put, get} put prod get put get cons prod cons

× × × ×

slide-35
SLIDE 35

35

Interaction models Interaction models -

  • composition

composition

⎢⎢

CN[P,C]: {put,get} MI[P,C]: ∅

prod put

CN[P]: {put},{prod} MI[P]: {prod}

get cons

CN[C]: {get}, {cons} MI[C]: {cons}

prod put get cons CN: {put,get},{prod},{cons} MI: {prod},{cons}

slide-36
SLIDE 36

36

Interaction models Interaction models -

  • composition

composition

a9 a1 a2

K1

a11 a5 a6 a7

⎢⎢

IM[K1,K2]: CN[K1,K2] : {a1, a2, a3 ,a4}, {a11, a12} MI[K1,K2] : {a1,a2,a3,a4}, {a11} IM[K1]: CN[K1] : {a1, a2}, {a5, a9},{a6, a9} MI[K1] : a5, a6, a11

K1

a1 a2 a9 a5 a6 a11

IM[K2]: CN[K2] : {a3, a4}, {a7, a10}, {a8, a10} MI[K2] : a10

K2

a3 a4 a10 a7 a8 a12 a8 a12 a3 a10

K2

a4

slide-37
SLIDE 37

37

Interaction models Interaction models – – composition (2) composition (2)

⎢⎢

IM[K1,K2]: CN[K1,K2] : {a1, a2, a3 ,a4}, {a11, a12} MI[K1,K2] : {a1,a2,a3,a4}, {a11} IM[K1]: CN[K1] : {a1, a2}, {a5, a9},{a6, a9} MI[K1] : a5, a6, a11

K1

a1 a2 a9 a5 a6 a11

IM[K2]: CN[K2] : {a3, a4}, {a7, a10}, {a8, a10} MI[K2] : a10

K2

a3 a4 a10 a7 a8 a12

K1∪ K2

a1 a2 a9 a3 a4 a10 a5 a6 a11 a7 a8 a12

IM[K1 ∪ K2] = IM[K1] ⊗ IM[K2] ⊗ IM[K1,K2] CN[K1 ∪ K2] = max CN[K1] ∪ CN[K2] ∪ CN[K1,K2] MI[K1 ∪ K2] = min MI[K1] ∪ MI[K2] ∪ MI[K1,K2] }

slide-38
SLIDE 38

38

Interaction models Interaction models – – results results [ [Goessler Goessler Sifakis] Sifakis] Incremental commutative composition encompassing blocking and non blocking interaction

  • ut1

in1 in2 sender receiver1 receiver2

sender receiver1 sender receiver1 receiver2

=

receiver2

slide-39
SLIDE 39

39

Interaction models Interaction models -

  • mod8 counter

mod8 counter

a0 a1

a0 a1

b0 b1

b0 b1

c0 c1

c0 c1

a0 a1 b0 b1 c0 c1 a1,b0 a1,b1 b1,c0 b1,c1 a1,c0 a1,c1 a1,b1,c0 a1,b1,c1

slide-40
SLIDE 40

40

Interaction models Interaction models-

  • mod8 counter(2)

mod8 counter(2)

a0 a1

a0 a1

b0 b1

b0 b1

c0 c1

c0 c1 {a1,b1,c1} a0 a0 {a1,b0} {a1,b1,c0} a0 a0 {a1,b0}

a1 b1

{a1,b1}

b1 a1 b0

a0 a0

b0

{a1,b0}

slide-41
SLIDE 41

Laser 2005 - Summer School on Software Engineering 41

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 no commit abort vote_1 yes_1 no_1 commit_1

ARBITER PROCESS_1

vote yes commit vote_1 yes_1 commit_1

slide-42
SLIDE 42

Laser 2005 - Summer School on Software Engineering 42

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 commit abort

ARBITER

no vote_1 yes_1 no_1 commit_1 abort_1

PROCESS_1

slide-43
SLIDE 43

43

Interaction models Interaction models -

  • checking for deadlock

checking for deadlock-

  • freedom

freedom 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

a

a1 a2 a3

{a,a1,a2,a3}

k k2 k1 k3

Blocking condition for an incomplete action a: Bl(a) = en(a) ∧ ¬ (en(a1) ∧ en(a2) ∧ en(a3) )

slide-44
SLIDE 44

44

Interaction models Interaction models -

  • checking for deadlock

checking for deadlock-

  • freedom (2)

freedom (2) 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

a1 a2 a3 a4

k1 k3 k4 k2

Bl(a1) Bl(a2) Bl(a4) Inc(k4) Inc(k1) Inc(k3) Inc(k2) Bl(a3)

slide-45
SLIDE 45

Laser 2005 - Summer School on Software Engineering 45

Interaction models - checking for deadlock-freedom: example

put get1 get2 CN: {put,get1,get2} MI: {put,get1}, {put,get2} producer consumer1 consumer2

slide-46
SLIDE 46

Laser 2005 - Summer School on Software Engineering 46

Interaction models - checking for deadlock-freedom: example

n1: {put,get1} producer consumer1 consumer2 n2 : {put, get2} put put put put get1 get1 get2 get2 get2 get1

ω1=(producer, n1, consumer2, n2) Bl(ω1) =false ω2=(producer, n2, consumer1, n1) Bl(ω2) =false ω3=(consumer1, n1,consumer2, n2,) Bl(ω3)=Inc(ω3 )∧en(get1) ∧ ¬ (en(get2) ∧ en(put)) ∧en(get2) ∧ ¬ (en(get1) ∧ en(put)) =Inc(ω3 )∧en(get1) ∧ en(get2) ∧ ¬ en(put) Deadlock-freedom if Inc(producer) ∧¬ en(put) =false

slide-47
SLIDE 47

Laser 2005 - Summer School on Software Engineering 47

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

  • f 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
slide-48
SLIDE 48

Laser 2005 - Summer School on Software Engineering 48

Interaction models - discussion

  • The distinction interaction model / behavior is crucial
  • r 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

  • perators at the same level.
  • Framework encompassing strict and non strict synchronization

((P1||P2)\a ||P3)\a’ \a ⊕\a’ P1||P2||P3

slide-49
SLIDE 49

Laser 2005 - Summer School on Software Engineering 49

Overview

  • Modeling real-time systems

– The problem – Heterogeneity – Component-based construction

  • Interaction Models

– Definition – Composition – Examples – Deadlock-freedom preservation

  • Timed systems

– Definition – Examples

slide-50
SLIDE 50

Laser 2005 - Summer School on Software Engineering 50

Timed systems – from untimed to timed systems

Methodology :

  • Avoid over-specification which

may lead to inconsistency

  • Make explicit all the

consequences of the constraints

  • n interactions
  • Define ⎜⎜T so as to preserve

properties such as well- timedness, and deadlock- freedom

TIMED

  • ⎜⎜

P2 P1

⎜⎜T

P2T P1T UNTIMED

Timing Constraints ⊕

slide-51
SLIDE 51

Laser 2005 - Summer School on Software Engineering 51

Timed systems – untimed systems : definition Untimed system: A set of transitions 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 s s’ a, g, f Operational semantics: A set of transitions a (s,x) (s’,f(x)) where x is a valuation of X such that g(x)=true

slide-52
SLIDE 52

Timed Systems - definition 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). s s’ a, g, u, f Timed system: A set of transitions

φs’ φs

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

slide-53
SLIDE 53

Laser 2005 - Summer School on Software Engineering 53

Timed Systems - a periodic process A periodic process of period T>0 and execution time E, (E ≤ T). sleep wait t=T t=T t:=0 t≤T-E t=T-E x:=0 exec (x=E) (x=E) t’=x’=1 at all states

slide-54
SLIDE 54

Laser 2005 - Summer School on Software Engineering 54

Timed Systems - definition b1 b2 bi s s2 si

φs

bi=(ai,gi,ui,fi) s1 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 = ¬(∨iui) Time can progress as long as no urgency condition is true

slide-55
SLIDE 55

Laser 2005 - Summer School on Software Engineering 55

Timed Systems - relating urgency and time progress

3≤ x≤5 4<y ≤ 7 x=5 4<y ≤ 7

a b

tp=x≠5∧(y ≤ 4∨y>7)

a b

3≤ x≤5 4<y ≤ 7

slide-56
SLIDE 56

Laser 2005 - Summer School on Software Engineering 56

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 u=false u=g↓ lazy (λ) delayable (δ) eager (ε)

slide-57
SLIDE 57

Laser 2005 - Summer School on Software Engineering 57

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’ a

(g,u) s a a (u,u) (g ∧¬ u, false) s’ s a a (g ∧¬ u)λ s’ uε

slide-58
SLIDE 58

Laser 2005 - Summer School on Software Engineering 58

Timed Systems - a periodic process A periodic process of period T>0 and execution time E, (E ≤ T). sleep (t≤T-E)δ (t=T)ε t:=0 x:=0 wait exec (x=E) ε t’=x’=1 at all states

slide-59
SLIDE 59

Laser 2005 - Summer School on Software Engineering 59

Timed systems – guard restriction

g’ u’ TS’ s1 s2 g u TS s1 s2 restriction g’⇒g u ⇒u’ TS’ simulates TS

slide-60
SLIDE 60

Laser 2005 - Summer School on Software Engineering 60

Timed systems – guard restriction

+urgent +liberal maximal urgency u = g

u g (g,u) (g’,u’) g’ u’ (u,u) (g,g) (g”,u”)

slide-61
SLIDE 61

Laser 2005 - Summer School on Software Engineering 61

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)

q1 -t1→q2 and q2 –t2→ q3 implies q1 –t1+t2→ q3

A run is a maximal sequence of transitions from states

q0 q1 … qi …

such that qi - ti→ qi+1 or qi -ai → qi+1 time[q0, qi]=Σk≤i tk

q0 q1 … qi … is time divergent if ∀k∈N ∃i time[q0, qi] > k

Important : Well-timed systems (only time divergent runs !)

slide-62
SLIDE 62

Laser 2005 - Summer School on Software Engineering 62

Timed systems as transition systems - discrete vs. continuous a TIMEOUT[2]b : execute a within 2 otherwise execute b b 2 1 1 a a time unit 1 a a 2 a a

0.5 0.5 0.5 0.5

b time unit 0.5 a a a a 2 t t-2 a a dense time b t 2-t

slide-63
SLIDE 63

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 1 a b c 1 1 AL1 possible abc within 0 AL2

slide-64
SLIDE 64

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 time unit 0.25

0.25

AL1 a a a a AL2 b c b c b c b c possible abc within 1.75 AL2

slide-65
SLIDE 65

Laser 2005 - Summer School on Software Engineering 65

Timed systems as Transition Systems - discrete vs. continuous a (bc TIMEOUT[1] AL2) TIMEOUT[1] AL1 for dense time AL1 a a a a AL2 b c b c b c b c AL2 a possible abc within <2

slide-66
SLIDE 66

Laser 2005 - Summer School on Software Engineering 66

Overview

  • Modeling real-time systems

– The problem – Heterogeneity – Component-based construction

  • Interaction Models

– Definition – Composition – Examples – Deadlock-freedom preservation

  • Timed systems

– Definition – Examples

slide-67
SLIDE 67

Laser 2005 - Summer School on Software Engineering 67

Timed systems – from untimed to timed systems

Methodology :

  • Avoid over-specification which

may lead to inconsistency

  • Make explicit all the

consequences of the constraints

  • n interactions
  • Define ⎜⎜T so as to preserve

properties such as well- timedness, and deadlock- freedom

TIMED

  • ⎜⎜

P2 P1

⎜⎜T

P2T P1T UNTIMED

Timing Constraints ⊕

slide-68
SLIDE 68

Laser 2005 - Summer School on Software Engineering 68

Scheduler modeling - example

A periodic process of period T and completion time C

sleep wait use f b a p r x<E t≤T-E x<E stop t=T t:=0 x:=0 x=E Actions a: arrive b: begin f: finish p: preempt r: resume (u) (c) (u) (c) (c) t’=x’=1 at all states except stop (x’=0)

slide-69
SLIDE 69

Laser 2005 - Summer School on Software Engineering 69

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
slide-70
SLIDE 70

Laser 2005 - Summer School on Software Engineering 70

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) K0 =KSCH ∧KPOL

  • KSCH scheduling constraints (timing constraints on processes)
  • KPOL scheduling policy

QoS requirem

Scheduler for KSCH ∧KPOL Interactions

Processes

state controllable interaction

Timed Model

slide-71
SLIDE 71

Laser 2005 - Summer School on Software Engineering 71

Scheduler modeling - control invariants

A control invariant K ⇒ K0

K0

K

u u

t

c u

ILLEGAL STATES

  • Control invariants are preserved by uncontrollable actions
  • It is possible to maintain the system in K by executing

controllable actions

slide-72
SLIDE 72

Laser 2005 - Summer School on Software Engineering 72

Scheduler modeling - restriction by a constraint The restriction of TS by a constraint K is a timed system TS/K

restriction

ac g

TS s1 s2

ac g∧K ∧pre12(K)

TS/K s1 s2

In TS/K, K holds right before and right after the execution

  • f any controllable action

If K is a control invariant of TS then TS/K, is the scheduled (controlled) system

slide-73
SLIDE 73

Laser 2005 - Summer School on Software Engineering 73

Scheduler modeling – controller synthesis There exists a scheduler maintaining K0 if there exists a non empty control invariant K, K ⇒ K0 For given K0, the maximal control invariant K, K ⇒ K0 can be computed as the result of a synthesis semi- algorithm SYNTH(TS,K0) = limI{Ki } where Ki+1 = Ki+1 ∧ contr-pre (Ki ) from K0

Ki c contr-pre(Ki ) u t

All states from which TS can be led to Ki no matter how the environment behaves

slide-74
SLIDE 74

Laser 2005 - Summer School on Software Engineering 74

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

  • TSu sat inv(K) implies TS/K sat inv(K)

K’

K

slide-75
SLIDE 75

Laser 2005 - Summer School on Software Engineering 75

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 TSu sat inv(K)
slide-76
SLIDE 76

Laser 2005 - Summer School on Software Engineering 76

Scheduler modeling – composability of control invariants

s2 s1 (t2=5) t2:=0 t1=15 t1:=0 w2 w1 b2

∧¬ e2 ¬ e1∧

(t1≤10) x1:=0 (t2≤3) x2:=0 b1 x1=5 x2=2 e2 e1

TS1∪TS2/K_mutex

K_mutex = ¬ (e1∧ e2) is a composable control invariant of TS1∪TS2

slide-77
SLIDE 77

Laser 2005 - Summer School on Software Engineering 77

Scheduler modeling – composability of control invariants

s2 s1 (t2=5) t2:=0 t1=15 t1:=0 w2 w1 b2

∧¬ e2 ¬ e1∧

(t1≤10) x1:=0 (t2≤3) x2:=0 b1 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

slide-78
SLIDE 78

Laser 2005 - Summer School on Software Engineering 78

Scheduler modeling – the scheduling constraint KSCH The scheduling constraint KSCH 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

slide-79
SLIDE 79

Laser 2005 - Summer School on Software Engineering 79

Scheduler modeling – the scheduling constraint KSCH

Each shared resource induces a partition {Sleep, Wait, Use}. begin

Sleep Use Wait

finish

x:=0 Emin ≤ x ≤Emax

arrive

t:=0 Tmin ≤ t ≤Tmax Execution time (x) t ≤ D t ≤ D - Emax t ≤ D Deadline D Arrival time (t)

slide-80
SLIDE 80

Laser 2005 - Summer School on Software Engineering 80

Scheduler modeling – the scheduling constraint KSCH

s

KSCH =∧i KiSCH

where KiSCH expresses the property that no timing constraint is violated in process i. a t=T t:=0 w b t ≤ T- E For timelock-free process models with bounded guards, schedulability boils down to deadlock- freedom of processes x:=0 x=E f u

KSCH = s∧(t ≤ T) ∨ w∧ (t≤T-E) ∨ u∧(x ≤ E)

slide-81
SLIDE 81

Laser 2005 - Summer School on Software Engineering 81

Scheduler modeling – the scheduling policy KPOL

KPOL is the conjunction of scheduling policies for the set R of

shared resources

KPOL =∧r ∈R Kr

POL where

Kr

POL = Kr CONF ∧ Kr ADM

  • Kr

CONF says how conflicts for the acquisition of resource r

are resolved e.g. EDF, RMS, LLF

  • Kr

ADM says which requests for r are considered by the

scheduler at a state e.g. masking

slide-82
SLIDE 82

Laser 2005 - Summer School on Software Engineering 82

Scheduler modeling – the scheduling policy KPOL

KPOL : scheduling policy ri KiADM KADM : admission control KCONF: Conflict resolution r1 K1ADM rn KnADM r1 K1CONF ri KiCONF rn KnCONF

slide-83
SLIDE 83

Laser 2005 - Summer School on Software Engineering 83

Scheduler modeling – the scheduling policy KPOL : example

KPOL 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”

slide-84
SLIDE 84

Laser 2005 - Summer School on Software Engineering 84

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)

1. Choose a scheduling policy K_pol such that the conflicts on controllable actions of TS/K_pol are resolved 2. Check TS/K_pol sat inv(K_sched)

slide-85
SLIDE 85

Laser 2005 - Summer School on Software Engineering 85

Composability results - application

A scheduler design methodology supported by the Prometheus tool connected to Kronos

K_pol2 K_pol1 trace 1 trace2 K_sced

K:= K_sched; while ¬ (TS/K sat inv(K) ) do choose K_pol; K:= K_sched ∧ K_pol

  • d
slide-86
SLIDE 86

Laser 2005 - Summer School on Software Engineering 86

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
slide-87
SLIDE 87

Laser 2005 - Summer School on Software Engineering 87

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 KPOL induces a restriction that can be described by priorities

slide-88
SLIDE 88

Laser 2005 - Summer School on Software Engineering 88

Timed Systems with priorities

s

exec2 a1 g1

〈

exec1 g2 a2

Priority Strengthened guard a1 〈0 a2 g1’ = g1 ∧ ¬g2 a1 〈5 a2 g1’ = g1 ∧ ¬〈5〉g2 a1 〈∝ a2 g1’ = g1 ∧ ¬〈∞〉g2

Notation: 〈k〉g(X) = ∃ t t≤ ≤k g(X+t) (= eventually g within time k) k g(X+t) (= eventually g within time k)

slide-89
SLIDE 89

Laser 2005 - Summer School on Software Engineering 89

Timed Systems with priorities a1 〈k a2 means that a1 is disabled when a2 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.

a1 〈k a2 ∧ a2〈m a3 ⇒ a1 〈k+m a3 (transitivity)

〈

g1 gn s1 sn a1 an

s

gi’=gi ∧ (∧ ¬<k>gm)

ai〈kam 〈k ∈〈 g1’ gn’ s1 sn a1 an

s

slide-90
SLIDE 90

Laser 2005 - Summer School on Software Engineering 90

Timed Systems with priorities A timed system with priorities is a pair (TS, pr) where pr is a set

  • f priority rules pr = {Ci, 〈i }i with
  • {Ci}i is a set of disjoint time invariant predicates
  • {〈i }i is a set of priority orders

pr = { Ci → 〈i }i

TS

ak gi ak gi’

TS’

gi’ = gi ∧ ∧ C → 〈 ∈pr (C ⇒ ∧ (∧ ¬<k>gm))

ai〈kam 〈k ∈〈

Activity Preservation Theorem: ◊∨i gi = ◊∨i gi’

slide-91
SLIDE 91

Laser 2005 - Summer School on Software Engineering 91

Timed Systems with priorities - fixed priority policy w1∧w2 → b1 〈k b2 for some k

x1=E1 f1 b1 t1≤T1-E1 x1:=0 a1 t1=T1 t1:=0 b2 t2≤T2-E2 x2:=0 a2 t2=T2 t2:=0

s1 w1 e1 s2 w2 e2

x2=E2 f2

#

slide-92
SLIDE 92

Laser 2005 - Summer School on Software Engineering 92

Timed Systems with priorities - FIFO policy t1≤ t2 → b1〈 0 b2 t2≤ t1 → b2〈 0 b1

x1=E1 f1 b1 t1≤T1-E1 x1:=0 a1 t1=T1 t1:=0 b2 t2≤T2-E2 x2:=0 a2 t2=T2 t2:=0

s1 w1 e1 s2 w2 e2

x2=E2 f2

#

slide-93
SLIDE 93

Laser 2005 - Summer School on Software Engineering 93

Timed Systems with priorities - LLF policy L1≤ L2 → b2 〈0 b1 L2≤ L1→ b1〈0b2 where Li=Ti-Ei-ti,

x1=E1 f1 b1 t1≤T1-E1 x1:=0 a1 t1=T1 t1:=0 b2 t2≤T2-E2 x2:=0 a2 t2=T2 t2:=0

s1 w1 e1 s2 w2 e2

x2=E2 f2

#

slide-94
SLIDE 94

94

Priority Systems Priority Systems -

  • Composition of priorities

Composition of priorities

pr1 pr2

≠

pr2 pr1 a c b a 〈1 b c b b〈2 c c b〈2 c a 〈1 b a c a c

slide-95
SLIDE 95

95

Priority Systems Priority Systems -

  • Composition of priorities

Composition of priorities

pr1 pr2 pr1⊕ pr2

=

We take:

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
slide-96
SLIDE 96

96

Timed Systems with priorities – mutual exclusion w1∧e2 → b1 〈∞ f2 w2∧e1 → b2 〈∞ f1

x1=E1 f1 b1 t1≤T1-E1 x1:=0 a1 t1=T1 t1:=0 b2 t2≤T2-E2 x2:=0 a2 t2=T2 t2:=0

s1 w1 e1 s2 w2 e2

x2=E2 f2 Idea: Give infinitely higher priority to the process using the resource

slide-97
SLIDE 97

97

Timed Systems with priorities – mutual exclusion

x1=E1 f1 b1 t1≤T1-E1∧(¬e2∨x2 ≤ E2) x1:=0 a1 t1=T1 t1:=0 b2 (¬e1∨x1≤ E1 ) ∧ t2≤T2-E2 x2:=0 a2 t2=T2 t2:=0

s1 w1 e1 s2 w2 e2

x2=E2 f2 The behavior after application of mutual exclusion constraints

slide-98
SLIDE 98

Laser 2005 - Summer School on Software Engineering 98

Timed Systems with priorities – mutual exclusion Mutex on R’ : b1 〈∞ f2 b2 〈∞{ f1, b1’} Mutex on R : b1’ 〈∞ { f2, b2 } b2’ 〈∞f1 s1 b1 w2 a1 f1 a2 f2 b2’ w1 b1’ b2 R RR’ RR’ R’ Risk of deadlock: The composition is not a priority order ! s2

slide-99
SLIDE 99

99

Timed Systems with priorities – mutual exclusion + FIFO policy w1∧e2 → b1 〈∞ f2 w2∧e1 → b2 〈∞ f1

x1=C1 f1 b1 t1≤T1-C1 x1:=0 a1 t1=T1 t1:=0 b2 t2≤T2-C2 x2:=0 a2 t2=T2 t2:=0

s1 w1 e1 s2 w2 e2

x2=C2 f2

t1≤ t2 → b1〈 0 b2 t2≤ t1 → b2〈 0 b1

slide-100
SLIDE 100

Laser 2005 - Summer School on Software Engineering 100

The BIP framework -fixed priority preemptive scheduling (1)

bi〈bj, ri 〈 rj , ri 〈 bj , bi 〈 rj (access to the resource – priority preserved by composition) {bi,pj } 〈 fj , {ri,pj } 〈 fj , n ≥ I >j ≥1 (non pre-emption by lower pty tasks) CN: {bi,pj } {ri,pj } for n ≥i,j ≥ 1 MI: ai, fi, bi for n ≥i ≥ 1

s1 e1 b1 w1 a1 e1’ r1 p1 f1 sj ej bj wj aj ej’ rj pj fj si ei bi wi ai ei’ ri pi fi sn en bn wn an fn ei’ pi en’ rn pn

slide-101
SLIDE 101

Laser 2005 - Summer School on Software Engineering 101

The BIP framework -fixed priority preemptive scheduling (state graph)

slide-102
SLIDE 102

Laser 2005 - Summer School on Software Engineering 102

The BIP framework - fixed priority preemptive scheduling (2)

bi〈bj, ri 〈 rj , ri 〈 bj , bi 〈 rj (access to the ressource – pty inherited by composition) pi 〈 fj , if wi or e’i n ≥ I >j ≥1 (non pre-emption by lower pty tasks)

{bi ,ri }〈 {fj pj }

n ≥ I,j ≥1 (Mutual exclusion)

s1 e1 b1 w1 a1 e1’ r1 p1 f1 sj ej bj wj aj ej’ rj pj fj si ei bi wi ai ei’ ri pi fi sn en bn wn an fn ei’ pi en’ rn pn

slide-103
SLIDE 103

Laser 2005 - Summer School on Software Engineering 103

The BIP framework - traffic light for tramway crossing

red signal signal green

  • ut

in enter r2g g2r exit appr exit signal

  • ut red

in green {enter,r2g} appr red r2g g2r

  • ut green

exit g2r {exit,g2r} appr green r2g enter

exit r2g enter signal g2r

signal

slide-104
SLIDE 104

Laser 2005 - Summer School on Software Engineering 104

The BIP framework – run to completion

i1 o1

f1 e1

i1

  • 1

i2 o2

f2 e2

i2

  • 2

i3 o3

f3 e3

i3

  • 3

i1 〈 {o1,i2} 〈 {o2,i3} 〈 o3 CN: {o1,i2}, {o2,i3} MI: i1,o3

i1 o1 i2 o2 i3 o3

slide-105
SLIDE 105

Laser 2005 - Summer School on Software Engineering 105

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
slide-106
SLIDE 106

Laser 2005 - Summer School on Software Engineering 106

Timed Systems with priorities – liveness Run: a maximal sequence of successive transitions in a TS q0- t0→q0’- a1→q1- t1 →q1’- a2→ … … qi- ti→qi’ -ai→qi+1- t1+1 → ….. Timelock: a run where the total time elapsed is bounded Livelock : a run where only a finite number of transitions

  • ccur

LIVE = Timelock-free + Livelock-free

slide-107
SLIDE 107

Laser 2005 - Summer School on Software Engineering 107

Timed Systems with priorities – structural liveness

Enforce liveness satisfaction by appropriate structural restrictions preserved by composition operators 3 structural properties easy to check

structurally non-Zeno locally timelock-free locally livelock-free structurally live timelock-free livelock-free

slide-108
SLIDE 108

Laser 2005 - Summer School on Software Engineering 108

Timed Systems with priorities – structural liveness

Structurally non-Zeno: any circuit of the control graph has some clock reset and tested against some positive lower bound Locally Timelock-free: if time cannot progress then some action is executed (satisfied by construction) Locally Livelock-free: if time can progress then some action will be executed

ui

s in(s) ⇒ ◊ ∨iui

LTLF+SnZ ⇒ TLF LTLF+LLLF ⇒LLF Structurally live = LTLF+SnZ +LLLF

slide-109
SLIDE 109

Laser 2005 - Summer School on Software Engineering 109

Timed Systems with priorities – structural liveness

sleep wait (t≤T-E)δ (t=T)ε t:=0 x:=0 exec (x=E) ε A periodic process of period T>0 and execution time E, (E ≤ T).

This process is structurally live:

  • Timelock-free because SnZ+ LTLF
  • Locally LLF because

in(wait)=(t=0) ⇒ ◊(t=T-E) = t≤T-E in(exec)=(x=0) ⇒ ◊(x=E) = x≤E in(sleep)=(x=E) ⇒ ◊(t=T) = t≤T ???

slide-110
SLIDE 110

Laser 2005 - Summer School on Software Engineering 110

Timed Systems with priorities – structural liveness

sleep wait (t≤T-E)δ (t=T)ε t:=0 x:=0 exec (x=E) ( ∧(t ≤ T)) ε A periodic process of period T>0 and execution time E, (E ≤ T). This process is structurally live:

  • Timelock-free because SnZ+ LTLF
  • Locally LLF because

in(wait)=(t=0) ⇒ ◊(t=T-E) = t≤T-E in(exec)=(x=0) ⇒ ◊(x=E) in(sleep)=(x=E) ⇒ ◊(t=T) = t≤T ∧(t ≤ T- E) ∧(t ≤ T) ∧(t ≤ T)

slide-111
SLIDE 111

Laser 2005 - Summer School on Software Engineering 111

Timed Systems with priorities – structural liveness

Theorem: Priorities preserve the 3 structural properties, thus they preserve structural liveness. If TS is structurally live then (TS, pr) is structurally live too

slide-112
SLIDE 112

Laser 2005 - Summer School on Software Engineering 112

Flexible Composition

s1 s1’ α1 s2 s2’ α2 (s1,s2) (s1’,s2’) α2 α1 (s1’,s2) (s1,s2’) α1∪α2 pr1 pr2 pr1⊕ pr2 ⊕ pr_12

  • All interactions are complete
  • pr_12 specifies maximal progress, that is an interaction has lower priority

wrt all the interactions containing it e.g. α1 〈α1∪α2 α2 〈 α1∪α2

slide-113
SLIDE 113

Laser 2005 - Summer School on Software Engineering 113

Flexible Composition - timed systems

s1 s1’ b1 s2 s2’ b2 (s1,s2) (s1’,s2’) b2 b1 (s1’,s2) (s1,s2’) {b1,b2} pr1 pr2 pr1⊕ pr2 ⊕ pr_12

  • For bi=(αi, giτi, fi), {b1,b2} = (α1∪α2, g1τ1 ∧ g2τ2, f1∪f2) with

g1τ1 ∧ g2τ2 = (g1 ∧ g2)τ with τ=max{τ1,τ2 }

  • pr_12(s1,s2) = α1 〈∞ α1∪α2, α2 〈∞ α1∪α2

Theorem: Flexible composition preserves

  • Structural liveness if the synchronization guards are not lazy
  • Individual liveness if ◊¬gi for i=1,2
slide-114
SLIDE 114

Laser 2005 - Summer School on Software Engineering 114

Flexible Composition - timed systems : best effort synchronization

f1 x1=E1 go1 g1 x1:=0 a1 t1=T1 t1:=0 go2 g2 x2:=0 a2 t2=T2 t2:=0

sleep1 wait1 exec1 sleep2 wait2 exec2

f2 x2=E2 g1∧g2 {go1,go2}

For g1 = (t1≤T1-E1), g2 = (t2≤T2-E2) we have:

  • g1 ∧ g2 = (t1≤T1-E1) ∧ (t2 ≤ T2-E2)
  • g1’ = (t1≤T1-E1)∧(t2>T2-E2) g2’ = (t2≤T2-E2)∧(t1>T1-E1)
slide-115
SLIDE 115

Laser 2005 - Summer School on Software Engineering 115

Timed Systems with priorities – discussion STRICT (NON FLEXIBLE) COMPOSITION

  • Preserves urgency - risk of timelock
  • Constraint - oriented

tp1 tp2 tp1 tp2 ∧

FLEXIBLE (NON STRICT) COMPOSITION

  • Relaxes urgency to avoid timelock
  • Design/Synthesis-oriented

tp1 tp2 tp

slide-116
SLIDE 116

Laser 2005 - Summer School on Software Engineering 116

Timed Systems with priorities – about priorities

  • Priorities are a special kind of restriction used to resolve

conflicts between actions

  • Priorities are commonly used in systems for resource

management and scheduling

  • Their combination with behavior raises some problems e.g.

associativity of composition

  • Have often been considered as “low” level concept e.g.

“What It Means for a Concurrent Program to Satisfy a Specification: Why No One Has Specified Priority” Leslie Lamport, POPL, 1984

slide-117
SLIDE 117

Laser 2005 - Summer School on Software Engineering 117

Timed Systems with priorities – discussion Priorities are a powerful modeling tool

  • they can advantageously replace static restriction
  • for real-time systems they allow straightforward

modeling of urgency, scheduling policies

  • run to completion and synchronous execution can be

modeled by assigning priorities to threads

slide-118
SLIDE 118

Laser 2005 - Summer School on Software Engineering 118

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
slide-119
SLIDE 119

Laser 2005 - Summer School on Software Engineering 119

The IF toolset: objectives Model-based development of real-time systems

Use of high level modeling and programming languages

  • Expressivity for faithful and natural modeling
  • Cover functional and extra-functional aspects
  • Openness

Model-based validation

  • Combine static analysis and model-based validation
  • Integrate verification, testing, simulation and debugging

Applications: Protocols, Embedded systems, Asynchronous circuits, Planning and scheduling

slide-120
SLIDE 120

Laser 2005 - Summer School on Software Engineering 120

The IF toolset: approach Modeling and programming languages (SDL, UML, SCADE, Java …) Transition systems simulation test verification1 verification2 verification3

Optimisation and abstraction

IF: Intermediate Format, based on a general and powerful semantic model

state explosion

slide-121
SLIDE 121

Laser 2005 - Summer School on Software Engineering 121

The IF toolset: challenges Find an adequate intermediate representation

Expressiveness: direct mapping of concepts and primitives of high modeling and programming languages

  • asynchronous, synchronous, timed execution
  • buffered interaction, shared memory, method call …

Use information about structure for efficient validation and traceability Semantic tuning: when translating languages to express semantic variation points, such as time semantics, execution and interaction modes

slide-122
SLIDE 122

Laser 2005 - Summer School on Software Engineering 122

The IF toolset - IF notation: system description Processes (Behavior) Interactions Data

extended timed systems (non-determinism, dynamic creation) asynchronous channels shared variables predefined data types (basic types, arrays, records) abstract data types

Dynamic priorities

slide-123
SLIDE 123

Laser 2005 - Summer School on Software Engineering 123

The IF toolset: - IF notation: the basic model (ACTA)

x,y: var t:timer ?g,a

slide-124
SLIDE 124

Laser 2005 - Summer School on Software Engineering 124

The IF toolset - IF notation: system description

  • A process instance:

– executes asynchronously with other instances – can be dynamically created – owns local data (public or private) – owns a private FIFO buffer

  • Inter-process interactions:

– asynchronous signal exchanges (directly or via signalroutes) – shared variables

slide-125
SLIDE 125

Laser 2005 - Summer School on Software Engineering 125

P1(N1)

const N1 = … ; // constants type t1 = … ; // types signal s2(t1, t2), // signals // signalroutes signalroute sr1(1) … // route attributes from P1 to P3 // processes process P1(N0) … // data + behaviour endprocess; … process P3(N3) … endprocess;

The IF toolset - IF notation: system description

P1(N1) P3(N3) P2(N2)

signalroute process signal (N1 initial instances) s2 (t1, t2) s1(t1) … … … … parameter sr(1) … local data

slide-126
SLIDE 126

Laser 2005 - Summer School on Software Engineering 126

The IF toolset -IF notation: process description

Process = hierarchical, timed system process P1(N1); fpar … ; // types, variables, constants, procedures state s0 … ; … // transition t1 endstate; state s1 #unstable…; … // transitions t2, t3 endstate; … // states s2, s3, s4 endprocess;

parameters local data state

  • utgoing transitions

s2 s1 s3 s0 s4 t1 t4 t5 t3 t2

local data + local clocks

s41 s42 t6 t7

P1(N1)

slide-127
SLIDE 127

Laser 2005 - Summer School on Software Engineering 127

The IF toolset - IF notation: dynamic creation

  • process creation:

p := fork client (true) a new instance is created

process name parameters pid of the newly created instance

  • process destruction:

the instance is destroyed, together with its buffer, and local data kill client(2) kill p

pid expression

  • process termination:

stop the “self” instance is destroyed, together with its buffer, and local data

slide-128
SLIDE 128

Laser 2005 - Summer School on Software Engineering 128

The IF toolset - IF notation: transition description

transition = urgency + trigger + body

state s0 … urgency eager provided x!=10; when c2 >= 4; input update(m); body …. nextstate s1; … endstate;

= trigger

urgency untimed guard timed guard signal consumption from the process buffer statement list

t1

statement = data assignment message emission, process or signalroute creation or destruction, …

  • sequential. conditional, or

iterative composition

slide-129
SLIDE 129

Laser 2005 - Summer School on Software Engineering 129

The IF toolset- IF notation: data and types Variables:

  • are statically typed (but explicit conversions allowed)
  • can be declared public (= shared)

Predefined basic types: integer, boolean, float, pid, clock Predefined type constructors:

  • (integer) interval: type fileno = range 3..9;
  • enumeration: type status= enum open, close endenum;
  • array: type vector= array[12] of pid
  • structure: type file = record f fileno; s status endrecord;

Abstract Data Type definition facilities …

⊇ {self, nil}

slide-130
SLIDE 130

Laser 2005 - Summer School on Software Engineering 130

The IF toolset - IF notation: interactions

signal route = connector = process to process communication channel with attributes, can be dynamically created

signalroute s1(1) #unicast #lossy #fifo from server to client with grant, fail;

route name initial instance number attributes signal set endpoints

attributes:

  • queuing policy: fifo | multiset
  • reliability: reliable | lossy
  • delivery policy: peer | unicast | multicast
  • delay policy: urgent | delay[l,u] | rate[l,u]
slide-131
SLIDE 131

Laser 2005 - Summer School on Software Engineering 131

The IF toolset - IF notation: interactions (delivery policies)

peer

server(0) server(0) server(0)

to one specific instance

client(1) client(0) client(2) client(1) client(0) client(2) client(1)

unicast multicast to all instances to a randomly chosen instance

slide-132
SLIDE 132

Laser 2005 - Summer School on Software Engineering 132

The IF toolset - IF notation: interactions (signal exchange) Signal emission (non blocking):

to a specific process: output req (3, open) to server(2);

signal

via a signalroute:

  • utput req(3, open) via s0(1);

mixed:

  • utput token via link(1) to client(k+1)%N;

parameters signalroute pid expression pid expression

Signal consumption (blocking):

input req (f, s);

formal parameters k=integer(self)

slide-133
SLIDE 133

Laser 2005 - Summer School on Software Engineering 133

The IF toolset - IF notation: System description (example)

server(NS) client(NC)

grant, fail(reason) req(file,status) stop abort s0 s1 s2 update(file) fail(reason)

const NS= … , NC= … ; type file= … , status= … , reason= … ; signal stop(), req(file, status), fail(reason), grant(), abort(), update(data); signalroute s0(1) #multicast from server to client with abort; signalroute s1(1) #unicast #lossy from server to client with grant,fail; signalroute s2(1) #unicast from client to server with req; process server(NS) … endprocess; process client(NC) … endprocess;

slide-134
SLIDE 134

Laser 2005 - Summer School on Software Engineering 134

The IF toolset - IF notation: timed behavior The model of time [timed systems]

– global time → same clock speed in all processes – time progress in stable states only → transitions are instantaneous

time = 0

q0 t1 t2 q1 q2

δ0(q2)

q3

time = δ0

q4

δ1(q4)

P1 P2 P3 Pk …

system configuration

q5

time = δ0 + δ1 …

slide-135
SLIDE 135

Laser 2005 - Summer School on Software Engineering 135

The IF toolset - IF notation: timed behavior

  • perations on clocks

– set to value – deactivate – read the value into a variable

  • timed guards

– comparison of a clock to an integer – comparison of a difference of two clocks to an integer state send;

  • utput sdt(self,m,b) to {receiver}0;

set t:= 10; nextstate wait_ack; endstate; state wait_ack; input ack(sender,c); … when 10 <t<20 ; … endstate;

slide-136
SLIDE 136

Laser 2005 - Summer School on Software Engineering 136

The IF toolset - IF notation: dynamic priorities

  • priority order between process instances p1, p2 ( free

variables ranging over the active process set) priority_rule_name : p1 < p2 if condition(p1,p2)

  • semantics: only maximal enabled processes can execute
  • scheduling policies

– fixed priority: p1 < p2 if p1 instanceof T and p2 instanceof R – run-to-completion: p1 < p2 if p2 = manager(0).running – EDF: p1 < p2 if Task(p2).timer < Task(p1).timer (p1)

slide-137
SLIDE 137

Laser 2005 - Summer School on Software Engineering 137

IF toolset - overall architecture

UML RT/UML OMEGA SDL

aml2if uml2if sdl2if

IF Description IF Exploration Platform

TGV Test Generation

Test Suites

model construction

LTS

model checking guided exploration

mincost path extraction

schedules

Objecteering Rational Rose ObjectGeode CADP SPIDER

IF Static Analyzer

LASH RMC TReX

guided simulation

slide-138
SLIDE 138

Laser 2005 - Summer School on Software Engineering 138

IF toolset - Core components

syntactic transformation tools:

  • static analyser
  • code generator

LTS exploration tools

  • - debugging
  • - model checking
  • - test generation

priorities (scheduling) interaction model state space representation writer IF description parser C/C++ code

IF AST

application specific process code predefined modules (time, channels, etc.)

compiler

slide-139
SLIDE 139

Laser 2005 - Summer School on Software Engineering 139

IF toolset - core components: exploration platform

step

S S u u c c c c ! ! Interaction model

I1:P2 I2:P1 Time I1:P1 Ik:Pj active instances process 1 process 2 process j Time module

  • utput

I2:P2 create s e t , r e s e t

execution control

run

S S u u c c c c ? ? priorities (scheduling)

run step run step run step

slide-140
SLIDE 140

Laser 2005 - Summer School on Software Engineering 140

IF toolset - core components: exploration platform (time)

i) discrete time

  • clock valuations represented as

varying size integer vectors

  • time progress is explicit and

computed w.r.t. the next enabled deadline

ii) continuous time

  • clock valuations represented using

varying size difference bound matrices (DBMs)

  • time progress represented

symbolically

  • non-convex time zones may arise

because of deadlines: they are represented implicitly as unions of DBMs

Dedicated module

  • including clock variables
  • handling dynamic clock allocation

(set, reset)

  • checking timing constraints (timed

guards)

  • computing time progress conditions

w.r.t. actual deadlines and

  • fires timed transitions, if enabled

Two implementations for discrete and continuous time (others can be easily added)

slide-141
SLIDE 141

Laser 2005 - Summer School on Software Engineering 141

IF toolset - case studies: protocols

SSCOP

Service Specific Connection Oriented Protocol

  • M. Bozga et al. Verification and test generation for the SSCOP
  • Protocol. In Journal of Science of Computer Programming - Special

Issue on Formal Methods in Industry. Vol. 36, number 1, January 2000.

MASCARA

Mobile Access Scheme based on Contention and Reservation for ATM case study proposed in VIRES ESPRIT LTR

  • S. Graf and G. Jia. Verification Experiments on the Mascara Protocol.

In M.B. Dwyer (Ed.) Proceedings of SPIN Workshop 2001, Toronto,

  • Canada. LNCS 2057.

PGM

Pragmatic General Multicast case study proposed in ADVANCE IST-1999-29082

slide-142
SLIDE 142

Laser 2005 - Summer School on Software Engineering 142

IF toolset - ase studies: asynchronous circuits

timing analysis

  • O. Maler et al. On timing analysis of combinational
  • circuits. In Proceedings of the 1st workshop on formal

modeling and analysis of timed systems, FORMATS’03, Marseille, France.

functional validation

  • D. Borrione et al. Validation of asynchronous circuit

specifications using IF/CADP. In Proceedings of IFIP Intl. Conference on VLSI, Darmstadt, Germany

slide-143
SLIDE 143

Laser 2005 - Summer School on Software Engineering 143

IF toolset - case studies: embedded software

Ariane 5 Flight Program

joint work with EADS Lauchers

  • M. Bozga, D. Lesens, L. Mounier. Model-checking Ariane 5

Flight Program. In Proceedings of FMICS 2001, Paris, France.

K9 Rover Executive

S.Tripakis et al. Testing conformance of real-time software by automatic generation of observers. In Proceedings of Workshop on Runtime Verification, RV’04, Barcelona, Spain. Akhavan et al. Experiment on Verification of a Planetary Rover Controller. In Proceedings of 4th International Workshop

  • n Planning and Scheduling for Space, IWPSS’04, Darmstadt,

Germany.

slide-144
SLIDE 144

Laser 2005 - Summer School on Software Engineering 144

IF toolset - Ariane-5 flight program

slide-145
SLIDE 145

Laser 2005 - Summer School on Software Engineering 145

IF toolset - Ariane-5 flight program : the model

  • built by reverse engineering by EADS-LV
  • two independent views
  • 1. asynchronous

– high level, non-deterministic, abstracts the whole program as communicating extended finite-state machines

  • 2. synchronous

– low level, deterministic, focus on specific components …

– we focus on the asynchronous view

slide-146
SLIDE 146

Laser 2005 - Summer School on Software Engineering 146

IF toolset - Ariane-5 flight program: architecture Regulation

engines/boosters ignition/extinction

Configuration

stage/payload separation

Control

Navigation Guidance Algorithms

OBC (On Board Computer) Ground OBC (Redundant)

~3500 lines

  • f SDL code
slide-147
SLIDE 147

Laser 2005 - Summer School on Software Engineering 147

IF toolset - Ariane-5 flight program: regulation components

  • initiate sequences of

“regulation” commands at right moments in time :

– at T0 + ∆1 execute action1 – at T0 +∆2 execute action2 … – at T0 + ∆n execute actionn

  • if necessary, stopped at any

moment

  • described as “sequential”

processes, moving on specific, precise times

start state1

action1

state2 state3

now = T0+∆1 now = T0+∆2 action2 now = T0+∆3 action3 input start-date(T0)

slide-148
SLIDE 148

Laser 2005 - Summer School on Software Engineering 148

IF toolset - Ariane-5 flight program: configuration components

  • initiates “configuration” changes depending on :

– flight phase : ground, launch, orbit, … – control information: reception of some signal, ... – time : eventually done in [T0+L,T0+U]

  • described as processes combining signal and

timeout-driven transitions

slide-149
SLIDE 149

Laser 2005 - Summer School on Software Engineering 149

IF toolset - Ariane-5 flight program: configuration component ( example)

start wait-sig done the opening action eventually happens between Tearly and Tlate moments, if possible, on the reception on the

  • pen signal.

ready wait-time now = Tearly

« opening » input open input open

now = Tearly now = Tlate

slide-150
SLIDE 150

Laser 2005 - Summer School on Software Engineering 150

IF toolset - Ariane-5 flight program: control components

  • compute the flight commands depending on

the current flight evolution

– guidance, navigation and control algorithms

  • abstracted over-simplified processes

– send flight commands with some temporal uncertainty

slide-151
SLIDE 151

Laser 2005 - Summer School on Software Engineering 151

IF toolset - Ariane-5 flight program: control components (example)

time non-deterministic: the firing signal can be sent between T0 + L and T0 + U time deterministic: the firing signal is sent exactly at T0 + K init done

  • utput firing

to vulcain T0 + K = now eager

init done

  • utput firing

to vulcain T0 + L ≤ now and now ≤ T0+U lazy

slide-152
SLIDE 152

Laser 2005 - Summer School on Software Engineering 152

IF toolset - Ariane-5 flight program: requirements

  • general requirements

– e.g. no deadlock, no timelock

  • overall system requirements

– e.g. flight phase order – e.g. stop sequence order

  • local component requirements

– e.g. activation signals arrive eventually in some predefined time intervals

slide-153
SLIDE 153

Laser 2005 - Summer School on Software Engineering 153

IF toolset - Ariane-5 flight program: validation (model exploration)

  • test simple properties by random or guided simulation
  • several inconsistencies because timing does not respect

causality e.g., deadline missed because of ∆1 > ∆2

  • utput status

now = T0+∆1 now = T0+∆2

  • utput desactivation

input status

slide-154
SLIDE 154

Laser 2005 - Summer School on Software Engineering 154

IF toolset - Ariane-5 flight program: Validation (static analysis)

  • Clock reduction

1st version: 143 clocks reduced to 41 clocks 2nd version : 55 clocks, no more reduction

  • Live variable analysis

20% of all variables are dead in each state

  • Dead code analysis

eliminates passive processes (without outputs and requirements are independent of their events)

slide-155
SLIDE 155

Laser 2005 - Summer School on Software Engineering 155

IF toolset - Ariane-5 flight program: Validation

Some results (for 31 processes)

time deterministic time non-deterministic

  • live reduction
  • partial order

n.a. n.a. + live reduction

  • partial order

2201760 st. 18796871 tr. n.a. + live reduction + partial order 1604 st. 1642 tr. 195718 st. 278263 tr.

slide-156
SLIDE 156

Laser 2005 - Summer School on Software Engineering 156

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
slide-157
SLIDE 157

Laser 2005 - Summer School on Software Engineering 157

The BIP framework

Interaction model Priority

Execution kernel

Platform

slide-158
SLIDE 158

Laser 2005 - Summer School on Software Engineering 158

The BIP framework – the execution platform

Interaction Meta-model Dynamic priorities Meta-model

Description in L C⇒ a<b Component Meta-model C⇒ a<b

L

Execution kernel

slide-159
SLIDE 159

159

Implementation Implementation -

  • atomic component: abstract syntax

atomic component: abstract syntax

Component: C Ports: p1,p2, … Data: x,y,z, …. Access: (p1,{x,y,z}), (p2,{x,u,v}), Behavior: state s1

  • n p1 provided g1 do f1 to state s1’

……………… ……

  • n pn provided gn do fn to state sn’

state s2

  • n …..

………. state sn

  • n .. ..
slide-160
SLIDE 160

160

Implementation Implementation -

  • atomic components

atomic components

run() { Port* p; int state = 1; while(true) { switch(state) { case 1: p = sync(a, ga, d, gd); if (p == a) fa; state = 2; else fd; state = 3; break; case 2: p = sync(b, gb, e, ge); … case 3: … } } }

2 3

a ga fa b gb fb c gc fc d gd fd e ge fe f gf ff

1

slide-161
SLIDE 161

161

Implementation Implementation -

  • connectors and priorities: abstract syntax

connectors and priorities: abstract syntax Connector: BUS={p, p’, … , } complete() Behavior:

  • n α1 provided gα1 do fα1
  • n α2 provided gα2 do fα2

Priorities: PR if C1 then {(α1, α2), (α3, α4) , … } if C2 then {(α,…), (α,…) , … } if Cn then {(α,…), (α,…) , … }

slide-162
SLIDE 162

Laser 2005 - Summer School on Software Engineering 162

The BIP framework - modulo-8 counter : atomic component

Zero’ One’

flip gflip: X=1 fflip: Y:=1 tick tick flip gflip: X=1 fflip: Y:=0

Zero One

tick tick tick

counter

in:X

  • ut:Y
slide-163
SLIDE 163

Laser 2005 - Summer School on Software Engineering 163

The BIP framework - modulo-8 counter: architecture

in:X1 in:X2 in:X0

  • ut:Y0
  • ut:Y1
  • ut:Y2

tick1 tick0 tick2 AND

slide-164
SLIDE 164

Laser 2005 - Summer School on Software Engineering 164

The BIP framework - modulo-8 counter: the model tick 〈 flip0 , tick 〈 flip1 , tick 〈 flip2 CN: tick={tick0, tick11 , tick2} CI: ∅

Transfer : X1 := Y0; X2 := Y1 ∧ Y0 in:X1 in:X2 in:X0

  • ut:Y0

CN: tick0, flip0 CI: flip0 CN: tick1, flip1 CI: flip1 CN: tick2, flip2 CI: flip2

  • ut:Y1
  • ut:Y2
slide-165
SLIDE 165

Laser 2005 - Summer School on Software Engineering 165

The BIP framework – readers/writers: architecture

Idle Writing wrReq wrRel rdRel rdCount == 0 Idle Rd_Busy Wr_Busy rdReq rdRel, rdCountr>0 rdReq wrRel wrReq wrRel wrReq wrReq wrRel rdReq rdRel file rdRel rdReq quantum Idle Reading rdReq rdRel repository rdData_i file quantum

Reader_i Resource Writer

slide-166
SLIDE 166

The BIP framework – readers/writers: resource model

Component : Resource Port: wrReq, rdReq, rdRel, wrRel Data: repository, rdID , rdData0 , rdData1 , …. rdDatan Access: (wrRel, {repository}), (rdRel, {rdData0 , rdData1 , …. rdDatan }), (rdReq,{rdID}) Behavior : (State : Idle, RdBusy, WrBusy) state Idle

  • n wrReq provided (true) do {Nop} to state WrBusy
  • n rdReq provided (true) do {rdDatardID := get(repository), rdCount++}

to state RdBusy state WrBusy

  • n wrRel provided (true) do {Nop} to state Idle

state RdBusy

  • n rdReq provided (true) do {rdDatardID := get(repository), rdCount++} to state

RdBusy

  • n rdRel provided (rdCount > 0) do {rdCount -- } to state RdBusy
  • n rdRel provided (rdCount ==0) do {Nop} to state Idle

Laser 2005 - Summer School on Software Engineering 166

slide-167
SLIDE 167

Laser 2005 - Summer School on Software Engineering 167

The BIP framework – readers/writers: writer model

Component : Writer Port : wrReq, wrRel Data : file, quantum Access : (wrRel, {quantum}) Behavior : (States : Idle, Writing) state Idle

  • n wrReq provided (true) do { quantum:=get(file)} to state Writing

state Writing

  • n wrRel provided (true) do { Nop} to state Idle
slide-168
SLIDE 168

Laser 2005 - Summer School on Software Engineering 168

The BIP framework – readers/writers: reader model

Component: Reader Port: rdReq, rdRel, Data: file, quantum Access: (rdRel, {quatum}) Behavior (States : Idle, Reading) state Idle

  • n rdReq provided (true) do {Nop} to state Reading

state Reading

  • n rdRel provided (true) do {put(quantum,file) } to state idle
slide-169
SLIDE 169

Laser 2005 - Summer School on Software Engineering 169

The BIP framework – Readers/Writers: connectors

Connector : WrReq = {Writer.wrReq, Resource.wrReq} Complete() :∅ Behavior: On WrReq provided (true), do {Nop} Connector : WrRel = {Writer.wrRel, Resource.wrRel} Complete() : ∅ Behavior: On WrRel provided (true), do { put(quantum,repository)} Connector : RdReqi = {Resource.rdReq, Readeri.rdReq} Complete() : ∅ Behavior: On RdReqi, provided (true), do {RdID:=i} Connector: ReadReli = { Resource.rdRel, Readeri.rdRel } Complete() : ∅ Behavior: On RdReli , provided (true), do {Readeri.quantum:=RdDatai}

slide-170
SLIDE 170

Laser 2005 - Summer School on Software Engineering 170

The BIP framework - Readers/Writers: state graph

slide-171
SLIDE 171

Laser 2005 - Summer School on Software Engineering 171

The BIP framework – implementation: the kernel p1 p2 p3 P.run

{p1,q1} { p2,q2} {p3, q3} {p3 ,q3 , r1} {q2 ,r2 }

q1 q2 q3 Q.run r1 r2 R.run Kernel.run

slide-172
SLIDE 172

Laser 2005 - Summer School on Software Engineering 172

The BIP framework – implementation: the kernel init loop

Launch atom’s threads

stable

Wait all atoms

ready

Compute legal interactions

filter

Filter w.r.t. priorities

choose

Choose among maximal

execute

Execute chosen interaction transfer Notify involved atoms

slide-173
SLIDE 173

Laser 2005 - Summer School on Software Engineering 173

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
slide-174
SLIDE 174

Laser 2005 - Summer School on Software Engineering 174

General discussion - the BIP framework

  • Framework for component-based modeling encompassing heterogeneity

and relying on a minimal set of constructs and principles e.g. interaction models + dynamic priorities

  • Clear separation between behavor and structure.

Structure is a first class entity Correctness-by-construction techniques for deadlock- freedom and liveness, based on suficient conditions on structure (mainly)

  • Applications at Verimag

IF toolset allows layered description of timed systems, Methodology and tool support for generating scheduled code for real-time applications (work by S. Yovine et al.)

slide-175
SLIDE 175

Laser 2005 - Summer School on Software Engineering 175

General discussion – work dealing with components

  • Architecture Description Languages focusing on non-functional aspects or

SW Design Description Languages

  • Modeling languages: Statecharts, UML, Simulink/Stateflow, Synchronous

languages, SystemC, Metropolis, Ptolemy

  • Coordination languages (extensions of programming languages): Linda,

Javaspaces, TSpaces, Concurrent Fortran, …

  • Middleware standards: IDL, Corba, Javabeans, .NET
  • Software development environments: PCTE, SWbuses, Softbench, Eclipse
  • Process algebras and automata : Pi-Calculus, ORC, automata-based

approaches

slide-176
SLIDE 176

General discussion – related approaches

Metropolis PTOLEMY

Laser 2005 - Summer School on Software Engineering 176

ASML .net Composition Operators

Vanderbilt’s Approach

Operational Semantics

Semantic Unit Meta-model Behavior Semantic Unit Meta-model Platform Connectors Directors Semantic Domains Behavior MoC

(Model of Computation)

Media Quantity Managers Behavior Platform

Operational Semantics Operational Semantics

slide-177
SLIDE 177

Laser 2005 - Summer School on Software Engineering 177

General discussion – future work Develop a rigorous and general basis for architecture modeling and implementation:

  • Study the concept of architecture as a means to organize computation

(components, interaction, control)

  • Define a meta-model for real-time architectures, encompassing specific

styles, paradigms, e.g.

  • Modeling synchronous reactive systems
  • Event driven vs. state driven interaction (distinction event ports /

state ports)

  • Hierarchical modeling
  • Timed systems
  • Distributed real-time systems, GALS
  • Architecture styles e.g. client-server, blackboard architecture
  • Provide automated support for component integration and generation of

glue code meeting given requirements

slide-178
SLIDE 178

General discussion – future work: synchronous reactive systems

Data flow partial order

Laser 2005 - Summer School on Software Engineering 178

input1:x1

  • utput1:y1

input4:x4

  • utput4:y4

input2:x2

  • utput2:y2

input3:x3

  • utput3:y3

input1:x1

  • utput1:y1

input4:x4

  • utput4:y4

input2:x2

  • utput2:y2

input3:x3

  • utput3:y3

Connector: s1,s2,s3,s4 transfer: x2,x3:=y1; x4:=y2,y3 Priority: lowest

s1 s2 s3 s4

slide-179
SLIDE 179

Laser 2005 - Summer School on Software Engineering 179

General discussion – future work: hierarchical modeling p1 p2 p3 q1 q2 q3 r1 r2 p1 q1 p2 q2 p3 q3 w1 r1 w2 r2 v1 v2 w1 w2

Pb: coordination between fathers and children

slide-180
SLIDE 180

Laser 2005 - Summer School on Software Engineering 180

General discussion – future work: expressiveness Study Component Algebras CA= (B, GL,⊕, ≅)

  • (GL,⊕) is a monoid and ⊕ is idempotent
  • ≅ is a congruence compatible with operational semantics
  • Study classes of glue operators
  • Focus on properties relating ⊕ to ≅

Study notions of expressiveness characterizing structure Given CAi= (B, GLi,⊕i, ≅i), i=1,2, CA1 is more expressive than CA2 if ∀ P ∃ gl2∈GL2 gl2(B1, .,Bn) sat P ⇒ ∃ gl1∈GL1. gl1(B1, …Bn) sat P

slide-181
SLIDE 181

Laser 2005 - Summer School on Software Engineering 181

General discussion – future work: expressiveness(2)

IM B

C⇒ a 〈 b

PR

Example: For given B, IM and PR which coordination problems can be solved?

Notion of expressiveness different from existing ones which

  • Either completely ignore structure
  • r use operators where separation between structure and behavior

seems problematic e.g. hiding, restriction