何为常规？未引入latency、pysical chennel-based(分为immediate和tardy)、concurency、connection-based
该篇考虑了pysical chennel-based
验证AutoTap无法解决channel-based
TAPInspector、AutoTap如何反应heater对温度的影响
特点：
之前是intra-app（app内），现在是cross-app（app间），主要还是针对smartthing的平台特性，其它都是部署在一个上面的，相当于就是多设备交互了
更准确的规则提取
对risk进行分级
each CAI threat type (Table II) has specific impacts on the involved rules,i.e.,promoting,suppressing or looping the rule actions
CAI threat instance I(type,R1,R2) as Risk(I)
不仅可以运用到是修复、不修复还是通知，而且可以搞个优先级，比如同一设备执行不同指令，哪个指令先执行
我觉得heater risk比lock高
For example, automatically locking a door is typically considered a safe operation, since “safety” rules usually
lock (rather than unlock) a door to ensure safety. Thus,
(+)lock.lock() (promote locking a door lock) has a
low risk, (-)lock.lock() (suppress locking a door)
has a high risk and (o)lock.lock() (alternately lock
and unlock a door) has a high risk. Automatically turning
on a light is regarded as a low-risk operation since “nonsafety” rules usually turn on lights for convenience. Thus,
(+)light.on() has a low risk, (-)light.on() has
a medium risk and (o)light.on() has a medium
risk (annoying users).
promoting,suppressing or looping 的影响取决于具体规则的敏感性和规则的action的敏感性（有些设备是敏感的），如safety-critical rule R1 (“unlock the door and open the window when smoke is detected”) 是出于安全目的，non-safety rule
R2 (“open the window when air quality is low”)处于舒适方便目的
取max是因为有一个高风险，整体就是高风险
With the SMT models of CAI threats, detecting CAI threats is converted to a theorem-proving problem
if a SMT model is solvable, the rule pair could cause the corresponding CAI threat.
用的是符号执行SMT而不是LTL model checking，SMT不需要提供安全策略，是否提供是用的方式决定的？
新APP安装时，分析和现有APP之间的冲突。
R1的action怎样影响R2的trigger condition和action
Action-Interference Threats
两类：triggered / not triggered by the same event，action overide了上一个action的效果
Cross-APP中的A.1、A.2是在(safe的那方，被打断的)同时或之后执行了¬。Action breaking，在执行过程中执行了¬（不一定相反而是其他值）,Disordered action scheduling和加入延迟的action overiding。都可以理解为对action的Interference，预期达不到
检测：
issue contradictory commands, or issue the same command with conflicting parameters; either situation indicates A1 = ¬A2.
由于满足条件不一定能引发冲突，需要确定是否能引发冲突，比如考察是否可以在同一条件下发生（overlapping condition detection (C1∧C2)），因为如果一个C1为present，一个C2为not present，肯定不会同时触发。其实也可以判断T1、T2
说明如今的米家还是没考虑，最终的状态还是uncertain
如果初始为关，则开关 或 开
如果初始为开，则关开 或 关
An example is that in two rules r1 (“When
motion is detected, turn on the light”) and r2 (“When motion is
detected over a 1 minute, turn off the light”), platform delays
may result in that r1 has a latency greater than 1 minutes and
the light will not turned off which violates r2.
如果没延迟，不会出现r1卡r2
physical interaction 好像有研究，在smv的50变100的那里
final state thus unpredictably violates the intention of either R1 or R2，所以要知道谁的 intention 更重要
第一步是实现状态完整，特别是extended，可以在一个规则中不设置off但要在其它规则中有off，还有闭环问题。闭环：状态没写全，如果打开，那必须有关闭。
A.1让用户自己改，把冲突时的状态变为certain
Disordered Action Scheduling和Action Overriding是特殊情况
A1:
||
ri,rj预期
A2：
|——————————|
ri预期 rj预期
Disordered Action Scheduling：
|————————————————————|——————————|
ri预期 rj预期
Action Overriding：
|————————————————————|——————————|
ri预期 rj预期
Action Breaking
|——————————|——————————|——————————|
rj预期 ri预期
对于A.1，如果是两条trigger和condition一样的，删除一条。其它情况，细化规则。
第一步，对于A.1，细化规则（因为一个property就对应一个TAP，对用户来说看着很多规则会不舒服，要尽量减少）、缺省状态（如unlock，heater必须关）等简单的先修复。heater必须有关，light不一定，加入后再smv。
Properties that share the same capabilities of devices sometimes interfere with each other。属性不能互相冲突，比如窗子一直要开着与开空调时要关着窗，如果冲突只能保证其中的一些。
例1
冲突取决于发生的间隔。发生的间隔远，就是正常的触发行为。
冲突取决于发生的执行顺序。执行顺序不同，会使修复的等级不同，比如：
Rule2属于着急上班的人害怕遗忘所以设置规则确保家里的电器都关闭，正常来说虽然Rule1没规定时间即可能随时被触发，但是Rule1只会在下班的时候才触发，两条规则很少冲突。user-centered，在早上八点用户的本意是要关闭设备，如果这个本意被打破才算冲突。某天，Rule2正常触发，人在8点后发现东西没拿回去拿触发Rule1然后离开，然后家里电器可能打开了，违背了rule2的本意，要修复。满足闭环，但是safe->unsafe
修复：门超时关闭，action是确定的，trigger看情况 ； 电器要及早关闭 比如增加present条件（也是因为rule2的前置条件有present）
Rule2正常触发，人在8点后发现不上班回去触发Rule1然后呆在家，门超时关，电器可能人需要就不关 需要增加present条件indicate人要正常使用。满足闭环，但是safe->unsafe
如果某天由于某些事8点前回家 Rule1先触发，然后离家，然后Rule2触发，即使是override了，但是是正常的。满足闭环，同时unsafe->safe
而且action的重叠程度也是可以影响的。比如unlock & turn on one light 比单纯的unlock影响大，更应该去修复
生效的时间段。我倾向于不选规则生效的时间段和周几。所以后花园的案例很容易发生。设置时间段没有unlock那个措施好
例2
spital因素如房间布局和设备布局也会影响修复。如果没设置周末（我想应该很多人都会因为嫌麻烦会不了解自身需求没设置规则发生的时间段和周几），在周末到点lock所有门或人出去超时未关就lock，如果是冬天，老人触发规则一进入后花园，然后由于怕冷风吹进家合上门但没锁。由于老人在室外干活久，规则二触发，锁上了门。老人由于没带手机，而且规则一要求人在室内移动，那么人就被锁在外面进不去了。家里没人外面又冷那不就出事了。 看会不会形成一个闭环。非闭环情况下（规则不完整），unsafe->safe可能会unsafe
unsafe到safe也不一定就安全，safe到unsafe也不一定就unsafe，比如正常的开关，但那是munual action了
处于室内和室外边界的掌管access的设备，如果trigger设备在室内，unlock意味着人去外面了，在外面无触发途径就不能关，lock不分双向，unlock分双向；如果trigger设备在室外，unlock意味着人在里面了。定义一个全局变量。室内默认有开大门的unlock，外面也有unlock，lock不分双向。可能是对现有的做修改让它不陷入，而不是新增让它陷入后逃脱
上个例子: outside_sensor.present unlock & in home <——> indoor_motion.not present lock & out home
indoor_motion & out home ->
在TAP规则连接的区域中涉及到present就要双边都有传感器
针对阳台门的attribute并不只是lock和unlock，unlock具有双向性，要indoor->unlock，outdoor->unlock，但是这样防不了贼
lock常和motion搭配
可以做区分：插座打开几秒（大概率说明正常运行），和短暂打开
修复：
如果有户外sensor
增加if 户外present，outdoor.unlock（可能违反用户本意，他就是想自己开）
预期效果：人在花园里不能锁门
或者 if lock (fan.off) & 人在花园里不能锁门, then unlock 这条是第二条的冗余版
还有种方式是等待冲突发生，没这种不用等待的好
如果没有户外sensor
if lock (fan.off) & 人在花园里（不久前触发过rule1在HA里是状态里的last_trigger且室内传感器没检测到人）（两点合一起说明发生冲突）, then unlock （被打断、被覆盖的行为）
并不是 if lock & 室内传感器没检测到人 ，then unlock，不合理
例3
如果闭环了，那么就遵循safe到unsafe就unsafe
正常顺序，Rule1先，相隔很长时间后Rule2。如果仅一段时间，就是人刚回家就熄灯，这不可能，因为有条件no motion detected，但是呢，可能门就没关了。unsafe->safe，可以。
Rule2先，Rule1后，safe operation到了一个unsafe就大概率要修复，要恢复lock但是light估计不用恢复，第一是人到家要使用，第二是lock是安全属性。
修复：
如果去自动lock，可能会违反晚归用户本意
If unlock & 如果超时未关，则关 or if unlock & not_present（门窗传感器是2分钟，测门超时未关的时间和not_present哪个更靠谱时间更低）
对判定家里有人的疑问？应该是主看门那的，present后即使很久没触发人也是在家的，要等二次present才会出门
如果是turn on / off heater就会严重
假设用户不会意识到，因为如果没意识到一次就可能会产生严重后果，如果做到预先预防，人只是起到检查的作用。修复的时候通知用户，防止confused
smv里有没有模拟手动开关？没有，要模拟也是init状态。像wet这样的状态才是啥都可以取，也模拟了突发情况
修复
valid：不止是满足语法，还包括不能修改自然现象和正常事件如present，还有设备功能device specification、property phi。smv中的属性是现象所以不能改，但是next中是TAP规则可以改、
修复思路
反例 LTL、CTL部分反置 门关的反置是门开 counterexample解决一个再出一个，就可以多个反例
共性修复，及在smv中的体现
拆分的思想 如果没TAP规则或者啥，就没冲突
删除现有的TAP规则
动态阻止
Trigger-Interference Threats
该类中也有Action-Interference，就是A和¬A
第一类：T1 用户由于缺少安全知识、misunderstand一些app dscription等，没意识到不在家不能发语音指令，可能是想语音操作其它，但是会关闭安全摄像头
第二类：T2 T3 T4 action影响了另一个rule的trigger，一般会触发rule，包括特殊的loop
检测：判断是否通过action直接触发或pysical channel间接触发（action与温度相关，而另一个规则的trigger也与温度相关）
如果overlapping condition detection (C1∧C2)为真，就是真威胁
T1可以考虑询问用户是否合并，有点像米家设置规则后提示条件已满足，是否触发，这种规矩的修复是不确定的，因为用户可能真想打开camera，也可能不想
被触发的Rule4触发场景更多，因为除了Rule3这种turn on tv触发方式，也能在其它触发方式下执行，所以合并存在一个问题，就是这里相当于是小范围并大范围。构建一个对应表
能trigger是由于trigger不够narrow
Condition-Interference Threats
action影响了另一个rule的condition，一般不会触发rule，毕竟是condition，要先满足trigger（米家的“当任意触发”）才进一步判断condition（米家的“且满足状态”）
分两类：Enabling-/Disabling-Condition Interference
哪些当作符号？不依赖于其他数据的数据被作为符号输入来处理. In SmartApps,they include device references(设备独有的标识符), device attribute values, device events, user input, constant values, and API return values(如t = API(参数))
而且符号执行的存在无法修复的问题吧
把论文里的例子转为smv代码
F的话会包括正常情况，得想另一种方法。因为没研究extended，所以可以用X，且XXX和X其实可以看作是一样
X看作是冲突而不是正常情况，X模拟period
检测冲突：用AutoTap的模板
check_ltlspec -p “!F(doorLock.lock = unlocked -> X(doorLock.lock = locked))”
| (doorLock.lock = locked -> X(doorLock.lock = unlocked)))"
*************** AVAILABLE STATES *************
================= State =================
0) -------------------------
presenceSensor.presence = present
presentState = not_present
doorLock.lock = unlocked
doorLockState = unlocked
light.switch = on
lightState = on
clock.timer = 10
================= State =================
1) -------------------------
presenceSensor.presence = not_present
Choose a state from the above (0-1): 0
Chosen state is: 0
*************** AVAILABLE STATES *************
================= State =================
0) -------------------------
presenceSensor.presence = present
presentState = present
doorLock.lock = unlocked
doorLockState = unlocked
light.switch = on
lightState = on
clock.timer = 11
================= State =================
1) -------------------------
presenceSensor.presence = not_present
Choose a state from the above (0-1): 1
Chosen state is: 1
*************** AVAILABLE STATES *************
================= State =================
0) -------------------------
presenceSensor.presence = present
presentState = not_present
doorLock.lock = locked
doorLockState = unlocked
light.switch = off
lightState = on
clock.timer = 12
如何模拟同时，还会有个问题，就是都触发了，下一个状态应该必是另一个触发状态
next(doorLock.lock):=
case
presentState!=presenceSensor.presence & presenceSensor.presence=present: unlocked;
clock.timer=11 & presenceSensor.presence=not_present: locked;
TRUE: doorLock.lock;
esac;
把每个TAP拆成单独的union case，现在变为了每个都会判断，如果union case不满足走true保持不变，更改后如下
next(doorLock.lock):=
case
presentState!=presenceSensor.presence & presenceSensor.presence=present: unlocked;
TRUE: doorLock.lock;
esac union
case
clock.timer=11 & presenceSensor.presence=not_present: locked;
TRUE: doorLock.lock;
esac;
待解决，处理delay的思路是把delay和规则放一个union case里
但是问题是timer到期的off行为也要反应出来 homePresent.presenceSensor.presence=present&homePresentState!=homePresent.presenceSensor.presence: on;
homewater.waterSensor.water=wet&homewaterState!=homewater.waterSensor.water: on;
runinfan61.timer=1&fan.switchCap.switch=on: off;
runinfan27.timer=1&fan.switchCap.switch=on: off;
Trigger有相反交集的（如都有presenceSensor.presence且值为相反，不可能同时为）放一个case里
next(doorLock.lock):=
case
presentState!=presenceSensor.presence & presenceSensor.presence=present: unlocked;
TRUE: doorLock.lock;
esac union
case
clock.timer=11 & presenceSensor.presence=not_present: locked;
TRUE: doorLock.lock;
esac;
Action breaking和TAP规则的顺序有关
两种思路：事先prevent & 事后trasient
– check_ltlspec -p “G((presentState != presenceSensor.presence & presenceSensor.presence = present)->!F(G(light.switch = on & presenceSensor.presence = not_present)))”
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
