Automated Reasoning Model Checking with SPIN Alan Bundy Automated - - PowerPoint PPT Presentation

▶
automated reasoning model checking with spin
SMART_READER_LITE
LIVE PREVIEW

Automated Reasoning Model Checking with SPIN Alan Bundy Automated - - PowerPoint PPT Presentation

Mar 04, 2023 155 likes •346 views

Automated Reasoning Model Checking with SPIN Alan Bundy Automated Reasoning SPIN Lecture 10, page 1 Model Checking in Practice System behaviour: what is possible in our model? We will use the language Promela to specify behaviour

slide-1
SLIDE 1

Automated Reasoning Lecture 10, page 1 SPIN

Automated Reasoning Model Checking with SPIN

Alan Bundy

slide-2
SLIDE 2

Automated Reasoning Lecture 10, page 2 SPIN

Model Checking in Practice

  • System behaviour: what is possible in our model?

– We will use the language Promela to specify behaviour

  • Process Meta Language
  • Similar to C
  • Property specification: what are we checking for?

– We will use the system Spin to check properties

  • Simple Promela Interpreter
  • Command-line and graphical user interfaces (XSpin)

– Spin takes Promela specifications for the model and for properties

  • Can generate Promela property specifications from LTL
  • Generates automata from Promela code
  • Uses automata to check for language emptiness and intersection
slide-3
SLIDE 3

Automated Reasoning Lecture 10, page 3 SPIN

Processes in Promela

  • Model checking is typically used for checking

– temporal properties (such as LTL formulae) – correctness of dynamic systems

  • So processes are central to Promela:

active proctype HelloWorld () { /* process code block (this is a comment) */ printf(“hello world\n”); }

  • Processes are execution threads (not functions!)

– Within a process block, code runs in order – But different processes run in any order (interleaved) – Processes marked active are started at runtime;

  • thers can be started with the run command
slide-4
SLIDE 4

Automated Reasoning Lecture 10, page 4 SPIN

Example: Fred Shopping

active proctype BuyLemonade () { printf(“Fred is buying lemonade.\n”); } active proctype BuyMilkAndWater() { printf(“Fred is buying milk.\n”); printf(“Fred is buying water.\n”); } active[3] proctype BuyFood() { atomic { printf(“PROCESS %d\n”, _pid); printf(“Fred is buying food.\n”); } }

FredShopping

  • [N] means to start N instances
  • f a process

–

Spin sets a unique process id in _pid

  • Different processes run in any
  • rder

–

Fred buys food, then milk, then food ...

  • Processes can interleave

–

Fred buys lemonade and food between milk and water.

–

Exception: atomic blocks run as a unit

atomic block runs

without interleaving with

  • ther processes
slide-5
SLIDE 5

Automated Reasoning Lecture 10, page 5 SPIN

Example: Fred Shopping (cont)

active proctype BuyLemonade () { printf(“Fred is buying lemonade.\n”); } active proctype BuyMilkAndWater() { printf(“Fred is buying milk.\n”); printf(“Fred is buying water.\n”); } active[3] proctype BuyFood() { atomic { printf(“PROCESS %d\n”, _pid); printf(“Fred is buying food.\n”); } }

% spin FredShopping PROCESS 2 Fred is buying food. Fred is buying milk. PROCESS 4 Fred is buying food. Fred is buying lemonade. Fred is buying water. PROCESS 3 Fred is buying food.

Using Spin to simulate model

  • % spin <file>

perform random simulation (so might produce different output each time)

  • % spin -i <file>

perform interactive simulation

  • Tabs indicate the different processes

(to suppress use spin -T <file> )

slide-6
SLIDE 6

Automated Reasoning Lecture 10, page 6 SPIN

Promela Types and Variables

  • Arrays and user datatypes are also supported
  • mtypes let us declare symbolic constants for more readable code

and output (as Promela does not have string variables)

mtype = { milk, water, lemonade }; /* declaration */ mtype a_drink = milk; /* set a variable */ printm(a_drink); /* prints 'milk' */

  • Variables can be global or local to a process

Type Typical Range Sample Declaration int int y = 2; false..true 1...255

  • 231...231-1

bool bool bought_milk = true; mtype mtype a_drink;

slide-7
SLIDE 7

Automated Reasoning Lecture 10, page 7 SPIN

Promela's if Statement

  • if..fi construct can be used to control statement execution

if :: guard -> statement; :: guard -> statement; fi;

  • The guard is a boolean expression that determines which

statement will be executed

– If there is a choice, one is picked non-deterministically – If none are true, the process blocks (waits) until a guard

becomes true (e.g. if another process changes a global variable)

– The keyword else can be used as a guard that evaluates to

true iff nothing else does (i.e. if the if would block)

slide-8
SLIDE 8

Automated Reasoning Lecture 10, page 8 SPIN

Example: Fred Buying Drinks

mtype = { milk, lemonade, water }; bool bought_milk = false, bought_lemonade = false, bought_water = false; int num_drinks = 0; inline buy_item(a_drink, bought_a_drink) { (item==a_drink) -> bought_a_drink = true; } proctype perhaps_buy(mtype item) { atomic { bool bought_something = true; if :: buy_item(milk, bought_milk); :: buy_item(lemonade, bought_lemonade); :: buy_item(water, bought_water); :: true -> bought_something = false; fi; if /* output what Fred bought, if anything */ :: bought_something -> printf("FRED BOUGHT "); :: else -> printf("FRED DID NOT BUY "); fi; printm(item);printf("\n"); num_drinks++; } }

Global variables declaration

inline defines a macro

(i.e. textual substitution)

perhaps_buy is not active,

so needs to be instantiated using

run command

Non-deterministic choices are possible here

Local variables declaration

FredsDrinks

slide-9
SLIDE 9

Automated Reasoning Lecture 10, page 9 SPIN

Example: Fred Buying Drinks (II)

active proctype buy_drinks() { run perhaps_buy(milk); run perhaps_buy(lemonade); run perhaps_buy(water); if :: num_drinks==3 -> printf("FRED HAS FINISHED BUYING THINGS.\n"); fi; }

Continuing the previous example, we define one active proctype which makes Fred perhaps_buy his various drinks. Several runs are shown.

% spin -T FredsDrinks FRED BOUGHT water FRED DID NOT BUY milk FRED DID NOT BUY lemonade FRED HAS FINISHED BUYING THINGS % spin -T FredsDrinks FRED BOUGHT milk FRED BOUGHT lemonade FRED DID NOT BUY water FRED HAS FINISHED BUYING THINGS % spin -T FredsDrinks FRED DID NOT BUY water FRED BOUGHT lemonade FRED DID NOT BUY milk FRED HAS FINISHED BUYING THINGS The if clause blocks until at least one condition becomes true; here, it waits until num_drinks equals three.

FredsDrinks

slide-10
SLIDE 10

Automated Reasoning Lecture 10, page 10 SPIN

Asserting Correctness with Spin

  • We have looked at system behaviour in Promela
  • Now we look at checking desired properties with Spin
  • One way is to assert that a property is true:

assert(bought_milk);

– assert is actually a Promela statement, so where it is in

the source code will affect when it is checked

– During a simulation, Spin complains if the assertion fails – Spin can also attempt to verify that the assertion holds for

all possible runs (i.e. all choices)

– And Spin can find failing runs

slide-11
SLIDE 11

Automated Reasoning Lecture 10, page 11 SPIN

Fred's Drink Problem Revisited

Recall Fred's drink problem from lecture 2:

Fred bought milk or Fred bought lemonade. Fred bought milk or Fred bought water. Fred did not buy both water and lemonade. What did Fred buy?

To solve this with model checking, we can use the code from the previous example, with the following assertion:

assert(! ( (bought_milk || bought_lemonade) && (bought_milk || bought_water) && !(bought_lemonade && bought_water) ) );

This should be placed after he has finished buying drinks.

FredsDrinksAssert

slide-12
SLIDE 12

Automated Reasoning Lecture 10, page 12 SPIN

Fred's Drink Problem (II)

We assert the negation of the goal, so that Spin will complain about runs where the goal is true (i.e. counterexamples are our solution). The following output, giving us a possible answer, is generated if one runs Spin enough times:

% spin -T FredsDrinksAssert FRED DID NOT BUY lemonade FRED BOUGHT water FRED BOUGHT milk FRED HAS FINISHED BUYING THINGS. spin: line 70 "FredsDrinksAssert", Error: assertion violated spin: text of failed assertion: assert(!((((bought_milk|| bought_lemonade)&&(bought_milk||bought_water))&&! ((bought_lemonade&&bought_water))))) #processes: 1 bought_milk = 1 bought_lemonade = 0 bought_water = 1 num_drinks = 3 34: proc 0 (buy_drinks) line 70 "FredsDrinksAssert" (state 9) 4 processes created

slide-13
SLIDE 13

Automated Reasoning Lecture 10, page 13 SPIN

Fred's Drink Problem (III)

  • Of course we do not want to run Spin over and over again!
  • Spin can generate a verifier which checks all behaviours
  • % spin -a <file> : generate C-code pan.c of the verifier
  • Run the verifier pan to find the error trails

% spin -a FredsDrinksAssert # build a verifier: spin puts this in pan.c % cc -o pan pan.c # compile the verifier to pan % ./pan -e -c5 # run the verifier and find up to 5 errors pan: assertion violated !((((bought_milk||bought_lemonade)&& ... pan: wrote FredsDrinksAssert1.trail pan: wrote FredsDrinksAssert2.trail pan: wrote FredsDrinksAssert3.trail ... State-vector 32 byte, depth reached 19, errors: 3

slide-14
SLIDE 14

Automated Reasoning Lecture 10, page 14 SPIN

Fred's Drink Problem (IV)

  • The verifier for FredsDrinksAssert found 3 error trails
  • Run pan -rX to simulate the model along trail X

% spin -a FredsDrinksAssert # build a verifier: spin puts this in pan.c % cc -o pan pan.c # compile the verifier to pan % ./pan -e -c5 # run the verifier and find up to 5 errors pan: assertion violated !((((bought_milk||bought_lemonade)&& ... pan: wrote FredsDrinksAssert1.trail pan: wrote FredsDrinksAssert2.trail pan: wrote FredsDrinksAssert3.trail ... State-vector 32 byte, depth reached 19, errors: 3 ... % ./pan -r1 # run error trail 1 ... FRED BOUGHT milk ... ... FRED BOUGHT lemonade ... ... FRED DID NOT BUY water ... ... FRED HAS FINISHED BUYING THINGS. ...

Error trails are written to these files

slide-15
SLIDE 15

Automated Reasoning Lecture 10, page 15 SPIN

The Bigger Picture

Promela code SPIN pan.c

C-code of the verifier

C- compiler pan

the verifier

Correctness Claims Error trails

interactive simulation random simulation

  • e

error-trail simulation

  • r?
  • i
  • a
slide-16
SLIDE 16

Automated Reasoning Lecture 10, page 16 SPIN

Many Ways to Spin a Cat

  • As you explore Spin, you will find there are many

alternative ways to do what we have done here

– XSpin is a graphical user interface for Spin

(Documentation at: http://spinroot.com/spin/Man/GettingStarted.html )

– A much shorter (single-process) solution to Fred's

Drink Problem is included in FredsDrinksShort

– Next Lecture: Correctness Claims and LTL formulae

(instead of assertions)

  • Spin and Promela reference manuals can be found at:

– http://spinroot.com/spin/Man/Manual.html – http://spinroot.com/spin/Man/promela.html

slide-17
SLIDE 17

Automated Reasoning Lecture 10, page 17 SPIN

Pros of LTL Model Checking

  • Model checking technique studied is

– automatic – efficient (comparing to earlier techniques) – can check partial specifications – can produce counterexamples, which help in debugging process – practical, and increasingly used in many real-life systems in

industry (e.g. Microsoft, Intel, Lucent, etc.)

– elegant theoretical foundation (automata theory)

slide-18
SLIDE 18

Automated Reasoning Lecture 10, page 18 SPIN

Limitations of LTL model checking

  • However, it has some limitations

– state explosion problem (mentioned earlier) – only works in finite-state systems, e.g. needs to put a bound on the

number of possible processes in advance, for otherwise consider: spawn: run Proc() goto spawn

– LTL formulae can only specify properties which hold in all runs. Some

useful property such as reset: at any state in any run there is a run from that state which leads to a reset state. requires branching-time logic, such as CTL.