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

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

无条件子句的期望状态将门锁锁定.这种做法消除缺陷②的前提是要正确配置安全默认文件.
如果用户希望在人体传感器激活后 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 中无参或带参的服务调用.