一种基于智能家居的规则冲突避免机制

常莹　朱庆华

摘要：将规则系统引入智能家居平台很好地解决了将控制逻辑与程序代码分离的问题，用户可以根据需求方便的添加修改规则。但是随着智能家居系统的不断扩大，系统设备的增多以及带来的用戶需求的日益复杂，规则系统也变得更加繁杂，不同规则之间可能发生冲突。本文介绍了智能家居系统中的核心部分——规则系统，研究了规则引擎的工作方式，揭示了规则冲突问题的重要性。对智能家居中的规则冲突问题进行了研究分析，并提出了避免规则冲突问题的方法。

关键词：智能家居;规则冲突;冲突检测

中图分类号：G642        文献标识码：A

文章编号：1009-3044（2021）01-0199-03

1规则系统

在智能家居系统中，规则系统是一个核心模块，用户是通过制定规则来享受系统带来的便利，对于系统中规则的存储，规则的分解、匹配，规则间冲突的避免和检测以及规则的执行都是通过规则系统来完成的。规则系统在本文提及的智能家居结构中位于业务层，承上启下，发挥着非常重要的作用。规则系统包括规则存储模块，规则引擎模块和冲突检测模块三个部分。规则存储模块即规则库，可以用来匹配以及规则展示。规则引擎对规则库和事件库进行匹配，在匹配前需要规则冲突检测模块对规则库进行检测，如果有冲突，则需要修改规则以避免规则冲突带来的问题，可见规则冲突检测对系统的重要性。如果匹配成功，则触发规则执行模块去执行动作部分。

1.1 规则引擎技术

规则引擎起源于基于规则的专家系统，它是在推理引擎的基础上发展而来的，是一种嵌入在程序内的组件[1]。专家系统实际上是一个计算机程序，只是它包含着特定领域大量的知识和经验，通过推理可以得到类似专家级别的效果。

规则引擎一般包括工作内存、匹配器、规则集容器和执行器几个部分，其结构如图所示。（1）规则集容器连接着存储规则的数据库，用于将规则数据库中的规则取出来以待匹配，是匹配前的规则缓存模块。（2）工作内存则相当于一个事件库，其中存放着当前的环境参数，设备状态等事件信息。（3）匹配器将规则集容器和工作内存连接起来，分别对两者中的规则和事件进行匹配，若匹配成功，则可以执行该规则。（4）执行器则存储着匹配成功的规则，并且系统会去按一定顺序执行这个规则的动作部分。

规则引擎的工作流程如下所示：

1）调用规则冲突检测模块对规则数据库中的规则进行冲突检测，如果冲突，则将冲突规则返回修改;

2）从规则库中取出需要匹配的规则放到规则集容器，并转化成一定的形式以便匹配;

3）更新工作内存中的数据，即更新事件库;

4）匹配器对容器中规则和工作内存中的事件进行匹配，并将匹配成功的规则加入执行器;

5）执行器按照某种预定顺序去执行匹配成功规则的动作。

规则引擎适合比较复杂的而且没有明确清晰的解决方案的场景，对于需要动态更新，基于一定数据量能够很快做出决策的场景也非常适用。目前常见的商业引擎有ILOG的JRules和Jess，商业引擎做得比较成熟好用，稳定性高，但缺点是其价格非常昂贵。作为一个商业引擎，Jess并不是开源的，但是好在对于学术研究用途是免费提供的，只有商业用途时才需要付费，因此基于Jess的研究项目非常多。而Drools则是目前最活跃的开源引擎。

1.2 Rete算法

在规则引擎中，规则匹配模块尤为重要，其匹配质量和效率直接影响着规则引擎的好坏。常用模匹配算法有Rete，Leaps，Treat等。目前许多规则引擎的匹配算法都是基于1982年Forgy提出的RETE算法改进而成的[2]。

Rete算法是一种高效的前向链型匹配算法，它是基于时间冗余性和结构相似性这两个基本的假设。（1）时间冗余性，即在每个执行周期，往往只有一小部分的事实发生了变化，如果每次对所有的事实重新匹配，效率非常低下，因此可以记录下已经匹配过得事实，然后下次匹配只对变化的事实进行匹配。（2）结构相似性，是指许多规则之间往往具有比较相似的模式和模式组。

在产生式系统（productionsystem）中，被处理的数据称为工作内存（workingmemory），一条产生式规则分为两个部分前提（LHS）和结论（RHS），进行匹配的主要流程可以分为：

（1）匹配找出符合条件部分的workingmemory集合;

（2）然后选择一个条件被满足的规则;

（3）执行该规则的动作部分;

（4）返回（1）;

Rete算法主要是通过构建一个匹配网络来提升匹配步骤的效率，该匹配网络分为aloha网络和beta网络两个部分进行匹配。Rete算法的核心思路是将在过去匹配过程中的全部信息保存下来，用于再次匹配时的筛选，以便提高匹配效率。在不断循环匹配中，通过记住已经匹配过的事实，然后只去计算新删除或新添加的事实所引发的变化，仅通过变化的事实去匹配其对应的规则，因为每次事实的变化相对于规则来说是少量，因此这种从事实去匹配规则的演绎推理能有效降低计算量，提升匹配效率。但随之而来的问题就是需要占用大量的内存资源，运行成本增加。

2规则冲突类型分析

所谓规则，就相当于一条完整的控制指令。基于物联网的智能家居传感网络可以从当前环境状态下获取相关环境状态参数以及设备状态参数，如果满足用户设定的触发条件，控制系统便控制设备对当前环境或者设备状态进行改变。规则可以分为条件（Condition）部分和动作（Action）部分。即IF条件部分满足，THEN执行动作部分的相应动作。

本文可以将规则抽象成是由用户（User），触发器（Triggers）和执行器（Actuators），环境实体（Environments）四个部分组成[3]。其中用户中包括用户ID以及用户权限，触发器中包括条件中涉及的环境实体的ID，触发条件，以及该触发条件优先级。环境实体中包括环境实体ID，以及它前状态和后状态。执行器中包括执行动作中涉及环境实体的ID以及动作（Action）。通过对上述规则模型分析，可以发现规则之间可能会有相似触发条件，相似执行动作，相反执行动作等关系，进一步总结这些关系得出了下述几种规则冲突类型：

1）执行动作相反冲突。执行动作相反冲突即当前状态下，两条规则的条件部分都得到满足，并且两规则优先级相同，即两条规则同时被触发时，如果两条规则的执行器是对相同环境实体采取相反的动作，即发生了执行动作相反冲突。例如下面两条规则：

RA：当温度大于28℃时，则打开空调;

RB：当温度大于28℃时，则关闭空调。

2）影子冲突。影子冲突即两条规则的触发条件部分有相互包含的关系，而且两规则的执行器对同一环境实体采取了相同的操作。比如：

RA：如果室内PM2.5浓度>35mg/m?，则打开空气净化器;

RB：如果室内PM2.5浓度>45mg/m?，则打开空气净化器。

如果当前室内的PM2.5是50mg/m?，两条规则皆符合。但考虑当前室内PM2.5浓度是40mg/m?时，显然未满足RB的触发条件，但满足RA要打开空气净化器的条件，显然这两条规则之间是冲突的。

3）依赖冲突。依赖冲突是指RA的触发条件恰好是RB执行后的状态，而RB的触发条件也恰好是RA执行后的状态，两条规则的触发条件和对方的执行后状态互为依赖型。例如下面两条规则：

RA：如果打开照明灯光，则关闭窗帘;

RB：如果关闭了窗帘，则打开照明灯光。

上述两条规则如果单独存在，则可以正常运行，但是如果两条规则同时存在，一旦一条规则被触发，比如打开了灯光，那么将会关闭窗帘，相应地B规则也会被触发，这样两条规则会不断进行循环执行，占用系统资源，影响系统稳定性。在依赖冲突里，上述两条规则间的依赖是一种直接依赖，还有可能就是有三条或三条以上的规则之间存在着间接依赖关系。

3规则模型

本文是基于本体和SWRL规则语言对智能家居规则冲突问题进行研究的，因此将使用SWRL建立规则。

SWRL是一种语义网规则表示语言，由W3C在2004年提出。SWRL结合了本体语言OWLDL，OWLLite与规则标记语言SWRLML[4]。SWRL允许用户编写基于OWL概念表示的规则，而且它能够提供比OWL语言更加强大的推理能力。在语义上，SWRL是建立在与OWL相同的描述逻辑基础上，并在执行推理時提供类似的强形式保证。

在形式上，一条SWRL规则分为两个部分，一个前提（antecedent）与一个结论（consequent）。Antecedent部分在owl文件中使用Body标签，consequent在owl文件中使用Head标签。即SWRL规则可以抽象为如下所示的形式：

Antecedent—>Consequent。

其中Body和Head部分都可以包含一个或者多个原子（atoms）。所以也可以将规则表示成：

atom^atom^atom^…—>atom^atom^…

它所表示的意思是只要前提部分的所有atoms都为真，就可以得到结论部分所有的atoms也为真。一个atom是形如：

P（arg1，arg2，arg3…argn）

其中P是一个谓词符号，其中arg1， arg2，…，argn是表达式的项或参数。在SWRL中，支持五种类型的谓词：OWL类、OWL属性、数据类型、数据范围和内置函数。参数可以是OWL个体或数据值或引用它们的变量。SWRL中的所有变量都被视为普遍的量化，其范围仅限于给定的规则。

在SWRL中约定了一种规范，用户是按照这些规范去方便的制定规则的。它主要分为四个部分：Imp、Atom、Variable和Building。Imp包括head和body，head表示的是这条规则的结果部分，body则是这个结果需要满足的所有条件的交，在head和body中包含着的一个个实例则是由原子和变量（variable）组成的。在Atom中包含了几种限制表达式，其主要可分为以下几类：C（x），P（x，y）， sameAs（x，y） 以及differentFrom（x，y）。C表示的是OWL中的类，P是OWL属性，括号中的x，y可以是变量，可以是owl个体（owlindividual），也可以是owl数据值。SameAs表示x和y相等，diffrentfrom表示x和y不相等。Building是SWRL内置的模块化元件，在编写规则时可以直接使用。

SWRL中提供了七种atoms：ClassAtoms、IndividualPropertyatoms、DataValuedPropertyatoms、DifferentIndividualsatoms、SameIndividualatoms、Built-inatoms、DataRangeatoms。下面列出一条简单的SWRL规则实例：

hasParent（？x ， ？y）^hasBrother（？y ， ？z）->hasUncle（？x，？z）

这条规则是说如果y是x的父亲并且z是y的兄弟，那么我们便可以得到z是x的叔叔。根据上述其中不同的atoms以及它们之间自由的组合，我们便可以使用SWRL构建强大的规则库，结合本体知识库和SWRL，便可以使用推理机进行推理，挖掘中知识库中隐藏的大量信息。

如果一条规则条件部分包含了“∧”和“∨”这样的逻辑运算符，那么规则往往可以通过这种逻辑组合表示的特别复杂。复杂的规则形式会使冲突检测变得困难，为解决这一问题，我们可以使用析取范式来将复杂的规则转化为基本的简单规则。比如形如：f：A1∧A2∧（A3∨（A4∧A5））->B1∧B2的一条规则，通过拆分化简可以将其分解为下述两条简单规则：：A1∧A2∧A3->B1∧B2与A1∧A2∧A4∧A5->B1∧B2，这样处理后会方便进行冲突检测。

4一种基于智能家居的规则冲突避免机制

基于智能家居系统中规则冲突的常见性以及带来的不良后果，必须有一套规则冲突避免和检测机制。在规则系统中，如果对所有的规则都进行规则冲突检测的话，一是如果规则库非常庞大，那么所带来的时间开销和资源开销也会大为增加。二是其实没有必要进行全部检测，在日常场景中，我们对各种家居设备操作的频率以及它们的重要性都有非常大的差异，因此可以在检测之前采用一定方法进行规则冲突的避免。可以基于优先级或者是“先进后出”的方法去执行规则。“先进后出”即一种类似栈机制的一种方法，即后添加的规则先被激活，先添加的后被激活，由于这种方式并不适合多任务并发的智能家居场景，因此暂不做讨论。下面将提出基于场景优先级和基于用户优先级的规则冲突避免方法。

4.1 基于场景优先级

在智能家居系统中，用户可以将所需要执行的任务划分为多个场景类型，每一个任务就对应着一条规则，而为每一条规则设定一个场景类型。比如现在有如下两条规则，RA：当检测到室内烟雾浓度高时，就打开窗户并打开烟雾报警;RB：当打开音响时，关闭窗户。那么如果在烟雾浓度過高时，恰好打开了音响，这时两条规则便发生了冲突。但明显RA涉及安全，更为重要，需要优先执行，因此我们可以将这两条规则加入不同的场景类型中，并按照类型的重要性为场景类型设置不同的优先级，正好避免了这种冲突的发生[5]。

我们可以将场景划分为以下四种场景类型：

1）安全场景。R1：如果在夜间，窗户或者门被打开，则打开灯光，打开报警器;

2）娱乐场景。R2：如果打开家庭影院，则关闭窗帘，关闭灯光。

3）能量场景。R3：当家用电器总功率超过2000W时且温度低于28℃时，则关闭空调。

4）环境场景。如果有人在家且室内PM2.5浓度>35mg/m?，则打开空气净化器。

根据不同的需求，用户可以灵活的设定各场景的优先级。例如：当家里有成人且孩子在家时，我们可以把娱乐场景设置到最高优先级，安全场景次之。当家中有老人时我们又可将环境场景设置到最高优先级，为老人的健康提供一定的服务。

对于不同场景类型的规则之间的冲突使用优先级便可以避免。对于同一场景类型中规则之间的冲突，我们可以使用冲突检测算法进行检测，此时由于进行的场景划分，冲突检测时需要遍历的规则数也将减少，效率也会提高。

4.2 基于用户优先级

此外，还可以进行基于用户优先级的冲突避免。在家庭中往往有多个人同时生活，相应的也将会有多个用户可以制定规则。由于不同用户需求不同，因此不同用户之间制定的规则具有随机性，很可能会发生冲突。如果现在系统中存在两个用户，A用户制定了一条R1：在早晨七点到八点之间打开窗户进行通风。B用户制定了一条R2：在晚上10点后到早晨10点前，关闭窗户，以便睡眠不被噪声干扰。那么在这两段时间重合的区域，系统将会发生规则冲突。为解决上述问题，可以采用类似设置用户权限的方法，为A，B用户设定不同的优先级，当不同用户的规则发生冲突时，系统将选择执行优先级高的用户的规则，从而可以避免这种类型的冲突发生。

可见，上述基于优先级的规则冲突避免机制很好地将各用户，各需求场景之间的冲突进行了避免，可以使得不同用户不同场景规则的添加变得更为丰富灵活同时又不影响规则的执行，也降低了冲突检测模块的复杂度。其主要分为两个阶段，首先是场景任务的添加阶段，此时涉及了同一类型场景的冲突检测，如果有冲突，则提醒用户进行规则修改，如果没有冲突，则进行场景任务执行阶段，此阶段便可以基于预设的场景优先级以及用户优先级，决定执行哪些规则。

参考文献：

[1] 刘伟. Java规则引擎——Drools的介绍及应用[J]. 网络新媒体技术， 2005，26（6）：717-721.

[2] Forgy CL. Rete： a fast algorithm for the many pattern/many object pattern match problem[M]. Expert systems. IEEE Computer Society Press， 1991：547-559.

[3] SunY， WangX， LuoH， etal. Conflict Detection Scheme Based on Formal Rule Model for Smart Building Systems[J]. IEEE Transactionson Human-Machine Systems， 2015， 45（2）：215-227.

[4] 金保华， 林青， 付中举， 等. 基于SWRL的应急案例库的知识表示及推理方法研究[J]. 科学技术与工程， 2012， 12（33）：9049-9055.

[5] 潘平安. 基于Zigbee和Android的智能家居系统的研究与实现[D].华东交通大学.2017

【通联编辑：王力】