第5章 形式化验证1
合集下载
形式语言与自动机理论--第五章(蒋宗礼)
• CSL
– CSG、LBA。
教材及主要参考书目
1.蒋宗礼，姜守旭. 形式语言与自动机理论. 北京： 清华大学出版社，2003年 2. John E Hopcroft, Rajeev Motwani, Jeffrey D Ullman. Introduction to Automata Theory, Languages, and Computation (2nd Edition). Addison-Wesley Publishing Company, 2001 3. John E Hopcroft, Jeffrey D Ullman. Introduction to Automata Theory, Languages, and Computation. Addison-Wesley Publishing Company, 1979
f : 2
*
是正则代换，则f(L)也是 RL。 证明： 描述工具：RE。 对r中运算符的个数n施以归纳，证明f(r) 是表示f(L)的RE。
5.2 RL的封闭性
• 当n=0时，结论成立。 • 当n≢k时定理成立,即当r中运算符的个数 不大于k时：f(L(r)) = L(f®。 • 当n=k+1时，
5.1 RL的泵引理
故， δ(q0，a1a2…ak(ak+1…aj)i aj+1…am)=qm 也就是说， a1a2…ak(ak+1…aj)i aj+1…am∈L(M) u= a1a2…ak， v=ak+1…aj， w= aj+1…am uviw∈L
5.1 RL的泵引理
• 例 5-1 证明{0n1n|n≥1}不是 RL。 证明： 假设L={0n1n|n≥1} 是 RL z=0N1N 按照泵引理所述 v=0k k≥1 此时有， u=0N-k-j w=0j1N
5【中考复习】第五章：不等式(不等量关系)
二、不等式组结构和转换
1.
不等式组（结构）和意义
2.
解不等式
3.
分式不等式转换为不等式组
4.
绝对值不等式转换为不等式组
5.
不等式结构和数式结构分类
三、不等式和数量
1.
通过数量判断不等式取值范围
2.
不等式解求不等式组系数
3.
不等量关系的日常语言表达
四、中考真题（出题形式）
1、不等式的意义
● 画一个大于9面积的几何图形。
有最大值5/2，最大整数2
观察什么？
1）观察范围延伸方向；2）观察范围边界数量；
中考复习
5、代数式是否有最大最小值
通过数量范围找出这个范围内的最大(小)数量，根据不等式判断是否有最大最小值
例：a≤4，有最大值4
例：b≥5，有最小值5
例：c<4，无最大值，最大整数值3
例：d>5，无最小值，最小整数值6
方程和不等式的区别：
1、方程的解——具体的数量；不等式的解——数量范围
2、等式没有方向；不等式有方向
等式两边代数式交换，等式成立；不等式两边代数式交换，不等式不成立
例：3=(2+1) 交换正确：(2+1)=3
(2+2)＞3 交换错误：3＞(2+2)
中考复习
3x+4
≤
5
3、不等式性质（结构转换）
性质1：不等式两边同加（减）同一个代数式，不等式方向不变；
＞、≥、＜、≤
✓ 表示数量不相等的数学符号：
•
不等式的意义：
字母n表示所有大于9的数量的范围。
思维如何确定数量范围？
字母m表示所小于等于9的数量的范围。
第5章 身份认证_图文.ppt
第5章 身份认证
从安全的角度衡量，上述协议显然优于例5-1中的 认证协议。但上述认证协议中，没有说明口令在服务 器端的存放方法。如果解决不了口令的存放问题，该 协议显然不能用于大规模认证。
那么上述协议是否就安全了呢？协议的安全性衡 量是非常复杂的，这一方面需要对安全性进行精确的 定义，另一方面还要对具体协议进行理论上的证明。 很多使用多年、貌似安全的协议后来被证明是不安全 的。目前，安全协议的形式化证明方面主要有以下3 类研究方法，分别是：① 基于推理结构型方法(如 BAN逻辑)；② 基于攻击结构性方法(如模型检测)；③ 基于证明结构性方法(如串空间模型)。
IDU
RU
RS
Key MAC
Keyed Hash Function
MAC
图5-5 一个基于挑战-应答协议的口令认证方案
第5章 身份认证
在该认证协议中，口令即是key。假如用户向服务 器发出认证请求，服务器首先产生一个随机数(挑 战)RS送给用户。用户把自己的身份IDU和自己产生的 随机数RU连同RS一起作为自变量计算由Key控制的 Hash值MAC，然后把IDU、RU和MAC发给服务器(应 答)。服务器根据收到的IDU、RU和自己保留的RS重 新计算MAC，然后与收到的MAC进行比较验证。
第5章 身份认证
5.1.5 完整性校验和
认证中秘密信息的存放是有要求的，例如，在基于口令的认 证系统中，验证端不允许存储口令，只允许存储口令的完整性校 验和。
完整性校验和是由要加以保护的数据按照特定的方法计算出 来的数值。数据的完整性靠反复计算校验和来证明正确有效。如 果计算出来的数值与存储的数值相符，则说明数据没受到损害； 反之，则认为数据已经受到损害。为行之有效，校验和必定是数 据中每一位的函数。
第5章程序正确性证明
试。
测试的原则
1. 应当 “尽早地和不断地进行软件测试” 。 2. 测试用例应由测试输入数据和对应的预期输出结果 组成。
3. 程序员应避免检查自己的程序。 4. 在设计测试用例时，应当包括合理的输入条件和不 合理的输入条件。
5. 充分注意测试中的群集现象。即测试后程序中残存 的错误数目与该程序中已发现的错误数目成正比。
白盒测试
此方法把测试对象看做一个透明的盒子，它允 许测试人员利用程序内部的逻辑结构及有关信息， 设计或选择测试用例，对程序所有逻辑路径进行测 试。
通过在不同点检查程序的状态，确定实际的状 态是否与预期的状态一致。因此白盒测试又称为结 构测试或逻辑驱动测试。
白盒测试…
软件人员使用白盒测试方法，主要想对程序模块进行 如下的检查：
但这是不可能的。
假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计 算机上运行。若X、Y取整数，按黑盒方法进行穷举测试：
可能采用的测试数据组： 232×232＝264
如果测试一组数据需要1毫秒，一年工作365×24小时， 完成所有测试需5亿年。
等价类划分 边界值分析 错误推测法 因果图
…黑盒测试
9）输入三个数，其中含有0 10）输入三个数，其中含有负数 11）输入三个数，其中含有非整数值 12）输入三个均为0的数 13）输入三个均为非法字符
列出各种产生的情况来测试的方法显然是黑盒子 方法。它不关心盒子内程序的具体逻辑，只是根 据程序功能来设计测试用例
程序测试的黑盒子方法常凭经验进行，在设计 测试用例时可以综合使用上述各种方法。在设 计测试数据时，我们应该考虑认为最易出错和 最易忽略的地方，进行重点测试。
包含的不同执行路径数达520条，对每一条路径进行 测试需要1毫秒，假定一年工作365 × 24小时，要想 把所有路径测试完，需3170年。
测试的原则
1. 应当 “尽早地和不断地进行软件测试” 。 2. 测试用例应由测试输入数据和对应的预期输出结果 组成。
3. 程序员应避免检查自己的程序。 4. 在设计测试用例时，应当包括合理的输入条件和不 合理的输入条件。
5. 充分注意测试中的群集现象。即测试后程序中残存 的错误数目与该程序中已发现的错误数目成正比。
白盒测试
此方法把测试对象看做一个透明的盒子，它允 许测试人员利用程序内部的逻辑结构及有关信息， 设计或选择测试用例，对程序所有逻辑路径进行测 试。
通过在不同点检查程序的状态，确定实际的状 态是否与预期的状态一致。因此白盒测试又称为结 构测试或逻辑驱动测试。
白盒测试…
软件人员使用白盒测试方法，主要想对程序模块进行 如下的检查：
但这是不可能的。
假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计 算机上运行。若X、Y取整数，按黑盒方法进行穷举测试：
可能采用的测试数据组： 232×232＝264
如果测试一组数据需要1毫秒，一年工作365×24小时， 完成所有测试需5亿年。
等价类划分 边界值分析 错误推测法 因果图
…黑盒测试
9）输入三个数，其中含有0 10）输入三个数，其中含有负数 11）输入三个数，其中含有非整数值 12）输入三个均为0的数 13）输入三个均为非法字符
列出各种产生的情况来测试的方法显然是黑盒子 方法。它不关心盒子内程序的具体逻辑，只是根 据程序功能来设计测试用例
程序测试的黑盒子方法常凭经验进行，在设计 测试用例时可以综合使用上述各种方法。在设 计测试数据时，我们应该考虑认为最易出错和 最易忽略的地方，进行重点测试。
包含的不同执行路径数达520条，对每一条路径进行 测试需要1毫秒，假定一年工作365 × 24小时，要想 把所有路径测试完，需3170年。
第5章知识推理分析课件
CBR是指利用旧的事例或经验来解决问题，评价方案，解 释异常情况或理解新情况。
CBR基于人的这种认知过程：人们在求解新问题时，常常回 忆过去积累下来的类似情况的处理，通过对过去类似情 况处理的适当修改来解决新的问题，过去的类似情况及 其处理被用来评价新的问题及产生新的问题求解方案。
其他方法还包括基于原型的推理、基于框架的推理和 模糊推理等等。
难。
推理与知识表示方法直接相关，产生式规则表示方 法提供了最基本的推理模式。他与框架、谓词逻辑 等其他表示方法相结合，可提供功能更强、更灵活的 推理方法。
1.产生式系统的组成
产生式系统一般由三个基本部分组成：规则库、综合数 据库和推理机。它们之间的关系如下图所示。
2024/3/14 18
（1）规则库:
Then 不出交通事故（x）
正向推理示例
交通事故示例：
目标结论：李先生不出交通事故。 推理过程 (用规则的前提匹配事实)
R1: 年龄（李先生）小于等于55 and 年龄（李先 生）大于等于35 中年人（李先生） (F1:年龄＝43)
R2: 中年人（李先生） 老练（李先生） R3: 中年人（李先生） 细心（李先生） R4: 老练（李先生）and 细心（李先生）and 有
搜索和匹配是推理机的两大基本任务。对于一个 性能良好的推理机，应有如下基本要求：
(1)高效率的搜索和匹配机制； (2)可控制性； (3)可观测性； (4)启发性。
5.1.3 知识推理的类型
从方式上分，可分为演绎推理和归纳推理； 从确定性上分，可分为确定性推理和不确定性推理； 从单调性上分，可分为单调推理和非单调推理。
目标状态
（事实条件） → （结论假设）
正向推理过程是：
搜索规则（知识）库，逐条检查规则的前 提在事实库中是否存在
CBR基于人的这种认知过程：人们在求解新问题时，常常回 忆过去积累下来的类似情况的处理，通过对过去类似情 况处理的适当修改来解决新的问题，过去的类似情况及 其处理被用来评价新的问题及产生新的问题求解方案。
其他方法还包括基于原型的推理、基于框架的推理和 模糊推理等等。
难。
推理与知识表示方法直接相关，产生式规则表示方 法提供了最基本的推理模式。他与框架、谓词逻辑 等其他表示方法相结合，可提供功能更强、更灵活的 推理方法。
1.产生式系统的组成
产生式系统一般由三个基本部分组成：规则库、综合数 据库和推理机。它们之间的关系如下图所示。
2024/3/14 18
（1）规则库:
Then 不出交通事故（x）
正向推理示例
交通事故示例：
目标结论：李先生不出交通事故。 推理过程 (用规则的前提匹配事实)
R1: 年龄（李先生）小于等于55 and 年龄（李先 生）大于等于35 中年人（李先生） (F1:年龄＝43)
R2: 中年人（李先生） 老练（李先生） R3: 中年人（李先生） 细心（李先生） R4: 老练（李先生）and 细心（李先生）and 有
搜索和匹配是推理机的两大基本任务。对于一个 性能良好的推理机，应有如下基本要求：
(1)高效率的搜索和匹配机制； (2)可控制性； (3)可观测性； (4)启发性。
5.1.3 知识推理的类型
从方式上分，可分为演绎推理和归纳推理； 从确定性上分，可分为确定性推理和不确定性推理； 从单调性上分，可分为单调推理和非单调推理。
目标状态
（事实条件） → （结论假设）
正向推理过程是：
搜索规则（知识）库，逐条检查规则的前 提在事实库中是否存在
形式化方法
两个用于转换的输入函数，用由位置指向转换的 箭头表示，它们是： I(t1)=｛P2,P4｝ I(t2)=｛P2｝ 两个用于转换的输出函数，用由转换指向位置的
箭头表示，它们是：
O(t1)=｛P1｝ O(t2)=｛P3，P3｝ 注意，输出函数O(t2)中有两个P3，是因为有两个 箭头由t2指向P3。
5.3.1 基本概念 Petri网包含4种元素：一组位置P、一组转换T、 输入函数I以及输出函数O。图5.5举例说明了Petri网 的组成。 其中， 一组位置P为｛P1，P2，P3，P4｝，在图中用圆圈 代表位置。 一组转换T为｛t1，t2｝，在图中用短直线表示转 换。
图5.5 Petri网的组成
数学作为软件开发工具的最后一个优点是，它提 供了高层确认的手段。可以使用数学方法证明，设计 符合规格说明，程序代码正确地反映了设计结果。
5.1.3
应用形式化方法的准则
为了更好地发挥这种方法的长处，下面给出应用 形式化方法的几条准则，供读者在实际工作中使用。 · 选择适用于当前项目的符号系统。 · 应该形式化，但不要过分形式化。通常没有必 要对系统的每个方面都使用形式化方法。 · 应该进行成本/效益分析。 · 需要有形式化方法的顾问。
6元组，其中每个谓词都是系统全局状态Y的函数。转
换函数T现在是一个从(J-F)×K×P到J的函数。现在的 转换规则形式如下： 当前状态〔菜单〕+事件〔所选择的项〕+谓词 下个状态。
5.2.2
电梯问题
为了说明在实际工作中怎样使用形式化的方法， 现在我们用有穷状态机技术给出电梯问题的规格说明。
果t2也被激发了，则令牌从P2中移出，两个新令牌被
J是一个有穷的非空状态集；
K是一个有穷的非空输入集； T是一个从(J-F)×K到J的转换函数； S∈J，是一个初始状态； FJ，是终态集。
05.形式化开发方法(1)-Petri网
-软件工程讲义-6-
目前流行的形式化开发方法
形式化规格说明建模 形式化验证 形式化程序求精
-软件工程讲义-
-7-
形式化规格说明建模
操作类
基于状态和转移
Petri网、有限状态机和状态图
描述类
基于数学公理和概念
基于逻辑的描述方法：命题线性时态逻辑（PLTL）、 一阶线性时态逻辑（FOLTL）、计算树逻辑（CTL） 基于代数的描述方法：Z语言、VDM和Larch
-软件工程讲义-5-
形式化开发方法发展历史
20世纪60年代末
形式化方法与非形式化大致同步 都是为解决当时出现的“软件危机”提出 一般认为是Floyd、Hoare和Manna等在程序正确性证明 方面的研究。但由于这些方法受程序规模的限制而未能 应用
20世纪80年代末
在硬件设计领域形式化方法的工业应用结果，又掀起了 软件形式化开发方法的学术研究和工业应用的热潮，建 立了一些较为成熟的方法和语言 如Petri网、statecharts、通信顺序过程、通信系统演算、 程序正确性证明、时态逻辑、模型验证、Z语言、 VDM 及Larch等
结构化和OO方法
使用了大量的自然语言。自然语言的二义性、不 完整和抽象层次的混杂等问题的解决，必然使开 发系统的质量不高、成本增加和进度拖长；尤其 对安全性或其他质量因素要求极高的软件，任何 微小的错误都可能带来灾难性的后果
形式化的方法
可以帮助软件开发人员开发出更为无二义性、完 整的和准确的需求规格说明，进而通过严格的验 证发现问题，以达到对软件质量、开发成本和开 发进度的有效控制
示例-四季系统Σ Petri网的定义 Petri网的基本原理-静态结构 Petri网的基本原理-动态特征 建模实例 特性分析 Petri网的特性分析方法 改进Petri网及其应用 时间网和随机网 从Petri网到程序结构的转换
目前流行的形式化开发方法
形式化规格说明建模 形式化验证 形式化程序求精
-软件工程讲义-
-7-
形式化规格说明建模
操作类
基于状态和转移
Petri网、有限状态机和状态图
描述类
基于数学公理和概念
基于逻辑的描述方法：命题线性时态逻辑（PLTL）、 一阶线性时态逻辑（FOLTL）、计算树逻辑（CTL） 基于代数的描述方法：Z语言、VDM和Larch
-软件工程讲义-5-
形式化开发方法发展历史
20世纪60年代末
形式化方法与非形式化大致同步 都是为解决当时出现的“软件危机”提出 一般认为是Floyd、Hoare和Manna等在程序正确性证明 方面的研究。但由于这些方法受程序规模的限制而未能 应用
20世纪80年代末
在硬件设计领域形式化方法的工业应用结果，又掀起了 软件形式化开发方法的学术研究和工业应用的热潮，建 立了一些较为成熟的方法和语言 如Petri网、statecharts、通信顺序过程、通信系统演算、 程序正确性证明、时态逻辑、模型验证、Z语言、 VDM 及Larch等
结构化和OO方法
使用了大量的自然语言。自然语言的二义性、不 完整和抽象层次的混杂等问题的解决，必然使开 发系统的质量不高、成本增加和进度拖长；尤其 对安全性或其他质量因素要求极高的软件，任何 微小的错误都可能带来灾难性的后果
形式化的方法
可以帮助软件开发人员开发出更为无二义性、完 整的和准确的需求规格说明，进而通过严格的验 证发现问题，以达到对软件质量、开发成本和开 发进度的有效控制
示例-四季系统Σ Petri网的定义 Petri网的基本原理-静态结构 Petri网的基本原理-动态特征 建模实例 特性分析 Petri网的特性分析方法 改进Petri网及其应用 时间网和随机网 从Petri网到程序结构的转换
第5章程序正确性证明精品PPT课件
I(x1,x2)=> P(x1,x2,y1,y2) x1>0 ∧ x2>0 =>
x1>0∧ x2>0 ∧ y1>0 ∧y2>0 ∧ gcd(y1,y2)=gcd(x1,x2)
通路2：
P(x1,x2,y1,y2) ∧ y1<>y2 ∧ y1>y2 => P(x1,x2,y1-y2,y2) x1>0 ∧x2>0 ∧ y1>0 ∧ y2>0 ∧ gcd(y1,y2)=gcd(x1,x2) ∧ y1<>y2 ∧ y1>y2
程序正确性理论是十分活跃的课题，不仅可 以证明顺序程序的正确性，而且还可以证明非确 定性程序，以及并行程序的正确性。
程序正确性理论
程序设计的一般过程
程序正确性理论
程序功能的精确描述 1、程序规约：对程序所实现功能的精确描述，
由程序的前置断言和后置断言两部分组成。 2、前置断言：程序执行前的输入应满足的条件，
通路2：
若y1>y2, gcd(y1-y2,y2) = gcd(y1,y2) =gcd(x1,x2)
通路3:
若y2>y1, gcd(y1,y2)=gcd(y1,y2-y1) =gcd(x1,x2)
通路4:
若y1=y2,gcd(y1,y2) =gcd(x1,x2)=y1=y2=z P(x1,x2,y1,y2) ∧ y1=y2 => O(x1,x2,z)
I(x)=> P(x,0,1,1) x>0=> 0 ≤ x ∧ 1=(0+1) 2 ∧ 1=2*0+1
通路2：B->D->B
P(x,y1,y2,y3) ∧ y2≤x => p(x,y1+1,y2+y3+2,y3+2) y12≤x ∧ y2=(y1+1)2 ∧ y3 = 2y1+1 ∧ y2≤x => (y1+1) 2 ≤ x ∧
x1>0∧ x2>0 ∧ y1>0 ∧y2>0 ∧ gcd(y1,y2)=gcd(x1,x2)
通路2：
P(x1,x2,y1,y2) ∧ y1<>y2 ∧ y1>y2 => P(x1,x2,y1-y2,y2) x1>0 ∧x2>0 ∧ y1>0 ∧ y2>0 ∧ gcd(y1,y2)=gcd(x1,x2) ∧ y1<>y2 ∧ y1>y2
程序正确性理论是十分活跃的课题，不仅可 以证明顺序程序的正确性，而且还可以证明非确 定性程序，以及并行程序的正确性。
程序正确性理论
程序设计的一般过程
程序正确性理论
程序功能的精确描述 1、程序规约：对程序所实现功能的精确描述，
由程序的前置断言和后置断言两部分组成。 2、前置断言：程序执行前的输入应满足的条件，
通路2：
若y1>y2, gcd(y1-y2,y2) = gcd(y1,y2) =gcd(x1,x2)
通路3:
若y2>y1, gcd(y1,y2)=gcd(y1,y2-y1) =gcd(x1,x2)
通路4:
若y1=y2,gcd(y1,y2) =gcd(x1,x2)=y1=y2=z P(x1,x2,y1,y2) ∧ y1=y2 => O(x1,x2,z)
I(x)=> P(x,0,1,1) x>0=> 0 ≤ x ∧ 1=(0+1) 2 ∧ 1=2*0+1
通路2：B->D->B
P(x,y1,y2,y3) ∧ y2≤x => p(x,y1+1,y2+y3+2,y3+2) y12≤x ∧ y2=(y1+1)2 ∧ y3 = 2y1+1 ∧ y2≤x => (y1+1) 2 ≤ x ∧
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
107 -> 1020 states and more
A Brief History of FV
Late 80s and early 90s:
Deal with state explosion OBDD Abstraction Modularity Symmetry
A Brief History of FV
Verification:Are we building the prodict right? Validation:Are we building the right prodict?
Simulation vs. Emulation vs.Test
Simulation(模拟 performed on the model 模拟): 模拟 Emulation(仿真 performed on prototyping 仿真): 仿真 Test(测试 performed on the actual product 测试): 测试 (manufacturing test)
Safety critical systems Commercially critical systems Mission critical systems
What is verification?
Theoretically, verification means proof of correctness
Verification vs Validation
Verification: is the procees checking if the product is built correctly according to the specification. Validation: is the procees that ensures that the product meets the expectation of the user. In Boehm word:
Small tricky(技巧的) programs manually annotated and proved
A Brief History of FV
1970s: Progress in automated deduction related to program verification
1973: [Boyer Moore] Computational Lisp 1975: [Nelson Oppen] Decision procedures for combination logic theories 1976: [D Gordon ] Higher Order Logic theorem proving (LCF) 1977: [F Pnueli] introduces (linear) temporal logics(LTL) as a formalism to reason about reactive systems
Chapter 5 Formal Verification
5.1 Overview 5.2 Theorem proving 5.3 Model Checking
5.1 Overview
What is Verification? What is formal Verification Formal Verification Methods Formal Verification Process A Brief History of FV
What is formal Verification?
Formal verification means to apply mathematical arguments to prove the correctness of systems Formal means two things:
A mathematical (not English) specification An exhaustive(彻底的) verification method (not simulation)
Automatic: Model Checking Semi-automatic (deductive/theorem proving)
Practically, it mainly attempts to increase reliability:
Automated systematic debugging VERY good at finding errors!
Formal Verification Process
1. Modelling
What the system actually does Expressed as a set of predicates, or as an automaton
2.
What the system ought to do Expressed in an assertion language, e.g., boolean logic,LTL,CTL,µ-calculus,…
A Brief History of FV
1960s: [Floyd,McCarthy] Program verification
Partial vs total correctness
1970s: [Hoare, Dijkstra] Logics for programs, axiomatic semantics (connect programs to logic), logical transformations for program constructs
Determine
Can we construct a proof for S (from A) in calculus C?
What is Theorem Proving?
Logic = Syntax + Semantics + Calculus TP = Proof-search in C (Huge search problem) Correctness and completeness of Calculi are essential properties Calculus = Non-deterministic Algorithm Central problem in TP: How to implement a non-deterministic algorithm efficiently on a deterministic machine
“State Explosion”Problem
Formal Verification Process
Formal Verification process consist of three parts:
1.A framework for Formal modeling systems some kind of modeling language 2.A Formal specification language for describing the properties to be verified 3.A Formal verification method for establishing if the description of the system satisfies the specification
Formal Verification Methods
Deductive演绎verification
Automated theorem proving
Interactive verification
Semi-automated theorem proving Formal Verification
What is Verification?
Verification: verifying the correctness of products
Hardware, software, embedded control systems, network protocols, …
It is most obvious in
a formal language (or logic) L a calculus C for this language (= set of rules) a conjecture (猜想)S and a set of assumptions or axioms A in the language L
By 1990s: Basic theoretical problems worked out 1990s: Emphasis on infinite state systems
Real time systems (timed automata) Embedded systems (hybrid automata) Models with stacks, queues, …(ADT)
Difficult and time consuming
for critical applications only
Formal Verification Methods
Interactive verification Analysis reduces to proving a theorem in a logic Uses interactive theorem prover(ITP) Requires more expertise
A Brief History of FV
1981: [Clarke, Emerson and Quielle Sifakis] independently discover finite state temporal logic model checking
Applied to digital circuits
A Brief History of FV
Late 80s and early 90s:
Deal with state explosion OBDD Abstraction Modularity Symmetry
A Brief History of FV
Verification:Are we building the prodict right? Validation:Are we building the right prodict?
Simulation vs. Emulation vs.Test
Simulation(模拟 performed on the model 模拟): 模拟 Emulation(仿真 performed on prototyping 仿真): 仿真 Test(测试 performed on the actual product 测试): 测试 (manufacturing test)
Safety critical systems Commercially critical systems Mission critical systems
What is verification?
Theoretically, verification means proof of correctness
Verification vs Validation
Verification: is the procees checking if the product is built correctly according to the specification. Validation: is the procees that ensures that the product meets the expectation of the user. In Boehm word:
Small tricky(技巧的) programs manually annotated and proved
A Brief History of FV
1970s: Progress in automated deduction related to program verification
1973: [Boyer Moore] Computational Lisp 1975: [Nelson Oppen] Decision procedures for combination logic theories 1976: [D Gordon ] Higher Order Logic theorem proving (LCF) 1977: [F Pnueli] introduces (linear) temporal logics(LTL) as a formalism to reason about reactive systems
Chapter 5 Formal Verification
5.1 Overview 5.2 Theorem proving 5.3 Model Checking
5.1 Overview
What is Verification? What is formal Verification Formal Verification Methods Formal Verification Process A Brief History of FV
What is formal Verification?
Formal verification means to apply mathematical arguments to prove the correctness of systems Formal means two things:
A mathematical (not English) specification An exhaustive(彻底的) verification method (not simulation)
Automatic: Model Checking Semi-automatic (deductive/theorem proving)
Practically, it mainly attempts to increase reliability:
Automated systematic debugging VERY good at finding errors!
Formal Verification Process
1. Modelling
What the system actually does Expressed as a set of predicates, or as an automaton
2.
What the system ought to do Expressed in an assertion language, e.g., boolean logic,LTL,CTL,µ-calculus,…
A Brief History of FV
1960s: [Floyd,McCarthy] Program verification
Partial vs total correctness
1970s: [Hoare, Dijkstra] Logics for programs, axiomatic semantics (connect programs to logic), logical transformations for program constructs
Determine
Can we construct a proof for S (from A) in calculus C?
What is Theorem Proving?
Logic = Syntax + Semantics + Calculus TP = Proof-search in C (Huge search problem) Correctness and completeness of Calculi are essential properties Calculus = Non-deterministic Algorithm Central problem in TP: How to implement a non-deterministic algorithm efficiently on a deterministic machine
“State Explosion”Problem
Formal Verification Process
Formal Verification process consist of three parts:
1.A framework for Formal modeling systems some kind of modeling language 2.A Formal specification language for describing the properties to be verified 3.A Formal verification method for establishing if the description of the system satisfies the specification
Formal Verification Methods
Deductive演绎verification
Automated theorem proving
Interactive verification
Semi-automated theorem proving Formal Verification
What is Verification?
Verification: verifying the correctness of products
Hardware, software, embedded control systems, network protocols, …
It is most obvious in
a formal language (or logic) L a calculus C for this language (= set of rules) a conjecture (猜想)S and a set of assumptions or axioms A in the language L
By 1990s: Basic theoretical problems worked out 1990s: Emphasis on infinite state systems
Real time systems (timed automata) Embedded systems (hybrid automata) Models with stacks, queues, …(ADT)
Difficult and time consuming
for critical applications only
Formal Verification Methods
Interactive verification Analysis reduces to proving a theorem in a logic Uses interactive theorem prover(ITP) Requires more expertise
A Brief History of FV
1981: [Clarke, Emerson and Quielle Sifakis] independently discover finite state temporal logic model checking
Applied to digital circuits