做車載診斷的朋友應(yīng)該都遇到過這樣的場景刷寫完一塊控制單元診斷儀發(fā)完34/36/37服務(wù)最后一步往往就是一個復(fù)位指令或者車輛出現(xiàn)某個偶發(fā)故障排查到最后發(fā)現(xiàn)先讓ECU重啟一次故障現(xiàn)象可能就變了。這個“讓ECU重啟”的指令就是UDS協(xié)議里的0x11服務(wù)ECUReset。它在ISO 14229標(biāo)準(zhǔn)里只占短短幾行描述但實際工程里牽扯到報文時序、條件限制、刷寫流程銜接、診斷儀重連機制坑一點都不少。這篇文章我想把UDS 0x11服務(wù)從協(xié)議規(guī)范到工程落地完整拆一遍。不管你是在做ECU軟件開發(fā)、診斷測試還是剛接觸車載總線想搞懂診斷服務(wù)看完應(yīng)該能對“ECU復(fù)位”這件事建立起一個清晰、可落地的認(rèn)知框架。內(nèi)容里會包含我實際踩過的坑和排查經(jīng)驗這部分是文檔里寫不到的。1. 把0x11服務(wù)放在UDS坐標(biāo)系里看1.1 0x11在診斷協(xié)議棧中的位置UDSUnified Diagnostic Services是ISO 14229標(biāo)準(zhǔn)定義的一套診斷服務(wù)集合跑在CAN、CAN FD、以太網(wǎng)DoIP、LIN等不同底層總線上。整套協(xié)議可以理解為診斷儀Tester和ECU之間的一套“對話規(guī)則”。常見的服務(wù)分區(qū)大概可以歸為幾類0x10/0x11負(fù)責(zé)會話和復(fù)位控制0x27負(fù)責(zé)安全訪問0x22/0x2E負(fù)責(zé)數(shù)據(jù)讀寫0x31是例程控制0x34/0x36/0x37是內(nèi)存讀寫和上傳下載0x19是故障碼相關(guān)0x28/0x85是通信控制。0x11在ISO 14229-1里排在會話控制服務(wù)0x10后面全稱是ECUReset。從功能定位上看0x10是改變ECU的診斷會話狀態(tài)0x11是讓ECU的軟件環(huán)境重新初始化。兩者經(jīng)常一起出現(xiàn)比如刷寫完程序后先通過0x10進(jìn)入編程會話刷完再用0x11退出復(fù)位又比如某些ECU在發(fā)生通信沖突后診斷儀會發(fā)0x11讓ECU回到一個干凈的初始狀態(tài)。從實現(xiàn)層級看0x11處于應(yīng)用層但它一旦生效影響會向下穿透到通信層和硬件層。ECU收到復(fù)位請求后不只是診斷狀態(tài)機要重置整個微控制器的運行環(huán)境都要重新初始化外設(shè)寄存器、中斷向量、棧指針、CAN控制器狀態(tài)都會回到上電初始狀態(tài)。所以0x11服務(wù)在UDS里屬于“影響范圍大、執(zhí)行后果重”的那一類服務(wù)。1.2 為什么ECU復(fù)位能成為一項診斷服務(wù)很多剛接觸汽車電子的人會問ECU重啟不是把鑰匙一擰或者斷電就行了嗎為什么要專門定義一個診斷服務(wù)這里的關(guān)鍵在于“可控性”和“可觀測性”。物理斷電重啟的問題在于你無法準(zhǔn)確控制重啟發(fā)生的時機也無法通過診斷鏈路獲知ECU當(dāng)前運行狀態(tài)。整車環(huán)境下ECU的供電直接受蓄電池和電源管理策略影響你不可能讓一輛正在行駛的車突然拔掉某個ECU的電源。而0x11服務(wù)由診斷儀通過總線發(fā)出ECU在正常通信狀態(tài)下收到請求在明確的時序窗口內(nèi)執(zhí)行復(fù)位動作整個過程可以通過總線報文被完整記錄下來。對產(chǎn)線測試、售后診斷、遠(yuǎn)程刷寫來說這一步不可或缺。另一個原因是ECU的“復(fù)位”本身也是測試對象。ECU在整車上要經(jīng)歷無數(shù)次的上下電循環(huán)每一次啟動和復(fù)位都可能觸發(fā)軟件缺陷比如初始化順序錯誤、RAM清零邏輯不完善、診斷狀態(tài)未保存等。0x11服務(wù)相當(dāng)于給了測試工程師一個精準(zhǔn)的“重演開關(guān)”通過不停發(fā)送復(fù)位請求可以快速做上下電可靠性測試暴露軟件在復(fù)位時序上的問題。再有從整車電子電氣架構(gòu)角度看很多ECU之間都有依賴關(guān)系。某個域控制器復(fù)位其他ECU要能感知并做出相應(yīng)處理。UDS 0x11服務(wù)在整個復(fù)位過程中提供了明確的狀態(tài)信號比如復(fù)位后ECU重新發(fā)送應(yīng)用層報文、重新廣播節(jié)點位置、重新建立診斷會話這些都可以作為系統(tǒng)級聯(lián)動的觸發(fā)條件。2. 0x11請求與響應(yīng)的報文細(xì)節(jié)2.1 從一條CAN報文說起0x11是怎么組成的用最常見的情況舉例UDS跑在CAN上診斷儀往ECU的物理尋址請求ID通常是0x7E0發(fā)一幀CAN報文CAN數(shù)據(jù)場里就裝著UDS報文。0x11服務(wù)的請求格式規(guī)定如下字節(jié)0單幀時0x02表示后面跟2個數(shù)據(jù)字節(jié)字節(jié)10x11服務(wù)ID字節(jié)20x01子功能表示hardReset硬復(fù)位所以一幀完整的0x11硬復(fù)位請求CAN數(shù)據(jù)場長這樣02 11 01 00 00 00 00 00注意如果ECU使用的是CAN FD或者DoIP單幀長度規(guī)則不同但服務(wù)ID和子功能字節(jié)的排列邏輯是一樣的只是外層長度字段表示方式有差異。請求發(fā)出后正常情況下ECU會回復(fù)正響應(yīng)06 51 01 32 00 00 00 00其中0x06表示后面跟著6個數(shù)據(jù)字節(jié)0x51是正響應(yīng)服務(wù)ID請求服務(wù)ID加0x400x01回顯請求的子功能0x32是powerDownTime。這個響應(yīng)字段的含義后面單獨講。隱含的一個問題是這個正響應(yīng)并不保證一定能在復(fù)位前完整發(fā)送到總線上因為ECU收到請求后可能馬上就開始復(fù)位流程了。實際測試中經(jīng)常出現(xiàn)“請求發(fā)出去響應(yīng)沒收到”的情況后面排查章節(jié)會分析。2.2 子功能位和抑制正響應(yīng)位0x11服務(wù)的第二個字節(jié)分成兩個域bit6到bit0是子功能bit7是suppressPosRspMsgIndicationBit也就是“抑制正響應(yīng)位”。用易懂的方式理解bit7等于1時相當(dāng)于你要求ECU“只管干活別回話了”。在診斷儀的實際配置里如果發(fā)送方清楚ECU復(fù)位后整個診斷鏈路會斷開正響應(yīng)根本來不及接收提前用bit7抑制正響應(yīng)也是一種常見做法。舉個可操作的例子0x01bit70子功能1需要正響應(yīng)表示hardReset0x81bit71子功能1不要正響應(yīng)同樣執(zhí)行hardReset注意ISO 14229規(guī)范里講了如果抑制正響應(yīng)位被置1ECU就不會發(fā)正響應(yīng)但可能還是會發(fā)負(fù)響應(yīng)。也就是說當(dāng)請求本身格式不對或者條件不滿足時即使bit7置1ECU也可以回復(fù)NRC。這是一種“正響應(yīng)可以不要但錯誤必須反饋”的設(shè)計邏輯。各子功能定義在協(xié)議中有保留范圍子功能值含義典型使用場景0x01hardReset模擬斷電再上電刷寫收尾、恢復(fù)默認(rèn)狀態(tài)0x02keyOffOnReset模擬ACC OFF再ON保留部分供電狀態(tài)0x03softReset軟件復(fù)位復(fù)位向量跳轉(zhuǎn)不涉及硬件復(fù)位0x04fastReset快速復(fù)位盡量縮短不可通信時間0x05-0x7F保留/OEM自定義各廠商自定義的特定復(fù)位類型2.3 powerDownTime響應(yīng)字段怎么理解正響應(yīng)第三字節(jié)0x32換成十進(jìn)制是50單位是毫秒。ISO 14229里對powerDownTime的定義是ECU執(zhí)行復(fù)位動作后到它開始重新通信所需的時間估計值。實際含義是這個ECU告訴診斷儀“我馬上要斷電重啟了你大概等50ms再來找我?！痹\斷儀拿到這個值就可以設(shè)置重連等待時間。但在真實ECU中50ms往往只是一個樂觀估計。硬件上電源有掉電時序晶振起振有穩(wěn)定時間Bootloader要判斷跳轉(zhuǎn)條件應(yīng)用軟件要完成外設(shè)初始化和診斷狀態(tài)恢復(fù)。我實測過某些ECU的hardReset恢復(fù)時間在100~200ms之間如果診斷儀嚴(yán)格按響應(yīng)里的50ms去重試請求前幾次會超時。所以實戰(zhàn)建議是診斷儀側(cè)的通信超時時間不能只依賴powerDownTime最好設(shè)置一個下限值比如至少等待200ms同時做連續(xù)多次重試。3. 各復(fù)位子功能的工程含義3.1 hardReset硬復(fù)位最常用的“重啟大法”hardReset模擬的是ECU的硬件下電再上電過程。在ECU內(nèi)部實現(xiàn)上它通常不是真的切斷電源而是通過控制復(fù)位引腳或者讓電源管理芯片觸發(fā)一次復(fù)位時序讓整個芯片回到復(fù)位狀態(tài)再從復(fù)位向量啟動。對應(yīng)用軟件來說hardReset帶來的結(jié)果是所有RAM內(nèi)容清空、外設(shè)寄存器恢復(fù)默認(rèn)值、全局變量重新初始化、RTC之類靠后備電源保持的資源可能保留也可能不保留。假如ECU在運行過程中積累了某些異常狀態(tài)比如內(nèi)部狀態(tài)機跑飛、標(biāo)志位被錯誤置位、變量超出預(yù)期范圍hardReset基本能把這些狀態(tài)全部清掉。這是它跟軟復(fù)位最大的區(qū)別。在實際刷寫流程里hardReset是最常用的收尾動作。新程序刷到Flash之后ECU需要一個完整的硬件復(fù)位來讓新程序從入口地址正常啟動。如果只用softReset某些硬件外設(shè)可能還是舊配置程序跑到一半才發(fā)現(xiàn)寄存器狀態(tài)不對輕則功能異常重則卡死。3.2 keyOffOnReset與softReset兩種容易被混淆的復(fù)位keyOffOnReset的語義是“模擬點火開關(guān)從OFF切換到ON”。它跟hardReset的區(qū)別主要體現(xiàn)在電源域上。整車ECU有時會分常電域和點火電域keyOffOnReset只復(fù)位點火電域的部分常電域相關(guān)的RAM可以保留。這對那些需要保存“長時間累計數(shù)據(jù)”的場景很有價值比如累計里程、學(xué)習(xí)值、故障發(fā)生次數(shù)。如果用hardReset把這些都清了客戶和法規(guī)都不會答應(yīng)。softReset則更輕量它不觸發(fā)硬件復(fù)位引腳而是軟件跳轉(zhuǎn)到復(fù)位向量重新執(zhí)行啟動代碼。啟動代碼如果判斷到是軟復(fù)位可能會跳過某些硬件初始化比如不復(fù)位PLL時鐘、不重新配置引腳復(fù)用這樣做的目的就是縮短啟動時間。代價是軟復(fù)位后的環(huán)境并不完全等價于上電某些硬件模塊的狀態(tài)可能殘留上一輪的配置。我遇到過一個案例ECU用softReset后CAN控制器沒有完全重新初始化導(dǎo)致舊報文過濾器還殘留新會話下收不到部分報文最后定位到啟動代碼沒在軟復(fù)位分支里清中斷標(biāo)志。所以選哪個子功能不能只看字面意思。如果寫復(fù)位邏輯時明確要求“徹底、干凈”可以考慮hardReset如果ECU有需要保留的掉電保持?jǐn)?shù)據(jù)需要考慮keyOffOnReset如果只是讓應(yīng)用程序重新運行一遍且硬件環(huán)境不變可以用softReset。診斷測試時要確保測試用例和實際復(fù)位類型一致我見過不少測試用例里寫的是softReset實現(xiàn)卻觸發(fā)了hardReset最后測試結(jié)論對不上。3.3 fastReset和其他OEM自定義復(fù)位fastReset是較新版本協(xié)議里補充的一種復(fù)位類型設(shè)計目標(biāo)是讓復(fù)位期間的“不可用時間”盡量短。它跟softReset類似但更激進(jìn)可以直接跳過部分外設(shè)初始化、跳過自檢項目、甚至不重新初始化某些通信控制器只要滿足功能安全要求能跑起來就行。OEM自定義復(fù)位就更多樣了。有些廠商在0x05到0x7F之間定義了自己的擴展復(fù)位功能比如“僅復(fù)位應(yīng)用軟件不復(fù)位Bootloader”“復(fù)位到Bootloader”“復(fù)位后保留診斷會話”等。自定義復(fù)位沒有統(tǒng)一規(guī)范實現(xiàn)完全依賴OEM的軟件設(shè)計所以診斷儀要對接這些自定義服務(wù)時必須拿到OEM的診斷規(guī)范說明。4. 0x11在真實診斷場景中的配合與落地4.1 刷寫流程中0x11的角色現(xiàn)在主流的UDS刷寫流程大體長這樣0x10 02進(jìn)入擴展診斷會話或者0x10 03進(jìn)入編程會話0x27請求種子然后發(fā)密鑰完成安全訪問解鎖0x2E或0x31做刷寫前提檢查確認(rèn)零件號、電壓、硬件版本等條件滿足0x34請求下載聲明要寫入的內(nèi)存地址和數(shù)據(jù)長度0x36周期性發(fā)送數(shù)據(jù)塊0x37請求傳輸結(jié)束告知ECU數(shù)據(jù)發(fā)送完畢0x11復(fù)位ECU讓新程序啟動0x11在整個刷寫流程里是“最后一腳油門”。注意這里有個時序上的細(xì)節(jié)刷寫完成后ECU里存儲的是新程序但當(dāng)前實際運行的是Bootloader程序必須靠一次復(fù)位才能跳轉(zhuǎn)到應(yīng)用程序。如果少了0x11這一步ECU會一直停在Bootloader里表現(xiàn)為不響應(yīng)應(yīng)用層的功能請求很多產(chǎn)線上的ECU就是這么被誤判為“刷壞”的。刷寫后通常建議用hardReset而不是softReset原因跟前面講的一樣新程序需要一個“干凈”的硬件環(huán)境來初始化所有外設(shè)避免舊配置殘留。4.2 故障診斷中如何用0x11做“環(huán)境復(fù)位”在故障排查中0x11還剩一個容易忽略的用途在讀取故障碼之前或者清碼之后讓ECU回到一個確定的初始狀態(tài)。舉例一個偶發(fā)故障碼在內(nèi)存里可能有環(huán)境數(shù)據(jù)殘留比如凍結(jié)幀里的電壓、車速、溫度。如果不復(fù)位ECU直接讀凍結(jié)幀讀到的可能是很久之前的歷史數(shù)據(jù)分析起來容易被誤導(dǎo)。先發(fā)一次0x11讓ECU把所有運行參數(shù)重新初始化再復(fù)現(xiàn)故障凍結(jié)幀里記錄的數(shù)據(jù)才有對照意義。還有一類情況是ECU進(jìn)入了某種保護(hù)模式后不再響應(yīng)正常請求只響應(yīng)診斷請求。此時通過0x11可以讓ECU退出保護(hù)模式回到正常的可測試狀態(tài)。比如整車某個ECU檢測到持續(xù)過壓觸發(fā)負(fù)載保護(hù)執(zhí)行完保護(hù)動作后禁止某些輸出我用0x11恢復(fù)過好幾次這樣的ECU效果立竿見影。4.3 診斷儀側(cè)必須處理的超時與重連機制0x11服務(wù)跟其他服務(wù)最大的差別是執(zhí)行成功的標(biāo)志不是“收到正響應(yīng)”而是“在一段時間內(nèi)收不到ECU的報文然后報文又恢復(fù)”。診斷儀如果在發(fā)送0x11后眼巴巴等正響應(yīng)大概率會超時。正確的處理邏輯一般是這樣發(fā)送復(fù)位請求等待一段可配置的時間比如500ms在此期間ECU可能出現(xiàn)通信中斷現(xiàn)象不視為故障超時后主動重發(fā)一次“會話切換請求”0x10 01回默認(rèn)會話或者直接發(fā)0x3E測試器在線如果ECU恢復(fù)了正常響應(yīng)判定復(fù)位成功如果多次重試仍無響應(yīng)才判定復(fù)位失敗這個重連邏輯如果做不好刷寫工具就會在最后一步誤報失敗。我記得有一次EOL線上刷寫程序?qū)懲旰蟀l(fā)0x11診斷儀一次性超時后直接報了失敗產(chǎn)線停了幾分鐘排查最后發(fā)現(xiàn)是診斷儀側(cè)的等待時間配的太短ECU的恢復(fù)時間比預(yù)期多了80ms。改成兩次重試之后問題消失。5. NRC與異常響應(yīng)的排查5.1 常見NRC速查ECU接收到0x11請求后如果條件不滿足會回復(fù)負(fù)響應(yīng)Negative Response。負(fù)響應(yīng)格式是03 7F 11 NRC0x7F是負(fù)響應(yīng)服務(wù)ID0x11是請求的服務(wù)ID最后一個字節(jié)是NRC碼。NRC含義常見觸發(fā)原因0x12子功能不支持發(fā)送了保留值或OEM未實現(xiàn)的子功能0x13報文長度錯誤或格式無效請求長度不等于2或者格式字節(jié)不對0x22條件不滿足整車狀態(tài)不允許復(fù)位比如車輛在行駛中0x24請求序列錯誤某些流程要求先進(jìn)入特定會話再復(fù)位0x31請求超出范圍子功能值雖然合法但當(dāng)前ECU狀態(tài)不適用0x33安全訪問被拒絕OEM要求先解鎖才能復(fù)位0x11服務(wù)的一個特殊點是標(biāo)準(zhǔn)并沒有強制要求這個服務(wù)必須通過安全訪問解鎖。在絕大多數(shù)ECU實現(xiàn)里0x11被歸為“非安全服務(wù)”可以在默認(rèn)會話里直接使用。但我在某些OEM規(guī)范里也見過要求先做安全訪問的變體比如防止售后診斷儀隨意復(fù)位控制器。遇到0x33時務(wù)必先去查OEM的診斷文檔確認(rèn)是否額外加了安全要求。5.2 請求0x11后無響應(yīng)的處理順序?qū)嶋H工作里發(fā)完0x11后最容易遇到的問題不是收到NRC而是從頭到尾一幀響應(yīng)的影子都沒看到。排查順序建議這樣走第一步確認(rèn)是否設(shè)置了抑制正響應(yīng)位。如果你發(fā)的字節(jié)是0x81那沒響應(yīng)是正常的。第二步通過總線報文確認(rèn)ECU在復(fù)位前是否發(fā)出了正響應(yīng)幀只是診斷儀沒來得及記錄。有些ECU的實現(xiàn)是先發(fā)正響應(yīng)再做復(fù)位但因為復(fù)位動作太快CAN控制器還沒把發(fā)送緩沖區(qū)的數(shù)據(jù)真正發(fā)出去正響應(yīng)就丟了。這時候把總線工具掛上去抓原始報文能看到ECU在復(fù)位后有沒有重新上電的報文序列。第三步檢查ECU的供電和復(fù)位電路。硬件上有些ECU的復(fù)位引腳被外部看門狗芯片控制如果應(yīng)用軟件初始化時間太長看門狗會在復(fù)位過程中再次觸發(fā)復(fù)位導(dǎo)致ECU反復(fù)重啟表現(xiàn)就是診斷儀永遠(yuǎn)等不到一個穩(wěn)定的響應(yīng)。排查方法是用示波器抓復(fù)位引腳的波形看有沒有周期性的反復(fù)拉低。第四步確認(rèn)ECU是否進(jìn)到了Bootloader但又被配置成“不進(jìn)診斷”的狀態(tài)。有些Bootloader在收到非法應(yīng)用啟動標(biāo)志后會嘗試把控制權(quán)交給應(yīng)用但應(yīng)用又校驗失敗最終卡在死循環(huán)里整個ECU變成“啞巴”。這種情況只能靠硬件調(diào)試器或強制進(jìn)入Bootloader模式來恢復(fù)。5.3 復(fù)位后“卡死”的排查思路復(fù)位完成后ECU應(yīng)該處于一個“活著”的狀態(tài)但有時會表現(xiàn)為復(fù)位后再也不發(fā)報文、診斷請求無響應(yīng)。這種“卡死后復(fù)位”問題一半以上是軟件初始化順序問題。我的排查習(xí)慣是分三層推進(jìn)首先是基本供電層面確認(rèn)ECU在復(fù)位期間沒有出現(xiàn)電壓跌落。上電瞬間多個外設(shè)同時初始化電流峰值可能把電源拉垮假如ECU的電源監(jiān)控芯片檢測到欠壓會再次觸發(fā)復(fù)位形成復(fù)位死循環(huán)。其次是啟動代碼層面檢查復(fù)位向量和啟動配置是否正確。比如中斷向量表有沒有被錯誤地映射到RAM地址啟動時訪問了未初始化的外設(shè)寄存器在某個外設(shè)初始化函數(shù)里輪詢等待一個永遠(yuǎn)不置位的標(biāo)志位。用調(diào)試器看PC指針跑在哪個地址基本能判斷卡在哪一步。最后是應(yīng)用層邏輯層面檢查診斷模塊有沒有“等待上一個會話關(guān)閉后才允許新會話”的設(shè)計缺陷。有些ECU復(fù)位后診斷狀態(tài)會恢復(fù)到默認(rèn)會話如果診斷儀在復(fù)位前處于擴展會話復(fù)位后直接發(fā)送擴展會話相關(guān)請求ECU會回0x7F導(dǎo)致后續(xù)流程中斷。6. 實操記錄與避坑心得6.1 一次EOL產(chǎn)線的復(fù)位超時排查之前接手過一條EOL產(chǎn)線的刷寫問題現(xiàn)象是十臺車?yán)镉袃扇_刷寫后報“復(fù)位失敗”重試一次就好了。當(dāng)時測試工程師懷疑是ECU軟件不穩(wěn)定拉著我們開會討論。我做的第一件事是看總線日志。對比成功和失敗兩種情況發(fā)現(xiàn)失敗的車在0x11請求發(fā)出后ECU在約30ms時回復(fù)了正響應(yīng)但緊接著在80ms時又發(fā)出了一幀“應(yīng)用就緒”報文。這本身沒問題問題出在診斷儀邏輯上它把“應(yīng)用就緒”報文當(dāng)成了第一個可以重新通信的信號馬上發(fā)送了后續(xù)的0x10 01請求。結(jié)果這個時刻ECU的通信棧剛剛初始化到一半還沒進(jìn)入接收狀態(tài)請求被丟掉了于是診斷儀判定超時。根因是診斷儀在“重新通信判定策略”上寫死了只要有報文就算通信恢復(fù)。后來把判定策略改成“收到診斷響應(yīng)的特定服務(wù)ID且連續(xù)收到2幀才算恢復(fù)”問題就解決了失敗率直接降到零。這個案例給我們的教訓(xùn)是ECU復(fù)位后的恢復(fù)過程不是一個點而是一個窗口診斷儀要在這個窗口里做更穩(wěn)健的握手。6.2 用CANoe腳本自動化測試0x11的要點如果你想在開發(fā)階段把0x11服務(wù)的行為摸透用CANoe或者其他總線工具做自動化測試是最快的路徑。用CAPL寫一個簡單測試思路大致是發(fā)送0x11請求記錄發(fā)送時間然后監(jiān)聽后續(xù)一段時間內(nèi)的全部報文統(tǒng)計ECU從復(fù)位到恢復(fù)通信的時間再做重復(fù)100次的壓力測試。CAPL腳本核心邏輯可以這樣寫on key r { long txTime; // 發(fā)送hardReset請求 diagRequest ECUReset.HardReset(); txTime timenow(); timer1.set(1000); // 1秒內(nèi)持續(xù)監(jiān)聽恢復(fù)報文 } on timer1 { if (communicationRestored) { write(ECU復(fù)位恢復(fù)時間: %d ms, restoreTime - txTime); } else { write(ECU復(fù)位失敗1秒內(nèi)未恢復(fù)通信); } }這只是一個雛形實際測試?yán)镄枰鸦謴?fù)條件的判定做得更精確。我常用的判定方式是在復(fù)位后不斷發(fā)送0x22讀取一個已知數(shù)據(jù)標(biāo)識符比如TesterPresent之外的讀取服務(wù)連續(xù)3次讀到正響應(yīng)才認(rèn)為ECU完全恢復(fù)。單純等應(yīng)用報文容易出現(xiàn)與ECU實際通信能力不一致的情況畢竟ECU有可能發(fā)送應(yīng)用報文但診斷服務(wù)端的接收還不夠。壓力測試時要注意發(fā)送頻率不能太快。建議每次請求間隔在1.5到2秒之間給ECU留夠完成整個復(fù)位和初始化過程的時間。如果間隔太短ECU還沒初始化完就收到下一次復(fù)位請求會累積初始化異常測試結(jié)果反而不真實。6.3 最后分享一個我在實際測試中總結(jié)的小技巧很多ECU的0x11響應(yīng)尤其是hardReset的正響應(yīng)并不總是能穩(wěn)定被診斷儀收到。不要單純?yōu)榱恕澳苁盏巾憫?yīng)”就增加診斷儀的超時時間更可靠的辦法是用“連續(xù)請求分頁模式”來驗證復(fù)位是否成功。比如刷寫完成后診斷儀發(fā)一次0x11然后定時以一定周期比如150ms發(fā)送0x3E只要能等到一次正響應(yīng)說明復(fù)位和通信已經(jīng)恢復(fù)。如果連續(xù)多次0x3E都沒響應(yīng)再去排查ECU的啟動流程也不遲。這個思路很多時候能救急尤其是在產(chǎn)線上快速區(qū)分“ECU真掛了”和“ECU只是恢復(fù)得慢”這兩種情況對減少誤判很有幫助。