一句话：
根据trace和goal（Goals are properties that the system should achieve），使用满足一些属性就是插值的定义，计算出插值（trace和goal），插值说明了出现反例的原因是反例的一部分，如果不摆脱它就会一直出错。插值就是用几个已知去预测未知的过程。用插值和前一状态计算最弱前置条件，从后往前推理，trying to find the first place where the violation might be avoided，阻止操作发生或者让没出现的操作发生（是否发生也是要满足一些属性）来避免冲突。如果没有满足，就去前面的状态找，计算新的插值以及其它信息
第一条用人话说就是当前路径要有at的trigger和状态
第二条就是说at之后的状态要能消除冲突
加入at本身的触发条件
表示状态的开始，结束或归为false
existing rules’ trigger states, cannot add new rules or preserve
existing property-compliant behaviors.
✸ (eventually) LTL是因为temporal operators (next)
Device = set attributes
attribute = set values
Trigger、Action、Condition = Device、Attribute、Value
match ri中一个元素与rj中一个元素如果在（device、attribute）有交集
same_channel ai和tj一个channel
are_connected ri的a触发rj的t 满足match same_channel不一定是漏洞，还需要are_connected
directly (by involving overlapping devices, attributes, and values) or mediated by some physical channel
CHANNEL以及act on在上面的actutors和sense on在上面的sensor
本文由于什么什么，比如考虑了某个东西，所以可以检测
理论是对的
每条相关规则都有可能由于交互产生漏洞，但不知道具体原因是哪一条，生成反例能知道具体原因是哪一条
经过之前的预处理，可不可以默认是配置及语义不正确
一、建模信息生成
1.1 生成缺陷状态
处理环境属性：
不考虑动态的余热，温度这种维持两个状态再变化，设置flag+1，加到2可以变化同时归0 （heater_indicator=1 & heater_on：温度升高）
temperature.low(触发或不触发) temperature.low temperature.high
co.high(if触发) co.high
co.high（if触发，A.1）co.high
两个延时属性，触发或不触发，都不会出现连续两次两个状态toggle
但是其他情况就会toggle
处理toggle
tuple < s1>
<s1,s2>
1.2 识别检测缺陷状态 / 漏洞
B1 通常对应 When / If __ , __ should / must be / not be __.
next(not_present) & next(heater)不能同时出现，be和not be对应两种语句
B2 next(temperature) > x &
n 从判断改为涉及的状态
1.3 生成安全属性对应的初始规则（待定，估计放到原始信息）
1.4 设备选择，包括筛选和当前系统有关的property
二 、基础模型
环境不变化，而是在初始时随机赋值 或者初始时随机赋值，然后环境正常变化(esac union一个增长一个不变一个变小)
如何实现单点特性
三、扩展模型
3.1 规则配置
3.2 规则语义
while condition 当前所有device selection设备的condition都加，可以考虑while none
平均准备30条总规则
修复模板
根据安全属性和Ngram得到常见组合、排除部分组合
当前所有设备对应的状态条件都进行组合变异，一种组合方式对应一条执行路径
第一个条件能达到该点，然后精细化
加了修复措施，是否能在不安全时达到安全
四、反例分析
变异后找不到，返回原配置。反例分析配置没变则要进行语义层面修改（或不返回原配置，如果LTL为对应值说明纯靠配置不成功）
意味着无法通过改进规则语义和规则配置来解决冲突
处理多property冲突，AutoTap没说 下雨时开窗
加入property对应的初始规则
If raining , then close window
If co > x , then open window
对于涉及同一设备的property在一起建模
co高时下雨
If raining while co
If raining while !co
下雨时 co高
If co while raining(其实就不用改，因为co在之后)
If co while raining
同时的情况
规则执行的次数，一次If还是多次When
处理没有TAP规则
在上一条基础上
客厅灯光照闪灯 纯配置
property： 灯不要toggle
设备筛选（还要是同attribute）后得到以下规则
规则1： when illuminance < 100 , turn on light
light illuminance(channel是自己定义的light和光照有关) 如果是开窗通风，window，co2，temperature
– 规则2： light.on , turn on light2 这个就是B3，因为涉及3个状态
规则2： when illuminance > 500 , turn off light
规则3： not present , turn off light
light illuminance，首先都在light里所以match，其次才是illuminance，都对应一条illuminance
判断两条规则value in 或者 same_channel
然后到自动机里判断loop
规则4： 口头命令 , TV on
规则5： TV on , turn on light
F(X)可以精准地探测到未来状态的下一状态
X(flag=0 & XX等价于第一、二个状态
[event1] should [never] happen within [time] after [event2] ¬F(time#event2 ∧ X@event1)
!F(time=2&X(flag=0)) 不等于 !F(time=2->X(flag=0))
red always followed by green or yellow G(color.red → X(color.green ∨ color.yellow))
check_ltlspec -p "!G((time=2->X(flag=1))&(time=2->X(X(flag=0))))"
p->q等价于非p或q
φ ↔ ψ ≡ (φ → ψ) ∧ ( ψ → φ)
**->和->F有区别**
一个判断当前和后续，一个只判断未后续状态
**!一般用于取具体的例子**
!G不等于G!
G! (runinfan61.timer=2 & fan.switchCap.switch = off) 全局的每一个状态存在! (runinfan61.timer=2 & fan.switchCap.switch = off)
等价于 !F(runinfan61.timer=2 & fan.switchCap.switch = off)
把500改为改为100+500=600
出现loop，而且loop的与light相关规则flag为1且满足互相触发
如何检测loop？
前后状态会有些一样
判定一条规则触发了另一条规则，立刻触发了另一条
判定没触发另一条规则
如何判断是哪几条？要更改哪一个？规则设置flag?flag,rule1 trigger:1,rule2 trigger:2
温湿度导致的uncertain 纯语义
If 8:00 while temperature < 20 , close window
If 8:00 while humidity > 60 , close window
<20 且 >60 ，用户选
<20 且 <60，原
大于60 且>20 ，原
1197
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
