張 震，童 斌，付建軍，袁 正，余紅英，陳 勇

(1. 中北大學(xué)電氣與控制工程學(xué)院 太原 030051；2. 重慶長安新能源汽車科技有限公司 重慶 江北區(qū) 401133；3. 電子科技大學(xué)自動化工程學(xué)院 成都 611731；4. 電子科技大學(xué)電動汽車動力系統(tǒng)與安全技術(shù)研究所 成都 611731)

智能汽車功能配置復(fù)雜，車載電子控制單元(electronic control unit, ECU)數(shù)量多，對行車數(shù)據(jù)處理效率要求高。車輛各域控制器(domain control unit, DCU)管理并采集ECU 數(shù)據(jù)，通過CAN 總線傳輸?shù)狡囀录涗泝x(黑匣子)，快速準(zhǔn)確地提取這些數(shù)據(jù)是檢測與分析車輛行駛狀態(tài)的關(guān)鍵。車載數(shù)據(jù)提取包括數(shù)據(jù)導(dǎo)出及數(shù)據(jù)處理兩部分。數(shù)據(jù)導(dǎo)出方面，文獻[1]利用車輛CAN-BUS 實時數(shù)據(jù)采集系統(tǒng)挖掘和檢測行車信息，建立車輛異常檢測系統(tǒng)。文獻[2]通過CAN 總線網(wǎng)絡(luò)實現(xiàn)車輛數(shù)據(jù)提取。文獻[3]利用串口通信將車輛運行數(shù)據(jù)發(fā)送至監(jiān)測站，實現(xiàn)車輛路線的跟蹤。以上方式均能實現(xiàn)車載數(shù)據(jù)的穩(wěn)定導(dǎo)出，但有線通信受地點和物理接口限制，傳輸速度慢、移動性較差。文獻[4]提出了一種基于紅外通訊的VeLC 系統(tǒng)，實現(xiàn)車載光通信。文獻[5]將無線通信引入到車載數(shù)據(jù)采集系統(tǒng)中，實現(xiàn)無線局域網(wǎng)數(shù)據(jù)通信。但無線信號不穩(wěn)定，誤操作可能產(chǎn)生傳輸中斷問題，多任務(wù)斷點續(xù)傳方法可記錄中斷處信息，避免數(shù)據(jù)重復(fù)傳輸。FTP(file transfer protocol)協(xié)議是一種專用于遠程文件傳輸?shù)膽?yīng)用層協(xié)議[6]。現(xiàn)有的FTP 工具進行多任務(wù)傳輸前會臨時創(chuàng)建一個存儲文件名稱等信息的列表，文件傳輸數(shù)目越大，臨時空間就越大。傳輸工具異常中斷后臨時空間銷毀，再次連接只能續(xù)傳上次中斷處的單個文件，其余任務(wù)只能重選重傳。為優(yōu)化任務(wù)管理，文獻[7]設(shè)計了一種新的調(diào)度方式，通過預(yù)先預(yù)約將文件分塊，從而實現(xiàn)網(wǎng)絡(luò)資源的最優(yōu)化分配，但該方式無法應(yīng)用于文件數(shù)目較多的情況。文獻[8]提出一種可擴展的動態(tài)哈希方案，用于記錄分布不均勻的文件，該方案適用于多文件的加解密，但哈希過程會影響傳輸效率。文獻[9]提到日志歸并樹結(jié)構(gòu)，并在此基礎(chǔ)上對批量搜索做出改進，遍歷樹的方式切換速度快，但文件結(jié)構(gòu)本身是利用葉子和非葉子結(jié)點分別保存文件和文件夾信息的樹，算法本身有冗余。文獻[10]提出扁平輕量級文件系統(tǒng)，使目錄內(nèi)容和樹結(jié)構(gòu)扁平化，提高訪問速度。

數(shù)據(jù)處理方面，導(dǎo)出完成后，需對其中的有效數(shù)據(jù)進行甄別以便分析。車載域控制器產(chǎn)生的日志信息都是周期性的時間序列數(shù)據(jù)，在大量日志信息中查找指定時間段的數(shù)據(jù)幀可看作精確線性搜索問題[11]。常見的線性搜索方法有進退法、二分法、黃金分割法等[12]，多用于函數(shù)值可計算的單谷函數(shù)。log 文件中數(shù)據(jù)幀長度不固定，幀之間沒有分隔標(biāo)識，以上檢索方式均不適用。共軛梯度法、牛頓切線法[13]等不適用于離散的時間戳序列，而傳統(tǒng)順序檢索方式效率太低。為提高智能車載域控制器的數(shù)據(jù)傳輸效率及有效數(shù)據(jù)的搜索速度，本文基于FTP 傳輸方式設(shè)計新的導(dǎo)出任務(wù)管理方法，優(yōu)化傳統(tǒng)斷點續(xù)傳方法，使之能應(yīng)用于多文件及文件夾的任務(wù)傳輸。在有效數(shù)據(jù)的搜索方面，通過分析車載日志數(shù)據(jù)幀特點，提出變步長搜索方式，實現(xiàn)時間序列數(shù)據(jù)快速精確搜索定位，減少無效數(shù)據(jù)處理時間損耗。

1 系統(tǒng)分析

車輛行駛?cè)罩臼前磿r間順序排列的二進制數(shù)據(jù)幀，每幀開頭的時間戳是該幀數(shù)據(jù)產(chǎn)生的時間標(biāo)識[14]。車輛上電后，黑匣子會不間斷地通過CAN總線接收各ECU 返回的車輛運行數(shù)據(jù)。車載SVDC 總成是車身中用于中轉(zhuǎn)處理數(shù)據(jù)的專用域控制器，如圖1 所示，其中包含WiFi 模塊、4G 模組、存儲模塊等。數(shù)據(jù)經(jīng)MCU 處理之后，以log 文件形式存儲到4G 通訊模組的外置EMMC 存儲器。單個log 文件最大設(shè)為5 MB，以其結(jié)尾幀的時間命名，最多可包含超過140000 幀數(shù)據(jù)，詳細記錄了每一時刻各域控制器采集的車輛運行狀態(tài)信息。EMMC 最大容量為200 M，當(dāng)數(shù)據(jù)量將要超過最大容量時，新文件會循環(huán)覆蓋最早的文件，以保證黑匣子存儲10～12 小時內(nèi)的最新數(shù)據(jù)。如果SVDC 總成在當(dāng)前文件未寫滿的情況下掉電或停止運行，則強行保存該文件，恢復(fù)后創(chuàng)建新的log 文件記錄數(shù)據(jù)。因此車輛在實際駕駛過程中產(chǎn)生的log 文件大小不定，且數(shù)量較多，呈碎片化。目前FTP 工具支持多文件傳輸，但分析多款軟件后發(fā)現(xiàn)當(dāng)前斷點續(xù)傳功能不支持碎片化的多任務(wù)環(huán)境。

圖1 黑匣子結(jié)構(gòu)及日志導(dǎo)出示意圖

如圖1 所示，導(dǎo)出日志時，WiFi 模塊建立無線局域網(wǎng)環(huán)境，4G 模組創(chuàng)建FTP 服務(wù)器，與FTP 客戶端建立連接并進行數(shù)據(jù)交互。實際應(yīng)用中，用戶需提前輸入某一時間范圍，滿足該范圍的數(shù)據(jù)幀稱作有效幀。將含有效幀的log 文件導(dǎo)出到本地后，需進一步檢索，以精確分析設(shè)定時間段數(shù)據(jù)。有效幀按照固定協(xié)議轉(zhuǎn)換成ASC 格式，利用專用的行車數(shù)據(jù)分析軟件CANalyser 將用戶感興趣的車輛狀態(tài)信息進行回放。

車輛行駛過程中會產(chǎn)生加速、轉(zhuǎn)向、制動等操作信息以及多種傳感器采集的不同數(shù)據(jù)，這些數(shù)據(jù)以CAN 協(xié)議報文格式發(fā)送至SVDC 總成，經(jīng)MCU處理后以固定協(xié)議存儲。與CAN 數(shù)據(jù)結(jié)構(gòu)有所不同，數(shù)據(jù)幀存儲結(jié)構(gòu)如圖2 所示。日志數(shù)據(jù)幀主要字段包括UTC 時間戳、數(shù)據(jù)來源、數(shù)據(jù)長度(DLC)和狀態(tài)數(shù)據(jù)[15]。其中，UTC 時間是該幀數(shù)據(jù)在ECU 中產(chǎn)生的時間，最高可精確到微秒級，CAN 通道和ID 號反映該幀數(shù)據(jù)的來源，其中ID 號還用于CAN 消息的仲裁，該字段值越低表示優(yōu)先級越高。通信中存在CAN 和CANFD 兩種信道，Device Type 分別使用0 或1 填充以作區(qū)分。DLC 字段記錄狀態(tài)數(shù)據(jù)Data的字節(jié)數(shù)，最大為64。以上數(shù)據(jù)均為不透明二進制，工程人員在解析字段時需依據(jù)固定協(xié)議解碼。從圖2 中可以看到，時間戳占據(jù)數(shù)據(jù)幀前6 字節(jié)，從CAN Channel 到DLC 共7 個字節(jié)存儲數(shù)據(jù)來源等信息，Data 記錄這一時刻ECU 的狀態(tài)信息。為節(jié)省存儲空間，幀之間沒有分隔標(biāo)志。不同ECU狀態(tài)數(shù)據(jù)長度不同，采樣時間間隔也不同，所以log 文件中幀長度不定。在黑匣子存儲的海量數(shù)據(jù)中查找有效幀，必須依據(jù)時間戳進行判斷。

圖2 車輛運行日志數(shù)據(jù)幀

2 關(guān)鍵技術(shù)

2.1 日志導(dǎo)出及斷點續(xù)傳

FTP 文件傳輸異常中斷時，斷點續(xù)傳可以將文件指針直接定位到中斷位置，避免數(shù)據(jù)重復(fù)傳輸。現(xiàn)有的多任務(wù)管理方式多采用樹形結(jié)構(gòu)，任務(wù)中斷后再次重啟需要重新生成目錄樹，這種方式效率不高。傳輸任務(wù)過程中，利用不同文件名代表不同任務(wù)，文件夾上下層切換操作相對獨立，即對目錄樹的每次操作只能用到一小部分，利用這一特性，可對導(dǎo)出前獲取傳輸任務(wù)的步驟作出改進，將生成樹目錄的步驟分解為每次進入文件夾后獨立生成臨時子項列表。在這種管理方式下，系統(tǒng)完成列表所有子項操作后將該列表銷毀，降低同級文件夾之間的耦合性。

用戶設(shè)定日志導(dǎo)出條件后由系統(tǒng)直接進行任務(wù)解析，選擇需要導(dǎo)出的log 文件，如圖3 所示。圖中1～5 為用戶創(chuàng)建新導(dǎo)出任務(wù)的過程，2a、3b 為斷點續(xù)傳任務(wù)流程路線?？梢钥吹?，新系統(tǒng)在遍歷文件樹過程中，進入下層非葉子結(jié)點時創(chuàng)建臨時字符串列表，該列表在退出當(dāng)前文件夾后自動銷毀。根據(jù)服務(wù)器端獲取的文件信息特點[16]，系統(tǒng)利用換行符統(tǒng)計文件數(shù)目，將文件、文件夾名截取出來存儲至該列表。依靠這些信息實現(xiàn)文件樹上下層切換以及文件絕對路徑的拼接。文件絕對路徑分為3 個部分：1)用戶在界面顯示的列表中手動雙擊進入的文件夾名稱；2)遍歷目錄樹過程系統(tǒng)自動進入的非葉子子目錄；3)樹葉子結(jié)點存儲的文件名稱。這種方式與傳統(tǒng)方式相比，實現(xiàn)了各級文件路徑與名稱的分離。導(dǎo)出任務(wù)進行時，各級文件信息都是從服務(wù)器端臨時獲取，信息獨立為多任務(wù)斷點續(xù)傳提供了條件。文件分多包傳輸，除最后一包，其余包均為固定大小。每包傳輸過程分為獲取緩沖區(qū)數(shù)據(jù)和寫入本地文件兩個步驟，每一步都有相應(yīng)反饋。若反饋傳輸出錯，則自動重傳當(dāng)前文件。傳輸完成后根據(jù)文件字節(jié)數(shù)對比判斷傳輸是否成功。

圖3 日志文件傳輸時序

任務(wù)斷點續(xù)傳是根據(jù)上述文件名稱存儲特點，在任務(wù)管理階段創(chuàng)建臨時文件，利用任務(wù)路徑記錄導(dǎo)出進度。每完成一條任務(wù)刪除相應(yīng)記錄，保證下次傳輸可以精確定位到尚未完成的任務(wù)。

2.2 變步長提取方法

前面將包含有效數(shù)據(jù)的多個log 文件導(dǎo)出到本地之后，其中的無效數(shù)據(jù)數(shù)量仍然龐大，需進一步處理。如圖4 所示，先將導(dǎo)出到本地的log 文件按時間順序合并成一個文件，該文件中的數(shù)據(jù)仍按時間順序存儲。因此，有效數(shù)據(jù)必然連續(xù)存放，無效數(shù)據(jù)只存在于文件頭和尾。找到首個有效數(shù)據(jù)幀后，逐幀進行格式轉(zhuǎn)換，直到再次查找到無效幀后停止轉(zhuǎn)換。因此本文的重點就是研究如何快速找到第一幀有效數(shù)據(jù)，跳過文件開頭的無效數(shù)據(jù)。

圖4 有效日志數(shù)據(jù)導(dǎo)出、提取過程

日志數(shù)據(jù)是按時間戳單向遞增的離散型序列，如圖5a 所示。若想快速查找有效數(shù)據(jù)首幀并計算其幀數(shù)，應(yīng)將問題轉(zhuǎn)換成線性搜索問題求解。線性搜索問題是給定條件為指定閉區(qū)間和已知函數(shù)體，求單谷函數(shù)最優(yōu)點；而當(dāng)前問題是已知最優(yōu)點函數(shù)值和函數(shù)整體趨勢，求解目標(biāo)幀在海量數(shù)據(jù)中的精確位置。將時間值T作為因變量，在日志中的幀數(shù)n作自變量，建立數(shù)學(xué)模型：

車載ECU 日志的每一幀數(shù)據(jù)由各個域控制器定時產(chǎn)生，車輛運行時，每秒采集的總幀數(shù)波動不大，時間戳可近似看作線性增長。設(shè)最優(yōu)點時間為Tb，計算當(dāng)前幀時間與最優(yōu)點時間差的絕對值，可以直觀看出當(dāng)前時間與最優(yōu)點的“距離”，從圖5b 可以看出，此時區(qū)間內(nèi)已明顯存在“最優(yōu)點”。

圖5 時間戳?幀數(shù)大致分布

從幾何意義上來看，解決該問題實際上是搜索函數(shù)在有限區(qū)間的最小點。由于時間?幀數(shù)函數(shù)無法求導(dǎo)，所以本文通過改進hooke-jeeves 搜索法，使其更適用于不定長單調(diào)離散數(shù)據(jù)搜索。

hooke-jeeves 算法是一種非線性函數(shù)優(yōu)化方法，利用迭代計算逐漸逼近目標(biāo)函數(shù)最優(yōu)解[17]。該算法的基本思路為：查找過程分為探測和爬行兩種操作，其中探測操作尋找函數(shù)下降方向，確定下一個數(shù)據(jù)點，如果新的數(shù)據(jù)點比原基點更優(yōu)，則進行爬行操作，繼續(xù)尋找下一點，若新點劣于原基點，則退回到基點重新探測，具體分為以下5 個步驟。

1) 取一個點作探測基點x1，n個方向分別設(shè)為ei(i=1,2,···,n)， 設(shè)定初始步長為δ，步長縮減率為β ∈(0,1)， 步長增加率 τ>1， 加速因子 α ≥1，精度要求為ε， 置t1=x1， 循環(huán)步數(shù)k=1，i=1。

2) 若 探 測 到 更 優(yōu) 點f(ti+δei)

3) 若最終i

4) 若f(tn+1)

5) 若 δ<ε ，則停止迭代，得到點xk(滿足精度要求的“最優(yōu)點”)，否則置 δ=βδ ，t1=xk，xk+1=xk，轉(zhuǎn)步驟2)。

搜索過程中步長根據(jù)相應(yīng)參數(shù)進行調(diào)整，且計算結(jié)果好壞與初值選擇相關(guān)。但是在有效數(shù)據(jù)搜索過程中，初值固定且在數(shù)據(jù)量很大的情況下步長不易確定。本文以hooke-jeeves 算法為基礎(chǔ)，提出更適用于日志數(shù)據(jù)查找的變步長提取方法。

搜索準(zhǔn)備階段，首先計算首幀與目標(biāo)幀時間差。若差值大于100 s，則將時間戳相同的數(shù)據(jù)幀分為一組，可大致看作與圖5b 類似的線性問題，利用該特性快速逼近目標(biāo)值；否則，直接進入搜索階段。從圖2 可以看到，從時間戳到行駛數(shù)據(jù)長度之間共14 字節(jié)。根據(jù)該特點，直接計算無需逐幀轉(zhuǎn)換的數(shù)據(jù)字節(jié)數(shù)，據(jù)此改變文件內(nèi)部指針指向，避免每幀時間戳的提取轉(zhuǎn)換及比對。而Data 字段長度由DLC 指定，所以搜索過程中每幀DLC 部分仍需計算。一個5 MB 的log 文件大約有14 萬幀，跳過大部分無效幀，可以大大減少數(shù)據(jù)處理時間。根據(jù)域控制器定時產(chǎn)生數(shù)據(jù)的特點，算法首先提取前20 幀數(shù)據(jù)，利用不同ID 大致估計域控制器數(shù)目為num，對試驗車輛進行統(tǒng)計，得出每個域控制器每秒大約反饋50～140 幀數(shù)據(jù)。為保證不越過最優(yōu)點，數(shù)據(jù)幀線性部分增長斜率h設(shè)置為：

計算目標(biāo)時間Tt與首幀時間T1的秒數(shù)差，得到首次跳轉(zhuǎn)距離：

跳 轉(zhuǎn) 后 記 錄 當(dāng) 前 幀 時 間Ti(i=1,2,···)，若(Ti?T1)<10 s，則進行下一步搜索，否則重復(fù)上述過程，最后記錄內(nèi)部指針?biāo)趲膸瑪?shù)nc與時間戳?xí)r間Tc。

搜索階段，距離目標(biāo)點不大于100 s 時，此時數(shù)據(jù)幀不再適合分組討論，線性方式不適用該區(qū)間的目標(biāo)搜索，此時問題變換為類似圖5c 曲線的單谷函數(shù)最優(yōu)點搜索問題。利用hooke-jeeves 算法進一步逼近，該算法需要對不同方向函數(shù)值下降速度進行比對以保證最優(yōu)。但是log 文件僅需朝著幀數(shù)增加的方向搜索，所以該搜索模式可以進行簡化。設(shè)定步長為k，步長縮減率 β=0.5，將探測與爬行兩步結(jié)合，首先計算搜索準(zhǔn)備階段記錄的時間Tc與目標(biāo)時間Tt的差值：

逼近過程如圖6 所示，每次跳轉(zhuǎn)之后需計算?T。若 ?T>2，則按照設(shè)定步長繼續(xù)跳轉(zhuǎn)，若1

圖6 跳轉(zhuǎn)過程中的幾種不同情況

3 實驗與分析

本文選擇Visual Studio 平臺，利用MFC 開發(fā)工具編寫了FTP 客戶端應(yīng)用軟件，硬件平臺為某型新能源汽車SVDC 總成。SVDC 總成CPU 為搭載Linux 系統(tǒng)的驍龍700 處理器，WiFi 模塊采用802.11b 協(xié)議，測試過程中理論最大的傳輸速度可以達到11 Mbps≈1.375 MB/s。試驗車輛在不同駕駛條件下正常運行，黑匣子同時開啟3 個域控制器實時采集，記錄約10 h、200 MB 左右的數(shù)據(jù)集。選取長度不等的幾個時間段進行日志導(dǎo)出和數(shù)據(jù)提取，并利用專業(yè)CAN 數(shù)據(jù)回放軟件CANalyser、文件比對軟件UltraEdit 等對數(shù)據(jù)進行分析。

本文針對不同時刻不同時間段的日志數(shù)據(jù)，分別對系統(tǒng)的數(shù)據(jù)導(dǎo)出和有效數(shù)據(jù)檢索功能進行驗證，并與現(xiàn)有FTP 傳輸工具FileZilla Cllient 3.55.0、順序搜索、hooke-jeeves 算法的運行速度及準(zhǔn)確率進行了對比，利用系統(tǒng)計時工具統(tǒng)計程序運行時間。

3.1 日志文件導(dǎo)出驗證

導(dǎo)出過程中，通過中斷網(wǎng)絡(luò)、屏蔽信號等方式，驗證系統(tǒng)多任務(wù)斷點續(xù)傳功能，實驗證明導(dǎo)出文件正確，該功能有效。

1)導(dǎo)出速度驗證

圖7 為本導(dǎo)出系統(tǒng)與通用FTP 軟件FileZilla分別對不同大小的日志數(shù)據(jù)導(dǎo)出的用時對比?？梢钥吹?，本系統(tǒng)在導(dǎo)出用時上稍有劣勢，但兩者相差不大。導(dǎo)出用時與文件總大小并不嚴格成線性關(guān)系，該現(xiàn)象由多任務(wù)切換時間損耗造成。

圖7 本系統(tǒng)與FileZilla 軟件傳輸時長對比

為了進一步了解兩種方式對導(dǎo)出速度的影響，在無線局域網(wǎng)環(huán)境下接入單個客戶端，導(dǎo)出全部日志同時進行了實時網(wǎng)速測試。從圖8 的測試結(jié)果看，本方法導(dǎo)出平均吞吐約8.861 9 Mbps，F(xiàn)ileZilla導(dǎo)出平均吞吐約8.934 4 Mbps，兩種方式寬帶利用率均在80%以上，所以綜上可知本系統(tǒng)傳輸方法對速率的影響不明顯。

圖8 本系統(tǒng)與FileZilla 流量吞吐對比

2)導(dǎo)出準(zhǔn)確率驗證

影響FTP 性能的因素有擁塞窗口大小和網(wǎng)絡(luò)剩余帶寬等[18]，最大網(wǎng)速受限于硬件不可調(diào)整。由于FTP 文件分包傳輸，包過大，傳輸速率超過硬件寫入速度時會導(dǎo)致服務(wù)器CPU 負載過大，增加丟包率；包過小則會線性增加FTP 交互次數(shù)，降低傳輸速率[19]。為提高傳輸?shù)恼_率，控制信息往返時長，需調(diào)整FTP 傳輸時網(wǎng)絡(luò)數(shù)據(jù)包的大小。經(jīng)過反復(fù)測試，將包大小設(shè)置為5 KB。

準(zhǔn)確率驗證分兩部分，程序中利用文件大小判斷傳輸成功與否，導(dǎo)出到本地之后利用UltraEdit軟件逐字節(jié)匹配源文件和導(dǎo)出文件。經(jīng)多次驗證，文件導(dǎo)出和斷點續(xù)傳功能穩(wěn)定可靠，導(dǎo)出成功率大于95%。將斷點續(xù)傳和正常傳輸?shù)玫降奈募ㄟ^UltraEdit 軟件進行比對，數(shù)據(jù)完全一致。

3.2 有效幀搜索驗證

為驗證變步長提取方法的效率以及準(zhǔn)確率，本文用該方法分別與順序搜索和直接基于hookejeeves 算法修改的搜索方法進行比對。選取不同長度以及不同時間段的多組數(shù)據(jù)，用3 種方法分別進行搜索提取，并利用程序計時工具分別統(tǒng)計log 文件中找到首條有效幀所用的時間。

選擇多次測試中具有代表性的幾組數(shù)據(jù)，如圖9 所示。圖中數(shù)值分別表示用戶實際搜索過程中，手動輸入的時間區(qū)間大小(5 min、15 min、30 min)以及提取的多個log 文件中首文件的大小(4.1 MB、10 MB 和3.75 MB)?？梢钥吹剿阉饔脮r與設(shè)定時間區(qū)間大小以及首文件大小無關(guān)，hookejeeves 和變步長提取方法較原順序搜索效率明顯提高，其中變步長提取檢索速度較順序檢索方式提高40%以上。為了進一步分析文件內(nèi)部指針跳轉(zhuǎn)情況，將hooke-jeeves 和變步長提取方法每一次跳轉(zhuǎn)后指針?biāo)趲瑪?shù)進行了統(tǒng)計。

圖9 3 種搜索方法查找首條有效幀用時

實驗中，車輛運行采集3 個域控制器數(shù)據(jù)，圖10 中每一小格代表50×3 幀數(shù)據(jù)，末尾深色部分表示有效數(shù)據(jù)，長線顯示了搜索過程中文件內(nèi)部指針跳轉(zhuǎn)情況?？梢钥吹絟ooke-jeeves 算法初始步長較小，搜索過程中步長調(diào)整增大，而變步長提取方式直接大致估算距離，所以初始步長較大。從首幀開始逼近目標(biāo)的這一階段，變步長方式與hookejeeves 相比，速度沒有明顯優(yōu)勢。但hooke-jeeves算法更加依賴初始步長的設(shè)置，相較于變步長方式靈活性較差。

圖10 hooke-jeeves 和變步長提取方法大區(qū)間文件指針跳轉(zhuǎn)情況

文件指針跳轉(zhuǎn)到距離目標(biāo)幀小于2 s 的位置后，兩種算法此刻均為步長縮減階段。由于步長縮減率均設(shè)置為0.5，所以變步長提取方式搜索準(zhǔn)備階段與 hooke-jeeves 收斂速度基本一致。區(qū)別在于?T≤1的階段，hooke-jeeves 繼續(xù)跳轉(zhuǎn)而變步長方法提前將步長設(shè)置為1。圖11 中每個長條代表兩個數(shù)據(jù)幀，可以看到，由于同一時刻的日志數(shù)據(jù)通常大于1 條，而有效幀的判斷方式為時間戳對比，hooke-jeeves 最終查找到目標(biāo)幀之后的數(shù)據(jù)導(dǎo)致出錯。變步長提取方式采用順序逐幀搜索判斷的方式避免越過首幀，保證了搜索的準(zhǔn)確性。

圖11 hooke-jeeves 和變步長提取方法小區(qū)間文件指針跳轉(zhuǎn)情況

實驗評估表明，log 文件導(dǎo)出系統(tǒng)在保證傳輸速度和準(zhǔn)確率的同時，實現(xiàn)了多任務(wù)傳輸?shù)臄帱c續(xù)傳功能。變步長有效數(shù)據(jù)提取方式比原有的順序檢索方式執(zhí)行時間更短，收斂性能與hooke-jeeves 模式搜索方式相當(dāng)?shù)耐瑫r，比后者更加精確。

4 結(jié) 束 語

汽車域控制器運行數(shù)據(jù)是反映車輛真實運行狀態(tài)的重要信息，及時導(dǎo)出指定時間的數(shù)據(jù)，是獲知車輛事故原因或車輛缺陷等的關(guān)鍵。本文設(shè)計了基于WiFi 的多任務(wù)導(dǎo)出系統(tǒng)，改進了FTP 多任務(wù)管理方式，實現(xiàn)了多任務(wù)斷點續(xù)傳。通過對行車數(shù)據(jù)存儲特點分析提出變步長追蹤算法，利用時間戳信息實現(xiàn)有效數(shù)據(jù)快速檢索定位。最后利用某型汽車SVDC 總成進行比對驗證，結(jié)果表明，新系統(tǒng)能穩(wěn)定實現(xiàn)多任務(wù)斷點續(xù)傳，算法將有效數(shù)據(jù)檢索時間縮短40%以上，證明了該方法的有效性。