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