Understanding an Error Trail from Spin Modelchecker

Question

I am trying to use Spin Model Checker to modelcheck a Game between two objects (A and B). The objects move on a board, and each location is defined by its (x,y) coordinates. The two objects are supposed to not collide. I have three processes: init, A Model, B Model. I am model checking an ltl property: (liveness property to check if the two objects ever occupy same location)

ltl prop1 { [] (!(x_a == x_b) && !(y_a == y_b)) }

The error trail that I get is: init -> A Model -> B Model -> init

However, I should not get an error trail (counterexample) based on the data that is shown: x_a=2, x_b=1, y_a=1, y_b=1.

Also the first init does go through all the lines of init process, but the second one only shows to the last line of it.

Also my A Model and B Model only consist of guards and actions in a 'do' block as shown below. However they are more complex and have if blocks on the right of '->'

active proctype AModel(){
do
:: someValue == 1 -> go North
:: someValue == 2 -> go South
:: someValue == 3 -> go East
:: someValue == 4 -> go West
:: else -> skip;
od
}

Do I need to put anything in an atomic block? The reason I am asking is that the line that the error trail is showing does not even go into the 'do' block, and it is just the first line of the two models.

EDIT: The LTL property was wrong. I changed that to:

ltl prop1 { [] (!((x_a == x_b) && (y_a == y_b))) }

However, I am still getting the exact same error trail.

Answer 1

Your LTL property is wrongly implemented. Essentially, the counter example that SPIN found is a true counter example for the LTL as stated.

[] ( !(x_a == x_b) && !(y_z == y_b) )   =>
[] ( !(2 == 1) && !(1 == 1) )  =>
[] ( !0 && !1) =>
[] ( 1 && 0)   =>
[] 0  =>
false

The LTL should be:

always not (same location) =>
[] (! ((x_a == x_b) && (y_a == y_b))) =>
[] (! ((2 == 1) && (1 == 1))) =>
[] (! (0 && 1) =>
[] (! 0) =>
[] 1 =>
true

Regarding your init and tasks. When starting your tasks you want to be sure that initialization is complete before the tasks run. I'll use one of two approaches:

init { ... atomic { run taskA(); run taskB() } where tasks are spawned once all initialization is complete`

or

bool init_complete = false;
init { ...;  init_complete = true }
proctype taskA () { /* init local stuff */ ...; init-complete -> /* begin real works */ ... }

Your LTL may be failing during the initialization.

And based on your problem, if you ever change x or y you'd better change both at once in an atomic{}.