Rigorous System Design
Joseph SifakisRiSD Laboratory EPFL
PODC 2014Paris
16-18 July 2014
System Design – About Design
RECIPE(Program)
Put apples in pie plate; Sprinkle with cinnamon and 1 tablespoon sugar;
In a bowl mix 1 cup sugar, flour and butter;
Blend in unbeaten egg, pinch of salt and the nuts;
Mix well and pour over apples;Bake at 350 degrees
for 45 minutes
INGREDIENTS(Resources)
1 pie plate buttered5or 6 apples, cut up¾ c. butter, melted
1 c. flour½ c. chopped nuts1tsp cinnamon1tbsp sugar1c. Sugar1 egg
Apple Pie
Design is a Universal Concept! .
Pro
cedu
raliz
atio
n
Mat
eria
lizat
ion
System Design – Two Main Gaps
Req
uire
men
ts(d
ecla
rativ
e)
App
licat
ion
SW
(exe
cuta
ble)
Sys
tem
(HW
+SW
)
Correctness? Correctness?
App
licat
ion
SW
Dev
elop
men
t
Impl
emen
tatio
n
Rigorous System Design – The Concept
Considers design as a formal accountable and iterative process for deriving trustworthy and optimized implementations from an application software and models of its execution platform and its external environment
Model-based: successive system descriptions are obtained by correct-by-construction source-to-source transformations of a single expressive modelrooted in well-defined semantics
Accountable: possibility to assert which among the requirements are satisfied and which may not be satisfied
Focuses on mastering and understanding design as a problem solving process based on divide-and-conquer strategies involving iteration on a set of steps and clearly identifying
points where human intervention and ingenuity are needed to resolve design choices through requirements analysis and confrontation with experimental results
segments that can be supported by tools to automate tedious and error-prone tasks
Rigorous System Design – Four Guiding Principles
Separation of concerns: Keep separate what functionality is provided (application SW) from how its is implemented by using resources of the target platform
Coherency: Based on a single model to avoid gaps between steps due to the use of semantically unrelated formalisms e.g. for programming, HW description, validation and simulation, breaking continuity of the design flow and jeopardizing its coherency
Components: Use components for productivity and enhanced correctness
Correctness-by-construction: Overcome limitations of a posteriori verification through extensive use of provably correct reference architectures enforcing essential properties as well as source-to-source transformations
Rigorous System Design – Simplified Flow
Integration ofArchitectural Constraints
Code GenerationIntegration of
Communication Glue
RequirementsRequirements
D-Finder
Cost/PerformanceAnalysis
Embedding
Application SWModel in BIP
Deployable Code Distributed System Modelin S/R-BIP
System Model in BIP
MappingExecution PlatformModel
Application SW
OVERVIEW
7
Rigorous System Design Component-based Design Correct-by-construction Design
The BIP Framework Modeling Interactions Modeling Priorities Distributed Implementation
Discussion
Component-based Design
Execution Platform
Any engineering discipline uses a limited number of types of components and rules for interconnecting them.This is a prerequisite for the development of formal frameworks!
There is no Common Component Model for computing systems!- Heterogeneity
Component-based Design – Synchronous vs. Asynchronous
Open problem: Theory for consistently composing synchronous and asynchronous components e.g. GALS
Synchronous components (HW, Multimedia application SW) Execution is a sequence of non interruptible steps
step step step step
Asynchronous components (General purpose application SW) No predefined execution step
Component-based Design – Synchronous vs. Asynchronous
10Matlab/Simulink
Component-based Design – Synchronous vs. Asynchronous
UML Model (Rational Rose)
Component-based Design – Interaction Mechanisms
Broadcast: asymmetric synchronization triggered by a Sender
Existing formalisms and theories are not expressive enough
use variety of low-level coordination mechanisms including semaphores, monitors, message passing, function call
encompass point-to-point interaction rather than multiparty interaction
Rendezvous: atomic symmetric
synchronization
Thread-based programming
Component-based Design – Programming Styles
Software Engineering
Actor-based programming
Systems Engineering
Component Heterogeneity – Composition
Most component composition frameworks fail to meet these requirements Some are formal such as process algebras e.g. CCS, CSP, pi-
calculus Other are ad hoc such as most frameworks used in software
engineering e.g. ADL, or systems engineering e.g. SystemC
Is it possible to express component coordination in terms of composition operators?We need a unified composition paradigm for describing and analyzing the coordination between components in terms of tangible, well-founded and organized concepts and characterized by Orthogonality: clear separation between behavior and coordination
constraints Minimality: uses a minimal set of primitives Expressiveness: achievement of a given coordination with a minimum
of mechanism and a maximum of clarity
The Concept of Glue
Build a component C satisfying a given property P, from C0 a set of atomic components described by their behavior GL ={gl1, …, gli, …} a set of glue operators on components
c1 c’1gl1
c2 c’2
gl12sat Pgl2
Glue operators are stateless – separation of concerns between behavior and coordination
Component-based Design – Glue Operators
B1gl
B2 Bn
We use operational semantics to define the meaning of a composite component – glue operators are “behavior transformers”
OperationalSemantics
B
Glue Operators build interactions of composite components from the actions of the atomic components e.g. parallel composition operators can be specified by using a family of operational semantics rules (the Universal Glue)
Component-based Design – Glue Operators: Example
a c
b
b
c
c
cbc
gl is defined by
q1 - a q’1 q1 q2 - a q’1 q2
q1 - a q’1 q2 - c q’2q1 q2 - ac q’1 q’2
q1 - b q’1 q2 - cq1 q2 - b q’1 q2
B1 B2
gl(B1,B2)a
a
b
ac
Component-based Design – Glue Operators
qi - ai i q’i iI C(qk) kK(q1 qn- a (q’1 q’n
A glue operator defines interactions as a set of derivation rules of the form
I,K {1, …n}, I
a= i I aI is an interaction q’i = qi for i I
A glue is a set of glue operators
Component-based Design – Glue Operators: Properties
Glue is a first class entity independent from behavior that can be decomposed and composed
gl1
1. Incrementality
gl gl2
gl2gl1
2. Flattening
gl
Component-based Design – Glue Operators: Expressiveness
c1 c2 c3 c4 c1 c3 c2 c4gl1
gl1gl1
Given two glues G1 , G2 G2 is strongly more expressive than G1if for any component built by using G1 and a set of components C0there exists an equivalent component built by using G2 and C0
Different from the usual notion of expressiveness!
Based on strict separation between glue and behavior
Component-based Design – Glue Operators: Expressiveness
c3c1 c2 c1 c3 c c2gl1
gl1gl1
Given two glues G1 , G2 G2 is weakly more expressive than G1
if for any component built by using G1 and a set of components C0there exists an equivalent component built by using G2 and C0 Cwhere C is a finite set of coordinating components.
Component-based Design – Glue Operators: Expressiveness
BIP BI CCS
SCCS
CSP
S. Bliudze and J. Sifakis “A Notion of Glue Expressiveness for Component-Based Systems” CONCUR'08 LNCS 5201, 508-522, Springer, 2008
SUniversal
Glue
OVERVIEW
23
Rigorous System Design Component-based Design Correct-by-construction Design
The BIP Framework Modeling Interactions Modeling Priorities Distributed Implementation
Discussion
Correct-by-Construction
Execution Platform
System Model
sat Functional
sat E
xtra
-Fun
ctio
nal
: refinement relation preserving functional properties
Requirements
Application SW
Focus on invariants and deadlock-freedom
25
Correct-by-Construction – Architectures
Architectures depict design principles, paradigms that can be understood
by all, allow thinking on a higher plane and avoiding low-level mistakes
are a means for ensuring global properties characterizing the coordination between components – correctness for free
Using architectures is key to ensuring trustworthiness and optimization in networks, OS, middleware, HW devices etc.
System developers extensively use libraries of reference architecturesensuring both functional and non functional properties e.g. Fault-tolerant architectures Resource management and QoS control Time-triggered architectures Security architectures Adaptive Architectures
26
Correct-by-Construction – Architectures
An architecture is a family of operators A(n)[X] parameterized by their arity n and a family of characteristic properties P(n)
A(n)[B1,..,Bn] = gl(n) (B1,..,Bn, C(n)), where C(n) is a set of coordinators
A(n)[B1,..,Bn] meets the characteristic property P(n).
Client-Server Architecture
C C S S
Glue
C C S S
Transaction Processing Component=
Characteristic property: atomicity of transactions, fault-tolerance ….
Note that the characteristic property need not be formalized!
27
Correct-by-Construction – Architectures
Components
Architecturefor Mutual Exclusion
Rule1: Property Enforcement
Architecturefor Mutual Exclusion
satisfies Mutex
Correct-by-Construction – Architectures: Composability
Mutual Exclusion
Rule2: Property Composability
Scheduling Policy
Mutual Exclusion
Scheduling Policy
Feature interaction in telecommunication systems, interference among web services and interference in aspect programming are all manifestations of a lack of composability
Sifakis et al “A General Framework for Architecture Composability” SEFM 2014
Correct-by-Construction – Refinement
Rendezvous
Protocol (Asynch Message Passing)
The Refinement Relation
S1 S2
S1 S2 (S2 refines S1) if all traces of S2 are traces of S1(modulo some observation criterion) if S1 is deadlock-free then S2 is deadlock-free too is preserved by substitution
Proof by establishing simulation or bisimulation relations between S1 and S2
C1 C2 C4 C’1C3 C’2 C’3 C’4
glProtocol
C’1 C’2
Rendezvous
C1 C2
glRendezvous
C1 C2
Correct-by-Construction – Refinement Preservation
Preservation of by substitution
Protocol
C’1 C’2
Correct-by-Construction – Refinement Preservation
a
C1 C2
str(a)
cmp(a)
rcv(a)
ack(a)
C’1 C’2D
ab
C1 C2C3
str(a)
cmp(a)
rcv(a)
ack(a)cmp(b)
rcv(b)
ack(b)
C’1 C’2C’3D13 D23
str(b)
OVERVIEW
32
Rigorous System Design Component-based Design Correct-by-construction Design
The BIP Framework Modeling Interactions Modeling Priorities Distributed Implementation
Discussion
Modeling in BIP – Basic Concepts
B E H A V I O RInteractions (protocols)Priorities (schedulers)
Layered component model
Composition operation parameterized by glue IN12, PR12
IN12PR12
PR1 IN1
PR2 IN2 IN1 IN2 IN12
PR1 PR2 PR12S2S
S2S
S2S
S2S
S2S
S2S
Expressiveness
Modeling in BIP – Atomic Components
in_x
in_y
in_xx
yin_y
z:=x2‐y2
out outz
Interface: set of ports and associated variables
Behavior: set of transitions of the form
(port, guard, assignment)s’s
Modeling Interactions – Connectors
s + sr2 + sr3 +sr2r3
A connector is a set of ports that can be involved in an interaction
tick1 tick2 tick3
s r2 r3
tick1tick2tick3
Port attributes (trigger , synchron ) are used to model rendezvous and broadcast.
An interaction of a connector is a set of ports such that: either it contains some trigger or it is maximal.
Express interactions by combining two protocols: rendezvous and broadcast
Modeling Interactions – Connectors
Atomic Broadcast:a+abc
Causality chain: a+ab+abc+abcd
c d
c(1+d)
b c
bca(1+bc)
a
y=b(1+y)
b
x=a(1+x)
a
Modeling Interactions – Connectors
bca(1+bc)
a b c
Atomic Broadcasta’[bc]
b(1+c(1+d))c(1+d)
a(1+b(1+c(1+d)))
a b c d
Causality chaina’[b’[c’d]]
a(1+b)(1+c)
a b c
Broadcasta’bc
Modeling Interactions – Connectors
a b c a b c
+
[a’b]’c a’bc
a ba
a’b’
a b
a’b
a ba
ab’
Modeling Interactions – Connectors with Data Transfer
p, xp q, xqw, xw
(w pq). [ (0xp 0xq) : xw:= max(xp ,xq) // xp:=xw, xq:=xw]
Guard UpstreamComputation
DownstreamComputation
Interactionpq named w
Note: There is no distinction between input and output ports
Modeling Interactions – Connectors with Data Transfer
p xp q xq
w xwr xr
(w pq).[ xw:= max(xp ,xq) // xp:= xw, xq:= xw](r ws).[ xr:=max(xw ,xs) // xw:= xr, xs:=xr]
s xs
p xp q xq
r xrs xs
(r pqs).[ xr:= max(xp,xq,xs) // xp:=xr, xq:= xr, xs:= xr]
Modeling Interactions – Some Results
The algebra of connectors Axiomatization Boolean representation allowing efficient implementation with BDDs
Simon Bliudze, Joseph Sifakis: The Algebra of Connectors - Structuring Interaction in BIP. IEEE Trans. Computers 57(10): 1315-1330 (2008)
Synthesis of connectors
Simon Bliudze, Joseph Sifakis: Synthesizing Glue Operators from Glue Constraints for the Construction of Component-Based Systems. Software Composition 2011: 51-67.
Dynamic Connectors
Sifakis et al : Modeling Dynamic Architectures Using Dy-BIP. Software Composition 2012: 1-16
OVERVIEW
42
Rigorous System Design Component-based Design Correct-by-construction Design
The BIP Framework Modeling Interactions Modeling Priorities Distributed Implementation
Discussion
Modeling Priorities
g1 g2
Priority rule Restricted guard g1’true p1 p2 g1’ = g1 g2
C p1 p2 g1’ = g1 C g2 )
p1 p2
Priority rules
Modeling Priorities – FIFO policy
PR : t1 t2 b1b2 t2
Modeling Priorities – EDF policy
idle1
ready1
exec1
idle2
ready2
exec2f1
b1
a1
b2
a2
f2
PR: D1-t1 D2- t2 b2 b1 D2-t2< D1-t1 b1 b2
t1:=0 t2:=0
t1 D1 t2 D2
Modeling Priorities – Composability
PR1PR2
PR2PR1
a 1 b b2 c
b2 ca 1 b
a cb
cb
c
a ca c
Modeling Priorities – Composability
PR1PR2 is the least priority containing PR1PR2
Results :•The operation is partial, associative and commutative• PR1(PR2(B))PR2(PR1(B))• PR1PR2(B) refines PR1PR2(B) refines PR1(PR2(B)) • Priorities preserve deadlock-freedom
PR1PR2 PR1PR2
We take:
=
Modeling Priorities – Mutual Exclusion + FIFO policy
true b1 f2 true b2 f1
t1 t2 b1 b2 t2< t1 b2 b1
idle1
ready1
exec1
idle2
ready2
exec2f1
b1
a1
b2
a2
f2
t1:=0 t2:=0
Modeling Priorities – Deadlock Detection
s1 b1
w2a1
f1
a2
f2
PR : b1 f2 b2 { f1, b1’} (mutex on R)
b2’
w1
b1’ b2
R
RR’ RR’
R’
Risk of deadlock: PRPR’ is not defined
PR’: b2’ f1 b1’ { f2, b2 } (mutex on R’)
s2
OVERVIEW
50
Rigorous System Design Component-based Design Correct-by-construction Design
The BIP Framework Modeling Interactions Modeling Priorities Distributed Implementation
Discussion
Distributed Implementation – The BIP Toolset
Distributed Computing Infrastructure
C nesC DOL Lustre SimulinkBIP
ParserLanguage
Factory
Embedding Tools
VerificationD-Finder
BIP Compiler
BIP model
S/R BIP model
C++ generator(engine-based)
Distributed BIPgenerator
C/C++ C/C++
Code generation and runtimes
BIP Execution Engine
BIP executable
C/C++ C/C++
BIP executable
S2STransformers
Platform model
BIP executable
BIP executable
BIP metamodel
Model Repository
Distributed Implementation – From BIP to S/R-BIP
BIP is based on: Global state semantics, defined by operational semantics rules,
implemented by the BIP Engine Atomic multiparty interactions, e.g. by rendezvous or broadcast and
priorities
Correct-by-construction translation of BIP models with multiparty interactions and priorities into observationally equivalent S/R-BIP models Point to point communication by asynchronous message passing No global state - Atomicity of transitions is broken by separating
interaction from internal computation The BIP Engine is replaced by a set of Engines executing subsets of
interactions Distributed coordination is orchestrated by an architecture
Distributed Implementation – Single Execution Engine
BIP Model1
1< 2< 3
One Engine executes all interactions !
C1 C2 C3 C4
C’1 C’2 C’3 C’4
Engine
p q r s t u
p
p
q
q
r
r
s
s t u
t u
Engine
Atomic components
Single Execution Engine
busy
filter
stable state
ready
execute
choose
wait
computefeasible interactions
filterusing prioritieschoose
a maximal interaction
executechosen interaction
notifyinvolved atoms
init
launchatom threads
Distributed Implementation – From BIP to S/R-BIP
Before reaching a state, the set of the offered ports is sent to some Engines1 and s2are “undefined” states
S2S
S2S
S2S
S2S
S2S
S2S
Transformation of atomic components
ga
a b
Global state model
fa
a gb
fb
b s
s1 s2
a
o{a,b}
bo{a,b}
Partial state model
fa fb
o{a,b}
ga
a gb
b
s1 s2
s
s1 s2
Distributed Implementation – Multiple Engines
Dispatch interactions across multiple engines !
Engine Engine
BIP Model
C’1 C’2 C’3 C’4
Semantics Violation
1
C1 C2 C3 C4
p q r s
t
u
p
p
q
q
r
r
s
s t
u
u
Distributed Implementation – Static Conflict Relation
1 2
1 and 2 involve ports of conflicting transitions
1 # 2: interactions 1 and 2 may be in conflict1 # 2: interactions 1 and 2 may be in conflict
p q
p q
1 2
1 and 2 share acommon port p
p
Distributed Implementation – Conflict-Free Multiple Engines
1 2 31 # 2 # 3
4 654 # 5 # 6
Each engine handles interactions of a class of #*
Engine
Engine1
23
Engine
Engine 4
5 6
Distributed Implementation – Limitations
Engine
Engine
Taking #* may reduce drastically parallelism between interactions
Distributed Implementation – 3-Layer Architecture
S2SS2S
S2SS2S
S2SS2S
C1C1 C6C6C3C3 C5C5C2C2 C4C4
C’1
offer port
C’2 C’3 C’4 C’5 C’6
Interaction ProtocolInteraction Protocol
offerport
Interaction ProtocolInteraction Protocol
offerport
reserveok
CR Protocol
fail
Conflict Resolution Protocol
reserveok fail
S2SS2S
S2SS2S
S2SS2S
1
offer port offer port offer port offer port offer port
reserveok fail reserveok fail
Distributed Implementation – Token Ring CRP
Interaction Protocol
Interaction Protocol
Interaction Protocol
Interaction Protocol
reserve2 ok2 fail2 reserve3 ok3 fail3reserve4 ok4 fail4
Token Ring CRP
Token Ring CRPRTST
Token Ring CRPRTST
RT ST
p1
C’1 C’3C’2 C’4
o1 o2 o3 o41p2 p3p5
p6p4 o42
C’5
o51 p7 p8o52
C’6
o6 p5 p6
C1 C6C3 C5C2 C4
Distributed Implementation – Dining Philosophers CRP
reserve2 ok2 fail2 reserve3 ok3 fail3 reserve4 ok4 fail4
Dining Philosophers
CRP Dining Philosophers
CRP
Dining Philosophers
CRP
SF1RF1SR1RR1SF2RF2SR2RR2
p1
C1’ C3’C2’ C4’
o1 o2 o3 o41p2 p3p5
p6p4 o42
C5’
o51 p7 p8o52
C6’
o6 p5 p6
C1 C6C3 C5C2 C4
Interaction Protocol
Interaction Protocol
Interaction Protocol
Interaction Protocol
Distributed Implementation – Design Flow
Conflict Resolution Protocol
Partitioning of Interactions
S2SS2S
S2SS2S
S2SS2S
Partitioning of Components S2SS2S
S2SS2S
S2SS2S
Core1Core1 Core2Core2
Core3Core3 Core4Core4
CHIPCHIP
Core1Core1 Core2Core2
Core3Core3 Core4Core4
CHIPCHIP
Sockets/C++Code
MPI/C++Code
Code Generator
S2S
S2S
S2S
S2S
S2S
S2S
C1 C6C3 C5C2 C4
Mapping of Components
C’1 C’3C’2 C’4 C’5 C’6
Dining Philo. CRP
Interaction Prot. 1 2Interaction Prot. 1 2
Interaction Prot. 3 4Interaction Prot. 3 4
Dining Philo. CRP
Dining Philo. CRP
C’1 C’2 C’4 C’5 C’6C’3
Dining Philo. CRP
Inter.Prot.
Inter. Prot.
Distributed Implementation – Optimization Issues
Conflict resolution is essential for maintaining overall coherency in particular integrity of resources
Conflicts between interactions can be resolved locally if they are handled by the same IP. Otherwise, they are resolved by the CRP
Conflict resolution based on static conflict relation may lead to considerable loss in performance – detect false conflicts based on partial state knowledge Sifakis et al: Distributed Semantics and Implementation for Systems
with Interaction and Priority. FORTE 2008: 116-133 Sifakis et al : Knowledge-Based Distributed Conflict Resolution for
Multiparty Interactions and Priorities. FMOODS/FORTE 2012: 118-134
Sifakis et al: Knowledge Based Scheduling of Distributed Systems. Essays in Memory of Amir Pnueli 2010: 26-41
Sifakis et al : Optimized distributed implementation of multiparty interactions with observation. AGERE!@SPLASH 2012: 71-82
Distributed Implementation – Optimization Issues
Code optimization for components implemented on the same site -replace a composite component by a single flattened component from which sequential monolithic code can be generated
Sifakis at al: Source-to-Source Architecture Transformation for Performance Optimization in BIP. IEEE Trans. Industrial Informatics 6(4): 708-718 (2010)
Discussion Endowing system design with scientific foundations is a major scientific
challenge – key ideas:
Design is formalized as a process of source-to-source correct-by-construction scalable transformations
Semantic coherency is achieved by using a single expressive component framework
Architectures are essential for enforcing specific characteristic properties by application of generic coordination principles
There is a huge body of not yet well-formalized solutions to coordination problems in the form of algorithms, protocols, hardware and software architectures. The challenge is to
Formalize these solutions as architectures and prove their correctness Provide a taxonomy of the architectures and their characteristic
properties Is it possible to decompose any component coordination property as
the conjunction of predefined characteristic properties enforced by corresponding architectures?
Discussion
The BIP component framework has been developed for more than 10 years, with Rigorous Design in mind
Translation of DSL (Simulink, Lustre, DOL, nesC) into BIP
Source-to-source transformations proven correct-by-construction taking into account HW resources generating distributed implementations for several platforms code optimization
Run-times for centralized execution/simulation, distributed execution, real-time execution
Validation and analysis tools incremental checking for Deadlock-freedom: D-Finder tool statistical Model Checking
Successful application in many industrial projects software componentization for robotic systems (DALA Space Robot for Astrium) programming multi-core systems (P2012 for STM, MPPA for Kalray) complex systems modeling (AFDX and IMA for Airbus)
Thank You