1 / 30

Communicating Active Components in System Modeling

Joint work focusing on communication, simulation, and model checking of component interactions in system modeling. Providing executable requirements, emphasizing process classes, and behavioral partitions to avoid blow-up in FSMs.

eara
Download Presentation

Communicating Active Components in System Modeling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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) *  ( (ActNode)*Txsnd ) 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 10^7 phones in a region of a telecom network

  13. Symbolic Simulation s1 Txsnd Txsnd s1 Tx Txrcv Txrcv Store Store s2 s2 ( s1 -> 2, s2 -> 0 ) ( s1 -> 1, s2 -> 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 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.

  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 Ackrcv Acksnd 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 Ackrcv Acksnd 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 1 CM 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 process’s state separately !!

  26. Experiments 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

More Related