Title: Theorem Proving
1Theorem 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.
2Theorem 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
3Theorem 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
4PVS 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
5Cache 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
P3
P4
MEM
6Cache 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 processors 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
7Cache 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_arrayN 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 -gt line_status,
- transaction transactions,
- bus_master processor
8Cache 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
9Cache 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(ps
0)(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
10Cache 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
11Cache 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
12Initial 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))
13What 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?
14PVS 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)
15PVS 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.
16PVS 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
17PVS 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)
18PVS 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?
19PVS 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)))
20PVS 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 cant solve
21PVS in action - 8
- -1 q!1 lt N
- -2 p!1 lt 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 pq
- -7 exclusive?(cache(ps1!1)(p!1))
- -8 exclusive?(cache(ps1!1)(q!1))
- -----------------
- 1 p!1 q!1
22PVS in action - 9
- The problem with the previous slide is that our
specification doesnt 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))
23PVS 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
cars cruise control system. Grab your seat and
have fun!! )
24PVS 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
25PVS and transition systems - 3
- scr input, mode, output TYPE THEORY
- BEGIN
- condition TYPE predinput
- event TYPE predinput, input
- state TYPE mode mode, vars input
- transition_relation TYPE predstate,
state - mode_table TYPE mode, input, input -gt
mode - (notice that the new mode is
specified as the function of the previous - mode and the previous and the
current inputs)
26PVS 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 -gt
output - the output table is constructed also from the
previous mode and the previous and current inputs.
27PVS and transition systems - 5
- The next task is to define what event
constructors are - event_constructor TYPE condition -gt
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
28PVS and transition systems - 6
- The previous stuff was all preamble to the
problem at hand. Heres 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 -
29PVS 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 - activatecondition LAMBDA (mmonitored_vars)
activate?(lever(m)) - resume condition LAMBDA (mmonitored_vars)
resume?(lever(m)) - runningcondition LAMBDA (m monitored_vars)
running?(engine(m)) - Ignitedcondition LAMBDA (mmonitored_vars)
-
ignition?(engine(m)) OR running?(engine(m))
30PVS and transition systems - 8
- brake condition LAMBDA (m
monitored_vars) brake(m) - toofastcondition 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)
31PVS 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
-
32PVS 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
33PVS 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
34PVS 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
35PVS and transition systems - 13
- One more definition needed for the example to
run is - conds1type condition
- conds2type condition, condition
-
- conds7type condition, condition,
condition, condition, condition, - condition,
condition -
36PVS 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?
37PVS 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) gt running(p)
38PVS 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.
39Conclusion
- 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 !