CS195Y Lecture 19

4/4/16

Model Checking

Very useful for modeling hardware and concurrent systems. Moving away from academic tools like Alloy to model checking tools, which are actually used by companies like Amazon.

Canonical Model Checking Problem: Traffic Light

System: a four way intersection with a traffic light. No pedestrians, no pressure sensors, no turn lights
Properties:

• If one is green or yellow, then the other is red.
• Cycles from Green -> Yellow -> Red -> Green …
• Progress ? What does progress mean?
  • Timer?
  • Cars get through the light eventually
• Alternation between the two lights
• Light doesn’t need to turn green if there is no car waiting. This will be on a homework assignment later, so we’ll ignore it for now

Q: How is progress different from the other properties?
What would a counterexample to each of the properties look like?
A: For the first one, it could be a state where one light is green and the other is yellow. Progress won’t have a counterexample in a finite amount of time. You need an infinite length counterexample to show that the light will never turn green.

Let’s try to model this system in Alloy
Instead of ordering states, we’re going to have another sig called Time and order that. This allows us to have cycles between states.

open util/ordering[Time]

sig Time {
    turn : one Light
}
abstract sig Color {}
one sig Red, Yellow, Green extends Color {}
abstract sig Light {
    myColor: Time -> one Color
}
one sig Light1, Light2 extends Light {}
fact initState {
    Light1.myColor[first] = Red
    Light2.myColor[first] = Red
    first.turn = Light1 // optional
}
fact traces {
    all t: Time - last |
        let other  = Light - t.turn | {
            t.turn.myColor[t] = Red => {
                t.turn.myColor[t.next] = Green
                other.myColor[t.next] = Red
                t.turn = t.next.turn
            }
            t.turn.myColor[t] = Green => {
                t.turn.myColor[t.next] = Yellow
                other.myColor[t.next] = Red
                t.turn = t.next.turn
            }
            t.turn.myColor[t] = Yellow => {
                t.turn.myColor[t.next] = Red
                other.myColor[t.next] = Red
                other = t.next.turn
            }
        }
}

assert alwaysOneRed {
    all t : Time | some l : Light | l.myColor[t] = Red
}
assert alwaysTurnGreen {
    all l : Light | all t : Time |
        l.myColor[t] = Red implies {
            some t' : t.^next | l.myColor[t'] = Green
        }
}

Q: What do we mean by turn?
A: We’re hardcoding the alternation between the lights into the model, so turn describes which light is going to turn green next
Q: How many possible states are there?
A: 18. There are three possible colors for each light and two options for whose turn it is for each light configuration. You can then do a search over the state space to see if bad states are ever reachable.

There is only one instance for this model, because it is completely deterministic. The event tells you exactly how to step through the states and alternate the lights.
Now let’s try to model the properties we discussed previously
alwaysOneRed is pretty straightforward. It’s a lot like the other kinds of assertions we’ve done in Alloy so far.
alwaysTurnGreen is actually impossible to correctly check in Alloy. As we discussed before, a counterexample to this would have to be an infinite trace. And Alloy can only give you a finite trace. This inevitably causes a counterexample because from the last state, the light does not turn Green.
You can re-do this model without time and allowing for states to cycle, then you could actually show this property.