一种CAN数据采集方法及装置与流程

本申请属于车联网技术领域，尤其涉及一种can数据采集方法及装置。

背景技术：

车联网是物联网在汽车领域的典型应用，它以车内can总线网络、无线通信网、互联网为基础，按照约定的通信协议和数据交互标准，在车-人、车-路、车-车之间，进行实时的无线通讯和信息交换，从而能够实现智能交通管理、智能动态信息服务和车辆智能化控制的一体化网络体系。can总线远程监测作为车联网的核心，能够以非常高的频率采集车辆的发动机、传动、制动、储能、灯光、车门、电气，以及里程、速度、定位等各方面的运行数据(即车辆信息)，并实时传送到云端服务器。

现有的车辆信息采集方案通常是，首先针对具体需求确定需要接收哪类can数据，然后，车载设备根据配置从can总线上筛选出指定的can数据，并对can数据进行解析和初步分析之后回传至云端服务器。在这种车联网架构中，车载设备承担的任务主要包括数据接收、筛选、初步分析和结果的上传，而云端服务器主要的任务是分析结果的汇总、统计、显示等。这种方案在车身can网络结构和报文相对固定、需求明确不频繁改动的情况下并没有问题。

但是，随着车联网技术的发展，以及v2x、大数据、自动驾驶等新兴应用场景的出现，车身can网络集成的控制器越来越多，can报文也越来越复杂和多变，同时对于can数据的利用方式可能灵活多变。此种方案只能根据确定好的配置采集固定的部分can数据，无法快速响应新的需求变化。

技术实现要素：

有鉴于此，本申请的目的在于提供一种can数据采集方法及装置，以解决现有的can数据采集方法只能根据确定好的配置采集固定的部分can数据，无法快速响应新的需求变化的技术问题，其公开的具体技术方案如下：

一方面，本申请提供了一种can数据采集方法，应用于车载设备，所述方法包括：

接收任一can通道传输的can数据并存储至为该can通道分配的内存块中；

依据所述内存块内存储的can数据生成对应的压缩任务；

将所述压缩任务存入压缩任务队列，并依据所述压缩任务队列中的压缩任务，从相应的内存块中读取相应的can数据并压缩得到压缩后can数据；

按照预设上传策略，将所述压缩后can数据发送至云端服务器，以使所述云端服务器解压所述车载设备发送的压缩后can数据并存储。

可选地，所述接收任一can通道传输的can数据并存储至为该can通道分配的内存块中，包括：

当从can通道接收到can数据后，判断为该can通道分配的内存块的内存空间是否充足；

如果内存块的内存空间充足，则将接收到的can数据存储至为所述can通道分配的内存块中；

如果内存块的内存空间不足，则将为所述can通道分配的内存块标记为不可用，生成与该内存块对应的压缩任务，并重新为所述can通道分配新的内存块，将所述can数据存储至新的内存块中。

可选地，所述依据所述内存块内存储的can数据生成对应的压缩任务，包括：

当监测到车辆熄火信号后，将当前传输can数据的can通道所对应的内存块标记为不可用，并生成压缩任务；

当内存块轮转定时器触发后，将内存块内存储的第一条数据的时间戳与当前时间戳进行比较，若时间差达到所述内存块轮转定时器的设定时间，则将该内存块标记为不可用，并根据该内存块内存储的can数据生成压缩任务。

可选地，所述将所述压缩任务存入压缩任务队列，包括：

判断所述压缩任务队列是否已满；

如果所述压缩任务队列未满，则直接将生成的压缩任务存入所述压缩任务队列中；

如果所述压缩任务队列已满，则删除所述压缩任务队列中最早的压缩任务后，将生成的压缩任务存入压缩任务队列中。

可选地，依据所述压缩任务队列中的压缩任务，从相应的内存块中读取相应的can数据并压缩得到压缩后can数据，包括：

当压缩任务定时器计时达到第一设定时长时，判断压缩任务队列是否为空，其中，所述压缩任务定时器在执行完一个压缩任务且所述压缩任务队列不为空时或向所述压缩任务队列中加入新的压缩任务且无正在执行的压缩任务时开始计时；

如果所述压缩任务队列不为空，则从所述压缩任务队列中读取压缩任务；

依据读取的压缩任务确定内存块的定位信息，依据所述定位信息从内存块中读取待压缩的can数据；

对所述待压缩的can数据进行压缩，得到压缩后can数据。

可选地，按照预设上传策略，将所述压缩后can数据发送至云端服务器，包括：

依据所述压缩后can数据生成上传任务，判断上传任务队列是否已满；

如果所述上传任务队列未满，则将所述上传任务加入所述上传任务队列；

如果所述上传任务队列已满，则将所述上传任务队列中最早的上传任务对应的压缩后can数据写入磁盘文件中，并将所述上传任务加入所述上传任务队列中；

当上传任务定时器计时达到第二设定时长时，判断所述上传任务队列是否为空，其中，所述上传任务定时器在执行完一个上传任务且所述上传任务队列不为空时或者向所述上传任务队列加入新的上传任务且无正在执行的上传任务时开始计时；

如果所述上传队列不为空，则从所述上传任务队列中读取上传任务，并依据读取的上传任务从内存块中读取压缩后can数据，并将压缩后can数据发送至云端服务器。

可选地，在将所述上传任务队列中最早的上传任务对应的压缩后can数据写入磁盘文件中之后，所述方法还包括：

当缓存文件监视定时器触发时，判断磁盘是否为空且所述上传任务队列内的任务数量小于预设比例阈值；

如果所述磁盘不为空且所述上传任务队列内的任务数量小于预设比例阈值，则从所述磁盘中读取缓存文件；

依据读取的缓存文件生成上传任务并加入所述上传任务队列，并启动所述缓存文件监视定时器。

可选地，在将所述压缩后can数据发送至云端服务器的过程中，所述方法还包括：

当检测到车辆熄火信号后，停止正在执行的上传任务，并将所述上传任务队列中的全部上传任务对应的压缩后can数据写入磁盘文件中。

第二方面，本申请还提供了一种can数据采集方法，应用于云端服务器中，所述方法包括：

接收压缩后can数据，所述压缩后can数据由车载设备利用第一方面任一项所述的can数据采集方法获得，且所述压缩后can数据中包括车辆中任一can通道采集的数据；

将接收到的压缩后can数据解压后存入数据库中，以使应用程序插件从所述数据库中提取该应用程序所需的can数据并处理。

第三方面，本申请还提供了一种can数据采集装置，应用于车载设备中，所述装置包括：

数据接收模块，用于接收任一can通道传输的can数据，存储至为该can通道分配的内存块中，并依据所述内存块内存储的can数据生成对应的压缩任务；

数据压缩模块，用于将所述压缩任务存入压缩任务队列，并依据所述压缩任务队列中的压缩任务，从相应的内存块中读取相应的can数据并压缩得到压缩后can数据；

数据上传模块，用于按照预设上传策略，将所述压缩后can数据发送至云端服务器，以使所述云端服务器解压所述车载设备发送的压缩后can数据并存储。

第四方面，本申请还提供了一种can数据采集装置，应用于云端服务器中，所述装置包括：

数据接收模块，用于接收压缩后can数据，所述压缩后can数据由车载设备利用第一方面任一项所述的can数据采集方法获得，且所述压缩后can数据中包括车辆中任一can通道采集的数据；

数据应用模块，用于将接收到的压缩后can数据解压后存入数据库中，以使应用程序插件从所述数据库中提取该应用程序所需的can数据并处理。

本申请提供的can数据采集方法，车载设备为每一can通道分配一内存块，将接收到的can数据存入对应的内存块中。然后，针对内存块中存储的can数据生成对应的压缩任务并存入压缩任务队列。执行压缩任务队列中的压缩任务，从内存块中读取can数据并压缩得到压缩后can数据。最后，按照预设上传策略将压缩后can数据上传至云端服务器，由云端服务器对can数据进行统一加工、处理及应用。由上述过程可知，该方案由车载设备采集车辆上所有can通道的can数据，并将can数据进行压缩后上传至云端服务器。车载设备不对can数据进行过滤、筛选、解析、处理等，云端服务器负责can数据的利用包括接收、解析、入库和利用。这样，云端服务器能够获得车辆的全量can数据，当面临需求变更时，能够快速从接收到的全量can数据中获得新的应用需求所需的can数据，即快速响应新的场景需求变化。此外，车载设备对can数据进行压缩后再上传，减少上传can数据所需的带宽和流量。

附图说明

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

图1是本申请实施例提供的一种车联网系统的结构示意图；

图2是本申请实施例提供的一种can数据采集方法的流程图；

图3是本申请实施例提供的一种车载设备接收can数据过程的流程图；

图4是本申请实施例提供的一种车载设备将压缩任务存入压缩任务队列的过程的流程图；

图5是本申请实施例提供的一种车载设备执行压缩任务的过程的流程图；

图6是本申请实施例提供的一种车载设备上传数据过程的流程图；

图7是本申请实施例提供的一种车载设备从磁盘文件中读取数据并加入上传任务队列过程的流程图；

图8是本申请实施例提供的一种can数据采集装置的结构示意图；

图9是本申请实施例提供的另一种can数据采集装置的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

请参见图1，示出了本申请实施例提供的一种车联网系统的结构示意图，该系统主要包括车载设备1和云端服务器2。

车载设备1和云端服务器2之间以网络互联，例如，移动通信网络，如，4g网络、5g网络等。

车载设备1用于采集车辆内全部can总线上的数据，即can数据，并对can数据进行压缩后上传至云端服务器2。即can数据经过数据接收、数据压缩和数据上传三个步骤的处理。而且，车载设备不对can数据做任何过滤、筛选，也不对can数据内容做解析或处理。

需要说明的是，数据接收、数据压缩和数据上传的执行顺序没有先后关系，仅表示数据的流动方向，实际运行时，这三个步骤分别由三个线程同时异步运行。

其中，车载设备是指能够接入车身can总线，且硬件满足要求(如处理器性能、内存、磁盘、网络等)的设备，例如，车载通信模块(telematicsbox，t-box)等。

云端服务器2用于利用车载设备1传输的can数据，进行包括数据的接收、解析、入库及具体应用场景下业务逻辑的实现。

下面将结合图2详细介绍应用于上述车联网系统的can数据采集方法，如图2所示，can数据采集方法主要包括以下步骤：

s110，车载设备接收任一can通道传输的can数据并存储至为该can通道分配的内存块中。

车载设备在初始化时申请一系列连续的固定大小的内存块，组成内存池，用于缓存接收到的can数据，其中，为每个can通道分配一个内存块，以实现不同can通道传输的can数据存入不同的内存块中。

当接收到任一can通道传输的数据后，将该数据存入为该can通道分配的内存块中，并为该数据添加时间戳。待内存块满足一定条件时，对内存块中的数据执行下一步操作，即对接收到的can数据进行集中处理而不是逐条处理，从而提高效率。

s120，车载设备根据内存块内存储的can数据生成对应的压缩任务。

在本申请的一种应用场景中，当内存块存满数据时，生成对应的压缩任务。压缩任务中包括存储待压缩的can数据的内存块的定位信息，其中，内存块的定位信息可以包括该内存块的首地址及内存块的大小。

在本申请的一个实施例中，设置缓存数据强制上传机制，在此种机制下，即使内存块未存满，也会进行下一环节的处理，该机制包括两种情况分别是：监测到车辆熄火信号(即整车ignoff信号)，以及，内存块轮转定时器触发。

(1)监测到车辆熄火信号(即整车ignoff信号)

因为车辆熄火后，can总线逐渐进入休眠状态，且各个车载控制器和设备逐步进入休眠或下电状态，在较短的时间内可能不再有can数据传输，因此，即使当前内存块未存满也要将当前内存块中的已有数据均上传至云端服务器中。

(2)内存块轮转定时器触发

由于每个can通道的负载不同，有些can通道的can数据可能很少，导致很长时间都写不满一个内存块，进而导致该can通道的数据上传非常不及时，为了避免此种现象发生，设置一个内存块转轮定时器，当该定时器达到定时时间后，即使内存块未写满，也进行下一环节的处理，即生成对应的压缩任务，并将该内存块标记为不可用。

在向每个内存块存入can数据时，该内存块记录存入第一条can数据时的时间戳，内存块轮转定时器周期性启动，将每个内存块所记录的时间戳与当前时间戳进行对比，如果超过内存块轮转定时器所设定的时间，即使该内存块未写满也会进行下一步操作。

需要说明的是，s110和s120可以由车载设备中的数据接收线程完成。

s130，车载设备将压缩任务存入压缩任务队列，并依据从压缩任务队列中读取的压缩任务，从相应的内存块中读取相应的can数据并压缩得到压缩后can数据。

车载设备在初始化时需要创建压缩任务队列，而且，为了保证各个can通道始终有可用的内存块，将压缩任务队列的大小配置为小于内存池中内存块的数量，例如，内存池包括100个内存块，压缩任务队列可以设置为80。需要说明的是，内存池包括的内存块可以被各个can通道共用且循环使用，因此，内存块的数量与can通道的数量没有固定关系，例如，can通道的数量是6个，而内存块的数量是100个。

执行压缩任务时，依据压缩任务中的内存块定位信息确定内存块的地址，依据该地址读取内存块内的can数据，并对该can数据进行压缩得到压缩后can数据。其中，压缩任务队列的读写规则是先入先出，即先写入压缩任务队列中的压缩任务先被取出执行。需要说明的是，数据压缩过程可以由车载设备中的数据压缩线程完成。

s140，车载设备按照预设上传策略，将压缩后can数据发送至云端服务器。

压缩后的can数据可以按照预设上传策略上传至云端服务器，以保证数据不丢失。

为了避免数据丢失，利用磁盘(如emmc、sd卡、ssd等大容量存储介质)容量大、非易失的特点作为内存的二级缓存，当网络链路不稳定、数据上传不成功时，将数据写入磁盘文件中，以避免can数据丢失，同时，保证实时上传优先于磁盘缓存，仅在必要的情况下使用磁盘缓存，以减少磁盘读、写操作，提升效率，并延长磁盘的读写寿命。

数据上传过程可以由车载设备中的数据上传线程完成。

s150，云端服务器解压车载设备发送的压缩后can数据并存储、利用。

云端服务器接收到车载设备发送的压缩后can数据后，对can数据进行统一加工、处理及应用。

云端服务器中需要部署用于数据接收到ftp(filetransferprotocol，文件传输协议)服务器，用于数据存储的数据库，以及其他和具体业务相关的组件。云端服务器对can数据处理和应用的过程如下：

(1)当车载设备上传can数据后，ftp服务器接收数据，并以文件形式存入硬盘。

(2)定期从硬盘取出最近上传的数据，并根据can数据包的包头信息对can数据进行校验，校验失败的数据认为无效予以丢弃，校验通过的数据利用和车载设备对称的解压缩算法进行解压，解析出来的数据存入数据库。

(3)不同的应用程序插件根据自身需求从数据库中提取不同的数据并根据各自不同的需求按照不同的步骤对数据进行加工和处理。

例如，对于大数据分析，首先根据分析的目的确定所需要的数据，如报文id、车辆编号、时间段等信息，然后从数据库中取出需要的数据，并根据相应的算法分析处理数据得出结果。

对于实车场景重建，首先从数据库中取出某一辆车在某一个时间段内的全部报文数据，然后把数据重新组织为can报文回放设备可以使用的文件格式(比如canoe软件可以使用的.asc文件)，在测试环境的can总线上回放重组后的报文文件，并在测试can总线上接入待测的ecu或其他部件，最终实现实车调试的效果。

需要说明的是，根据不同应用场景和需求分别定制化开发相应的应用程序插件。

本实施例提供的can数据采集方法，车载设备为每一can通道分配一内存块，将接收到的can数据存入对应的内存块中。然后，针对内存块中存储的can数据生成对应的压缩任务并存入压缩任务队列。执行压缩任务队列中的压缩任务，从内存块中读取can数据并压缩得到压缩后can数据。最后，按照预设上传策略将压缩后can数据上传至云端服务器，由云端服务器对can数据进行统一加工、处理及应用。由上述过程可知，该方案由车载设备采集车辆上所有can通道的can数据，并将can数据进行压缩后上传至云端服务器。车载设备不对can数据进行过滤、筛选、解析、处理等，云端服务器负责can数据的利用，包括接收、解析、入库和利用。这样，云端服务器能够获得车辆的全量can数据，当面临需求变更时，能够快速从接收到的全量can数据中获得新的应用需求所需的can数据，即快速响应新的场景需求变化。此外，车载设备对can数据进行压缩后再上传，减少上传can数据所需的带宽和流量。

在本申请的一个实施例中，如图3所示，接收can通道传输的can数据并存入对应的内存块的过程如下：

s111，当车载设备从can通道接收到can数据后，判断为该can通道分配的内存块的内存空间是否充足；如果否，则执行s112；如果是，则执行s113。

s112，将为该can通道分配的内存块标记为不可用，并重新为该can通道分配新的内存块，并将can数据存储至新的内存块中。

如果当前内存块已经没有足够空间，则把当前内存块标记为不可用，生成相应的压缩任务以便尽快对该内存块内的数据进行压缩。然后，从内存池取出一个新的内存块分配给当前can通道，将该can通道传输的can数据缓存进新分配的内存块，并添加时间戳。

在本申请的一个实施例中，数据接收、数据压缩分别由不同的线程执行。当数据压缩线程执行完相应的数据压缩任务后，向数据接收线程发送数据压缩完毕的通知，以使数据接收线程释放该内存块空间，即将该内存块重新标记为可用并加入内存池中。

s113，将接收到的can数据存储至为can通道分配的内存块中。

如果当前can通道对应的内存块有足够的空间存储新的can数据，则直接将新的can数据存入该内存块中，并添加时间戳。

本实施例提供的接收can数据的过程，为不同的can通道分配不同的内存块，当接收到该can通道传输的can数据后，先判断为该can通道分配的内存块是否有足够的空间，若有则直接存储该can数据，若没有则触发下一环节的处理，从而实现对接收到的can数据集中处理而不是逐条处理，从而提高数据上传效率。

在本申请的另一个实施例中，如图4所示，将压缩任务存入压缩任务队列的过程如下：

s131，判断压缩任务队列是否已满；如果是，则执行s132；如果否，则执行s133。

数据压缩线程接收到数据接收线程发送的数据压缩任务后，先判断压缩任务队列中已经存满，如果压缩任务队列已满则无法写入新的压缩任务，如果未满则可以继续存入新的压缩任务。

s132，删除压缩任务队列中最早的压缩任务。

如果压缩任务队列已满，则将该队列中最早的一个压缩任务取出(即从压缩任务队列中删除最早的压缩任务)，并回收存储该压缩任务对应的can数据的内存空间，即将该内存块重新标记为可用，并加入内存池中。之后执行s133。

其中，队列中最早的压缩任务是指队列中目前存储的，且入队列时间最早的压缩任务。

s133，将压缩任务存入压缩任务队列中。

如果压缩任务队列已满，删除最早的压缩任务后，之后可以将新的压缩任务加入压缩任务队列中。

如果压缩任务队列未满，则直接将新的压缩任务存入压缩任务队列中。

s134，当确定当前未执行压缩任务时启动压缩任务定时器。

在将新的压缩任务存入压缩任务队列后，如果当前未执行压缩任务，则启动压缩任务定时器，即压缩任务定时器开始计时。

设置压缩任务定时器的目的是触发数据压缩线程执行数据压缩操作。利用压缩任务定时器能够达到两个效果，一是能够达到异步执行的效果；另一个是在压缩任务队列不为空但是没有接收到新的压缩任务的情况下，能够通过压缩任务定时器循环执行压缩操作。

本实施例提供的压缩任务存储压缩任务队列的过程，利用压缩任务队列实现can数据接收和数据压缩异步执行，而不是接收到一条can数据后立即执行压缩操作，提高数据上传效率。而且，能够保证先接收的数据先被压缩上传，保证数据上传的实时性。

在本申请的一个实施例中，如图5所示，执行压缩任务的过程如下：

s135，当压缩任务定时器触发时，判断压缩任务队列是否为空；如果否，则执行s136；如果是，则结束当前流程。

当压缩任务定时器的计时时长达到第一设定时间后触发该压缩任务定时器。

在本申请的一个实施例中，如前所述，向压缩任务队列中加入新的压缩任务后，且当前未执行压缩任务时，启动压缩任务定时器。

s136，依据从压缩任务队列中读取的压缩任务确定内存块的定位信息，并依据定位信息从内存块中读取待压缩的can数据。

前已叙及，压缩任务中包含存储待压缩数据的内存块的地址，依据该地址从对应的内存块中读取待压缩的can数据。

s137，对待压缩的can数据进行压缩，得到压缩后can数据。

s138，通知数据上传线程上传数据，并通知数据接收线程回收相应的内存空间。

压缩后的can数据存入申请的新的内存块中，通知数据接收线程对该压缩后can数据所对应的原始can数据的内存空间进行回收。以及，通知数据上传线程上传该压缩后can数据，即生成上传任务。

s139，当确定压缩任务队列不为空时，再次启动压缩任务定时器。

即压缩任务定时器的启动条件包括两种情况：一种是将新的压缩任务加入压缩任务队列且当前无正在执行的压缩任务时启动；另一种是数据压缩线程执行完一个压缩任务后且压缩任务队列不为空时启动。

本实施例提供的数据压缩过程，当压缩任务定时器触发后从压缩任务队列中读取一个压缩任务并执行，利用压缩任务定时器能够使压缩任务的接收和执行实现异步执行，从而实现先接收到的压缩任务先执行，保证数据上传的实时性，同时，还能提高数据上传效率。

在本申请的一个实施例中，数据上传线程主要负责数据的上传，车载设备在初始化时需要创建上传任务队列、缓存文件列表，并启动缓存文件监视定时器。如图6所示，数据上传过程如下：

s141，依据压缩后can数据生成上传任务，判断上传任务队列是否已满；如果否，则执行s144；如果是，则执行s142；

当数据压缩线程将can数据进行压缩后，生成相应的上传任务并发送给数据上传线程，以便压缩后的数据能够及时上传。其中，上传任务中包含存储该待上传的数据的内存块的定位信息，如首地址和内存块的大小。

当数据上传线程接收到数据压缩任务发送的上传任务后，需要将该上传任务加入上传任务队列，在加入队列之前，先判断上传任务队列是否已满，如果队列未满则可以直接将新接收的上传任务加入队列中。

s142，将上传任务队列中最早的上传任务对应的压缩后can数据写入磁盘文件中，并向缓存文件列表中添加此磁盘文件。

如果队列已满则无法直接将新接收到的上传任务加入队列中，此种情况下，读取上传任务队列中最早的上传任务，并依据该最早的上传任务从内存块中读取待上传的压缩后can数据，并将该压缩后can数据写入磁盘文件中，并向缓存文件列表中添加该缓存文件。

将上传任务队列中最早的任务对应的待上传数据缓存至磁盘文件中，能够避免数据丢失。同时，保证新的上传任务及时加入上传任务队列中并上传，保证数据及时上传。

s143，确定写入磁盘文件中的上传任务的来源，并针对确定出的来源对相应的内存进行回收。

针对压缩后can数据的不同来源采用不同的方式进行内存回收。具体的，如果压缩后can数据来自数据压缩线程，则对数据压缩线程用于存储该压缩后can数据的内存块进行回收，即重新标记为可用；如果压缩后can数据读取自磁盘文件，则由数据上传线程回收从磁盘文件中读取压缩后can数据所存入的内存块。执行完s143后再执行s144。

s144，将上传任务加入上传任务队列。

s145，判断是否正在执行上传任务，如果否，则执行s146；如果是，则结束当前流程，直到上传任务执行完后再执行s146。

s146，启动上传任务定时器。

启动上传任务定时器后，上传任务定时器开始计时。

上传任务定时器的作用是在固定的时间段(即第二设定时长)之后，从上传任务队列中取出压缩后can数据进行上传，从而使上传任务的生成与执行实现异步执行，提高数据上传效率。

在本实施例中，向上传任务队列加入新的上传任务且上传任务队列不为空时，启动上传任务定时器。

在本申请的另一个实施例中，在执行完一个上传任务且上传任务队列不为空时启动上传任务定时器以便触发上传操作循环执行。

s147，当上传任务定时器触发时，判断上传任务队列是否为空；如果否，则执行s148；如果是，则结束当前流程，当上传任务定时器下一次触发时，再判断上传任务队列是否为空。

当上传任务定时器的计时时长达到第二设定时长后上传任务定时器触发，然后判断上传任务队列是否为空。

上传任务队列为空表示队列中没有未执行的上传任务；如果上传任务队列不为空表示队列中有未执行的上传任务。

s148，依据上传任务队列中的上传任务从内存块中读取压缩后can数据，并将压缩后can数据发送至云端服务器。

如果上传任务队列不为空，则从上传任务队列中读取一个上传任务，并将执行该上传任务。

在一种应用场景中，当检测到车辆熄火信号(即，ignoff信号)后，为了避免车辆熄火后丢失数据，停止正在执行的上传任务，并将上传任务队列中的所有上传任务对应的压缩后can数据写入磁盘文件中，并将对应的磁盘文件加入缓存文件列表，同时根据上传任务的数据来源回收对应的内存资源。

本实施例提供的上传任务执行过程，通过上传任务定时器触发上传任务循环执行，实现上传任务的生成和任务执行异步执行，而不是逐条数据依次进行各个步骤的操作从而提高数据上传效率。而且，使用磁盘作为内存的二级缓存，可以在网络链路不稳定、数据上传不成功时的缓冲避免丢失数据。同时，保证实时上传优先于磁盘缓存，仅在必要的情况下使用磁盘缓存，以减少磁盘读、写操作，提升效率，并延长磁盘的读写寿命。

在另一个实施例中，在上传任务队列较空(即，上传任务队列不为空且队列内的任务数量占任务队列能容纳的任务总数之比小于预设比例阈值)时，将写入磁盘文件的压缩后can数据对应的上传任务再次加入上传任务队列中，以便将该数据上传至云端服务器，该过程由缓存文件监视定时器循环触发执行。如图7所示，该过程包括以下步骤：

s1410，当缓存文件监视定时器触发时，判断磁盘是否不为空且上传任务队列内的任务数量小于预设比例阈值；如果是，则执行s1420。如果否，则结束本次流程。

其中，预设比例阈值可以根据实际需求及上传任务队列的大小确定，例如，10％，当然在其它实施例中预设比例阈值还可以选取其它数值。

s1420，从磁盘中读取缓存文件，依据该缓存文件生成上传任务加入上传任务队列，并启动缓存文件监视定时器。

其中，上传任务加入队列的过程与上述的s141～s146的过程相同，此处不再赘述，并从缓存文件列表中删除对应的缓存文件。

由上述内容可知该机制能够保证写入磁盘文件中的数据也能上传至云端服务器，通过缓存文件监视定时器循环触发磁盘文件数据上传，同时，为了保证实时生成的压缩数据优先于磁盘文件中的数据，当上传任务队列中的上传任务较少时，才将磁盘文件中的数据对应的上传任务加入上传任务队列中。

相应于上述的can数据采集方法实施例，本申请还提供了can数据采集装置实施例。

如图8所示，本申请实施例提供的一种can数据采集装置包括：

数据接收模块110，用于接收任一can通道传输的can数据，存储至为该can通道分配的内存块中，并依据内存块内存储的can数据生成对应的压缩任务。

在本申请的一个实施例中，数据接收模块110用于接收任一can通道传输的can数据，存储至为该can通道分配的内存块中，并依据内存块内存储的can数据生成对应的压缩任务时，具体用于：

当从can通道接收到can数据后，判断为该can通道分配的内存块的内存空间是否充足；

如果内存块的内存空间充足，则将接收到的can数据存储至为can通道分配的内存块中；

如果内存块的内存空间不足，则将为can通道分配的内存块标记为不可用，生成与该内存块对应的压缩任务，并重新为can通道分配新的内存块，将can数据存储至新的内存块中。

当监测到车辆熄火信号后，将当前传输can数据的can通道所对应的内存块标记为不可用，并生成压缩任务；

当内存块轮转定时器触发后，将内存块内存储的第一条数据的时间戳与当前时间戳进行比较，若时间差达到内存块轮转定时器的设定时间，则将该内存块标记为不可用，并根据该内存块内存储的can数据生成压缩任务。

数据压缩模块120，用于将压缩任务存入压缩任务队列，并依据压缩任务队列中的压缩任务，从相应的内存块中读取相应的can数据并压缩得到压缩后can数据。

在本申请的一个实施例中，数据压缩模块120用于将压缩任务存入压缩任务队列时，具体用于：

判断压缩任务队列是否已满；

如果压缩任务队列未满，则直接将生成的压缩任务存入压缩任务队列中；

如果压缩任务队列已满，则删除压缩任务队列中最早的压缩任务后，将生成的压缩任务存入压缩任务队列中。

在本申请的一个实施例中，数据压缩模块120用于依据压缩任务队列中的压缩任务，从相应的内存块中读取相应的can数据并压缩得到压缩后can数据时，具体用于：

当压缩任务定时器触发时，判断压缩任务队列是否为空，压缩任务定时器在执行完一个压缩任务且压缩任务队列不为空时或向压缩任务队列中加入新的压缩任务且当前无正在执行的压缩任务时启动；

如果压缩任务队列不为空，则从压缩任务队列中读取压缩任务；

依据读取的压缩任务确定内存块的定位信息，依据定位信息从内存块中读取待压缩的can数据；

对待压缩的can数据进行压缩，得到压缩后can数据。

数据上传模块130，用于按照预设上传策略，将压缩后can数据发送至云端服务器，以使云端服务器解压车载设备发送的压缩后can数据并存储。

在本申请的一个实施例中，数据上传模块130具体用于：

依据压缩后can数据生成上传任务，判断上传任务队列是否已满；

如果上传任务队列未满，则将上传任务加入上传任务队列；

如果上传任务队列已满，则将上传任务队列中最早的上传任务对应的压缩后can数据写入磁盘文件中，并将待加入的上传任务加入上传任务队列中；

当上传任务定时器触发时，判断上传任务队列是否为空，上传任务定时器在执行完一个上传任务且上传任务队列不为空时或者向上传任务队列加入新的上传任务且当前无正在执行的上传任务时启动；

如果不为空，则从上传任务队列中读取上传任务，并依据读取的上传任务从内存块中读取压缩后can数据，并将压缩后can数据发送至云端服务器。

在本申请的另一个实施例中，将上传任务队列中最早的上传任务对应的压缩后can数据写入磁盘文件中之后，数据上传模块130还用于：

当缓存文件监视定时器触发时，判断磁盘是否为空且上传任务队列内的任务数量小于预设比例阈值；

如果磁盘不为空且上传任务队列内的任务数量小于预设比例阈值，则从磁盘中读取缓存文件；

依据读取的缓存文件生成上传任务并加入上传任务队列，并启动缓存文件监视定时器。

在本申请的又一个实施例中，数据上传模块130还用于：当检测到车辆熄火信号后，停止正在执行的上传任务，并将上传任务队列中的全部上传任务对应的压缩后can数据写入磁盘文件中。

另一方面，本申请实施例还提供了一种应用于云端服务器的can数据采集装置，如图9所示，该装置包括：

数据接收模块210，用于接收压缩后can数据，压缩后can数据由车载设备利用上述的车载设备侧的can数据采集方法获得，且压缩后can数据中包括车辆中任一can通道采集的数据。

数据应用模块220，用于将接收到的压缩后can数据解压后存入数据库中，以使应用程序插件从数据库中提取该应用程序所需的can数据并处理。

本申请提供的can数据采集装置，由车载设备采集车辆上所有can通道的can数据，并将can数据进行压缩后上传至云端服务器。车载设备不对can数据进行过滤、筛选、解析、处理等，云端服务器负责can数据的利用包括接收、解析、入库和利用。这样，云端服务器能够获得车辆的全量can数据，当面临需求变更时，能够快速从接收到的全量can数据中获得新的应用需求所需的can数据，即快速响应新的场景需求变化。此外，车载设备对can数据进行压缩后再上传，减少上传can数据所需的带宽和流量。

本申请提供了一种车载设备，该计算设备包括处理器和存储器，该存储器内存储有可在处理器上运行的程序。该处理器运行存储器内存储的该程序时实现上述的车载设备所执行的任一种can数据采集方法。

本申请实施例提供了一种服务器，设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，处理器执行程序时实现上述的云端服务器所执行的任一种can数据采集方法。

上述的处理器中包含内核，由内核取存储器中调取相应的程序，内核可以设置一个或以上。

对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本申请各实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。

本申请各实施例中的装置及终端中的模块和子模块可以根据实际需要进行合并、划分和删减。

本申请所提供的几个实施例中，应该理解到，所揭露的终端，装置和方法，可以通过其它的方式实现。例如，以上所描述的终端实施例仅仅是示意性的，例如，模块或子模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个子模块或模块可以结合或者可以集成到另一个模块，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的模块或子模块可以是或者也可以不是物理上分开的，作为模块或子模块的部件可以是或者也可以不是物理模块或子模块，即可以位于一个地方，或者也可以分布到多个网络模块或子模块上。可以根据实际的需要选择其中的部分或者全部模块或子模块来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能模块或子模块可以集成在一个处理模块中，也可以是各个模块或子模块单独物理存在，也可以两个或两个以上模块或子模块集成在一个模块中。上述集成的模块或子模块既可以采用硬件的形式实现，也可以采用软件功能模块或子模块的形式实现。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。