一个模式互斥性检查的实例

1 背景

在控制系统、任务管理系统等设计中，系统行为往往依赖系统当前的模式（或状态）。在系统设计时，会给出系统模式的判定逻辑。系统模式应是互斥的，也即不允许在同一时刻超过一个模式被判定为真。

当系统模式的判定逻辑较为复杂，尤其包含了时序关系时，模式之间是否满足互斥，靠人工检查很难得出可靠的结果。如果在系统设计时不能保证互斥性，则将导致设计缺陷，可能要到系统测试甚至运营时才会暴露。

本文讨论一个模式互斥检查的实例。该实例与具体应用场景不相关，但以类似的方式可以应用于飞行阶段等场景的互斥性检查。

2 实例

一组描述模式切换的需求如下：

Req01：当事件P发生后，系统应进入M1模式，并在接下来至少5s内保持不变；

Req02：当alt大于等于200且小于1000， wow为False且持续时间至少200s时，发生事件Q；

Req03：当事件Q发生后，系统必须在1s到2s内切换到M2模式；

Req04：M1、M2不能同时成立；

上述需求与具体场景无关，为使其具有代表性，包含了多种时序关系，以及事件、状态逻辑。其中，Req04是一条安全性需求，要求M1、M2模式互斥，也是本例的检查对象。

3 需求结构化

为了能够进行自动化需求检查，需对上述自然语言需求进行结构化转换，如下图。

图1 结构化需求图

分析需求之间的依赖关系，获得如下图所示的检查构型。

图2 需求关联关系图

4 互斥性检查

对上述结构化需求进行互斥性检查，结果如下。

由检查结果可见，模式互斥属性不满足，并给出了一个反例。按照时间约束进行激励信号设置，即可到达目标状态。

在这种耦合了时序关系的需求逻辑中，要通过人工检查发现存在的缺陷是非常伤脑筋的事。这种活应该交给机器去干。

5 飞行阶段互斥性检查

飞行阶段（Flight phase）是飞机状态的一部分，对许多机载应用至关重要。基本飞行阶段包括滑行、起飞、巡航、进近、着陆等，根据具体应用不同会进一步扩展或细分。

飞行阶段基于飞机内部数据，依据设计的逻辑进行计算。飞行阶段应满足互斥性。

按照本文所示方式对飞行阶段判定逻辑进行结构化，即可进行互斥性检查。飞行阶段的计算逻辑显然相比本文实例要复杂的多，但是检查模式是一致的。这恰恰体现了机器自动检查的优点。在检查能力范围内，自动化检查能够更好的适应逻辑复杂性的增加，并且能够对给定属性进行完全、彻底的检查。

6 总结

本文给出了一个模式互斥性检查的实例。对于复杂需求，相比于人工审查，自动化需求检查能够更有效的在逻辑迷雾中发现隐藏的缺陷。