物联网网关中轻量化规则引擎的设计与实现Word格式文档下载.docx
- 文档编号:19109517
- 上传时间:2023-01-03
- 格式:DOCX
- 页数:11
- 大小:1.37MB
物联网网关中轻量化规则引擎的设计与实现Word格式文档下载.docx
《物联网网关中轻量化规则引擎的设计与实现Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《物联网网关中轻量化规则引擎的设计与实现Word格式文档下载.docx(11页珍藏版)》请在冰豆网上搜索。
响应时间
中图分类号:
TP273.5
文献标志码:
A
Abstract:
InordertoapplytheInternetofThings(IoT)gatewaytovariousscenarios,alightweightrulesenginewasproposed,throughwhichuserscandefinepersonalizedrulesondemand.However,thelimitedresourceforcomputingandstoragepreventsthetraditionalrulesengine,suchasJRules,beingappliedontheIoTgatewaydirectly.Bythe“relatedfacts”attributeaddedtoeachruleandthemechanismof“AgentInference”,boththerunningtimeandtheresponsetimeoftherulesenginewerereduced.Addingthe“relatedfacts”attributetoeachrulecanreducethenumberoftherulesinvolvedinmatchingoperations,andthemechanismof“AgentInference”canreducethewaitingtimeforavailablerules.Basedonthesemethods,aFasterLightweightRulesEngine(FLRE)wasimplementedandappliedtoIoTgateways.Theexperimentsondifferentsizedatasetsshowedthattherunningefficiencywasincreasedby8%-30%withadding“relatedfacts”attribute,andtheresponsetimewasdecreasedby7%-35%withusingmechanismof“AgentInference”.TheevaluationshowsthetwomethodsareeffectivetoapplythelightweightrulesenginetotheIoTgateway.
英文关键词Keywords:
InternetofThings(IoT)gateway;
lightweightrulesengine;
runningtime;
responsetime
0引言
物联网网关是连接传感网络与通信网络的纽带,能够实现不同类型感知网络之间的协议转换[1]。
然而,通常物联网网关只适用在一个特定的应用场景下,无法广泛应用于不同应用场景。
用户也无法方便地根据一些暂时的、特定的需求作出任何个性化设置,而为用户提供个性化定制规则的服务,实现用户在特定场景中的业务需求很有必要。
规则引擎是一种嵌入在应用程序中的组件,用于将业务逻辑从代码中分离出来,使用预定义的语义模块编写规则,接受数据输入,并最终就编写好的规则作出决策[2]。
规则引擎的使用,不仅能有效减少系统开发人员对系统开发和维护所付出的代价,也使用户能根据实际业务需求定制符合特定场景的规则,扩展系统的使用范围[3]。
因此将规则引擎应用于物联网网关,能使物联网网关用户根据特定场景需求定义业务规则,从而使物联网网关能够应用于多个实际场景,满足用户需求。
目前已有一些成熟的商业化规则引擎产品,如ILOGJRules和Drools等。
ILOGJRules是一款业务规则管理软件(BusinessRulesManagementSystem,BRMS),通过预先提供的业务规则以及推理模块,该系统能够自动为用户和开发者提供决策结果(http:
//
规则引擎常用的匹配算法有Rete算法和Leaps算法。
Rete算法通过在匹配过程中保存匹配状态节点,避免后续匹配过程中重复匹配带来的时间损耗,来提高匹配效率,是一种以空间代价换取时间代价的匹配算法[5]。
基于Rete的衍生算法,分别通过哈希查找和建立索引以及扩展Rete算法的节点网络,来弥补Rete节点网络中的查找节点的速度慢并且只支持匹配布尔型、一阶逻辑等规则的不足[6-7]。
但Rete算法以及基于Rete算法的衍生算法,是在内存中用树结构去保存节点匹配的状态信息,并且在匹配过程中实例化了所有的事实元组,比较耗费存储资源,而Leaps算法能够弥补这一不足。
Leaps算法对元组采用Lazy评估的方式,只有在必要时才实例化元组[8]。
为提高规则引擎的运行效率,目前已有很多方法。
其中,用html文件定义规则集的方法[9],用xml文件表示的规则集转化为and/or树,再转换为01矩阵的方法[10],预先编译规则文件、详述规则文件内容、子功能包划分的方法[11],以及采用数据分类的方法[12]等,都能在不同程度上优化规则引擎的运行效率,但是主要针对于运行在PC或服务器上的规则引擎,应用于轻量级网关设备并不能表现出良好性能。
在移动设备上通过限制每个匹配周期中Rete算法匹配过程中的规则集和事实集的规模大小[4]的方法,虽然是针对于轻量级设备的,但没有对系统整体运行效率和响应速度进行研究,而物联网网关设备由于计算能力和存储能力有限,因此对运行效率的要求较高,同时由于用户通过网关设备和底层传感器设备进行交互,因此对其响应速度的要求也较高。
基于以上原因,本文对提高规则引擎运行速度和响应速度的方法进行探究,采用“关联事实”属性的方法来提高系统的运行效率,采用“议程推理”机制的实现方式来提高系统的响应速度。
基于这两种方法,在物联网网关上设计并实现了一种速度更快的轻量化规则引擎(FasterLightweightRulesEngine,FLRE)。
论文内容结构如下,FLRE的核心机制原理在第一部分具体阐述,在物联网网关上设计并实现FLRE的详细介绍在第二部分说明,第三部分是实验测试结果,并就结果进行了性能分析,最后一部分给出了总结。
1FLRE的核心机制
通常情况下,规则引擎的基本模块有:
数据模块(包括规则集和事实集)、推理模块(由匹配算法进行规则集与事实集之间的匹配)、议程模块(决定被触发规则的执行顺序)以及执行模块(执行被触发规则)。
规则集存储规则引擎的所有规则条目,事实集存储与规则引擎相关的变量状态,规则集和事实集的数据进入推理模块由匹配算法进行匹配。
经过匹配,将被完全触发的规则送入议程模块,由议程模块决定这些规则的执行顺序。
议程模块处理完之后,便送入执行模块依次执行这些规则对应的动作[11]。
对应的流程如图1所示。
为了在物联网网关上实现规则引擎,将现有规则引擎的实现方法进行优化,设计出能运行于物联网网关上的轻量化规则引擎;
同时,提出了基于“关联事实”属性的方法来提高该规则引擎的运行效率,提出了“议程推理”机制的实现方法来提高该规则引擎的响应速度。
下面分别介绍这两种方法的实现原理:
1.1“关联事实”属性
事实集是系统中事实条目的集合,对应于物联网网关底层传感器的状态信息;
规则集是系统中规则条目的集合,对应于物联网网关用户定义的业务规则。
一条事实表示每个事实变量的状态值,通常用“……是(或等于)……”的形式来表示,比如事实条目“空气温度等于20摄氏度”,就表示当前空气温度的值为20℃。
一条规则由条件部分和动作部分构成,通常用“如果……,则……”的形式表示,条件部分为“如果……”,动作部分为“则……”。
其中,条件部分和动作部分均可包含一个或多个条件元素,多个条件元素之间用“并且”或“或者”相连接,来表示这些条件元素之间的逻辑关系。
每个条件元素的值都是一个布尔变量,条件部分则是多个布尔变量表达式的逻辑组合,只有当条件部分的逻辑结果为真时,才会执行动作部分的动作。
每个条件元素关联一个事实变量,包含多个条件元素的规则就会关联多个事实变量,将这一个或者多个关联的事实变量作为该条规则的“关联事实”属性的值,也即“关联事实”属性的值就是一个或多个与该规则相关联的事实变量的集合。
例如,规则“如果时间是晚上十点以后并且灯泡开,则关闭灯泡”,与该规则相关联的事实就是“时间和灯泡状态”,该规则“关联事实”属性的值就为“时间,灯泡状态”。
采用添加“关联事实”属性的方法,就是当事实集里的某条事实与规则集里的某条规则进行匹配时,若该事实属于该规则的“关联事实”属性表示的事实集合,则表明该事实与该规则关联,该事实与该规则才进行匹配;
若不属于该规则的“关联事实”,则跳过该条规则,选取规则集中的下一条规则进行匹配。
以上述规则为例,若该事实是表示“时间”或者表示“灯泡状态”,则才会与该规则进行匹配;
否则不参与这条规则的匹配。
由于每条规则有其相应的“关联事实”属性,因此该规则集就有其对应的“关联事实”集,在事实集与规则集匹配时,属于该“关联事实”集的事实才会与该规则集匹配。
由于参与匹配的事实子集完全是与规则集相关联的事实,因此在事实集与规则集匹配的过程中,能够有效避免不必要的匹配过程,从而减少了不必要的时间损耗,进而显著提高整个规则引擎的运行效率。
下面用一个例子来说明该方法对运行效率的提高。
现用大写字母表示规则,小写字母表示事实,用m表示事实集的条目数,n表示规则集的条目数,ci表示第i条事实总共属于ci条规则的“关联事实”(其中i=1,2,…,n)。
假如事实集有事实a、b、c,规则集有规则A、B、C、D、E、F、G,即m=3,n=7。
规则集与事实集的关联关系如图2所示。
事实a分别属于规则A、C、G的关联事实,事实b分别属于规则C、D、E的关联事实,事实c分别属于规则B、D、F的关联事实,即c1=3,c2=3,c3=3。
则采用“关联事实”的方法之后,规则集与事实集对应的匹配次数用的树结构如图3所示。
图2表示未添加“关联事实”属性时,匹配次数的树结构图,其匹配次数为m×
n=3×
7=21。
图3表示添加“关联事实”属性之后,匹配次数的树结构图,其匹配次数大大减少,匹配次数为c1+c2+c3=3+3+3=9。
也即为每条规则添加“关联事实”属性之后,能够减少的匹配次数为m×
n-∑mi=0ci(ci
1.2“议程推理”机制
在传统规则引擎的执行过程中,事实集和规则集经过“推理”模块的模式匹配后,匹配结果会送入“议程”模块,由“议程”模块来决定被触发的规则的执行顺序。
这样会使较先触发的规则在所有规则匹配完之后才得到执行,从而降低了物联网网关的响应速度。
因此,为了提高网关的响应速度,将传统的“议程”模块的功能融入到“推理”模块中,形成新的“议程推理”机制来实现,即在规则集和事实集进入“推理”模块进行模式匹配之前,规则集按优先级顺序进入推理模块,因此越先被触发到的规则优先级越高。
由于最先被触发的规则一定是当前规则集中优先级最高的规则,此时将被触发的规则立即执行,而不是等到规则集中的所有规则全部匹配结束之后再执行,这样就能减少被触发规则等待执行的时间。
用这种边匹配边执行的方式,能够大大提高规则引擎的响应速度,从而有效地保证物联网网关的实时性,满足实际场景的需求。
用以下例子来说明该方法对响应时间的提高。
由于无论采用“推理”和“议程”模块串行执行还是采用“议程推理”机制的实现方法,都需要执行被触发的规则,所以在此处不考虑执行规则所花费的时间。
假设经过匹配算法的运算之后,共有m条规则被触发,Ti(i=1,2,…,m)表示第i条规则在Ti时刻被触发。
因此采用“推理”和“议程”模块串行执行时,被触发规则的等待时间和为∑mi=1(Tm-Ti),所以采用“议程推理”机制的设计方式,就能减少这些不必要的等待时间,从而缩短系统响应时间,系统减少的平均响应时间为1m∑mi=1(Tm-Ti)。
在实际应用中,这种方式能够减少系统的平均响应时间,提高系统的响应速度。
2物联网网关上FLRE的设计实现
物联网网关底层接入一些常用的传感器设备,通过物联网网关,用户能够远程获取并控制传感器设备的状态信息。
在将规则引擎应用于实际物联网网关的过程中,传感器的实时状态信息或实时数据信息作为规则引擎事实集的事实条目,用户创建的应用场景的业务规则作为规则引擎规则集的规则条目。
通过网关上实现的规则引擎,用户就能够根据不同应用场景中的不同需求灵活控制传感器的状态。
实现平台是基于Android4.0.3操作系统的物联网网关平台,采用SQLite数据库来存储数据信息。
例如数据库中存储的网关传感器的数据状态信息如表1所示。
用户定义的规则条目如表2所示。
表2中:
relateFact列为该规则的关联事实;
state列为规则状态,若为0则该规则未被触发,若为1则被触发;
Priority列为规则优先级;
timestamp列为创建时间。
网关通过规则引擎模块,便能根据用户定义的上述规则条目和底层传感器的实时状态去自动控制传感器,方便用户在不用应用场景中使用。
基于“关联事实”属性的方法和“议程推理”机制的设计方法,在物联网网关上设计了FLRE的实现方法。
基于图1中规则引擎的实现方法,首先按照规则集对应的“关联事实”集,在事实集里面找出与规则集关联的事实子集。
然后,对于规则集中的规则条目,先按照优先级级数越高则优先级越高的原则将规则条目进行排序,若有优先级级数相同的规则,再按照创建时间越早则优先级越高的原则。
接着将排序后的规则集和事实子集按照匹配算法进行匹配,在匹配的过程中,若有被完全触发的规则则立即执行,然后再继续回到匹配过程进行匹配。
整个过程如图4所示。
FLRE的模式匹配模块采用Leaps算法实现。
Leaps算法的原理就是将插入系统中的所有事实条目按照先后顺序放入栈中,然后取出栈顶事实条目去依次匹配规则集中的规则,在此过程中,若有被完全触发的规则,则执行该规则,然后返回至刚才匹配的位置,若所有规则均已匹配完毕,则弹出该栈顶事实。
如此循环往复,直到事实栈为空即可[8]。
在该物联网网关上,基于上述两种方法和Leaps算法,设计出FLRE的实现流程如图5所示。
根据图5,规则集在进行匹配之前,先按照优先级顺序排列,然后才与事实集进行匹配。
而事实与规则进行匹配时,先判断该事实是否属于该规则的“关联事实”,若属于,则进行匹配;
若不属于,则跳过该规则,继续匹配规则集中的下一条规则。
3实验测试结果
由于所实现的FLRE的性能体现在运行速度和响应速度上,因此分别从运行时间和平均响应时间两个方面进行测试。
测试的参数是事实条目10条,规则条目依次为5,10,20,30,40,50。
3.1运行时间
运行时间是指从事实集和规则集进入模式匹配到执行完所有被触发规则所需要的时间。
分别在采用传统的独立“议程”模块和“议程推理”机制两种实现方式下,测试了对规则添加“关联事实”属性和未添加“关联事实”属性两种情况下的运行时间,运行结果如图6所示。
由图6可知,无论是采用独立“议程”模块的设计方式还是采用“议程推理”机制的设计方式,在不同大小规模的规则集中,为每条规则添加“关联事实”属性后系统运行时间比未添加“关联事实”属性时运行时间短,在不同规模数据集下,运行效率提高8%~30%不等。
因此添加“关联事实”属性能够提高运行效率。
在为每条规则添加“关联事实”属性的前提下,分别比较了采用独立“议程”模块的设计方式和采用“议程推理”机制的设计方式两种情况下运行时间的差异,测试结果如图7所示。
由图7可知,当为每条规则添加“关联事实”属性时,采用“议程推理”机制的设计方式时系统运行时间比采用独立“议程”模块设计方式时系统运行时间短。
因此为每条规则添加“关联事实”属性并且采用“议程推理”机制的设计方式,能够提高系统运行效率。
3.2平均响应时间
平均响应时间是指系统响应完所有被触发的规则花费的时间与被触发规则条目的比值。
分别在没有为每条规则添加“关联事实”属性和添加“关联事实”属性两种方式下,测试了采用独立“议程”模块设计方式和采用“议程推理”机制的设计方式两种情况下的平均响应时间,运行结果如图8所示。
由图8可知,无论是为每条规则添加“关联事实”属性还是不添加“关联事实”属性,在不同大小规模的规则集下,系统采用“议程推理”机制的设计方式时,其平均响应时间都比独立“议程”模块设计方式时短,在不同规模数据集下,平均响应时间提高7%~35%不等。
因此,采用“议程推理”机制的设计方式,能够提高系统的响应速度。
在采用“议程推理”机制的设计方式下,比较为每条规则添加“关联事实”属性和未添加“关联事实”属性两种情况下的平均响应时间,测试结果如图9所示。
由图9可知,当采用“推理议程”机制的设计方式时,为每条规则添加“关联事实”属性时平均响应时间比未添加“关联事实”属性时平均响应时间短。
由图7和图9可知,当采用“议程推理”机制,并且为每条规则添加“关联事实”属性时,不仅能够提高系统的运行效率,也能缩短系统的平均响应时间。
4结语
本文通过同时采用“议程推理”机制的设计方式和为每条规则添加“关联事实”属性的方法,在物联网网关上设计并实现的轻量化规则引擎,不仅能够很好地运行在计算能力和存储能力有限的物联网网关这种轻量级设备上,而且也表现出了较好的运行效率和响应速度,使网关能够满足用户自定义需求规则的目的。
在研究过程中,发现由于规则集和事实集本身的内容对匹配所花费的时间有一定的影响,即如果事实集和规则集分别数量相等,但内容不同,其匹配过程所花费的时间也会不同,导致在不同的数据规模下优化效果不同。
更精确的定量结果,还需在现有的系统上进行更多的研究和实验。
参考文献:
[1]CHENH,JIAX,LIH.AbriefintroductiontoIoTgateway[C]//Proceedingsofthe2011IETInternationalConferenceonCommunicationTechnologyandApplication.Piscataway:
IEEEPress,2011:
610-613.
[2]GENGQ.Researchofadomainorientedruleengine[D].Beijing:
BeihangUniversity,2009.(耿庆宦.面向领域的规则引擎的研究[D].北京:
北京航空航天大学,2009.)
[3]ZHANGY,ZHAOJ,XINGC.AnextensibleframeworkforInternetbookingapplicationbasedonruleengine[C]//ProceedingsoftheSixthWebInformationSystemsandApplicationsConference.Piscataway:
IEEEPress,2009:
139-142.
[4]CHOIC,PARKI,HYUNS,etal.MiRE:
aminimalruleengineforcontextawaremobiledevices[C]//ProceedingsoftheThirdInternationalConferenceonDigitalInformationManagement.Piscataway:
IEEEPress,2008:
172-177.
[5]FORGECL.Rete:
afastalgorithmforthemanypattern/manyobjectpatternmatchproblem[J].ArtificialIntelligence,1982,19
(1):
17-37.
[6]XIAOD,ZHONGX.Improvingretealgorithmtoenhanceperformanceofruleenginesystems[C]//Proceedingsofthe2010InternationalConferenceonComputerDesignandApplications.Piscataway:
IEEEPress,2010:
572-575.
[7]SOTTARAD,MELLOP,PROCTORM.AconfigurableReteOOengineforreasoningwithdifferenttypesofimperfectinformation[J].IEEETransactionsonKnowledgeandDataEngineering,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 联网 网关 量化 规则 引擎 设计 实现
![提示](https://static.bdocx.com/images/bang_tan.gif)