rigorous component-based system design in bipkgoossens/2011-emsoft-tutorial/sifakis.pdf · tutorial...

Rigorous Rigorous ComponentComponent--based based

System Design in BIPSystem Design in BIP

TutorialTutorialEmbedded Systems Week 2011Embedded Systems Week 2011

Taipei, October 9, 2011Taipei, October 9, 2011Joseph SifakisJoseph SifakisVERIMAG VERIMAG LaboratoryLaboratory and EPFLand EPFLin collaboration with in collaboration with A. A. BasuBasu, S. Bensalem, B. , S. Bensalem, B. BonakdarpourBonakdarpour, M. , M. BozgaBozga, J. , J. CombazCombaz, H. Nguyen, M. , H. Nguyen, M. JaberJaber, , J. Quilbeuf

OVERVIEW

2

System Design

The Limits of Correctness-by-Checking

Rigorous System Design

Multi-language Frameworks

Architectures

Automatic Implementation

Putting RSD into Practice in BIP

Discussion

System Design – An Increasing Gap

Tech

nolo

gica

l Te

chno

logi

cal

Cap

abilit

ies

Cap

abilit

ies

Com

putin

g S

yste

ms

Com

putin

g S

yste

ms

Des

ign

Des

ign

System Design – Simplified ViewSystem design is the process leading to a mixed software-hardware system meeting given requirements

RequirementsThe expected behavior of the system to be designed with respect to its potential users and its environment

ProgramExecutable platform-independent model meeting the requirements

System composed of HW and SW – the HW platform may be given

SWHW

Different from pure SWor pure HW design!

System Design System Design –– Quest for Productivity Quest for Productivity

6

Efficiency of the design processEfficiency of the design process

SkillsSkills

ToolsTools

ComponentsComponents

System Design – Quest for Trustworthiness

7

Assurance that the designed system can be trusted that it will perform as expected despite

HW failuresHW failures Design ErrorsDesign Errors

Physical Environment Physical Environment DisturbanceDisturbance

Erroneous or Erroneous or Malevolent ActionMalevolent Action

System Design System Design –– Quest for Optimality Quest for Optimality

8

Languages for describing feasible (trustworthy) design solutions Don’t program multimedia applications in plain C!

Optimal use of resources through design space exploration to resolve choices such as reducing parallelism (through mapping on the same processor) reducing non determinism (through scheduling) fixing parameters (quality, frequency, voltage)

OVERVIEW

9

System Design




Architectures



Discussion

1010

CorrectnessCorrectness--byby--Checking Checking –– The VThe V--modelmodel

The VThe V--model of the Systems Engineering Process, Source: Wikipedia model of the Systems Engineering Process, Source: Wikipedia

1111

CorrectnessCorrectness--byby--CheckingChecking

consists in comparing a system model against requirements is a relative judgment “Are we building the system right?” would be an answer to the question “Are we building the right system” if

Requirements could be correctly formalized, sound and complete Models could represent faithfully the detailed behavior of a mixed

HS/SW system interacting with its environment We had effective and efficient checking techniques

its value has been largely overestimated: it only partially contributes to trustworthiness as it is limited to

systems and properties that can be formalized and checked efficiently

it is of limited help for achieving optimality often characterized by quantitative properties

Any hype about mathematical rigor is pointless if we cannot provide supporting methods and tools !

1212

The Limits of CorrectnessThe Limits of Correctness--byby--Checking Checking –– RequirementsRequirements

Requirements should be written in a formal language easy to understand and use by engineers. But for some types of requirements we do not have adequate languages

e.g. to describe security properties even if some languages are expressive enough, their effective use by

engineers seems to be problematic e.g. SUGAR

Requirements should be sound. But checking soundness, even for decidable requirements specification languages, is problematic due to intrinsic complexity of decision algorithms

Requirements should be complete that is they tightly characterize the system’s behavior. But

there is no criterion characterizing completeness for declarative languages – writing requirements may be an endless game!

1313

The Limits of CorrectnessThe Limits of Correctness--byby--Checking Checking –– ModelsModels

Models should be

faithful e.g. whatever property is satisfied for the model holds for the real system

generated automatically from system descriptions

For mixed HW/SW systems modeling

Interaction between application software and the underlying execution platform (hardware-dependent software and hardware) is intricate and hard to understand

Hardware execution platforms have “unpredictable” behavior Variability due to manufacturing errors or aging Varying execution times due to layering, caches, speculative execution

Detailed models are intrinsically complex

1414

The Limits of CorrectnessThe Limits of Correctness--byby--Checking Checking –– Checking Checking

Checking correctness with respect to given requirements

Ad hoc techniques e.g. by simulation allow error detection only

Formal verification allows exhaustive validation, but

Monolithic verification is limited to small or medium size systems and to specific of properties

Attempts to apply compositional top-down verification to composite systems and thus cope with complexity of monolithic verification, have failed e.g. assume/guarantee techniques: the main obstacle is decomposition of a global property into a set of properties met by the constituent components

1515

The Limits of CorrectnessThe Limits of Correctness--byby--Checking Checking –– TopTop--Down Down VerificationVerification

S ReqReq

S_11 S_12 Req_11 Req_12

S_21 Req_21 Req_22 Req_23 Req_24S_22 S_23 S_24

1616

The Limits of CorrectnessThe Limits of Correctness--byby--Checking Checking –– TopTop--Down Down VerificationVerification

S ReqReq

S_11 S_12 Req_11 Req_12


OVERVIEW

17

System Design




Architectures



Discussion

1818

Rigorous DesignRigorous DesignTrustworthy and optimal design raises complex issues crosscutting all aspects of system design and lifecycle that cannot be addressed through correctness-by-checking

Two principles:

Systems are built bottom-up by composing componentsincrementally

Essential properties are enforced by construction

Rigorous design flow is

Accountable: at each step we know which essential properties hold and why

Has no gaps: all system descriptions are based on a common host language – this allows in particular, guaranteeing property preservation between steps

Scalable: overcomes difficulties of monolithic correct-by-checking techniques

1919

Rigorous Design Rigorous Design –– BottomBottom--up constructionup construction


Base elements e.g. atomic features

S_21 S_22 Pty12Pty12 S_23 S_24Pty34Pty34

S_21 S_22 S_23 S_24 PtyPty

Pty21Pty21 Pty22Pty22 Pty23Pty23 Pty24Pty24

OVERVIEW

20

System Design




Architectures



Discussion

Multi-language FrameworksSystem designers deal with a large variety of components, with different characteristics, from a large variety of viewpoints, each highlighting different dimensions of a system

Verilog VHDL SystemC

Statecharts

SysML

Matlab/Simulink,

AADL

BPEL,

JavaTSpaces Concurrent FortranNesC

CorbaMPI

Javabeans.NET

SWbusSoftbench

TLM

C

SES/Workbench

Fractal

Consequences: Using semantically unrelated formalisms e.g. for programming, HW

description and simulation, breaks continuity of the design flow and jeopardizes its coherency

System development is often decoupled from validation and evaluation.

Embedding

Embedding

Embe

dding

Embe

dding

Embedding

Embedding

Embedding

Embedding

2222

Multi-language Frameworks – Interoperability

Semantic interoperability: To ensure global consistency of the design flow we need to express the semantics of the various languages in terms of an all encompassing host language

DSLDSLDataData--flowflow

SynchronousSynchronousEventEvent--drivendriven

Asynchronous MPAsynchronous MP

Phys. SystemsPhys. SystemsMod. Mod. LanguLangu..

MatlabMatlabModelicaModelica

HDL HDL VerilogVerilog

SystemCSystemCTLMTLM

IPIP--XACTXACT

ModelingModelingLanguagesLanguages

UMLUMLSysMLSysMLAADLAADL

Host Language HHost Language HCommon Component ModelCommon Component Model

Expressive Expressive Simple and ElegantSimple and Elegant

MultiMulti--language Frameworks language Frameworks –– InteroperabilityInteroperability

Engine for L(SOS for L)

Description in a language L

Structured Operational Semantics for L is implemented by an Engine which cyclically executes a two-phase protocol:

1. Monitors components and determines enabled connections

2.Chooses one enabled connection and executes the corresponding interaction – the latter may modify the states of the involved components

MultiMulti--language Frameworks language Frameworks –– InteroperabilityInteroperability

Engine for L(SOS for L)

SW written in a language L SW written in Host Language H

Engine for H(SOS for H)

Engine for L written in H

EMBEDDING

Multi-language Frameworks – The Host Language

What we need?

Overcome the limitations of existing theoretical frameworks based on a single composition operator e.g. function call, asynchronous message passing, rendez-vous

A Common Component Model based on a unified composition paradigm for describing and analyzing the coordination between components. in terms of tangible, well-founded and organized concepts expressive – coordination glue between components e.g. protocols, schedulers, buses, architectures can be expressed as the combination of composition operators

simple and elegant - achievement of a given functionality with a minimum of mechanism and a maximum of clarity

OVERVIEW

26

System Design




Architectures



Discussion

2727

ArchitecturesArchitectures

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 enforcing global properties characterizing the coordination between components – correctness for free

Using architectures is key to ensuring trustworthiness and optimality in 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

2828

Architectures Architectures –– Definition Definition An architecture is as operator that constraints the behavior of the composed components to enforce a given property – correctness for free!

ComponentsComponents

ArchitectureArchitecturefor Mutual Exclusionfor Mutual Exclusion

Composite ComponentComposite Component

ArchitectureArchitecturefor Mutual Exclusionfor Mutual Exclusion

2929

Architectures Architectures –– Property Enforcement Property Enforcement

Postulate: An architecture ensuring a given property can be obtained as the combination of a set of architectures ensuring basic properties:

1. Identification of an expressive and minimal set of basic architectures/properties

2. Correct-by-construction theory for combining architectures and their characteristic properties

Security architectures are obtained by composition of architectures ensuring Antivirus protection Intrusion Detection System, Intrusion Protection System Sampling Monitoring Watermarking Embedded cryptography Integrity checking

3030

Architectures Architectures –– CorrectnessCorrectness--byby--ConstructionConstruction

DeadlockDeadlock--freefreeComponentsComponents

Property PreservationProperty Preservation

DeadlockDeadlock--freefreeRouting ProtocolRouting Protocol

DeadlockDeadlock--free free Composite ComponentComposite Component

DeadlockDeadlock--freefreeRouting AlgorithmRouting Algorithm

Architectures Architectures –– CorrectnessCorrectness--byby--ConstructionConstructionProperty Property ComposabilityComposability

Mutual Exclusion Mutual Exclusion ProtocolProtocol

SchedulingSchedulingAlgorithmAlgorithm

Mutual Exclusion Mutual Exclusion

ProtocolProtocol

SchedulingSchedulingAlgorithmAlgorithm

OVERVIEW

32

System Design




Architectures



Discussion

3333

Automatic ImplementationAutomatic ImplementationProblem: Given an application software and an execution platform generate

trustworthy and optimal implementations

Application Software is written in high level languages supporting abstractions such as Atomicity of primitives and interactions between components –

in particular multiparty interaction A logical notion of time assuming zero-time actions and synchrony

of execution with respect to the physical environment

The generated implementation should be functionally equivalent to the application software (correctness) generated automatically for a given mapping associating

Processes of the ASW processors of the platform Data of the ASW memories of the platform Interactions execution paths or protocols

3434

Automatic Implementation Automatic Implementation –– Methods and ToolsMethods and ToolsApplication SW Execution Platform Model

Code Generationand Deployment

Mapping

Analysis and Validation Tools

Optimal DesignOptimal Design

Process Process ProcessorProcessor

Data Data MemoryMemory

OVERVIEW

35

System Design




Architectures



Discussion

Putting RSD into Practice – System Design Flow in BIP

Platform

CodeGeneration

Implementation

Transformation

System model in S/R-BIP

ProtocolsProtocols

System model in BIP

HWHWInfrastructure Infrastructure MappingMapping

TransformationEmbedding

ApplicationApplicationSWSW

Application SW model in BIP

S2S

S2S S2S

S2S

S2S

S2S S2S

S2S

S2S

S2S S2S

S2SS2S

S2S S2S

S2S

Analysis&Analysis&ValidationValidation

Putting RSD into Practice – Using BIP as a Host Language

BIP is a component framework including 1. a language for hierarchical construction of composite components

2. associated tools Translators from domain specific languages Run-time Engines Validation and analysis tools Code generation tools

workP < workC

p:=f(p)

talkPwork

pcom

p

workP talkP c:=f(c)

talkCwork

ccom

c

workC talkC

ConsumerProducer

c:=p

Putting RSD into Practice – Basic Concepts of BIP

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 PR12

Putting RSD into Practice – Integrating HW constraintsIntegrating HW constraintsAp

pli c

atio

n SW

ProcessorProcessor ProcessorProcessor

BusBus

MemoryMemory HW

Arc

h ite

ctur

e

Sche

dule

rSc

hedu

ler

Inte

rface

Inte

rface

Sche

dule

rSc

hedu

ler

Inte

rface

Inte

rface

BusBus

Inte

rface

Inte

rface

Inte

rface

Inte

rface

InterfaceInterface

ArbiterArbiter

MemoryMemoryInterfaceInterface

Syst

e m M

o del

Putting RSD into Practice – Integrating HW constraintsIntegrating HW constraints

Software Model (BIP)

System Model (BIP)

Transformation

Architecture(XML)

Mapping(XML)

Simulation/Validation, Functional Correctness, Deployable Code Generation, Statistical Model Checking

System Component

Library

Performance ObserverLibrary

Application Software

Behavior(C code)

Process Network

(XML)

Translation

XMLParser

CParser

XMLParser

BIP Toolset

Input in DOL

The frontendtransforms networks of processes written in DOL into BIP models

The backend applies a series of source-to-source correct-by-construction transformations over the BIP software model.

The generated system model includes can be validated and analyzed

MJPEG decoder

The MJPEG decoder

reads a sequence of frames and displays the decompressed frames

is described as a process network with five processes and nine communication channels

MJPEG decoder – MPARM Architecture

A simplified Multi-Processor ARM (MPARM) Five identical tiles and a Shared Memory connected via a Shared Bus. Tiles contain a CPU connected to its Local Memory via a Local Bus. CPU frequency: 200 Mhz. Access times: 2 CPU cycles for local memory

6 CPU cycles for shared memory

SharedMem(SM)

SharedMem(SM)

Shared bus (SB)

Tile1Tile1ARM1ARM1

LocalMem

(LM1)

LocalMem

(LM1)

Local Bus (LB1)Local Bus (LB1)

Tile2Tile2ARM2ARM2

Local Mem(LM2)

Local Mem(LM2)


Tile5Tile5ARM5ARM5

Local Mem(LM5)

Local Mem(LM5)


MJPEG decoder – Mapping

ARM1 ARM2 ARM3 ARM4

ARM5

Mapping1 allMapping2 SS, SF, IQ MF, MSMapping3 SS, SF IQ,MF,MS

Mapping4 SS, SF IQ MF, MSMapping5 SS, MS SF IQ MFMapping6 SS SF IQ MF MSMapping7 SS, SF IQ MF, MSMapping8 SS SF IQ MF MS

Shared LM1 LM2 LM3 LM4Mapping1 allMapping2 C6, C7 C1, C2, C3, C4, C5 C8, C9Mapping3 C3, C4, C5, C6 C1, C2 C7, C8, C9Mapping4 C3, C4, C5, C6, C7 C1, C2 C8, C9Mapping5 allMapping6 allMapping7 C6, C7 C1, C2, C3, C4, C5 C8, C9Mapping8 C1, C2 C3, C4, C5, C6 C7 C8, C9

Process mapping table

SW-Channel mapping table

MJPEG decoder – Results

Mapping (1) gives the worst computation time as all processes are mapped to a single processor.

The communication overhead is reduced if we distribute sw-channels to the local memories of the processors.

Communication delayComputation delay

MJPEG decoder – Results

As more channels are mapped to the local memory, the shared bus contention is reduced. However, this might increase the local memory contention, as is evident for mapping (8).

Delay (waiting time) due to bus and memory conflict

Putting RSD into Practice – Distributed ImplementationDistributed Implementation

SW model

I1

I2

I3

InterfaceInterface InterfaceInterface InterfaceInterface InterfaceInterface InterfaceInterface

Distributed Mutual Exclusion ProtocolDistributed Mutual Exclusion Protocol

DistributedImplementation

Engine for I1

InteractionInteractionProtocol forProtocol for

l1l1Engine for I1


l2l2Engine for I1


l3l3


SW model

I1

I2

I3

InterfaceInterface InterfaceInterface InterfaceInterface InterfaceInterface InterfaceInterface

Distributed Mutual Exclusion ProtocolDistributed Mutual Exclusion Protocol

DistributedImplementation

Engine for I1


l1l1Engine for I1


l2l2Engine for I1


l3l3

Distributed Distributed Execution Execution EngineEngine


C1C1

C6C6

C3C3

C5C5

C2C2

C4C4

1 2 3

4

Conflict Resolution Protocol

Partitioning of Interactions

p1

dp1

dp2

dp5

dp6

o1

o2

o41

p2

p5

p6

Interaction

Protocol

Interaction

Protocol

1 2Interaction ProtocolInteraction Protocol3 4

o42

dp7

dp8

o51

p7

p8

o52

dp9

dp10

o6

p5

p6

reserve2

ok2

fail2

Dining Philo. Conflict Resolution ProtocolDining Philo. Conflict Resolution Protocol

Partitioning of Components

Sockets/C++Code

Sockets/C++Code

MPI/C++Code

MPI/C++Code

Code Generator

Code Generator

p1

dp1

dp2

dp3

dp4

dp5

dp6

o1

o2

o3

o41

p2

p3

p5

p6

p4

o42

dp7

dp8

o51

p7

p8

o52

dp9

dp10

o6

p5

p6

ok3

fail3

reserve4

fail4

Dining Philo. CRP

Dining Philo. CRP

Dining Philo. CRP

Dining Philo. CRP

Interaction Prot. 1 2Interaction Interaction Prot. Prot. 1 1 22

Interaction Prot. 3 4Interaction Interaction Prot. Prot. 3 3 44

Dining Philo. CRP

Dining Philo. CRP


The UTOPAR system is an automated transportation systemproposed by Israel Aircraft Industries in the COMBEST EU project


request

enter

exit

destination

exiti=1,N

departurei=1,Nopeni=1,N

awakei=1,N

destinationi=1,NposChangedi=1,Narrivali=1,Nclosei=1,N

enteri=1,N

enterk,,i=1,M*1,M

requestk,,i=1,M*1,M

closearrival

posChangeddestination

awake

opendeparture

request

User(*)

CallingUnit(M*M)

Ucar(N)

CentralStation

(1)

openi=1,N

UTOPAR model in BIPUTOPAR model in BIP


Benchmarks for fully automated generation of distributed C++ code for Linux sockets

25 = 5 * 5 calling units and 4 cars –29 Interaction Protocols

49 = 7 * 7 calling units and 4 cars –53 Interaction Protocols

Putting RSD into Practice – Monolithic Code GenerationMonolithic Code Generation

OVERVIEW

53

System Design




Architectures



Discussion

Conclusion Conclusion – Breaking with Outdated Ideas

New trends break with traditional Computing Systems Engineering New trends break with traditional Computing Systems Engineering --Goodbye to desktop applications and their ilk Goodbye to desktop applications and their ilk

Focus is moving from pure software to systems Focus is moving from pure software to systems -- Interplay between Interplay between application software, execution platform and physical environmenapplication software, execution platform and physical environment is t is crucial for trustworthiness and optimalitycrucial for trustworthiness and optimality

Too much of research in software engineering, systems, formal Too much of research in software engineering, systems, formal methods, etc. never made it in practice because it assumed a "demethods, etc. never made it in practice because it assumed a "design sign from scratch" approach and correctnessfrom scratch" approach and correctness--byby--checkingchecking

These approaches These approaches can only partially contribute to enhancing trustworthiness and can only partially contribute to enhancing trustworthiness and

optimality optimality are limited to systems and properties that can be formalized andare limited to systems and properties that can be formalized and

checked efficiently e.g. functional properties of SW componentschecked efficiently e.g. functional properties of SW components

Conclusion Conclusion – For a Discipline of DesignNew approach for the design of trustworthy and optimal systemsNew approach for the design of trustworthy and optimal systems

Assumes thatAssumes that systems are built/modified systems are built/modified incrementallyincrementally by integrating components by integrating components

bottombottom--upup correctness can be effectively enforced correctness can be effectively enforced by constructionby construction the Software IS the Model the Software IS the Model

Raises challenging and relevant fundamental problems with high Raises challenging and relevant fundamental problems with high potential for innovation and impact on languages, architectures,potential for innovation and impact on languages, architectures,implementation techniquesimplementation techniques

Endeavors unification through formalization of design as a procEndeavors unification through formalization of design as a process ess for deriving trustworthy and optimal implementations from an for deriving trustworthy and optimal implementations from an

application software and models of its execution platform and application software and models of its execution platform and physical environmentphysical environment

which is which is semantically soundsemantically sound, , scalablescalable and and accountableaccountable

Opens the way for moving from Opens the way for moving from empiricalempirical design techniques to a welldesign techniques to a well--founded design disciplinefounded design discipline

Discussion – Putting RSD into Practice in BIPin BIPThe BIP component framework has been developed for more than 10 years, with Rigorous Design in mind Main achievements: Translation of several DSL (Simulink, Lustre, DOL, nesC) into BIP Rigorous design flow based on source-to-source transformations

proven correct-by-construction, in particular for 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 ST Microelectronics,

MPPA for Kalray) complex systems modeling (AFDX and IMA for Airbus)

rigorous component-based system design in bipkgoossens/2011-emsoft-tutorial/sifakis.pdf · tutorial...

Documents