具体实施方式

现有的规则引擎处理业务数据的规则都是设定好的，并由规则引擎统一加载，在业务场景发生改变的情况下，无法根据业务场景的变化为与其对应的规则引擎提供适用格式的规则，若是通过编码实现新的业务场景的规则的需求，会造成大量重复工作。并且，现有的规则引擎支持的也是一些简单的物联网（Internet of things，简称IOT）设备上报的数据转发路由策略规则，实现的规则也比较简单。针对上述问题，本发明实施例提供了一种车联网业务数据的处理方法。

图1是根据本发明一个实施例的车联网业务数据的处理方法的流程图。参见图1，车联网业务数据的处理方法可包括以下步骤S102至步骤S108。

步骤S102：获取车联网业务数据。

在本步骤中，车联网业务数据可以从接入网络的IHU（Infotainment Head Unit，信息娱乐主机）、DHU（娱乐主机和仪表的集成机器）、TCAM(车机设备)、手机、SuperBox（行车大脑）以及SuperBrain（车上的智能设备）等设备中获取。接入网络的IHU、DHU、TCAM、手机、SuperBox以及SuperBrain等设备可以向车辆发送数据。

步骤S104：确定处理车联网业务数据的规则引擎的类型，根据规则引擎的类型确定规则引擎对应的表达式的目标格式。

在本步骤中，规则引擎即指根据上述的IHU、DHU、TCAM以及手机等设备上报的每条数据进行基于云端预定义规则集的实时分析，当数据满足某个规则判断条件时，触发相应的执行动作。

步骤S106：将车联网业务数据对应的规则转化成目标格式的表达式。

在本步骤中，不同类型的规则引擎所适用的表达式的格式可能不同，因此，需要将车联网业务数据对应的规则转化成目标格式的表达式以适用于对应的规则引擎。

步骤S108：将目标格式的表达式发送至规则引擎，以使规则引擎通过目标格式的表达式对车联网业务数据进行处理。

在本实施例中，获取车联网业务数据，确定处理车联网业务数据的规则引擎的类型，根据规则引擎的类型确定规则引擎对应的表达式的目标格式，将车联网业务数据对应的规则转化成目标格式的表达式，将目标格式的表达式发送至规则引擎，以使规则引擎通过目标格式的表达式对车联网业务数据进行处理，这种处理车联网业务数据的方式，可以根据车联网业务数据的变化，为处理车联网业务数据的相应类型的规则引擎提供目标格式的表达式，从而适配不同类型规则引擎的需求。并且，规则引擎可以动态加载和动态解析目标格式的表达式，即规则引擎可以及时加载和及时解析生效目标格式的表达式，在车联网业务数据符合规则时，执行相应的动作，从而更加灵活高效地处理车联网业务数据。另外，随着车联网业务数据地增多和改变，这种处理车联网业务数据的方式，可以避免大量重复的编码工作。

在本发明一个实施例中，确定处理车联网业务数据的规则引擎的类型，可包括：根据车联网业务数据的属性确定规则引擎的类型；和/或根据车联网业务数据所属的场景确定规则引擎的类型。

在本实施例中，在确定处理车联网业务数据的规则引擎的类型时，可以根据车联网业务数据的属性确定规则引擎的类型，车联网业务数据的属性可以包括业务数据的来源、单位等，也可以根据车联网业务数据所属的场景确定规则引擎的类型，即根据车联网业务数据所属的规则确定规则引擎的类型。车联网业务数据所属的场景可以包括车端告警场景、用户出行场景以及各种运营需求场景等，举例来说，车联网业务数据所属的场景为满足A地和B地的VIP用户发放奖励，便可以根据该场景确定处理这个车联网业务数据的规则引擎的类型。上述确定处理车联网业务数据的规则引擎的类型的方式可以比较灵活准确地确定规则引擎的类型。

在本发明一个实施例中，当确定处理车联网业务数据的规则引擎的类型为自定义类型时，根据规则引擎的类型确定规则引擎对应的表达式的目标格式，可包括：

根据规则引擎的自定义类型确定规则引擎对应的表达式的目标格式为JSON格式；

将车联网业务数据对应的规则转化成目标格式的表达式，可包括：

将车联网业务数据对应的规则转化成JSON格式的表达式。

在本实施例中，自定义类型的规则引擎可以理解为自研类型的规则引擎，即指基于自己的代码实现车联网业务数据处理的规则引擎。自定义类型的规则引擎可以加载和解析JSON格式的表达式，对车联网业务数据进行处理。下面通过具体示例说明JSON格式的表达式。

示例1：满足北京上海的vip用户发放奖励

示例2：给总里程总计达到10000KM，上海，北京，杭州的VIP车主发放奖励

JSON格式的表达式的规则说明可以如表1所示。

表1

通过表1，本领域的技术人员能够理解示例1和示例2的具体含义。

在本发明一个实施例中，当确定处理车联网业务数据的规则引擎的类型为mysql或Flink时，根据规则引擎的类型确定规则引擎对应的表达式的目标格式，可包括：

根据规则引擎的mysql或Flink类型确定规则引擎对应的表达式的目标格式为类SQL格式；

将车联网业务数据对应的规则转化成目标格式的表达式，可包括：

将车联网业务数据对应的规则转化成JSON格式的表达式，将JSON格式的表达式转化为类SQL格式的表达式。

在本实施例中，类SQL格式的表达式表示类似数据库的SQL查询语句，作为本领域的技术人员，通过下面的具体示例能够理解类SQL格式的具体含义。类SQL相对于数据库的SQL查询语句于来说，类SQL的使用方式更加灵活。Flink类型的规则引擎的数据处理是基于内存临时表，只能够识别类SQL或SQL格式的表达式。当表达式的目标格式为类SQL格式时，之所以先将车联网业务数据对应的规则转化成JSON格式的表达式，再将JSON格式的表达式转化为类SQL格式的表达式，相对于将规则直接转化为类SQL格式的表达式，可以保证转化后的类SQL格式的表达式更加准确。下面通过具体示例说明类SQL格式的表达式。

将上述示例1的JSON格式的表达式转化为类SQL格式的表达式，如下：

select * from tempTable where (address = “北京” and vip = true) or(address = “上海” and vip = true)

将上述示例2的JSON格式的表达式转化为类SQL格式的表达式，如下：

select * from tempTable where mileage >= 10000 and vip = true andaddress in (’上海’, ’北京’, ’杭州’)。

在本发明一个实施例中，车联网业务数据对应的规则为可配置的。

在本实施例中，车联网业务数据对应的规则为可配置的，即使车联网业务数据的处理规则发生改变，也可以重新配置车联网业务数据对应的新的规则，避免重新编码的工作，也使修改车联网业务数据对应的规则的过程更加简单。在修改车联网业务数据对应的规则后，可以及时的生成新的表达式，并将新的表达式发送至对应的规则引擎，由规则引擎加载和解析，即完成规则的动态表达和实现。

在本发明一个具体实施例中，车联网业务数据对应的规则可以通过网页（WorldWide Web，WEB）进行配置，通过网页配置车联网业务数据对应的规则，使配置规则的方式更加简单易学。当然，也可以通过其他方式配置车联网业务数据对应的规则，例如，通过文本的形式配置车联网业务数据对应的规则。

通过网页配置车联网业务数据对应的规则的方式可以参见图2，图2是根据本发明一个实施例的通过网页配置规则的示意图。在图2中，向下的箭头可表示下拉按钮，通过选择事件添加了事件A、事件B和事件C。事件A包括的规则为当日时间小于用户注册时间超过30，30的单位可以根据实际需要进行设定，如设置为分钟、小时等。事件B包括的规则为用户当前所在城市在集合[code1，code2]中，code1和code2表示城市名称，当然集合还可以包括code3、code4等。事件C包括的规则为用户ID绑定车辆时间大于规则阈值，规则阈值可以根据实际需要进行设定。图2中的表达式为A and（B or C），在对表达式进行解析的时候，往往是从最外层开始进行层次的遍历解析，“and”操作符对应的数组解析规则为数组中每个元素的操作符比较结果必须全为true，则解析结果返回true，否则解析结果返回false，“or”操作符对应的数组解析规则为数组中任何一个元素的操作符比较结果为true，则解析结果返回true，数组所有元素的操作符比较结果都为false，则解析结果返回false。图2的表达式即满足事件A的规则，并且满足事件B或事件C的规则，则返回true。

具体地，可以将表达式理解为一个数据树形结构图，参见图3，图3是根据本发明一个实施例的表达式的数据树形结构的示意图。在图3中，最上方（即最外层）为“or”，在“or”的下方（第二层）包括“and”和“or”，可以理解，最外层的“or”对应的第二层的数组“and”和“or”中，当第二层的数组“and”和“or”中有一个解析为true时，最外层的“or”的解析结果便为true。第二层的“and”包含“=”、“key/value”和“in”、“key/value”两个条件，当这两个条件均解析为true时，第二层的“and”的返回结果为true。第二层的“or”包含“>=”、“key/value”和“like”、“key/value”两个条件，当这两个条件中的一个解析为true时，第二层的“or”的返回结果为true。当然，图3中的包含的条件的个数仅为示意，并不对本发明造成任何限制，还可以包括其他条件，其他条件采用省略号代替。

在发明一个实施例中，不同格式的表达式之间能够相互转化。

在本实施例中，当规则引擎通过目标格式的表达式对车联网业务数据进行处理后，若还需要其他类型的规则引擎通过表达式对车联网业务数据进行处理，此时，只需要将目标格式的表达式转化成与其他类型的规则引擎对应的格式的表达式，无需重新将规则转化成其他类型的规则引擎对应的格式的表达式，这种处理方式可以减少转化的步骤，提高转化的效率，进而提高车联网业务数据的处理效率。具体地，例如，处理车联网业务数据的规则引擎的类型为自定义类型时，将车联网业务数据对应的规则转化成JSON格式的表达式，之后，若还需要Flink类型的规则引擎对车联网业务数据进行处理，可以直接将JSON格式的表达式转化成类SQL格式的表达式，无需重新将规则转化为JSON格式的表达式，再转化为类SQL格式的表达式。又例如，处理车联网业务数据的规则引擎的类型为Flink类型时，将车联网业务数据对应的规则转化成JSON格式的表达式，再转化为类SQL格式的表达式，之后，若还需要自定义类型的规则引擎对车联网业务数据进行处理，可以直接将类SQL格式的表达式转化成JSON格式的表达式。

图4是根据本发明另一个实施例的车联网业务数据的处理方法的架构示意图。参见图4，以TCAM（车机设备）为例，描述TCAM上报的车联网业务数据的处理方法。TCAM（车机设备）在车的整个点火过程中实时上报车况数据，云端通过统一TCP网关接收上报车况，并转发影子服务。影子服务解析报文后转发Kafka(消息中间件)消息通道的集群。规则判定服务基于流式处理框架，采用普通计算模式消费Kafka（消息中间件）集群批量取得大批数据提交到Flink集群进行计算。Flink集群根据设定规则动态转成类SQL规则表达式对上报的每一条数据进行处理，过滤。对于命中规则的数据分发到实际的动作执行服务（Action）。动作执行服务执行相应的业务，如执行积分服务。通过对TCAM（车机设备）上报的车联网业务数据的处理方法的介绍，本领域的技术人员可以理解上述架构示意图，也可以理解其他设备上报车联网业务数据的处理过程。

图5是根据本发明另一个实施例的车联网业务数据的处理方法的规则平台的结构示意图。具体地，可以通过具体示例对规则平台的工作过程进行描述。例如，当驾驶里程达到10000KM，发放积分奖励，里程>10000KM为规则判定，发放积分奖励为动作执行。用户驾驶里程数据通过车上TCAM设备持续上报到融合分发服务，数据处理集中到规则引擎（Flink）。行驶里程一直再变化，当规则判定里程>10000KM时，触发动作执行服务发放积分奖励的动作，流程执行完毕。其中类SQL规则表达式用于Flink规则引擎规则判定的数据过滤。规则判定条件可以是多个条件组合形成。

在上述的实施例中，前端配置的规则可以在规则设定后台服务实现。前端配置的规则动态转Json格式和类Sql格式的规则表达式也可以在规则设定后台服务实现。规则判定分发服务启动后，导入规则表达式，监听kafka（消息中间件）上指定的消息通道以接收信息，并对接收的每一条消息进行解析，判断该消息是否符合规则列表中的条件，如符合，则取得该规则对应的执行（Action）方法，并下发给实际处理该消息的执行动作服务。

参见图6，基于同一构思，本发明还提供了一种车联网业务数据的处理装置600。车联网业务数据的处理装置600可包括数据获取模块601、格式确定模块602、格式转化模块603以及规则引擎模块604。数据获取模块601获取车联网业务数据。格式确定模块602确定处理车联网业务数据的规则引擎的类型，根据规则引擎的类型确定规则引擎对应的表达式的目标格式。格式转化模块603将车联网业务数据对应的规则转化成目标格式的表达式，并发送至规则引擎模块604。规则引擎模块604通过目标格式的表达式对车联网业务数据进行处理。

在本实施例中，车联网业务数据的处理装置600可以根据车联网业务数据的变化，为处理车联网业务数据的相应类型的规则引擎提供目标格式的表达式，从而适配不同类型规则引擎的需求，并且，可以动态加载和动态解析目标格式的表达式，即可以及时加载和及时解析生效目标格式的表达式，在车联网业务数据符合规则时，执行相应的动作，从而更加灵活高效地处理车联网业务数据，另外，随着车联网业务数据地增多和改变，可以避免大量重复的编码工作。

在本发明一个实施中，格式确定模块602可根据车联网业务数据的属性确定规则引擎的类型；和/或根据车联网业务数据所属的场景确定规则引擎的类型。

在本发明一个实施中，格式确定模块602确定处理车联网业务数据的规则引擎的类型为自定义类型时，根据规则引擎的自定义类型确定规则引擎对应的表达式的目标格式为JSON格式。格式转化模块603将车联网业务数据对应的规则转化成JSON格式的表达式。

在本发明一个实施中，格式确定模块602确定处理车联网业务数据的规则引擎的类型为mysql或Flink时，根据规则引擎的mysql或Flink类型确定规则引擎对应的表达式的目标格式类SQL格式。格式转化模块603将车联网业务数据对应的规则转化成JSON格式的表达式，将JSON格式的表达式转化为类SQL格式的表达式。

在本发明一个实施例中，车联网业务数据的处理装置600可包括规则配置模块605。规则配置模块605用于配置车联网业务数据对应的规则。具体地，规则配置模块605可通过网页配置车联网业务数据对应的规则。

在本实施例中，即使车联网业务数据的处理规则发生改变，规则配置模块605也可以重新配置车联网业务数据对应的新的规则，避免重新编码的工作，也使修改车联网业务数据对应的规则的过程更加简单。

在本发明一个实施中，格式转化模块603可将不同格式的表达式之间相互转化。

当规则引擎模块604通过目标格式的表达式对车联网业务数据进行处理后，若还需要其他类型的规则引擎通过表达式对车联网业务数据进行处理，格式转化模块603只需要将目标格式的表达式转化成与其他类型的规则引擎对应的格式的表达式，无需重新将规则转化成他类型的规则引擎对应的格式的表达式，这种处理方式可以减少转化的步骤，提高转化的效率，进而提高车联网业务数据的处理效率。

参见图7，基于同一构思，本发明还提供了一种电子设备700。电子设备700可包括可存储器701和处理器702。存储器701内存储有控制程序。控制程序被处理器702执行时用于实现根据上述任一项实施例的车联网业务数据的处理方法。

基于同一构思，本发明还提供了一种计算机存储介质。计算机存储介质存储有计算机程序代码，当计算机程序代码在计算设备上运行时，导致计算设备执行根据上述任一项实施例的车联网业务数据的处理方法。

上述各个实施例可以任意组合，根据上述任意一个优选实施例或多个优选实施例的组合，本发明实施例能够达到如下有益效果：

获取车联网业务数据，确定处理车联网业务数据的规则引擎的类型，根据规则引擎的类型确定规则引擎对应的表达式的目标格式，将车联网业务数据对应的规则转化成目标格式的表达式，将目标格式的表达式发送至规则引擎，以使规则引擎通过目标格式的表达式对车联网业务数据进行处理，这种处理车联网业务数据的方式，可以根据车联网业务数据的变化，为处理车联网业务数据的相应类型的规则引擎提供目标格式的表达式，从而适配不同类型规则引擎的需求。并且，规则引擎可以动态加载和动态解析目标格式的表达式，即规则引擎可以及时加载和及时解析生效目标格式的表达式，在车联网业务数据符合规则时，执行相应的动作，从而更加灵活高效地处理车联网业务数据。另外，随着车联网业务数据地增多和改变，这种处理车联网业务数据的方式，可以避免大量重复的编码工作。

至此，本领域技术人员应认识到，虽然本文已详尽示出和描述了本发明的多个示例性实施例，但是，在不脱离本发明精神和范围的情况下，仍可根据本发明公开的内容直接确定或推导出符合本发明原理的许多其他变型或修改。因此，本发明的范围应被理解和认定为覆盖了所有这些其他变型或修改。