130 likes | 261 Views
Component-Based Abstraction. Juncao Li Dept. of Computer Science Portland State University. 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.
E N D
Component-Based Abstraction Juncao Li Dept. of Computer Science Portland State University
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 University
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 University
A(p) Assumptions = Assumed Properties 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 • pis verified assumingA(p)holds. A(p) p holds on C p C System Verification Laboratory, Portland State University
xUML Object Instance Input Message Type Component Boundary Output Message Type Example: Software Sensor Component System Verification Laboratory, Portland State University
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 University
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 University
Unify hardware and software semantics via translation Semantics Mapping Semantics Mapping Asynchronous Interleaving Message-passing Semantics Synchronous Clock- driven Semantics ω-automaton Semantics Semantics Conformance Semantics Conformance Semantics Conformance xUML-to-S/R Translation Verilog-to-S/R Translation Executable UML (xUML) S/R Verilog System Verification Laboratory, Portland State University
Constraints: properties of C2 related to pand whose assumptions hold Constraints: properties of C1 related to pand whose assumptions hold ω-automaton ω1 (simulating the interface of C1; non-deterministic) ω-automaton ω2 (simulating the interface of C2; non-deterministic) ω-automaton env (simulating the interface of the composition’s environment; non-deterministic) Constraints: the composition’s environment assumptions related to p Note: Circular reasoning must be ruled out by appropriate compositional reasoning rules. Properties as Component Abstractions Abstraction for checking p on the composition of C1 and C2: System Verification Laboratory, Portland State University
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 University
Dependency Graph Example System Verification Laboratory, Portland State University
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 University
Scalability Evaluation on Small-Size Systems • 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 System Verification Laboratory, Portland State University