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

3730                                Journal of Software  软件学报 Vol.32, No.12, December 2021

         以实体-能力抽象为基础,按动作实体将规则分组、组内按序优先,有效避免了优先级冲突;它区分只读和可控能
         力,提供 4 种表示历史状态的算符,并方便表达在指定状态/状态保持下对多种能力的期望;
             (3)  引入能表达事件型智能家居执行引擎的独立“Event-trigger Event-action”(EE)中间表示,基于 HA 构建
         智能家居自动化框架 SSRules,它能将 SS 规则集合经 EE 规则表示转译成 HA 规则,利用 Z3 定理证明器                       [18] 进行
         触发事件的筛选和规则化简,并提供运行时子系统动态感知设备变化和检查规则执行的有效性;
             (4)  实现了智能家居模拟器和 SSRules 原型系统.对 10 组测试场景,用 SS 范式编写所需的规则条数比转译
         和合并后得到的 EE 范式规则数平均减少了 60%左右;在模拟实验环境下,最终生成的 HA 规则的运行时检查都
         未发现连续异常,并且所记录到的瞬时异常(小于总检查次数的 0.3%)经查阅日志均为网络延迟引起.
             本文第 1 节对现有 TAP 编程范式及其引起的缺陷、易用性以及缺陷检查和修复现状进行总结.第 2 节提
         出智能家居自动化框架的设计目标,对以 HA 为底层基础、以 SS 规则范式为用户输入的智能家居自动化框架
         SSRules 的总体设计进行总结.第 3 节详细讨论 SS 规则范式的定义及其到 HA 规则的转译方法.第 4 节介绍基
         于 HA 构建的智能家居模拟环境,并在该模拟环境上评估了 SSRules 的有效性.第 5 节和第 6 节分别对相关工作
         和本文的工作进行总结.

         1    TAP 编程范式及缺陷分析

             为了满足终端用户灵活多样的需求,大多数智能家居平台都提供特定的 TAP 编程接口用于对智能设备和/
         或服务进行编程,以定制智能家居系统的行为.本节首先对 TAP 编程范式进行了详细分析,然后系统总结分析了
         可能导致 TAP 缺陷的原因,最后简要总结改进 TAP 的可能渠道.

         1.1   TAP编程范式概述
             TAP 的表达能力及易写易改性,对智能家居的推广和普及至关重要.目前最流行的 TAP 接口是 IFTTT 在线
             [3]
         服务 ,它允许用户创建程序、自动执行由单个事件触发的动作,尽管 IFTTT 应用广泛,但其表达能力非常受限.
             •   多触发器、多动作
                                 [5]
             根据 Ur 等人的用户调查 ,22%的编程行为需要不止一个触发器或动作,并且触发器和动作在用户期望的
         行为中的组合也更为多样化.因此,Ur 等人引入“and”连接触发同一动作的多个事件,例如“IF  窗户是开的 and 在
                                                                    [9]
         下雨”就触发“关窗”.Zapier    [11] 允许将多个动作绑定到一个触发器;Stringify 支持形如“If This and This, Then
                             [4]
         That and That”的规则.HA 还允许定制只要多个触发器中任意一个被触发就执行的规则.
             •   条件过滤与工作流控制
             Zapier 和 HA 提供过滤器,支持对触发器的进一步(and/or)条件过滤.例如:可以在触发器“接收邮件”后追加
         过滤器“主题包含 X and 来自 Y”;MicrosoftFlow     [10] 不仅提供多步骤的工作流,还提供 If-then-else 条件过滤、
         For-Each 和 Do-While 循环等;HA 允许定制包含“call service”动作、自定义事件和自定义触发器的规则,允许开
         发者编程实现各种服务.Flow 和 HA 提供的这些功能非常强大,但是对终端用户编程的能力要求高,且缺少对用
         户配置的有效性检查.
             •   区分事件(event)与状态(state)
             IFTTT 的“if this then  that”易被理解为通用编程中的 if-then 语句,而其实际语义却等价于事件驱动编程.
                  [6]
         Huang 等人 认为:把 IFTTT 隐喻成 if-then 会有歧义,这种歧义会给用户带来困难.由此提出用事件和状态区分
         触发器:事件是瞬时信号(如“温度降到 10°C 以下”),而状态是可随时评价的布尔条件(如“在下雨”).Brackenbury
         等人  [17] 进一步将动作分成事件(在特定时刻发生,如“关灯”)和状态(一段时间内设备的期望状态,如“灯应亮着”)
         两类.这种区分事件和状态的 TAP 看似消除了一些歧义,潜在简化了系统实现中对 TAP 规则的理解,但是研究表
                                           [6]
         明:终端用户往往很难清晰区分事件和状态 ,且它们的组合又引出新问题.
             •   事件和状态的组合
             事件和状态在组合时有以下语义:多个状态 s i 的合取是另一个状态 s,仅当每个 s i 为真时 s 为真;状态 s 与事
         件 e 的合取是在 s 为真时 e 同时发生的另一个事件 e′;两个事件 e 1 和 e 2 的合取是与 e 1 和 e 2 同时发生的另一个
   61   62   63   64   65   66   67   68   69   70   71