1 / 39

Theorem Proving

Theorem Proving. One of the problems with model checking based methods is that they can be applied only to finite state systems. However, reasoning about infinite state systems is equally important and methods must be developed which enable a modeller to ”attack the infinite”.

olaf
Download Presentation

Theorem Proving

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. Theorem Proving • One of the problems with model checking based methods is that they can be applied only to finite state systems. • However, reasoning about infinite state systems is equally important and methods must be developed which enable a modeller to ”attack the infinite”. • However, the combined use of theorem proving and model checking is justified because they examine ALL BEHAVIOURS rather than simulation which do only a partial check. • The biggest problem with theorem proving is its steep learning curve. It takes about 6 months to master a good automated theorem prover as PVS.

  2. Theorem Proving - Definition • Theorem proving could be defined as follows (Rushby 99) “Specify the system, a required property, the assumptions, and necessary background theories as formulas in a single logic. Prove that background + assumptions + system is a model of the property. “ • Theorem Proving works best on data intensive systems

  3. Theorem Proving compared with Model Checking (from Rushby 99) • When theorem proving is used, the system is not restricted to finite-state (or even to a transition system)!! • The required property is not restricted to invariance or eventuality properties that can be expressed in Computation Tree Logic (CTL) • The assumptions are not restricted to fairness assumptions, but rather, they can be arbitrary theories • However, with the increased freedom in logics and theories comes less automation and more involved human involvement in proofs

  4. PVS Briefly • PVS is a verification system. It provides a general purpose specification language integrated with a theorem prover, model checker and other tools • PVS can be obtained free of charge for non-commercial purposes from SRI (URL = http://www.csl.sri.com/pvs.html) • PVS runs on SunOS, Solaris, IBM AIX, and Linux • PVS has been applied in several areas: safety-critical systems, hardware, distributed algorithms, and mathematics • The use of PVS is best illustrated through an example that follows

  5. Cache Coherency protocol (Futurebus+) (Rushby 99) • A multiprocessor system consists of several processes and a shared memory • Each process maintains a local cache of the memory, and the state of this copy changes as memory is being written to, etc. • Each change made by any processor must be reflected in other processors’ cache as well to maintain the notion of coherency P1 P5 P2 P4 P3 MEM

  6. Cache Coherency - 2 • The memory is organized into lines and for the purposes of this study, it is sufficient to consider the status changes of only a single line • Each line has a status in a processor’s cache: • If a line status is INVALID, the line is not present in this cache • If a line status is SHARED, the line is present in a read-only mode • If a line status is EXCLUSIVE, the line is present for read-write access • There are three key memory operations • Read-shared: get a shared copy of the line • Read-modified: get an exclusive copy of the line • Write-back: give up the exclusive copy

  7. Cache Coherency - 3 • For the protocol to be correct, we should show that at most one processor has an exclusive copy of a single line in its cache cache_array[N : posnat]: THEORY BEGIN processor : TYPE = below(N) line_status: TYPE = {invalid, shared, exclusive} transactions: TYPE = {idle, read_shared, read_modified, write_back} protocol_state : TYPE = [# cache : [processor -> line_status], transaction : transactions, bus_master : processor #]

  8. Cache Coherency - 4 ps, ps0, ps1: VAR protocol_state p_next(ps0, ps1): bool = LET p = bus_master(ps0), t = transaction(ps0) IN (idle?(t) AND do_idle(ps0, ps1)) OR (read_shared?(t) AND do_read_shared(ps0, ps1)(p)) OR (read_modified?(t) AND do_read_modified(ps0, ps1)(p)) OR (write_back?(t) AND do_write_back(ps0, ps1)(p)) do_idle(ps0, ps1): bool = (ps1 = ps0) ** The Bus Master is the process that initiated the current event on the bus *

  9. Cache Coherency - 5 p, q, r: VAR processor do_read_shared(ps0, ps1)(p): bool = invalid?(cache(ps0)(p)) AND shared?(cache(ps1)(p)) AND ((EXISTS q: exclusive?(cache(ps0)(q)) AND NOT exlusive?(cache(ps1)(q)) AND (FORALL r: r/=q IMPLIES exclusive?(cache(ps1)(r )) = exclusive?(cache(ps0)(r )))) OR (FORALL q: NOT exclusive?(cache(ps0)(q)) AND NOT exclusive?(cache(ps1)(q)))) ** This transition allows reading of a line in memory when no one has an exclusive copy of the line in its cache

  10. Cache Coherency - 6 do_read_modified(ps0, ps1)(p): bool = shared?(cache(ps0)(p)) AND (FORALL q: cache(ps1)(q) = IF p = q THEN exclusive ELSIF shared?(cache(ps0)(q)) THEN invalid ELSE cache(ps0)(q) ENDIF) ** This transition makes the bus master exclusive, and invalidates all those processes who had a read access to the memory line

  11. Cache Coherency - 7 do_write_back(ps0, ps1)(p): bool = exclusive?(cache(ps0)(p)) AND cache(ps1) = cache(ps0) WITH [(p) := invalid] ** This function shows how the exclusive right is given up by the bus master

  12. Initial State and Invariant assertions • The next task is to identify the initial states and the alleged properties we want to verify. p_init(ps): bool = FORALL p: invalid?(cache(ps)(p)) p_safe(ps): bool = FORALL p, q; exclusive?(cache(ps)(p)) AND exclusive?(cache(ps)(q)) IMPLIES p = q invariant: THEOREM (p_init(ps) IMPLIES p_safe(ps)) AND (p_safe(ps0) AND p_next(ps0, ps1) IMPLIES p_safe(ps1))

  13. What does theorem proving look like? • Now, the only thing to do is to actually prove our initial conjecture or come up with a counterexample. This is what the theorem prover PVS looks like in action invariant: |----------- {1} (FORALL (ps, ps0, ps1: protocol_state): (p_init(ps) IMPLIES p_safe(ps)) AND (p_safe(ps0) AND p_next(ps0, ps1) IMPLIES p_safe(ps1))) Rule?

  14. PVS in action - 1 • When the above goal is simplified with (skosimp) and (ground) which stand for skolemization and simplifying and propositional simplification, respectively, we get the following output: This yields 2 subgoals: invariant.1: {-1} p_init(ps!1) |--------- {1} p_safe(ps!1) Rule? This branch of the proof is discharged with the strategy (grind)

  15. PVS in action - 2 • We continue with our proof and get the following This completes the proof of invariant.1 {-1} p_safe(ps0!1) {-2} p_next(ps0!1, ps1!1) |--------- {1} p_safe(ps1!1) Rule? Now the applications of (expand “p_next”) and (ground) are used to divide the above problem to four cases.

  16. PVS in action - 3 Applying propositional simplification and decision procedures this yields 4 subgoals: invariant 2.1: {-1} idle?(transaction(ps0!1)) {-2} do_idle(ps0!1, ps1!1) [-3] p_safe(ps0!1) |-------- [1] p_safe(ps1!1) Rule? • The above goal is proved by the (grind) strategy

  17. PVS in action - 4 • Similarly, the last invariant can be proved as follows: invariant.2.4: {-1} write_back?(transaction(ps0!1)) {-2} do_write_back(ps0!1, ps1!1)(bus_master(ps0!1)) [-3] p_safe(ps0!1) |---------- [1] p_safe(ps1!1) Rule? • This is proved by using the strategy (grind :if-match all)

  18. PVS in action - 5 invariant.2.2: {-1} read_shared?(transaction(ps0!1)) {-2} do_read_shared(ps0!1, ps1!1)(bus_master(ps0!1)) [-3] p_safe(ps0!1) |------------ [1] p_safe(ps1!1) Rule?

  19. PVS in action - 6 • The previous theorem is proven by the following interactive proof: (grind :if-match NIL) ((“1” (inst –8 “q!2”) (assert) (inst –9 “q!1”) (assert) (inst –9 “q!2”) (assert)) (“2” (inst –6 “p!1”) (assert)))

  20. PVS in action -7 invariant.2.3: {-1} read_modified?(transaction(ps0!1)) {-2} do_read_modified(ps0!1, ps1!1) (bus_master(ps0!1)) [-3] p_safe(ps1!1) |---------- [1] p_safe(ps1!1) Rule? • This proof is once again started with (grind :if-match NIL) but we run into a difficulty that we can’t solve

  21. PVS in action - 8 {-1} q!1 < N {-2} p!1 < N [-3] read_modified?(transaction(ps0!1)) {-4} shared?(cache(ps0!1)(bus_master(ps0!1))) {-5} FORALL (q: processor): cache (ps1!1) (q) = IF bus_master(ps0!1) = q THEN exclusive ELSIF shared?(cache(ps0!1)(q)) THEN invalid ELSE cache(ps0!1)(q) ENDIF {-6} FORALL (p: processor): exclusive?(cache(ps0!1)(p)) IMPLIES FORALL (q: processor): exclusive?(cache(ps0!1)(q)) IMPLIES p=q {-7} exclusive?(cache(ps1!1)(p!1)) {-8} exclusive?(cache(ps1!1)(q!1)) |----------------- {1} p!1 = q!1

  22. PVS in action - 9 • The problem with the previous slide is that our specification doesn’t say anything about a situation where a read_modified transaction is executed when someone is already in exclusive state • However, this is in effect impossible, but to show it formally, we need to strengthen our safety invariant as follows: If any processor has exclusive status, all the others must be invalid strong_p_safe(ps): bool = FORALL p: exclusive?(cache(ps)(p)) IMPLIES FORALL q: q/=p IMPLIES invalid?(cache(ps)(q)) strong_invariant: THEOREM (p_init(ps) IMPLIES strong_p_safe(ps)) AND (strong_p_safe(ps0) AND p_next(ps0, ps1) IMPLIES strong_p_safe(ps1))

  23. PVS and transition systems • One of the most powerful, yet easy to grasp ideas in theoretical computer science is that of transition systems • PVS has been adapted in such a way that it can handle the specification of transition systems as TABLES • The example we will consider here relates to a car’s cruise control system. Grab your seat and have fun!! ;)

  24. PVS and transition systems –2 • The SCR method consists of state machines that interact with their environment by periodically sampling the values of monitoredvariables (i.e. inputs) and producing controlled variables (i.e. outputs). • The state of an individual state machine is a mode • Condition is a predicate on monitored variables (I.e. inputs) • Event occurs when a monitored variable changes its value

  25. PVS and transition systems - 3 scr[ input, mode, output: TYPE ]: THEORY BEGIN condition: TYPE = pred[input] event: TYPE = pred[[input, input]] state: TYPE = [# mode: mode, vars: input #] transition_relation: TYPE = pred[[state, state]] mode_table: TYPE = [mode, input, input -> mode] (notice that the new mode is specified as the function of the previous mode and the previous and the current inputs)

  26. PVS and transition systems - 4 trans (mt: mode_table): transition_relation = (LAMBDA (s, t: state): mode(t) = mt(mode(s), vars(s), vars(t))) ** the above definition constructs the transition relation from the mode table output_table: TYPE = [mode, input, input -> output] ** the output table is constructed also from the previous mode and the previous and current inputs.

  27. PVS and transition systems - 5 The next task is to define what event constructors are event_constructor: TYPE = [condition -> event] EC: TYPE = event_constructor p, q: VAR input P: VAR condition atT(P)(p, q): bool = NOT P(p) & P(q) atF(P)(p, q): bool = P(p) & NOT P(q) T(P)(p, q): bool = P(p) & P(q) F(P)(p, q): bool = NOT P(p) & NOT P(q) dc(P)(p, q): bool = true

  28. PVS and transition systems - 6 • The previous stuff was all preamble to the problem at hand. Here’s the definition of the car cruise control system cruise: THEORY BEGIN lever_pos: TYPE = {activate, deactivate, resume} engine_state: TYPE = {off, ignition, running} monitored_vars: TYPE = [# engine: engine_state, toofast: bool, brake: bool, lever: lever_pos #]

  29. PVS and transition systems - 7 modes: TYPE = { off, inactive, cruise, override } null: TYPE IMPORTING scr[ monitored_vars, modes, null] ** next we must start to define the conditions accordingly activate:condition= LAMBDA (m:monitored_vars): activate?(lever(m)) resume: condition= LAMBDA (m:monitored_vars): resume?(lever(m)) running:condition= LAMBDA (m: monitored_vars): running?(engine(m)) Ignited:condition= LAMBDA (m:monitored_vars): ignition?(engine(m)) OR running?(engine(m))

  30. PVS and transition systems - 8 brake: condition = LAMBDA (m: monitored_vars): brake(m) toofast:condition = LAMBDA (m: monitored_vars): toofast(m) Then we will describe the rows of the table. To do that, we must define the notion of PC or pairwise conjunction. It is defined as a collection of functions that each take a list of event constructors and a list of conditions and conjoins their pairwise applications. PC(A)(a)(p, q): bool = A(a)(p, q) PC(A, B)(a, b)(p, q): bool = A(a)(p,q) & B(b)(p, q) … PC(A, B, C, D, E, FF, G)(a, b, c, d, e, f, g)(p, q): bool = A(a)(p, q) & B(b)(p, q) & … & G(g)(p, q)

  31. PVS and transition systems - 9 original(s: modes, (p, q: monitored_vars)): modes = LET x: conds7 = (ignited, running, toofast, brake, activate, deactivate, resume), X = (LAMBDA (a,b,c,d,e,f,g: EC): PC(a,b,c,d,e,f,g)(x)(p, q)) IN TABLE s |off| TABLE %-----|-----|-----|-----|-----|-----|-----|------|--------------|| |X( atT, dc, dc, dc, dc, dc, dc) | inactive || %-----|-----|-----|-----|-----|-----|-----|------|--------------|| | ELSE | off || %-----|------------------------------------------|--------------|| ENDTABLE ||

  32. PVS and transition systems – 10 |inactive| TABLE %-----|-----|-----|-----|-----|-----|-----|------|--------------|| |X( atF , dc , dc , dc , dc , dc , dc) | off || %-----|-----|-----|-----|-----|-----|-----|------|--------------|| |X( T , T , dc , F , atT , dc , dc) | cruise || %-----|-----|-----|-----|-----|-----|-----|------|--------------|| | ELSE | inactive || %------|------------------------------------------|--------------|| ENDTABLE

  33. PVS and transition systems - 11 |cruise| TABLE %-----|-----|-----|-----|-----|-----|-----|------|--------------|| |X( atF , dc , dc , dc , dc , dc , dc) | off || %-----|-----|-----|-----|-----|-----|-----|------|--------------|| |X( dc , atF , dc , dc , dc , dc , dc) | inactive || %-----|-----|-----|-----|-----|-----|-----|------|--------------|| |X( dc , dc , atT, dc , dc , dc , dc) | inactive || %-----|-----|-----|-----|-----|-----|-----|------|--------------|| |X( dc , dc , dc , atT, dc , dc , dc) | override || %-----|-----|-----|-----|-----|-----|-----|------|--------------|| |X( dc , dc , dc , dc , dc , atT , dc) | override || %-----|-----|-----|-----|-----|-----|-----|------|--------------|| | ELSE | cruise || %------|------------------------------------------|--------------|| ENDTABLE ||

  34. PVS and transition systems - 12 |override| TABLE %-----|-----|-----|-----|-----|-----|-----|------|--------------|| |X( atF , dc , dc , dc , dc , dc , dc) | off || %-----|-----|-----|-----|-----|-----|-----|------|--------------|| |X( dc , atF , dc , dc , dc , dc , dc) | inactive || %-----|-----|-----|-----|-----|-----|-----|------|--------------|| |X( T , T , dc , F , atT, dc , dc) | cruise || %-----|-----|-----|-----|-----|-----|-----|------|--------------|| |X( T , T , dc , F , dc , dc , atT) | cruise || %-----|-----|-----|-----|-----|-----|-----|------|--------------|| | ELSE | override || %------|------------------------------------------|--------------|| ENDTABLE ||

  35. PVS and transition systems - 13 ** One more definition needed for the example to run is conds1:type = [condition] conds2:type = [condition, condition] … conds7:type = [condition, condition, condition, condition, condition, condition, condition]

  36. PVS and transition systems - 14 • When we typecheck the above description, a number of TCCs (Type Correctness Conditions) are generated and each one must be discharged by the theorem prover • However, our table as is does not exhibit completely deterministic behaviour. We get the following sequent in proof: Trying repeated skolemization, instantiation, and if-lifting this yields 8 subgoals: original_TCC2.1 : {-1} cruise?(s!1) {-2} toofast(q!1) {-3} deactivate?(lever(q!1)) |---------- {1} toofast(p!1) {2} deactivate?(lever(p!1)) Rule?

  37. PVS and transition systems - 15 • The problem on the last slide was that in cruise state the eventuality that toofast and deactivate both go from FALSE to TRUE is ambiguous • In the spec, the first causes a transition to inactive mode, and the second one a transition to override mode. • The problem is circumvented when we add the condition that toofast be FALSE when a transition from cruise to override mode are taken • Also, the transition to inactive need to be conditioned on ignited staying TRUE. • We should also use the axiom engine_prop: AXIOM toofast(p) => running(p)

  38. PVS and transition systems - 16 • Once these changes are made, the TCCs may be proven by (then (grind)(lemma “engine_prop”)(grind :if-match all)) • Once the TCCs have been discharged by PVS, we know that our resulting table is deterministic. • 16 slides to say this simple thing !! ? !! I take the blame, alright.

  39. Conclusion • Theorem proving is much more labour intensive than model checking • However, theorem proving provides the verification engineer with a way to attack the infinite by e.g. induction axioms and all theorems from set theory, and natural numbers. • I warmly suggest that you take a look at the web pages of PVS and start to learn it while you study. You never know, after a couple of years, people who can do theorem proving might be the hottest studs in the job market !

More Related