Component-Based Abstraction Juncao Li Dept. of Computer Science Portland State University

System Verification Laboratory, Portland State University2 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

System Verification Laboratory, Portland State University3 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)

System Verification Laboratory, Portland State University4 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

System Verification Laboratory, Portland State University5 Example: Software Sensor Component Output Message Type Component Boundary xUML Object Instance Input Message Type

System Verification Laboratory, Portland State University6 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);

System Verification Laboratory, Portland State University7 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);

System Verification Laboratory, Portland State University8 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

System Verification Laboratory, Portland State University9 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.

System Verification Laboratory, Portland State University10 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

System Verification Laboratory, Portland State University11 Dependency Graph Example

System Verification Laboratory, Portland State University12 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

System Verification Laboratory, Portland State University13 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.) Out of memory FlatMem. (MB) Manual CBCVTime (Sec.) Manual CBCVMem. (MB) Manual CBCV# of COSPAN Calls824 Automatic CBCVTime (Sec.) Automatic CBCVMem. (MB) Automatic CBCV# of COSPAN Calls392439