智能车载DCU 数据高效传输及变步长提取

张 震，童 斌，付建军，袁 正，余红英，陈 勇

(1. 中北大学电气与控制工程学院 太原 030051；2. 重庆长安新能源汽车科技有限公司 重庆 江北区 401133；3. 电子科技大学自动化工程学院 成都 611731；4. 电子科技大学电动汽车动力系统与安全技术研究所 成都 611731)

智能汽车功能配置复杂，车载电子控制单元(electronic control unit, ECU)数量多，对行车数据处理效率要求高。车辆各域控制器(domain control unit, DCU)管理并采集ECU 数据，通过CAN 总线传输到汽车事件记录仪(黑匣子)，快速准确地提取这些数据是检测与分析车辆行驶状态的关键。车载数据提取包括数据导出及数据处理两部分。数据导出方面，文献[1]利用车辆CAN-BUS 实时数据采集系统挖掘和检测行车信息，建立车辆异常检测系统。文献[2]通过CAN 总线网络实现车辆数据提取。文献[3]利用串口通信将车辆运行数据发送至监测站，实现车辆路线的跟踪。以上方式均能实现车载数据的稳定导出，但有线通信受地点和物理接口限制，传输速度慢、移动性较差。文献[4]提出了一种基于红外通讯的VeLC 系统，实现车载光通信。文献[5]将无线通信引入到车载数据采集系统中，实现无线局域网数据通信。但无线信号不稳定，误操作可能产生传输中断问题，多任务断点续传方法可记录中断处信息，避免数据重复传输。FTP(file transfer protocol)协议是一种专用于远程文件传输的应用层协议[6]。现有的FTP 工具进行多任务传输前会临时创建一个存储文件名称等信息的列表，文件传输数目越大，临时空间就越大。传输工具异常中断后临时空间销毁，再次连接只能续传上次中断处的单个文件，其余任务只能重选重传。为优化任务管理，文献[7]设计了一种新的调度方式，通过预先预约将文件分块，从而实现网络资源的最优化分配，但该方式无法应用于文件数目较多的情况。文献[8]提出一种可扩展的动态哈希方案，用于记录分布不均匀的文件，该方案适用于多文件的加解密，但哈希过程会影响传输效率。文献[9]提到日志归并树结构，并在此基础上对批量搜索做出改进，遍历树的方式切换速度快，但文件结构本身是利用叶子和非叶子结点分别保存文件和文件夹信息的树，算法本身有冗余。文献[10]提出扁平轻量级文件系统，使目录内容和树结构扁平化，提高访问速度。

数据处理方面，导出完成后，需对其中的有效数据进行甄别以便分析。车载域控制器产生的日志信息都是周期性的时间序列数据，在大量日志信息中查找指定时间段的数据帧可看作精确线性搜索问题[11]。常见的线性搜索方法有进退法、二分法、黄金分割法等[12]，多用于函数值可计算的单谷函数。log 文件中数据帧长度不固定，帧之间没有分隔标识，以上检索方式均不适用。共轭梯度法、牛顿切线法[13]等不适用于离散的时间戳序列，而传统顺序检索方式效率太低。为提高智能车载域控制器的数据传输效率及有效数据的搜索速度，本文基于FTP 传输方式设计新的导出任务管理方法，优化传统断点续传方法，使之能应用于多文件及文件夹的任务传输。在有效数据的搜索方面，通过分析车载日志数据帧特点，提出变步长搜索方式，实现时间序列数据快速精确搜索定位，减少无效数据处理时间损耗。

1 系统分析

车辆行驶日志是按时间顺序排列的二进制数据帧，每帧开头的时间戳是该帧数据产生的时间标识[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 车辆运行日志数据帧

2 关键技术

2.1 日志导出及断点续传

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

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

图3 日志文件传输时序

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

2.2 变步长提取方法

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

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

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

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

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

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

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

1) 取一个点作探测基点x1，n个方向分别设为ei(i=1,2,···,n)， 设定初始步长为δ，步长缩减率为β ∈(0,1)， 步长增加率 τ>1， 加速因子 α ≥1，精度要求为ε， 置t1=x1， 循环步数k=1，i=1。

2) 若 探 测 到 更 优 点f(ti+δei)

3) 若最终i

4) 若f(tn+1)

5) 若 δ<ε ，则停止迭代，得到点xk(满足精度要求的“最优点”)，否则置 δ=βδ ，t1=xk，xk+1=xk，转步骤2)。

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

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

计算目标时间Tt与首帧时间T1的秒数差，得到首次跳转距离：

跳 转 后 记 录 当 前 帧 时 间Ti(i=1,2,···)，若(Ti−T1)<10 s，则进行下一步搜索，否则重复上述过程，最后记录内部指针所在帧的帧数nc与时间戳时间Tc。

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

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

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

3 实验与分析

本文选择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 算法的运行速度及准确率进行了对比，利用系统计时工具统计程序运行时间。

3.1 日志文件导出验证

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

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 软件进行比对，数据完全一致。

3.2 有效帧搜索验证

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

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

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

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

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

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

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

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

4 结 束 语

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