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

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 ● Pro cess Me ta La nguage ● Similar to C ● Property specification: what are we checking for? – We will use the system Spin to check properties ● S imple P romela In terpreter ● 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 Automated Reasoning SPIN Lecture 10, page 2

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; others can be started with the run command Automated Reasoning SPIN Lecture 10, page 3

Example: Fred Shopping ● [N] means to start N instances active proctype BuyLemonade () { of a process printf(“Fred is buying lemonade.\n”); } Spin sets a unique process id – active proctype BuyMilkAndWater() { in _pid printf(“Fred is buying milk.\n”); ● Different processes run in any printf(“Fred is buying water.\n”); order } Fred buys food, then milk, active[3] proctype BuyFood() { – then food ... atomic { printf(“PROCESS %d\n”, _pid); ● Processes can interleave printf(“Fred is buying food.\n”); Fred buys lemonade and food – } } between milk and water. FredShopping Exception: atomic blocks – run as a unit atomic block runs without interleaving with other processes Automated Reasoning SPIN Lecture 10, page 4

Example: Fred Shopping (cont) Using Spin to simulate model % spin FredShopping ● % spin <file> perform random simulation (so might PROCESS 2 produce different output each time) Fred is buying food. Fred is buying milk. ● % spin -i <file> PROCESS 4 perform interactive simulation Fred is buying food. Fred is buying lemonade. active proctype BuyLemonade () { Fred is buying water. printf(“Fred is buying lemonade.\n”); PROCESS 3 } Fred is buying food. active proctype BuyMilkAndWater() { printf(“Fred is buying milk.\n”); printf(“Fred is buying water.\n”); } ● Tabs indicate the different processes active[3] proctype BuyFood() { atomic { (to suppress use spin -T <file> ) printf(“PROCESS %d\n”, _pid); printf(“Fred is buying food.\n”); } } Automated Reasoning SPIN Lecture 10, page 5

Promela Types and Variables Type Typical Range Sample Declaration -2 31 ...2 31 -1 int int y = 2; bool false..true bool bought_milk = true; mtype 1...255 mtype a_drink; Arrays and user datatypes are also supported ● mtype s 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 ● Automated Reasoning SPIN Lecture 10, page 6

Promela's if Statement ● i f..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) Automated Reasoning SPIN Lecture 10, page 7

Example: Fred Buying Drinks mtype = { milk, lemonade, water }; bool bought_milk = false, Global variables declaration bought_lemonade = false, bought_water = false; int num_drinks = 0; inline defines a macro inline buy_item (a_drink, bought_a_drink) { (i.e. textual substitution) ( item ==a_drink) -> bought_a_drink = true; } perhaps_buy is not active , proctype perhaps_buy (mtype item ) { so needs to be instantiated using atomic { run command bool bought_something = true; if :: buy_item(milk, bought_milk); Local variables declaration :: buy_item(lemonade, bought_lemonade); :: buy_item(water, bought_water); :: true -> bought_something = false; Non-deterministic choices are fi; possible here 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++; } } FredsDrinks Automated Reasoning SPIN Lecture 10, page 8

Example: Fred Buying Drinks (II) Continuing the previous example, we define one active proctype which makes Fred perhaps_buy his various drinks. % spin -T FredsDrinks Several runs are shown. FRED DID NOT BUY water FRED BOUGHT lemonade active proctype buy_drinks() { FRED DID NOT BUY milk run perhaps_buy(milk); FRED HAS FINISHED BUYING THINGS run perhaps_buy(lemonade); run perhaps_buy(water); % spin -T FredsDrinks if FRED BOUGHT milk :: num_drinks==3 -> FRED BOUGHT lemonade printf("FRED HAS FINISHED BUYING THINGS.\n"); FRED DID NOT BUY water fi; FRED HAS FINISHED BUYING THINGS } FredsDrinks % spin -T FredsDrinks The if clause blocks until at least one FRED BOUGHT water condition becomes true; here, it waits FRED DID NOT BUY milk until num_drinks equals three. FRED DID NOT BUY lemonade FRED HAS FINISHED BUYING THINGS Automated Reasoning SPIN Lecture 10, page 9

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 Automated Reasoning SPIN Lecture 10, page 10

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) ) ); FredsDrinksAssert This should be placed after he has finished buying drinks. Automated Reasoning SPIN Lecture 10, page 11

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 Automated Reasoning SPIN Lecture 10, page 12

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 Automated Reasoning SPIN Lecture 10, page 13

Fred's Drink Problem (IV) % 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 Error trails pan: wrote FredsDrinksAssert3.trail are written to ... these files 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. ... ● The verifier for FredsDrinksAssert found 3 error trails ● Run pan -r X to simulate the model along trail X Automated Reasoning SPIN Lecture 10, page 14