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.

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

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

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

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 P2 P3 P4 P5 MEM

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: 1.If a line status is INVALID, the line is not present in this cache 2.If a line status is SHARED, the line is present in a read-only mode 3.If a line status is EXCLUSIVE, the line is present for read-write access There are three key memory operations 1.Read-shared: get a shared copy of the line 2.Read-modified: get an exclusive copy of the line 3.Write-back: give up the exclusive copy

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 #]

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 *

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

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

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

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

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?

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)

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.

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

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)

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?

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

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

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

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

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!! ;)

PVS and transition systems –2 The SCR method consists of state machines that interact with their environment by periodically sampling the values of monitored variables (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

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)

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.

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

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 #]

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

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)

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

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

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

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

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]

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?

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)

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.

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 !