1 Reasoning with Promela Safety properties bad things do not happen can check by inspecting finite behaviours Liveness properties good things do eventually happen need to check infinite behaviours – e.g. progression Three types of reasoning in SPIN: assertions process and system invariants proctype monitor {assert (invariant)} run monitor, run process1, run process2;... validation labels temporal claims (Linear Temporal Logic)

2 Validation Labels End state labels Distinguish between valid and invalid endstates valid endstates are not just termination could be acceptable waiting state a valid endstate is one where all processes reached end of code (i.e. }) all channels are empty it is indicated by a label beginning with end e.g. end, end_1, endhere, … In SPIN you check for invalid endstates. Checking for invalid endstates (deadlock) is a SAFETY PROPERTY.

3 End state label: Example If you check the semaphores example for invalid endstates (deadlock), i.e. with chan sema = [0] of byte; proctype Semaphore() { do :: sema!p -> sema?v od } Then an error will be reported because the system will terminate but the process Semaphore will not. However, if you check the semaphores example for invalid endstates (deadlock), i.e. with chan sema = [0] of byte; proctype Semaphore() { do end :: sema!p -> sema?v od } Then no error will be reported because when the system terminates the process Semaphore will be at end..

4 Validation Labels Progress state labels Allow you to distinguish between valid and invalid execution cycles. Allow you to state that a finite sequence should not be repeated infinitely often through the concept of progress - a process should always be able to make progress. The modeller defines what constitutes progress with a progress label. progress labels: progress, progress_1, progresshere,... In SPIN you check for non-progress (i.e. you might not reach a progress label). SPIN will report an error if there is an execution that does not visit infinitely often a progress state. Checking for non-progress (livelock) is a LIVENESS PROPERTY.

5 Validation Labels Progress state label: Examples chan sema = [0] of byte; proctype Semaphore() {end: do :: sema!p -> progress: sema?v od } Check for non-progress is passed. (You will always pass progress.) proctype Loop() {byte count=1; do :: count=count+1 :: break od progress: skip } Contains a non-progress loop. Check for non-progress is not passed An error will be reported because there is a cycle where progress is never reached.

6 Validation Labels Acceptance state labels Distinguish between states that cannot be repeated infinitely often. Converse of progress. Acceptance labels: accept1, accept2, etc. In SPIN you check for acceptance cycles. SPIN will report an error if there is an execution that visits infinitely often an acceptance state. Checking for acceptance cycles is a LIVENESS PROPERTY. (Recall: LIVENESS involves consideration of infinite execution sequences.)

7 Validation Labels Acceptance state labels: Example chan sema = [0] of byte; proctype Semaphore() {end: do :: sema!p -> accept: sema?v od } Check that it is impossible to cycle through p and v infinitely often. i.e., check accept is not passed infinitely often. SPIN would report no acceptance cycles, if this semaphore is used properly.

8 Validation Labels Acceptance state labels: Example proctype Loop() {byte count=1; accept do :: (count count=count+1 :: (count==10) ->break od progress: skip } SPIN would report no acceptance cycles. SPIN would report no non-progress cycles.

9 Complexity Size of state space (worst case) is exponential in no. of processes. E.g. 10 n, for n processes. assertions & end states < progress < accept assertions & end states linear in no. of states (both CPU time and memory) progress & acceptance 2 x CPU time no additional memory

10 LTL - Linear Temporal Logic Propositional logic + temporal operators. form ::= prop | true | false | (form) | form bop form | uop form uop ::= [](always) | <> (eventually) | ! (negation) bop ::= && (conjunction) | || (disjunction) | -> (implication) | U (strong until) p U q strong iff <>q ****(implemented in SPIN) weak if []p is a possibility

11 LTL - Linear Temporal Logic Quantification When you express an LTL formula, which execution paths does it pertain to? ALL (or indeed, none). There is an implicit universal quantification for all formulae

12 LTL - Examples Invariance: []p all states arising in a computation satisfy p. E.g. [](device == on) Response: [](p -> <>q) every state satisfying p is eventually followed by one which satisfies q. E.g. [](device == off) -> <> (device == on) Precedence: [](p -> q U r) every state satisfying p is followed by a sequence in which q is satisfied and that sequence is terminated by a state in which r is satisfied. E.g. [](device == off) -> (device == off) U (event == toggle)

13 LTL A formula is interpreted with respect to a computation path and a state. Note the difference between [], <> and []<>. []p Consider computation path s0 s1 s2 s3 ….. sn sn+1 … and current state s0. p has to hold at every si. <>p Consider computation path s0 s1 s2 s3 ….. sn sn+1 …and current state s0. p has to hold at some sj, j>=0. [] <>p Consider computation path s0 s1 s2 s3 ….. sn sn+1 …and current state s0. for every state si, there is a state sj, j>=i, s.t. p holds at sj.