Rigorous System Design

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


10Matlab/Simulink


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

B1

glB2 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 c4

gl1

gl1gl1

Given two glues G1 , G2

G2 is strongly more expressive than G1

if for any component built by using G1 and a set of components C0

there 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


c3c1 c2 c1 c3 c c2

gl1

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 C0

there exists an equivalent component built by using G2 and C0 Cwhere C is a finite set of coordinating components.


BIP BI CCS

SCCS

CSP

<S

<S

<S

<S W >W >

W >

W >

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



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


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


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



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


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


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


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, xq

w, 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 xw

r 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 xr

s 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



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<t1 b2b1

idle1

ready1

exec1

idle2

ready2

exec2f1

b1

a1

b2

a2

f2

t1:=0 t2:=0

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



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




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





Distributed Implementation – Design Flow

Conflict Resolution Protocol

Partitioning of Interactions

S2SS2S

S2SS2S

S2SS2S

Partitioning of Components S2SS2S

S2SS2S

S2SS2S

Core1Core1 Core2Core2


CHIPCHIP



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

Rigorous System Design

Documents

Transcript of Rigorous System Design