Page 83 - 《软件学报》2021年第12期
P. 83

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


             EXPECT (模式,关) WHILE  客厅温湿度传感器.温度<22°C AND  客厅温湿度传感器.温度>14°C
             而在转译出的 13 条 HA 规则中,没有被执行过的(可能是多余的)一条 HA 规则用 EE 范式表达为:
                   IF  客厅温湿度传感器.温度 FROM (−30°C,10°C)∪(28°C,70°C) TO [10°C,28°C] WHILE
                      客厅空调.模式!=制冷 AND  客厅空调.模式!=制热 AND  客厅空调.模式!=干燥
                          AND  客厅温湿度传感器.湿度>65% THEN  客厅空调.模式设定干燥
                               Table 8    Comparison of SS and HA rules and test results
                                       表 8   SS→HA 翻译对比和测试运行
            规则组编号      动作实体       相关实体     SS#  EE#  HA#  覆盖率(HA)   规则执行次数      瞬时异常    连续异常
                1      3 客厅空调       3,11    4   13   13     12/13       325      1/1200   无
                2     7 客厅氛围灯      7,12~15  4   14   14     14/14       206      1/1200   无
                3     9 厨房排气扇     1,2,9,13,15  3  13  13    12/13       237      1/1200   无
                4     6 客厅加湿器      6,11,13  3    6    6      6/6        257      0/1200   无
                5      4 厨房窗户     1,4,13~15  3   9    9      9/9        187      0/1200   无
                6        2,4,9    1,2,4,9,15  5  11   11    11/11       509      3/1200   无
               T1     7 客厅氛围灯      7,12,13  2    5    5      5/5        201      1/1200   无
               T2      5 大门门锁      5,12,13  2    6    6      6/6        395      0/1200   无
               T3        2~4,7   1~4,7,11~13  8  17  17     17/17       390      0/1200   无
               T4         4,8    1,4,8,13~15  6  13  13     13/13       298      0/1200   无

                                                                                S
             原因在于:当前的筛选策略没有假设系统状态在事件发生之前的瞬间与整个规则组 G 的描述相符,而仅仅
         假设系统状态与第 3 条 SS 规则的描述是兼容的(即第 3 条规则未激活或者其期望状态已满足).但是在测试运
                                                         S
         行中,当温度低于 10°C 或者高于 28°C 时,系统状态持续与 G 的描述相符,空调模式一定是制热(第 2 条 SS 规则
         激活)或者制冷(第 1 条 SS 规则激活),所以该条 EE 规则是多余的,通过使用更激进的事件筛选策略可将其消除.
             •   HA 规则运行异常检测
             表 8 的后 3 列分别是在 20 分钟的随机测试下,各组的 HA 规则的执行次数、异常检测模块发现的异常次
         数(系统状态不满足动作实体的 SS 规则集合中激活的那一条 SS 规则的期望状态)与总检测次数之比、是否存
         在连续两次检测到异常的情况.各组总的规则执行次数相差不大.异常检测模块目前以定时轮询方式实现,在 20
         分钟内进行了 1 200 次异常检查,未发现连续出现异常的情形.对于单次检测出现异常的情况,经过查看记录的
         状态日志和 HA 规则的执行序列,这些异常均因网络延迟(动作执行不及时)造成.

         5    相关工作
             智能家居目前在市场上受到了广泛欢迎,越来越多的家庭配置了智能家居的设备.智能家居最吸引人的功
         能之一就是以应用程序的形式支持自定义自动化.但是由于用户未经过专业的培训,导致其自定义的规则存在
         一定的缺陷,甚至无法定制规则,这引起了人们对物联网增强生活的风险的担忧.这些风险远非仅仅是学术上
         的,更紧迫的是对用户的生命财产的威胁.Triger-Action 编程(TAP)是一种流行的终端用户编程方式,可以让用户
         实现其智能设备和云服务的交互.然而,用户有时并不能通过 TAP 正确表达自己的意图并实现相应的功能.随着
         此类系统部署在越来越复杂的智慧家居场景中,用户必须能够识别编程错误并解决.
                                                                                             [6]
             为了给终端用户提供更高效的服务,首先需要理解用户编程出现错误和规则冲突的原因.Huang 等人 认
         为,现有 TAP 编程系统(如 IFTTT)的过分简化限制了程序的表达能力.提出了改进 IFTTT 界面的建议,以减轻因
         心理模型不正确而引起的问题.Corno 等人            [28] 认为:现有的 TAP 接口界面暴露了太多功能,并迫使用户在众多混
         乱的网格菜单中进行搜索,导致用户无法得到原本需要的功能.为此,作者提出了 EUDoptimizer,旨在以交互方
         式协助终端用户使用循环中的优化器来组合 IF-THEN 规则,减少了编写 Triger-Action 规则所需的工作.
         Brackenbury 等人 [17] 提出了 10 类常见的 TAP 编程错误类型,作者发现:错误的存在,使参与者更难正确预测规则
         的行为.Davidoff 等人  [29] 发现,智能家居用户的日常活动与编程任务并不匹配.论文描述了家庭想要的控制,并提
         出了有助于终端用户编程系统实现这种控制的 7 种设计原则.Brush 等人                    [20] 认为:为使智能家居得到更广泛的使
   78   79   80   81   82   83   84   85   86   87   88