车辆数据处理方法、装置、电子设备和存储介质

技术领域

本申请涉及大数据处理技术领域，特别涉及一种车辆数据处理方法、装置、电子设备和存储介质。

背景技术

基于互联网技术搭建的网约车平台，使得用户足不出户即可约车出行。并且可以基于网约车平台提供的司机到达时间合理安排出行计划。

相关技术中，用户可以基于终端设备向网约车平台发起网约车请求，网约车平台基于该请求为用户分配车辆接驾。

有时候不能为用户及时分配接驾的车辆时，网约车平台为了便于用户了解情况，会向用户展示用户需要等待多少时长其用车请求才会被处理。

然而，实际情况表明，预估的需要等待多少时长往往比实际时长要长。故此，相关技术未能提供有价值的信息给用户，则相关技术中用于统计时长所耗费的处理资源是一种浪费。

发明内容

本申请的目的是提供一种车辆数据处理方法、装置、电子设备和存储介质，用于解决相关技术中无法有效的利用处理资源提供更有价值的信息的问题。

第一方面，本申请提供一种车辆数据处理方法，所述方法包括：响应于终端设备的网约车请求，获取所述网约车请求对应的出发地；

以所述出发地为基准，确定目标地理范围；

获取行车目的地在所述目标地理范围内的多台车辆到达相应目的地所需的剩余时长；

按照各台所述车辆所需的剩余时长，从所述多台车辆的车辆信息中筛选出至少一条目标车辆信息；所述目标车辆信息包括车辆标识、目的地和剩余行驶时长；

将目标车辆信息发送给所述终端设备。

可选的，所述对所述多台车辆中的每台车辆，分别确定各台所述车辆到达相应的目的地所需的剩余时长，包括：

对每台所述车辆，分别执行：

获取所述车辆的剩余行车路线；

基于车速和所述剩余行车路线的长度，以及所述剩余行车路线的每条道路的以下道路信息中的至少一种确定所述车辆的行驶至目的地所需的所述剩余时长：

道路的拥挤程度、所述剩余行车路线中进行转向所耗费的时长、等待交通灯所耗费的时长。

可选的，所述基于车速和所述剩余行车路线的长度，以及所述剩余行车路线的每条道路的以下道路信息中的至少一种确定所述车辆的行驶至目的地所需的所述剩余时长，包括：

基于以下剩余时长确定公式确定所述剩余时长：

其中，urplusEta表示所述剩余时长；node表示道路的节点；node

其中，相邻节点之间的道路上的车速为以下车速中的最小值：

车辆的平均速度、相邻两节点之间的道路的限速标准、相邻两节点之间的道路的路面的平滑度对应的限速要求、相邻两节点之间的道路的坚固程度对应的限速要求、相邻两节点之间的道路的材质对应的限速要求。

可选的，所述按照各台所述车辆所需的剩余时长，从所述多台车辆的车辆信息中筛选出至少一条目标车辆信息，包括：

选择满足以下至少一种筛选条件的车辆的车辆信息作为所述目标车辆信息：

剩余时长最短的车辆；

剩余时长为剩余时长平均值或中位数的车辆；

剩余时长最长的车辆。

可选的，所述以所述出发地为基准，确定目标地理范围之后，所述方法还包括：

若不存在行车目的地在所述目标地理范围内的车辆，则基于所述出发地确定候选地理范围；

获取行车目的地在所述候选地理范围内的多台候选车辆到达相应目的地所需的剩余时长；

筛选出剩余时长在指定时长内的至少一条目标车辆信息发送给所述终端设备。

可选的，所述以所述出发地为基准，确定目标地理范围，包括：

确定所述出发地所在的热点区域；

以所述热点区域为基准确定所述目标地理范围。

可选的，所述方法还包括：

按照目标车辆信息对应的剩余时长筛选出待分配车辆；

若任一待分配车辆的目标车辆信息发送给多个热点区域内的终端设备，则按照所述待分配车辆的目的地距离各所述热点区域的距离以及各所述热点区域内各终端设备的优先级筛选出目标终端设备；

将所述待分配车辆分配给所述目标终端设备。

第二方面，本申请还提供一种车辆数据处理装置，所述装置包括：

出发地获取模块，用于响应于终端设备的网约车请求，获取所述网约车请求对应的出发地；

目标地理范围确定模块，用于以所述出发地为基准，确定目标地理范围；

剩余时长确定模块，用于获取行车目的地在所述目标地理范围内的多台车辆到达相应目的地所需的剩余时长；

筛选模块，用于按照各台所述车辆所需的剩余时长，从所述多台车辆的车辆信息中筛选出至少一条目标车辆信息；所述目标车辆信息包括车辆标识、目的地和剩余行驶时长；

发送模块，用于将目标车辆信息发送给所述终端设备。

可选的，所述剩余时长确定模块具体用于：

对每台所述车辆，分别执行：

获取所述车辆的剩余行车路线；

基于车速和所述剩余行车路线的长度，以及所述剩余行车路线的每条道路的以下道路信息中的至少一种确定所述车辆的行驶至目的地所需的所述剩余时长：

道路的拥挤程度、所述剩余行车路线中进行转向所耗费的时长、等待交通灯所耗费的时长。

可选的，所述剩余时长确定模块具体用于：

基于以下剩余时长确定公式确定所述剩余时长：

其中，urplusEta表示所述剩余时长；node表示道路的节点；node

其中，相邻节点之间的道路上的车速为以下车速中的最小值：

车辆的平均速度、相邻两节点之间的道路的限速标准、相邻两节点之间的道路的路面的平滑度对应的限速要求、相邻两节点之间的道路的坚固程度对应的限速要求、相邻两节点之间的道路的材质对应的限速要求。

可选的，所述筛选模块，具体用于：

选择满足以下至少一种筛选条件的车辆的车辆信息作为所述目标车辆信息：

剩余时长最短的车辆；

剩余时长为剩余时长平均值或中位数的车辆；

剩余时长最长的车辆。

可选的，所述目标地理范围确定模块以所述出发地为基准，确定目标地理范围之后，所述装置还包括：

候选地理范围确定模块，用于若不存在行车目的地在所述目标地理范围内的车辆，则基于所述出发地确定候选地理范围；

所述剩余时长确定模块，还用于获取行车目的地在所述候选地理范围内的多台候选车辆到达相应目的地所需的剩余时长；

所述筛选模块，还用于筛选出剩余时长在指定时长内的至少一条目标车辆信息发送给所述终端设备。

可选的，所述目标地理范围确定模块，具体用于：

热点区域确定模块，用于确定所述出发地所在的热点区域；

以所述热点区域为基准确定所述目标地理范围。

可选的，所述装置还包括：

分配模块，用于按照目标车辆信息对应的剩余时长筛选出待分配车辆；

若任一待分配车辆的目标车辆信息发送给多个热点区域内的终端设备，则按照所述待分配车辆的目的地距离各所述热点区域的距离以及各所述热点区域内各终端设备的优先级筛选出目标终端设备；

将所述待分配车辆分配给所述目标终端设备。

第三方面，本申请还提供一种电子设备，包括至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行第一方面中任一项所述的方法。

第四方面，本发明还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现第一方面所述方法的步骤。

考虑派车可采用就近原则，实施时考虑用户出发地周围一定范围内作为终点的车辆，然后结合这些车辆行驶到终点所需的剩余时长为用户确定需要显示的车辆信息推送给用户。例如显示车辆当前位置、目的地以及剩余行驶时长给用户，以便于用户了解周边车辆的情况，能够直观的了解可能需要等待多长时间接驾。由此，本申请能够提供更有价值的信息来提高处理资源的利用率。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为根据本申请一实施例提供的应用场景示意图；

图2为根据本申请一实施例提供的车辆数据处理方法的流程示意图；

图3为根据本申请一实施例提供的车辆数据处理方法的另一流程示意图；

图4为根据本申请一实施例提供的车辆数据处理方法的又一流程示意图；

图5为根据本申请一实施例提供的车辆数据处理方法的展示界面示意图；

图6为根据本申请一实施例提供的车辆数据处理装置的结构示意图；

图7为根据本申请一实施例提供的电子设备的结构示意图。

具体实施方式

下面将结合附图对本申请实施例中的技术方案进行清除、详尽地描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；文本中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，另外，在本申请实施例的描述中，“多个”是指两个或多于两个。

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为暗示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征，在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

发明人研究发现，相关技术中提供的需要等待时长一般情况下是根据网约车平台当前需要处理的网约车请求量来确定的。如，一个网约车请求所耗费时长假设是一个已知参数，则基于所有待处理的网约车请求和处理速率，可以确定各待处理的网约车请求需要等待多少时间会被处理。得出的时间作为需要等待时长推送给客户端显示。

然而，网约车请求多长时间能够被处理并非用户关心的核心问题，用户更关心的是多长时间能够有车辆接驾。

有鉴于此，为了提供更有价值的信息来提高处理资源的利用率，本申请实施例提出了一种车辆数据处理方法。

在本申请实施例中，考虑派车可采用就近原则，实施时考虑行驶终点在用户出发地周围的车辆，然后结合这些车辆行驶到终点所需的剩余时长为用户确定需要显示的车辆信息并推送给用户。例如显示车辆当前位置、目的地以及剩余行驶时长给用户，以便于用户了解周边车辆的情况，能够直观的了解可能需要等待多长时间接驾。由此，本申请实施例能够提供更有价值的信息来提高处理资源的利用率。

下面结合附图对本申请实施例提供的车辆数据处理方法进行说明。

图1为根据本申请一个实施例的应用环境的示意图。

如图1所示，该应用场景中例如可以包括存储系统10、服务器20以及终端（例如，图1中30_1与30_2或30_N）。终端可用来进行网络访问的任何合适的电子设备，包括但不限于计算机、笔记本电脑、智能手机、平板电脑、智能手表、智能手环或是其它类型的终端。存储系统10能够存储用户信息、用户状态、地理信息等网约车平台所需的资源。服务器20用于实现与终端的交互来完成网约车业务。如与用车用户的终端交互，实现用车用户下单、为司机派单规划路径进行导航等协助司机完成订单的业务等。

实施时，用车用户基于终端向网约车平台发起网约车请求时，终端可进行定位获得出发地，亦或者基于用户选择或手动输入的信息得到出发地，然后将出发地携带在网约车请求中发送给网约车平台（图1中以服务器20表示）。服务器20基于出发地为用户选择行车终点在以该出发地为基准的n公里内的车辆，然后筛选出一些车辆，将筛选出车辆的剩余行驶时长、车辆标识和位置信息等推送给终端设备显示。由此，用户可以了解到周围车辆的可用情况，合理安排出行计划。

在图1所示的应用场景中，终端之间（例如，30_1与30_2或30_N之间）也可以经由网络40彼此通信。网络40可以是广义上的用于信息传递的网络，可以包括一个或多个通信网络，诸如无线通信网络、因特网、私域网、局域网、城域网、广域网或是蜂窝数据网络等。

本申请中的描述中仅就单个服务器或终端加以详述，但是本领域技术人员应当理解的是，示出的单个服务器20、终端和存储系统10旨在表示本申请的技术方案涉及终端、服务器以及存储系统的操作。对单个终端以及单个服务器和存储系统加以详述至少为了说明方便，而非暗示对终端和服务器的数量、类型或是位置等具有限制。应当注意，如果向图示环境中添加附加模块或从其中去除个别模块，不会改变本申请的示例实施例的底层概念。另外，虽然为了方便说明而在图1中示出了从存储系统10到服务器20的双向箭头，但本领域技术人员可以理解的是，上述数据的收发也是可以通过网络40实现的。

服务器20可以是一台服务器、若干台服务器组成的服务器集群或云计算中心。服务器20可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

如图2所示，为本申请实施例中提供的车辆数据处理方法的一种流程示意图，包括以下内容：

当用户基于终端设备发送网约车请求给网约车平台服务器之后，网约车平台服务器在步骤201中，响应于终端设备的网约车请求，获取网约车请求对应的出发地。

在步骤202中，以出发地为基准，确定目标地理范围。

在一种实施方式中，可以将出发地作为中心确定n公里内的范围为目标地理范围。n为大于0的数值，可以为整数也可以为小数。

由此可以筛选出目的地在目标地理范围内的车辆。这些车辆都是潜在的可分配给用户的车辆。

在另一个实施例中，有些用户可能聚集于同一地理范围内，例如同一办公楼内的用户，同一小区内的用户在用车高峰期时，可能多个用户在几乎相同的地点叫车。

故此，本申请实施例中，还可以设置热点区域，热点区域可以根据用户密度来确定，例如上下班时间段科技园A内的用户较多，可以将科技园A确定为热点区域。例如，同一小区用户基于生活规律某个时间段用户较多，该小区也可以为热点区域。实施时，可基于实际情况合理设置热点区域均适用于本申请实施例。

热点区域实质上实现了对出发地的区域划分，故此，当有多个网约车请求需求处理时，可以确定属于同一热点区域的出发地。实施时，可以确定出发地所在的热点区域；然后以热点区域为基准确定目标地理范围。由此，可以实现同一热点区域内多个终端设备的网约车请求合并处理，进而能够节约处理资源。

得到目标地理范围以后，为了便于合理的显示用户周围可用车辆信息，本申请实施例中在步骤203中，获取行车目的地在目标地理范围内的多台车辆到达相应目的地所需的剩余时长。

然后，在步骤204中，按照各台车辆所需的剩余时长，从多台车辆的车辆信息中筛选出至少一条目标车辆信息；所述目标车辆信息包括车辆标识、目的地和剩余行驶时长。

例如，在一种实施方式中可以筛选出满足以下至少一种筛选条件的车辆的车辆信息作为目标车辆信息：

筛选条件1、剩余时长最短的车辆；即目的地在周围且最快能够结束订单的车辆。

筛选条件2、剩余时长为剩余时长平均值或中位数的车辆；即反映了目的地在周围且能够结束订单的平均用时。

筛选条件3、剩余时长最长的车辆。即反映了目的地在周围且最迟结束订单的可能需要的时长。

由此，当提供以上3种筛选条件的车辆给用户时，使得用户能够了解到周围车辆的详细信息，能够据此合理安排出行计划。

剩余时长的确定一般有赖于剩余路线的长度和行驶速度，本申请实施例中为了能够准确的确定剩余时长，实施时对每台车辆考虑行经的每条道路的情况来确定。实施时，可以获取车辆的剩余行车路线；然后，基于车速和剩余行车路线的长度，以及剩余行车路线的每条道路的以下道路信息中的至少一种确定车辆的行驶至目的地所需的剩余时长。

其中，涉及的道路信息包括以下信息中的至少一种：道路的拥挤程度、剩余行车路线中进行转向所耗费的时长、等待交通灯所耗费的时长等。

由此，可以结合剩余行驶路线中每条道路的实际情况来确定剩余时长，能够提高剩余时长的准确性。

在另一些实施例中，假设剩余行驶路线中包括多段道路，每段道路有相应的节点表示，相邻节点之间对应一段道路，则剩余行驶路线可表示为公式（1）所示。

其中，OrderNodes为从订单当前位置到订单终点，中间所经过的所有路径节点；node

得到剩余行驶路线之后，可基于剩余时长确定公式（如公式2所示）来确定剩余时长：

其中，urplusEta表示所述剩余时长；node表示道路的节点；node

基于公式（2）可知，剩余时长的确定考虑了剩余路线的长度，车辆的行驶速度还考虑了转向所需时长和等待交通灯所需的时长，公式（2）实现了对实际情况的建模考虑了实际情况中应考虑的多种因素，故此确定剩余时长更为准确。

其中，为了尽可能避免确定的剩余时长超过用户实际等待时长，又兼容确定的剩余时长能够与尽可能实际情况更加吻合，本申请实施例中，相邻节点之间的道路上的车速为以下车速中的最小值，包括：车辆的平均速度、相邻两节点之间的道路的限速标准、相邻两节点之间的道路的路面的平滑度对应的限速要求、相邻两节点之间的道路的坚固程度对应的限速要求、相邻两节点之间的道路的材质对应的限速要求等。

如公式（3）所示，每相邻两节点之间的道路所采用的速度Speed均由公式（3）来确定。

其中，Speed

由此，可以实现基于驾驶员的驾驶习惯和道路的坚固程度、行政规划的限速要求以及路面材质、平滑度综合来确定剩余时长，提高剩余时长确定的准确性。

当然，在另一个实施例中，在确定的目标地理范围中寻找不到目的地在该地理范围的车辆时，还可以进一步扩大目标地理范围直至寻找到行驶的终点在目标地理范围内的车辆为止。

在另一个实施例中，若不存在行车目的地在目标地理范围内的车辆，还可以基于出发地确定候选地理范围，然后，获取行车目的地在候选地理范围内的多台候选车辆到达相应目的地所需的剩余时长；之后，筛选出剩余时长在指定时长内的至少一条目标车辆信息发送给终端设备。

需要说明的是，实施时候选地理范围与目标地理范围的大小可以不作限定。

由此，可以通过该方式作为目标地理范围筛选不出车辆时的补充措施，以便于能够尽可能筛选出用户周围可用车辆信息帮助用户了解能够接驾的车辆情况。

得到目标车辆信息之后，可以在步骤205中，将目标车辆信息发送给终端设备。

其中，发送给终端设备的目标车辆信息可包括车辆标识，可实施为虚拟标识，例如车辆1、车辆2、车辆N来标识筛选出的不同车辆。同时还可以包括各车辆运行中订单的目的地和剩余行驶时长以及各车辆的实时地理位置作为车辆信息发送给终端设备。

在基于用户的网约车请求为用户分配车辆时，可以将剩余时长最短的车辆分配给用户。

在另一种情况下，可能将同一车辆作为目标车辆并将其车辆信息发送给多个终端设备。此时，为了避免派车冲突，可借用热点区域进行车辆分配。

如图3所示，可实施为在步骤301中，在分配车辆时，按照目标车辆信息对应的剩余时长筛选出待分配车辆。

例如按照剩余时长由短至长的顺序依序筛选待分配车辆。

在步骤302中，若待分配车辆的目标车辆信息发送给多个热点区域内的终端设备，则按照待分配车辆的目的地距离各热点区域的距离以及各热点区域内各终端设备的优先级筛选出目标终端设备。

例如，可将待分配车辆分配给距离最短的热点区域（即热点区域）。然后，在该热点区域内按照请求时间的先后顺序进行分配。即，下单时间越早越优先分配。

步骤303中，将待分配车辆分配给目标终端设备。

下面结合图4对本申请实施例提供的车辆数据处理方法做进一步说明，包括：

在步骤401中，终端设备发送网约车请求给服务器，网约车请求中携带出发地。

在步骤402中，服务器获取网约车请求中的出发地。

在步骤403中，服务器获取出发地对应热点区域中各网约车请求。

在步骤404中，以热点区域为基准，确定目标地理范围。

在步骤405中，获取行车目的地在目标地理范围内的多台车辆到达相应目的地所需的剩余时长。

在步骤406中，按照剩余时长筛选3辆目标车辆。

如用时最短的车辆，用时中位的车辆以及用时最长的车辆，由此便于了解周围可用车辆的宏观情况。

在步骤407中，将筛选的3辆目标车辆的剩余时长以及目的地发送给终端设备显示。

如图5所示为终端设备显示车辆信息的一种界面示意图。在图5中显示了目标车辆的车辆标识（如车辆1、车辆2），并在图5中显示了各目标车辆的目的地以及行驶至目的地所需的剩余时长。

在另一些实施例中，还可以统计不同剩余时长范围的车辆数，并发送给终端设备显示，例如统计5分钟内周围可结束订单的车辆总量、10分钟周围可结束订单的车辆总量。

基于相同的发明构思，本申请实施例还提供一种车辆数据处理装置，如图6所示，该装置600包括：

出发地获取模块601，用于响应于终端设备的网约车请求，获取所述网约车请求对应的出发地；

目标地理范围确定模块602，用于以所述出发地为基准，确定目标地理范围；

剩余时长确定模块603，用于获取行车目的地在所述目标地理范围内的多台车辆到达相应目的地所需的剩余时长；

筛选模块604，用于按照各台所述车辆所需的剩余时长，从所述多台车辆的车辆信息中筛选出至少一条目标车辆信息；所述目标车辆信息包括车辆标识、目的地和剩余行驶时长；

发送模块605，用于将目标车辆信息发送给所述终端设备。

在一些实施例中，所述剩余时长确定模块具体用于：

对每台所述车辆，分别执行：

获取所述车辆的剩余行车路线；

基于车速和所述剩余行车路线的长度，以及所述剩余行车路线的每条道路的以下道路信息中的至少一种确定所述车辆的行驶至目的地所需的所述剩余时长：

道路的拥挤程度、所述剩余行车路线中进行转向所耗费的时长、等待交通灯所耗费的时长。

在一些实施例中，所述剩余时长确定模块具体用于：

基于以下剩余时长确定公式确定所述剩余时长：

其中，urplusEta表示所述剩余时长；node表示道路的节点；node

其中，相邻节点之间的道路上的车速为以下车速中的最小值：

车辆的平均速度、相邻两节点之间的道路的限速标准、相邻两节点之间的道路的路面的平滑度对应的限速要求、相邻两节点之间的道路的坚固程度对应的限速要求、相邻两节点之间的道路的材质对应的限速要求。

在一些实施例中，所述筛选模块，具体用于：

选择满足以下至少一种筛选条件的车辆的车辆信息作为所述目标车辆信息：

剩余时长最短的车辆；

剩余时长为剩余时长平均值或中位数的车辆；

剩余时长最长的车辆。

在一些实施例中，所述目标地理范围确定模块以所述出发地为基准，确定目标地理范围之后，所述装置还包括：

候选地理范围确定模块，用于若不存在行车目的地在所述目标地理范围内的车辆，则基于所述出发地确定候选地理范围；

所述剩余时长确定模块，还用于获取行车目的地在所述候选地理范围内的多台候选车辆到达相应目的地所需的剩余时长；

所述筛选模块，还用于筛选出剩余时长在指定时长内的至少一条目标车辆信息发送给所述终端设备。

在一些实施例中，所述目标地理范围确定模块，具体用于：

热点区域确定模块，用于确定所述出发地所在的热点区域；

以所述热点区域为基准确定所述目标地理范围。

在一些实施例中，所述装置还包括：

分配模块，用于按照目标车辆信息对应的剩余时长筛选出待分配车辆；

若任一待分配车辆的目标车辆信息发送给多个热点区域内的终端设备，则按照所述待分配车辆的目的地距离各所述热点区域的距离以及各所述热点区域内各终端设备的优先级筛选出目标终端设备；

将所述待分配车辆分配给所述目标终端设备。

关于车辆数据处理装置中各操作的实施以及有益效果可参见前文方法中的描述，此处不再赘述。

在介绍了本申请示例性实施方式的车辆数据处理方法和装置之后，接下来，介绍根据本申请的另一示例性实施方式的电子设备。

所属技术领域的技术人员能够理解，本申请的各个方面可以实现为系统、方法或程序产品。因此，本申请的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式（包括固件、微代码等），或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

在一些可能的实施方式中，根据本申请的电子设备可以至少包括至少一个处理器、以及至少一个存储器。其中，存储器存储有程序代码，当程序代码被处理器执行时，使得处理器执行本说明书上述描述的根据本申请各种示例性实施方式的车辆数据处理方法中的步骤。

下面参照图7来描述根据本申请的这种实施方式的电子设备130。图7显示的电子设备130仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图7所示，电子设备130以通用电子设备的形式表现。电子设备130的组件可以包括但不限于：上述至少一个处理器131、上述至少一个存储器132、连接不同系统组件（包括存储器132和处理器131）的总线133。

总线133表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、外围总线、处理器或者使用多种总线结构中的任意总线结构的局域总线。

存储器132可以包括易失性存储器形式的可读介质，例如随机存取存储器（RAM）1321和/或高速缓存存储器1322，还可以进一步包括只读存储器（ROM）1323。

存储器132还可以包括具有一组（至少一个）程序模块1324的程序/实用工具1325，这样的程序模块1324包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

电子设备130也可以与一个或多个外部设备134（例如键盘、指向设备等）通信，还可与一个或者多个使得用户能与电子设备130交互的设备通信，和/或与使得该电子设备130能与一个或多个其它电子设备进行通信的任何设备（例如路由器、调制解调器等等）通信。这种通信可以通过输入/输出（I/O）接口135进行。并且，电子设备130还可以通过网络适配器136与一个或者多个网络（例如局域网（LAN），广域网（WAN）和/或公共网络，例如因特网）通信。如图所示，网络适配器136通过总线133与用于电子设备130的其它模块通信。应当理解，尽管图中未示出，可以结合电子设备130使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

在一些可能的实施方式中，本申请提供的一种车辆数据处理方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序产品在计算机设备上运行时，程序代码用于使计算机设备执行本说明书上述描述的根据本申请各种示例性实施方式的一种车辆数据处理方法中的步骤。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子（非穷举的列表）包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请的实施方式的用于车辆数据处理的程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在电子设备上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户电子设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户电子设备上部分在远程电子设备上执行、或者完全在远程电子设备或服务端上执行。在涉及远程电子设备的情形中，远程电子设备可以通过任意种类的网络——包括局域网（LAN）或广域网（WAN）—连接到用户电子设备，或者，可以连接到外部电子设备（例如利用因特网服务提供商来通过因特网连接）。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程图像缩放设备的处理器以产生一个机器，使得通过计算机或其他可编程图像缩放设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程图像缩放设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程图像缩放设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。