Model checking模型检测应用于实际系统或者实际软件中的瓶颈、挑战

Model checking顾名思义是基于模型的一种形式验证方法，总的来说。模型检测是一种对有限状态空间穷尽遍历的方法。

作为一种形式验证方法，与约束求解相比，最大的优势在于自动化程度高（私以为这是它能获得图灵奖的重要原因）。而这种自动化程度来源于可以提供一套通用的方法，设计并实现一套完整的工具，从而便于使用者不需要太多的人工干预，就能利用工具进行验证。除此之外，与软件测试方法相比，它可以提供正确性证明或不存在错误的结论，弥补测试方法只能发现错误的不足。针对一些安全攸关的领域，这种代价高的方法还是很有意义的。

 

那么，模型检测在实际系统或实际软件中的瓶颈或者挑战到底是什么呢？

 

私以为主要集中在两个方面：模型构建和状态空间爆炸。

什么是模型构建问题呢？简单来说，就是怎么得到模型检测需要的模型和规约。

现有的成熟模型检测工具的输入主要是模型和规约，那么应用这些工具的主要问题就是怎么得到这个模型和规约。

传统的模型是Krinke结构或者LTS，但是这种模型很难与实际系统或者实际软件有直接的映射关系。

而传统的规约是CTL或者LTL，但是这种逻辑公式也难以与实际需要的规约关联起来。

所以解决了这个问题，采用现有的模型检测工具就可以基本解决怎么用的问题了。

目前针对软件的模型检测工具，能够将程序作为输入，在工具内将其转换成需要验证的模型，基本不需要人工干预。而针对的公式呢，则是一些容易理解的安全性等问题。私以为很复杂的性质或者规约转换成逻辑公式还是很难的。

至于状态空间爆炸问题就比较好理解了，其实就是内存、时间等现实问题的限制，没有办法处理过特别特别特别大规模的状态空间。

以16G内存空间为例，假如一个状态的空间是4个字节（相当于一个指针在32位的空间），大概能存10的9次方个状态。而一个大型实际系统的状态数远远超这个数字。

针对这个问题的也有很多了，从状态存储的角度来看，有符号模型检测方法（私以为是一个时间换空间的方法），但是这个方法在很久之前就能出了10的120次方的状态空间了；从约简状态数的角度来看，有针对系统的偏序约简、对称约简方法，也有针对软件的谓词抽象、懒惰抽象方法；从遍历或者搜索算法的角度来看，效果最好的就是on the fly思想的应用，但是结果为真的问题仍然无法解决。

 

任何方法或者技术都有利有弊，怎么发挥它自身最大的优势，怎么应用到实际系统或软件中也还是一件值得做的事儿吧（但是还是挺难的）。

（以上仅代表个人看法。）