Logic NuSMV通过了错误的规范

我是NuSMV和CTL的新手，尝试过一些简单的例子。我有3个状态A、B和C，并且有一个从A到B的转换

我在NuSMV中对其进行了建模，并希望检查是否存在从B到A的任何执行路径。尽管我没有定义这种转换，但规范给出了反例

Module main
VAR
state:{a,b};
ASSIGN
init(state):=a;
next(state):=b;
SPEC !EF(state=a -> state=c)
SPEC !EF(state=b -> state=a)

有谁知道这有什么问题吗

如何编写“A是否可从B访问？”的规范-这应该返回false，因为没有定义转换

注意：您的代码示例未在我的机器上运行，它报告了一些语法错误，因此我实际上已将其更改为如下所示：

MODULE main ()
VAR
  state : {a,b,c};

ASSIGN
  init(state):=a;
  next(state):=b;

---

对您的方法发表评论。 属性

SPEC！EF（state=a->state=c）

可以理解为：

并非存在从初始状态开始的路径，使得逻辑条件

state=a->state=c

迟早是

true

对于所有状态，条件

state=a->state=c

为

true

，例如

state！=仅限a

，因为不存在条件

state=a

和

state=c

可以同时保持的状态

如果运行NuSMV，将显示以下反例：

NuSMV > reset; read_model -i test.smv; go; check_property
-- specification !(EF (state = a -> state = c))  is false
-- as demonstrated by the following execution sequence
Trace Description: CTL Counterexample 
Trace Type: Counterexample 
-> State: 1.1 <-
  state = a
-> State: 1.2 <-
  state = b

内容如下：

对于从所有初始状态开始的所有执行路径之后可以达到的所有状态，CTL属性

state=a->AX state！=c

始终经过验证。这样的属性表示，如果在当前状态下

状态=a

，那么必然是在所有可能的紧接下的状态中

状态的值与
c
不同的情况

如果我们与NuSMV一起检查该属性，我们会发现该属性已得到验证：

NuSMV > reset; read_model -i test.smv; go; check_property
-- specification AG (state = a -> AX state != c)  is true

NuSMV > reset; read_model -i test.smv; go; check_property
-- specification AG (state = a -> AX (AG state != c))  is true

类似的示例适用于要编码的其他属性


路径可达性。如果要检查是否不存在由任意数量的中间转换形成的路径，该路径从
state=a
保持的状态开始，达到
state=c
保持的状态，则编码略有不同：

SPEC AG (state = a -> AX AG state != c)

内容如下：

对于从所有初始状态开始的所有执行路径之后可以达到的所有状态，CTL属性
state=a->AX AG state！=c
始终经过验证。对于所有州
s'
s.t.，此类属性均为
true


状态！=
s'中的a


或


s'
中的
state=a
，以及
state！=c
用于所有可到达状态
s'
在所有从
s'开始的传出路径上

如果我们使用NuSMV检查该属性，我们发现它已得到验证：

NuSMV > reset; read_model -i test.smv; go; check_property
-- specification AG (state = a -> AX state != c)  is true

NuSMV > reset; read_model -i test.smv; go; check_property
-- specification AG (state = a -> AX (AG state != c))  is true


为了更好地描述这两种编码之间的差异，我将在这里放一个模型示例，其中第一个属性是
false
，而第二个属性是
true
：

MODULE main ()
VAR
  state : {a,b,c};

ASSIGN
  init(state):=a;
  next(state) := case
     state = a : b;
     state = b : c;
     TRUE : state;
    esac;

SPEC AG (state = a -> AX state != c)
SPEC AG (state = a -> AX AG state != c)

如果在此示例上运行NuSMV，则输出如下：

NuSMV > reset; read_model -i test.smv; go; check_property
-- specification AG (state = a -> AX state != c)  is true
-- specification AG (state = a -> AX (AG state != c))  is false
-- as demonstrated by the following execution sequence
Trace Description: CTL Counterexample 
Trace Type: Counterexample 
-> State: 1.1 <-
  state = a
-> State: 1.2 <-
  state = b
-> State: 1.3 <-
  state = c


预计到达时间：

在这个用例场景中，属性

SPEC AG (state = a -> AX AG state != c)

可以简化为

SPEC AG (state = a -> AG state != c)

而且，很显然，它仍然有效

然而，我没有这样做是有原因的：这两种编码之间存在细微的语义差异，即使在某些情况下可以使用后一种编码来验证可达性属性，但前一种编码更健壮，因为它更接近可达性问题的实际语义例如只要
B_COND_2:=，模板
B_COND_1->AG B_COND_2
就会失败！B_COND_1
，因为对于验证前提的任何状态
B_COND_1
结论
agb_COND_2
——可以重写为
AG！B_COND_1
——不可能保持；在结论前面加上
AX
，增加了一级间接寻址，这更为正确，因为应该只要求从执行树中的下一个状态开始保留结论


预计到达时间第2天：

你写道：

如何编写“A是否可以从B访问？”的规范-这应该返回false，因为没有定义转换

当没有从
state=b
到
state=A
的路径时，返回
false
的属性如下：

SPEC AG (state = b -> EF state = a)

如果您想验证从
state=b
访问
state=a
的情况永远不会发生，那么这实际上是一个坏主意，原因有二：


如果验证了属性，则不会返回执行跟踪s.t.的见证计数器示例。
state=a
可从
state=b
访问，因此您可以自行确定模型上出现这种情况的原因

如果属性为
false
，则该工具需要列出从
state=b
开始的所有路径（可能是指数数量），以便无法访问
state=a


由于这些原因，我实际上以另一种方式对可达性问题进行了编码，当从
state=b
无法访问
state=a
时返回
true
，否则返回
false
+单个反例