论文Summary03——TAP规则脆弱性静态修复

这类论文的4个主要问题：能检测什么样的冲突？冲突是怎么检测的？冲突是怎么解决的？如果涉及动态，是怎么个动态法

检测的冲突类型： 一致性问题是指有两条或两条以上的服务需求之间出现冲突,完整性问题是指在某些情况下的输入,软件无法给出确切的输出

当一氧化碳的浓度高于一定阈值时自动开窗,又规定下雨时自动关窗,那么如果下雨时一氧化碳浓度过高,同时满足这
两条需求,便会出现一致性问题,在这种情况下,房间的一氧化碳浓度可能会超过 200mg/L,这是有害甚至致命的;再比如规定亮度低于一定阈值时开灯,但没有规定高于这个阈值时的行为,那就会出现完整性问题,导致灯一直开着,严重浪费能源.

怎样检测冲突

冲突怎么解决 其它文章并没有在服务需求层面和系统行为层面上的检测.
用户提供的服务需求的基础上

系统结构

在用户撰写服务需求后,首先借助环境本体对系统行为进行推导,得到初始问题图,然后对其进行一致性、完整性检测.若通过检测,则将检测后的问题图结合现象指令对照表生成 TAP 规则,否则返回给用户修改服务需求（当期望属性存在缺陷时，需要用户来修改其期望的描述）

用户的本意，比如用户关心关灯，但不关心哪种行为把灯关了。那么更重视关灯而不是把灯关了的行为就是一种accomodating

用户需求的撰写

IF <entity.trigger> THEN <entity.state>

系统行为推导

1. 用户需求转为问题图
   问题图的组成部分： 需求 需求现象 需求引用 需求约束 问题领域 系统 接口

问题图右侧

在“IF entity.trigger THEN entity.state”中,entity 就是与系统交互的环境实体,它们就是问题图的问题领域

问题图左侧

需要根据环境本体推导相应的系统行为,即定义问题图的左边接口部分.

简单服务需求

无论 entity.trigger 中的 entity 是被监视实体还是被控制实体,都将需求引用中的条件直接拷贝过来
对于 entity.state 中的实体,则需要通过其状态机,查找触发状态 state 的事件,将其作为共享现象放在接口中,而且这个接口必须是软件发出的,如图 6 所示,Window 状态机里的状态 wopen 的触发事件为 wopenPulse （只考虑了本机的原始触发条件） ,则接口就可以定义为 M!{wopenPulse}.

包含&& ||的复杂服务需求

没考虑多entity.state（多action）

一致性和完整性的检测

一致性缺陷：

缺陷定义：

检测范围不一致 trigger同且范围有重合，action效果相反
覆盖不一致 trigger不同且可能同时发生，action效果相反
多了个与或不一致:需求前半句要求温度高于 25而后半句要求温度低于 25,使用与连接说明需要同时满足这两个条件因此这是永远也无法达到的

缺陷检测：

检测相同实体相矛盾的的 state 对应的 trigger 是否有重合,从而检测范围不一致，覆盖不一致通过判断trigger是否会同时发生来判定
(trigger,state)对中的 trigger 检测是否发生与或不一致

完整性缺陷：

state不完整：

将所有服务需求对应的问题图合并起来,它们并没有涉及到环境本体中所有实体的所有状态,从而导致需求的不完整。例如只规定了开，没规定关
将没有涉及到的状态反馈回用户

attribute不完整:

trigger 并没有覆盖到对应实体属性可达的全部范围。例如Light.brightness>20000 与 Light.brightness<15000 时灯处于打开和关闭的状态,但当亮度处于 15000lux 和 20000lux 中间情况时
判断trigger中同一实体的指是否完全覆盖，将没有覆盖到的情况反馈回用户

生成TAP规则

从问题图生成系统行为，再从系统行为到TAP规则（wopenPulse 对应指令 open the window，这步需要人工设置表，没有半自动或全自动）

Towards a Natural Perspective of Smart Homes

设计了一种**基于统计语言(概率，传感器检测运动，灯被打开，一段时间没有检测到运动，<缺失事件>”。“关灯”的概率最大)**的智能家居自动化场景生成，可以在用户创建的规则基础上生成 更为安全 的自动化场景策略
关键假设是，人们说的语言有pattern，且由用户创建的智能家居事件序列/代码表现出固有的语义模式，或 自然性 ，可以被建模并用于生成有效和有用的场景。本文证明了这个自然性假设是成立的，通过一个包含30,518个家庭自动化事件的语料库

缺乏自然的家庭自动化场景，即可能发生在最终用户家庭中的事件序列。

user-driven 编程：不用编写代码就可以设置trigger、action
user-driven视角，有用户参与，而不是从iot app层面，实际也证明了app会忽略一些用户的routine

做问卷获得routine（IF THEN），routine转为tokens（ smart home events，如回家、关门，不将事件划分为trigger和action，一些事件可以是触发或动作，取决于它们在例程中使用的位置）

顺序调度token化的routine生成家庭自动化序列event sequence

从用户那里获得关于单个例程的潜在执行的线索，即执行指标（execution indicators），并使用它们来调度例程，从而导致有序的家庭自动化序列
execution indicators, i.e.,clues for when these routines typically execute.
调度机制是由用户对自己的家庭使用的理解所决定的
（1）时间指标（例如，清晨，中午和晚上），（2）白天指标（例如，主要在工作日，主要在周末），（3）频率指标（例如，一天多次，一天几次，一个月几次）。
每个例程可能占用一个或多个一个小时的时间段（即，取决于频率）
首先放置在特定的时间触发的例程（例如，在上午8点，打开百叶窗）的定义
根据其时间范围指标，决定潜在的放置槽
例程的频率指示器决定了在这些插槽中均匀分布的例程实例的数量。这种分布也会根据日范围指标进行调整，即偏向于工作日或周末。对于少数没有执行指标的例程（即，当用户不确定时），我们将它们随机分配在这个月剩余的插槽中。

对event sequence建模

n-gram的n的选取大于等于3
n值高未出现的序列，smoothing会简单地恢复到基于低阶n-克的预测。

生成场景

n-gram模型检查之前的n个−1事件，并预测下一个最可能的事件，即大多数用户提供的子序列(详见附录E)。新预测的事件现在将成为下一个预测的历史的一部分。我们可以继续这些预测，得到任意长的场景。
非自然场景来证明压力测试

自然语言的预测比Graph-based Modeling有效

可用的物联网应用程序和我们的用户创建的例程(F2)之间的显著不匹配，这表明用户可能更喜欢容易创建的例程，而不是物联网应用程序
与过去基于应用程序的平台的研究不同，仅基于市场应用程序来描述环境的方法对于描述家庭自动化是不可行的。

从家庭中收集痕迹将具有极强的侵入性,real execution traces from end-user homes

能检测什么样的冲突？17 security/safety policies

冲突是怎么检测的？discover 27 unsafe scenarios that motivate 17 policies.

冲突是怎么解决的？

自然性如何实现？
uses the n-gram language model（考虑最近的几个标记，较短的序列更容易出现在语料库） to learn patterns from such sequences即从自然角度来看自动化
自然性通过模型对新数据的困惑程度来衡量，如果模型发现一个新序列与在语料库中观察到的任何序列不同，它会在观察时感到“困惑”。如果从一个域建立在语料库上的模型的困惑度较低，这意味着该域表现出自然性，该模型可以识别语料库中的规律。

安全性如何实现？
从用户那里获得关于单个例程的潜在执行的线索，即执行指标（execution indicators），并使用它们来调度例程，从而导致有序的家庭自动化序列
execution indicators, i.e.,clues for when these routines typically execute.
非自然场景来证明压力测试
existing policy checker，并不是本文的重点，本文只是研究TAP规则的自然生成
文章的policy是自动生成的
基于文章实现一个扩展系统，获得一个当前的快照（各种属性），针对当前属性检测冲突

SIFT：Building an Internet of Safe Things

提供了一种以安全为中心的编程平台，用于检测操作冲突，并帮助用户理解如何通过模型检查纠正问题，但是无法实现自动修复