Integration of Model Checking into Software Development Processes

1. Integration of Model Checking into Software Development Processes Fei Xie

2. Outline • Problem • Dissertation research overview • Focus: Integration of model checking into CBD • Conclusion and future work

3. Validation of Software • Testing is the most commonly used technique • Software complexity has overwhelmedconventional testing methods • Test case coverage • Lack of automation • Concurrency makes testing even harder • Software must be validated • Advanced validation techniques are needed

4. Model Checking (MC) • A formal verification method • Able to explore all possible states (or execution paths) of a system • Enjoys substantial automation support • Has been quite successful for hardware [Clarke and Emerson 81, Queille and Sifakis 82]

5. Research Goal and Problem • Goal: Seamlessly integrate MC into software development processes • Problem: Address two major challenges • Applicability • State space explosion

6. Challenge I: Applicability • Syntax and semantics gaps between • Software specification languages • Input languages of model checkers • Often specify finite-state systems • Difficulties in property specification • For instance, software engineers are not familiar with temporal logics

7. Challenge II: State Space Explosion • 5 components, 1000 states/component • Worst case: 1000 trillion states

8. Model-Driven Development (MDD) Component-Based Development (CBD) Model Checking Model Checking Overview of My Research +

9. Analysis and Design Executable Design Model Design Validation Predefined Templates Code (C/C++, Java) Code Generation Validated Executable Design Model-Driven Development Requirement Increasingly popular for Embedded Systems and Web-Based Systems

10. Executable UML (xUML) • Has well-defined Execution Semantics • Utilizes UML Action Semantics recently adopted by OMG • Can be compiled to procedural codes • Tools provided by: • Project Technologies • Kennedy Carter • Hyperformix (SES) • …

11. Integration of MC into MDD How to address applicability? • Executable design-level models are key to MDD • Executable:amenable to model checking • Design-level: lower complexities • Model Checking Software Designs via Translation[FASE’04, FASE’02a, ASE’01] • Translate designs into model-checkable languages • Reuse state-of-the-art model checkers • Support design-level property formulation

12. Designer Property xUML Model Error Report S/R Query S/R Model Error Track The ObjectCheck Toolkit Property Specification Interface xUML IDE Error Visualizer xUML-to-S/R Translator Error Report Generator COSPAN Model Checker

13. COSPAN [Hardin, Har’El, and Kurshan 96] • Automata-theoretical approach to model checking[Kurshan 94] • Model a system and its property as -automata, P and T • Check the language containment, L(P)  L(T) • Many state space search and reduction algorithms • Explicit state enumeration • Symbolic model checking • Localization reduction • Homomorphism reduction • (and more)

14. Integration of MC into MDD (cont.) How to reduce state spaces? • Model Checking Software Designs via Translation[FASE’04, FASE’02a, ASE’01] • Many reduction algorithms applied in translation • Integrated State Space Reduction[FASE’02b] • Reduction algorithms applied in an integrated way • Translation-Based Compositional Reasoning[FME’03] • Application of CR in model checking via translation

15. Verification Task Compositional Reasoning Abstraction Symmetry Reduction User-Driven State Space Reduction Verification Subtasks Reduced xUML Model Reduced xUML Level Query Partial Order Reduction Symbolic Verification Localization Reduction Basic Model Checking Process Integrated State Space Reduction Framework xUML Model xUML Level Query xUML-to-S/R Translation S/R Model S/R Level Query Model Checking with COSPAN Success Report / Error Track

16. Translation-Based Compositional Reasoning • Compositional Reasoning (CR)[Misra and Chandy 81, …] • Decompose a system into modules • Verify module properties • Derive system properties from module properties • To apply CR, what need be done • Establish a compositional reasoning rule • Prove the correctness of the rule • Implement the rule • How to apply CR in model checking via translation?

17. (4) Prove the rule based on the mapping and proof of the corresponding rule in formal semantics (2) Map the rule to its corresponding rule in the formal semantics Semantics Translation Rule Establishment and Proof • Establish a compositional reasoning rule Software Semantics Formal Semantics (3) Prove the corresponding rule or reuse existing proof

18. (4) Establishment of conclusion according to the proven rule. (2) Translation of the premises. Rule Implementation and Application • Formulation of premises for applying the rule Software System Formal Representation (3) Discharge of the premises

19. Real-World Systems Verified • The control subsystem of a NASA robotics system[FMSD’03] • Code size 45,000 lines of C++ • 22 properties checked: safety and liveness • 6 bugs found • Instances of TinyOS run-time system for networked sensors [ESEC/SIGSOFT FSE’03]

20. Component-Based Development (CBD) Model Checking Today’s Focus:Integration of MC into CBD How are Applicability and State Space Explosion addressed? Verified Systems by Composition from Verified Components[ESEC/SIGSOFT FSE’03]

21. Integration of MC into CBD • Motivation • Overview • Component Model for Verification • Case Study: TinyOS • Verification of Components

22. What is CBD? • Compose systems via component assembly • Pre-fabricate many components • Reuse components as much as possible • Increasingly popular for • Embedded systems • Web-based systems • Analogies: Automotive and Avionics

23. Research Goal • Goal: • To construct safe, secure, and reliable systems from safe, secure, and reliable components • Framework: • Composition of verified systems from verified components

24. Research Challenges • How to verify primitive components? • How to represent the environment? • How to conduct the verification? • How to compose verified components to build larger verified components effectively? • How to verify the larger components? • How to reuse verified properties? Both applicability and state space management

25. Synergy between CBD and MC • Component-based development • Introduces compositional structures to software • Helps minimize state spaces to be explored • Model checking • Provides exhaustive state space coverage • Strong at detection of composition errors Explore this synergy to address these challenges

26. Integration of MC into CBD • Motivation • Overview • Component Model for Verification • Case Study: TinyOS • Verification of Components

27. + = Verified Properties Verified Properties Verified Properties Our Approach Verification of a property on a composite component • Reuses verified properties of its sub-components • Is based on compositional reasoning • Follows an abstraction-refinement paradigm

28. Compositional Reasoning To model check a property on a software system • Step 1: Decompose the system into modules and model-check module properties • Step 2: Derive the system property from the verified module properties Assume-guarantee style of compositional reasoning[Misra and Chandy 81, Abadi and Lamport 93, Alur and Henzinger 99, McMillan 99, Amla, Emerson, Namjoshi and Trefler 01, …] • Model check properties of a module assuming properties of other modules hold

29. Integration of MC into CBD • Motivations • Overview • Component Model for Verification • Case Study: TinyOS • Verification of Components

30. Functional Interface External Visible Variables Verified Temporal Properties Executable Representation (Design Models or Sources) Component

31. Environment of C (Components interacting with C ) Component Property • A property of C is a pair (p, A(p)) • p is a temporal property • A(p) is a set of assumptions on environment of C • pis verified assumingA(p)holds. A(p) p holds on C A(p) Assumptions = Assumed Properties p C

32. Executable of C1 Connect via interfaces Executable of C … Executable of Cn Interface of C1 Selectively merge Interface of C … Interface of Cn (Visible variable sets are treated in the same way.) ? Properties of C1 Properties of C … Properties of Cn Component Composition

33. Instantiation of Component Model on AIM Computation Model • Asynchronous Interleaving Message-passing • A system consists of a finite set of processes • Processes execute asynchronously • At any moment, only one process executes • Interactions via asynchronous message-passing • Semantics of xUML conforms to the AIM model.

34. External Visible Variables Verified Temporal Properties Instantiation of Component Model on AIM Computation Model (cont.) • Compose components by establishing mappings among their input and output message types Messaging Interface Design models in xUML

35. Integration of MC into CBD • Motivation • Overview • Component Model for Verification • Case Study: TinyOS • Verification of Components

36. TinyOS [Hill, et al., 00] • A run-time system for networked sensors from UC Berkeley • Component-based • Different requirements of sensors • Physical limitations of sensors • High reliability required • Concurrency-intensive operations • Installation to many sensors

37. Integration of MC into CBD • Motivation • Overview • Component Model for Verification • Case Study: TinyOS • Verification of Components

38. Designer Property xUML Model Error Report S/R Query S/R Model Error Track Background:Verification of Closed AIM System Property Specification Interface xUML IDE Error Visualizer xUML-to-S/R Translator Error Report Generator COSPAN Model Checker

39. 2. Constrain the closed system 1. Create a closed system p Env (AIM Process) … Assumptions in A(p) 3. Check p on the constrained system Verification of Primitive Components To check a property (p, A(p)) : Addressing both applicability and state space explosion in model checking primitive components With a matching interface, but non-deterministic Primitive Component Step 1 of Compositional Reasoning: Verification of Module Property

40. AIM Process Input Message Type Component Boundary Output Message Type Sensor Component

41. Sensor Component (cont.) Properties: (Output repeatedly and handle output handshakes correctly.) Repeatedly (Output);After (Output) Never (Output) UntilAfter (OP_Ack);After (Done) Eventually (Done_Ack);Never (Done_Ack) UntilAfter (Done);After (Done_Ack) Never (Done_Ack) UntilAfter(Done); Assumptions: (Output handshakes are correctly ack-ed.) After (Output) Eventually (OP_Ack);Never (OP_Ack) UntilAfter (Output);After (OP_Ack) Never (OP_Ack) UntilAfter (Output);After (Done) Never (Done) UntilAfter (Done_Ack);

42. Output Env Output_Ack Done Done_Ack … Assumptions Verification of Sensor Component Sensor Component

43. Network Component

44. Network Component (cont.) Properties: (Transmit repeatedly if input repeatedly, and handle input handshakes correctly.) IfRepeatedly (Data) Repeatedly (RFM.Pending); IfRepeatedly (Data) Repeatedly (Not RFM.Pending); After (Data) Eventually (Data_Ack); Never (Data_Ack) UntilAfter (Data); After (Data_Ack) Never (Data_Ack) UntilAfter (Data); After (Sent) Never (Sent) UntilAfter (Sent_Ack); Assumptions: (Input handshakes are correctly ack-ed.) After (Data) Never (Data) UntilAfter (Data_Ack); After (Sent) Eventually (Sent_Ack); Never (Sent_Ack) UntilAfter (Sent); After (Sent_Ack) Never (Sent_Ack) UntilAfter (Sent);

45. (3) Refinement (2) Verification Verification of Composite Components Addressing both applicability and state space explosion in model checking composite components To model check a property on a composite component: (1) Abstraction

46. Refine through adding details Refined Abstraction … Good Enough Abstraction Abstraction-Refinement Paradigm Abstraction What is the abstraction? Verified properties of sub-components Component

47. Verified Properties as Abstraction A property = a behavior of a component Sensor Component Property 1: Outputs repeatedly Property 2: Handles output handshakes correctly The component can be represented by the property if only the behavior is of interest.

48. Sensor-to-Network Component

49. Sensor-to-Network Component Properties: (Transmit repeatedly on physical network.) Repeatedly (RFM.Pending); Repeatedly (Not RFM.Pending); Assumptions: (Assumptions on hardware platform are ignored. )

50. Verified Properties Verified Properties SP (Sensor) NP (Network) Non-deterministic AIM Processes Assumptions Abstraction Env (Environment)