2022-4-29 初步验证AutoTap无法解决Action Breaking

本文链接：https://blog.csdn.net/q1uTruth/article/details/124408600

Abstract

AutoTap原句是“AutoTap currently does not consider issues like actions failing to complete or not taking effect immediately”，就是说他没有考虑Action Breaking和extended action。在按照他的思路去一步步推演的过程中，会存在一些细节论文里不清楚，导致无法完整复现。为了尽量克服这个，我在验证过程中每个点都有原文的推理依据，做到可能有不足但是大致是完整的。
AutoTap针对正常的可以进行，主要是看针对extended相关的是否可行。经过初步实验，AutoTap虽然说没考虑Action Breaking，却有 My smart lights should stay on for at least 30 seconds each time 这样简单的Action Breaking（我猜想是只考虑了没执行够时间而不是action breaking，只是恰好也可以满足action breaking），AutoTap没给出除了这个property以外的Action Breaking property，这是AutoTap没研究的一个依据。AutoTap虽然看似引入了timer要解决extended action，给出的例子却又在解决在一个time period内就能完成的sustained action。这给我一种解决了又没解决的感觉。而且，AutoTap的方法具有普适性，是因为对TAP规则的修复，难免会涉及分析冲突前的状态和冲突后的状态，这类似AutoTap分析bridge前和bridge后的状态。这种特点让类似方法很容易像AutoTap。

一、将安全属性转化为LTL形式

一段话总结一、，剩下的内容不用看，跳到二、。

AutoTap和TAPInspector有几个不同：∅的LTL形式，timer的设置，@event。Action Breaking对应Event-Event Conditional这种安全属性模板。用自然语言描述是The fan should never be off within its running time（e.g. 900 seconds） after it is on under the alarm state，其对应的LTL语句是¬F(running time#fan on under the alarm state ⋀ X(@fan.off))

下面内容不用看，跳到二、。

理解原文如何time modeling

event e happened within the past t (seconds), denoted as t#e 这个说的是 event
ap has been true for at least t (seconds), denoted as t ∗ ap 这个说的是 state
如果t#e timer>0，该state就和t#e有关，t ∗ ap初始化为-1，如果t ∗ ap timer = 0说明已经保持了t秒
tick用于引导timer每次-1秒

在理解time modeling基础上，对表格难点的理解

在这里插入图片描述
@event代表下一状态的transition，所以

event e happened within the past t (seconds)”, denoted as t#e只要是发生过一次就行，可以一次也可以一直发生？
G(@event2 → (time#event2W@event1))如果无event2为true，如果有event2且后续无event1发生，则会违背W中的G(∅)造成不满足
与TAPInspector不同，AutoTAP在e has just occurred和ap has just appeared就把timer置为t，TAPInspector是在下一状态，AutoTAP用clock引导timer的递减过程。所以G(@event2 → (time#event2W@event1))，@event2时timer = t，time#event2时timer>0，然后下一状态event1 & timer=0，0这个node无关了，1->0的这个trasition却有关
¬F(time#event2 ∧ X@event1) 的意思是不能在time#event2期间出现next为@event1。event1发生的情况是X(@event1) & timer = 1、event1 & timer=0，所以特殊情况timer=1下,如果timer = 1 & X(@event1)，就是event1发生，这违背了∅的event1不发生
在这里插入图片描述

选择fan对应的表格中的安全属性类型

∅要按照它的定义，两条和时间有关的One-State Duration，Event-Event Conditional，时间状态是state，fan.off是event也可以是state，并且是conditional，所以 state-state conditional、Event-State Conditional也相关
c) One-State Duration: “My smart lights should stay on for at least 30 seconds each time.”
e) State-State Conditional : “The stove should always be off if no one is home.”
The [window] should always be closed when [weather] is raining”. It corresponds to an LTL formula G(weather.raining → window.closed).
f) Event-State Conditional : “My smart window should never be opened while the AC is on.”
g) Event-Event Conditional : “My smart door lock should always lock after I come in.”
One-State Duration 是单状态，所以不是.State-State Conditional、Event-State Conditional是将timer的每个取值都看作state的一部分，虽然状态机里是这样，但是上层理解没有Event-Event Conditional好

State-State Conditional: The fan should always be on when alarm is sirening（实际情况是when alarm siren时的计时时间内）
Event-State Conditional: The fan should should never be off when alarm is sirening
Event-Event Conditional: The fan should never be off within its running time（e.g. 900 seconds） after it is on under the alarm state（风扇在警报报警情况下打开后的运行时间（如15分钟）内，不应该关闭）
所以选择Event-Event Conditional

将fan的安全属性转为LTL形式

∅是¬F(running time#fan on under the alarm state ⋀ X(@fan.off)) ，验证冲突存在用的¬∅是F(running time#fan on under the alarm state ⋀ X(@fan.off))

在状态机里time#fan on under the alarm state对应的timer是delay，只要当前state node有delay这个属性且delay>0，就代表time#fan on under the alarm state，但是这个time又恰好是running time而不是类似等待的time，所以实际意义是runinfan.timer，也是匹配到我们的代码中的。所以∅是¬F(runinfan61.timer > 0 ⋀ X(@fan.off)) ，验证冲突存在用的¬∅是F(runinfan61.timer > 0 ⋀ X(@fan.off))

二、对Action Breaking用一遍AutoTap的方法

Step1 将设备描述、TAP规则、∅转为自动机

1.1 fan.smv的状态机带TAP规则的A(fan)

Rule1:If wet,then fan on一段时间后关闭
Rule2:If alarm siren,then fan on一段时间后关闭

Device selection
选∅中涉及的设备，之后根据包含该设备的TAP规则中，如果位于trigger，选action中涉及的设备；如果位于action，选trigger中涉及的设备
Device Selection只选以下变量，由于timer属于t#event，所以初始值为0而不是-1

    waterSensor:{dry,wet};
    alarm: {off,siren};
    fan: {off,on};
    fan.watertimer: 0..600;
    fan.alarmtimer: 0..900;

A(fan)如下
在这里插入图片描述

1.2 A(¬∅)

¬∅是F(fan.alarmtimer > 0 ⋀ X(@fan.off))，冲突点基本都会在尽头循环
用 Spot 的简单模式生成 F(tiemr.positive & X(fan.off)) 对应的自动机
在这里插入图片描述

1.3 A = A(fan) + A(¬∅)

在这里插入图片描述

Step2 Patching the Automaton

2.1 初步patch

用“IF e1 WHILE AP1 THEN e2”的方法,初步修复为：
If (@fan.off & @clock -1) while (water.wet&alarm.siren&fan.on&fan.watertimer=1&fan.alarmtimer=601) , then (@fan.on & @clock -1)

从nusmv输出的反例路径中，可以得到上述的之前的AP和e
在这里插入图片描述

2.2 Refine Patch

一句话概括refine：

对于修复rule要在bridge处触发而不在其它地方误触，现有rule不在bridge处触发而在其它地方触发，这就要求修复rule的trigger比AP弱，越弱越会走到bridge处，同时要修复rule的trigger event和现有rule的trigger event冲突，一种可行的方法是narrow现有rule的trigger event。同时，修复rule的action也有自己的方法，1）不能是自然 2）引起其它冲突的action不选 3）与trigger违背就不选。

2.2.1 Refine Trigger

根据原文算法，trigger 需要做weaker处理，使得其更容易到达冲突的位置：
(@fan.off & @clock -1) 舍掉其中的@clock -1，(water.wet&alarm.siren&fan.on&fan.watertimer=1&fan.alarmtimer=601)舍掉其中与冲突不相关的water.wet&alarm.siren&fan.on&fan.watertimer=1。
refine后的trigger为 If (@fan.off) while (fan.alarmtimer=601)

2.2.2 Refine Action

由于bridge后有多个action，假设选择了最正确的@fan.on & @clock - 1，舍去@clock - 1。
refine后的action为 then (@fan.on)

2.2.3 Refine existing rule & Rule merging（在这个例子中不用考虑）

在这里插入图片描述

Step3 TAP Synthesis

如上图，无法解决:
while fan.alarmtimer=601等要体现action break的原因如smoke还是烟雾状态（好像也能解决，看似不能解决是因为没引入smoke），alarm siren只是表象以及 fan.on的运行时间（这个可以解决，被打断时可以参考fan.alarmtimer），或者直接就是往最大了开；无法解决空白区；而且我们的方法更智能，能解决TAP的死板

一些想法：
比如和fan同一类的安全属性：

My smart door lock should always lock after I come in。
虽然里面有timer，但是解决的确实door lock这样在一个time period内就能完成的sustained action。