Page 69 - 《软件学报》2021年第12期

王博 等:SSRules:让智能家居自动化规则更易于编写和检查 3733

器的 TAP 编程中.Brackenbury 等人 [17] 对这 10 种缺陷的进一步用户调查表明:相比 Event-State,问卷参与者使用
State-State 能写得更正确,而使用 Event-Event 则正确性要差些.
1.3 改进TAP的可能渠道
现有的 TAP 平台尚未能充分满足用户需求,在实际运行中容易出现缺陷导致系统出错.综合分析现有智能
家居系统及学术研究成果,以下给出了几种改进 TAP、减少编程缺陷的渠道.
(1) TAP 编程范式
实际智能家居系统大都基于 Event-State→Event 规则范式来实现.相比于使用事件型触发器进行 TAP 编程,
使用纯状态触发器更容易让终端用户正确表达意图.即使使用相同的触发器范型和动作范型,不同的 TAP 规则
结构仍会影响 TAP 编程的表达能力、易用性和编程缺陷.现有解决方案中,除了直接让终端用户写 TAP 规则,
研究人员还提出了不同的实现方案,如:
• AutoTap [15] 允许用户输入设备的安全性质(可转化为线性时序逻辑公式)而由系统合成 Event-State→
Event 规则,从而减少最终规则的缺陷,但是存在合成效率较低、难以适用较多设备、安全性质不适合
表达需求细节等不足;
• Zave 等人 [24] 提出让用户对设备按不同目的(如安全性、节能等)分别描述需求特征,然后手工为特征建
立状态机,并根据它设计运行时的特征组合机制来实时控制执行器.如何由非形式的特征描述建立
FSM 以及解决特征冲突(或称特征交互)是其中的难点,该方法目前只支持对几种设备的人工建模且仅
支持“值设置”动作.
(2) TAP 规则的检查与修复
改进 TAP 编程范式不可能完全消除编程缺陷,TAP 平台仍需要一些额外的工具或方法来检查 TAP 规则的
有效性,并尝试修复规则.现有的方法大都针对 Event-State→Event 规则进行静态检查(如 IRuler [14] ,AutoTap [15] ,
MenShen [16,22] )、动态检查(IoTGuard [19] )或规则修复(AutoTap,MenShen,TrigGen [26] ),仅有极个别方案是基于状态
触发的 [21,24] ,这很大程度上是因为实际的智能家居系统是按事件驱动方式来运行的.表 3 从多种维度比较了已
有方法,可以看出,Event-State→Event 规则的修复存在搜索修复策略低效以及在不清楚用户意图的情况下仍需
用户决策等局限性.而随着设备数增多,这类规则及修复逻辑的可读/可理解性也在下降.此外,由于网络延迟/重
放攻击等,也会使基于 EE 的智能家居系统执行不期望的动作.Wang 等人 [27] 提出,通过分析日志中事件间的依赖
来事后追因.
Table 3 Existing work towards bugsin smart home rules
表 3 关于智能家居用户规则缺陷的相关工作
AutoTap [15] IRuler [14] MenShen [16] TrigGen [26] IoTGuard [19] FIResolution [24]
工具类型 修复和合成 静态检查 修复 修复 动态检查 运行时特征组合
支持的平台 自定义 自定义 自定义 openHAB SmartThings AT&T HA
用户规则和
用户输入 用户规则 用户规则 用户规则 运行时策略 特征描述
安全性质
Event-State→ Event-State→ Event-State→ Event-State→
支持的范式 IFTTT 状态触发器
Event Event Event Event
用重写逻辑
检查用户 检查如绕过 模型检查 生成必要和
减少缺陷的 指定的安全 条件、动作 设备的安全 充分的触发器 运行时检查用户 运行时特征组合
做法 性质,并添加 循环或重复 性质,修改 修复,如触发器 配置的 36 种 实时控制执行器
安全策略
缺失和矛盾的
规则来修复 等 10 种通用 规则来修复 动作等
逻辑缺陷
只能处理部分
处理的缺陷 要在 Applet 中
算法复杂度高, 触发器缺失 操作繁琐,需
局限性 难以适用 类型有限,且 支持的输入 缺陷且规则 插桩,特殊情况下 人工建模几种
较多设备 模型只适 范式受限 脚本必须有 安全策略和阻塞 设备的特征
用于 IFTTT 会有不良后果
触发器的引用