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

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


         事件.然而在智能家居系统中,“事件同时发生”无论是理论还是实际都不太可能发生.Brackenbury 等人                             [17] 提出
         了 3 种多触发器组合的时序范式:Event-Event,Event-State 和 State-State,并将它们与动作组合成表 1 所示的 4 类
         TAP 规则.其中:Event-Event 时序范式引入 WITHIN 时间窗口子句来描述不能同时发生的事件,并提供
         AFTERWARDS 指定事件次序;Event-State 时序范式将触发器限制为一个带若干状态的事件.这两类触发器均
         触发事件型动作,也是真实智能家居系统主要采取的方式.State-State 触发器范式组合多个状态并且状态会在一
         段时间内满足,故自然地触发状态动作;考虑到影响同一设备的多条规则的多个状态可能同时为真(如控制空调
         的模式),故 State-State→State 范式需要包含优先级来解决冲突.此外,对于少数不能直接表示为状态型的离散事
         件动作(如“记录日志”),State-State 时序范式会触发事件动作.
             •   状态保持性描述
                      [6]
             Huang 等人 将动作分成瞬时动作(如“发邮件”)、在固定时间完成的动作(如“冲泡咖啡”)、包含改变状态
         的持续性动作(如“开灯”),这给智能家居系统提出了描述和实现状态保持特性的需求.SmartRules 提供“状态保
         持”的表达,可以创建“如果门开着有 5 分钟就通知”之类的动作.HA 提供的 trigger 可以定时,虽然其 action 没有
         直接提供保持时长的表示方法,但是它提供的 callservice 动作潜在允许开发者编写处理状态保持时长等服务的
         能力,因此也可以实现类似状态保持的表达.
                       Table 1    Four kinds of TAP rules defined by Brackenbury et al. and examples
                           表 1   Brackenbury 等人定义的 4 类 TAP 规则范式以及规则举例
                   范式类别                   范式定义                           规则举例
                               IF event (AND event|AND AFTERWARDS  IF  主人离家 AND AFTERWARDS  外卖送达
                Event-Event→Event
                               event)*(WITHIN timewindow) THEN event  WITHIN 5 分钟 THEN  通知主人
                                      IF event (WHILE state      IF  主人进入卧室 WHILE  晚上
                Event-State→Event
                                    (AND state)*)* THEN event         THEN  打开卧室灯
                                                                 IF  小明不在家 AND  小黄不在家
                                      IF state (AND state)*   THEN  空调应处于关闭状态 PRIORITY 0
                State-State→State
                                   THEN state PRIORITY priority      IF 室内温度高于 28°C
                                                              THEN  空调应处于制冷模式 PRIORITY 1
                                      IF state (AND state)*         IF  室内温度高于 30°C
                State-State→Event
                                         THEN event                THEN 记录温度到日志文件

         1.2   TAP规则的缺陷分析
             用户在编写 TAP 规则时很容易出错,原因在于智能家居设备众多、用户期望的行为复杂多样、智能家居
         设备之间存在大量的交互          [19] ,单个设备会直接或间接影响到其他设备.人的行为也会影响设备状态,而人的即使
         看似简单的行为也可能会引起背后复杂的设备行为;且人的行为与需求并非一成不变,在不同的场景需求下,很
         可能会造成对已有规则的破坏           [20] .由于智能家居的用户通常缺乏编程相关的训练,为降低编程门槛,TAP 过分简
                    [6]
         化了操作界面 ,从而使程序的表达能力变差,这进一步恶化了 TAP 对复杂行为的可解释性.
             Brackenbury 等人 [17] 通过用户调查,总结出可能出现在 TAP 的 10 种缺陷,包括:
             (1) 4 种缺陷已被发现且详细讨论
             ① 优先级冲突(priority conflict),仅在采用 State-State→State 时需要对作用于同一设备的多条规则进行优
                先级排序,而用户往往难以按自己的意图正确设置规则优先级                        [21] .这种缺陷已被 TAP 文献广泛讨
                论 [7,13,22−24] ,可以通过静态分析来检测;
             ② 安全默认偏差(secure-default bias)发生在用户默认系统处在安全状态             [21] (例如夜间锁住窗口),但广泛部
               署的 Event–State 设备没有默认状态,Yarosh 等人详细讨论了门锁的这种缺陷                [21] ;
             ③ 非瞬时动作(extended action)源于动作发生在一段时间而不是瞬时的(如冲泡咖啡);
             ④ 缺少反向动作(missing reversal)发生在用户创建了一条执行某动作的规则而没有写撤销该动作的规则
                时,例如写了“IF  进客厅 THEN  开灯”但忘写离开关灯的规则,但用户可能认为系统会自动关灯                          [6,21] .
                       [6]
             Huang 等人 详细讨论了缺陷③和缺陷④,并对系统接口提出改进建议.缺陷④可以通过静态分析检测,但
   62   63   64   65   66   67   68   69   70   71   72