Abstraction and Compositional Verification Techniques for Asynchronously Communicating Components...

Abstraction and Compositional Verification Techniques for

AsynchronouslyCommunicating Components

Marjan SirjaniTehran University, IPM

FMCO’06Amsterdam

7-10 November 2006

M. Sirjani, FMCO'06 2

A joint work with Ali Movaghar Frank de Boer

Acknowledgements to Michael Huth Mohammad Reza Mousavi Rebeca Group at Tehran and Sharif

Universities


Outline Motivation Actor-based Language Rebeca Compositional Verification of Rebeca Introducing Components Supporting Tools Conclusion Future Work


MotivationEstablishing a formal verification method, easy to use for practitioners,for developing reliable systems in concurrent and distributed applications.

Formal verification method:Modeling language + Verification mechanism


The Idea Actor-based modeling language, plus component notion, and formal verification support.

Asynchronous message passing in actor-based modeling makes the verification problem difficult

Inherent modularity and encapsulation provide some solutions: abstraction and modular

verification


Actor A reference model for concurrent

computation Consisting of concurrent, distributed

active objects

Proposed by Hewitt as an agent-based language (MIT, 1971)

Developed by Agha as a concurrent object-based language (Illinois, since 1984)


Rebeca Reactive object language An operational interpretation of actor

language Formal semantics Abstraction and Compositional verification

approach Model checking tool

Introduced by Sirjani and Movaghar, 2001


Key Features of Rebeca Actor-based computational model

Units of concurrency and distribution: Reactive objects

Simple and natural Objects are threads.

Formal semantics Labeled transition system A solid basis for verification


Key Features … Asynchronous communication

Increases the decoupling Buffers lead to state space explosion in model

checking Abstraction and compositional verification

approaches Reduce the state space Exploite the actor-based semantics to

abstract the model Preserving a set of behavioral specifications in

temporal logic


Other Features Object-based language, Java like syntax

Encapsulation of data and process, no shared variable

Easy to use by software engineers Tool supported

Model checking Rebeca code using back-end model checkers

Automated abstraction and compositional verification

Symmetry and static Partial order reduction


Added Feature Grouping a set of reactive objects

as an open component Allow a set of more tightly coupled

objects to be grouped as a component A higher level of abstraction in

software design Considering a strategy to keep the

verification theory sound

SMV Promela(NuSMV) (Spin)

Back-End Model Checkers

Compositional VerificationDecomposing the model into components

Composing the model from re-usable components

Rebeca LanguageActor-based

Properties Closed modelComponents

Rebeca Verifier Tools

Abstraction

ModereRebeca Direct Model CheckerPartial order reduction - Symmetry


Rebeca Model Communication:

Asynchronous message passing Unbounded message queue for each

rebec No explicit receive

Computation: Take a message from top of the queue

and execute it Event-driven


In the execution of a message server, a rebec may Execute an assignment Evaluate a condition Send a message

The messages are asynchronous No-way blocking (sender, receiver) No explicit receive, arrives in the message

queue of the receiver


Dynamic Behavior Dynamic topology Dynamic rebec creation (runtime)

(not considered in compositional verification)


Operational Semantics The state of a rebec, is the valuation of

state variables, and the unbounded buffer (queue) for incoming

messages. The state of the system, is the product of

local object states A state transition:

an atomic execution of a method off the top of the rebec’s queue.


An Example: Bridge Controller There is a two-way bridge. Trains may arrive at each side. At the same time two trains should

not be on the bridge.

There are green/red lights on each side.

A train goes on the bridge if the light is green.

Train1

Bridge Controller

Train2Arrive

YouMayPass

Arrive

YouMayPass

Leave

Leave

passed passed

Example: Rebeca codereactiveclass Train {

knownobjects {BridgeController controller;}statevars{ … }msgsrv ……

}reactiveclass BridgeController {

knownobjects{Train t1; Train t2;} statevars{ … }

msgsrv ……

}main {

BridgeController theController (t1, t2);Train t1 (theController);Train t2 (theController);

}

Trainsreactiveclass Train(3){ knownobjects … statevars

{boolean

onTheBridge;}

msgsrv initial(){

onTheBridge = false;

self. ReachBridge();}

msgsrv YouMayPass(){onTheBridge = true;self.Passed();

}msgsrv Passed(){

onTheBridge = false;controller.Leave();self.ReachBridge();

}msgsrv ReachBridge(){

controller.Arrive();}

}

Bridge Controllerreactiveclass BridgeController(3){

knownobjects … statevars

{boolean isWaiting1;boolean isWaiting2;boolean signal1;boolean signal2;

}

msgsrv initial(){

signal1 = false; /* red */

signal2 = false; /* red */

isWaiting1 = false;isWaiting2 = false;

} msgsrv Arrive(){

…}msgsrv Leave(){

…}

}


Formal Verification Two general approaches

Model checking: Algorithmic verification

Theorem proving: Deductive verification


Model Checking of Real Systems

State explosion problem Solution:

Modularity Abstraction


Compositional Verification1. proving properties of components (as

open systems in an arbitrary environment) by model checking, and

2. deducing the whole system’s property from the properties of its components.

C |= P C’ |= Q

P Q R-----------

C || C’ |= R


Useful if the model is inherently modular.

Environment Problem.

Note:We need assume-guarantee reasoning.We only consider LTL and ACTL properties.


Inherent Modularity in Rebeca Rebecs are inherently

Independent, decoupled, encapsulated

Because of Asynchronous message passing no explicit receive statement no shared variables

=> Leads to natural modularity and abstraction techniques


Rebeca verification approach Exploit the inherent modularity and

encapsulation of the model to apply Compositional verification Property preserving abstraction

Can be used for any system based on asynchronous message passing and actor-based computation.


Compositional verification details …

Decompose a model into components, verify some specific properties for

these components, and then deduce the system’s property from

the properties of its components.

This deduction is sound, due to the weak simulation relation.

(between a component in a model and its parallel composition with another arbitrary component in the same model.)


Decompose a model into components: Model the environment as incoming

messages (external messages): M={C,Ec}

Abstracting the environment from its concrete behavior (state variables).

Abstract the queue from external messages: Ca

Decomposing a system into components:

Internal messages: coming from internal rebecsExternal messages: coming from external rebecs.


Semantics of a Component Values for all variables of all internal

rebecs. A multi-queue: one message-queue

for each internal rebec. A set of external messages always

present.

Properties: based on rebecs’ state variables.


The Environment: Automatic Generation The Environment of a component C: EC

sending all the possible messages to C Nondeterministically Unboundedly

EC can be automatically derived from the system. No state variable Servicing no messages Just sending messages to C

The composition of C and EC makes a closed model M=(C, EC).

Bridge Controller Example

Train1

Bridge Controller

Arrive

YouMayPass

Arrive

YouMayPass

Leave

Leave

passed

Receiving ‘Arrive’ or ‘Leave’ from the environment, arbitrarily (not blocking the component).

EC CntlEnvLeave

CntlEnvArrive


CTrain1

Controller


Abstracting the Message Queue

No external messages (messages coming from EC) in the Queue

External messages are assumed to be always present and are modeled by transitions of Ca.



C

Ca

.

.GoOnTheBridge

YouMayPassYouMayPassYouMayPass

ReachTheBridgeYouMayPass

Queue

c

Ca

.

.GoOnTheBridgeReachTheBridgeGoOnTheBridgeReachTheBridgeGoOnTheBridgeReachTheBridge

Queue

YouMayPass

External Messages

Ca

Train as a component

s0

s3

s2

s1

sk

...

External messages

Inte

rnal m

essa

ges

e1

e2

e3

i1

e1

e2 e3 …

i1

sl

i2 i2

Multi-queue

Constant set

States and Transition

Formally speaking: Let

∑(M) be the transition system of M={C,Ec} ∑(Ca) be the transition system generated by

the transition relation considering queue abstraction

∑(M’) be the transition system of any model M’ containing C

We have the following weak simulation relations: ∑(Ca) weakly simulates ∑(M) (Queue Abstraction)

∑(M) weakly simulates ∑(M’) (Component Composition)

We have the following weak simulation relations: ∑(Ca) ≤ ∑(M) (Queue Abstraction) ∑(M) ≤ ∑(M’) (Component Composition)

And the property preservation theorem Safety properties (LTL-X, ACTL-X) are

preserved due to weak simulation. Hence

∑(Ca) |= φ → ∑(M) |= φ, for M={C,Ec} ∑(M) |= φ → ∑(M’) |= φ, for an arbitrary model

M’ containing C.


SummaryHaving a model M,and a component C (a sub-model of M), we can derive the environment EC for C.

For every safety property,specified by LTL-X or ACTL-X formula,

with atomic propositions on variables in C, Ca |= P implies C||C’||EC||C’ |= P


Abstraction Techniques:Summary Abstracting environment as external

messages Bounded queues

Abstracting external messages Queue length in model checking

Check overflow, supported by tool Course grained interleaving

Method execution as a transition (Atomic method execution)

Conventional data abstractions


One more point:Symmetry Reduction Techniques

We may use symmetry for state space reduction Like in dining philosophers (Ring-like

topologies) The permutation relation shall

preserve both rebec types and known-rebec relation.

Dining Philosophers

Component C1Component C5

Component C2

Component C3

Component C4

(� i=0,n ¬(phili.fr phili+1.fl))

External message fromthe right fork of philosopher 0 External message from the

left fork of philosopher 1

Component C1

Component C1: phil0 || fork0 || phil1

Property: (� ¬(phil0.fr phil1.fl))


What we had: decomposing a model for verification

purposes in a top-down manner.

What we added: notion of components re-usable parts fixed proven specifications build a system in bottom-up fashion.


Introducing Components Introducing components for

modeling purposes, As an additional higher level of

abstraction in modeling Enriching the model of

computation


Components Components are sets of reactive objects Components interact

via broadcasting asynchronous anonymous messages

=> No need to put a name for a component. No need to know the names of the rebecs

inside a component (for communication).

Just know the service you want.


In Extended Rebeca Rebecs within a component can be

synchronized by handshaking communication mechanism.

Components encapsulate tightly coupled reactive objects.

Like in Globally Asynchronous Locally Synchronous Systems (GALS)

Extended Rebeca Components in Extended Rebeca

Syncronus Messages

Local Asyncronus Messages

External Asyncronus Messages (Broadcast)


Asynchronous anonymous broadcasting (between components)

Dispatching the message arrived in a component Internal broadcast to all Nondeterministic choice of one rebec (is selected to keep queue abstraction possible)

left-Controller right-Controller

Train1 Train2

Extended Rebeca code: the controller

reactiveclass leftController() { knownobjects { rightController right;}

provided { Arrive; } required { YouMayPass; } statevars { int trainsin; } msgsrv initial() { trainsin = 0; } msgsrv Arrive (int TrainNr) { YouMayPass(TrainNr); trainsin = trainsin + 1; receive(passed); }}

reactiveclass rightController() { knownobjects { leftController left;}

provided {Leave; } required { } statevars { int trainsout; } msgsrv initial() { trainsout = 0; } msgsrv Leave () { trainsout = trainsout + 1; left.passed( ); }}

Extended Rebeca code: trainsreactiveclass Train() { knownobjects {} provided { YouMayPass; } required { Arrive; Leave; } statevars { boolean OnTheBridge; } msgsrv initial(int MyTrainNr) { self.ReachBridge(); OnTheBridge = false; } msgsrv YouMayPass(int TrainNr) { if (TrainNr == MyTrainNr) { self.GoOnTheBridge(); OnTheBridge = true; } }

msgsrv GoOnTheBridge() { Leave(); OnTheBridge = false; self.ReachBridge();} msgsrv ReachBridge() { Arrive(MyTrainNr); } }

Extended Rebeca code: instantiating rebecs and declaring components

main {

Train train1(1); Train train2(2); leftController theLeftCtrl(theRightCtrl); rightController theRightCtrl(theLeftCtrl); Components: {train1}; {train2}; {theLeftCtrl, theRightCtrl}; }


Modular verification: the same approach

Environment of a component Queue Abstraction Weak Simulation Property Preservation


Subtleties for queue abstraction: Initial state Internal dispatching of message


Rebeca Verifier Tool Enter a model in Rebeca, Translate it into SMV (or Promela), Specify properties at Rebeca source

code level (based on state variables),

Translate the properties to NuSMV (or Spin) format,

Model check using NuSMV (or Spin).


Or Choose a component and then the

same scenario … (compositional verification)

By Amin Shali, Mahdi Jaghoori and Hamed Iravanchi, 2003-2005


Modere: Rebeca Model Checker Engine

Direct model Checking of Rebeca Symmetry and Partial Order

Reduction

By Mahdi Jaghoori, 2005-2006

Automated Modular Verification


Case studies Network and Security Protocols

CSMA/CD protocol Mitnick and Needham Schroeder

attacks Perlman algorithm Security Sub-layer in IEEE 802.16

Hardware/Software Co-designs A pipeline CPU design Examples in TLM library of SystemC


A Real Case Study:ACM Module in SystemC SystemC code specification:

1 module 14 sc_methods 31 Signals (all shared)

18 sc_logic 13 variable size unsigned-int

5 shared variables

Total states: 2^165 The code


ACM in Rebeca Stages of modeling the system:

Modeling: 14 rebecs for 14 methods with their own variables

Optimization: reducing number of rebecs

Abstraction: removing insignificant data Compositional verification: model

checking the units involved in the given properties


ACM: Model Checking Compositional verification for

memory unit: 1 rebec Queue length: one A total of approximately 2^18 states

Model checking results: Stored states: 3276 Memory used: 34507 KB Time: less than 1 minute


ACM: Properties Memory read and write signals can never be active at the

same time [] ( (flag_start_mem_read == 1) (flag_start_mem_write == 0) ) violated in certain situations The code

Read and write signals to HDLC unit can never be active at the same time

[] ( (flag_start_hdlc_read == 1) (flag_start_hdlc_write == 0) ) violated in certain situations The code

When the system starts to save an announce it starts the saving process from the first bit

[] ( (flag_save == 0) && (EX(flag_save == 1)) (EX counter == 0) ) Satisfied The code


Conclusion Proposing an actor-based language Defining its Formal Semantics Using a Java–based syntax Abstraction and compositional

verification approaches using the formal semantics and exploiting the

encapsulation and inherent modularity of the model

Developing a tool Modeling case studies


Generalizing the verification theorem for a component-based actor language

Related, Ongoing and Future Work Theory

Symmetry in Rebeca Queue abstractions Dynamic features in verification Coordinating rebecs

Tool Direct model checking Partial order reduction Rebeca to mCRL to use its model checker SystemC to Rebeca

Application Network and security protocols Hardware/software co-design Web services


Questions?

RebecIs a bowed string musical instrument, developed from the Persian instrument, the rabab.

Like all good medieval things, the rebec's origins can be traced to the middle east. Around the middle to the end of the ninth century AD, there are several discussions of an instrument called a rabab in Persia …

http://en.wikipedia.org/wiki/Rabab

CCS

SMV

Java C

Modeling languages

RMLI/O Automata

Actor model

CSP

Promela

Mocha

FDR

NuSMVSpin

Java PathFinderBandera

SLAM

Abstract

Mathematical

Too heavyInformal

Verification Techniques: • Deduction

• Model checking

Programming languages

Petri net

needs high expertise

causes state explosion

Where are we standing?

Abstraction and Compositional Verification Techniques for Asynchronously Communicating Components...

Documents

Transcript of Abstraction and Compositional Verification Techniques for Asynchronously Communicating Components...