Presentation is loading. Please wait.

Presentation is loading. Please wait.

Verified Systems by Composition from Verified Components Fei Xie and James C. Browne.

Similar presentations


Presentation on theme: "Verified Systems by Composition from Verified Components Fei Xie and James C. Browne."— Presentation transcript:

1 Verified Systems by Composition from Verified Components Fei Xie and James C. Browne

2 2 Research Goal Goal: –Construction of reliable and secure software systems from reliable and secure components; Framework: –Composition of verified systems from verified components.

3 3 Research Challenges How to verify components? How to compose verified components to build larger verified components effectively?

4 4 Synergism between CBD and MC Component-Based Development (CBD) –Introduces compositional structures to software; –Helps minimizing state spaces to be explored. Model Checking (MC) –Provides exhaustive state space coverage; –Strong at detection of composition errors.

5 5 Agenda Motivations Our Approach Component Model for Verification Case Study: TinyOS Verification of Components Related Work Conclusions and Future Work

6 6 Highlights of Our Approach Temporal properties are specified, verified, and packaged with components. Larger components are composed incrementally. Component reuse considers component properties. Verification of a property of a composed component –Reuses verified properties of its sub-components; –Follows abstraction-refinement paradigm; –Is based on compositional reasoning.

7 7 Compositional Reasoning To verify a property on a software system Step 1: Verification of component properties; Step 2: Validation of circular dependencies; Step 3: Derivation of the system property from component properties. Previous work: in top-down system decomposition; Our approach: in bottom-up component composition.

8 8 Why validate circular dependencies between component properties? Eventually (A)Eventually (B) Eventually (A) and Eventually (B) ? C1C2 XX A = FALSE B = FALSE

9 9 Agenda Motivations Our Approach Component Model for Verification Case Study: TinyOS Verification of Components Related Work Conclusions and Future Work

10 10 Component A component, C, has four parts: –Executable representation (models or sources); –Interface (procedural, messaging, …); –A set of externally visible variables; –A set of verified temporal properties of C.

11 11 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. –p is verified assuming A(p) hold. The environment of C –is the set of components that C interacts with; –varies in different compositions.

12 12 Component Composition Connect executable representations of sub-components through their interfaces; Selectively merge interfaces and visible variable sets of sub-components; Verify properties of composed component by reusing properties of sub-components.

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

14 14 Instantiation of Component model on AIM Computation Model (cont.) Component –Represented in Executable UML (xUML); –Messaging interface; Composition –Establishing mappings among input and output message types of sub-components.

15 15 Agenda Motivations Our Approach Component Model for Verification Case Study: TinyOS Verification of Components Related Work Conclusions and Future Work

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

17 17 Agenda Motivations Our Approach Component Model for Verification Case Study: TinyOS Verification of Components Related Work Conclusions and Future Work

18 18 Background: Verification of Closed AIM System Property Specification InterfacexUML IDEError Visualizer xUML-to-S/R TranslatorError Report Generator COSPAN Model Checker S/R ModelS/R Query Error ReportError TrackDesigner xUML Model Property

19 19 Verification of Primitive Components Given a component and a property: –Create a closed system from the component and an environment process, env; –Constrain env with assumptions of the property; –Verify the property on the constrained system. Compositional Reasoning: Step 1

20 20 Sensor Component Output message Type Input message Type Component Boundary AIM Process

21 21 Sensor Component (cont.) Properties: 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: 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); Repeatedly (C_Intr); After (C_Intr) Never (C_Intr + A_Intr + S_Schd) UntilAfter (C_Ret); After (ADC.Pending) Eventually (A_Intr); After (A_Intr) Never (C_Intr + A_Intr + S_Schd) UntilAfter (A_Ret); After (STQ.Empty = FALSE) Eventually (S_Schd); After (S_Schd) Never (C_Intr + A_Intr + S_Schd) UntilAfter (S_Ret);

22 22 Verification of Sensor Component Sensor Component Assumptions Env Output Output_Ack Done Done_Ack …

23 23 Network Component

24 24 Network Component (cont.) Properties: 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: 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); After (NTQ.Empty = FALSE) Eventually (N_Schd); After (N_Schd) Never (N_Schd +R_Intr) UntilAfter (N_Ret); After (RFM.Pending) Eventually (R_Intr); After (R_Intr) Never (N_Schd +R_Intr) UntilAfter (R_Ret);

25 25 Verification of Composed Components (1) Abstraction (2) Verification (3) Refinement

26 26 Abstraction-Refinement Paradigm Component … Abstraction Abstract through removing details Refined Abstraction Refine through adding details What is it? How to create it? How to refine it?

27 27 Sensor-to-Network Component

28 28 Sensor-to-Network Component Properties: Repeatedly (RFM.Pending); Repeatedly (Not RFM.Pending); Assumptions: Repeatedly (C_Intr); After (C_Intr) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) UntilAfter (C_Ret); After (ADC.Pending) Eventually (A_Intr); After (A_Intr) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) UntilAfter (A_Ret); After (STQ.Empty = FALSE) Eventually (S_Schd); After (S_Schd) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) UntilAfter (S_Ret); After (NTQ.Empty = FALSE) Eventually (N_Schd); After (N_Schd) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) UntilAfter (N_Ret); After (RFM.Pending) Eventually (R_Intr); After (R_Intr) Never (C_Intr+A_Intr+S_Schd+N_Schd+R_Intr) UntilAfter (R_Ret);

29 29 Abstraction SP (Sensor) NP (Network) Env (Environment) Verified Properties Assumptions AIM Processes

30 30 Abstraction (cont.) A sub-component property is included if it is –In the cone-of-influence; –Not involved in invalid circular dependencies; –Enabled: Its environment assumptions hold on Other components in the composition; Environment of the composition. Compositional Reasoning: Step 2

31 31 Verification and Complexity ComponentTimeMemory 1Sensor-to-Network89m15.45s208.48M 2Sensor10m41.01s33.673M 3Network18.0S6.8239M 4Abstraction0.1s0.1638M Check the property of SN on the abstraction. Compositional Reasoning: Step 3 and Step 1

32 32 Abstraction Refinement An abstraction can refined by –(Introducing, verifying, and) enabling additional sub-component properties; A property can be enabled by –enabling its assumptions on other components. Currently requires user interactions.

33 33 Refinement Example To check Property P1 on Sensor-to-Network SN transmits any sensor reading exactly once. Property P2 has been verified on Network. Network transmits any input exactly once. Assumption: A new input arrives only after Network acks the last input with a Sent message. P2 is not enabled in the composition of SN.

34 34 Refinement Example (cont.) To enable P2, introduce and check Property P3 on Sensor: Sensor outputs any sensor reading exactly once; After an output, Sensor will not output again until a done message is received. A bug was found in Sensor and fixed. P3 was verified on the revised Sensor. Inclusion of P2 and P3 into the abstraction leads to verification of P1.

35 35 Property and Assumption Formulation Properties –Currently manually guided; –Derived from component specifications; –Added incrementally in component reuses. Assumptions –Manual formulation; –Automatic generation Often lead to complex assumptions. Automatic generation heuristics in progress.

36 36 Agenda Motivations Our Approach Component Model for Verification Case Study: TinyOS Verification of Components Related Work Conclusions and Future Work

37 37 Related Work Compositional Reachability Analysis (CRA) [Graf and Steffen, Yeh and Young, Cheung and Kramer] –Compose and minimize the LTS of a software system from LTSs of its components. Modular Feature Verification [Fisler and Krishnamurthi] –Verification of layered composition of features.

38 38 Conclusions and Future Work An important step towards composition of verified systems from verified components. Results are promising: –Detection of composition errors; –Significant reduction on verification complexity. Future work –Automatic property and assumption generation; –Extended case studies.


Download ppt "Verified Systems by Composition from Verified Components Fei Xie and James C. Browne."

Similar presentations


Ads by Google