1 / 40

LPV: a new technique, based on linear programming, to formally prove or disprove safety properties

LPV: a new technique, based on linear programming, to formally prove or disprove safety properties. J-L Lambert, valiosys. Contents. What is LPV ? LPV in brief The counter-example in real numbers LPV in details 1 The linear programming model The proof engine An example LPV in details 2

dhiner
Download Presentation

LPV: a new technique, based on linear programming, to formally prove or disprove safety properties

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. LPV: a new technique, based on linear programming, to formally prove or disprove safety properties J-L Lambert, valiosys

  2. Contents • What is LPV ? • LPV in brief • The counter-example in real numbers • LPV in details 1 • The linear programming model • The proof engine • An example • LPV in details 2 • A completeness theorem • The refinement process • Conclusion

  3. What is LPV ?

  4. LPV in brief • LPV is a theorem prover • No state space exploration nor representation of the state space • The performance depends on the complexity of the proof, not on the size of the system • Based on linear programming computations • Efficiency (polynomial time) • Real numbers used (the gap between real numbers and integers is always the problem) • High level modeling (state machines) • LPV can generate counter-examples • The technology is complete: if the proof fails there exists a counter-example • Beware: the counter-example may not be a real one. It may be in real numbers

  5. What is a counter-example in real numbers ? t=0 1/2 1/2 1/2 1/2 t=1 1/2 1/2 1/2 1/2 t=2

  6. What to do with counter-examples in real numbers ? Real number counter-examples are the price to pay for having a polynomial and complete proof system Analyzing a counter-example allows to understand why the proof engine failed That analyze gives some indications on how the model can be modified to make the proof succeed The modification of the model is called the refinement the analysis is the refinement algorithm

  7. LPV in details 1

  8. c a d b The model used The model is communicating automata synchronized by blocking rendez-vous c a d b

  9. The translation into linear equations in State e Variable X (e) Transition t Variable Y(t) b Message b Variable M(b) out State e’ Variable X (e’)

  10. X (e) = S Y(t) in t exiting e M(b) = S Y(t) t emitting b X (e) = S Y(t) out t entering e S Y(t)=1 t in the automaton The translation into linear equations One equation for each state One equation for each message and each automaton emitting the message One equation for each state One equation for each automaton

  11. c a d b The epsilon transitions • The model is supposed to contain epsilon transitions: • epsilon transitions carry no message • each state carry one epsilon transition • the epsilon transition has the same input and output state • the epsilon transitions allow an automaton to do nothing epsilon transitions

  12. in X = AY M = BY X = CY 1 = DY _ It has the form: out The linear system of equations generated • And its integer solutions are the global transitions of the system where: • X (e) = 1 iff the automaton is in the state e at the begining of the global transition • M(b)=1 iff b is emitted • Y(t) = 1 iff t is fired • X (e)=1 iff the automaton is in the state e at the end of the global transition in out

  13. The proof engine • The LPV proof engine works under the following assumptions: • The system is described as communicating automata (following the lines mentionned previously) • Each state of each automaton has an epsilon transition • The initial state of the system is implicitely given by an equation: EXi = 0 (E positive) i.e. some states are empty in the initial state • The objective is described as an additional constraint concerning the last state: FXf = 0 (F positive) i.e. some states are empty in the final state

  14. States e such that u(e) >0 The first engine: interpretation The first engine can be be interpreted as the computation of a set of states such that any transition entering the set must synchronize with one that exits it

  15. in u.X = 0 X = AY M = BY X = CY 1 = DY in out implies u.X =0 out _ The first engine It computes a positive vector u (one component per state) such that: E.X =0 implies u.X=0 u has the maximum number of non zero components

  16. The first engine: conclusion • The first engine proves that: • The invariant u.X = 0 is satisfied on any sequence having Xi as initial state • This leads to the conclusions: • all the states of the system for which u(e) > 0 remain empty on any sequence satisfying the request • If for all the states e of an automaton we have u(e) > 0 or F(e) > 0 then the final state must verify: SXf (e) = 0 which is impossible • In consequence we get that • Either there is no possible final state for the request • Or all the states of the system for which u(e) > 0 can be removed from the model e state of the automaton

  17. The second engine: interpretation The second engine can be interpreted as the computation of a set of states such that any transition exiting the set must synchronize with one that enters it States e such that u(e) >0

  18. out u.X = 0 X = AY M = BY X = CY 1 = DY in in implies u.X =0 out _ The second engine It computes a positive vector u (one component per state) such that: F.X =0 implies u.X=0 u has the maximum number of non zero components

  19. The second engine: conclusion • The second engine proves that: • The invariant u.X = 0 is satisfied on any sequence having Xf as final state • This leads to the conclusions: • all the states of the system for which u(e) > 0 remain empty on any sequence satisfying the request • If for all the states e of an automaton we have u(e) > 0 or E(e) > 0 then the initial state must verify: SXi (e) = 0 which is impossible • In consequence we get that • Either there is no possible initial state for the request • Or all the states of the system for which u(e) > 0 can be removed from the model e state of the automaton

  20. C.X = b Xi C.X < b C.X > b Xf The third engine: interpretation

  21. The third engine: interpretation The third engine can be interpreted as the computation of a potential function that increases at each global transition of the system The value of that function is increased iff some specified transitions are fired Moreover that function is decreased between the initial and the final state

  22. in X = AY M = BY X = CY 1 = DY out in implies C.X - C.X = V.Y out _ The third engine It computes a vector C (one component per state) and a vector V positive (one component per transition) such that: E.X=0, F.X’=0 implies C.X ≥ C.X’ V has the maximum number of non zero components

  23. The third engine: conclusion • The third engine proves that: • The linear function C.X increases with any global transition of the system and strictly increases when a transition such that V(t) > 0 is fired • This leads to the conclusions: • all the transitions of the system for which V(t) > 0 cannot be fired in any sequence satisfying the request • If the inequality C.Xi≥ C.Xf is strict: C.Xi > C.Xf then the request is impossible • In consequence we get that • Either the request is impossible • Or all the transitions of the system for which V(t) > 0 can be removed from the model

  24. Behaviour of the proof engine • While no result has been returned • Choose one of the engines and apply it • If the engine proves impossibility then • Returns « proof done » • Else suppress transitions or states • If the three engines were tried and none of them suppressed a transition or a state then • Returns « proof failed » The above process works in polynomial time wrt the number of transitions

  25. An example

  26. An example E1 A1 A2 a ra b a rb ra E0 rb b B1 B2 E2

  27. An example: the first question E1 A1 A2 a ra b a rb ra E0 rb b B1 B2 E2 The question is: Can the state: (A1,E1,B2) be reached ?

  28. An example: the first answer E1 A1 A2 a ra b a rb ra E0 Q rb b B1 B2 E2 The answer is: no since the set: Q={B1,E2,E0,A2} cannot be emptied

  29. An example: the second question E1 A1 A2 a ra b a rb ra E0 rb b B1 B2 E2 The question is: Can a state in: {(A1,E1,B2), (B1,E1,B2)} be reached ?

  30. An example: the second answer E1 A1 A2 a ra b a rb ra E0 rb b B1 B2 E2 The answer is: no since the function: -2X(B1)-X(E0)+X(E1)-3X(E2)+2X(B2) is constant

  31. C.X = 0 Xi 3 C.X  1 C.X = -1 Xf An example: the second answer

  32. LPV in details 2

  33. i-1 i X = AY M = BY X = CY 1 = DY i i i i _ for i=1 to n: i n F.X = 0 0 E.X = 0 The failure of the proof engine: a completeness theorem • When the proof engine fails in finding a proof, it provides an answer that is not simply « the proof failed » • It can provide a counter-example showing why the proof failed • The counter-example is composed of a number n and a real positive number solution of the system of equations:

  34. 1 2 2 1 n n n 1 0 2 Y M M Y M X Y X X X n-1 X Meaning of the counter-examples A counter-example is a scenario on n steps contradicting the property: If the counter-example is in integers, it is a valid counter-example to the property If the counter-example is in real numbers one doesn’t know the status of the property

  35. What to do with counter-examples in real numbers ? Real number counter-examples are the price to pay for having a polynomial and complete proof system Analyzing a counter-example allows to understand why the proof engine failed That analyze gives some indications on how the model can be modified to make the proof succeed The modification of the model is called the refinement the analysis is the refinement algorithm

  36. An example of refinement a.0 b.0 c.0 a.0 b.0 d.0 0,5 0,5 a.1 b.1 c.0 a.1 b.0 c.1 a.1 b.1 d.0 a.1 b.0 d.1 0,5 0,5 a.0 b.1 c.1 a.0 b.1 d.1 a 0,5 0 1 c d 0,5 b

  37. Typical refinement situation 1/2a.0 1/2a.1 1/2a.0 1/2a.1 c.0 d.1 1/2b.0 1/2b.1 1/2b.1 1/b.0 On the refined system: c=0 and d=1 is impossible: a.0 a.1 c.0 d.1 b.0a.0 b.0a.1 b.1

  38. The refined system a.0 b.0a.0 c.0 a.0 b.0a.0 d.0 0 0 0 0 a.1 b.1 c.0 a.1 b.0a.1 c.1 a.1 b.1 d.0 a.1 b.0a.1 d.1 0 0 0 a.0 b.1 c.1 a.0 b.1 d.1 a 0 1 c d b

  39. More general refinements na b ma n n m¬a m m n(¬a ¬b) ca b ca b ca b a b c c c(¬a ¬b)

  40. Conclusion • LPV is a new theorem prover • LPV manipulates new concepts that are not manipulated by other verification techniques • LPV applies well at the level of communicating state machines • LPV’s proof system works in polynomial time and is then scalable • In case of failure, a counter-example is generated, this counter-example permits to modify the system and do the proof • The refinement process is not polynomial time • The success and scalability of LPV depends on both the adequacy of the underlying proof concepts and the description level of the model • The linear invariants manipulated by LPV are often preserved by system complications

More Related