CN115439076A - 一种车辆状态数据处理方法及装置、电子设备及存储介质 - Google Patents

Abstract

本公开提供了一种车辆状态数据处理方法、装置、电子设备及存储介质，涉及数据处理技术领域。该车辆状态数据处理方法包括：接收上报的车辆状态数据；根据车辆状态数据查找与车辆状态数据关联的业务场景；根据车辆状态数据和业务场景对应的业务触发规则确定是否触发业务指令；以及当触发业务指令时，将业务指令发送给业务系统执行。本公开的车辆状态数据处理方案优化了云端服务器的业务处理流程，提高了数据处理的效率，降低了业务系统开发成本。

Description

一种车辆状态数据处理方法及装置、电子设备及存储介质

技术领域

本公开涉及数据处理技术领域，尤其涉及一种车辆状态数据处理方法及装置、电子设备及存储介质。

背景技术

随着云计算和大数据技术的不断成熟，数据在各行业中扮演重要角色。在车辆领域，车辆在测试和使用过程中采集的数据对车辆的产品升级、故障排查以及事故分析都具有相当深远的意义。

目前，云端服务器对车辆数据采集与解析的方案在于，当车辆状态发生变化时，车辆通知云端服务器，云端服务器存储车辆状态数据，业务系统根据数据分析及业务功能的需要，通过查询云端服务器上存储的大量数据来实现业务功能，导致业务处理不及时、数据处理效率低等问题。

发明内容

为了克服现有技术的不足，本公开提供了一种车辆状态数据处理方法、装置、电子设备和存储介质。

根据本公开的第一方面，提供了一种车辆状态数据处理方法。该方法包括：接收车辆状态数据；根据车辆状态数据查找与车辆状态数据关联的业务场景；根据车辆状态数据和业务场景对应的业务触发规则确定是否触发业务指令；以及当触发业务指令时，将业务指令发送给业务系统执行。

在本公开的一些实施例中，业务触发规则包括业务场景对应的数据条目数量、数据类型以及规则判断条件，根据车辆状态数据和业务场景对应的业务触发规则确定是否触发业务指令包括：判断车辆状态数据是否满足业务场景中与车辆状态数据对应的规则判断条件；若业务场景对应的所有车辆状态数据均满足各自的规则判断条件，则确定触发业务指令；以及若业务场景对应的所有车辆状态数据中，至少存在一个车辆状态数据不满足业务场景中与车辆状态数据对应的规则判断条件，则等待收集业务场景下的其他车辆状态数据，待收集完其他车辆状态数据后，判断其他车辆状态数据是否满足与其他车辆状态数据对应的规则判断条件。

在本公开的一些实施例中，判断车辆状态数据是否满足业务场景中与车辆状态数据对应的规则判断条件之前，该方法还包括：获取接收到的车辆状态数据的条目数量和对应的数据类型；若接收到的车辆状态数据的条目数量大于或等于业务场景对应的数据条目数量，且接收到的车辆状态数据对应的数据类型包含业务场景对应的数据类型，则判断车辆状态数据是否满足业务场景中与车辆状态数据对应的规则判断条件；以及若接收到的车辆状态数据的条目数量小于业务场景对应的数据条目数量，或接收到的车辆状态数据对应的数据类型不包含业务场景对应的数据类型，则等待收集业务场景下的其他车辆状态数据，待收集完其他车辆状态数据之后，判断车辆状态数据、其他车辆状态数据是否满足对应的规则判断条件。

在本公开的一些实施例中，该方法还包括：获取接收到其他车辆状态数据的时间与接收到车辆状态数据的时间间隔；判断时间间隔是否在预定阈值范围内；若在预定阈值范围内，则判断其他车辆状态数据是否满足与其他车辆状态数据对应的规则判断条件；以及若不在阈值范围内，则放弃判断。

在本公开的一些实施例中，将业务指令发送给业务系统执行包括：根据业务系统所采用的协议，将业务指令通过业务系统对应的通信路径发送给业务系统执行。

在本公开的一些实施例中，将业务指令发送给业务系统执行包括：将业务场景对应的车辆状态数据打包为数据包，数据包的格式与参数对应；以及将数据包与业务指令一并发送给业务系统执行。

在本公开的一些实施例中，根据车辆状态数据查找与车辆状态数据关联的业务场景包括：根据车辆状态数据查询预存储的业务场景信息，业务场景信息中包括业务场景对应的数据参数；以及将业务场景中数据参数与车辆状态数据匹配的业务场景选出，作为与车辆状态数据关联的业务场景。

在本公开的一些实施例中，根据车辆状态数据和业务场景对应的业务触发规则确定是否触发业务指令之前，还包括：获取预配置的业务场景规则信息，业务场景规则信息中存储有不同业务场景的业务触发规则；以及将业务场景规则信息中与业务场景匹配的业务场景规则选出，作为与业务场景对应的业务触发规则。

根据本公开的第二方面，提供了一种车辆状态数据处理装置。该装置包括：接收单元，用于接收上报的车辆状态数据；查找单元，用于根据车辆状态数据查找与车辆状态数据关联的业务场景；确定单元，用于根据车辆状态数据和业务场景对应的业务触发规则确定是否触发业务指令；以及发送单元，用于当触发业务指令时，将业务指令发送给业务系统执行。

根据本公开的第三方面，提供了一种电子设备，包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行前述第一方面描述的方法。

根据本公开的第四方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，计算机指令用于使计算机执行前述第一方面描述的方法。

本公开提供的车辆状态数据处理方法及装置、电子设备、存储介质和计算机程序产品，通过接收车辆状态数据，查找与车辆状态数据相关联的业务场景根据车辆状态数据和业务触发规则判断是否触发业务指令，并当触发对应的业务指令时将业务指令发送给业务系统执行，使得云端服务器能够及时获得车辆数据并判断是否触发对应业务场景的业务指令，当判断通过时直接将业务指令发送给业务系统执行，保证了业务流程执行的及时性，降低了因等待业务系统间歇性查询而导致的时滞性。同时，业务系统响应于业务指令执行相应的业务流程即可，不需要对大量数据进行查询和判断处理，实现了执行功能和数据处理功能的解耦，降低了业务系统的开发成本，提高了数据处理效率。

应当理解，本部分所描述的内容并非旨在标识本申请的实施例的关键或重要特征，也不用于限制本申请的范围。本申请的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1为本公开实施例提供的一种车辆状态数据处理方法的流程示意图；

图2为本公开实施例提供的一种车辆状态数据处理方法的流程示意图；

图3为本公开实施例提供的一种车辆状态数据处理方法的流程示意图；

图4为本公开实施例提供的一种车辆状态数据处理装置的结构示意图；

图5为本公开实施例提供的示例电子设备500的示意性框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

相关技术存在以下技术问题：

1)数据处理滞后性问题：在车辆状态发生改变时会通知到云端服务器，以便云端服务器执行相关业务处理。目前，车辆会在采集车辆状态数据后将其上报至云端服务器，云端服务器接收到车辆状态数据时，会把车辆状态数据存储在信号解析模块中，该车辆状态数据需要云端服务器中各个业务系统按照轮询的方式向该信号解析模块进行查询获取，在获取之后，由各业务系统对车辆状态数据进行判断和处理，确定是否需要触发业务指令。由于各业务系统通过轮询的方式获取车辆状态数据，导致车辆状态数据需要等待被获取，使得车辆状态数据处理存在延时，业务指令的发出也存在较大的延迟。

2)业务系统数据处理及传输效率低：现有技术中信号解析模块仅有储存功能，各业务系统需要从信号解析模块中进行查找获取数据，若多个业务系统都关注同一数据，各个系统需要分别查询获取该数据，这种方式下，对网络带宽和计算能力要求较高，存在数据使用效率低，网络资源浪费的情况。

3)业务系统开发成本高、维护难：现有技术中，程序员在开发各个业务系统时，需要对其数据处理和业务执行功能进行共同开发，当需要增加或删除业务场景时，需要程序员重新修改业务系统的代码。此外，对于多个业务系统都关注某个数据的触发机制，现有技术中各个业务系统都需要分别判断，分别调用，导致开发成本较高，维护难度较大。

为了解决相关技术中的问题，本公开提供了一种车辆状态数据处理方法、装置、电子设备、存储介质和计算机程序产品。下面参考附图详细描述本公开的方案。

图1为本公开实施例提供的一种车辆状态数据处理方法的流程示意图。该方法应用于车辆与云端服务器组成的系统，具体应用于云端服务器中的信号解析模块。本领域技术人员可以理解的是，信号解析模块是部署于云端服务器的软件系统，其具体用于处理车辆上报的车辆状态数据。

如图1所示，该方法包括以下步骤。

步骤101，接收车辆状态数据。

在本公开的一种实施方式中，车辆状态数据是指车辆在测试或使用过程中采集到的车辆信息，例如车门的开关、车速、周围环境温度等。作为一种优选实施例，车辆状态数据包括所采集数据的类型或名称、数据值、以及采集时间，例如，9点时刻的车速为60km/h。

车辆状态数据的采集方式包括但不限于通过各种传感器进行采集，车辆状态数据的采集时机包括但不限于依序采集或并行采集，车辆状态数据的采集规则包括但不限于周期采集、变化采集或增量采集，在本公开中均不予限制。

具体地，周期采集是指传感器以固定或周期性变化的时间间隔进行采集，例如车辆可以每隔5分钟采集一次车速数据；变化采集是指传感器检测到车辆状态数据发生变化时进行采集，例如当车门的开关状态由“开”变化为“关”(或反之)时采集车门状态数据；增量采集是指传感器检测到车辆状态数据的值增加或减少至预设值时进行采集，例如当车辆的里程数从一万公里增加至两万公里时采集里程数据。

应当理解的是，信号解析模块接收到的车辆状态数据为至少一条数据。在本公开的一种实施方式中，当车辆的传感器依据一定采集规则采集到车辆状态数据时，即向云端服务器中的信号解析模块上报该数据，信号解析模块可以即时接收到该车辆状态数据，在网络状态不稳定情况下，信号解析模块接收到该数据的时间相较于车辆采集该数据的时间有一定延迟。

步骤102，根据车辆状态数据查找与车辆状态数据关联的业务场景。

在本公开的一种实施方式中，业务场景是指云端服务器需要执行的某一业务处理所实现的功能。例如，对于“提醒用户锁车门”的业务场景，云端服务器可执行提醒业务处理，从而实现提醒用户锁车门的功能。

云端服务器可以对各个业务场景配置和订阅该业务场景关注的车辆状态数据。当信号解析模块接收到车辆状态数据时，云端服务器可以查出订阅了该车辆状态数据的业务场景。可以理解的是，业务场景关注的车辆状态数据类型和条目数量是预配置并存储于信号解析模块中的。一个业务场景可以关注一个或多个车辆状态数据，同一车辆状态数据可以对应多个业务场景，换言之，不同的业务场景关注的车辆状态数据数量或类型可以相同或不同。

步骤103，根据车辆状态数据和业务场景对应的业务触发规则确定是否触发业务指令。

在本公开的一种实施方式中，业务触发规则是指触发云端服务器指示业务系统执行该业务场景对应的业务流程所满足的条件。可以理解的是，业务触发规则是预配置并存储于信号解析模块中的，其至少包括业务场景关注的车辆状态数据各自对应的规则判断条件。当信号解析模块获取业务场景后，可从信号解析模块的存储中查找并获取该业务场景对应的业务触发规则。

在本公开的一种实施方式中，信号解析模块根据接收到的车辆状态数据，以及从本地存储中获取到的业务触发规则，确定是否触发业务指令。该业务指令用于指示业务系统执行该业务场景对应的业务流程，以实现相应的业务功能。

具体地，对于第一业务场景，可以对其配置一条车辆状态数据，并设置该车辆状态数据对应的规则判断条件，作为该第一业务场景对应的业务触发规则，则以上第一业务场景对应的车辆状态数据、业务触发规则及其对应关系将存储于信号解析模块中，当信号解析模块获取车辆上报的车辆状态数据为预存的车辆状态数据，且该车辆状态数据达到预存的规则判断条件，则判断满足业务触发规则，此时即触发业务指令。

对于第二业务场景，可以对其配置多条车辆状态数据，并设置多条车辆状态数据各自对应的规则判断条件，组成该第二业务场景对应的业务触发规则，则以上第二业务场景对应的车辆状态数据、业务触发规则及其对应关系将存储于信号解析模块中，当信号解析模块获取车辆上报的车辆状态数据为预存的车辆状态数据，且车辆状态数据各自达到对应的规则判断条件，则判断满足业务触发规则，此时即触发业务指令。

步骤104，当触发业务指令时，将业务指令发送给业务系统执行。

本领域技术人员可以理解的是，业务系统部署在云端服务器上用于实现车辆特定功能的软件系统。云端服务器上部署有至少一个业务系统，一个业务系统对应一个或多个业务场景。例如，车控部门开发车控相关的业务系统，售后部门开发售后相关的业务系统，换言之，信号解析模块下游的业务系统是分布式的。

在本公开的一种实施方式中，当触发业务指令时，信号解析模块将该业务指令发送至业务系统，业务系统响应于该业务指令，执行对应的业务流程。可选地，信号解析模块可将接收到的与该业务场景对应的车辆状态数据一并发送给业务系统，本公开不予限定。

信号解析可以通过业务系统对应的通信规则发送该业务指令，各业务系统对应的通信规则是预设的，在本公开中不予限定。

业务系统接收到业务指令后，可根据业务场景的属性确定执行的时机，对于紧急程度较高的业务场景，例如涉及车辆安全性的业务场景，业务系统收到业务指令时立即触发执行，对于非紧急的业务场景，例如涉及车辆内饰功能的业务场景，可以以消息队列的形式执行，或定时执行等，在本公开中不予限制。

此外，业务系统可以理解为一种执行器，其能够实现在云端服务器中对应的功能，例如记录一条数据。业务系统下游还可能存在其他执行器，包括但不限于车辆或与车辆绑定的智能设备，例如提示用户锁车的业务场景，业务系统响应于接收到的业务指令执行其对应的功能后将继续推送至下游执行器，最终到达用户手机端或实现用户可视化，下游执行器的数量和功能取决于业务场景需要，本公开中不予限制。

综上，通过接收车辆状态数据，查找与车辆状态数据相关联的业务场景并获取业务场景对应的业务触发规则，根据车辆状态数据和业务场景对应的业务触发规则判断是否触发业务指令，并当触发对应的业务指令时将业务指令发送给业务系统执行，使得云端服务器能够及时获得车辆数据并判断是否触发对应业务场景的业务指令，当判断通过时直接将业务指令发送给业务系统执行，保证了业务流程执行的及时性，降低了因等待业务系统间歇性查询而导致的时滞性。同时，业务系统响应于业务指令执行相应的业务流程即可，不需要对大量数据进行查询和判断处理，实现了执行功能和数据处理功能的解耦，仅通过产品经理就可以实现零成本增减业务场景，信号解析中配置的规则可以反复被多个业务系统调用，降低了业务系统的开发和维护成本，提高了数据处理效率，通过在云端服务器的业务开发人员和车辆状态数据之间提供抽象接口，降低对接成本，降低系统复杂度。

图2为本公开实施例所提供的一种车辆状态数据处理方法的流程示意图。该方法包括以下步骤。

步骤201，接收上报的车辆状态数据。

步骤202，根据车辆状态数据查找与车辆状态数据关联的业务场景。

步骤201-202与上述图1所示实施例中的步骤101-102原理相同，具体描述请参见上述实施例，在此不再赘述。

步骤203，获取业务场景对应的业务触发规则。

具体地，本公开实施例中的业务触发规则包括业务场景对应的数据条目数量、数据类型以及规则判断条件。

可以理解的是，条目数量指该业务场景关注或订阅的车辆状态数据的数量，数据类型指该业务场景中的数据名称或分别归属于何种不同的属性，规则判断条件指各个数据需达到何种条件。

举例而言，对于提醒用户锁车的业务场景，预配置其关注的车辆状态数据为档位数据、车门状态数据以及座椅压力数据，当座椅压力数据小于一定阈值、车门状态数据为关闭，且档位数据为P档时触发提醒用户锁车的事件，则该业务场景下的数据条目数量为三条，其类型分别为档位数据、车门状态数据以及座椅压力数据，各自对应的规则判断条件为座椅压力数据小于一定阈值、车门状态数据为关闭，档位数据为P档。

步骤204，根据车辆状态数据和业务场景对应的业务触发规则确定是否触发业务指令。

在本公开的一种实施方式中，根据上述车辆状态数据和上述业务场景对应的业务触发规则确定是否触发业务指令时，可以有但不局限于以下的两种方式进行：第一种方式，接收到上述车辆状态数据并确定业务场景之后，直接根据对应的业务触发规则判断该车辆状态数据是否满足其对应的规则判断条件，再判断随后收到的车辆状态数据，待该业务场景对应的车辆状态数据与其对应的规则触发条件全部判断完毕后，判断是否触发业务指令；第二种方式，接收到上述车辆状态数据并确定业务场景之后，确定业务场景所需要的车辆状态数据是否已经全部上报，在确定全部上报时，再判断接收到的车辆状态数据是否满足各自对应的规则判断条件，从而根据对应的业务触发规则判断是否要触发业务指令。

具体地，针对上述第一种方式，步骤204包括如下步骤。

步骤2041，判断车辆状态数据是否满足业务场景中与车辆状态数据对应的规则判断条件。若业务场景对应的所有车辆状态数据均满足各自的规则判断条件，执行下述步骤2042，若业务场景对应的所有车辆状态数据中，至少存在一个车辆状态数据不满足业务场景中与车辆状态数据对应的规则判断条件，执行下述步骤2043。

举例而言，当接收到的车辆状态数据为档位数据时，查找到该车辆状态数据对应有提醒用户锁车的业务场景，在该业务场景下，档位数据对应的规则判断条件为挂入P档。若接收到的档位数据是P档，表示其满足提醒用户锁车的业务场景下档位数据对应的规则判断条件。

步骤2042，确定触发业务指令。

在上述的示例中，当接收到的车辆状态数据为档位数据、车门状态数据以及座椅压力数据，且接收到的各个数据分别满足在提醒用户锁车的业务场景下其各自对应的规则判断条件，则确认触发提醒用户锁车的业务场景对应的业务指令。

步骤2043，等待收集业务场景下的其他车辆状态数据，待收集完其他车辆状态数据后，判断其他车辆状态数据是否满足与其他车辆状态数据对应的规则判断条件。

例如，在上述的示例中，若当前只收到档位数据，该档位数据是P档，表示其满足提醒用户锁车的业务场景下档位数据对应的规则判断条件。但由于该业务场景有另外两个规则判断条件尚未满足(未收到座椅压力数据和车门数据，或二者之一不满足对应的规则判断条件)，此时不会触发提醒用户锁车的业务，而是等待收集业务场景下的其他车辆状态数据，待收集完其他车辆状态数据后，判断其他车辆状态数据是否满足与其他车辆状态数据对应的规则判断条件。待该业务场景对应的所有车辆状态数据均满足各自的规则判断条件时，执行步骤2042，即，确定触发业务指令。

作为一种可选实施例，针对上述第二种方式，在上述步骤2041之前，步骤204还包括如下步骤。

步骤2044，根据业务触发规则获取业务场景对应的数据条目数量和数据类型。

在上述示例中，若信号解析模块接收到档位数据，并确定档位数据对应有提示用户锁车的业务场景，在判断接收到的档位数据是否满足该业务场景中与档位数据应的规则判断条件之前，信号解析模块可获取提示用户锁车场景订阅的车辆状态数据条目数量和数据类型。如上述实施例中描述的，该业务场景下订阅的数据条目数量为三条，类型分别为档位数据、座椅压力数据和车门状态数据。

步骤2045，获取接收到的车辆状态数据的条目数量和对应的数据类型。

由于车辆采集数据的规则不同，同一时间上报至信号解析模块的车辆状态数据可能是多个。在该情况下，信号解析模块将确定与上述档位数据同时上报的车辆状态数据的条目数量和对应的数据类型。

若数据全面且数据类型匹配，即，接收到的车辆状态数据的条目数量大于或等于业务场景对应的数据条目数量，且接收到的车辆状态数据对应的数据类型包含业务场景对应的数据类型，则执行步骤2041。

例如，信号解析模块接收上述档位数据的同时还接收到车速数据、车门状态数据、座椅压力数据。即，接收到的车辆状态数据的条目数量大于或等于业务场景对应的数据条目数量，且接收到的车辆状态数据对应的数据类型包含业务场景对应的数据类型，此时一并判断档位数据、座椅压力数据、车门状态数据是否满足提示用户锁车的业务场景下各自对应的规则判断条件。若全部满足，则确定触发业务指令，若任一不满足，则等待收集不满足规则判断条件的车辆状态数据，待收集到后，再次判断该不满足规则判断条件的车辆状态数据。

若数据不全或数据类型不匹配，即，接收到的车辆状态数据的条目数量小于业务场景对应的数据条目数量，或接收到的车辆状态数据对应的数据类型不包含业务场景对应的数据类型，则执行步骤2046。

步骤2046，等待收集业务场景下的其他车辆状态数据，待收集完其他车辆状态数据之后，判断车辆状态数据、其他车辆状态数据是否满足对应的规则判断条件。

例如，信号解析模块接收上述档位数据的同时还接收到车速数据、车内温度数据、胎压数据、里程数据。即，接收到的车辆状态数据的条目数量尽管大于业务场景对应的数据条目数量，但接收到的车辆状态数据对应的数据类型没有全部包含业务场景对应的数据类型，此时等待收集业务场景下的其他车辆状态数据(座椅压力数据、车门状态数据)，待收集完其他车辆状态数据之后，一并判断车辆状态数据(档位数据)、其他车辆状态数据(座椅压力数据、车门状态数据)是否满足其各自对应的规则判断条件。若全部满足，则确定触发业务指令，若任一不满足，则等待收集不满足规则判断条件的车辆状态数据，待收集到后，再次判断该不满足规则判断条件的车辆状态数据。

在本公开的一种可选实施方式中，上述两种方式中，对于步骤2043和2046中接收到其他车辆状态数据时，该方法还包括：

步骤2047，获取接收到其他车辆状态数据的时间与接收到车辆状态数据的时间间隔。

进一步的，信号解析模块可以获取每个接收到的车辆状态数据的时间，当接收到其他状态数据时，比较接收到其他车辆状态数据的时间与接收到车辆状态数据的时间，并得到时间间隔。

步骤2048，判断时间间隔是否在预定阈值范围内。

若在预定阈值范围内，判断其他车辆状态数据是否满足与其他车辆状态数据对应的规则判断条件，若不在阈值范围内，则放弃判断。

例如，信号解析模块可预先设置时间间隔阈值，例如5分钟，当判断两车辆状态数据的接收时间间隔未超过设置的阈值范围，则接收到的该其他车辆状态数据为有效数据，可进行后续判断；否则，在先接收到的车辆状态数据可确定为无效数据，则在先收到的车辆状态数据将不再用于该业务场景的判断，而将接收到的其他状态数据作为判断该业务场景的新数据，并等待后续上报的数据。

在该实施例中，设置了有效时间间隔阈值，由于车辆状态数据分析具有时效性，超过一定时效的数据的时效性降低，信号解析模块将选择时效性高的数据用于数据处理和判断，提高了数据处理的准确性和有效性。

步骤205，当触发业务指令时，将业务指令发送给业务系统执行。

步骤205与上述图1所示实施例中的步骤105原理相同，具体描述请参见上述实施例，在此不再赘述。

综上，根据本公开提出的车辆状态数据处理方法，云端服务器在接收到车辆上传的车辆状态数据时立即对该车辆状态数据进行处理分析，通过查找相对应的预定义业务场景，根据预定义的业务场景查找到对应的业务触发规则，根据业务触发规则判断是否触发业务指令，通过具体的判断规则，在确定满足触发业务指令时，将触发的业务指令发送给业务系统执行，使得云端服务器能够及时获得车辆数据并判断是否触发对应业务场景的业务指令，当判断通过时直接将业务指令发送给业务系统执行，保证了业务流程执行的及时性，降低了因等待业务系统间歇性查询而导致的时滞性。同时，业务系统响应于业务指令执行相应的业务流程即可，不需要对大量数据进行查询和判断处理，实现了执行功能和数据处理功能的解耦，降低了业务系统的开发成本，提高了数据处理效率。除此之外，通过设置时间间隔判断，提高了数据处理的有效性和准确性。

图3为本公开实施例提供的一种车辆状态数据处理方法的流程示意图。

步骤301，接收上报的车辆状态数据。

步骤301与上述图1及图2所示实施例中的步骤101和201原理相同，在此不再赘述。

步骤302，根据车辆状态数据查找与车辆状态数据关联的业务场景。

具体地，步骤302包括：

步骤3021，根据车辆状态数据查询预存储的业务场景信息，业务场景信息中包括业务场景对应的数据参数。

在本公开的一种实施方式中，信号解析模块预存储业务场景信息，该业务场景信息为业务场景与其对应的数据参数之间的对应关系，该数据参数包括该业务场景订阅的车辆状态数据条目数量、数据类型以及各车辆状态数据对应的规则判断条件。当信号解析模块收到车辆状态数据时，可根据接收到的车辆状态数据和该对应关系进行查询。

应当理解的是，业务场景信息的存储形式包括但不限于数据表，在本公开中不予限制。

步骤3022，将业务场景中数据参数与车辆状态数据匹配的业务场景选出，作为与车辆状态数据关联的业务场景。

信号解析模块通过数据库查询，从预存储的业务场景信息中选出与接收到的车辆状态数据匹配的业务场景，并将该业务场景作为与接收到的车辆状态数据关联的业务场景。可以理解的是，同一车辆状态数据可以被一个或多个业务场景订阅，因此与接收到的车辆状态数据关联的业务场景可能是一个或多个。

步骤303，获取业务场景对应的业务触发规则。

具体地，步骤303包括：

步骤3031，获取预配置的业务场景规则信息，业务场景规则信息中存储有不同业务场景的业务触发规则。

在本公开的一种实施方式中，信号解析模块预存储有业务场景规则信息，该业务场景规则信息为业务场景与其对应的业务场景规则之间的对应关系，该触发规则包括触发业务指令时该业务场景订阅的车辆状态数据满足的规则判断条件。当信号解析模块查找出业务场景后，可根据该业务场景和该对应关系进行查询。

应当理解的是，业务场景规则信息的存储形式包括但不限于数据表，在本公开中不予限制。

步骤3032，将业务场景规则信息中与业务场景匹配的业务场景规则选出，作为与业务场景对应的业务触发规则。

信号解析模块通过数据库查询，从预存储的业务场景规则信息中选出与在先查找到的业务场景匹配的业务场景规则，并将该业务场景规则作为与业务场景对应的业务触发规则。业务触发规则可以是数据组，其中包含与该业务场景订阅的车辆状态数据各自对应的规则判断条件。

步骤304，根据车辆状态数据和业务场景对应的业务触发规则确定是否触发业务指令。

步骤304与上述图1及图2所示实施例中的步骤104和204原理相同，在此不再赘述。

步骤305，当触发业务指令时，将业务指令发送给业务系统执行。

具体地，步骤305包括：

步骤3051，确定业务系统的通信规则，通信规则包括协议、路径、参数。

在本公开的一种实施方式中，信号解析模块中预存有业务系统与通信规则之间的对应关系，不同的业务系统可对应于相同或不同的通信规则。其中，通信规则包括协议、路径、参数，即，该业务系统采用何种协议通信，通过何种路径传输控制指令或数据包，数据包采用何种格式进行封装等。可以理解的是，同一业务系统中包含一个或多个业务场景，但对于同一业务系统其通信规则是相同的，比如HTP或消息队列等通信规则，在本公开中不予限制。

步骤3052，根据协议，将业务指令通过路径发送给业务系统执行。

信号解析模块确定该业务系统对应的通信规则后，则根据通信规则中的协议，将业务指令经由通信规则中的路径发送给业务系统。

在一种优选的实施例中，信号解析模块可将接收到的业务场景对应的车辆状态数据打包为数据包，数据包的格式由通信规则中的参数定义，例如二进制格式或xml格式，在本公开中不予限制。信号解析模块可将数据包与业务指令一并发送给业务系统。

例如，对于提醒用户锁车的业务场景，当业务指令触发时，信号解析模块可仅将业务指令发送给业务系统，由业务系统执行提醒用户锁车的功能。再例如，对于车辆保养的业务场景，当业务指令触发时，信号解析模块可将该业务场景下对应的车辆数据(例如里程数据)以预定格式进行封装打包，并将该数据包同业务指令一起发送给业务系统，由于不同的里程数据可能对应于不同的保养方案，从而使业务系统根据车辆的里程数据执行具体的车辆保养业务。

综上，通过信号解析模块在本地存储中查找与车辆状态数据相关联的业务场景并获取业务场景对应的业务触发规则，再根据不同业务系统对应的通信规则将业务指令发送给业务系统执行，解决了相关技术中由业务系统对信号解析模块中的数据进行查找、处理导致的问题，提高了车辆数据处理效率和查询速度，降低了业务系统开发难度，节省了数据传输带宽和服务器处理能力。此外，信号解析模块可根据不同的业务场景需要确定是否发送车辆状态数据包，对于可以简单响应指令执行的业务场景，仅向业务系统发送业务指令，节省了数据传输带宽，对于需要数据的复杂业务场景，将车辆状态数据打包一并发送给业务系统，提高了业务流程执行的精确性。

与上述的车辆状态数据处理的方法相对应，本发明还提出一种车辆状态数据处理装置。

图4为本公开实施例提供的一种车辆状态数据处理装置的结构示意图，如图4所示，该装置包括：

接收单元410，用于接收上报的车辆状态数据。

查找单元420，用于根据车辆状态数据查找与车辆状态数据关联的业务场景。

确定单元430，用于根据车辆状态数据和业务场景对应的业务触发规则确定是否触发业务指令。

发送单元440，用于当触发业务指令时，将业务指令发送给业务系统执行。

需要说明的是，由于本发明的装置实施例与上述的方法实施例相对应且原理相同，前述对方法实施例的解释说明，也适用于本实施例的装置，对于装置实施例中未披露的细节可参照上述的方法实施例，本发明中不再进行赘述。

在本公开的一种实施方式中，该装置还包括获取单元，用于获取业务场景赌赢的业务触发规则，其中，业务触发规则包括业务场景对应的数据条目数量、数据类型以及规则判断条件，确定单元440具体用于：判断车辆状态数据是否满足业务场景中与车辆状态数据对应的规则判断条件；若业务场景对应的所有车辆状态数据均满足各自的规则判断条件，则确定触发业务指令；以及若业务场景对应的所有车辆状态数据中，存在至少一个车辆状态数据不满足业务场景中与车辆状态数据对应的规则判断条件，则等待收集业务场景下的其他车辆状态数据，待收集完其他车辆状态数据后，判断其他车辆状态数据是否满足与其他车辆状态数据对应的规则判断条件。

在本公开的一种实施方式中，判断车辆状态数据是否满足业务场景中与车辆状态数据对应的规则判断条件之前，确定单元440具体用于：获取接收到的车辆状态数据的条目数量和对应的数据类型；若接收到的车辆状态数据的条目数量大于或等于业务场景对应的数据条目数量，且接收到的车辆状态数据对应的数据类型包含业务场景对应的数据类型，则判断车辆状态数据是否满足业务场景中与车辆状态数据对应的规则判断条件；以及若接收到的车辆状态数据的条目数量小于业务场景对应的数据条目数量，或接收到的车辆状态数据对应的数据类型不包含业务场景对应的数据类型，则等待收集业务场景下的其他车辆状态数据，待收集完其他车辆状态数据之后，判断车辆状态数据、其他车辆状态数据是否满足各自对应的规则判断条件。

在本公开的一种实施方式中，确定单元440具体用于：获取接收到其他车辆状态数据的时间与接收到车辆状态数据的时间间隔；判断时间间隔是否在预定阈值范围内；若在预定阈值范围内，则判断其他车辆状态数据是否满足与其他车辆状态数据对应的规则判断条件；以及若不在阈值范围内，则放弃判断。

在本公开的一种实施方式中，发送单元450具体用于：根据业务系统所采用的协议，将业务指令通过业务系统对应的通信路径发送给业务系统执行。

在本公开的一种实施方式中，发送单元450具体用于：将业务场景对应的车辆状态数据打包为数据包，数据包的格式与参数对应；以及将数据包与业务指令一并发送给业务系统执行。

在本公开的一种实施方式中，查找单元420具体用于：根据车辆状态数据查询预存储的业务场景信息，业务场景信息中包括业务场景对应的数据参数；以及将业务场景中数据参数与车辆状态数据匹配的业务场景选出，作为与车辆状态数据关联的业务场景。

在本公开的一种实施方式中，获取单元430具体用于：获取预配置的业务场景规则信息，业务场景规则信息中存储有不同业务场景的业务触发规则；以及将业务场景规则信息中与业务场景匹配的业务场景规则选出，作为与业务场景对应的业务触发规则。

综上，通过接收车辆状态数据，查找与车辆状态数据相关联的业务场景并获取业务场景对应的业务触发规则，根据车辆状态数据和业务场景对应的业务触发规则判断是否触发业务指令，并当触发对应的业务指令时将业务指令发送给业务系统执行，使得云端服务器能够及时获得车辆数据并判断是否触发对应业务场景的业务指令，当判断通过时直接将业务指令发送给业务系统执行，保证了业务流程执行的及时性，降低了因等待业务系统间歇性查询而导致的时滞性。同时，业务系统响应于业务指令执行相应的业务流程即可，不需要对大量数据进行查询和判断处理，实现了执行功能和数据处理功能的解耦，降低了业务系统的开发成本，提高了数据处理效率。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图5示出了可以用来实施本公开的实施例的示例电子设备500的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图所示，设备500包括计算单元501，其可以根据存储在ROM(Read-Only Memory，只读存储器)502中的计算机程序或者从存储单元508加载到RAM(Random Access Memory，随机访问/存取存储器)503中的计算机程序，来执行各种适当的动作和处理。在RAM 503中，还可存储设备500操作所需的各种程序和数据。计算单元501、ROM 502以及RAM 503通过总线504彼此相连。I/O(Input/Output，输入/输出)接口505也连接至总线504。

设备500中的多个部件连接至I/O接口505，包括：输入单元506，例如键盘、鼠标等；输出单元507，例如各种类型的显示器、扬声器等；存储单元508，例如磁盘、光盘等；以及通信单元509，例如网卡、调制解调器、无线通信收发机等。通信单元509允许设备500通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元501可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元501的一些示例包括但不限于CPU(Central Processing Unit，中央处理单元)、GPU(Graphic Processing Units，图形处理单元)、各种专用的AI(Artificial Intelligence，人工智能)计算芯片、各种运行机器学习模型算法的计算单元、DSP(Digital SignalProcessor，数字信号处理器)、以及任何适当的处理器、控制器、微控制器等。计算单元501执行上文所描述的各个方法和处理，例如车辆状态数据处理方法。例如，在一些实施例中，车辆状态数据处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元508。在一些实施例中，计算机程序的部分或者全部可以经由ROM 502和/或通信单元509而被载入和/或安装到设备500上。当计算机程序加载到RAM 503并由计算单元501执行时，可以执行上文描述的方法的一个或多个步骤。备选地，在其他实施例中，计算单元501可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行前述车辆状态数据处理方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、FPGA(Field Programmable Gate Array，现场可编程门阵列)、ASIC(Application-Specific Integrated Circuit，专用集成电路)、ASSP(Application Specific StandardProduct，专用标准产品)、SOC(System On Chip，芯片上系统的系统)、CPLD(ComplexProgrammable Logic Device，复杂可编程逻辑设备)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、RAM、ROM、EPROM(Electrically Programmable Read-Only-Memory，可擦除可编程只读存储器)或快闪存储器、光纤、CD-ROM(Compact Disc Read-Only Memory，便捷式紧凑盘只读存储器)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(Cathode-Ray Tube，阴极射线管)或者LCD(Liquid Crystal Display，液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：LAN(LocalArea Network，局域网)、WAN(Wide Area Network，广域网)、互联网和区块链网络。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务("Virtual Private Server"，或简称"VPS")中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。

其中，需要说明的是，人工智能是研究使计算机来模拟人的某些思维过程和智能行为(如学习、推理、思考、规划等)的学科，既有硬件层面的技术也有软件层面的技术。人工智能硬件技术一般包括如传感器、专用人工智能芯片、云计算、分布式存储、大数据处理等技术；人工智能软件技术主要包括计算机视觉技术、语音识别技术、自然语言处理技术以及机器学习/深度学习、大数据处理技术、知识图谱技术等几大方向。

需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。

应当理解，本公开中使用的“系统”、“装置”、“单元”和/或“模块”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换该词语。

如本公开和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

其中，在本公开实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本公开实施例的描述中，“多个”是指两个或多于两个。

本公开中使用的术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。

本公开中使用了流程图用来说明根据本公开的实施例的系统所执行的操作。应当理解的是，前面或后面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各个步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作，可以使用所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

以上描述仅为本公开的实施例以及对所运用技术原理的说明，并不用于限制本公开。对于本领域技术人员来说，本公开可以有各种更改和变化。本公开中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (11)

1.一种车辆状态数据处理方法，其特征在于，包括：

接收车辆状态数据；

根据所述车辆状态数据查找与所述车辆状态数据关联的业务场景；

根据所述车辆状态数据和所述业务场景对应的业务触发规则确定是否触发业务指令；以及

当触发所述业务指令时，将所述业务指令发送给业务系统执行。

2.根据权利要求1所述的方法，其特征在于，所述业务触发规则包括所述业务场景对应的数据条目数量、数据类型以及规则判断条件，所述根据所述车辆状态数据和所述业务场景对应的业务触发规则确定是否触发业务指令包括：

判断所述车辆状态数据是否满足所述业务场景中与所述车辆状态数据对应的规则判断条件；

若所述业务场景对应的所有车辆状态数据均满足各自的规则判断条件，则确定触发所述业务指令；以及

若所述业务场景对应的所有车辆状态数据中，至少存在一个车辆状态数据不满足所述业务场景中与所述车辆状态数据对应的规则判断条件，则等待收集所述业务场景下的其他车辆状态数据，待收集完所述其他车辆状态数据后，判断所述其他车辆状态数据是否满足与所述其他车辆状态数据对应的规则判断条件。

3.根据权利要求2所述的方法，其特征在于，所述判断所述车辆状态数据是否满足所述业务场景中与所述车辆状态数据对应的规则判断条件之前，所述方法还包括：

获取接收到的车辆状态数据的条目数量和对应的数据类型；

若所述接收到的车辆状态数据的条目数量大于或等于所述业务场景对应的数据条目数量，且所述接收到的车辆状态数据对应的数据类型包含所述业务场景对应的数据类型，则判断所述车辆状态数据是否满足所述业务场景中与所述车辆状态数据对应的规则判断条件；以及

若所述接收到的车辆状态数据的条目数量小于所述业务场景对应的数据条目数量，或所述接收到的车辆状态数据对应的数据类型不包含所述业务场景对应的数据类型，则等待收集所述业务场景下的其他车辆状态数据，待收集完所述其他车辆状态数据之后，判断所述车辆状态数据、所述其他车辆状态数据是否满足各自对应的规则判断条件。

4.根据权利要求2所述的方法，其特征在于，所述方法还包括：

获取接收到所述其他车辆状态数据的时间与接收到所述车辆状态数据的时间间隔；

判断所述时间间隔是否在预定阈值范围内；

若在预定阈值范围内，则判断所述其他车辆状态数据是否满足与所述其他车辆状态数据对应的规则判断条件；以及

若不在所述阈值范围内，则放弃判断。

5.根据权利要求1-4中任一项述的方法，其特征在于，所述将所述业务指令发送给所述业务系统执行包括：

根据所述业务系统所采用的协议，将所述业务指令通过所述业务系统对应的通信路径发送给所述业务系统执行。

6.根据权利要求5中任一项述的方法，其特征在于，所述将所述业务指令发送给业务系统执行包括：

将所述业务场景对应的车辆状态数据打包为数据包，所述数据包的格式与所述参数对应；

将所述数据包与所述业务指令一并发送给所述业务系统执行。

7.根据权利要求1-4中任一项述的方法，其特征在于，所述根据所述车辆状态数据查找与所述车辆状态数据关联的业务场景包括：

根据所述车辆状态数据查询预存储的业务场景信息，所述业务场景信息中包括所述业务场景对应的数据参数；以及

将所述业务场景中数据参数与所述车辆状态数据匹配的业务场景选出，作为与所述车辆状态数据关联的业务场景。

8.根据权利要求1-4中任一项所述的方法，其特征在于，所述根据所述车辆状态数据和所述业务场景对应的业务触发规则确定是否触发业务指令之前，还包括：

获取预配置的业务场景规则信息，所述业务场景规则信息中存储有不同业务场景的业务触发规则；以及

将所述业务场景规则信息中与所述业务场景匹配的业务场景规则选出，作为与所述业务场景对应的业务触发规则。

9.一种车辆状态数据处理装置，其特征在于，包括：

接收单元，用于接收上报的车辆状态数据；

查找单元，用于根据所述车辆状态数据查找与所述车辆状态数据关联的业务场景；

确定单元，用于根据所述车辆状态数据和所述业务场景对应的业务触发规则确定是否触发业务指令；以及

发送单元，用于当触发所述业务指令时，将所述业务指令发送给业务系统执行。

10.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-8中任一项所述的方法。

11.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1-8中任一项所述的方法。

Images