CS1950Y Lecture 17: Model Checking
March 14, 2018
Last class, we modeled a two traffic light intersection in Alloy. As a refresher, below is the state diagram for our intersection. The first character in each node represents the color of light 1 (R for red, Y for yellow and G for green), the second character represents the color of light 2, and the third character which light's turn it is.
Using Alloy, we we easily able to determine that our model prevented a variety of unsafe states from ever occurring (for example, G,G,1 and Y,G,2, both of which could cause automobile collisions). However, just demonstrating that we can't reach unsafe states is not enough; to make a model of an intersection viable, we also need a way to verify that at any given point, each of the lights will eventually be green. That is, the east-west traffic should always eventually be able to move, and so should the north-south traffic.
Today, we'll start exploring a new class of tools intended to handle this type of temporal verification. These tools work directly with the state machine related to a particular problem, and use depth-first search to traverse the state space in order to verify the properties we want to check. This process is called explicit state model checking.
The explicit state model checker we'll be using is called TLA+, which stands for the Temporal Logic of Actions (plus some other stuff!). In the TLA+ sense, an action is an edge in state space, a way that we move from one state to a possible next state.
Today's code is a version of our two light intersection, modeled in TLA+ rather than in Alloy. You may find the following pieces of syntax and their associated semantics useful when rereading the spec:
- /\ : logical and
- \/ : logical or
- v' : the post-transition value of variable v
- UNCHANGED v : indicates that the value of variable v should stay the same across a state transition -- syntactic sugar for v' = v
- [] : usually read as "always," ensures that the following formula holds in every state
- <> : usually read as "eventually," ensures that the following formula holds in some future state
Just for a moment, we'll leave TLA+ aside and hop back to Alloy. A quick note that may be helpful for your final projects: if you find that your unsatisfiable spec is taking a long time to run, avoid using the Minisat solver. This solver is best for generating unsat cores, and does some otherwise unnecessary file IO that can substantially increase runtime. If you don't need the core, you can save time by switching to another underlying solver!