Interacting Process Classes

1
Interacting Process Classes

• Abhik Roychoudhury
• National University of Singapore

Joint work with Ankit Goel and P.S. Thiagarajan
2
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.

3
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

4
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.

5
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

6
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.

7
A Simple Example
? ( (ActNode) Txsnd )
(ActNode)
Txsnd
s1
Erase
Txrcv
data
Store
s2
Role snd
Role rcv
(a) TSNode
(b) Transaction Tx
8
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.

9
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.

10
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 ?

11
? (? 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
Data
Txsnd
snd
rcv
s1
Transaction Tx Comm. between network nodes
Txrcv
Store
s2
12
Concrete Simulation
Txsnd
Txsnd
Tx
Txrcv
Txrcv
Store
Store
The number of nodes could be very large,
consider 107 phones in a region of a telecom
network
13
Symbolic Simulation
s1
Txsnd
Txsnd
s1
Tx
Txrcv
Txrcv
Store
Store
s2
s2
( s1 -gt 2, s2 -gt 0 )
( s1 -gt 1, s2 -gt 1)
But this is not (yet) accurate since the
transactions are guarded.
14
Behavioral Partitions

• Group active objects into Behavioral
  Partitions
• Control state of Process classs 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.

15
Illustration of Behavioral Partitions
Erase, Store No communication Guards of Tx are
? , ?(? Txsnd) ? Erase,Store,Txsnd,
Txrcv
Txsnd, Erase
s1
Txsnd
Txrcv
Store
?
Txsnd
t
u2
u1
?Tx snd
s2
?Tx snd
?
? (? Tx snd )
Behavioral partitions (s1, t, u1) (s1,t,u2)
(s2,t,u1) (s2,t,u2)
Tx
snd
rcv
16
Symbolic Simulation
Txsnd, Erase
s1
?
Txsnd
t
u2
u1
Txrcv
?Tx snd
?Tx snd
Store
One step of symbolic simulation (s1, t, u1)
100 (s1,t,u2) (s2,t,u1) (s2,t,u2) 0
s2
Tx
(s1, t, u1) 98 (s1,t,u2) 1 (s2,t,u1) 1
(s2,t,u2) 0
17
Dynamic Object Associations
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
Txrcv
Acksnd
Ackrcv
Txsnd
Node3
t1
t2
Node1
Connect
Node1/Node2/Node3
Node2
Tx checks (snd,rcv) in Connect
18
Simulation
Execute Tx
Txrcv
Acksnd
Ackrcv
Txsnd
Node1/Node2/Node3
No distinction among objects of the same class.
19
Simulation
Execute Tx -- executed Execute Tx
Wait-for-ack ( )
Txrcv
Acksnd
Txsnd
Ackrcv
Node1/Node2/Node3
20
Simulation
Execute Tx -- executed Execute Tx -- executed
Wait-for-ack ( ), ( )
Txrcv
Acksnd
Ackrcv
Txsnd
Denote behavioral
partitions of Node1/Node2/Node3 -- No object
Identifiers
Node1/Node2/Node3
21
What do we have ?
But, the proof of the pudding
22
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

23
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.

24
Weather update subsystem
CM
1
1
1
connected
itsWCP
0..N
1
Clients
N
WCP
1
WCP -- Weather Control Panel
(contains weather info.) CM -- Communications
Manager (transfers info from WCP to
clients) Clients Weather aware, seek connection
with CM
25
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 processs state
  separately !!

26
Experiments
Time (C ) secs Time (S) secs Mem ( C) MB Mem (S ) MB
Rail-car (24 cars) 2.1 3.9 83 173
Rail-car (48 cars) 2.2 7.0 84 153
Shuttle (30) 0.44 0.7 18 33
Shuttle (60) 0.44 1.2 18 69
CTAS (10) 1.5 2 63 87
CTAS (20) 1.5 4.1 64 189
Simulation stopped after 1000 transactions
27
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
  !!

28
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

29
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.

30
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