Abstract model checking

Abstraction Model checking is for systems where an actual representation is too complex and and a state space explosion will result in developing the model alone. So, the design undergoes a kind of translation to scaled down "abstract" version.
The set of variables are partitioned into visible and invisible depending on their change of values. The real state space is summarized into a smaller set of the visible ones.

Galois connected

The real and the abstract state spaces are galois connected which means that if we take an element from the abstract space, concretize it and abstract the concretized version, the result will be equal to the original. On the other hand, if you pick an element from the real space, abstract it and concretize the abstract version, the final result will be a super set of the original.
That is,

$\eta$($\theta$(abstract)) = abstract
$\theta$($\eta$(real)) $\supset$ real

Abstraction refinement loop

A problem with abstraction model checking is that although the abstraction simulates the real, when the abstraction does not satisfy a property, it does not mean that this property actually fails in the real model. Counter examples are checked against the real state space because we obtain "spurious" counter examples. So a part of the abstraction refinement loop is-
1. Obtain the abstract model
2. Model check and see if everything is ok.
3. If there is a counter example, then go back to the real state space and find out if it actually a counter model.
4. If not, return and continue model checking.

References

• Edmund M. Clarke and Orna Grumberg and David E. Long (1992). "Model checking and abstraction". ACM Transactions on Programming Languages and Systems. 16 (5): 1512--1542.

This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.