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

王 博,张 昱,耿佳宁,李向阳

1(中国科学技术大学 计算机科学与技术学院 下一代移动计算与数据创新实验室,安徽 合肥 230027)

2(中国科学院 无线光电通信重点实验室,安徽 合肥 230027)

随着物联网、人工智能与5G 等创新技术驱动的万物互联时代的到来,智能家居作为物联网的重要应用场景之一,正快速进入千家万户.智能家居令家庭中的各种设备互联互通,使用户实现设备的自动控制、远程控制和可编程控制,甚至可以根据历史经验主动进行自动化服务.根据MarketWatch 发布的报告[1],2016 年,全球智能家居市值556.5 亿美元,预计2025 年将达到1 742.4 亿美元;同时,中国的智能家居市场也在快速发展,据艾瑞咨询发布的报告[2],2017 年,中国智能家居市场规模为3 254.7 亿元,预计2020 年将达到5 819.3 亿元.

为管理种类和规模不断增加的智能设备,国内外主要领导厂商纷纷推出智能家居平台,如三星的SmartThings、Amazon 的Alexa、Google 的Home、小米的米家、华为HiLink、云端规则定制平台IFTTT(“IF This Then That”)[3]等,但它们几乎不开源并且仅支持相关品牌的设备,限制了用户所能管控的设备类型及范围;在开源的智能家居平台中,基于Python3 的HomeAssistant[4]相对成熟,支持多种操作系统/平台,集成了IFTTT、GoogleAssistant、MQTT 等产品/功能.这些智能家居平台将要管控的设备抽象化,通过建立通信标准以及API互联等方式连接设备和app,采用“触发-动作编程”(trigger-action programming,简称TAP)[5]支持用户定制规则以指定系统行为.但我们通过多次调研发现:现有TAP 虽足以满足终端用户表达简单的自动化任务,但灵活性不足,难以支持更复杂的用例[5-8].

TAP 规则(如IFTTT)典型地将单个触发器(trigger)与单个动作(action)关联起来,例如“如果开始下雨,则关窗”.然而,许多常见行为需要TAP 提供更强的表达能力,如对空调等复杂设备的设定、对门锁窗户等安全攸关设备的可靠设定、对夜灯/咖啡机等设备的工作持续时间设定等.为支持用户的日常需求,不同的智能家居平台提供不同的支持,例如引入and 连接多个触发器[5]或者连接多个触发器和多个动作(如Stringify[9])、用更一般的and/or 组合多个触发器或多个动作(如HomeAssistant)、增加对触发器的条件过滤(如Microsoft Flow[10],Zapier[11]和 HomeAssistant)、增加“状态保持时长”的表达能力(如 SmartRules[12])、支持自定义的事件/服务(如HomeAssistant).各种TAP 扩展丰富了可定制性,但是也存在语义不清晰、编写复杂等缺陷,不便于用户使用.

随着设备数量的增加,其交互也随之增多,TAP 编程出错的可能性也会增加.针对这类问题,一些研究如BuildingRules[13],IRuler[14]等提供对某些TAP 编程缺陷的检测;AutoTap[15]能由线性时序逻辑表达的设备性质合成某些TAP 规则,从而避免用户直接编写TAP 规则;AutoTap 和Menshen[16]还提供有限的错误修复功能.Brackenbury 等人[17]首次提出和规范可用于TAP 规则触发器的3 种时序范式Event-Event,State-State 和Event- State,并总结了TAP 可能存在的10 种编程缺陷.

针对智能家居系统面临的挑战,本文研究易写易改、支持多触发器-多动作、支持状态保持描述等能力的TAP 规则的表示,然后构建支持这种规则表示的智能家居自动化框架.在TAP 规则的表示方面,触发器和动作均可以分为(纯)状态型和事件型.本文首先系统分析和总结了各种TAP 编程范式以及它们引起的缺陷种类、原因和检测/修复现状,指出了改进TAP 的可能渠道;然后,针对用户不易分清事件和状态、不易写全规则所要考虑的情况组合以及“Event-trigger Event-action”(EE)风格的规则冗长、更改琐碎等特征,本文提出以“State-trigger State-action”(SS)为基础构建面向终端用户易写易改的、具有丰富表达能力的具体SS 规则范式.在自动化框架构建方面,鉴于HomeAssistant(简称HA)相对成熟和开源,支持多种平台和多种设备及服务集成方式,提供以Event 为核心的宽泛TAP 配置,本文以它为基础构建支持SS 规则范式的智能家居自动化框架SSRules.针对Brackenbury 等人[17]指出的10 种TAP 缺陷,采用SS 规则范式能天然排除时间窗错误和翻转触发器这2 种缺陷,完全避免优先级冲突;结合SSRules 的实现策略,能部分解决或消除安全默认偏差、非瞬时动作、重复触发这3种缺陷,并附带改善缺少反向动作的缺陷;对于无限循环和不确定时序这两种缺陷,可以通过模型检查等方法在规则转译成HA 之前避免;SSRules 尚不能解决矛盾的动作这种缺陷.本文的主要贡献如下:

(1) 系统分析和总结了TAP 编程范式及其编程缺陷,指出了改进TAP 的几种可能渠道,为我国智能家居领域从业者和软件研发人员全面了解TAP 编程、缺陷及改进提供了参考资料;

(2) 提出以“State-trigger State-action”为基础构建易写易改、有丰富表达力的TAP 编程范式.SS 规则范式以实体-能力抽象为基础,按动作实体将规则分组、组内按序优先,有效避免了优先级冲突;它区分只读和可控能力,提供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 应用广泛,但其表达能力非常受限.

• 多触发器、多动作

根据Ur 等人的用户调查[5],22%的编程行为需要不止一个触发器或动作,并且触发器和动作在用户期望的行为中的组合也更为多样化.因此,Ur 等人引入“and”连接触发同一动作的多个事件,例如“IF 窗户是开的and 在下雨”就触发“关窗”.Zapier[11]允许将多个动作绑定到一个触发器;Stringify[9]支持形如“If This and This,Then That and That”的规则.HA[4]还允许定制只要多个触发器中任意一个被触发就执行的规则.

• 条件过滤与工作流控制

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 语句,而其实际语义却等价于事件驱动编程.Huang 等人[6]认为:把IFTTT 隐喻成if-then 会有歧义,这种歧义会给用户带来困难.由此提出用事件和状态区分触发器:事件是瞬时信号(如“温度降到10°C 以下”),而状态是可随时评价的布尔条件(如“在下雨”).Brackenbury等人[17]进一步将动作分成事件(在特定时刻发生,如“关灯”)和状态(一段时间内设备的期望状态,如“灯应亮着”)两类.这种区分事件和状态的TAP 看似消除了一些歧义,潜在简化了系统实现中对TAP 规则的理解,但是研究表明:终端用户往往很难清晰区分事件和状态[6],且它们的组合又引出新问题.

• 事件和状态的组合

事件和状态在组合时有以下语义:多个状态si的合取是另一个状态s,仅当每个si为真时s 为真;状态s 与事件e 的合取是在s为真时e 同时发生的另一个事件e′;两个事件e1和e2的合取是与e1和e2同时发生的另一个事件.然而在智能家居系统中,“事件同时发生”无论是理论还是实际都不太可能发生.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 时序范式会触发事件动作.

• 状态保持性描述

Huang 等人[6]将动作分成瞬时动作(如“发邮件”)、在固定时间完成的动作(如“冲泡咖啡”)、包含改变状态的持续性动作(如“开灯”),这给智能家居系统提出了描述和实现状态保持特性的需求.SmartRules 提供“状态保持”的表达,可以创建“如果门开着有5 分钟就通知”之类的动作.HA 提供的trigger 可以定时,虽然其action 没有直接提供保持时长的表示方法,但是它提供的callservice 动作潜在允许开发者编写处理状态保持时长等服务的能力,因此也可以实现类似状态保持的表达.

Table 1 Four kinds of TAP rules defined by Brackenbury et al.and examples表1 Brackenbury 等人定义的4 类TAP 规则范式以及规则举例

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].

Huang 等人[6]详细讨论了缺陷③和缺陷④,并对系统接口提出改进建议.缺陷④可以通过静态分析检测,但不总能被修复.

(2) 3 种缺陷被提及

⑤ 无限循环(infinite loop)的原因是规则相互触发,这种缺陷在机器人终端用户编程中常被遇到[6];

⑥ 重复触发(repeated triggering)指用户希望规则仅触发一次,但却触发多次.这种缺陷主要出现在State- State 范式下因状态触发器持续为真导致规则触发多次.Cao 等人[25]在mashup 编程工作中提及了这种 缺陷;

⑦ 不确定的时序(nondeterministic timing)是由于系统处理同时发生的触发器的顺序不确定而导致.Huang 等人[6]简要讨论了TAP 中存在的这种缺陷.

这3 种缺陷均可以通过静态分析来检测,但是实际系统无法鉴别重复触发是否是用户的有意行为.缺陷⑤和缺陷⑦还可以通过动态分析检测.

(3) TAP 新增缺陷

⑧ 矛盾的动作(contradictory action)指的是长周期内在矛盾的动作间无限循环(例如加热和冷却之间不断 交替);

⑨ 时间窗错误(time-window fallacy)是当用户在编写Event-Event 范式的规则时忘指定时间窗时导致;

⑩ 翻转触发器(flipped triggers)是因用户难以指定触发器中哪部分是事件哪部分是状态而导致的.这种缺 陷在静态或动态分析中都很难检测到.

表2 总结了上述10 种缺陷的原因、引起缺陷的TAP 编程范式、缺陷检查或修复方法.

Table 2 Causes and detection of various bugs in TAP rules表2 各种TAP 缺陷的起因与可检测性

10 种缺陷中,第①种、第②种、第④种、第⑨种、第⑩种归结为与用户预期不一样,第③种、第⑦种为时序缺陷,剩余3 种为控制流缺陷.表中第3 列的“All”表示表1 中的4 类TAP 规则都可能引起这种缺陷.从中可见:第①种和第③种这两种缺陷仅存在于纯状态触发器的TAP 编程中,而第⑨种、第⑩种仅存在于含事件的触发器的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 关于智能家居用户规则缺陷的相关工作

(3) 智能家居系统的实现

对TAP 规则的静态检测和修复可以在规则实际运行前识别出部分规则缺陷,并尝试手工/自动修复.但是如表2 第4 列所说,还有许多缺陷是静态无法检测,或是由于难以判断用户意图从而无法确定缺陷是否存在.因此,智能家居系统在实现时需要提供:

1) 给用户更多的提示和警告:针对那些潜在有歧义、有冲突或已做动作不会被自动撤销等情况,系统要给出用户易于理解的提示或警告;

2) 提供不易让用户混淆的选项供用户选择;

3) 提供运行时日志的记录,需要权衡日志的存储量与事后推理的便利性;

4) 支持和提供含义更明确的顶层trigger-action 结构,等等.

2 SSRules 智能家居系统总体设计

为使终端用户易于编程,本文重点探索状态触发器-状态动作的TAP 编程范式(简称SS 规则范式),并基于HA 构建了支持SS 规则范式输入的SSRules 系统.SSRules 在不改变HA 规则执行引擎的基础上,扩展提供更易被用户理解和掌握的规则表达方式以及对应的规则转译器.虽然SS 规则范式尚不支持表达无状态或难以抽象出状态的事件动作,但由于这类动作所占比重小、用户需求低,因此,SSRules 可以支持用户的绝大多数需求.未来可以设计专门的机制,将这些无状态的事件动作加入到SSRules 系统中.本节首先简要介绍SSRules 的设计目标,然后分析HA 的关键特征,最后给出SSRules 总体架构以及所引入的Entity-Capability 抽象.

2.1 设计目标

智能家居正进入寻常百姓家,为了让SSRules 满足用户的不同需求,现阶段至少应围绕如下目标设计.

G1.易写易改.针对用户调查[5,6,15,17]反映的TAP 规则编写和修改的问题,SSRules 应提供让无编程经验的终端用户快速学习并正确使用的编程范式,方便表达所期望的智能家居系统性质,且在需求变化时容易修改;

G2.可管可控.SSRules 系统应能提供按终端用户的有效需求对来自不同厂商的设备实时监测与控制,感知系统中动态加入和退出的管控对象,而不能只支持特定厂商的设备和仅提供极其有限的监测能力;

G3.异常检测.智能家居系统的可靠性受限于网络、设备故障等不定因素,而用户希望系统提供实时反馈以及对系统更多的控制感.因此,系统需要能够帮助用户监视运行状况,并将异常信息反馈给用户;

G4.协调需求.作用于同一设备的多种需求存在冲突,是智能家居中的常见现象.系统要提供简单的处理方式,便于用户协调好同一设备存在冲突的多种需求.例如希望灯在夜间关闭,但是有人经过则应以较低亮度打开一段时间,如果遇到紧急情况(如厨房着火)则应当完全打开;

G5.多方信息.智能家居系统的功能边界应当不限于家庭的物理空间.系统不仅要能够处理家庭中存在的物理设备,也要能处理虚拟传感器和虚拟的设备,如情景模式、天气、时钟等.

2.2 HomeAssistant(HA)

本文的研究重点为探索TAP 编程的表示及其在现有执行引擎的实现,同时提供一定的规则有效性检查功能.因此,为更有效地实现G2 和G5 涉及的目标,SSRules 需要选择成熟开源的智能家居执行引擎来实现与各种(虚拟)设备的连接、实时监控、动态感知以及自动化管理等.

在开源智能家居系统中,HA 是基于Python 的成熟智能家居开源系统,能部署在任何能运行Python 3 的机器上,从树莓派到网络存储,还可以使用Docker 部署到其他系统上.它主要根据automations.yaml 等配置文件实现集中化的智能家居设备管理,设备支持度高,具有自动化、群组化、UI 客制化等高度定制化设置;同时,其开发者数量、版本更新速度在所有开源项目中也都属于佼佼者.因此,我们最终选取HA 作为SSRules 的执行引擎.

• 灵活的集成方式

在HA 中,物理设备和虚拟设备均被抽象为实体,带有状态的实体可以与状态对象关联.天气、太阳角度等均为HA 预置的虚拟实体;通过用户自定义或第三方集成,还可以实现如模式开关、空气质量、用户位置等虚拟传感器和动作器.实体上可以执行的动作被抽象为服务调用,除了HA 自带的值变化事件、服务调用事件等事件类型,第三方集成也能够发布其他自定义的事件.采用HA 可以自然地支持目标G5.

• 设备的动态管理

HA 接入设备的方式之一是MQTT Discovery,它提供对基于MQTT(message queuing telemetry transport)协议通信的设备的自动发现、配置和移除.MQTT 协议是一种基于TCP 的发布订阅协议,在物联网通信中使用较多.设备接入HA 时,每个设备只需按照HA 指定的格式配置其MQTT 通信模块,HA 即可间接从MQTT 代理获得配置信息并完成配置流程.若设备需要移除,则它可以更新状态信息将自己移除,也可以由HA 根据超时设置自动移除.因此,HA 提供实现G2 的基础,SSRules 需要主动与HA 交互真正达到G2.

• 高自由度的输入

HA 的规则输入语言为Trigger-Condition-Action(即Event-State→Event)范式,单规则中可以含有多触发器、多动作.动作不仅可以是与设备相关的服务调用,也可以是自定义的事件触发和状态值写入、HTTP 接口调用等,自由度很高.但是HA 的自动化规则的编写非常繁琐,用户难以使用其描述有优先级的功能需求,并且用户自行推理编写极易遗漏或写错.此外,由于HA 的实体状态和服务调用之间的松耦合,HA 提供运行时异常检查极其有限.HA 在G1,G3 和G4 方面较弱,因此,这也是SSRules 要重点解决的问题.

2.3 SSRules系统总体架构

SSRules 系统总体架构如图1 所示.整个系统通过HA 提供的接口与智能家居设备连接,包括通过MQTT 代理连接智能家居真实设备或模拟器.系统由离线的转译器子系统和在线的SSRules 运行时子系统组成:前者提供终端用户输入的SS 规则到HA 规则的转译,后者提供HA 抽象信息的获取和规则执行的有效性检查.SSRules引入Entity-Capability 抽象(见第2.4 节)来描述智能家居系统所能管控的设备(实体)及可管控的内容(能力),用户输入的SS 规则最终被SSRules 转化为HA 规则注入到HA 的配置文件并得以执行.

Fig.1 Overall structure of SSRules图1 SSRules 系统总体架构

• 抽象信息获取

SSRules 需要HA 中的实体、状态、服务的抽象信息用于SS 规则的转译和异常检测,这些信息由SSRules运行时子系统的抽象信息获取模块来提取和更新.该模块定期从HA 更新实体信息并检测变化情况,获取设备的动态信息(加入或离开),生成SSRules 所需的最新实体-能力抽象信息和动作翻译信息.

• 规则转换流程

SSRules 的用户交互模块根据实体-能力抽象信息将用户输入规则所需的信息以用户友好的方式呈现在前端界面中.用户完成编辑后,用户交互模块根据用户的输入生成SS 规则文件.接着,SSRules 运行时系统会调用可离线运行的转译器将SS 规则转译成HA 规则,再将其更新到HA 的automations.yml 中.

• 异常检测设计

当由SS 规则翻译得到HA 规则并开始执行之后,规则执行有效性检查模块会从HA 获取所关心的状态变化事件,定期获取全部实体的状态,检查实体状态及其状态变化是否符合SS 规则的描述,并将因网络/设备故障等问题导致的设备状态与SS 规则描述不相符等情况进行告警以及写入日志.

2.4 Entity-Capability抽象

一个智能家居系统所管理的设备可以包括真实物理设备(如空调)、虚拟设备(如天气、时钟等),还可以是人.SSRules 系统使用实体-能力抽象(entity-capability abstraction)来描述智能家居系统中各种设备的可感知和/ 或可控制的能力,记为,ND为实体总数.每个设备抽象为一个实体E(entity),每个实体由其ID e、一组能力C(capability)以及描述各能力状态之间转移关系的状态机M组成,即E=(e,C,M).

• 能力

每种能力表示单个可变化的只读或者可控属性.表4 列出了几种常见智能家居设备及其能力.每种能力可 表示为一个四元组(c,k,ro,J),其中:c是该能力在实体内的唯一标识;k表示该能力的状态值类型,可以是二值 (binary)/多值(set)/实数(numeric)等类型之一(实数可以细分成子界类型或实数区间等,本文为简便起见不作区 分);布尔量ro为真表示能力是只读的、为假表示是可控的;J表示一组关联的命令序列,其中每个元素是要执行 的命令代号.

• 状态机

每个实体的状态机由该实体每种能力c 的状态机组成:Mc=(Vc,Tc),其中,Vc是能力c 的状态值集合,Tc是状 态值之间的转移函数.

Table 4 Examples of entities and their capabilities表4 实体及能力举例

在缺省的Mc中,任意两个状态值之间存在条件为True 的转移(即无条件状态转移);若c 可控,则存在无条件 动作,它可触发任意两个状态值之间的状态转移.SSRules 系统会提供初始的Mc配置文件,其中提供部分常用 设备能力及其状态转移描述,用户也可以根据需要添加某个设备或者某一类设备的Mc补充信息.

根据c 的Mc抽象,可以进一步检测动作的执行前提,或者判断事件的可能性.例如,假设电扇和咖啡机的能力状态机如图2 所示:① 电扇的c2(风速)只有在其c1(开关)的取值为开时才可以接受改变风速的动作;② 咖啡机的咖啡状态仅在咖啡机的c1(开关)取值为开时才能从未准备好进入准备好状态.

Fig.2 The state machines for each capability of the fan and coffee machine图2 电扇和咖啡机的能力状态机

3 SSRules 编程范式及其到HA 规则的翻译

本节首先分析以状态触发器-状态动作(SS)风格设计SSRules 编程范式的可行性;然后给出SSRules 提供给终端用户使用的SS 规则范式的定义,分析它在应对表2 所列的10 种TAP 缺陷的能力;接着分析转译器面对的主要问题,并引入EE 中间范式作为SS 规则到HA 规则转换的桥梁;最后介绍SS 到EE 转译的关键算法.

3.1 SS范式的引入

由第1 节可知:终端用户不太能区分事件和状态,并且用户使用State-State 时序范式会比使用含Event 触发器的范式更易写对规则.为此,我们以状态为基础,通过规则分组、自动优先级等改进措施(详见第3.2 节)来提供“State-trigger State-action”编程范式,简称SS 范式.

• SS 范式的易写易改性

SS 范式可以较为简洁地表达用户日常常见需求;并且和Event-State→Event 相比,SS 范式写出的规则容易随需求的变更和细化进行修改.为了更清晰地表述这两种范式的区别,表5 给出了分别用两种范式描述夜灯开关的规则,其中,模式是HA 提供的虚拟传感器,有回家模式和离家模式两种取值.在SS 范式下,作用于夜灯的3条规则均作为子句按序置于“ FOR 夜灯”语句中,每个子句形如“EXPECT A [WHILE B]”,表示当B 成立(或永真)时,期望A 中各能力为指定的值;对于同一实体的多个EXPECT,SSRules 按从前往后以第一个WHILE 条件成立的EXPECT 子句所指定的期望状态为准.然而,当用Event-State→Event 表示时,为了正确表达所列出的几种情况的状态保持和它们之间的转移关系,需要写出9 条规则来细分情况.假设用户用SS 范式先写了后2 条规则,运转一段时间后他又添加第1 条保证离家模式下夜灯总是关闭的需求,在SS 范式下,这种添加是简单的;但是若使用Event-State→Event 达到相同目的,则需要在原先第3 条~第6 条、第8 条、第9 条这6 条规则基础之上新增3 条规则,并修改原先的规则细节(修改部分用粗体字表示),这样的编写和修改非常琐碎、易错.

Table 5 Example of comparing SS rules and Event-State→Event rules表5 SS 范式与Event-State→Event 范式的比较举例

• SS 范式的局限

SS 范式能表达大多数智能家居的场景需求,但是无法表达无状态或者难以抽象出状态的事件和动作(如无状态按钮、记录日志等).对于这类需求,目前仍需编写Event-State→Event 规则.因此,SSRules 将SS 范式转译为Event-State→Event,并允许两种范式共存.未来可以扩展降低这类需求编程难度的具体范式.

3.2 SS范式的定义

表6 的左部列出了SSRules 系统支持的SS 范式的抽象语法,其中:FOR 语句集结同一动作实体的所有规则,且约定组内靠前的规则优先级更高;每条规则(ssrule)包含在WHILE 子句指定的条件成立时,对该实体全部或部分能力的期望状态;多条规则按从前到后的次序、以第1 条满足WHILE 条件的规则中的EXPECT 子句来设置期望的实体能力状态;一般地,无 WHILE 子句的规则放在最后作为安全默认.Condition 中的“entityID.capName op value”,“historyOp timeperiod entityID.capName value”分别表示当前状态和历史状态型原子判断,其中,历史状态运算符historyOp 的4 种可能取值的含义举例如下.

• “WITHIN 5 分钟电扇.开关关”表示电扇的开关在5 分钟内曾经处于关闭状态,则该原子判断为真;

• “!WITHIN 5 分钟电扇.开关关”表示电扇的开关在5 分钟内不曾处于关闭状态,则该原子判断为真;

• “STAY 5 分钟电扇.开关开”表示电扇的开关在5 分钟内持续处于开启状态,则该原子判断为真;

• “!STAY 5 分钟电扇.开关关”表示电扇的开关在5 分钟内未一直处于开启状态,则该原子判断为真.

Table 6 Abstract syntax of paradigms of SS rules and EE rules used in SSRules表6 SSRules 系统使用的SS 范式和EE 范式的抽象语法

3.3 SS范式的缺陷避免能力分析

SS 范式天然地排除了表2 中所列的缺陷⑨、缺陷⑩这两种缺陷.对于在使用State-State 时序范式时可能存在的缺陷①~缺陷⑧这8 种缺陷,SS 范式的表示机制能完全避免缺陷①优先级冲突;SS 范式的表示及转译机制能部分解决或消除缺陷②安全默认偏差、缺陷③非瞬时动作、缺陷⑥重复触发,其附带效果可以辅助改善缺陷④缺少反向动作;对于缺陷⑤无限循环、缺陷⑦不确定时序等缺陷的检测,可以通过模型检查等方法在规则转译之前避免;由于难以提供通用的鉴别何谓矛盾的机制,因而SSRules 不能解决缺陷⑧矛盾的动作.下面分别讨论SS 范式应对缺陷①~缺陷③和缺陷⑥的措施.

(1) “按动作实体将规则分组、组内规则有序”可完全避免缺陷①优先级冲突

用户只需移动规则在组内的相对位置,免除显式设置优先级数值的困难.由于同一动作实体的各规则优先级不同,故无缺陷①(示例见3.1 节).

(2) “将配置的安全默认规则自动作为动作实体的最低优先级规则”可辅助消除缺陷②安全默认偏差

SSRules 提供可配的安全默认设置文件,其中的条目形如“实体/实体类ssrule”可描述指定实体或实体类的默认期望状态,SSRules 会自动将其追加到相应实体的规则集尾部,作为最低优先级规则.例如针对门锁可以配置默认安全规则“EXPECT (状态,锁定)”,则用户只需描述其他需求,如:

FOR 门锁 EXPECT (状态,未锁定) WHILE 人体传感器.状态==激活 [AND 其他安全条件]

而SSRules 会自动在尾部追加“EXPECT (状态,锁定)”.只要人体传感器不再激活,SSRules 就会按最后一条无条件子句的期望状态将门锁锁定.这种做法消除缺陷②的前提是要正确配置安全默认文件.

如果用户希望在人体传感器激活后2 分钟内均保持门锁解锁,可使用SS 范式提供的历史状态判断:

FOR 门锁 EXPECT (状态,未锁定) WHILE WITHIN 2 分钟人体传感器.状态激活 [AND 其他安全条件]

(3) “通过避免用户直接编写动作”可避免缺陷③非瞬时动作和缺陷⑥重复触发

在SSRules 中,状态转移所需要的动作的执行前提被描述在实体-能力抽象信息中,用户只能选择期望的状态,而无法写出有缺陷的程序造成对非瞬时动作的多次触发动作而进入不期望的状态.例如:针对冲泡咖啡这样的非瞬时动作,如果主人希望每天7:00 让咖啡机工作,且咖啡机工作完成后自动关闭,7:00~7:20 之外的时间不开启咖啡机,则用SS 范式编写的规则为:

FOR 咖啡机

EXPECT (开关,开) WHILE 时钟.时间>7:00 AND 时钟.时间<7:20 AND 咖啡机.咖啡状态==未准备好

EXPECT (开关,关)

当咖啡机开启后,即使咖啡未准备好,SSRules 转译后的HA 规则也保证不会再出现开启动作.而用户倘若用State-State→Event 范式,容易写出如下有缺陷的规则,造成咖啡机多次启动:

IF 咖啡未准备好 AND 时间处于7:00~7:20 之间 THEN 启动咖啡机

对于重复触发缺陷,能够用SS 范式表达的规则可以用上述类似的机制来避免;而不能够用SS 范式表达的规则,仍需要使用Event-State→Event 或者Event-Event→Event 范式来写(未来将对此提供更直观的编程方式).

3.4 转译器面对的问题及EE中间范式的引入

• 转译器面对的问题

如果要在一个仅支持Event-State→Event 范式的智能家居系统上实现对SS 范式规则的支持,需要将智能家居系统状态之间的转移和状态转移带来的新的状态设定与智能家居系统所支持的事件和动作关联起来,并且要尽可能避免重复触发、非瞬时动作等缺陷.这一翻译过程应该对用户不可见,是由系统自动完成的.此外,为了从翻译的主要算法中排除HA 规则描述的琐碎细节,以及让算法一般化以支持到其他平台的移植,SSRules 引入了EE 中间范式(基于Event-State→Event).从而:转译器的第1 阶段,SS→EE 的翻译可以避开HA 的语法及实现细节,重点是基于同一套实体-能力抽象将SS 范式表示的功能需求转化为EE 范式所表示的具体做法;而第2 阶段,EE→HA 的翻译则只需从较为抽象的EE 规则根据HA 的事件/条件描述方式、动作对应表,生成HA 所需的规则细节即可.

• EE 中间范式

表6 的右部列出了SSRules 系统转译中使用的EE 中间范式的抽象语法,其主要特点为:一条规则可以含有多个触发事件(event)、条件过滤(condition)和多个按顺序执行的动作(eeAction).event 包括状态值变化事件“entityID.capName FROM range TO range”和状态保持事件“entityID.capName STAYON value REACH timeperiod”:前者表示给定实体能力的取值从一个值集变迁到另一个值集,后者表示指定的实体能力保持给定值value 的时间长达timeperiod 时触发该事件.目前,SSRules 仅对二值类型的能力提供状态保持事件.EE 范式中条件过滤condition 的定义与SS 范式一样.

• EE 规则到HA 规则的转译

EE 规则到HA 规则的翻译是一一对应的,EE 规则的状态值变化事件可以对应到HA 的state_changed 事件和在HA 规则的condition 中对事件数据中的old_state 和new_state 的限制条件.EE 规则中的状态保持事件可以转译为在HA 中的延时执行和自定义事件触发.EE 规则中的条件表达式可以对应到HA 条件表达式中的相同树形结构.EE 规则中,实体能力的取值对应到HA 规则中的状态对象state 或者状态对象attribute 中的附加状态;EE 规则中,对实体能力的历史状态判断被对应到HA 规则中的自定义状态对象取值判断;EE 规则中的一个或多个动作被单个或组合对应到HA 中无参或带参的服务调用.

3.5 SS规则集与EE规则集的符号表示与一些定义

为了方便后文的说明和理解,我们引入表7 中的符号以及几个基本概念,这些符号和表6 定义的语法结构 一一对应.例如:GS对应于语法定义中的一个ssrulesGroup,RS对应于一个ssrule,RS中的C和X分别对应于 WHILE 子句中的条件表达式和EXPECT 子句中的期望状态组.wt 和st 分别表示“WITHIN”和“STAY”.

Table 7 Symbolic representation of SS ruleset and EE ruleset表7 SS 规则集合和EE 规则集合的符号表示

对于一个由ND个实体组成的智能家居系统,每个由三元组(e,C,M)描述.在某个时刻下,W的系统状态记为σ,它是各实体的各能力到状态值的映射,即σ(e,c)表示实体e的能力c 在该时刻的状态值.不论是SS 范式的程序GS,还是EE 范式的程序RE,都是对系统状态变迁的描述;而转译的目标是由GS得到RE,使得GS与RE满足一致性.在定义一致性之前,我们先定义系统抽象状态ω,然后定义SS 规则与系统抽象状态ω的关 系,包括规则在ω下是否激活、规则是否与ω兼容.

定义1(系统抽象状态).对于规则引擎来说,系统当前状态σ、当前时刻τnow以及状态变化轨迹T可抽象为一个三元组ω=(σ,τnow,T),称之为系统抽象状态.其中,T=((e1,c1,v1,τ1),,…,(en,cn,vn,τn)),(ei,ci,vi,τi)表示实体ei的能力ci在τi时刻变为vi(i∈{1,…,n}),它只记录状态值发生变化的特定实体的特定能力及其新状态.状态变化可能由外 部事件引起(如用户交互、环境变化),也可能由GS或RE执行动作序列引起.每当发生状态变迁时,都相当于T更新为,其中,τn+1为状态变迁发生时的τnow.

定义2(规则在系统抽象状态ω下激活).假设GS=(e,RS)为某动作实体e的SS 规则组,表示RS中期望状态组均为X的规则子集,当前的系统抽象状态为ω.称期望状态组相同的一组规则SXR 在ω下激活,是指该组内任 意一条规则RS激活;而规则RS在ω下激活,是指在该规则所在的规则组GS内,其前面的规则的条件(对应WHILE子句,即C)在ω下都未满足,而该规则的条件RS.C满足.

定义3(规则与系统抽象状态ω兼容).规则RS与系统抽象状态ω不兼容,是指在ω下RS激活且RS.X尚不成立;而RS与ω兼容,是指在ω下RS未激活或者RS.X已成立;一组规则与ω兼容,是指组内每条规则与ω都是兼容的;一 组规则与ω不兼容,是指组内存在与ω不兼容的规则.

实际的规则引擎提供的时间戳的精度是有限的.假设系统抽象状态ω中的时间戳都有最小时间单位(例如1秒),τnow以最小时间单位离散地更新.那么,对于规则集合执行方式的假设如下.

• SS 规则执行假设.假设无时序缺陷的规则组GS的执行方式为:每当发生状态变化,或者τnow变为新值之后,判断GS中是否存在与最新的ω不兼容的规则.如果存在这样的规则RS,说明其对应实体e不满足RS的期望状态组X,于是计算e上的需要执行的动作序列A,使得A执行后实体e的状态符合X;

• EE 规则执行假设.假设无时序缺陷的规则组RE的执行的方式为:设RE中的所有触发事件可分为状态 变化事件EI和状态保持事件EH这两种类型,每当出现与EI相符的状态变迁,或者每当τnow的更新触发了EH中的某个状态保持事件后,检查与触发事件相符的各条规则.如果存在RE,RS.C在ω下成立,则执行 RE.A.

定义4(SS 与EE 的一致性).称GS与RE一致是指:对于无时序缺陷的GS,RE,在上述规则执行假设下(且不存在超时、执行失败、规则重叠执行的情形),从与GS兼容的任意系统抽象状态ω开始,对于同样的、同时刻的、一次发生一个事件的外部事件序列,GS所产生的状态变迁序列和RE所产生的状态变迁序列一致.

与GS一致的RE不唯一,原因在于:① RE中不会被执行的规则不影响一致性;② 一个条件较弱的EE 规则(如一条规则,条件.C为时钟.状态==白天)可等价于多个条件更强的EE 规则(如等价于规则和,条件.C和.C分别为“时钟.状态==白天 AND 模式.状态==回家模式”和“时钟.状态==白天 AND 模式.状态==离家模式”);③ 一条EE 规则RE还可以等价于m条EE 规则,满足.E ;④ 逻辑表达式 有多种等价表述.

3.6 SS规则到EE规则的转译

图3 详细说明了SS 规则到EE 规则的转译算法实现,其中:图3(a)中的算法1 是总控算法;图3(b)是相应的 流程图,转译器的输入分别是左上角的实体-能力抽象信息W和右上角的SS 规则集合GS,输出是与输入SS 规则集对应的EE 规则集RE(右下角).

Fig.3 Algorithm and flowchart of translation from SS rules to EE rules图3 SS 规则到EE 规则转译算法与流程图

转译的具体流程为:

• SS 规则集解析器首先会解析用户输入的GS,并将解析结果传给动作序列信息生成模块;

• 然后,动作序列信息生成模块会将同一动作实体e的SS 规则序列GS=(e,RS)按照EXPECT 子句作用的期望状态组分类,期望状态组X相同的SS 规则组中的多条规则会放在一起处理:一方面,调用ConditionalActionsPairs(e,X,W)(见算法2),计算实体e上所有可能的动作序列Aj和每种动作序列的执行前提Cj,得到二元组集合PairsX={(Cj,Aj) |j∈{1,n}};另一方面,求出与规则组不兼容的条件ΨX(见算法1 第5 行),这是事件发生后、动作执行前系统抽象状态所应满足的条件;

• 接下来,事件筛选模块首先调用CandidateEvents(ΨX,W)(见算法3),根据ΨX生成一组候选事件E(这些事件可能对ΨX的成立与否有影响);然后,对E中的每个事件E调用ShouldRejectEvent(E,ΨX,W)(见算法4),依据缺省的事件筛选策略Pdefault判断该事件是否要排除掉,即:若E发生后ΨX不成立,则需将E排除;

在转译过程中,有多个环节需要与Z3 交互:在转译开始之前,转译器会根据实体-能力抽象构建Z3 数据类型和Z3 常量,并将对应关系填入Z3-Python 数据结构转换模块中的Z3 常量映射表;在转译过程中,事件筛选模块和EE 中间表示生成模块通过Z3 判定事件的可满足性;规则合并模块通过Z3 判断等价的条件部分,合并触发事件;可读性化简模块通过Z3 进行表达式化简以减少条件表达式长度.

下面结合算法2~算法5 详细介绍动作序列信息生成、事件筛选以及EE 中间表示生成这3 个关键模块.

算法2.“执行前提-动作序列”对集合的生成(ConditionalActionsPairs).

输入:实体e,期望状态组X,系统实体-能力抽象W;

输出:结构如{(C1,A1),…,(Cn,An)}的Pairs,表示实体e 满足Ci时要达到X需执行Ai.

• 动作序列信息生成模块

该模块会针对期望状态组X相同的SS 规则组,调用算法2 产生可能的动作序列及其执行前提集合PairsX={(Cj,Aj) |j∈{1,n}},并求出与不兼容的条件ΨX(见算法1 第5 行).算法2 的第2 行指出,X投影得到的能力集合XC 中的每个能力都必须是可控的.如第2.4 节所述,可控能力c 的状态机Mc=(Vc,Tc)中的转移函数,每个状态转移带有条件C以及要执行的命令J,C中可能会涉及其他实体能力.考虑到实际需求以及处理上的简便,假设XC 中各能力的状态转移条件C中依赖的其他能力遵循部分序关系,算法2 的第3行调用Reorder 函数将XC 中的能力按这种序关系重排得到,这样在第8 行就可以尝试按此顺序依次检查动作转移的可行性.另外,对于中的能力ci,其状态值域可能是无限的实数,而是有限的,故第5 行的SplitRangeByAction 函数会检查中到达期望值vi的各个状态转移动作J和转移条件C,将J,C相同的状态转移的起始状态涉及的各状态值划分到同一个子集,从而形成的有限子集划分Setsi,进而可能减少第7 行要处理的初始状态情形的数目,也能够减少后续规则合并的运算次数.

下面结合图4 的例子来解释.该例子的动作实体为“电扇”,有3 条SS 规则.这些规则按期望状态组X是否相同分成两组.以组为例,根据该组的X2“(开关,开)(风速,低)”和图2 电扇的状态机,按照算法2 求出到达X2的所有执行前提-动作序列对(图4 左下方的4 种动作序列).另一方面,该模块也要输出不兼容的条件用于稍后的事件筛选,=模式.状态==回家模式 AND 温湿度传感器.温度 >28°C AND (电扇.开关!=开OR 电扇.风速!=低).

Fig.4 Generating sequences of commands information图4 动作序列信息生成

• 事件筛选模块

该模块先使用算法3 生成候选事件,接着进一步使用算法4,根据系统可能的状态变迁对事件进行筛选.算法3 主要根据一个执行前要满足的条件C生成候选事件集,旨在以较低运算成本快速得到较小的待筛选事件集.其中:第2 行分别获取C中出现的实体能力集合ECs以及原子条件集合Catom,原子条件有当前状态判断(e,c,O,v)和历史状态判断(e,c,Oh,t,v)这两种形式(如表7);第4 行的SplitRangeByCond 则是根据Catom对实体E的能力 c 的状态值域Vc进行划分,将对所有原子条件的判断影响一致的状态取值划分到同一个子集,从而将实数类型的事件转移转化为了有限情形;第5 行~第7 行分别产生状态变化事件El和状态保持事件EH,能够涵盖C中出现的原子条件取值变化的情形.对于历史状态原子条件(e,c,Oh,t,v),由于只支持二值类型的能力c,在固定e,c,t下,Oh和v最多有8 种组合,我们为之按v的两种取值产生2 种状态保持事件,忽略Oh;而被忽略的Oh仍在C中,传 递到后续由算法5 产生的EE 规则RE=(E,C,A)中.这种状态保持事件EH能在状态迁移中快速知道实体能力保 持状态的时长,再结合C中的Oh进行状态保持的可满足性检查.

算法3.候选事件生成算法(CandidateEvents).

算法4.事件排除判定算法(ShouldRejectEvent).

算法5.同一动作序列的EE 规则生成(SameActionsRules).

算法4 旨在判断事件E可否发生并在发生后使得Ψ(不兼容的条件)为真(进而导致Ψ对应的某个动作序列的执行),需要根据筛选策略P做关于系统抽象状态的可满足性判定.筛选策略从保守到激进有多种策略:激进 的策略需要对事件发生之前的系统状态做出更强的假设,而保守的策略只需要相对较弱、能够更快判定的假 设.本文提出的默认策略Pdefault为:事件发生前Ψ为假(兼容),事件发生后Ψ为真(不兼容),且事件发生前 后Vs→Vd的事件转移条件CE成立,则该事件不会被排除.

Fig.5 Relation between current event filtering strategy and state transition图5 当前使用的事件筛选策略与状态转移的关系

• EE 中间表示生成模块

该模块调用算法5 生成EE 规则.以上一步骤筛选输出的事件E=(模式,状态,{离家模式},{回家模式})、规 则组的不兼容条件为例,对于图4 左下方中的4 个执行前提-动作序列对,都要判断执行前提是否可能 满足并生成规则.这里以4 对中的左上一对为例,由算法5 的第5 行得到的条件:“回家模式=回家模式 AND 温湿度传感器.温度>28°C AND (电扇.开关!=开 OR 电扇.风速!=低) AND (电扇.开关!=开 AND 电扇.风速!=低)”作为动作执行的完整前提条件,同时也应当是E发生后为真的条件,结合事件发生前应当为真的条件!Ψ,得到关于系统状态的断言并判定是可满足的,因此生成一条规则:

IF 模式.状态 FROM {离家模式} TO {回家模式} WHILE 温湿度传感器.温度>28°C AND

电扇.开关!=开 AND 电扇.风速!=低 THEN 电扇.开关 打开,电扇.风速 设定 低.

算法4 虽然和这里的算法5 都需要对一组系统状态的断言做可满足性求解,但是算法4 不考虑动作序列的 执行前提,其筛选结果能够被同一X的多个动作序列复用;且能够通过算法4 筛选的只有较少数量事件,这些事 件至少能够与一个动作序列组合成为规则.算法4 的存在,减少了转译过程中总的可满足性判定的次数.若直接将候选事件集合与多种动作序列的组合输入算法5,可能需要较多次数的不必要的求解.

4 方法评估

为了验证SSRules 的系统设计的有效性,基于Python 开发了SSRules 运行时子系统和离线转译器;基于Javascript 开发了SSRules 前端用户交互模块,方便终端用户设置SS 规则(如图6 左上方);同时,结合已有用户调查[15]构建智能家居使用情景,在这些场景下,就SSRules 系统运行情况和规则转译效果进行评估和讨论.

4.1 智能家居实验场景搭建

为了能够评估SSRules,需要将一些设备连接到HA,并让设备和环境产生足够多的状态转移,以覆盖各种可能的使用情形.但是,使用真实设备无法在短时间得到这样的测试场景并且调试不便.为此,我们基于Unity 游戏引擎开发了一个能接入HA 的智能家居模拟器HA-Simulator(其界面如图6 下方).利用HA-Simulator 可以将时间加速,以较高的速度发生系统的状态变化,并对温湿度/烟雾浓度等环境因素合理建模.这使得在短时间内测试大量的智能家居系统状态变迁并验证SSRules 成为可能.

在HA-Simulator 中模拟了12 种智能家居设备,布局和类型如图6 右上方所示,这些设备通过HA 的MQTT Discovery 集成方式接入HA.此外,在HA 中以自定义方式提供模式、天气和时钟这3 种虚拟设备.在模拟器中,同一房间内的设备受同一组环境变量(温度、湿度、烟雾浓度)的影响.模拟器可以设置环境变量改变的速度,进而间接改变虚拟传感器的取值;同时,模拟器中的设备可以被手动调节或者由模糊测试程序随机改变.

Fig.6 SSRules user interface,Smart home configuration and HA-simulator图6 SSRules 用户交互界面与智能家居场景配置和模拟器示意图

4.2 实验结果分析

• SS→HA 翻译对比

首先参考以往用户调查[15]中用户的智能家居需求,构造了10 组SS 规则作为测试集,其中:编号为1~6 的规则组不含历史状态,编号为T1~T4 的规则组含有历史状态.每一组规则至少有一个动作实体(设备),规则中会引用多个相关实体的状态.另外,规则组6、规则组T3、规则组T4 含有多个动作实体.按照当前的事件筛选策略,翻译前后的规则条数比较见表8.最终生成的HA 规则条数均多于SS 规则条数,比例为2 倍~4 倍.

• HA 规则运行覆盖率

在由SS 转译得到HA 规则之后,每一组HA 规则均在模拟器上运行20 分钟.除第1 组规则(包含空调与温湿度传感器)和第3 组规则(包含排气扇以及其他4 个相关实体)之外,其余组的HA 规则均全部被执行过.这说明SS→HA 转译器为其余8 组规则产生的HA 规则集中没有多余的规则,当前的事件筛选策略对于多数测试样例是比较合理的.对于含有多余规则的情形,而第1 组的4 条SS 规则为:

FOR 客厅空调

EXPECT (模式,制冷)(温度,18°C) WHILE 客厅温湿度传感器.温度>28°C

EXPECT (模式,制热)(温度,20°C) WHILE 客厅温湿度传感器.温度<10°C

EXPECT (模式,干燥) WHILE 客厅空调.模式!=制热 AND 客厅空调.模式!=制冷 AND 客厅温湿度传感器.湿度>65% 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 翻译对比和测试运行

原因在于:当前的筛选策略没有假设系统状态在事件发生之前的瞬间与整个规则组GS的描述相符,而仅仅假设系统状态与第3 条SS 规则的描述是兼容的(即第3 条规则未激活或者其期望状态已满足).但是在测试运行中,当温度低于10°C 或者高于28°C 时,系统状态持续与GS的描述相符,空调模式一定是制热(第2 条SS 规则激活)或者制冷(第1 条SS 规则激活),所以该条EE 规则是多余的,通过使用更激进的事件筛选策略可将其消除.

• HA 规则运行异常检测

表8 的后3 列分别是在20 分钟的随机测试下,各组的HA 规则的执行次数、异常检测模块发现的异常次数(系统状态不满足动作实体的SS 规则集合中激活的那一条SS 规则的期望状态)与总检测次数之比、是否存在连续两次检测到异常的情况.各组总的规则执行次数相差不大.异常检测模块目前以定时轮询方式实现,在20分钟内进行了1 200 次异常检查,未发现连续出现异常的情形.对于单次检测出现异常的情况,经过查看记录的状态日志和HA 规则的执行序列,这些异常均因网络延迟(动作执行不及时)造成.

5 相关工作

智能家居目前在市场上受到了广泛欢迎,越来越多的家庭配置了智能家居的设备.智能家居最吸引人的功能之一就是以应用程序的形式支持自定义自动化.但是由于用户未经过专业的培训,导致其自定义的规则存在一定的缺陷,甚至无法定制规则,这引起了人们对物联网增强生活的风险的担忧.这些风险远非仅仅是学术上的,更紧迫的是对用户的生命财产的威胁.Triger-Action 编程(TAP)是一种流行的终端用户编程方式,可以让用户实现其智能设备和云服务的交互.然而,用户有时并不能通过TAP 正确表达自己的意图并实现相应的功能.随着此类系统部署在越来越复杂的智慧家居场景中,用户必须能够识别编程错误并解决.

为了给终端用户提供更高效的服务,首先需要理解用户编程出现错误和规则冲突的原因.Huang 等人[6]认为,现有TAP 编程系统(如IFTTT)的过分简化限制了程序的表达能力.提出了改进IFTTT 界面的建议,以减轻因心理模型不正确而引起的问题.Corno 等人[28]认为:现有的TAP 接口界面暴露了太多功能,并迫使用户在众多混乱的网格菜单中进行搜索,导致用户无法得到原本需要的功能.为此,作者提出了EUDoptimizer,旨在以交互方式协助终端用户使用循环中的优化器来组合 IF-THEN 规则,减少了编写Triger-Action 规则所需的工作.Brackenbury 等人[17]提出了10 类常见的TAP 编程错误类型,作者发现:错误的存在,使参与者更难正确预测规则的行为.Davidoff 等人[29]发现,智能家居用户的日常活动与编程任务并不匹配.论文描述了家庭想要的控制,并提出了有助于终端用户编程系统实现这种控制的7 种设计原则.Brush 等人[20]认为:为使智能家居得到更广泛的使用,需要解决成本高昂、设备不灵活、客观理性差和安全保障这4 个障碍.论文还为进一步研究提供了几个方向,包括消除变化结构的需要、为用户提供简单的安全原语并支持家庭设备的组合.

因此,为减少终端用户编程的错误,TAP平台需要对用户生成TAP规则进行指导,并实现模型的检查,自动发现规则漏洞或冲突.Wang 等人[14]利用IFTTT 平台,探讨了在Triger-Action 平台中可能存在的规则漏洞,并借助于自然语言处理的方法推断Triger-Action 信息,实现了一个模型检查系统iRuler,用于发现物联网中的规则间漏洞.Celik 等人[19,30,31]认为,物联网中存在大量的设备交互.因此,不仅需要验证单个设备,还需要对设备的联合行为进行检查.Soteria[30]是一种静态分析系统,可从IoT 应用程序的源代码中提取状态模型,并通过模型检查来验证IoT 应用程序或IoT 环境是否符合已标识的属性.考虑到静态分析在估计物联网状态转换方面的局限性,Celik 等人[19]继续开发了一个动态分析系统IoTGuard,可通过在运行时监视设备执行行为,来强制执行已标识的属性,并可以通过阻止违反属性的设备操作,或在运行时要求用户批准或拒绝违规操作来应对属性违规.肖丁等人提出的基于知识图谱的KGIID 算法[32]能够检测TAP 编程模型中冲突的动作(隐式冲突).孟岩等人提出的HODETECT 检测工具[33]利用无线侧信道技术从智能家居应用中提取工作逻辑,并用有限状态自动机建模,通过在应用运行时监听无线加密流量的元数据来推测应用的执行状态,间接检测恶意应用.陈星等人[34]提出了智能家居情境感知服务的运行时建模与执行方法,能够降低开发者开发智能家居情境感知服务的难度和复杂度.

更进一步地,TAP 服务提供平台还需要对存在缺陷的规则进行修复.Nandi 等人[26]注意到,终端用户在编写规则时所犯的一个常见错误是触发器数量不足.因此,作者开发了TrigGen,它可以根据规则中的操作自动生成一组必要和充分的触发器,来帮助终端用户正确地编写规则.这种做法在一定程度上减少了意外行为和安全漏洞的发生率,但是其对于潜在冲突的检测还有提升空间.为帮助非专业的物联网用户系统地实现高置信度的实时HA-IoT 系统,Bu 等人[16]介绍了一种自动化端到端编程辅助框架MenShen,它能够检查自动化规则集是否违反规范,从而为用户提供可能的解决方案.Zave 等人[24]建议在运行时通过优先级来减少设备管理和交互的成本,并通过组合机制实现了目标.Zhang等人[15]将用户需要表达的属性转换为线性时序逻辑(LTL),自动合成满足属性的TAP 规则,并修复现有的TAP 规则.

6 总 结

基于规则的智能家居系统是目前流行的一种智能家居系统,而编写琐碎、修改困难、错误难以追踪是以往用户调查[15]所反映的问题.本文提出的SS 范式以及配套的SSRules 系统实现方式,使得用户规则编写和修改的复杂程度大为减低;同时,设计的SS 规则到HA 规则的转译算法使得输入的SS 规则能够在现有的智能家居系统HA 规则引擎上运行,并且通过辅助的SSRules 运行时模块,能够提供规则执行异常检测的能力.

未来的工作重点在以下两个方面:一方面,采用模型检测技术实现对SS 范式无法避免的缺陷进行检测,并设计辅助用户编写SS 规则和避免缺陷的实时反馈算法;另一方面,对于SS 范式目前不能够表达的需求,进行用户调查并寻找合适的多范式协同输入对策.