1. Component-Based Abstraction and Refinement Juncao Li 1, Xiuli Sun 2, Fei Xie 1, and Xiaoyu Song 2 1 Dept. of Computer Science 2 Dept. of ECE Portland State University

2. juncao@cs.pdx.edu System Verification Laboratory, Portland State University2 Agenda Problems and Challenges Component-Based Abstraction and Refinement Case Studies and Evaluations Conclusions and Future Work

3. juncao@cs.pdx.edu System Verification Laboratory, Portland State University3 Goal Correctness of Development and Reuse in Component-Based Development (CBD) In CBD: –A system is developed by components –Components do not share states –Communicate through interfaces

4. juncao@cs.pdx.edu System Verification Laboratory, Portland State University4 Problems of CBD Same interface, but different behaviors Literal specification is not accurate Whether sub-components together can implement system functionalities Explosion of Ariane 5 rocket on June 4, 1996 (cost $500 million)

5. juncao@cs.pdx.edu System Verification Laboratory, Portland State University5 Solution: Model Checking Checking whether a given model conforms to given formal specifications –Model, e.g., hardware or software design –Formal specification, e.g., temporal logic formula

6. juncao@cs.pdx.edu System Verification Laboratory, Portland State University6 State Space Explosion Model checking tries all possibilities State space explosion –Possible states and execution paths in a real-world system could be too large to explore Compositional reasoning for CBD –Decompose system into modules –Check module properties locally –Derive system properties from the module properties –Potential to relieve the problem

7. juncao@cs.pdx.edu System Verification Laboratory, Portland State University7 Research Challenges How to reuse verification efforts –Verified properties should not be checked again How to build the abstraction for verification –Important to reduce the complexity How to determine the causes for a compositional reasoning failure –Real error or abstraction inaccuracy

8. juncao@cs.pdx.edu System Verification Laboratory, Portland State University8 Our Contributions Verification reuse –Verified properties as component abstractions Automatic component-based abstraction algorithm Mechanized assistant for abstraction refinement Application –Co-verification of embedded systems: consider both HW and SW in verification

9. juncao@cs.pdx.edu System Verification Laboratory, Portland State University9 Agenda Problems and Challenges Component-Based Abstraction and Refinement Case Studies and Evaluations Conclusions and Future Work

10. juncao@cs.pdx.edu System Verification Laboratory, Portland State University10 Unifying hardware and software component models Component = (Design, Interface, Properties) HW, SW, and bridge components –Different design and interface specifications –Same property specification Verified properties are associated with components Unified Component Model Software Component Software Component Software Component Bridge Component Bridge Component Hardware Component Hardware Component

11. juncao@cs.pdx.edu System Verification Laboratory, Portland State University11 Environment of C (Components interacting with C ) Component Property A property of a component C is a pair (p, A(p)) –p is a temporal assertion –A(p) is a set of assumptions on environment of C –p is verified assuming A(p) holds. C p A(p)  p holds on C A(p) Assumptions = Assumed Properties

12. juncao@cs.pdx.edu System Verification Laboratory, Portland State University12 Example: Software Sensor Component Output Message Type Component Boundary xUML Object Instance Input Message Type

13. juncao@cs.pdx.edu System Verification Laboratory, Portland State University13 Software Sensor Properties /* Properties on overall component functionality */ IfRepeatedly (C_Intr) Repeatedly (Output); /* Properties on interactions with software components */ After (Output) Never (Output) UnlessAfter (OP_Ack); /* Properties on interactions with hardware and responses to scheduling */ After (C_Intr) Eventually (C_Ret); Never (C_Ret) UnlessAfter (C_Intr); After (C_Ret) Never (C_Ret) UnlessAfter (C_Intr); After (A_Intr) Eventually (A_Ret); Never (A_Ret) UnlessAfter (A_Intr); After (A_Ret) Never (A_Ret) UnlessAfter (A_Intr); After (ADC.Pending) Never (ADC.Pending) UnlessAfter (A_Ret); After (S_Schd) Eventually (S_Ret); Never (S_Ret) UnlessAfter (S_Schd); After (S_Ret) Never (S_Ret) UnlessAfter (S_Schd); After (STQ.Empty = False) Never (STQ.Empty = False) UnlessAfter (S_Ret);

14. juncao@cs.pdx.edu System Verification Laboratory, Portland State University14 Software Sensor Assumptions /* Assumptions on interactions with software components */ After (Output) Eventually (OP_Ack); Never (OP_Ack) UnlessAfter (Output); After (OP_Ack) Never (OP_Ack) UnlessAfter (Output); /* Assumptions on interactions with hardware and on scheduling */ After (C_Intr) Never (C_Intr+A_Intr+S_Schd) UnlessAfter (C_Ret); After (ADC.Pending) Eventually (A_Intr); Never (A_Intr) UnlessAfter (ADC.Pending); After (A_Intr) Never (C_Intr+A_Intr+S_Schd) UnlessAfter (A_Ret); After (A_Ret) Never (A_Intr) UnlessAfter (ADC.Pending) After (STQ.Empty = FALSE) Eventually (S_Schd); Never (S_Schd) UnlessAfter (STQ.Empty = FALSE); After (S_Schd) Never (C_Intr+A_Intr+S_Schd) UnlessAfter (S_Ret); After (S_Ret) Never (S_Schd) UnlessAfter (STQ.Empty = FALSE);

15. juncao@cs.pdx.edu System Verification Laboratory, Portland State University15 Unify hardware and software semantics via translation Verilog-to-S/R Translation Semantics Mapping xUML-to-S/R Translation Semantics Mapping Asynchronous Interleaving Message-passing Semantics ω-automaton Semantics Synchronous Clock- driven Semantics Executable UML (xUML) S/RVerilog Semantics Conformance Semantics Conformance Semantics Conformance

16. juncao@cs.pdx.edu System Verification Laboratory, Portland State University16 Properties as Component Abstractions ω-automaton ω2 (simulating the interface of C2; non-deterministic) ω-automaton ω1 (simulating the interface of C1; non-deterministic) ω-automaton env (simulating the interface of the composition’s environment; non-deterministic) Abstraction for checking p on the composition of C1 and C2: Constraints: properties of C1 related to p and whose assumptions hold Constraints: properties of C2 related to p and whose assumptions hold Constraints: the composition’s environment assumptions related to p Note: Circular reasoning must be ruled out by appropriate compositional reasoning rules.

17. juncao@cs.pdx.edu System Verification Laboratory, Portland State University17 Key Challenges in Abstraction (1) What component properties are related? –ABV tends to introduce many properties Construct property dependency graph –Add dependency arcs of (q, A(q)) based on A(q) –Dependency analysis based on variables –Optimizations based on property templates Differentiating safety and liveness properties Utilizing template semantics to remove false arcs

18. juncao@cs.pdx.edu System Verification Laboratory, Portland State University18 Dependency Graph Example

19. juncao@cs.pdx.edu System Verification Laboratory, Portland State University19 Key Challenges in Abstraction (2) What component properties can be included? –Properties have assumptions –Circular dependencies among properties Enable component properties optimistically –Follow the dependency graph –Check whether their assumptions are satisfied –Assume that dependency cycles do not cause problems Detect cycles of liveness properties –No cycle with both safety and liveness properties –Cycles of safety properties not a problem

20. juncao@cs.pdx.edu System Verification Laboratory, Portland State University20 Automatic Abstraction Algorithm

21. juncao@cs.pdx.edu System Verification Laboratory, Portland State University21 Automatic Abstraction Algorithm (Cont.)

22. juncao@cs.pdx.edu System Verification Laboratory, Portland State University22 Mechanized Refinement Assistant Unsatisfied assumptions of component properties Identification –Breadth-first search on the dependency graph –All nodes marked “directly unsatisfied” and reachable from (true, {p}) only via “indirectly unsatisfied” nodes Automatic remedies –Verify unsatisfied assumptions of identified properties Manual remedies –Modify existing component properties –Introduce new component properties

23. juncao@cs.pdx.edu System Verification Laboratory, Portland State University23 Mechanized Refinement Assistant (Cont.) Liveness property dependency cycles Identification –Done in abstraction algorithm Automatic remedies –Exclude properties on the cycles –Apply CR rules with automatic checks [Amla, et al. 01] Manual remedies –Conduct temporal inductions [McMillan 99] –Modify component properties involved

24. juncao@cs.pdx.edu System Verification Laboratory, Portland State University24 Agenda Problems and Challenges Component-Based Abstraction and Refinement Case Studies and Evaluations Conclusions and Future Work

25. juncao@cs.pdx.edu System Verification Laboratory, Portland State University25 Bottom-Up Verification of Basic Components Verification of primitive HW/SW components Direct application of model checking Verification of properties shown before Properties are verified under their assumptions ComponentsTime (Seconds)Memory (Mbytes) S-SEN18.668.49 S-NET18.069.11 H-CLK0.213.38 H-SEN0.223.39 H-NET0.223.39

26. juncao@cs.pdx.edu System Verification Laboratory, Portland State University26 Top-Down Verification of Basic Sensor System Properties of bridge components –Derived from properties of HW/SW components they connect –Verified in 3.76 seconds and 6.03 MB and 0.66 seconds and 4.07 MB System property –Verified on an abstraction constructed from component properties –Using 0.1 seconds and 3.40 MB Repeated Transmission Property: Repeated (H-NET.flag); Repeated (H-NET.flag = False) S-SENS-NET H-CLKH-SEN H-NET Bridge

27. juncao@cs.pdx.edu System Verification Laboratory, Portland State University27 Top-Down Verification of Basic Sensor (Cont.) Abstraction construction and verification –No verified component properties are included –The property does not hold on the abstraction Abstraction refinement –Introducing and verifying new component properties –Facilitating detection of design errors No Consecutive 1’s Property: Never ((S-NET.RFM.Rev=1) and (S-NET.RFM.Buf=1) and (S-NET.RFM.Status=Transmitting)) S-SENS-NET H-CLKH-SEN H-NET Bridge

28. juncao@cs.pdx.edu System Verification Laboratory, Portland State University28 Top-Down Verification of Multi-Sensor System Properties of new bridge component –Derived from properties of HW/SW components it connects –Verified in 10.24 seconds and 6.05 MB System property –Verified on an abstraction constructed from component properties –Using 0.1 seconds and 3.40 MB Repeated Transmission Property: Repeated (H-NET.flag); Repeated (H-NET.flag = False) S-SENS-NET H-CLKH-SEN 1H-SEN 2H-NET Bridge

29. juncao@cs.pdx.edu System Verification Laboratory, Portland State University29 Top-Down Verification of Encryption-Enabled Sensor Properties of S-ENC and H-ENC –Verified in 0.24 seconds and 3.57 MB and 0.22 seconds and 3.39 MB Properties of new bridge component –Verified in 10.24 seconds and 6.05 MB System property –Verified on an abstraction constructed from component properties –Using 0.1 seconds and 3.40 MB Repeated Transmission Property: Repeated (H-NET.flag); Repeated (H-NET.flag = False) S-SENS-ENCS-NET H-CLKH-SENH-ENCH-NET Bridge

30. juncao@cs.pdx.edu System Verification Laboratory, Portland State University30 Integrated Verification of New Reusable Components A new reusable composite component: encryption-enabled network is constructed bottom-up Properties IfRepeatedly (Raw) Repeatedly (HNET.flag); IfRepeatedly (Raw) Repeatedly (HNET.flag=False); After (Raw) Eventually (Raw_Ack); Never (Raw_Ack) UnlessAfter (Raw); After (Raw_Ack) Never (Raw_Ack) UnlessAfter (Raw); Assumptions: After (Raw) Never (Raw+E_Intr+N_Schd+R_Intr) UnlessAfter (Raw_Ack); After (E_Intr) Never (Raw+E_Intr+N_Schd+R_Intr) UnlessAfter (E_Ret); After (N_Schd) Never (Raw+E_Intr+N_Schd+R_Intr) UnlessAfter (N_Ret); After (R_Intr) Never (Raw+E_Intr+N_Schd+R_Intr) UnlessAfter (R_Ret); S-ENCS-NET H-ENCH-NET Bridge

31. juncao@cs.pdx.edu System Verification Laboratory, Portland State University31 Verification of the repeated transmission property on three systems Conducted on a SUN Workstation with 1GHZ CPU and 2GB memory CBCV: Time (or memory) usage = sum (or max) of time (or memory) usages for verifying new components and abstractions Scalability Evaluation on Small-Size Systems UsagesBasicMultiEncrypting FlatTime (Sec.)31272.8 Out of memory FlatMem. (MB)1660.62 Manual CBCVTime (Sec.)41.8910.340.77 Manual CBCVMem. (MB)9.116.053.57 Manual CBCV# of COSPAN Calls824 Automatic CBCVTime (Sec.)205.9310.4512.97 Automatic CBCVMem. (MB)27.574.443.54 Automatic CBCV# of COSPAN Calls392439

32. juncao@cs.pdx.edu System Verification Laboratory, Portland State University32 Agenda Problems and Challenges Component-Based Co-Verification Case Studies and Evaluations Conclusions and Future Work

33. juncao@cs.pdx.edu System Verification Laboratory, Portland State University33 Conclusions and Future Work An important step towards component-based HW/SW co-verification of embedded systems Preliminary results are promising –Achieved major verification reuse –Led to order-of-magnitude verification reductions Future work –Heuristics for automating property formulation –Further evaluation and cost quantification

34. juncao@cs.pdx.edu System Verification Laboratory, Portland State University34 Further Information Website: –http://www.cs.pdx.edu/~xie/co-ver/co-ver-home.htmhttp://www.cs.pdx.edu/~xie/co-ver/co-ver-home.htm Email: –juncao@cs.pdx.edujuncao@cs.pdx.edu Questions?