1 Refactoring Design Models for Inductive Verification Yung-Pin Cheng Dept. of Info. & Comp. Edu. National Taiwan Normal Univ. TAIWAN Michal Young Dept.

Slides:



Advertisements
Similar presentations
1 Verification by Model Checking. 2 Part 1 : Motivation.
Advertisements

Tintu David Joy. Agenda Motivation Better Verification Through Symmetry-basic idea Structural Symmetry and Multiprocessor Systems Mur ϕ verification system.
Translation-Based Compositional Reasoning for Software Systems Fei Xie and James C. Browne Robert P. Kurshan Cadence Design Systems.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
Hierarchical Cache Coherence Protocol Verification One Level at a Time through Assume Guarantee Xiaofang Chen, Yu Yang, Michael Delisi, Ganesh Gopalakrishnan.
A component- and message-based architectural style for GUI software
1 1 Regression Verification for Multi-Threaded Programs Sagar Chaki, SEI-Pittsburgh Arie Gurfinkel, SEI-Pittsburgh Ofer Strichman, Technion-Haifa Originally.
Timed Automata.
© 2011 Carnegie Mellon University SPIN: Part /614 Bug Catching: Automated Program Verification Sagar Chaki April 21, 2014.
Concurrency: introduction1 ©Magee/Kramer 2 nd Edition Concurrency State Models and Java Programs Jeff Magee and Jeff Kramer.
Programming Paradigms for Concurrency Lecture 11 Part III – Message Passing Concurrency TexPoint fonts used in EMF. Read the TexPoint manual before you.
© 2011 Carnegie Mellon University SPIN: Part /614 Bug Catching: Automated Program Verification Sagar Chaki April 21, 2014.
Regular Model Checking Parosh Aziz Abdulla Uppsala University Cooperation with B. Jonsson, M. Nilsson, J. d’Orso.
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
1 Towards formal manipulations of scenarios represented by High-level Message Sequence Charts Loïc Hélouet Claude Jard Benoît Caillaud IRISA/PAMPA (INRIA/CNRS/Univ.
An Automata-based Approach to Testing Properties in Event Traces H. Hallal, S. Boroday, A. Ulrich, A. Petrenko Sophia Antipolis, France, May 2003.
Understanding Networked Applications: A First Course Chapter 17 by David G. Messerschmitt.
Course Summary. © Katz, 2003 Formal Specifications of Complex Systems-- Real-time 2 Topics (1) Families of specification methods, evaluation criteria.
VIDE Integrated Environment for Development and Verification of Programs.
Model Checking. Used in studying behaviors of reactive systems Typically involves three steps: Create a finite state model (FSM) of the system design.
Developing Verifiable Concurrent Software Tevfik Bultan Department of Computer Science University of California, Santa Barbara
Verification of Hierarchical Cache Coherence Protocols for Future Processors Student: Xiaofang Chen Advisor: Ganesh Gopalakrishnan.
Review of “Embedded Software” by E.A. Lee Katherine Barrow Vladimir Jakobac.
Software Engineering, COMP201 Slide 1 Protocol Engineering Protocol Specification using CFSM model Lecture 30.
1 IFM 2005 – November 30, 2005 EXP.OPEN 2.0 A flexible tool integrating partial order, compositional, and on-the-fly verification methods Frédéric Lang.
Chapter 11: Distributed Processing Parallel programming Principles of parallel programming languages Concurrent execution –Programming constructs –Guarded.
Course Summary. © Katz, 2007 Formal Specifications of Complex Systems-- Real-time 2 Topics (1) Families of specification methods, evaluation criteria.
System-Level Types for Component-Based Design Paper by: Edward A. Lee and Yuhong Xiong Presentation by: Dan Patterson.
Router modeling using Ptolemy Xuanming Dong and Amit Mahajan May 15, 2002 EE290N.
The OSI Model A layered framework for the design of network systems that allows communication across all types of computer systems regardless of their.
Time, Clocks, and the Ordering of Events in a Distributed System Leslie Lamport (1978) Presented by: Yoav Kantor.
02/06/05 “Investigating a Finite–State Machine Notation for Discrete–Event Systems” Nikolay Stoimenov.
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
Transitioning From Software Requirements Models to Design Models
Regular Model Checking Ahmed Bouajjani,Benget Jonsson, Marcus Nillson and Tayssir Touili Moran Ben Tulila
ECE 720T5 Winter 2014 Cyber-Physical Systems Rodolfo Pellizzoni.
Using Mathematica for modeling, simulation and property checking of hardware systems Ghiath AL SAMMANE VDS group : Verification & Modeling of Digital systems.
Parallel Programming Models Jihad El-Sana These slides are based on the book: Introduction to Parallel Computing, Blaise Barney, Lawrence Livermore National.
Verification of Information Flow Properties in Cyber-Physical Systems Ravi Akella, Bruce McMillin Department of Computer Science Missouri University of.
 Network Segments  NICs  Repeaters  Hubs  Bridges  Switches  Routers and Brouters  Gateways 2.
Scientific Computing By: Fatima Hallak To: Dr. Guy Tel-Zur.
The OSI Model.
SDS Foil no 1 Process Algebra Process Algebra – calculating with behaviours.
Software Engineering Research paper presentation Ali Ahmad Formal Approaches to Software Testing Hierarchal GUI Test Case Generation Using Automated Planning.
Chapter 14 Asynchronous Network Model by Mikhail Nesterenko “Distributed Algorithms” by Nancy A. Lynch.
Advanced Computer Networks Topic 2: Characterization of Distributed Systems.
Lecture 4: Sun: 23/4/1435 Distributed Operating Systems Lecturer/ Kawther Abas CS- 492 : Distributed system & Parallel Processing.
Performance evaluation of component-based software systems Seminar of Component Engineering course Rofideh hadighi 7 Jan 2010.
CS 367: Model-Based Reasoning Lecture 5 (01/29/2002) Gautam Biswas.
Programming Paradigms for Concurrency Pavol Cerny Vasu Singh Thomas Wies Part III – Message Passing Concurrency.
Laboratory of Model Driven Engineering for Embedded Systems An Execution Framework for MARTE-based Models UML&AADL’2008 workshop Belfast, Northern Ireland.
1 CSEP590 – Model Checking and Automated Verification Lecture outline for August 6, 2003.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
1 Joint work with Claudio Antares Mezzina and Jean-Bernard Stefani Controlled Reversibility and Compensations Ivan Lanese Focus research group Computer.
R*: An overview of the Architecture By R. Williams et al. Presented by D. Kontos Instructor : Dr. Megalooikonomou.
Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System.
Shinya Umeno Nancy Lynch’s Group CSAIL, MIT TDS seminar September 18 th, 2009 Machine-Assisted Parameter Synthesis of the Biphase Mark Protocol Using Event.
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
/ PSWLAB Thread Modular Model Checking by Cormac Flanagan and Shaz Qadeer (published in Spin’03) Hong,Shin Thread Modular Model.
Specifying Multithreaded Java semantics for Program Verification Abhik Roychoudhury National University of Singapore (Joint work with Tulika Mitra)
SystemC Semantics by Actors and Reduction Techniques in Model Checking Marjan Sirjani Formal Methods Lab, ECE Dept. University of Tehran, Iran MoCC 2008.
Distributed Algorithms Dr. Samir Tartir Extracted from Principles of Concurrent and Distributed Programming, Second Edition By M. Ben-Ari.
Agenda  Quick Review  Finish Introduction  Java Threads.
Symbolic Model Checking of Software Nishant Sinha with Edmund Clarke, Flavio Lerda, Michael Theobald Carnegie Mellon University.
Copyright 1999 G.v. Bochmann ELG 7186C ch.1 1 Course Notes ELG 7186C Formal Methods for the Development of Real-Time System Applications Gregor v. Bochmann.
Formal methods: Lecture
Chapter 3: Open Systems Interconnection (OSI) Model
Distributed Algorithms
Presentation transcript:

1 Refactoring Design Models for Inductive Verification Yung-Pin Cheng Dept. of Info. & Comp. Edu. National Taiwan Normal Univ. TAIWAN Michal Young Dept. of Comp. & Info. Sci. Univ. of Oregon USA

2 Outline An overview of verifying parameterized concurrent systems An overview of induction framework Using refactoring transformations to enable induction framework for systems with parameterized behaviors Related work Conclusion Future work

3 Parameterized concurrent systems Concurrent systems can be parameterized in many ways, such as The number of identical components e.g., processes The number of data values e.g., the length of a bounded buffer The number of control commands e.g., a protocol that allows retransmission of messages over a lossy channel at most n time Increasing the size parameters often causes state explosion

4 The general verification problem of parameterized systems : system of size i : a family formed by The verification problem: whether every in F satisfies a given property Parameterization induces infinite-state space The problem is undecidable in general but experience shows that many subclasses are decidable.

5 Approaches to the problem 1. Project the infinite-state space into finite-state space and then apply the finite-state techniques Often limited to a particular topology of networks (such as ring, chain, or a central control process with many identical user processes.) Usually requires manual proof 2. Find a network invariant to pass the induction tests (which we call induction framework) In principle, not restricted by network topology Induction test is automatic More popular The main problem is network invariant may not exist or difficult to find (due to the undecidability)

6 Induction framework – An overview By Wolper & Lovinfosse1989 and Kurshan & McMillan A popular approach to extend finite-state verification techniques to verify parameterized systems

7 Induction framework – An overview Assume, where I is some identical component : a preorder relation (e.g., simulation relation) : a preorder relation (e.g., simulation relation) : a property of interest : a property of interest such that such that Find a network invariant Inv to pass three tests Find a network invariant Inv to pass three tests

8 Induction framework – An overview Why with the 3 tests? (use assumption and (1)) (use (2)) (use (3))

9 How models can be affected by parameterization? 1. Models add/remove processes when the system size is increased/decreased (commonly seen in literature) Hardware systems Protocols that communcate by a shared bus 2. The behaviors (transition relation and number of states) of processes grow/shrink when the system size is increased/decreased communication channels of a process varied by size data values varied by size (e.g., buffer size) Some process needs to be aware of new process’s existence

10 How models are affected by parameterization? (Cont.) Typical examples of the first kind P1P2P3 S The three process share the same port of S (adding P4 does not change S’s behaviors) P1 P2 P3 P4 Ring structure: processes only communicate with their left/right-hand sides. (only channel relabelling is needed while adding a new process)

11 How models are affected by parameterization? (Cont.) An example of second kind P1P2P3 S(n) S(n) needs to be aware of every process’s existence and each P_i must communicate with S(n) by a private channel

12 When the induction framework fails For a system whose behaviors are parameterized by n This is where the induction would fail This problem has been ignored or avoided in the past

13 Synchronization structure transformed by refactoring P1P2P3 S(n) P1P2P3P1P2P3P1P2P3 T1T2 T3 S S’s behavior is now independent of system size S’s behavior is now independent of system size So, if we increase the system size by one: So, if we increase the system size by one: P1P2P3 T1T2 T3 S P4 T4 It satisfies the assumption It satisfies the assumption Induction framework is enabled by the new architecture Induction framework is enabled by the new architecture

14 Refactoring Use a sequence of transformations (selected from a set) and apply them in a right order to transform a model into a final model Each maintains behavioral equivalence (weak bisimulation)

15 Refactoring Preprocessor Models in Design Languge e,g, Promela, Ada- like design language LTS Parallel Composition Global State space analysis Property Verification result refactoring

16 A case study - a remote temperature sensor system (RTSS) [Yeh&Young 1994,Sanden 1989] The parameterized control parts Lossy channel

17 Refactoring CP_MODULE (interface behaviors) -send(0) call(1) call(0) -send(1) -send(0) call_end call(1) call(0) call_end CP_MODULE INTR UI Modeled by CCS (Milner)

18 Refactoring strategy A general refactoring strategy is to separate behaviors which are linked to different control parts for example -send(0), call(0) furnace 0 -send(1), call(1) furnace 1 call_end ?

19 -call_end Transformation I: Edge relabeling INTR -send(0) call(1) call(0) -send(1) -send(0) call_end call(1) call(0) call_end CP_MODULE UI -call(0)-call_end -call(1) -call_end(1)  Ada’s accept/do block or Promela’s atomic call_end(1) call_end(0) call_end(1) call_end(0) -call_end(0)

20 Behavioral equivalence View CP_MODULE and INTR as a subsystem, we have where is the weak bisimulation

21 call_end(0) call(0) -send(0) Transformation II: Behavior decomposition CP_MODULE call(1) -send(1) call(1) call_end(1) 1. Identify segment -send(0) call(0) call_end(0) 2. Decompose segment and make it into a new process -send(0) call(0) call_end(0) -send(0) call(0) call_end(0) -send(0) call(0) call_end(0) -send(0) call(0) call_end(0) -send(0) call(0) call_end(0) -send(0) call(0) call_end(0) 3. Add new synchronizations to preserve equivalence -send(1) -send(0) call(0) call_end(0) -get(0) -release(0) -send(0) call(0) call_end(0) CP_SUB0 -send(0) release(0) UI release(0) -send(0)get(0)

22 Transformation II: Behavior decomposition behavioral equivalence is again preserved as

23 Transformation III: Behavior decomposition call(0) -send(0) call(0) call_end(0) -get(0) -release(0) -send(0) call(0) call_end(0) CP_SUB0 release(0) -get(1) -release(1) -send(1) call(1) call_end(1) -send(1) call(1) call_end(1) release(1) -send(0) -get(1) -send(0) -get(0) -send(1)get(1) UI CP_SUB1

24 -send(0) -get(0) -send(0) -get(1) Transformation IV: Semaphore simplification call(0) -send(0) call(0) call_end(0) -get(0) -release(0) -send(0) call(0) call_end(0) CP_SUB0 release(0) release -get(1) -release(1) -send(1) call(1) call_end(1) release release(1) CP_SUB1 -send(1) call(1) call_end(1) -send(0) -get -release -get -release UI -send(0)get-send(1)get CCS two-way rendezvous When increase size by 1, we add another CP_SUB2 The system may no longer meaningful to user

25 Refactoring of INTR -call(0)alert0-call_end(0) -call(0)alert0 -call_end(0)  -call(1)alert1-call_end(1) -call(1)alert1 -call_end(1)  A0 B0 A1 B1 Emulate the loss of alert A0 B0 A1 B A0 A1

26 The result of refactoring INTR -get -release -get-release alert1 -call_end(1)  -call(1) alert1 release -call(1) alert1 -call_end(1) -call(1) alert0 -call_end(0)  -call(0) alert0 release -call(0) alert0 -call_end(0) -call(0)

27 A summary of refactored RTSS Task Name Names of tasks after refactoring CP_MODULE CP_MODULE, CP_MODULE, CP_SUB0, CP_SUB1 INTR INTR INTR,INTR_SUB0,INTR_SUB1 TINTR TINTR, TINTR, TINTR_SUB0, TINTR_SUB1 DP_MODUL E DP_MODULE DP_MODULE,DP_SUB0,DP_SUB1 UI UI UI,UI_SUB0,UI_SUB1 Device[i]Not refactored Furnace[i]Not refactored

28 The induction of RTSS The safety property is translated into a deadlock detection (Cheung & Kramer1999) Property can be inserted into F 0 and R 0  send(0) send_end(0) send(1),alert1 for example

29 The induction of RTSS (cont) We need to find a network invariant to pass We need to find a network invariant to pass Note that we replace the preorder by weak bisimulation Note that we replace the preorder by weak bisimulation Let Inv= RTSS(1) \{actions linked to furnace 0} Let Inv= RTSS(1) \{actions linked to furnace 0} Finally, we test (3) by checking Finally, we test (3) by checking Inv is an effective network invariant Inv is an effective network invariant

30 Other systems A continuously running part of elevator system Alternating bit protocol …….

31 Related work Yeh and Young [STVR 1994] Redesign RTSS for compositional analysis Avrunin et. al. [UMass technical report,1999] Chiron interface – a decomposed dispatcher task Valmari and Kokkarinen [ ICACSD 1998] A protocol that can retransmit the message at most n times With a brave titile: …10^any states and beyond CSP (multi-way rendezvous)

32 Conclusion We propose a technique called refactoring to transform (equivalence preserving) system structure We enable induction framework for systems with parameterized behaviors Partially automated tool support

33 Future research More tool support Full automation for subclasses Looking for a unified family of transformations Extend refactoring to Java threads Question?

34 A prototype Chera

35 A prototype

36 Refactoring of INTR (cont). A0 B0 A A0 B0 A0 B0 A1 B1 A1 B1 A0 B0 A0 B0