Constraints bliudze-slides-sc2011

Synthesizing Glue Operators from Glue
Constraints for the Construction of
Component-Based Systems
Simon Bliudze and Joseph Sifakis

Z¨rich, June 30th , 2011
u

Outline

Motivation
BIP and the Glue
Synthesizing glue operators
Design ﬂow

Quite some liberties taken w.r.t. the paper for the sake of the pre-
sentation clarity!

SC 2011 — S. Bliudze, J. Sifakis, “Synthesizing Glue Operators...” — Z¨rich, June 30th , 2011 — 2 / 29
u

Outline

Motivation
BIP and the Glue
Design ﬂow

u

At the TOOLS keynote on Tuesday...

...Oscar Nierstrasz spoke of the necessity of
Manipulating the models
Bridging the gap between high-level models
and run-time code
Questions:
Recently, did we get any closer to these
objectives? If not, what is the way there?
Does not raising the abstraction level rather
increase the gap?
Answer:
We should build solid and light-weight bridges!

u

Solid and light-weight bridges

A unified modelling formalism

Solid:
Clearly established formal semantics
Heterogeneity
computation, execution, implementation
Certifying code generation

Light-weight:
Clear, accessible formal semantics
Minimal set of primitives
Separation of concerns
coordination is a first-class citizen
Efficient implementation for popular platforms
u

More speciﬁcally
Context: Component-based modelling, design and validation of
embedded (safety-critical) systems.
Presently:
A number of coordination mechanisms for concurrent systems
shared variables, semaphores, message passing, etc.
Ad-hoc use and analysis methodologies.

Our goal: Uniﬁed framework for component-based modelling and
design
Incremental description
Correctness by construction
Heterogeneity
synchronous and asynchronous execution
event- and data-driven computation
centralised and distributed implementation

u

Outline

Motivation
BIP and the Glue
Design ﬂow

u

Component design by reﬁnement

Three layers:
1 Component
behaviour
2 Coordination
3 Data transfer

u


Three layers:
1 Component f1
behaviour A p1
2 Coordination b1 r1

3 Data transfer
b2
p3 f3 B
b3 f2
C
r3

u


Three layers:
1 Component f1
behaviour A p1

3 Data transfer
b2
p3 f3 B
b3 f2
C
r3

u


Three layers:
A.x:=max(B.y ,C .z)
1 Component f1
behaviour A p1

3 Data transfer
b2
p3 f3 B
b3 f2
C
r3

u

Unbuﬀered synchronous communication
(Not to confuse with synchronous execution!)

Channel
collect deliver

d
d
Channel.buf :=A.m dB.m:=Channel.buf
d
send receive

A B

A sends a message m to B:
Two synchronisations with the channel
Each synchronisation allows a data transfer
An explicit model of the channel behaviour
u

Scope of the basic BIP model

f1
A p1
b1 r1

Three layers:
b2
1 Component behaviour p3 f3 B
b3 f2
2 Coordination C
r3
3 Data transfer

Interesting results already at this level, e.g.
Analysis of synchronisation deadlocks
S. Bensalem, M. Bozga, J. Sifakis, T.-H. Nguyen. D-Finder: A Tool for Compositional
Deadlock Detection and Veriﬁcation. [CAV’09]

Synthesis of glue for safety properties

u

Basic model of BIP

Priorities (conﬂict resolution)
Interactions (collaboration)
B E H A V I O U R

Layered component model
Behaviour — labelled transition systems with disjoint sets of
ports
Interaction — set of interactions (interaction = set of ports)
Priorities — strict partial order on interactions

u

BIP examples
Modulo-8 counter:
i i i
p ! pq q r ! rs
s t
! tu
u
p r t
i i
i

Interactions: {p, pqr , pqrst, pqrstu}.

Mutual exclusion:
i i
b1 ! b1 f1 b2 ! b2 f2
f1 f2
w
i w
i

Interactions: {b1 , f1 , b2 , f2 }
Priority: b1 f2 , b2 f1 .

u

Glue semantics in BIP: Solid
Bi = (Qi , Pi , →i ,↑ i ): Pi pairwise disjoint, P = i Pi
→ ⊆ Q × 2P × Q
a
↑ ⊆ Q × P such that (∃a ∈ 2P : p ∈ a ∧ q →) ⇒ q ↑ p

Interaction model: γ ⊆ 2P — set of allowed interactions
a∩P
i
qi −→ qi i ∈ [1, n], a ∩ Pi = ∅
a
for each a ∈ γ ,
q1 . . . qn → q1 . . . qn
where qi denotes qi if a ∩ Pi = ∅, and qi otherwise.

Priority model: ⊆ 2P × 2P — strict partial order
a
q → q {q ↑ a | a a}
a for each a ∈ 2P
q→ q

u

Outline

Motivation
BIP and the Glue
Design ﬂow

u

Connector synthesis
b f
i Mutual preemption:
p
f b 1 A running task is preempted, when the
Tc p r
i
w
E
i other one begins computation.
'
r 2 A preempted task resumes computation,
when the other one ﬁnishes.

true ⇒ b1 ∨ f1 ∨ b2 ∨ f2 u u
b1 f1 r2 p2
p1 ⇒ b2 p2 ⇒ b1 p1 u b2
T1 T2
r1 ⇒ f2 r2 ⇒ f1 r1 u f2

Mutual exclusion?.. {b1 , b2 , b1 p2 , b2 p1 ,
f1 , f2 , f1 r2 , f2 r1 }
S. Bliudze, J. Sifakis. Causal semantics for the algebra of connectors. In Formal Methods in System Design, 2010.

u

Mutual exclusion (design front-end)
i i
b1 ! b1 f1 b2 ! b2 f2
f1 f2
w
i w
i

1 B1 can enter the critical state if B2 is in the non-critical one
or leaves the critical state simultaneously
fire(b1 ) ⇒ ¬active(f2 ) ∨ fire(f2 )
2 Idem for B2 :
fire(b2 ) ⇒ ¬active(f1 ) ∨ fire(f1 )
3 B1 and B2 cannot enter the critical state simultaneously

¬ fire(b1 ) ∧ fire(b2 )

u

Mutual exclusion (semantic back-end)
Notation: For a port p ∈ P, let p and p — boolean activation
˙
and ﬁring variables

Constraints:
b˙1 ⇒ f2 ∨ f˙ ∧ b˙2 ⇒ f1 ∨ f˙ ∧ b˙1 b˙2 — Mutual exclusion
2 1

∧ b1 ∨ f1 ∨ b2 ∨ f2 — Progress
∧ f˙ f˙ ∧ f˙ ∨ f˙ ⇒ b1 b2
1 2 1 2 — “Internality” of ﬁnish
= b˙1 b˙2 f˙ f˙ ∨ b˙1 b˙2 f˙ f˙ ∨ b˙1 b˙2 f˙ f˙ f2 ∨ b˙1 b˙2 f˙ f˙ f1
1 2 1 2 1 2 1 2

1f 2 f 1 b 2 b
q1 → q1 q2 → q2 q1 → q1 q2 ↑ f2 q1 ↑ f1 q2 → q2
f
, f
, b
, b
1 2 1 2
q1 q2 → q1 q2 q1 q2 → q1 q2 q1 q2 → q1 q2 q1 q2 → q1 q2

Priorities: b1 f2 , b2 f1

u

Rescue robot (design front-end)

f r r
u
N E
b a a

m
S h

R

1 Must not advance and rotate at the same time: a r ;
˙˙
2 Must not leave the region: b ⇒ a ;
˙
3 Must not drive into hot areas: h ⇒ a ;
˙
4 Must stop, when objective is found: f ⇒ a r ;
˙ ˙
5 Must update navigation and sensor data on every move
(advance or rotate): a ∨ r ⇒ u m .
˙ ˙ ˙ ˙

u

Rescue robot (semantic back-end)
a r ∧ (b ⇒ a) ∧ (h ⇒ a) ∧ (f ⇒ a r ) ∧ (a ∨ r ⇒ u m) — Safety
˙˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙
∧ (a ∨ r ∨ u ∨ m) ∧ h b f˙
˙ ˙ ˙ ˙ ˙ ˙ — Progress
= a r u m ∨ a r u m ∨ a r u m ∨ a r f u m ∨ a r b h f u m ∧ h b f˙
˙ ˙˙ ˙ ˙ ˙˙ ˙ ˙ ˙ ˙ ˙ ˙˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙ ˙

u m u m
qn → qn qs → qs qn → qn qs → qs
, , ,
u mu m
qe qs qn → qe qs qn qe qs qn −→ qe qs qn qe qs qn → qe qs qn
r m u
qe → qe qs → qs qn → qn qn ↑ f
,
rmu
qe qs qn −→ qe qs qn
a m u
qe → qe qs → qs qn → qn qs ↑ h qn ↑ b qn ↑ f
.
amu
qe qs qn −→ qe qs qn

u

General case

˙
Constraints: B[P, P] with an axiom p ⇒ p
˙

SOS rules:
ai
Bi : qi −→ qi Bj : qj ↑ bj Bk : qk ↑ cs s ∈ Lk
i∈I j∈J k∈K
a
gl(B1 , . . . , Bn ) : q1 . . . qn −→ q1 . . . qn

Theorem
Constraint glues and SOS glues are equivalent.

u

Outline

Motivation
BIP and the Glue
Design ﬂow

u

Design flow

1 Choice of the functionalities to be realized by sequential
atomic components.
2 Independent design of sequential atomic components.
3 Specification of state safety properties to be satisfied by the
system.
4 Automatic glue operator and connector synthesis. This
implies that the underlying state safety properties are satisfied
by construction.

u

Existing BIP desing ﬂow

http://www.slideshare.net/sbliudze/bip-design-ﬂow
http://www-verimag.imag.fr/The-BIP-Design-Flow.html

u

Conclusion

We have
Taken BIP one step closer to something
Solid — by improving semantics of hierarchical composition
Light-weight — by isolating designers from low-level details
Through separation of concerns, reduced a very hard problem
of synthesizing controllers to a tractable one.
Given a natural boolean characterisation of glue through
constraints ⇒ symbolic manipulation with BDDs.
u

Thank you for your attention!

u

SOS operator example

Glue operator g deﬁned by the following rules
a a c b c
q1 → q1 q → q1 q2 → q2 q → q1 q2 →
a , 1 ac , 1 b
q1 q2 → q1 q2 q1 q2 → q1 q2 q1 q2 → q1 q2

Behaviours Parallel product Application of glue
B1 , B2 B1 B2 g (B1 , B2 )

a c a
a ac ac
b c a a
c
bc
b
c b b

u

Constraints bliudze-slides-sc2011

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

Constraints bliudze-slides-sc2011