1 / 13

Component-Based Abstraction

This work focuses on improving the correctness and reusability of component-based development (CBD). At Portland State University's System Verification Laboratory, we explore challenges such as behavioral discrepancies in components with identical interfaces and the difficulties in validating the interaction between sub-components. We propose a framework for formal verification, including xUML and automated reasoning, to ensure that component properties align with their environmental assumptions, mitigating risks exemplified by historical failures like the Ariane 5 rocket incident.

keagan
Download Presentation

Component-Based Abstraction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. 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

  4. 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

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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. Dependency Graph Example System Verification Laboratory, Portland State University

  12. 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

  13. 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

More Related