1 / 31

Linear Programming for Software Verification

Linear Programming for Software Verification. Model Checking Group Talk. Linear Programming for Software Verification. Dellacherie et al LPV Technology patent #97 15217 [ France Telecom, the CNRS, and the University of Caen ]. Problem Definition.

branden-blackburn
Download Presentation

Linear Programming for Software Verification

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. Linear Programming for Software Verification Model Checking Group Talk

  2. Linear Programming for Software Verification Dellacherie et al LPV Technology patent #97 15217 [ France Telecom, the CNRS, and the University of Caen ]

  3. Problem Definition • Given a software S and a property P, determine whether a path of S satisfies P. • If yes, show the path • If not, generate a proof of its non-existence.

  4. System Model and Approach • System Model: A system of automatons synchronized by a set of messages • Approach: A system of linear equations is derived from the model whereof the unknowns are related to • the status of the automatons, • the occurrence of transitions in the automatons, and • the production of synchronization messages between automatons. • These unknowns have in principle a value of 0 or 1, and • Each of these unknowns concerns an operating step among T successive steps. • The property to be verified is defined using additional linear constraints.

  5. Synchronized Automata - I A small example of synchronized automata • Each automata has a single token that can move from state to state using the transitions. • Transitions carry (possibly multiple) synchronization messages. • An automaton can go (i.e. move its token) from a state to another if and only if • there exists a transition between those two states and • all the synchronization messages present on that transition can be emitted.

  6. Synchronized Automata - II • A message can be emitted if and only if all automata that know the message(i.e. that have at least one transition carrying this message)can use simultaneously a transition carrying this message. • For example, automaton A can go from state Ae1 to state Ae2 if and only if both synchronization messages m1 and m2 can be emitted. • This is possible if, for example, automata B and C are (i.e. have their token) respectively in states Be1 and Ce1 . • In this situation, the three automata will arrive in state Ae2 , Be2 and Ce2 respectively

  7. Definition: System of Automata • A system of automata S is composed of N sub-systems Sn (1 · n · N) called automata, and of a set M = { mj,,1 · k · |M| } containing the messagesmjof S. • Every automaton Snis described by • 1. the set En= { ein ; 1 · i · |En| } of its states; • 2. the set An= { ajn; 1 · j · |An| } of itstransitions; • 3. the set ofmessagesMn½ M carried by An.

  8. Definition: Synchronization Rule • Let us call configuration a mapping C which associates to every automaton Sna unique state en2 Sncalled the activated state of Sn, and let us call syn a subset s of M. We then define the sync rule as follows: • The synchronization s has the automata system S changed from configuration C to configuration C’ if and only if 8Sn2 S, • 1. if s Å Mn= ; then C’ (Sn) = C (Sn) • If s does not share a message with Sn, then the token on Sn does not move. • 2. if s Å Mnand 9ajn = (ej1n, ej2n2An, such that Mjn= s Å Mn, then ej1n= C (Sn) andej2n= C’ (Sn) • If s does share a message with S_n, then the transition labeled with a subset of s are enabled.

  9. Definition: Synchronized Automata • A system of synchronized automata is a system of automata endowed with the (previously discussed) synchronization rule. • Accessibility Properties: The kind of requests we will check on a system of synchronized automata corresponds to the classical set of accessibility (or reachability) properties.

  10. Definition: Path Satisfiability • An accessibility property P = (C; C’) on S has a path satisfying P if and only if there exists a path in N steps going from the initial conguration C0 to a conguration C’nsuch that 8 Sn2 S, • if EnÅ C , then C0 (Sn) 2 C • if EnÅ C’ , then C’n (Sn) 2 C’

  11. Flow-Synchronized Automata • Message-flow: A message-flowis a function fmwhich associates to every message m of S a real quantity fm(m) 2[0, 1]. • Transition-flow: A transition-flowis a function fawhich associates to every transition ajnof S a real quantity fa(ajn) 2[0, 1]. • State-flow: A state-flowis a function fewhich associates to every state einof S a real quantity fe(ein) 2[0,1].

  12. Flow-Synchronization Rules - I • Amnis the set of transitions of automata Sncarrying message m: • Amn= { ajn2An / m2 Mjn } • Ei+nis the set of transitions of Snhaving einas starting state: • Ei+n= { ajn2 An / 9 e, ajn= (ein, e) } • Ei−nis the set of transitions of Snhaving einas arriving state: • Ei−n= { ajn2 An / 9 e; ajn= (e, ein) }.

  13. Flow-Synchronization Rules - II • Conservation of tokens in state-flow of automata: 8Sn, ein2 Sn fC(ein) = 1 • i.e. the quantity of token on each automaton is equal to 1 • Relation between Transition Flow and Message Flow for valid synchronization: 8m 2 M, 8Sn, Amn) fs(m) = ajn2 Amn fa(ajn) • i.e. for all automata that know m, the quantity of m emitted is equal to the flow going through the transitions carrying m.

  14. Flow Synchronization Rules - III • 1. ajn2 Ei+n fa(ajn) · fC(ein) • (i.e. the flow leaving ein is not greater than the quantity of token which is on ein), • 2. ajn2 E(i-)N fa(ajn) · fC’(ein) • (i.e. the flow arriving on ein is not greater than the total amount of token which is on ein), • 3. fC(ein)− ajn2 Ei+n fa(ajn) = fC’(ein) − ajn2 Ei−n fa(ajn) • (i.e. the new quantity of token on ein is the previous quantity plus the flow arriving on ein and less the flow leaving ein).

  15. Flow Synchronization Automata • A system of flow-synchronized automatais a system of automata endowed with the flow-synchronization rule. • Furthermore, let fCand fC’ be two flow-configurations of S. The change from fCto fC’ by flow-synchronization fsdefines a flow-step (fC, fs, fC’) for S. • A succession of flow-steps (fC0, fs0, fC’0 ), …, (fCn−1, fsn−1, fC’n) such that fC’i= fCi+1 defines a flow-pathfor S.

  16. Storied Automata • Let S be a system of automata. We consider S on T + 1 time steps as follow: for each automaton Sn2 S we associate • To every value t 2 { 0; … ; T} and every state ein, a state ein(t); • To every value t 2 { 1; … ; T} and every transition ajn = (ej1n ; ej2n ), a transition ajn(t) = (ej1n (t − 1), ej2n (t)); • To to every value t 2 {1; … ; T} and every message mk2 Majn, a message mk(t) 2 Majn(t); • To every value t 2 {1; … ; T} and every state ein, an -transition in(t) = (ein(t − 1), ein(t)). • The system thus constructed from S is called the storied system of automata ST of S on T time steps.

  17. System of Equations: L(ST,P) • Flow equations:8Sn2 S; 8 t 2 {1; … ; T}, 8 ein2 Sn, we have • ein(t − 1) = j12 Ei+n aj1n(t) + in(t) • ein(t) = j22 Ei−n aj2n(t) + in(t) • Synchronization equations: 8 Sn2 S; forall t 2 {1, … ,T}; 8 m 2 Mn, we have • m(t) = j32 Amn aj3n(t) • Property equations: 8 Sn2 S, we have ein2 Amn ein(0)=1 • If C Å En then ein2 C Å Enein (0) = 1 • If C’ Å En then ein2 C’ Å Enein (T) = 1

  18. Key Result • The solving of L(ST ;P) gives either a flow-path or a proof of the inexistence of any path of length N on a model of T stories. • If we find a flow path, it may be spurious. • If we find a proof of the inexistence of any path, we are done.

  19. Examples Analyzed - I • Telephone System: The systems is made of more than 800 automata and uses more than 2500 different synchronization messages. The state space is more than 1040wide. • The property checked was to know whether phone#2 ring while nobody ever called it ?

  20. Examples Analyzed - II • An Access Control System: On this last instance the resulting system is made of 230 automata and uses more than 2800 different synchronization messages. The state space is more than 1052 wide • The property checked was: • Can card#1, who entered building#1, enter building#2 without first getting out of building#1 ?

  21. Examples Analyzed - III • Bus Arbiter: Systems with up to 1200 cells were analyzed. The state space is then at least 10500 wide, and the computation took around one hour. • The property checked was to know whether a client could access the bus at the same time as client#1.

  22. Deeper Insights • There is a PhD thesis in German which perhapscontain the details: • [Del99b] S. Dellacherie. Vrication logicielle base sur la programmation linaire. PhD thesis, Universit de Caen, 1999. To appear. • [Dev99] S. Devulder. Un modle de preuve de logiciels fond sur la programmationlinaire. PhD thesis, Universit de Caen, 1999. To appear.

  23. US PatentOctober 15, 2002Dellacherie; Samuel (Caen, FR), Broult; Christophe (Briouze, FR), Devulder; Samuel (Saint-Contest, FR), Lambert; Jean-Luc (Amfreville, FR) • Farkas Lemma: Let A be a matrix and x and b be vectors. Then the system A x = b for some x ¸ 0 has no solution iff the system ATy ¸ 0 and bTy < 0 has a solution, where x is a vector. Fang, S.-C. and Puthenpura, S. Linear Optimization and Extensions: Theory and Algorithms. Englewood Cliffs, NJ: Prentice-Hall, p. 60, 1993.

More Related