CN111049937B - 智能网联汽车的数据处理系统及数据传输方法 - Google Patents

Abstract

本发明涉及智能网联汽车技术领域，提供一种智能网联汽车的数据处理系统及数据传输方法。所述数据处理系统包括：后台服务器，用于向车载终端下发数据收集策略文件，并接收车载终端上传的车辆数据；车载终端，用于根据数据收集策略文件，利用网关设备收集车辆数据，并向后台服务器上传；网关设备，用于向车载终端传输各个车辆部件的数据，并在车内网络异常时，缓存相应的待传输数据；以及大数据应用单元，用于从后台服务器获取与预期的大数据应用场景相对应的车辆数据来进行大数据分析。本发明利用有限的带宽资源，设计出一套完美支撑智能网联大数据需求的架构，其通过数据收集策略文件，可以实现自动化适配全车型或单个车辆的信号采集需求。

Description

智能网联汽车的数据处理系统及数据传输方法

技术领域

本发明涉及智能网联汽车技术领域，特别涉及一种智能网联汽车的数据处理系统及数据传输方法。

背景技术

随着汽车智能化和网联化程度的普及，大数据的应用涉及车企的方方面面，通过对车辆实现全车型、全系统的远程在线大数据收集，可为用户提供例如车辆状态查询服务及维修保养建议等，以预防故障发生，从而提升用户的消费体验。同时，大数据也可用于设计研发端，以持续提高及改善车辆的质量和性能。

但是，车辆数据来源的多样性、均衡性、不确定性对传统汽车大数据传输方案等造成了如下的冲击：

1)传统汽车大数据架构的扩展性不强、灵活度较低，其往往将大数据涉及的信号及相关数据通道进行固化(例如，使每个车型根据开始定义的信号量和频率进行整车数据收集)，一旦大数据所需信号发生调整，则从信号源到后台服务器(例如云端)的整个数据传输途径都得被动整改。而随着大数据的数据广度需求(例如已逐渐从单一零部件的小数据，向多系统多车型交融的大数据方向发展)、数据完整性需求和/或数据时效性需求的不断提高，这种固定僵硬的数据传输途径已明显无法满足智能网联对大数据的需求。

2)传统汽车大数据方案的数据收集并不适配于车辆实际网络，因为车辆实际的总线网络带宽资源是有限的，宽口径的数据收集会造成车辆总线网络带宽资源的浪费，降低大数据系统的运行效率，同时还会导致车辆总线网络负载率爆表，给整车带来安全隐患。

发明内容

有鉴于此，本发明旨在提出一种智能网联汽车的数据处理系统，以至少部分地解决上述技术问题。

为达到上述目的，本发明的技术方案是这样实现的：

一种智能网联汽车的数据处理系统，包括设置在云端的后台服务器和大数据应用单元以及设置在车机端的车载终端和网关设备，其中：所述后台服务器，被配置为与所述车载终端及所述大数据应用单元通信连接，且用于向所述车载终端下发数据收集策略文件，并接收所述车载终端响应于所述数据收集策略文件而上传的车辆数据，其中所述数据收集策略文件用于规定所述车载终端进行数据收集的数据收集方式和数据收集内容；所述车载终端，用于根据所述数据收集策略文件的规定，利用所述网关设备收集车辆数据，并向所述后台服务器上传收集的车辆数据；所述网关设备，用于建立所述车载终端与各个车辆部件之间基于车内网络的通信，以向所述车载终端传输所述各个车辆部件的数据，并在所述车内网络异常时，缓存相应的待传输数据；以及所述大数据应用单元，用于从所述后台服务器获取与预期的大数据应用场景相对应的车辆数据来进行大数据分析。

进一步的，所述后台服务器被配置为包括：信号仓，该信号仓基于车型信息被配置，并用于以物料清单BOM结构存储各车型的信号量及信号量编码规则，其中所述BOM结构与车辆的整车逻辑结构相一致；以及信号检索引擎模块，用于从所述车载终端获取车型信息，并根据所述车型信息从所述信号仓中检索出相应的信号量以用于形成所述数据收集策略文件。

进一步的，所述数据收集方式包括：周期收集方式，被配置为规定所述车载终端以设定的采集周期收集车辆数据，并以设定的上传周期向所述后台服务器上传车辆数据；事件收集方式，被配置为规定所述车载终端在所收集的车辆数据的大小大于或等于设定大小时向所述后台服务器上传车辆数据，或者被配置为规定所述车载终端在收集时间到达设定的文件上传周期时，将在所述文件上传周期内收集的车辆数据生成为文件并上传至所述后台服务器；和/或端点检测与响应EDR收集方式，被配置为将待收集的车辆数据以数据队列形式存储在缓冲区，并在接收到触发信号的时刻，将该时刻前后预设时段内的数据生成文件并上传至所述后台服务器。

进一步的，所述数据收集内容包括待收集数据的版本号、数据数量、数据位置和收集频率。

进一步的，所述网关设备被配置为包括：存储器，用于在所述车内网络异常时，缓存所述待传输数据。

进一步的，所述存储器用于缓存所述待传输数据包括：给存储至所述存储器的数据分配传输优先级；以及若所述存储器的可用存储空间无法存储新的数据，则选择传输优先级低于该新的数据的部分数据进行删除，其中正处于数据传输过程中的数据不能被选择。

进一步的，所述网关设备还用于在所述车载终端请求收集的数据量超出该车载终端所在网段的负荷时，将对应于所述车载终端之外的任意一个或多个其他车辆部件的网段的信号路由给所述车载终端。

进一步的，所述网关设备具有根据所述车载终端的数据收集要求临时配置的动态路由表，并且所述网关设备获取所述动态路由表所指定的车辆部件的数据并向所述车载终端传输。

进一步的，所述大数据应用单元针对不同的大数据应用场景，包括以下大数据模型单元中的至少一者或多者：车险管理单元，用于从所述后台服务器获取车主的驾驶行为数据来进行大数据分析，以实现车险管理；交通管理单元，用于从所述后台服务器获取车辆的驾驶数据来进行大数据分析，以实现交通管理；二手车评估单元，用于从所述后台服务器获取车辆的维保数据、诊断数据以及同车型车辆的成交数据来进行大数据分析，以实现二手车评估；电池管理单元，用于从所述后台服务器获取车辆的电量信息来进行大数据分析，以实现电池管理；埋点管理单元，用于从所述后台服务器获取车辆的车机日志数据来进行大数据分析，以实现埋点管理；以及售车管理单元，用于从所述后台服务器获取车辆的用户特征数据来进行大数据分析，以实现售车管理。

相对于现有技术，本发明所述的智能网联汽车的数据处理系统能够利用有限的带宽资源，设计出一套完美支撑智能网联大数据需求的架构方案，该方案通过灵活配置数据收集策略文件，可以实现自动化适配全车型或单个车辆的信号采集需求。

本发明的另一目的在于提出一种智能网联汽车的数据传输方法，以至少部分地解决上述技术问题。

为达到上述目的，本发明的技术方案是这样实现的：

一种智能网联汽车的数据传输方法，应用于上述任意的数据处理系统，且包括：所述车载终端登录所述后台服务器，并向所述后台服务器传输车型信息；所述后台服务器根据所述大数据应用单元的大数据应用需求，向所述车载终端下发与所述车型信息及所述大数据应用需求相匹配的数据收集策略文件；所述车载终端响应于所述数据收集策略文件，向所述网关设备请求收集包括相应数据收集内容的车辆数据；所述网关设备通过车内网络向所述车载终端传输所述车辆数据，其中在所述车内网络异常时，所述网关设备缓存相应的待传输数据以等待所述车内网络恢复正常；以及所述车载终端按照所述数据收集方式向所述后台服务器上传所收集的车辆数据。

所述智能网联汽车的数据传输方法与上述智能网联汽车的数据处理系统相对于现有技术所具有的优势相同，在此不再赘述。

本发明的其它特征和优点将在随后的具体实施方式部分予以详细说明。

附图说明

构成本发明的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施方式及其说明用于解释本发明，并不构成对本发明的不当限定。

在附图中：

图1是本发明实施例的智能网联汽车的数据处理系统的结构示意图；

图2是本发明实施例的数据处理系统所包括的后台服务器的结构示意图；

图3是本发明实施例的示例信号仓BOM结构；

图4是本发明实施例中后台服务器和车载终端进行信息交互的流程示意图；

图5是本发明实施例中从车辆经网关设备和车载终端向后台服务器传输数据的信号流程图；

图6是本发明实施例中网关设备进行数据缓存的流程示意图；

图7(a)与图7(b)分别为车辆总线未叠加大数据功能和叠加大数据功能所涉及的网段负载情况的示意图；以及

图8是本发明另一实施例的智能网联汽车的数据传输方法的流程示意图。

附图标记说明：

100、后台服务器；200、车载终端；300、网关设备；400、大数据应用单元；110、信号仓；120、信号检索引擎模块。

具体实施方式

需要说明的是，在不冲突的情况下，本发明中的实施方式及实施方式中的特征可以相互组合。

另外，在本发明实施例中，智能网联汽车(Intelligent Connected Vehicle，ICV)是指车联网与智能汽车的有机联合，其可参考现有技术进行理解。另外，在本发明实施例中，术语“数据”、“信息”、“信号”、“报文”、“数据包”、“帧”可相互交换进行理解，术语“采集”与“收集”也可相互交换进行理解。

下面将参考附图并结合实施方式来详细说明本发明。

图1是本发明实施例的一种智能网联汽车的数据处理系统的结构示意图。如图1所示，所述数据处理系统包括设置在云端的后台服务器100和大数据应用单元400以及设置在车机端的车载终端200和网关设备300。

举例而言，所述后台服务器100可以是TSP(Telematics Service Provider，汽车远程服务提供商)后台，所述车载终端200例如是车载TBOX(Telematics BOX)，所述网关设备300例如是常规GW(Gateway，网关)，而所述大数据应用单元400可包括多个大数据模型单元，这些大数据模型单元可根据需要进行配置，具体的模型类型将在下文进行列举。需说明的是，下文介绍数据处理系统的构成及实施细节时，多以TSP、TBOX和GW为例。

参考图1，在本发明实施例中，所述数据处理系统所包括的各个部分可按如下描述进行配置。

一、后台服务器100

所述后台服务器100，被配置为与所述车载终端200及所述大数据应用单元200通信连接，且用于向所述车载终端200下发数据收集策略文件，并接收所述车载终端200响应于所述数据收集策略文件而上传的车辆数据。

其中，所述数据收集策略文件是一种配置文件，其用于规定所述车载终端进行数据收集的数据收集方式和数据收集内容。

在优选的实施例中，由后台服务器100规定且为车载终端200所支持的数据收集方式可以包括以下三种中的任意一者或多者：

1)周期收集方式，被配置为规定所述车载终端以设定的采集周期收集车辆数据，并以设定的上传周期向所述后台服务器上传车辆数据；

2)事件收集方式，被配置为规定所述车载终端在所收集的车辆数据的大小大于或等于设定大小时向所述后台服务器上传车辆数据，或者被配置为规定所述车载终端在收集时间到达设定的文件上传周期时，将在所述文件上传周期内收集的车辆数据生成为文件并上传至所述后台服务器；

3)端点检测与响应(Endpoint Detection&Response，EDR)收集方式，被配置为将待收集的车辆数据以数据队列形式存储在缓冲区，并在接收到触发信号的时刻，将该时刻前后预设时段内的数据生成文件并上传至所述后台服务器。

表1示出了对应于这三种数据收集方式的示例，具体如下：

表1

传统汽车大数据方案往往只有一种基于周期的数据收集方式，远远无法满足大数据的应用场景需求，而本发明实施例通过表1中的四种数据收集方式解决了这一问题。

进一步地，在优选的实施例中，所述数据收集内容可以包括待收集数据的版本号、数据数量、数据位置和收集频率。举例而言，TSP后台下发的配置策略文件包含：版本号(即，数据收集方案号)+要收集的信号数量+信号1位置和收集频率+信号2位置和收集频率+信号3位置和收集频率+……+信号n位置和收集频率。

基于此，可知通过灵活配置所述配置策略文件，能够使得本发明实施例的数据处理系统随时针对不同车型匹配不同的配置策略文件，从而间接地更新了所述车载终端数据收集方案，打破了传统汽车大数据方案固定僵硬的数据传输途径。在更为优选的实施例中，为使所述配置策略文件能适配更多车型并与整车逻辑结构一致，所述后台服务器100被配置为图2所示的结构，其包括：信号仓110，该信号仓100基于车型信息被配置，并用于以物料清单(Bill of Material，BOM)结构存储各车型的信号量及信号量编码规则，其中所述BOM结构与车辆的整车逻辑结构相一致；信号检索引擎模块120，用于从所述车载终端200获取车型信息，并根据所述车型信息从所述信号仓110中检索出相应的信号量以用于形成所述数据收集策略文件。

需说明的是，本发明实施例中使得BOM结构与车辆的整车逻辑结构相一致的方案利用了数字孪生的思路，实现了在后台服务器100搭建与实车等效的信号仓BOM结构。

参考图3，后台服务器100会可基于车型信号库(包括车型1、车型2……)建立一个信号仓110，该信号仓包含各车型所有物理量(例如照明物理量及其下关于近光灯和远光灯的分量)，以及各物理量对应的信号量(例如信号ID1、信号ID2……信号ID6)和信号量编码规则。信号仓110可基于预设的信号量编码规则对收集的信号进行管理。本发明实施例中，信号仓110中存储的大数据收集信息范围可覆盖整车所有的CAN信号，而后台服务器100响应于信号检索引擎模块120获取车型信息，从所述信号仓110中调取数据灵活配置每次数据收集的数据收集内容。

需说明的是，后台服务器100配置每次数据收集的数据收集内容还可能与所述大数据应用单元400所针对的大数据应用场景相关联，即需要考虑大数据应用的需求，这将在下文结合所述大数据应用单元400的示例进行描述，在此则不再进行赘述。

二、车载终端200

所述车载终端200，被配置为根据所述数据收集策略文件的规定，利用所述网关设备300收集车辆数据，并向所述后台服务器100上传收集的车辆数据。

以后台服务器100为TSP后台，车载终端200为TBOX为例，图4是本发明实施例中后台服务器和车载终端进行信息交互的流程示意图。参考图4，在示例中，具体的信息交互过程可包括以下步骤：

步骤S401，TBOX登录TSP后台，并告知TSP后台车型信息。

举例而言，TBOX唤醒后和TSP后台建立联接，联接建立后，TBOX向TSP后台告知车型信息。

步骤S402，TSP后台下发大数据收集指令。

步骤S403，TBOX响应大数据收集指令而上传数据。

对于步骤S401-步骤S403，它们示出了从云端到车机端的大数据收集的“自上而下”过程及“由下而上”过程，分别如下：

1)“自上而下”过程。

举例而言，云端的TSP后台根据接收到车型信息确定要下发的数据收集策略文件属于哪个车型以及哪个版本，据此下发指令到TBOX，TBOX筛选出需要GW额外转发的路由报文，GW收到指令后将这些报文路由到TBOX的网段上。

2)“由下而上”过程

举例而言，TBOX按照TSP后台下发的指令，进行相应频率的CAN报文收集并上传到云端的TSP后台。其中，所述CAN报文例如来自于车辆的车身控制模块(Body ControlModule，BCM)、主机导航系统(本领域也常称其为HUT)、仪表单元(Instrument Panel，IP)、交流电源(Alternating Current，AC)等等。其中，TBOX是利用网关设备300来收集各个车辆部件的数据，该细节将在下文描述，在此则不再赘述。

另外，参考上述的表1，车载终端200通过网关设备300收集数据后，可能是将数据形成文件并上传至后台服务器100。举例而言，形成的文件可包括：文件的起始时间戳、文件格式及计时方式、数据收集方案号、数据收集起始标识符、数据格式等。示例的文件格式如下所示：

后台服务器100可直接按该文件格式将接收的文件存储至信号仓中如图3所示的BOM结构的相关位置。

三、网关设备300

所述网关设备300，用于建立所述车载终端200与各个车辆部件之间基于车内网络的通信，以向所述车载终端传输所述各个车辆部件的数据，并在所述车内网络异常时，缓存相应的待传输数据。其中，所述各个车辆部件例如是前述的BCM、HUT、IP、AC等，当然也包括TBOX；所述车内网络例如为4G网络或WLAN网络。

网关设备300获取车辆数据后，在其向车载终端200传输的过程中，因无4G等网络问题，车载终端200会直接将传输数据丢失。对此，在优选的实施例中，所述网关设备300被配置为包括存储器，该存储器用于在所述车内网络异常时，缓存所述待传输数据。其中，所述存储器例如是存储卡。

图5是本发明实施例中从车辆经网关设备300和车载终端200向后台服务器100传输数据的信号流程图。如图5所示，具体可包括以下步骤：

步骤S501，从车辆部件收集数据。

举例而言，即是车载终端200根据数据收集策略文件的规定，向网关设备300要求获取相应数据。

在优选的实施例中，所述网关设备300具有可随时根据所述车载终端200的数据收集要求临时配置的动态路由表，并且所述网关设备300获取所述动态路由表所指定的车辆部件的数据(或称报文、CAN报文或CAN信号)并向所述车载终端200传输。其中，所述车载终端200的数据收集要求由其根据接收的数据收集策略文件来进行配置。其中，网关设备300可以利用PDU(一种报文封装形式)来完成报文的格式转换以用于路由。

步骤S502，判断是否存在可用网络，若是则执行步骤S503，否则执行步骤S504。

举例而言，判断车内是否存在可用的4G或WLAN网络。

步骤S503，在存在可用网络时，车载终端200接收数据。

步骤S504，在不存在可用网络时，网关设备300缓存数据，并在车内网络恢复正常后，将缓存的数据传输至所述车载终端200。

步骤S505，车载终端200向后台服务器100上传数据。

需注意的是，虽然存储器的缓存功能可避免因网络问题造成的数据丢失。但即使配置有存储器的网关设备依然存储空间有限，不易保证数据的完整性。

对此，在优选的实施例中，针对步骤S504，所述网关设备300通过其内置的存储器来缓存数据，而具体的缓存方法可包括：给存储至所述存储器的数据分配传输优先级；以及若所述存储器的可用存储空间无法存储新的数据，则选择传输优先级低于该新的数据的部分数据进行删除，其中正处于数据传输过程中的数据不能被选择。其中，正处于数据传输过程中的数据是指已经开始传输但传输过程还未完成的数据。另外，在删除数据时，所删除的数据量应尽量少，以刚好满足新数据的存储需求为原则。

更为优选地，图6是本发明实施例中网关设备300进行数据缓存的流程示意图，其中所缓存的数据为数据包格式，且通过图6示出了上述选择传输优先级低于该新的数据的部分数据进行删除的优选方案。参考图6，具体可包括以下步骤：

步骤S601，判断是否有足够存储空间，若是，则执行步骤S602，否则执行步骤S603。

步骤S602，存储新数据包。

其中，存储新数据包后，可返回示出存储成功的指示。

步骤S603，判断存储器中是否已存有低优先等级的数据包，若是则执行步骤S604，否则执行步骤S605。

其中，该低优先等级的数据包是指优先级低于新数据包的数据包。

步骤S604，删除低优先等级的旧数据包，并返回步骤S601。

步骤S605，判断存储器中是否有相同优先等级的数据包，若是则执行步骤S607，否则执行步骤S606，。

步骤S606，丢弃新数据包。

其中，丢弃新数据包后，可返回示出存储不成功的指示。

步骤S607，判断存储器中是否存在有效期更短的数据包，若是则执行步骤S608，否则返回步骤S606。

其中，关于有效期的长短是基于与新数据包的比较来确定的。

步骤S608，删除有效期短的旧数据包。

如此，通过步骤S601-S608，可使得网关设备300能够实时地缓存传输优先级高的数据包，以在网络恢复正常后，再继续将这些数据包传输给车载终端200。因此，利用网关设备300的缓存功能，可有效地控制因无网络或网络故障造成的传输数据的丢失问题。

进一步地，网关设备(GW)要求能够接入车辆所有的CAN总线，从而网络设备300可以采集到所有车辆部件的数据。例如，GW可接图1中所示出的PTCAN总线(Power Train CAN总线，动力驱动CAN总线，也可直接简称为PT总线)和车身控制总线(也称BodyCAN总线)。其中，每一车辆部件对应总线的不同网段。图7(a)与图7(b)分别为车辆总线未叠加大数据功能和叠加大数据功能所涉及的网段负载情况示意图，以车辆终端为TBOX为例，从图7(a)与图7(b)可以看出：未叠加大数据功能时，TBOX网段负载率为11.49％，而叠加大数据功能后，TBOX网段负载率为33.45％。从而可知，大数据对TBOX网段的负载率影响很大的，而过大的数据上传任务可能也会使网关丢帧。这是上文中利用数据收集策略文件来管理数据收集方式和数据收集内容的重要原因，据此也可以使得大数据收集适配于车辆实际的网络带宽。

更进一步地，除利用数据收集策略文件之外，针对上述大数据对TBOX网段的负载率影响很大的问题，本发明实施例还利用网关设备对网段的灵活配置来实现。具体地，本发明实施例配置所述网关设备300还用于在所述车载终端200请求收集的数据量超出该车载终端所在网段的负荷时，将对应于所述车载终端之外的任意一个或多个其他车辆部件的网段的信号路由给所述车载终端。举例而言，在TBOX当前所在网段无法满足其数据收集需求时，网关设备300根据该车载终端的数据收集需求，将例如HUT网段的信号选择性地路由到TBOX所在网段，从而扩展了TBOX网段，使其能满足当前的数据收集需求。

需说明的是，网关设备将整车其他网段的信号选择性路由到TBOX网段时，需遵循一定的规则，例如：总线负载率不能被100％使用，一般只能使用50％以下；不能完全占用其他网段的负载率，各网段都应具有一定的负载率；进行选择性路由时，需判断各网段是否有额外的负载率可以提供，不予选择本身处于高负载率情况的网段等等。

通过上述对网关设备300的配置，本发明实施例实质上实现了针对网络条件和本地资源的数据传输保护，以及实现了针对整车总线负载率的数据传输保护。在此，对网络条件、本地资源和整车总线负载率的考虑使得本发明实施例关于大数据处理的方案完全适配于车辆实际网络，例如适配于有限的网络带宽。易知，大数据只有适配于车辆实际网络才具有可行性，而传统汽车大数据方案正是受制于这点而不具有可行性。

四、大数据应用单元400

所述大数据应用单元400，用于从所述后台服务器100获取与预期的大数据应用场景相对应的车辆数据来进行大数据分析。举例来说，该大数据应用单元400即是通过对车辆大数据进行数据处理、分析和/或预测，以获得在某一领域或某一场景的优势。

在本发明优选的实施例中，所述大数据应用单元400针对不同的大数据应用场景，可以例如为以下大数据模型单元中的至少一者或多者。

1)车险管理单元

该车险管理单元用于从所述后台服务器100获取车主的驾驶行为数据来进行大数据分析，以实现车险管理。

该车险管理单元适用于保险公司或车企。举例而言，通过本发明实施例的数据处理系统，后台服务器100从智能网联汽车收集车主的驾驶行为数据，车险管理单元从后台服务器100中获取相应的驾驶行为数据以评判车主的驾驶行为习惯，从而可准确评估车主驾驶的好与坏，而不是简单地、主观地进行人为评判。因此，在大数据的支持下，可增进车辆保险的质量，使车企和保险公司达到双赢的局面。

2)交通管理单元

该交通管理单元用于从所述后台服务器100获取车辆的驾驶数据来进行大数据分析，以实现交通管理。

该交通管理单元适用于交通部门或导航服务提供服务商。举例而言，通过本发明实施例的数据处理系统，后台服务器100从多个智能网联汽车收集用户的驾驶数据，而该驾驶数据涉及导航数据、车速数据等。交通管理单元从后台服务器100中获取多个车辆的导航数据以预测交通情况(例如哪一路段可能会发生拥挤等)，并可根据预测结果，向各车驾驶员推荐行驶路线；或者交通管理单元从后台服务器100获取各车辆的车速数据，并与各路段的路况进行对比，据此判断车辆是否存在超速、闯红灯等，并予以提醒和警告。据此，通过这样的交通管理单元，能缓解交通压力，并有效地减少交通事故发生概率，打击各类交通违章和违法行为，给车主最为直接实时的交通信息服务。因此，在大数据的支持下，可推动智慧交通的发展。

3)二手车评估单元

二手车评估单元用于从所述后台服务器100获取车辆的维保数据、诊断数据以及同车型车辆的成交数据来进行大数据分析，以实现二手车评估。

该二手车评估单元适用于二手机交易平台或用户个人。举例而言，通过本发明实施例的数据处理系统，后台服务器100获取某二手车的维保数据、诊断数据以及同车型车辆的成交数据，且二手车评估单元获取这些数据来对二手车的真实价值进行评估。

4)电池管理单元

电池管理单元用于从所述后台服务器100获取车辆的电量信息来进行大数据分析，以实现电池管理。

该电池管理单元适用于车辆远程监控平台。举例而言，通过本发明实施例的数据处理系统，后台服务器100收集车辆蓄电池的电量信息，电池管理单元获取电量信息以进行大数据分析，包括：当车辆电量下降到某限额时，会触发大数据分析找到馈电原因，例如若原因在于忘记关闭车灯，则可远程提醒关闭车灯，再例如若因蓄电池相关问题导致抛锚，则在分析真实原因之外，还可提醒车主，以便采取措施，提升服务品质。

5)埋点管理单元

埋点管理单元用于从所述后台服务器100获取车辆的车机日志数据来进行大数据分析，以实现埋点管理。

该埋点管理单元适用于车辆制造企业，车机埋点可以便于企业更好地了解客户，为整车的研发改善提供有力支持。举例而言，通过本发明实施例的数据处理系统，后台服务器100收集车机日志(log文件)数据，埋点管理单元以车机日志数据为基础，记录客户的使用习惯和偏好，生成月度车机日志数据，运用统计分析法、回归分析法以及关联规则等数据挖掘技术，分析用户访问行为的时间特征和信息需求特征等，用以改善或提升车辆功能。

6)售车管理单元

售车管理单元用于从所述后台服务器100获取车辆的用户特征数据来进行大数据分析，以实现售车管理。

该售车管理单元适用于车辆销售企业或车辆制造企业。举例而言，通过本发明实施例的数据处理系统，后台服务器100收集用户特征数据，售车管理单元以用户特征数据为基础，通过大数据对消费群体分析，产生高度精炼的用户特征标识(如90后、务实人群等)，从而提供精准营销服务及销量预测服务，并指导新车型的研发。

通过上述六种类型的大数据应用单元400，可知本发明实施例将应用与数据进行融合，能从多个方面提升用户体验。

返回到图1，同样以大数据模型单元、TSP后台、TBOX、GW为例，本发明实施例的数据处理系统独立于实现服务的硬件平台、操作系统以及编程语言，大数据模型单元、TSP后台单元和车内TBOX、GW以一种通用的方式进行交互，交互的变量通过一种简单、精确的接口方式进行定义，但不涉及底层编程接口和通讯模式。并且，物理量和信号量，信号量和配置文件(数据收集策略文件)，配置文件和路由的CAN报文之间没有强制的绑定关系，可以根据不同服务、不同车型来灵活组合和随意配置。

综上所述，本发明实施例的智能网联汽车的数据处理系统利用有限的带宽资源，设计出一套完美支撑智能网联大数据需求的架构方案，该方案通过灵活自由地配置数据收集策略文件，可以实现自动化适配全车型或单个车辆的信号采集需求。更为具体地，本发明实施例的智能网联汽车的数据处理系统相对于传统汽车大数据方案，至少可以包括以下几个方面的优势：

1)传统汽车大数据方案的开发思路是面向应用，由特定的功能应用场景，确定需要的信号及信号传输路径，然后再确定开发计划和费用，其缺点是随着大数据需求的不断变化以及服务需求和应用场景的持续更新，导致整车的开发周期及开发进度不可控。对此，本发明实施例的数据处理系统搭建了云端和车机端的松耦合(即云端和车机端并不清楚对方如何实现)，其面向大数据应用场景，在云端和车机端分别建立动态可配置的信号仓和动态路由表，且云端的后台服务器和大数据应用单元以及设置在车机端的车载终端和网关设备按不同的功能单元进行拆分，并通过定义的接口和协议联接起来，且使得后台服务器下发的数据收集策略文件和网关设备路由的CAN报文之间没有强制的绑定关系，从而可以根据不同服务、不同车型灵活组合及随意配置数据收集策略。另外，大数据应用单元和后台服务器各自独立设置，避免了两者相集成所带来的系统反应速度慢的问题，有利于减少客户抱怨。

2)本发明实施例的智能网联汽车的数据处理系统所设计的架构方案包括大数据收集功能系统拓扑、数据管道与信号仓、数据应用设施的技术架构方案，可深入到操作系统、协议栈、信号处理等更底层的技术领域，从根本上确保了方案的技术优势和独立性。

3)建立车型级信号仓，其可以存储整车所有信号，而单次使用时可从信号仓中抓取数据，并通过后台服务器灵活自由地下发包括所需信号及频率的数据收集策略文件，避免了车辆带宽的限制，需要什么任意部件的电子控制单元(Electronic Control Unit，ECU)的信号频率就可以通过后台服务器下发相关ECU的数据收集策略文件，该部件就会根据后台服务器下发的数据收集策略文件进行上传。因此，信号仓与信号抓取的双管齐下，打破了传统汽车大数据方案固化的数据传输途径。

4)通过周期收集方式，保持了心跳的链接，更新了数据的状态；通过事件收集方式，保证了数据内容的完整性和应用的实时性；通过两种方式的结合，克服了网络延迟、信道拥塞等外在干扰，产生了更快的网络服务响应，减少了网络传输负荷与后台服务器计算负荷，满足了应用多个大数据场景(如智能、安全与隐私保护等方面)的需求。因此，本发明实施例的三种数据收集方式，满足了数据的完整性和时效性需求，保证了数据的新鲜度。

图8是本发明另一实施例的一种智能网联汽车的数据传输方法的流程示意图，该数据传输方法应用上述实施例的数据处理系统，且可以包括如下：

步骤S801，所述车载终端登录所述后台服务器，并向所述后台服务器传输车型信息。

步骤S802，所述后台服务器根据所述大数据应用单元的大数据应用需求，向所述车载终端下发与所述车型信息及所述大数据应用需求相匹配的数据收集策略文件。

步骤S803，所述车载终端响应于所述数据收集策略文件，向所述网关设备请求收集包括相应数据收集内容的车辆数据。

步骤S804，所述网关设备通过车内网络向所述车载终端传输所述车辆数据，其中在所述车内网络异常时，所述网关设备缓存相应的待传输数据以等待所述车内网络恢复正常。

步骤S805，所述车载终端按照所述数据收集方式向所述后台服务器上传所收集的车辆数据。

本发明实施例的智能网联汽车的数据传输方法的实施细节及效果可参考上述关于智能网联汽车的数据处理系统的实施例，在此不再进行赘述。

以上所述仅为本发明的较佳实施方式而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种智能网联汽车的数据处理系统，其特征在于，所述智能网联汽车的数据处理系统包括设置在云端的后台服务器和大数据应用单元以及设置在车机端的车载终端和网关设备，其中：

所述后台服务器，被配置为与所述车载终端及所述大数据应用单元通信连接，且用于向所述车载终端下发数据收集策略文件，并接收所述车载终端响应于所述数据收集策略文件而上传的车辆数据，其中所述数据收集策略文件用于规定所述车载终端进行数据收集的数据收集方式和数据收集内容；

所述车载终端，用于根据所述数据收集策略文件的规定，利用所述网关设备收集车辆数据，并向所述后台服务器上传收集的车辆数据；

所述网关设备，用于建立所述车载终端与各个车辆部件之间基于车内网络的通信，以向所述车载终端传输所述各个车辆部件的数据，并在所述车内网络异常时，缓存相应的待传输数据；以及

所述大数据应用单元，用于从所述后台服务器获取与预期的大数据应用场景相对应的车辆数据来进行大数据分析；

其中，所述后台服务器被配置为包括：

信号仓，该信号仓基于车型信息被配置，并用于以物料清单BOM结构存储各车型的所有物理量及各物理量对应的信号量和信号量编码规则，其中所述BOM结构与车辆的整车逻辑结构相一致；以及

信号检索引擎模块，用于从当前对应的所述车载终端获取车型信息，并根据所述车型信息从所述信号仓中检索出相应的信号量以用于形成所述数据收集策略文件；

其中，所述后台服务器还用于将所接收的所述车辆数据存储至所述信号仓中的所述BOM结构的相关位置。

2.根据权利要求1所述的智能网联汽车的数据处理系统，其特征在于，所述数据收集方式包括：

周期收集方式，被配置为规定所述车载终端以设定的采集周期收集车辆数据，并以设定的上传周期向所述后台服务器上传车辆数据；

事件收集方式，被配置为规定所述车载终端在所收集的车辆数据的大小大于或等于设定大小时向所述后台服务器上传车辆数据，或者被配置为规定所述车载终端在收集时间到达设定的文件上传周期时，将在所述文件上传周期内收集的车辆数据生成为文件并上传至所述后台服务器；和/或

端点检测与响应EDR收集方式，被配置为将待收集的车辆数据以数据队列形式存储在缓冲区，并在接收到触发信号的时刻，将该时刻前后预设时段内的数据生成文件并上传至所述后台服务器。

3.根据权利要求1所述的智能网联汽车的数据处理系统，其特征在于，所述数据收集内容包括待收集数据的版本号、数据数量、数据位置和收集频率。

4.根据权利要求1所述的智能网联汽车的数据处理系统，其特征在于，所述网关设备被配置为包括：

存储器，用于在所述车内网络异常时，缓存所述待传输数据。

5.根据权利要求4所述的智能网联汽车的数据处理系统，其特征在于，所述存储器用于缓存所述待传输数据包括：

给存储至所述存储器的数据分配传输优先级；以及

若所述存储器的可用存储空间无法存储新的数据，则选择传输优先级低于该新的数据的部分数据进行删除，其中正处于数据传输过程中的数据不能被选择。

6.根据权利要求1所述的智能网联汽车的数据处理系统，其特征在于，所述网关设备还用于在所述车载终端请求收集的数据量超出该车载终端所在网段的负荷时，将对应于所述车载终端之外的任意一个或多个其他车辆部件的网段的信号路由给所述车载终端。

7.根据权利要求1所述的智能网联汽车的数据处理系统，其特征在于，所述网关设备具有根据所述车载终端的数据收集要求临时配置的动态路由表，并且所述网关设备获取所述动态路由表所指定的车辆部件的数据并向所述车载终端传输。

8.根据权利要求1所述的智能网联汽车的数据处理系统，其特征在于，所述大数据应用单元针对不同的大数据应用场景，包括以下大数据模型单元中的至少一者或多者：

车险管理单元，用于从所述后台服务器获取车主的驾驶行为数据来进行大数据分析，以实现车险管理；

交通管理单元，用于从所述后台服务器获取车辆的驾驶数据来进行大数据分析，以实现交通管理；

二手车评估单元，用于从所述后台服务器获取车辆的维保数据、诊断数据以及同车型车辆的成交数据来进行大数据分析，以实现二手车评估；

电池管理单元，用于从所述后台服务器获取车辆的电量信息来进行大数据分析，以实现电池管理；

埋点管理单元，用于从所述后台服务器获取车辆的车机日志数据来进行大数据分析，以实现埋点管理；以及

售车管理单元，用于从所述后台服务器获取车辆的用户特征数据来进行大数据分析，以实现售车管理。

9.一种智能网联汽车的数据传输方法，其特征在于，应用于权利要求1至8中任意一项所述的智能网联汽车的数据处理系统，且包括：

所述车载终端登录所述后台服务器，并向所述后台服务器传输车型信息；

所述后台服务器根据所述大数据应用单元的大数据应用需求，向所述车载终端下发与所述车型信息及所述大数据应用需求相匹配的数据收集策略文件；

所述车载终端响应于所述数据收集策略文件，向所述网关设备请求收集包括相应数据收集内容的车辆数据；

所述网关设备通过车内网络向所述车载终端传输所述车辆数据，其中在所述车内网络异常时，所述网关设备缓存相应的待传输数据以等待所述车内网络恢复正常；以及

所述车载终端按照所述数据收集方式向所述后台服务器上传所收集的车辆数据。

Images