车辆行驶日志是按时间顺序排列的二进制数据帧，每帧开头的时间戳是该帧数据产生的时间标识^[14]。车辆上电后，黑匣子会不间断地通过CAN总线接收各ECU返回的车辆运行数据。车载SVDC总成是车身中用于中转处理数据的专用域控制器，如图1所示，其中包含WiFi模块、4G模组、存储模块等。数据经MCU处理之后，以log文件形式存储到4G通讯模组的外置EMMC存储器。单个log文件最大设为5 MB，以其结尾帧的时间命名，最多可包含超过140000帧数据，详细记录了每一时刻各域控制器采集的车辆运行状态信息。EMMC最大容量为200 M，当数据量将要超过最大容量时，新文件会循环覆盖最早的文件，以保证黑匣子存储10～12小时内的最新数据。如果SVDC总成在当前文件未写满的情况下掉电或停止运行，则强行保存该文件，恢复后创建新的log文件记录数据。因此车辆在实际驾驶过程中产生的log文件大小不定，且数量较多，呈碎片化。目前FTP工具支持多文件传输，但分析多款软件后发现当前断点续传功能不支持碎片化的多任务环境。

图  1  黑匣子结构及日志导出示意图

如图1所示，导出日志时，WiFi模块建立无线局域网环境，4G模组创建FTP服务器，与FTP客户端建立连接并进行数据交互。实际应用中，用户需提前输入某一时间范围，满足该范围的数据帧称作有效帧。将含有效帧的log文件导出到本地后，需进一步检索，以精确分析设定时间段数据。有效帧按照固定协议转换成ASC格式，利用专用的行车数据分析软件CANalyser将用户感兴趣的车辆状态信息进行回放。

车辆行驶过程中会产生加速、转向、制动等操作信息以及多种传感器采集的不同数据，这些数据以CAN协议报文格式发送至SVDC总成，经MCU处理后以固定协议存储。与CAN数据结构有所不同，数据帧存储结构如图2所示。日志数据帧主要字段包括UTC时间戳、数据来源、数据长度(DLC)和状态数据^[15]。其中，UTC时间是该帧数据在ECU中产生的时间，最高可精确到微秒级，CAN通道和ID号反映该帧数据的来源，其中ID号还用于CAN消息的仲裁，该字段值越低表示优先级越高。通信中存在CAN和CANFD两种信道，Device Type分别使用0或1填充以作区分。DLC字段记录状态数据Data的字节数，最大为64。以上数据均为不透明二进制，工程人员在解析字段时需依据固定协议解码。从图2中可以看到，时间戳占据数据帧前6字节，从CAN Channel到DLC共7个字节存储数据来源等信息，Data记录这一时刻ECU的状态信息。为节省存储空间，帧之间没有分隔标志。不同ECU状态数据长度不同，采样时间间隔也不同，所以log文件中帧长度不定。在黑匣子存储的海量数据中查找有效帧，必须依据时间戳进行判断。

图  2  车辆运行日志数据帧

FTP文件传输异常中断时，断点续传可以将文件指针直接定位到中断位置，避免数据重复传输。现有的多任务管理方式多采用树形结构，任务中断后再次重启需要重新生成目录树，这种方式效率不高。传输任务过程中，利用不同文件名代表不同任务，文件夹上下层切换操作相对独立，即对目录树的每次操作只能用到一小部分，利用这一特性，可对导出前获取传输任务的步骤作出改进，将生成树目录的步骤分解为每次进入文件夹后独立生成临时子项列表。在这种管理方式下，系统完成列表所有子项操作后将该列表销毁，降低同级文件夹之间的耦合性。

用户设定日志导出条件后由系统直接进行任务解析，选择需要导出的log文件，如图3所示。图中1～5为用户创建新导出任务的过程，2a、3b为断点续传任务流程路线。可以看到，新系统在遍历文件树过程中，进入下层非叶子结点时创建临时字符串列表，该列表在退出当前文件夹后自动销毁。根据服务器端获取的文件信息特点^[16]，系统利用换行符统计文件数目，将文件、文件夹名截取出来存储至该列表。依靠这些信息实现文件树上下层切换以及文件绝对路径的拼接。文件绝对路径分为3个部分：1)用户在界面显示的列表中手动双击进入的文件夹名称；2)遍历目录树过程系统自动进入的非叶子子目录；3)树叶子结点存储的文件名称。这种方式与传统方式相比，实现了各级文件路径与名称的分离。导出任务进行时，各级文件信息都是从服务器端临时获取，信息独立为多任务断点续传提供了条件。文件分多包传输，除最后一包，其余包均为固定大小。每包传输过程分为获取缓冲区数据和写入本地文件两个步骤，每一步都有相应反馈。若反馈传输出错，则自动重传当前文件。传输完成后根据文件字节数对比判断传输是否成功。

图  3  日志文件传输时序

任务断点续传是根据上述文件名称存储特点，在任务管理阶段创建临时文件，利用任务路径记录导出进度。每完成一条任务删除相应记录，保证下次传输可以精确定位到尚未完成的任务。

前面将包含有效数据的多个log文件导出到本地之后，其中的无效数据数量仍然庞大，需进一步处理。如图4所示，先将导出到本地的log文件按时间顺序合并成一个文件，该文件中的数据仍按时间顺序存储。因此，有效数据必然连续存放，无效数据只存在于文件头和尾。找到首个有效数据帧后，逐帧进行格式转换，直到再次查找到无效帧后停止转换。因此本文的重点就是研究如何快速找到第一帧有效数据，跳过文件开头的无效数据。

图  4  有效日志数据导出、提取过程

日志数据是按时间戳单向递增的离散型序列，如图5a所示。若想快速查找有效数据首帧并计算其帧数，应将问题转换成线性搜索问题求解。线性搜索问题是给定条件为指定闭区间和已知函数体，求单谷函数最优点；而当前问题是已知最优点函数值和函数整体趋势，求解目标帧在海量数据中的精确位置。将时间值T作为因变量，在日志中的帧数n作自变量，建立数学模型：

车载ECU日志的每一帧数据由各个域控制器定时产生，车辆运行时，每秒采集的总帧数波动不大，时间戳可近似看作线性增长。设最优点时间为T_b，计算当前帧时间与最优点时间差的绝对值，可以直观看出当前时间与最优点的“距离”，从图5b可以看出，此时区间内已明显存在“最优点”。

从几何意义上来看，解决该问题实际上是搜索函数在有限区间的最小点。由于时间−帧数函数无法求导，所以本文通过改进hooke-jeeves搜索法，使其更适用于不定长单调离散数据搜索。

hooke-jeeves算法是一种非线性函数优化方法，利用迭代计算逐渐逼近目标函数最优解^[17]。该算法的基本思路为：查找过程分为探测和爬行两种操作，其中探测操作寻找函数下降方向，确定下一个数据点，如果新的数据点比原基点更优，则进行爬行操作，继续寻找下一点，若新点劣于原基点，则退回到基点重新探测，具体分为以下5个步骤。

图  5  时间戳−帧数大致分布

1) 取一个点作探测基点$ {x_1} $，n个方向分别设为$ {e_i}(i = 1,2, \cdots ,n) $，设定初始步长为$ \delta $，步长缩减率为$ \beta \in (0,1) $，步长增加率$ \tau > 1 $，加速因子$ \alpha \geqslant 1 $，精度要求为$ \varepsilon $，置$ {t_1} = {x_1} $，循环步数$ k = 1 $，$ i = 1 $。

2) 若探测到更优点$ f({t_i} + \delta {e_i}) < f({t_i}) $，则置$ {t_{i + 1}} = {t_i} + \delta {e_i} $。

3) 若最终$ i < n $，则置$ i = i + 1 $，转步骤2)，若以上情况都没有实现函数值下降，则$ {t_{i + 1}} = {t_i} $，转步骤5)。

4) 若$ f({t_{n + 1}}) < f({x_k}) $，即探测结果优于此次探测出发点，则进行爬行操作，置$ {x_{k + 1}} = {t_{n + 1}} $。令$ {t_i} = {x_{k + 1}} + \alpha ({x_{k + 1}} - {x_k}) $，置$ k = k + 1 $，$ i = 1 $，转步骤2)。

5) 若$ \delta < \varepsilon $，则停止迭代，得到点$ {x_k} $(满足精度要求的“最优点”)，否则置$ \delta = \beta \delta $，$ {t_1} = {x_k} $，$ {x_{k + 1}} = {x_k} $，转步骤2)。

搜索过程中步长根据相应参数进行调整，且计算结果好坏与初值选择相关。但是在有效数据搜索过程中，初值固定且在数据量很大的情况下步长不易确定。本文以hooke-jeeves算法为基础，提出更适用于日志数据查找的变步长提取方法。

搜索准备阶段，首先计算首帧与目标帧时间差。若差值大于100 s，则将时间戳相同的数据帧分为一组，可大致看作与图5b类似的线性问题，利用该特性快速逼近目标值；否则，直接进入搜索阶段。从图2可以看到，从时间戳到行驶数据长度之间共14字节。根据该特点，直接计算无需逐帧转换的数据字节数，据此改变文件内部指针指向，避免每帧时间戳的提取转换及比对。而Data字段长度由DLC指定，所以搜索过程中每帧DLC部分仍需计算。一个5 MB的log文件大约有14万帧，跳过大部分无效帧，可以大大减少数据处理时间。根据域控制器定时产生数据的特点，算法首先提取前20帧数据，利用不同ID大致估计域控制器数目为num，对试验车辆进行统计，得出每个域控制器每秒大约反馈50～140帧数据。为保证不越过最优点，数据帧线性部分增长斜率$ h $设置为：

计算目标时间$ {T_t} $与首帧时间$ {T_1} $的秒数差，得到首次跳转距离：

跳转后记录当前帧时间$ {T_i}(i = 1,2, \cdots ) $，若$ ({T_i} - {T_1}) < 10\;{\text{s}} $，则进行下一步搜索，否则重复上述过程，最后记录内部指针所在帧的帧数$ {n_c} $与时间戳时间$ {T_c} $。

搜索阶段，距离目标点不大于100 s时，此时数据帧不再适合分组讨论，线性方式不适用该区间的目标搜索，此时问题变换为类似图5c曲线的单谷函数最优点搜索问题。利用hooke-jeeves算法进一步逼近，该算法需要对不同方向函数值下降速度进行比对以保证最优。但是log文件仅需朝着帧数增加的方向搜索，所以该搜索模式可以进行简化。设定步长为k，步长缩减率$ \beta = 0.5 $，将探测与爬行两步结合，首先计算搜索准备阶段记录的时间$ {T_c} $与目标时间$ {T_t} $的差值：

逼近过程如图6所示，每次跳转之后需计算$ \Delta T $。若$ \Delta T > 2 $，则按照设定步长继续跳转，若$ 1 < \Delta T \leqslant 2 $，则设定步长为$ k = \beta k $，期间若有$ \Delta T < 0 $的情况则提前开始减速。当$ \Delta T \leqslant 1 $时将步长设为1，单帧搜索直到查找到第一帧满足设定条件的数据。

图  6  跳转过程中的几种不同情况

本文选择Visual Studio平台，利用MFC开发工具编写了FTP客户端应用软件，硬件平台为某型新能源汽车SVDC总成。SVDC总成CPU为搭载Linux系统的骁龙700处理器，WiFi模块采用802.11b协议，测试过程中理论最大的传输速度可以达到11 Mbps≈1.375 MB/s。试验车辆在不同驾驶条件下正常运行，黑匣子同时开启3个域控制器实时采集，记录约10 h、200 MB左右的数据集。选取长度不等的几个时间段进行日志导出和数据提取，并利用专业CAN数据回放软件CANalyser、文件比对软件UltraEdit等对数据进行分析。

本文针对不同时刻不同时间段的日志数据，分别对系统的数据导出和有效数据检索功能进行验证，并与现有FTP传输工具FileZilla Cllient 3.55.0、顺序搜索、hooke-jeeves算法的运行速度及准确率进行了对比，利用系统计时工具统计程序运行时间。

导出过程中，通过中断网络、屏蔽信号等方式，验证系统多任务断点续传功能，实验证明导出文件正确，该功能有效。

1)导出速度验证

图7为本导出系统与通用FTP软件FileZilla分别对不同大小的日志数据导出的用时对比。可以看到，本系统在导出用时上稍有劣势，但两者相差不大。导出用时与文件总大小并不严格成线性关系，该现象由多任务切换时间损耗造成。

图  7  本系统与FileZilla软件传输时长对比

为了进一步了解两种方式对导出速度的影响，在无线局域网环境下接入单个客户端，导出全部日志同时进行了实时网速测试。从图8的测试结果看，本方法导出平均吞吐约8.861 9 Mbps，FileZilla导出平均吞吐约8.934 4 Mbps，两种方式宽带利用率均在80%以上，所以综上可知本系统传输方法对速率的影响不明显。

图  8  本系统与FileZilla流量吞吐对比

2)导出准确率验证

影响FTP性能的因素有拥塞窗口大小和网络剩余带宽等^[18]，最大网速受限于硬件不可调整。由于FTP文件分包传输，包过大，传输速率超过硬件写入速度时会导致服务器CPU负载过大，增加丢包率；包过小则会线性增加FTP交互次数，降低传输速率^[19]。为提高传输的正确率，控制信息往返时长，需调整FTP传输时网络数据包的大小。经过反复测试，将包大小设置为5 KB。

准确率验证分两部分，程序中利用文件大小判断传输成功与否，导出到本地之后利用UltraEdit软件逐字节匹配源文件和导出文件。经多次验证，文件导出和断点续传功能稳定可靠，导出成功率大于95%。将断点续传和正常传输得到的文件通过UltraEdit软件进行比对，数据完全一致。

为验证变步长提取方法的效率以及准确率，本文用该方法分别与顺序搜索和直接基于hooke-jeeves算法修改的搜索方法进行比对。选取不同长度以及不同时间段的多组数据，用3种方法分别进行搜索提取，并利用程序计时工具分别统计log文件中找到首条有效帧所用的时间。

选择多次测试中具有代表性的几组数据，如图9所示。图中数值分别表示用户实际搜索过程中，手动输入的时间区间大小(5 min、15 min、30 min)以及提取的多个log文件中首文件的大小(4.1 MB、10 MB和3.75 MB)。可以看到搜索用时与设定时间区间大小以及首文件大小无关，hooke-jeeves和变步长提取方法较原顺序搜索效率明显提高，其中变步长提取检索速度较顺序检索方式提高40%以上。为了进一步分析文件内部指针跳转情况，将hooke-jeeves和变步长提取方法每一次跳转后指针所在帧数进行了统计。

图  9  3种搜索方法查找首条有效帧用时

实验中，车辆运行采集3个域控制器数据，图10中每一小格代表50×3帧数据，末尾深色部分表示有效数据，长线显示了搜索过程中文件内部指针跳转情况。可以看到hooke-jeeves算法初始步长较小，搜索过程中步长调整增大，而变步长提取方式直接大致估算距离，所以初始步长较大。从首帧开始逼近目标的这一阶段，变步长方式与hooke-jeeves相比，速度没有明显优势。但hooke-jeeves算法更加依赖初始步长的设置，相较于变步长方式灵活性较差。

文件指针跳转到距离目标帧小于2 s的位置后，两种算法此刻均为步长缩减阶段。由于步长缩减率均设置为0.5，所以变步长提取方式搜索准备阶段与 hooke-jeeves收敛速度基本一致。区别在于$ \Delta T \leqslant 1 $的阶段，hooke-jeeves继续跳转而变步长方法提前将步长设置为1。图11中每个长条代表两个数据帧，可以看到，由于同一时刻的日志数据通常大于1条，而有效帧的判断方式为时间戳对比，hooke-jeeves最终查找到目标帧之后的数据导致出错。变步长提取方式采用顺序逐帧搜索判断的方式避免越过首帧，保证了搜索的准确性。

实验评估表明，log文件导出系统在保证传输速度和准确率的同时，实现了多任务传输的断点续传功能。变步长有效数据提取方式比原有的顺序检索方式执行时间更短，收敛性能与hooke-jeeves模式搜索方式相当的同时，比后者更加精确。

图  10  hooke-jeeves和变步长提取方法大区间文件指针跳转情况

图  11  hooke-jeeves和变步长提取方法小区间文件指针跳转情况

汽车域控制器运行数据是反映车辆真实运行状态的重要信息，及时导出指定时间的数据，是获知车辆事故原因或车辆缺陷等的关键。本文设计了基于WiFi的多任务导出系统，改进了FTP多任务管理方式，实现了多任务断点续传。通过对行车数据存储特点分析提出变步长追踪算法，利用时间戳信息实现有效数据快速检索定位。最后利用某型汽车SVDC总成进行比对验证，结果表明，新系统能稳定实现多任务断点续传，算法将有效数据检索时间缩短40%以上，证明了该方法的有效性。