Interacting Process Classes

Abhik RoychoudhuryNational University of

Singapore

Joint work with Ankit Goel and P.S. Thiagarajan

Component Behavior

Communicating Active Components Focus is more on the communication

than computation. Modeling and simulation of component

interaction Can be extended to support model checking.

Many similar components can be grouped into “classes” in the specification.

Network of FSM

Describe each component as a finite state LTS Labels on the edges correspond to

(multi-party) interactions. Interactions may be a protocol snippet

Bi-directional communication Captured by a guarded Sequence

Diagram Concrete Execution Semantics

CTP

Communicating Transaction Processes Network of FSMs

Intra-component control flow not suppressed. Actions in FSMs denote Transactions

Communication between components. Executable assuming that in our specs

A component can decide locally which transaction to take part in.

System or Requirements ? High-level System description

Modeling and Simulation at high level Combination of state-based and MSC

based modeling Appl. in Reactive Embedded Systems

Contrast with Live Sequence Charts Executable Requirements Description No state-based description, extends

MSCs

The problem addressed here

Systems with many similar components Telecommunications

Phones, Switches Transportation

Railways – Rail-shuttle, Terminal-controllers Avionics – Aircraft controller

Specify and execute these systems without suffering blow-up.

A Simple Example

Store

Erase

Txsnd

Txrcv

s1

s2Role snd

(a) TSNode

Role rcv

( (ActNode) * Txsnd )

data

(b) Transaction Tx

(ActNode) *

Highlights - Specification Combine

Intra-process control flow. Scenario based interactions between

processes. Process Classes

Classes of Active objects. Objects of the same class have similar control flow. Objects of the same class may interact via scenarios. Associations between objects

E.g. Phone objects engaged in a conversation.

Highlights - Execution The execution semantics is symbolic.

States of concrete objects not directly represented

Partition concrete objects of a process class Current control state History of MSCs executed

different histories may lead to diff. futures from the same control state.

Maintain # of objects in each partition No need to maintain identifiers of behaviorally

indistinguishable objects.

Questions about Specification

Each process class described by a FSM Arcs in the FSM labeled with transactions. Transaction = Guarded MSC

Guard needs to hold for Tx. to be enabled. Guard on MSC history – Regular Expressions Prevents blow-up of the FSM for each class.

Many processes can participate in a Tx Two objects of the same class can participate

in a transaction ?

snd rcv

Data

Transaction Tx – Comm. between network nodes

* (* Tx snd )

A node object can play diff. roles in a Tx. execution,

Maintain seq. of Tx role as local history of process objects.

Guard on strings of Tx role

Last action not a send

Store

Txsnd

Txrcv

s1

s2

Concrete Simulation

Store

Txsnd

Txrcv

Store

Txsnd

Txrcv

Tx

The number of nodes could be very large, consider

10^7 phones in a region of a telecom network

Symbolic Simulation

Store

Txsnd

Txrcv

Store

Txsnd

Txrcv

Tx

s1

s2

s1

s2

( s1 -> 2, s2 -> 0 )

( s1 -> 1, s2 -> 1)

But this is not (yet) accurate since the transactions are guarded.

Behavioral Partitions

Group active objects into “Behavioral Partitions” Control state of Process class’s FSM Automata states for each history-based

guard of the process class. Maintain count of objects in each

behavioral subclass during simulation. Object names not mentioned anywhere.

Illustration of Behavioral Partitions

Txsnd, Erase

Txrcv Store

s1

s2

Erase, Store – No communication

Guards of Tx are * , (* Txsnd)

= {Erase,Store,Txsnd, Txrcv }

t

u1

Txsnd

Txsnd

Tx sndTx snd

u2

Behavioral partitions

(s1, t, u1) (s1,t,u2) (s2,t,u1) (s2,t,u2)

snd rcv

* (* Tx snd )

Tx

Symbolic Simulation

Txsnd, Erase

Txrcv Store

s1

s2

t

u1

Txsnd

Tx sndTx snd

u2

Tx

(s1, t, u1) = 98 (s1,t,u2) =1 (s2,t,u1) =1 (s2,t,u2) = 0

One step of symbolic simulation

(s1, t, u1) = 100 (s1,t,u2) = (s2,t,u1) =(s2,t,u2) = 0

Dynamic Object Associations

Txsnd

TxrcvAcksnd

Dynamic relation Wait-for-Ack

Tx inserts (snd, rcv) to Wait-for-Ack

Ack checks (rcv,snd) Wait-for-Ack

Ack deletes (rcv,snd) from Wait-for-Ack

s

t1 t2

Node1/Node2/Node3

Tx checks (snd,rcv) in Connect

Connect

Node1

Node2

Node3

Ackrcv

Simulation

Txsnd

TxrcvAcksnd

Node1/Node2/Node3

Execute Tx

Ackrcv

No distinction among objects of the same class.

Simulation

Txsnd

TxrcvAcksnd

Node1/Node2/Node3

Execute Tx -- executed

Execute Tx

Ackrcv

Wait-for-ack = { ( ) }

Simulation

Txsnd

TxrcvAcksnd

Node1/Node2/Node3

Execute Tx -- executed

Execute Tx -- executed

Ackrcv

Wait-for-ack = { ( ), ( ) }

Denote

behavioral partitions of

Node1/Node2/Node3

-- No object Identifiers

What do we have ?

But, the proof of the pudding …

… is in the eating ! Cuts simulation time/memory for realistic

controllers CTAS weather update controller Rail Shuttle system from Paderborn

Benchmarks for State & Seq. Diagram based modeling

Rail car (from Live Sequence Charts) Many cars operating in two parallel cyclic paths Many process classes – cars, cruisers, proximity sensors

Telephone switch network (from SPIN model checker) Simulator found realizable bugs in the examples

Deadlock scenarios in CTAS weather controller

A (more realistic) example NASA CTAS

Automation tools for managing large volume arrival air traffic in large airports.

Final Approach Spacing Tool Determine speed and trajectory of

incoming aircrafts on their final approach. Master controller updates weather info. to

“clients” controllers using inputs to compute

aircraft trajectories.

Weather update subsystem

CM

WCPClients

1

1N1

1 1

0..N

connecteditsWCP

WCP -- Weather Control Panel

(contains weather info.)

CM -- Communications Manager

(transfers info from WCP to clients)

Clients – Weather aware, seek connection with CM

Usage of Process Classes Weather aware Clients

Class of similar processes Communicating among each other (in

general) and with other process classes.

Behavior can be captured succinctly … Through an FSM which captures all clients

But what about system simulation ? No need to maintain each client process’s

state separately !!

Experiments

Simulation stopped after 1000 transactions

Time (C )secs

Time (S) secs

Mem ( C)MB

Mem (S )MB

Rail-car(24 cars)

2.1 3.9 83 173Rail-car(48 cars)

2.2 7.0 84 153Shuttle(30)

0.44 0.7 18 33Shuttle(60)

0.44 1.2 18 69CTAS(10)

1.5 2 63 87CTAS(20)

1.5 4.1 64 189

Wrapping up Combining intra-component and inter-

component style to produce an executable spec. is challenging. CTP formalism

Avoiding blow-up in specification and execution of such specs. due to many similar processes. Symbolic execution semantics

Many other challenging issues Hierarchy of process classes

We only consider a collection of process classes !!

Overall Summary Scenarios are useful to capture

requirements, test cases, possible behaviors.

Can blend into later stages of system design as well Test cases tried on actual system

Collection of scenarios – HMSCs Understanding system behavior at high-

level

Overall Summary Developing executable specs. based on scenarios

Directly executing and testing out inter-component specifications.

LSCs – completely suppress intra-process flow CTP – combine intra process flow with scenarios

Efficient execution of these specs. is an issue Symbolic execution of process class specifications.

Code generation Backward association between models and code.

Other Work Code generation of a restricted subset

of the modeling language to SystemC SystemC supports

description of mixed HW-SW designs Performance simulation

Our work pushes the abstraction one level Support rough perf. sim of UML descriptions Tried out various SoC bus protocols (AMBA

from ARM) and other SoC protocols