一种基于规则的物联网报警方法和系统
技术领域
本发明涉及物联网领域,具体涉及一种基于规则的物联网报警方法和系统。
背景技术
2005年,ITU在突尼斯举行的信息社会世界峰会(WSIS)上正式确定了“物联网”的概念,并随后发布了《ITUInternetreports2005——theInternetofThings》,介绍了物联网的特征、相关的技术、面临的挑战。物联网的技术构成主要包括感知与标识技术、网络与通信技术、计算与服务技术及管理与支撑技术四大体系。一个物联网可能包含类型繁多的、相互连接的设备,这些设备不断产生海量的信号,如RFID阅读器的数据、温度传感器的数据等。这些直接获取来的信号称为原始事件。但是这些信息的层次太低,粒度太细,无法表达一个完整的业务含义,上层应用无法直接处理原始事件。只有类似“室温超标1摄氏度”、“大门已关闭”这样含义明确的事件才是用户可以理解的、有意义的。
针对物联网环境下的应用而言,如何利用从海量的传感器数据中过滤出的有价值数据,实现复杂的业务逻辑,采取灵活的处置流程措施,仍然是一个迫切需要解决的问题。现有的大多数系统将业务逻辑硬编码在系统实现中。
然而,业务规则千变万化,一旦修改代码,需要重新编译、构建、部署系统,代价巨大;而且业务人员不懂编程语言,开发人员不熟悉业务规则,双方的沟通成本高,且极容易引入错误,为系统埋下隐患。
发明内容
针对现有技术的不足,本发明提供了一种基于规则的物联网报警方法和系统,本发明能够基于规则引擎实现复杂的业务逻辑,方便采取灵活的处置措施解决物联网报警。
为实现上述目的,本发明通过以下技术方案予以实现:
一种基于规则的物联网报警方法,该方法包括:
采集报警数据;
预先订阅一个以上类型的感兴趣报警数据;
从采集的报警数据中挑选出预先订阅的一个以上类型的感兴趣报警数据;
将一个以上类型的感兴趣报警数据整合成预定格式的报警信息;
利用规则引擎,确定报警消息的报警级别;
根据报警消息的报警级别,执行相应的处置流程。
其中,在所述将一个以上类型的感兴趣报警数据整合成预定格式的报警信息之前,利用事件处理引擎,根据一定的匹配规则,先将一个以上类型的感兴趣报警数据过滤出基本故障事件和复杂故障事件。
其中,所述利用规则引擎,确定报警消息的报警级别包括:
根据实际业务,制定规则,根据制定的规则判定报警消息的报警级别。
其中,所述根据报警消息的报警级别,执行相应的处置流程包括:
当报警消息的报警级别为3级以下时,根据报警处置业务流程,完成报警消息的处理;当报警消息的报警级别为4级时,发送人工处理请求,由人工完成报警消息的处理;当报警消息的报警级别不为1至4中的任何一个时,执行预先设置的报警处理。
一种基于规则的物联网报警系统,该系统包括:传感器单元、数据分发单元、数据接收单元、判定单元和执行单元,其中:
传感器单元,用于采集报警数据;
数据分发单元,用于从采集的报警数据中挑选出预先订阅的一个以上类型的感兴趣报警数据,将一个以上类型的感兴趣报警数据分发给数据接收单元;
数据接收单元,用于将一个以上类型的感兴趣报警数据整合成预定格式的报警消息,发送给判定单元;
判定单元,用于基于规则引擎,确定报警消息的报警级别,将带有报警级别的报警消息传给执行单元;
执行单元,用于针对报警消息的报警级别,执行相应的处置流程。
其中,所述数据分发单元包括:面向简单对象访问协议的SOAP绑定模块和消息路由模块,其中,
SOAP绑定模块,用于从传感器采集的报警数据中挑选出预先订阅的一个以上类型的感兴趣报警数据,并发送给消息路由模块。
消息路由模块,用于将挑选出的一个以上的感兴趣报警数据转发给数据接收单元。
其中,所述数据接收单元包括面向简单对象访问协议的SOAP绑定模块、消息路由模块、事件过滤模块和消息解析模块,其中,
SOAP绑定模块,用于向数据分发单元订阅一个以上类型的感兴趣报警数据;
消息路由模块,用于接收数据分发单元转发来的一个以上类型的感兴趣报警数据,并发送给事件过滤模块;
事件过滤模块,用于利用事件处理引擎,根据一定的匹配规则,从一个以上类型的感兴趣报警数据中过滤出基本故障事件和复杂故障事件;
消息解析模块,用于将基本故障事件和复杂故障事件整合成预定格式的报警消息,发送给判定单元。
其中,所述判定单元包括:
规则文件编写模块,用于根据实际业务,制定规则;
规则引擎判定模块,用于根据制定的规则,判定报警消息的报警级别;
判定结果传送模块,用于将带有报警级别的报警消息传送给执行单元。
其中,所述执行单元包括:
报警自动处理模块,用于在报警消息的报警级别为3级以下时,根据报警处置业务流程,完成报警消息的处理;
报警人工处理模块,用于在报警消息的报警级别为4级时,发送人工处理请求,由人工完成报警信息的处理;
报警默认处理模块,用于在报警消息的报警级别不为1至4中的任何一个时,执行预先设置的报警处理。
本发明至少具有如下的有益效果:
1、本发明基于规则引擎,判定报警消息的报警级别,利用这种高可读性、用户友好的规则进行报警级别判定,使得报警处置流程可以较灵活的适应业务逻辑的变化。另外,相对于以往将业务逻辑编码在系统中方式,规则引擎使得业务规则和系统本身达到完全解耦,使得业务规则的变化不再需要做大幅度变动,只需要修改规则文件即可,符合用户寻求灵活,方便业务逻辑的需求,在此基础之上,本发明中的规则文件可以使用自然语言描述业务逻辑,这使得本系统的技术门槛大大降低,业务人员只需要懂简单的英语,就可以写出可执行的规则,这满足了用户追求高可读性和易编写的规则的要求。
2、使用事件处理引擎,可以从大量数据中提取和过滤有价值的基本事件,或者更进一步,将基本事件组合成复杂事件,这样系统可以有针对性的对这些事件进行分析,将系统从海量数据中解放出来,同时也达到了计算资源的高效使用。
3、把廉价的传感器安装在需要检测的设备上,采集各种各样的数据,并且采集时间可达到全天候,不会遗漏任何数据。
4、基于订阅的消息传递可以尽可能的减少系统的耦合程度,对外提供透明的接口,大大降低了系统的复杂度,使得整个系统由消息驱动。当然,实施本发明的任一方法或产品不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明实施例1中一种基于规则的物联网报警方法的流程图;
图2是本发明实施例2中一种基于规则的物联网报警方法的流程图;
图3是本发明实施例2中一种高报警级别的报警消息流程处理示意图;
图4是本发明实施例2中完成一条报警消息的处理流程图;
图5是本发明实施例3中一种基于规则的物联网报警系统的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整的描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
实施例1
本发明的实施例1提出了一种基于规则的物联网报警方法,参见图1,该方法包括:
步骤101:采集报警数据。
步骤102:预先订阅一个以上类型的感兴趣报警数据。
步骤103:从采集的报警数据中挑选出预先订阅的一个以上类型的感兴趣报警数据。
步骤104:将一个以上类型的感兴趣报警数据整合成预定格式的报警信息。
步骤105:利用规则引擎,确定报警消息的报警级别。
步骤106:根据报警消息的报警级别,执行相应的处置流程。
可见,本发明实施例基于规则引擎,判定报警消息的报警级别,利用这种高可读性、用户友好的规则进行报警级别判定,使得报警处置流程可以较灵活的适应业务逻辑的变化。另外,相对于以往将业务逻辑编码在系统中方式,规则引擎使得业务规则和系统本身达到完全解耦,使得业务规则的变化不再需要做大幅度变动,只需要修改规则文件即可,符合用户寻求灵活,方便业务逻辑的需求,在此基础之上,本发明中的规则文件可以使用自然语言描述业务逻辑,这使得本系统的技术门槛大大降低,业务人员只需要懂简单的英语,就可以写出可执行的规则,这满足了用户追求高可读性和易编写的规则的要求。
实施例2
本发明实施例2通过一个例子,来更为详细的说明本发明一个较佳实施例的实现过程,参见图2,该过程包括如下步骤:
步骤201:采集报警数据。
在本步骤中,利用待检测设备上的各种类型的传感器采集原始的报警数据。
步骤202:预先订阅一个以上类型的感兴趣报警数据。
在本步骤中,预先订阅一个以上类型的感兴趣报警数据,例如,预先订阅温度报警数据和气压报警数据这两种类型的感兴趣报警数据。
基于订阅的消息传递可以尽可能的减少系统的耦合程度,对外提供透明的接口,大大降低了系统的复杂度,使得整个系统由消息驱动。
步骤203:从采集的报警数据中挑选出预先订阅的一个以上类型的感兴趣报警数据。
在本步骤中,从采集的原始报警数据中选取预先订阅的温度报警数据和气压报警数据这两种感兴趣数据。
步骤204:将一个以上类型的感兴趣报警数据过滤出基本故障事件和复杂故障事件。
在本步骤中,由于故障情况毕竟是少数,选取的温度报警数据和气压报警数据大部分都是正常数据,且数据量巨大。这些数据不都是本故障报警系统所关注的。如果对它们全部都进行处理,既无必要,也会浪费宝贵的计算资源。利用事件处理引擎,根据故障报警事件的匹配规则,从选取的温度报警数据和气压报警数据中过滤出需要关注的基本故障事件和复杂故障事件。比如说,如果一个采集量超过了上限或下线,那么这就是一个基本故障事件;如果多个相关联的采集量都发生了超限异常,那么某种根据特定的业务规则,可以将这样的现象定义为一个复杂故障事件。
步骤205:将过滤出的基本故障事件和复杂故障事件整合成预定格式的报警信息。
步骤206:编写规则文件。
在本步骤中,可以使用Drools的DSL语言,它使得业务领域的术语能够转换成简单易懂的类自然语言来进行表达。在Drools中DSL相当于一个转换器,它能在两种语言之间建立映射。本系统通过配置这个转换器,将自然语言转换成可执行的规则语言。业务规则可以通过标准的英语描述,可读性强,大大降低了系统的使用门槛,提高了系统的用户友好度。一个简单的DSL规则如下所示:
针对报警流程(图3)中的第四个级别,可以建立如下DSL映射文件:
[when]ThereisanInstancewithfieldinset"{value}"=i:Instance("{value}".contains(field))
[then]Setitsleveltobe"{value}"=i.setAlarmLevel("{value}");
利用映射文件,规则描述如下:
Rule"AlarmruleNo.1"
When
ThereisanalarmMessagewith“type”inset“complexType”
Then
Setitsleveltobe4
End
上例的含义是:“如果有一条报警消息,它的type域在集合complexType中,那么就把该消息的报警级别设置为4”。上面只是整个规则的一小部分,不过从中可以看出,业务规则清晰易懂,系统用户只要懂简单的英语,就能读懂和编写业务规则。加上规则和系统本身的解耦,规则的变化不会影响到系统,使得系统的灵活性和稳定性大大增强;同时也减轻了用户的负担,增加了系统的用户友好度。
步骤207:按照规则文件,确定报警消息的报警级别。
在本步骤中,报警消息的Level域是空的,根据规则文件,判定报警消息的严重程度,对Level域进行赋值。
步骤208:根据报警消息的报警级别,执行相应的处置流程。
在本步骤中,举例来说明完成一条报警消息的处置流程,该流程如图3所示,包括以下步骤:
2080、带有报警级别的报警消息到来时,报警处置业务流程被激活。
这里,报警消息含有报警处置必须的相关信息,如:设备名称(location)、参数类型(type)、报警发生时间(startTime)、报警参数值(alarmValue)、报警说明(alarmInfo)、报警级别(level)。
2081、业务流程被激活后,会议根据报警消息携带的级别,去执行相对应的流程分支。
2082、每一个分支的第一个动作都是赋值,执行赋值(Assign)操作将报警消息的状态获取出来。
Ⅰ、如果报警消息级别为1,说明故障不太严重,调用SendControlCommand服务,向相应设备发送控制消息,令其自动调节即可;
Ⅱ、如果报警消息级别为2,说明故障严重程度升级,除了调用SendControlCommand服务之外,还需要调用SendMail服务,向设备的管理员发送提示邮件,令其立即关注故障状况;
Ⅲ、如果报警消息级别为3,说明故障已经比较严重,除了调用SendControlCommand和SendMail服务之外,因为发送邮件的实时性较低,所以还需要调用SendTextMessage服务,向设备的管理员的移动电话发送短信,令其立即处理故障状况;
Ⅳ、如果报警消息级别为4,说明故障一直持续,情况没有改善。这用情况比较严重,此时已经不能让设备和管理员自主调节,而是需要调用SendJbpmRequest服务,向值班经理发送人工处置请求,由值班经理手动人工处理。SendJbpmRequest是一个基于JBPM的人工处置流程。JBPM是一种基于J2EE的轻量级工作流管理平台,它最大的特点是对人工任务有良好的支持,而不像BPEL那样主要面向自动化、无人为干涉的流程。
在该流程中,首先将报警信息通知值班经理,值班经理决定异常的严重程度,当比较严重如水管爆裂等事件发生时,值班经理上报事件到公司总部如果需要停止供暖,则通知受影响住户,并进行紧急维修,当维修成功之后恢复供暖。其流程如图4所示。
Ⅴ、如果不在1到4之间,说明故障级别未定义,则调用Default服务,执行默认操作
2083、调用分支完成后,流程结束并返回。
实施例3:
本发明的实施例3还提出了一种基于规则的物联网报警系统,参见图5,该系统包括如下:
传感器单元301,用于采集报警数据;
数据分发单元302,用于从采集的报警数据中挑选出预先订阅的一个以上类型的感兴趣报警数据,将一个以上类型的感兴趣报警数据分发给数据接收单元303:
数据接收单元303,用于将一个以上类型的感兴趣报警数据整合成预定格式的报警消息,发送给判定单元304;
判定单元304,用于利用规则引擎,确定报警消息的报警级别,将带有报警级别的报警消息传给执行单元305;
执行单元305,用于针对报警消息的报警级别,执行相应的处置流程。
其中,数据分发单元302包括SOAP绑定模块3020和消息路由模块3021。
SOAP绑定模块3020,用于从传感器采集的报警数据中挑选出预先订阅的一个以上类型的感兴趣报警数据,并发送给消息路由模块3021;
消息路由模块3021,用于将挑选出的一个以上的感兴趣报警数据转发给数据接收单元。
其中,所述数据接收单元303包括SOAP绑定模块3030、消息路由模块3031、事件过滤模块3032和消息解析模块3033。
SOAP绑定模块3030,用于向数据分发单元302订阅一个以上类型的感兴趣报警数据。
消息路由模块3031,用于接收数据分发单元302转发来的一个以上类型的感兴趣报警数据,并发送给事件过滤模块3032。
事件过滤模块3032,用于利用事件处理引擎,根据一定的匹配规则,从一个以上类型的感兴趣报警数据中过滤出基本故障事件和复杂故障事件。
消息解析模块3033,用于将基本故障事件和复杂故障事件整合成预定格式的报警消息,发送给判定单元304。
其中,判定单元304包括规则文件编写模块3040、规则引擎判定模块3041和判定结果传送模块3042。
规则文件编写模块3040,用于根据实际业务,制定规则。
规则引擎判定模块3041,用于根据制定的规则,判定报警消息的报警级别。
判定结果传送模块3042,用于将带有报警级别的报警消息传送给执行单元305。
其中,所述执行单元305包括报警自动处理模块3050、报警人工处理模块3051和报警默认处理模块3052。
报警自动处理模块3050,用于在报警消息的报警级别为3及以下时,根据报警处置业务流程,完成报警消息的处理;
报警人工处理模块3051,用于在报警消息的报警级别为4级时,发送人工处理请求,由人工完成报警信息的处理;
报警默认处理模块3052,用于在报警消息的报警级别不为1至4中的任何一个时,执行预先设置的报警处理。
以上实施例仅用于说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。