《Principles of Model Checking》Charpter 1 System Verification

Charpter 1 System Verification （系统验证)

The reliability of ICT systems is a key issue
in the system design process. --ICT系统的可靠性是系统设计过程中的一个关键问题。

1.0 Hard- and Software Verification

系统验证技术正以更可靠的方式应用于ICT系统的设计。本规范规定了系统必须做什么和不做什么，因此构成了任何验证活动的基础。一旦系统不满足规范属性之一，就会发现缺陷。只要系统满足从其规范中获得的所有特性，则认为该系统是“正确的”。因此，正确性总是相对于规范，而不是系统的绝对属性。

Software Verification ：Peer reviewing and testing are the major software verification
techniques used in practice. – 软件验证同行评审和测试是实践中使用的主要软件验证技术。同行评审相当于由软件工程师团队进行的软件检查，该团队最好没有参与正在评审的软件的开发。实证研究表明，同行评审提供了一种有效的技术，可以发现31%到93%的缺陷，中位数约为60%。由于其静态性质，经验表明，使用同行审查很难发现并发性和算法缺陷等细微错误。

​ 软件测试是任何软件工程项目的重要组成部分。软件项目总成本的30%到50%用于测试。与同行评审相反，同行评审静态分析代码而不执行代码，测试是一种动态技术，实际上运行软件。测试需要考虑的软件，并为其编译代码提供输入，称为测试。因此，正确性是通过强制软件遍历一组执行路径、代表软件运行的代码语句序列来确定的。根据测试执行期间的观察结果，将软件的实际输出与系统规范中记录的输出进行比较。虽然测试生成和测试执行可以部分自动化，但比较通常由人执行。测试的主要优点是，它可以应用于各种软件，从应用软件（如电子商务软件）到编译器和操作系统。由于对所有执行路径进行彻底测试实际上是不可行的；实际上，只处理这些路径中的一小部分。因此，测试永远不可能完成。也就是说，测试只能显示错误的存在，而不是错误的缺失。测试的另一个问题是确定何时停止。实际上，很难指示测试强度以达到某个缺陷密度，即每行未注释代码中的缺陷比例，这几乎是不可能的。

​ 大约50%的缺陷是在编程期间引入的，而编程是实际编码发生的阶段。虽然在初始设计阶段仅检测到15%的错误，但大多数错误是在测试期间发现的。单元测试旨在发现组成系统的各个软件模块中的缺陷，在单元测试开始时，每1000行（未注释）代码中约有20个缺陷的缺陷密度是典型的。在系统测试开始时，每1000个代码行中大约有6个缺陷，其中测试了构成真实产品的一组模块。在发布新的软件版本时，通常公认的软件缺陷密度约为每1000行代码中有一个缺陷1。

​ 错误通常集中在几个软件模块中——大约一半的模块没有缺陷，大约80%的缺陷出现在一小部分（约20%）的模块中——并且通常在连接模块时发生。在测试之前检测到的错误的修复可以相当经济地完成。当缺陷仅在系统运行期间被证明时，修复成本从单元测试中的约1000美元（每次错误修复）显著增加到最高约12500美元。寻求在软件设计过程中尽早发现缺陷的技术至关重要：修复缺陷的成本大大降低，它们对其他设计的影响较小。

​ Hardware Verification --防止硬件设计错误的硬件验证至关重要。硬件制造成本高；交付给客户后很难修复缺陷，而且质量期望很高。

·Hardware verification techniques. Emulation, simulation, and structural analysis are the
major techniques used in hardware verification. -仿真、模拟和结构分析是硬件验证中使用的主要技术。

结构分析包括几种具体技术，如合成、时序分析和等价性检查，此处不再详细描述。

仿真是一种测试。配置可重构通用硬件系统（仿真器），使其行为类似于所考虑的电路，然后进行广泛测试。与软件测试一样，仿真相当于向电路提供一组刺激，并将生成的输出与芯片规范中规定的预期输出进行比较。为了全面测试电路，应检查每个可能系统状态下的所有可能输入组合。这是不切实际的，需要显著减少测试数量，从而产生潜在的未发现错误。

模拟是最流行的硬件验证技术，用于各个设计阶段，例如寄存器传输级、栅极和晶体管级。除了这些错误检测技术外，还需要进行硬件测试，以发现制造过程中由布局缺陷引起的制造故障

1.1 Model Checking

​ 在复杂系统的软件和硬件设计中，验证比构建花费的时间和精力更多。寻求减少和简化验证工作的技术，同时增加其覆盖范围。形式化方法具有很大的潜力，可以在设计过程中实现验证的早期集成，提供更有效的验证技术，并缩短验证时间。

​ 模型检查是一种验证技术，以蛮力方式探索所有可能的系统状态。与检查可能移动的计算机象棋程序类似，执行模型检查的软件工具模型检查器以系统的方式检查所有可能的系统场景。通过这种方式，可以证明给定的系统模型确实满足某个属性。研究可用当前方法处理的最大可能状态空间是一个真正的挑战，即处理器和内存。最先进的模型检查器可以通过显式状态空间枚举处理大约108到109个状态的状态空间。使用巧妙的算法和定制的数据结构，可以为特定问题处理更大的状态空间（1020到10476个状态）。即使是使用仿真、测试和仿真尚未发现的细微错误，也可能通过模型检查来发现

系统模型通常是根据模型描述自动生成的，该模型描述是用一些适当的编程语言（如C或Java）或硬件描述语言（如Verilog或VHDL）指定的。注意，属性规范规定了系统应该做什么和不应该做什么，而模型描述描述了系统的行为。模型检查器检查所有相关的系统状态，以检查它们是否满足所需的特性。如果遇到违反正在考虑的属性的状态，模型检查器将提供一个反例，指示模型如何达到不想要的状态。反例描述了从初始系统状态到违反正在验证的属性的状态的执行路径。在模拟器的帮助下，用户可以回放违规场景，通过这种方式获得有用的调试信息，并相应地调整模型（或属性）（见图1.4）。

模型检查已成功应用于多个ICT系统及其应用。

例如，在线航空公司预订系统中检测到死锁，现代电子商务协议得到验证，对家用电器内部通信的国际IEEE标准的几项研究导致了系统规范的显著改进。在深空1号航天器控制器的执行模块中发现了五个以前未发现的错误（见图1.5），其中一个发现了重大设计缺陷。在距离地球9600万公里的飞行实验中，一个与模型检查发现的错误相同的错误逃脱了测试，并导致了死锁。在荷兰，模型检查发现，保护鹿特丹主要港口免受洪水侵袭的风暴潮屏障的控制软件存在一些严重的设计缺陷。

示例1.1。并发性和原子性大多数错误，例如深空一号航天器中暴露的错误，都与经典并发错误有关。进程之间不可预见的交叉可能会导致意外事件的发生。这可以通过分析以下并发程序来说明，其中Inc、Dec、an和Reset三个进程相互协作。它们对共享整数变量x进行操作，该变量具有可访问（即读取）的任意初始值，并且

x的值是否始终在（包括）0和200之间？乍一看，这似乎是真的。然而，更彻底的检查表明，情况并非如此。假设x等于200。过程Dec测试x的值，并通过测试，因为x超过0。然后，通过过程重置接管控制。它测试x的值，通过测试，并立即将x重置为零。然后，控制返回到过程Dec，该过程将x减1，导致x为负值（即-1）。直觉上，我们倾向于将x上的测试和对x的分配解释为原子执行，即作为单个步骤，而实际上（大部分）并非如此。

1.2 Characteristics of Model Checking

Model checking is an automated technique that, given a finite-state model of a system and a formal property, systematically checks whether this property holds for (a given state in) that model.

模型检查是一种自动化技术，在给定系统的有限状态模型和形式属性的情况下，系统地检查该属性是否适用于该模型（中的给定状态）。

1.2.1 The Model-Checking Process

• Modeling phase:
– model the system under consideration using the model description language of
the model checker at hand;
– as a first sanity check and quick assessment of the model perform some simu-
lations;
– formalize the property to be checked using the property specification language.
• Running phase: run the model checker to check the validity of the property in the
system model.
• Analysis phase:
– property satisfied? → check next property (if any);
– property violated? →

1. analyze generated counterexample by simulation;
2. refine the model, design, or property;
3. repeat the entire procedure.
   – out of memory? → try to reduce the model and try again.

建模： 系统模型以准确、明确的方式描述系统的行为。它们大多使用有限状态自动机表示，由有限状态集和一组转换组成。状态包括关于变量的当前值、先前执行的语句（例如，程序计数器）等的信息。

运行模型检查器： 首先必须通过适当设置可用于执行穷举验证的各种选项和指令来初始化模型检查器。随后，进行实际模型检查。这基本上是一种单独的算法方法，其中在系统模型的所有状态下检查所考虑的属性的有效性。

分析结果： 基本上有三种可能的结果：指定的属性在给定的模型中是否有效，或者模型太大，无法满足计算机内存的物理限制。

验证组织：整个模型检查过程应组织良好、结构良好、计划周密。模型检查的工业应用证明，版本和配置管理的使用具有特别的相关性。例如，在验证过程中，对系统的不同部分进行了不同的模型描述，提供了各种版本的验证模型（例如，由于抽象），并提供了大量的验证参数（例如，模型检查选项）和结果（诊断跟踪、统计）。为了管理实际的模型检查过程，并允许复制所进行的实验，需要非常仔细地记录和维护这些信息

1.2.2 Strengths and Weaknesses

模型检查的优点：

•它是一种通用的验证方法，适用于广泛的应用，如嵌入式系统、软件工程和硬件设计。

•它支持部分验证，即可以单独检查属性，从而允许首先关注基本属性。不需要完整的需求规范。

•不易暴露错误的可能性；这与旨在跟踪最可能的缺陷的测试和模拟形成对比。

•在属性失效时提供诊断信息；这对于调试非常有用

•它是一种潜在的“按钮”技术；使用模型检查既不需要高度的用户交互，也不需要高度的专业知识。

•行业对它的兴趣迅速增加；一些硬件公司已经开始了他们的内部验证实验室，在模型检查方面具有所需技能的工作机会经常出现，商业模型检查已经可用。

•它可以很容易地集成到现有的开发周期中；它的学习曲线不是很陡，实证研究表明，它可能会缩短开发时间。

•它有健全的数学基础；它基于图形算法、数据结构和逻辑理论。

模型检查的缺点：

•它主要适用于控制密集型应用程序，不太适用于数据密集型应用程序，因为数据通常分布在无限域上。

•其适用性取决于可判定性问题；对于无限状态系统，或关于抽象数据类型的推理（需要不可判定或半可判定逻辑），模型检查通常不可有效计算。

•它验证系统模型，而不是实际系统（产品或原型）本身；因此，任何获得的结果都与系统模型一样好。需要补充技术，如测试，以发现制造故障（硬件）或编码错误（软件）。

•它只检查规定的要求，即不保证完整性。无法判断未检查属性的有效性。

•它面临状态空间爆炸问题，即准确建模系统所需的状态数可能很容易超过可用的计算机内存量。尽管开发了几种非常有效的方法来解决这个问题（见第7章和第8章），但现实系统的模型可能仍然太大，无法放入内存。

•它的使用需要一些专业知识来寻找适当的抽象，以获得较小的系统模型，并以使用的逻辑形式表示属性。

•不能保证产生正确的结果：与任何工具一样，模型检查器可能包含软件缺陷。2.

•它不允许检查泛化：通常，无法处理具有任意数量组件或参数化系统的检查系统。然而，模型检查可以建议使用证明助手验证的任意参数的结果。

Model checking is an effective technique to expose potential design errors.