30、Maude LTLR模型检查器：原理、实现与应用

Maude LTLR模型检查器：原理、实现与应用

1. 理论基础

给定一个LTLR公式 $\phi$，其原子命题集合为 $P$，空间动作模式集合为 $W$，一个可计算的无死锁重写理论 $R$，以及一个初始状态 $[t] E$，存在如下定理：
$R, [t]_E \models \phi \Leftrightarrow L(K {P,W}(R)[t] E \otimes B {\neg\phi}) = \varnothing$

使用标记克里普克结构（LKS）进行LTLR模型检查的成本为 $O((n + m) \cdot 2^f)$，其中 $n$ 为状态数，$m$ 为转换数，$f$ 为公式大小。如果公式中没有空间动作模式，成本则为 $O(n \cdot 2^f)$，与LTL模型检查相同。

2. Maude LTLR模型检查器概述

Maude LTLR模型检查器扩展了Maude中现有的LTL模型检查器。对于LTL公式的模型检查，若重写理论 $R$ 通过系统模块 $M$ 和初始状态 init 指定，可按以下步骤进行：
1. 定义一个新模块（如 CHECK-M ），包含模块 $M$ 和 MODEL-CHECKER 模块。
2. 声明子排序 subsort StateM < State ，其中 State 是 MODEL-CHECKER 支持签名中的排序。
3. 定义排序为 Prop 的（参数化）状态谓词的语法， Prop 是LTL公式排序 Formula 的子排序。
4. 使用运算符 |= 定义状态谓词的语义，形式如下：
plaintext ceq Statei |= p(arg i1, ..., argim) = true if Cond i .
其中 Statei 是 StateM 排序的模式， p(argi1, ..., argim) 是 Prop 排序的模式， Condi 是等式和成员关系的合取。
5. 模型检查命令 reduce modelCheck(init,formula) 返回 true 或反例。

对于LTLR公式，需要扩展模块的签名以支持空间动作模式。

3. LTLR公式的支持签名

支持签名在 LTLR-MODEL-CHECKER 系统模块中定义，包括单步证明项和空间动作模式的定义。单步证明项 $u[l(\phi)]_p$ 表示为一个三元组，由规则标签 $l$、作为单赋值集合的替换 $\phi$ 以及在位置 $p$ 有洞 [] 的上下文项 $u$ 组成。替换形式为 var1\value1 ; ... ; vark\valuek 。单步证明项的排序为 ProofTerm ，通过以下运算符定义：

op {_|_:_} : StateContext RuleName Substitution -> ProofTerm [ctor...] .

还定义了具有 ProofTerm 排序的死锁常量来表示死锁事件。

空间动作模式的排序为 Action ， Prop 和 Action 都是 Formula 的子排序。空间动作模式的语法和语义与状态命题类似，默认定义了与单步证明项部分信息相关的有用空间动作模式。例如：

subsorts ProofTerm < Action .
op {_} : RuleName -> Action .
op {_:_} : RuleName Substitution -> Action .
op {_|_} : StateContext RuleName -> Action .
op top : RuleName -> Action .
op top : RuleName Substitution -> Action .

证明项和空间动作模式之间的满足关系通过涉及运算符 |= 的等式定义：

var C : StateContext . var R : RuleName . var S S’ : Substitution .
eq {C | R : S} |= {R} = true .
eq {C | R : S ; S’} |= {R : S} = true .
eq {C | R : S ; S’} |= {C | R : S} = true .
eq {C | R : S} |= {C | R} = true .
eq {[] | R : S} |= top(R) = true .
eq {[] | R : S ; S’} |= top(R, S) = true .

用户还可以通过以下形式的（条件）等式定义自己的（参数化）空间动作模式：

ceq Prooftermi |= sp(arg i,1, ..., arg i,m) = true if Cond i .

4. 单步证明项的理论扩展

单步证明项的上下文项和替换的签名取决于给定的重写理论 $R$。对于每个重写规则 $l : q \to r$（$q$ 和 $r$ 具有排序 $B$），最大签名 $P_{\Omega}(R)$ 会逐步扩展构造函数的子签名 $\Omega$：
1. 为 $q$ 中每个变量 $x_i$ 的排序 $B_i$ 添加赋值运算符：
plaintext op \ : Qid Bi -> Assignment [ctor...] .
2. 添加一个与排序 $B$ 相关的新排序 Context$B 的洞运算符：
plaintext op [] : -> Context$B [ctor...] .
3. 为 $\Omega$ 中的每个运算符 $o : A_1 … A_m \to A$，添加一组运算符：
plaintext op o : Context$A1 A2 A3 ... Am -> Context$A [ditto] . op o : A1 Context$A2 A3 ... Am -> Context$A [ditto] . ... op o : A1 A2 A3 ... Context$Am -> Context$A [ditto] .

Context$StateM 最终应定义为 StateContext 的子排序。理论扩展可以手动定义或自动生成。

5. LTLR模型检查器的实现

LTLR模型检查器重用了现有的C++ LTL模型检查器的模块。对于基于自动机的LTLR公式验证，将事件视为状态命题，将LTLR公式转换为LTL公式，使用相同的算法生成Büchi自动机。空检查算法与LTL模型检查器相同，但同步积从标记克里普克结构构建。

标记克里普克结构是动态生成的，每个生成的状态或转换会记录两个位向量：
1. 已测试的状态命题（或事件）。
2. 在状态（或转换）中满足的状态命题（或事件）。

此外，LTL和LTLR实现都需要为每个状态额外使用三个位向量进行同步积搜索。为了优化空间，生成单步证明项时会测试所有可能的空间动作模式，并丢弃单步证明项的完整项图表示，除非需要生成带有单步证明项的反例。

6. 实验结果

通过三个LTLR模型检查案例进行实验，比较新算法与旧实现的性能。实验模型和属性包括：
1. 有界重传协议（BRP）及其第一个属性。
2. 简单的客户端 - 服务器模型及其活性属性。
3. Dekker互斥算法及其弱公平性属性。

实验结果如下表所示：
| 模型 | 旧实现（#状态/#转换） | 新实现（#状态/#转换） |
| ---- | ---- | ---- |
| BRP协议 | 283/1034 | 122/372 |
| 客户端 - 服务器 | 141/1140 | 48/272 |
| Dekker算法 | 263/586 | 152/336 |

可以看出，新算法的状态数和转换数都明显小于旧算法。

以下是新算法和旧算法在状态和转换数量上的对比流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B{选择算法}:::decision
    B -->|旧算法| C(统计状态和转换数):::process
    B -->|新算法| D(统计状态和转换数):::process
    C --> E(记录旧结果):::process
    D --> F(记录新结果):::process
    E --> G(对比结果):::process
    F --> G
    G --> H([结束]):::startend

综上所述，Maude LTLR模型检查器通过引入空间动作模式，在复杂系统的建模和验证中具有显著优势，能够简化系统描述并提高模型检查的效率。

Maude LTLR模型检查器：原理、实现与应用

7. 示例：有界重传协议（BRP）

本示例展示了如何使用LTLR模型检查器简化仅基于状态设计的复杂系统描述。有界重传协议（BRP）是交替位协议的扩展，对消息的传输次数设置了限制。以往基于状态逻辑的协议描述较为复杂，而使用LTLR可以完全消除对动作信息的状态编码，使协议规范更加简单。

7.1 协议建模

• 状态表示 ：系统状态由 Conf 排序的6元组表示： < Sender, Bool, MsgL, MsgL, Bool, Receiver > 。
• 第一个和第六个组件分别描述发送者和接收者的状态。
• 第二个和第五个组件是布尔值，用于同步。
• 第三个和第四个组件对应两个有损通道。
• 消息类型 ：消息可以是 0 、 1 、 fst （第一个数据）或 last （最后一个数据）。
• 发送者状态 ： idle （空闲）、 snd(α) （发送消息 α ）和 acc(α) （收到消息 α 的确认）。
• 接收者状态 ： wait （等待）或 rec(α) （收到消息 α ）。
• 初始状态 ： < idle, false, nil, nil, false, wait > 。

7.2 协议规则

• 客户端行为规则 ：

var S : Sender . var R : Receiver .
vars M M’ : Msg . vars K L : MsgL . vars A T : Bool .
rl [req] : < idle, A, nil, nil, false, R > => < set(fst), false, nil, nil, false, R > .
rl [snd] : < snd(M), A, K, L, T, R > => < snd(M), A, K ; M, L, T, R > .
rl [acc] : < snd(M), A, K, M’ ; L, T, R > => < M # M’, A, K, L, T, R > .
crl [loss] : < snd(M), A, K, nil, T, R > => < idle, true, K, nil, T, R > if M =/= fst .
eq M # M’ = if M == M’ then acc(M) else snd(M) fi .
eq < set(M), A, K, L, T, R > = < snd(M), A, K ; M, L, T, R > .

• 消息选择规则 ：

rl [sel] : acc(fst) => set(0) .
rl [sel] : acc(fst) => set(last) .
rl [sel] : acc(0) => set(1) .
rl [sel] : acc(0) => set(last) .
rl [sel] : acc(1) => set(0) .
rl [sel] : acc(1) => set(last) .
rl [sel] : acc(last) => idle .

• 服务器端行为规则 ：

crl [rec] : < S, false, M ; K, L, T, R > => < S, false, K, L ; M, M ? T, rec(M) > if R =/= rec(M) .
rl [ign] : < S, A, M ; K, L, T, rec(M) > => < S, A, K, L ; M, T, rec(M) > .
crl [nil] : < S, A, nil, L, T, rec(M) > => < S, A, nil, L, false, wait > if M == last or A == true .
eq M ? T = if M == fst then true else T fi .

7.3 协议属性

BRP协议应满足以下属性：
1. 请求 REQ 必须在下次请求之前有确认（ SOK 、 SNOK 或 SDNK ）。
2. RFST 指示必须在新传输开始前有 ROK 或 RNOK 指示。
3. SOK 确认必须在 ROK 指示之后。
4. RNOK 指示必须在 SNOK 或 SDNK 确认（中止）之后。

7.4 事件定义

(mod BRP-CHECK is
    protecting PROOF[BRP] .
    including LTLR-MODEL-CHECKER .
    subsort Conf < State .
    subsorts Context$Conf < StateContext .
    ops req sok snok sdnk rfst rinc rok rnok : -> Action .
    var M : Msg . var C : StateContext . var SS : Substitution .
    eq {C | ’req : SS} |= req = true .
    eq {C | ’acc : ’M \ last ; ’M’ \ last ; SS} |= sok = true .
    ceq {C | ’loss : ’M \ M ; SS} |= snok = true if M =/= last .
    eq {C | ’loss : ’M \ last ; SS} |= sdnk = true .
    eq {C | ’rec : ’M \ fst ; SS} |= rfst = true .
    ceq {C | ’rec : ’M \ M ; SS} |= rinc = true if M == 0 or M == 1 .
    eq {C | ’rec : ’M \ last ; SS} |= rok = true .
    ceq {C | ’nil : ’M \ M ; SS} |= rnok = true if M =/= last .
endm)

7.5 模型检查

通过等式抽象将系统状态集缩减为有限集后，可以对上述属性进行模型检查：

Maude> (red modelCheck(init,[](req -> O(~ req W(sok \/ snok \/ sdnk)))).)
result Bool : true
Maude> (red modelCheck(init,[](rfst -> (~ req W(rok \/ rnok)))) .)
result Bool : true
Maude> (red modelCheck(init,[](req -> (~ sok W rok))) .)
result Bool : true
Maude> (red modelCheck(init,[](req -> (~ rnok W(snok \/ sdnk)))) .)
result Bool : true

8. 相关逻辑与结论

包含空间动作模式的TLR逻辑家族被引入。除了LTLR，最通用的是TLR ，它推广了基于状态的逻辑CTL 。许多知名的基于状态的逻辑（如LTL、CTL和CTL ）和基于事件的逻辑（如Hennessy - Milner逻辑、De Nicola和Vaandrager的A - CTL ）都可以视为空间逻辑的特例。

Maude LTLR模型检查器通过引入空间动作模式，为复杂系统的建模和验证提供了强大的工具。它能够简化系统描述，减少模型的状态和转换数量，提高模型检查的效率。无论是在理论基础、实现细节还是实际应用中，都展现出了显著的优势，为系统的正确性验证提供了更有效的手段。

以下是BRP协议模型检查的流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B(定义协议规则和状态):::process
    B --> C(定义协议属性和事件):::process
    C --> D(等式抽象缩减状态集):::process
    D --> E(进行模型检查):::process
    E --> F{检查结果是否为真}:::decision
    F -->|是| G([结束，协议满足属性]):::startend
    F -->|否| H([结束，协议不满足属性]):::startend

综上所述，Maude LTLR模型检查器在系统验证领域具有重要的应用价值和发展潜力。它不仅能够提高验证效率，还能使复杂系统的描述更加简洁明了，为系统的设计和开发提供了有力的支持。