詳解：動(dòng)態(tài)控制診斷通訊波特率與實(shí)戰(zhàn)應(yīng)用)
1. 從一次真實(shí)的通訊故障說起為什么我們需要LinkControl前段時(shí)間我在調(diào)試一個(gè)基于CAN總線的控制器時(shí)遇到了一個(gè)讓人頭疼的問題。設(shè)備在實(shí)驗(yàn)室環(huán)境下一切正常診斷會(huì)話切換、讀寫數(shù)據(jù)、刷寫流程都跑得飛快。但一旦裝到實(shí)車上在發(fā)動(dòng)機(jī)啟動(dòng)、大負(fù)載電器工作的瞬間診斷儀就頻繁報(bào)“通訊超時(shí)”。抓取總線報(bào)文一看發(fā)現(xiàn)不是ECU沒回復(fù)而是ECU回復(fù)的報(bào)文被淹沒在了密集的總線負(fù)載中診斷儀沒能在規(guī)定時(shí)間內(nèi)收到完整的響應(yīng)幀。這個(gè)問題本質(zhì)上不是協(xié)議邏輯錯(cuò)誤而是物理層和數(shù)據(jù)鏈路層的通訊參數(shù)與當(dāng)前惡劣的電磁環(huán)境、高總線負(fù)載不匹配。在UDS統(tǒng)一診斷服務(wù)協(xié)議棧中負(fù)責(zé)管理這個(gè)“通訊管道”粗細(xì)和節(jié)奏的服務(wù)就是0x87服務(wù)——LinkControl鏈接控制。簡(jiǎn)單來說UDS協(xié)議就像兩個(gè)人用對(duì)講機(jī)通話。0x10、0x22這些服務(wù)定義了“說什么”比如“請(qǐng)報(bào)告車速”、“清除故障碼”而0x87服務(wù)則是用來調(diào)整“對(duì)講機(jī)本身”的。比如在嘈雜的工地高電磁干擾我們可以把語速放慢、每個(gè)字說清楚降低波特率、增加幀間隔在安靜的辦公室則可以快速交流提高波特率。0x87服務(wù)就是用來動(dòng)態(tài)切換這些底層通訊參數(shù)的指令。對(duì)于嵌入式軟件工程師、汽車診斷測(cè)試工程師以及任何需要深度定制或優(yōu)化UDS通訊的開發(fā)者而言深入理解0x87服務(wù)意味著你不僅能實(shí)現(xiàn)診斷功能更能確保診斷通訊的魯棒性和適應(yīng)性。它是在復(fù)雜車載網(wǎng)絡(luò)環(huán)境中保障診斷這條“生命線”始終可用的關(guān)鍵工具。接下來我將結(jié)合ISO14229-1標(biāo)準(zhǔn)為你徹底拆解0x87服務(wù)的原理、使用方法和那些手冊(cè)上不會(huì)寫的實(shí)戰(zhàn)經(jīng)驗(yàn)。2. 深入原理0x87服務(wù)到底在控制什么“鏈接”在展開具體服務(wù)之前我們必須先厘清一個(gè)核心概念這里的“Link”指的是什么很多人會(huì)誤以為是TCP/IP中的網(wǎng)絡(luò)鏈接但在UDS的語境下尤其是在經(jīng)典的CAN、CAN FD、LIN乃至DoIP基于IP的底層LinkControl控制的是數(shù)據(jù)鏈路層Data Link Layer的通訊屬性。根據(jù)ISO 14229-1標(biāo)準(zhǔn)0x87服務(wù)主要用于在診斷會(huì)話期間請(qǐng)求服務(wù)器ECU切換其與客戶端診斷儀之間用于診斷通訊的網(wǎng)絡(luò)層或數(shù)據(jù)鏈路層參數(shù)。這通常不是指切換整個(gè)ECU的通信矩陣那需要刷寫而是在運(yùn)行時(shí)臨時(shí)調(diào)整診斷通道的“行為模式”。2.1 三種子功能Sub-function詳解0x87服務(wù)包含三個(gè)核心子功能分別對(duì)應(yīng)三種不同的鏈接控制模式### 2.1.1 子功能0x01: verifyBaudrateTransitionWithFixedBaudrate驗(yàn)證固定波特率切換這個(gè)子功能的名字有點(diǎn)長(zhǎng)但其意圖很明確驗(yàn)證ECU是否支持切換到某個(gè)指定的、固定的波特率。請(qǐng)求格式87 01 [Baudrate Identifier]87: 服務(wù)標(biāo)識(shí)符(SID)。01: 子功能表示“驗(yàn)證”。Baudrate Identifier: 一個(gè)字節(jié)的波特率標(biāo)識(shí)符。這是關(guān)鍵這個(gè)標(biāo)識(shí)符的具體數(shù)值如0x01代表125kbps0x02代表250kbps0x03代表500kbps完全由整車廠或ECU供應(yīng)商自定義并在網(wǎng)絡(luò)設(shè)計(jì)文檔如CDD、ODX中定義。UDS標(biāo)準(zhǔn)本身不規(guī)定這個(gè)映射關(guān)系。ECU的響應(yīng)肯定響應(yīng)Positive Response:C7 01 [Baudrate Identifier]。這僅表示“我ECU支持你請(qǐng)求的這個(gè)波特率標(biāo)識(shí)符所代表的波特率”。注意這并不代表ECU已經(jīng)切換了波特率它只是一個(gè)能力查詢。否定響應(yīng)Negative Response: 如果ECU不支持該標(biāo)識(shí)符對(duì)應(yīng)的波特率會(huì)回復(fù)7F 87 33requestOutOfRange或其他相應(yīng)NRC。使用場(chǎng)景在嘗試真正的波特率切換之前先進(jìn)行“探路”。比如診斷儀不確定當(dāng)前ECU是否支持500kbps的診斷波特率可以先發(fā)87 01 03假設(shè)03代表500kbps來詢問。得到肯定響應(yīng)后再使用87 02子功能進(jìn)行實(shí)際切換。這是一種安全、規(guī)范的操作流程。### 2.1.2 子功能0x02: verifyBaudrateTransitionWithSpecificBaudrate驗(yàn)證特定波特率切換這個(gè)子功能比0x01更靈活。它不是查詢預(yù)定義的波特率標(biāo)識(shí)符而是允許診斷儀直接提議一個(gè)具體的波特率數(shù)值以bit/s為單位讓ECU驗(yàn)證是否支持。請(qǐng)求格式87 02 [Baudrate Byte 1] [Baudrate Byte 2] [Baudrate Byte 3]87 02: 服務(wù)和子功能。后跟3個(gè)字節(jié)共同表示一個(gè)24位3字節(jié)的無符號(hào)整數(shù)單位是bit/s比特每秒。例如要提議500000 bit/s (500kbps)這個(gè)數(shù)值的十六進(jìn)制是0x07A120那么三個(gè)字節(jié)就是07 A1 20。請(qǐng)求報(bào)文即為87 02 07 A1 20。ECU的響應(yīng)肯定響應(yīng):C7 02。表示ECU支持切換到此特定波特率。否定響應(yīng): 如果不支持回復(fù)7F 87 33等。使用場(chǎng)景當(dāng)診斷儀需要與一個(gè)波特率信息未知的ECU建立通訊或者需要嘗試非標(biāo)波特率時(shí)使用。它提供了更大的靈活性。但同樣這只是驗(yàn)證不執(zhí)行切換。### 2.1.3 子功能0x03: transitionBaudrate切換波特率這是執(zhí)行實(shí)際操作的子功能。它命令ECU立即將其診斷通訊的波特率切換到之前通過87 01或87 02驗(yàn)證過的波特率。請(qǐng)求格式87 03 [Baudrate Identifier]這里的Baudrate Identifier必須與之前成功驗(yàn)證的請(qǐng)求中的標(biāo)識(shí)符一致。如果是通過87 02驗(yàn)證的這個(gè)標(biāo)識(shí)符通常就是0x00或一個(gè)約定的值具體取決于實(shí)現(xiàn)。ECU的響應(yīng)關(guān)鍵點(diǎn)ECU在成功處理該請(qǐng)求后會(huì)先以當(dāng)前的舊波特率發(fā)送肯定響應(yīng)C7 03。發(fā)送完這個(gè)響應(yīng)后ECU會(huì)立即將其診斷CAN控制器的波特率切換到新的設(shè)定值。此后診斷儀必須將自己的CAN接口波特率也調(diào)整為相同的新值才能繼續(xù)進(jìn)行后續(xù)的診斷通訊。使用場(chǎng)景這是整個(gè)流程的最后一步。在驗(yàn)證通過后執(zhí)行實(shí)際切換以優(yōu)化通訊如從125kbps切換到500kbps以加速刷寫或適配特殊環(huán)境。重要提示波特率切換是一個(gè)高風(fēng)險(xiǎn)操作。一旦切換如果診斷儀沒有同步更改接口設(shè)置將立即丟失與ECU的通訊連接且ECU通常不會(huì)自動(dòng)切回。因此在執(zhí)行87 03前必須有完備的錯(cuò)誤處理和超時(shí)重連機(jī)制。2.2 不僅僅是波特率擴(kuò)展的鏈接控制雖然標(biāo)準(zhǔn)主要描述了波特率控制但“LinkControl”的概念可以擴(kuò)展。在一些具體的實(shí)現(xiàn)或更底層的協(xié)議中如針對(duì)CAN FD它可能還包括對(duì)以下參數(shù)的控制CAN FD 比特率切換控制仲裁階段標(biāo)準(zhǔn)比特率和數(shù)據(jù)階段更高數(shù)據(jù)比特率的速率。幀間隔時(shí)間調(diào)整連續(xù)發(fā)送的CAN幀之間的最小間隔例如用于滿足某些硬件收發(fā)器的要求或降低總線負(fù)載。喚醒模式控制診斷通訊對(duì)ECU休眠/喚醒行為的影響。這些擴(kuò)展功能通常通過自定義子功能0x80-0xFE或利用87 02子功能傳遞更復(fù)雜的數(shù)據(jù)參數(shù)來實(shí)現(xiàn)。具體需要查閱對(duì)應(yīng)ECU的診斷規(guī)范。3. 實(shí)戰(zhàn)演練一個(gè)完整的波特率切換流程與CAPL腳本示例理論說得再多不如一行代碼。下面我將以最常見的場(chǎng)景——在CANoe/CANalyzer環(huán)境中使用CAPL腳本實(shí)現(xiàn)“驗(yàn)證并切換至500kbps”——為例展示完整的操作流程和注意事項(xiàng)。我們假設(shè)當(dāng)前診斷波特率為125kbps標(biāo)識(shí)符0x01。目標(biāo)波特率為500kbps標(biāo)識(shí)符0x03。診斷請(qǐng)求ID物理尋址0x7E0診斷響應(yīng)ID0x7E83.1 步驟分解與CAPL實(shí)現(xiàn)步驟一連接與初始會(huì)話建立首先你需要確保診斷儀與ECU在默認(rèn)波特率下已經(jīng)建立了通訊并且進(jìn)入了非默認(rèn)會(huì)話例如擴(kuò)展診斷會(huì)話0x10 03因?yàn)?x87服務(wù)通常需要在非默認(rèn)會(huì)話下才被啟用。// CAPL腳本示例 - 初始化與建立會(huì)話 variables { // 定義標(biāo)識(shí)符 const long DEFAULT_BAUD_ID 0x01; // 125kbps const long TARGET_BAUD_ID 0x03; // 500kbps byte positiveResponse[4096]; dword responseLength; } on start { // 1. 確保CAN通道波特率已設(shè)置為當(dāng)前波特率125kbps canSetBaudrate(1, 125); // 假設(shè)通道1125代表125kbps // 2. 發(fā)送10 03進(jìn)入擴(kuò)展會(huì)話 byte request_10_03[] {0x10, 0x03}; diagSendRequest(request_10_03); // 等待并檢查肯定響應(yīng) 50 03 // ... (省略響應(yīng)檢查代碼) }步驟二驗(yàn)證目標(biāo)波特率使用子功能0x01在會(huì)話建立成功后先驗(yàn)證ECU是否支持我們想要切換的波特率標(biāo)識(shí)符。// 函數(shù)驗(yàn)證波特率 int verifyBaudrate(byte baudId) { byte request[3]; request[0] 0x87; // SID request[1] 0x01; // Sub-function: verifyBaudrateTransitionWithFixedBaudrate request[2] baudId; // Baudrate Identifier // 發(fā)送請(qǐng)求 diagSendRequest(request); // 設(shè)置超時(shí)等待響應(yīng) setTimer(udsTimeout, 2000); // 2秒超時(shí) // 在on diagResponse事件中處理響應(yīng) // 如果收到 C7 01 [baudId]返回1成功 // 如果收到 7F 87 33返回0不支持 // 如果超時(shí)返回-1通訊失敗 // ... (具體響應(yīng)處理邏輯需在 on diagResponse 中實(shí)現(xiàn)) return waitForResponse(); // 假設(shè)此函數(shù)阻塞等待并返回結(jié)果 } on key v { // 按鍵盤v觸發(fā)驗(yàn)證 int result verifyBaudrate(TARGET_BAUD_ID); if (result 1) { write(驗(yàn)證成功ECU支持切換到波特率標(biāo)識(shí)符 0x%02X, TARGET_BAUD_ID); } else if (result 0) { write(驗(yàn)證失敗ECU不支持該波特率標(biāo)識(shí)符。); } else { write(驗(yàn)證超時(shí)通訊異常。); } }步驟三執(zhí)行波特率切換使用子功能0x03驗(yàn)證成功后執(zhí)行實(shí)際的切換操作。這是最關(guān)鍵的步驟需要處理好切換前后的波特率同步。// 函數(shù)執(zhí)行波特率切換 int transitionBaudrate(byte baudId) { byte request[3]; request[0] 0x87; request[1] 0x03; // Sub-function: transitionBaudrate request[2] baudId; diagSendRequest(request); // 特別注意 // ECU會(huì)以舊波特率回復(fù) C7 03然后立即切換。 // 因此我們需要在發(fā)送請(qǐng)求后立即準(zhǔn)備切換診斷儀端的CAN接口波特率。 // 通常在確認(rèn)收到肯定響應(yīng)后或在一個(gè)極短的確定延時(shí)后進(jìn)行切換。 setTimer(switchTimer, 50); // 假設(shè)50ms后執(zhí)行切換確保已收到響應(yīng) return 1; } on timer switchTimer { // 停止當(dāng)前測(cè)量 stopMeasurement(); // 切換CAN通道的波特率設(shè)置 // 注意這里的數(shù)值需要根據(jù) TARGET_BAUD_ID 的實(shí)際含義來設(shè)置 // 假設(shè) 0x03 對(duì)應(yīng) 500kbps canSetBaudrate(1, 500); // 將通道1波特率改為500kbps write(診斷儀端波特率已切換至500kbps。); // 重新啟動(dòng)測(cè)量 startMeasurement(); // 可選發(fā)送一個(gè)簡(jiǎn)單的診斷請(qǐng)求如0x3E 80 保持會(huì)話來測(cè)試新波特率下的通訊 byte testerPresent[] {0x3E, 0x80}; diagSendRequest(testerPresent); write(正在測(cè)試新波特率下的通訊...); } on diagResponse 0x7E8 { // 處理0x87服務(wù)的響應(yīng) if (this.byte(0) 0xC7 this.byte(1) 0x03) { write(收到波特率切換肯定響應(yīng)。ECU即將切換波特率。); // 可以在這里設(shè)置一個(gè)標(biāo)志通知switchTimer可以安全執(zhí)行 } // ... 其他響應(yīng)處理 }步驟四異常處理與回退機(jī)制必須考慮切換失敗的情況。例如發(fā)送87 03后沒有收到響應(yīng)可能ECU切換異?；蛟\斷儀切換時(shí)機(jī)不對(duì)。// 在全局變量中定義一個(gè)重試機(jī)制和回退波特率 variables { int baudSwitchRetryCount 0; const int MAX_RETRY 3; } // 修改 transitionBaudrate 函數(shù)或在其調(diào)用處增加重試邏輯 on key t { // 按鍵盤t觸發(fā)切換 while (baudSwitchRetryCount MAX_RETRY) { if (executeTransition() SUCCESS) { // 假設(shè)的封裝函數(shù) baudSwitchRetryCount 0; break; } else { baudSwitchRetryCount; write(切換失敗第%d次重試。, baudSwitchRetryCount); // 重要在重試前先將診斷儀波特率切回已知可用的波特率如初始的125kbps canSetBaudrate(1, 125); testConnection(); // 測(cè)試連接是否恢復(fù) delay(1000); } } if (baudSwitchRetryCount MAX_RETRY) { write(波特率切換徹底失敗請(qǐng)檢查硬件連接或ECU配置。); // 嘗試最終回退到默認(rèn)波特率 canSetBaudrate(1, 125); } }3.2 使用CANdelaStudio (CDD) 或 ODX 文件在實(shí)際工程中波特率標(biāo)識(shí)符(Baudrate Identifier)的映射關(guān)系、0x87服務(wù)是否支持、在哪些會(huì)話下支持等信息都定義在ECU的診斷數(shù)據(jù)庫文件CDD或ODX中。在CANoe中你可以通過Diagnostics/ISO TP配置窗口導(dǎo)入這些文件CAPL腳本可以通過Diag對(duì)象以更安全、便捷的方式調(diào)用服務(wù)而無需硬編碼SID和子功能。// 使用Diag對(duì)象調(diào)用更推薦 on key c { DiagRequest drvReq; // 診斷請(qǐng)求對(duì)象 DiagResponse drvResp; // 診斷響應(yīng)對(duì)象 // 通過服務(wù)名稱獲取請(qǐng)求對(duì)象需CDD/ODX支持 drvReq DiagGetPrimitiveDataByService(LinkControl); // 設(shè)置子功能和參數(shù) drvReq.SetSubFunction(0x01); // verify drvReq.SetParameter(BaudrateIdentifier, TARGET_BAUD_ID); // 發(fā)送并等待響應(yīng) diagSendRequest(drvReq); }這種方式避免了記憶具體的SID并且參數(shù)名更直觀依賴于數(shù)據(jù)庫的完整性。4. 高階應(yīng)用、常見陷阱與調(diào)試技巧掌握了基礎(chǔ)流程我們來看看那些容易踩坑的地方和一些高級(jí)用法。4.1 為什么我的0x87服務(wù)請(qǐng)求總是被否定NRC 0x22這是最常見的問題之一。NRC 0x22代表“conditionsNotCorrect”。請(qǐng)按以下順序排查會(huì)話狀態(tài)確認(rèn)ECU是否處于支持0x87服務(wù)的診斷會(huì)話中通常是編程會(huì)話0x10 02或擴(kuò)展診斷會(huì)話0x10 03。在默認(rèn)會(huì)話0x10 01下絕大多數(shù)安全相關(guān)和配置服務(wù)都是被禁止的。解決方案先發(fā)送10 02或10 03進(jìn)入相應(yīng)會(huì)話。安全狀態(tài)0x87服務(wù)可能被定義為“安全相關(guān)服務(wù)”。這意味著在執(zhí)行前必須通過0x27服務(wù)SecurityAccess完成安全解鎖獲得足夠的權(quán)限等級(jí)。解決方案檢查診斷規(guī)范確認(rèn)是否需要先進(jìn)行0x27服務(wù)種子密鑰交換。依賴條件有些ECU要求在執(zhí)行波特率切換前必須滿足特定條件如“車輛速度為零”、“點(diǎn)火開關(guān)ON但發(fā)動(dòng)機(jī)OFF”等。這些條件不滿足也會(huì)返回0x22。解決方案仔細(xì)閱讀ECU的詳細(xì)診斷需求規(guī)范。4.2 切換波特率后“失聯(lián)”了怎么辦這是最令人緊張的狀況。發(fā)送87 03后診斷儀再也收不到任何ECU的報(bào)文。原因診斷儀沒有在ECU切換波特率后同步更改自身CAN接口的波特率設(shè)置。兩者波特率不匹配自然無法通訊。應(yīng)急恢復(fù)手動(dòng)重設(shè)在CANoe/CANalyzer的硬件配置界面手動(dòng)將對(duì)應(yīng)CAN通道的波特率改回原來的值或嘗試其他可能的值。腳本自動(dòng)回退如3.1節(jié)所述在腳本中實(shí)現(xiàn)超時(shí)檢測(cè)。如果發(fā)送87 03后在預(yù)定時(shí)間內(nèi)如100ms沒有收到任何來自ECU的報(bào)文不限于診斷響應(yīng)任何ECU發(fā)送的CAN幀則自動(dòng)將診斷儀波特率切回上一個(gè)已知有效的值并嘗試發(fā)送10 01回到默認(rèn)會(huì)話。硬件復(fù)位最徹底的方法給ECU重新上電。ECU在冷啟動(dòng)后通常會(huì)加載默認(rèn)的通信配置包括默認(rèn)的診斷波特率。4.3 0x87服務(wù)在CAN FD和DoIP中的應(yīng)用在CAN FD中CAN FD允許在數(shù)據(jù)階段使用更高的比特率。0x87服務(wù)可以用來動(dòng)態(tài)控制這個(gè)數(shù)據(jù)階段比特率。例如在刷寫大量數(shù)據(jù)時(shí)切換到更高的數(shù)據(jù)比特率如2Mbps或5Mbps以顯著提升傳輸效率。此時(shí)請(qǐng)求參數(shù)可能需要包含兩個(gè)波特率值仲裁段波特率和數(shù)據(jù)段波特率。在DoIP (Diagnostic over IP) 中雖然DoIP底層是TCP/IP但“鏈接控制”的概念依然存在。這里的0x87服務(wù)可能被用來控制DoIP實(shí)體車輛網(wǎng)關(guān)與測(cè)試設(shè)備之間的TCP數(shù)據(jù)吞吐率、激活/停用DoIP路由或控制車輛發(fā)現(xiàn)過程。其參數(shù)和語義與CAN環(huán)境完全不同需要參考ISO 13400DoIP和具體的實(shí)現(xiàn)規(guī)范。4.4 調(diào)試技巧使用CANoe的Trace和Graphics窗口Trace窗口過濾顯示0x7E0和0x7E8的報(bào)文。清晰看到87 01請(qǐng)求和C7 01響應(yīng)以及87 03請(qǐng)求和C7 03響應(yīng)。確認(rèn)時(shí)序和內(nèi)容是否正確。Graphics窗口創(chuàng)建一個(gè)信號(hào)用來顯示“當(dāng)前診斷波特率”。在CAPL腳本中每次成功切換波特率后更新這個(gè)信號(hào)的值。這樣可以在圖形上直觀地看到波特率切換的發(fā)生時(shí)刻便于與總線負(fù)載率、錯(cuò)誤幀等信號(hào)進(jìn)行關(guān)聯(lián)分析?？偩€負(fù)載率觀察在執(zhí)行切換前后觀察總線負(fù)載率的變化。從低波特率切換到高波特率在發(fā)送相同數(shù)量報(bào)文的情況下負(fù)載率會(huì)降低因?yàn)槊勘忍貢r(shí)間變短單位時(shí)間能發(fā)送更多比特。這可以間接驗(yàn)證切換是否真正生效。5. 與其他服務(wù)的協(xié)同構(gòu)建健壯的診斷序列0x87服務(wù)很少孤立使用它總是嵌入在一個(gè)更復(fù)雜的診斷操作序列中尤其是ECU軟件刷寫Programming流程。理解它在這個(gè)序列中的位置至關(guān)重要。一個(gè)簡(jiǎn)化的、包含波特率切換的刷寫前置流程可能如下進(jìn)入擴(kuò)展會(huì)話10 03安全訪問解鎖27 01- 獲取種子(Seed) - 計(jì)算密鑰(Key) -27 02 [Key]這里可能就涉及到uds capl 調(diào)用dll uds算seedkey這個(gè)熱搜詞中的場(chǎng)景即用CAPL調(diào)用外部DLL來計(jì)算密鑰。鏈接控制驗(yàn)證波特率87 01 [HighSpeedBaudID]- 響應(yīng)C7 01鏈接控制切換波特率87 03 [HighSpeedBaudID]- 響應(yīng)C7 03診斷儀在收到C7 03后立即更改CAN接口波特率設(shè)置。測(cè)試新鏈接發(fā)送3E 80TesterPresent或22 [DID]讀取數(shù)據(jù)確認(rèn)在新波特率下通訊正常。進(jìn)入編程會(huì)話10 02注意有些ECU要求在編程會(huì)話下才能進(jìn)行后續(xù)的34、36、37服務(wù)。關(guān)閉DTC設(shè)置85 02控制DTC設(shè)置通信控制28 03 [控制類型]可能禁止非診斷報(bào)文降低總線負(fù)載為高速刷寫讓出帶寬。開始刷寫流程34請(qǐng)求下載36傳輸數(shù)據(jù)37請(qǐng)求退出傳輸...在這個(gè)序列中0x87服務(wù)步驟34是提升后續(xù)34/36/37服務(wù)數(shù)據(jù)傳輸效率的關(guān)鍵準(zhǔn)備步驟。如果沒有切換到更高波特率刷寫一個(gè)幾兆字節(jié)的軟件包將耗費(fèi)難以忍受的時(shí)間。6. 測(cè)試考量如何全面測(cè)試0x87服務(wù)作為測(cè)試工程師針對(duì)0x87服務(wù)不能只測(cè)“正常流程通過”。以下是一些關(guān)鍵的測(cè)試點(diǎn)呼應(yīng)了“最全面的uds測(cè)試用例”這個(gè)需求正常功能測(cè)試在支持的會(huì)話如擴(kuò)展會(huì)話、編程會(huì)話下驗(yàn)證87 01和87 03序列成功執(zhí)行且切換后通訊正常。驗(yàn)證87 02子功能如果支持可以指定任意波特率并成功切換。無效參數(shù)測(cè)試發(fā)送87 01或87 03時(shí)使用未定義的Baudrate Identifier如0xFF應(yīng)返回NRC0x31requestOutOfRange。發(fā)送87 02時(shí)使用ECU不支持的波特率值如一個(gè)極低或極高的值應(yīng)返回NRC0x33securityAccessDenied? 這里更可能是0x31或自定義NRC具體看規(guī)范。條件不滿足測(cè)試在默認(rèn)會(huì)話下發(fā)送0x87服務(wù)請(qǐng)求應(yīng)返回NRC0x7EserviceNotSupportedInActiveSession或0x22。在未通過安全訪問時(shí)發(fā)送請(qǐng)求如果該服務(wù)受安全保護(hù)應(yīng)返回NRC0x33。在車輛行駛狀態(tài)模擬車速信號(hào)0下發(fā)送請(qǐng)求應(yīng)返回NRC0x22。序列錯(cuò)誤測(cè)試不經(jīng)過87 01驗(yàn)證直接發(fā)送87 03請(qǐng)求切換ECU應(yīng)如何處理可能返回NRC0x24-requestSequenceError或直接拒絕。連續(xù)兩次發(fā)送87 03請(qǐng)求切換波特率第二次請(qǐng)求應(yīng)如何處理異常與恢復(fù)測(cè)試中斷測(cè)試在ECU回復(fù)C7 03后診斷儀延遲切換自身波特率如延遲1秒。驗(yàn)證ECU在此期間是否還能處理以舊波特率發(fā)送的請(qǐng)求通常不能因?yàn)镋CU已經(jīng)切換?；謴?fù)測(cè)試執(zhí)行87 03切換后強(qiáng)制讓診斷儀與ECU“失聯(lián)”。然后給ECU重新上電驗(yàn)證其診斷波特率是否恢復(fù)為默認(rèn)值并能用默認(rèn)波特率重新建立連接。壓力測(cè)試在極高總線負(fù)載80%的情況下執(zhí)行波特率切換操作觀察是否會(huì)出現(xiàn)錯(cuò)誤幀或切換失敗。邊界與性能測(cè)試測(cè)試支持的最小和最大波特率。測(cè)量切換波特率操作本身所耗費(fèi)的時(shí)間從發(fā)送87 03到在新波特率下成功完成一次診斷通信的時(shí)間。這個(gè)時(shí)間對(duì)于刷寫流程的整體耗時(shí)評(píng)估很重要。通過以上這些測(cè)試你才能稱得上對(duì)0x87服務(wù)進(jìn)行了“全面”的覆蓋確保該功能在車輛各種復(fù)雜環(huán)境下都能穩(wěn)定可靠地工作。理解并掌握LinkControl服務(wù)是你從“會(huì)用UDS”到“精通UDS”道路上必不可少的一步。 UDS 0x87 LinkControl服務(wù)詳解：動(dòng)態(tài)控制診斷通訊波特率與實(shí)戰(zhàn)應(yīng)用
1. 從一次真實(shí)的通訊故障說起為什么我們需要LinkControl前段時(shí)間我在調(diào)試一個(gè)基于CAN總線的控制器時(shí)遇到了一個(gè)讓人頭疼的問題。設(shè)備在實(shí)驗(yàn)室環(huán)境下一切正常診斷會(huì)話切換、讀寫數(shù)據(jù)、刷寫流程都跑得飛快。但一旦裝到實(shí)車上在發(fā)動(dòng)機(jī)啟動(dòng)、大負(fù)載電器工作的瞬間診斷儀就頻繁報(bào)“通訊超時(shí)”。抓取總線報(bào)文一看發(fā)現(xiàn)不是ECU沒回復(fù)而是ECU回復(fù)的報(bào)文被淹沒在了密集的總線負(fù)載中診斷儀沒能在規(guī)定時(shí)間內(nèi)收到完整的響應(yīng)幀。這個(gè)問題本質(zhì)上不是協(xié)議邏輯錯(cuò)誤而是物理層和數(shù)據(jù)鏈路層的通訊參數(shù)與當(dāng)前惡劣的電磁環(huán)境、高總線負(fù)載不匹配。在UDS統(tǒng)一診斷服務(wù)協(xié)議棧中負(fù)責(zé)管理這個(gè)“通訊管道”粗細(xì)和節(jié)奏的服務(wù)就是0x87服務(wù)——LinkControl鏈接控制。簡(jiǎn)單來說UDS協(xié)議就像兩個(gè)人用對(duì)講機(jī)通話。0x10、0x22這些服務(wù)定義了“說什么”比如“請(qǐng)報(bào)告車速”、“清除故障碼”而0x87服務(wù)則是用來調(diào)整“對(duì)講機(jī)本身”的。比如在嘈雜的工地高電磁干擾我們可以把語速放慢、每個(gè)字說清楚降低波特率、增加幀間隔在安靜的辦公室則可以快速交流提高波特率。0x87服務(wù)就是用來動(dòng)態(tài)切換這些底層通訊參數(shù)的指令。對(duì)于嵌入式軟件工程師、汽車診斷測(cè)試工程師以及任何需要深度定制或優(yōu)化UDS通訊的開發(fā)者而言深入理解0x87服務(wù)意味著你不僅能實(shí)現(xiàn)診斷功能更能確保診斷通訊的魯棒性和適應(yīng)性。它是在復(fù)雜車載網(wǎng)絡(luò)環(huán)境中保障診斷這條“生命線”始終可用的關(guān)鍵工具。接下來我將結(jié)合ISO14229-1標(biāo)準(zhǔn)為你徹底拆解0x87服務(wù)的原理、使用方法和那些手冊(cè)上不會(huì)寫的實(shí)戰(zhàn)經(jīng)驗(yàn)。2. 深入原理0x87服務(wù)到底在控制什么“鏈接”在展開具體服務(wù)之前我們必須先厘清一個(gè)核心概念這里的“Link”指的是什么很多人會(huì)誤以為是TCP/IP中的網(wǎng)絡(luò)鏈接但在UDS的語境下尤其是在經(jīng)典的CAN、CAN FD、LIN乃至DoIP基于IP的底層LinkControl控制的是數(shù)據(jù)鏈路層Data Link Layer的通訊屬性。根據(jù)ISO 14229-1標(biāo)準(zhǔn)0x87服務(wù)主要用于在診斷會(huì)話期間請(qǐng)求服務(wù)器ECU切換其與客戶端診斷儀之間用于診斷通訊的網(wǎng)絡(luò)層或數(shù)據(jù)鏈路層參數(shù)。這通常不是指切換整個(gè)ECU的通信矩陣那需要刷寫而是在運(yùn)行時(shí)臨時(shí)調(diào)整診斷通道的“行為模式”。2.1 三種子功能Sub-function詳解0x87服務(wù)包含三個(gè)核心子功能分別對(duì)應(yīng)三種不同的鏈接控制模式### 2.1.1 子功能0x01: verifyBaudrateTransitionWithFixedBaudrate驗(yàn)證固定波特率切換這個(gè)子功能的名字有點(diǎn)長(zhǎng)但其意圖很明確驗(yàn)證ECU是否支持切換到某個(gè)指定的、固定的波特率。請(qǐng)求格式87 01 [Baudrate Identifier]87: 服務(wù)標(biāo)識(shí)符(SID)。01: 子功能表示“驗(yàn)證”。Baudrate Identifier: 一個(gè)字節(jié)的波特率標(biāo)識(shí)符。這是關(guān)鍵這個(gè)標(biāo)識(shí)符的具體數(shù)值如0x01代表125kbps0x02代表250kbps0x03代表500kbps完全由整車廠或ECU供應(yīng)商自定義并在網(wǎng)絡(luò)設(shè)計(jì)文檔如CDD、ODX中定義。UDS標(biāo)準(zhǔn)本身不規(guī)定這個(gè)映射關(guān)系。ECU的響應(yīng)肯定響應(yīng)Positive Response:C7 01 [Baudrate Identifier]。這僅表示“我ECU支持你請(qǐng)求的這個(gè)波特率標(biāo)識(shí)符所代表的波特率”。注意這并不代表ECU已經(jīng)切換了波特率它只是一個(gè)能力查詢。否定響應(yīng)Negative Response: 如果ECU不支持該標(biāo)識(shí)符對(duì)應(yīng)的波特率會(huì)回復(fù)7F 87 33requestOutOfRange或其他相應(yīng)NRC。使用場(chǎng)景在嘗試真正的波特率切換之前先進(jìn)行“探路”。比如診斷儀不確定當(dāng)前ECU是否支持500kbps的診斷波特率可以先發(fā)87 01 03假設(shè)03代表500kbps來詢問。得到肯定響應(yīng)后再使用87 02子功能進(jìn)行實(shí)際切換。這是一種安全、規(guī)范的操作流程。### 2.1.2 子功能0x02: verifyBaudrateTransitionWithSpecificBaudrate驗(yàn)證特定波特率切換這個(gè)子功能比0x01更靈活。它不是查詢預(yù)定義的波特率標(biāo)識(shí)符而是允許診斷儀直接提議一個(gè)具體的波特率數(shù)值以bit/s為單位讓ECU驗(yàn)證是否支持。請(qǐng)求格式87 02 [Baudrate Byte 1] [Baudrate Byte 2] [Baudrate Byte 3]87 02: 服務(wù)和子功能。后跟3個(gè)字節(jié)共同表示一個(gè)24位3字節(jié)的無符號(hào)整數(shù)單位是bit/s比特每秒。例如要提議500000 bit/s (500kbps)這個(gè)數(shù)值的十六進(jìn)制是0x07A120那么三個(gè)字節(jié)就是07 A1 20。請(qǐng)求報(bào)文即為87 02 07 A1 20。ECU的響應(yīng)肯定響應(yīng):C7 02。表示ECU支持切換到此特定波特率。否定響應(yīng): 如果不支持回復(fù)7F 87 33等。使用場(chǎng)景當(dāng)診斷儀需要與一個(gè)波特率信息未知的ECU建立通訊或者需要嘗試非標(biāo)波特率時(shí)使用。它提供了更大的靈活性。但同樣這只是驗(yàn)證不執(zhí)行切換。### 2.1.3 子功能0x03: transitionBaudrate切換波特率這是執(zhí)行實(shí)際操作的子功能。它命令ECU立即將其診斷通訊的波特率切換到之前通過87 01或87 02驗(yàn)證過的波特率。請(qǐng)求格式87 03 [Baudrate Identifier]這里的Baudrate Identifier必須與之前成功驗(yàn)證的請(qǐng)求中的標(biāo)識(shí)符一致。如果是通過87 02驗(yàn)證的這個(gè)標(biāo)識(shí)符通常就是0x00或一個(gè)約定的值具體取決于實(shí)現(xiàn)。ECU的響應(yīng)關(guān)鍵點(diǎn)ECU在成功處理該請(qǐng)求后會(huì)先以當(dāng)前的舊波特率發(fā)送肯定響應(yīng)C7 03。發(fā)送完這個(gè)響應(yīng)后ECU會(huì)立即將其診斷CAN控制器的波特率切換到新的設(shè)定值。此后診斷儀必須將自己的CAN接口波特率也調(diào)整為相同的新值才能繼續(xù)進(jìn)行后續(xù)的診斷通訊。使用場(chǎng)景這是整個(gè)流程的最后一步。在驗(yàn)證通過后執(zhí)行實(shí)際切換以優(yōu)化通訊如從125kbps切換到500kbps以加速刷寫或適配特殊環(huán)境。重要提示波特率切換是一個(gè)高風(fēng)險(xiǎn)操作。一旦切換如果診斷儀沒有同步更改接口設(shè)置將立即丟失與ECU的通訊連接且ECU通常不會(huì)自動(dòng)切回。因此在執(zhí)行87 03前必須有完備的錯(cuò)誤處理和超時(shí)重連機(jī)制。2.2 不僅僅是波特率擴(kuò)展的鏈接控制雖然標(biāo)準(zhǔn)主要描述了波特率控制但“LinkControl”的概念可以擴(kuò)展。在一些具體的實(shí)現(xiàn)或更底層的協(xié)議中如針對(duì)CAN FD它可能還包括對(duì)以下參數(shù)的控制CAN FD 比特率切換控制仲裁階段標(biāo)準(zhǔn)比特率和數(shù)據(jù)階段更高數(shù)據(jù)比特率的速率。幀間隔時(shí)間調(diào)整連續(xù)發(fā)送的CAN幀之間的最小間隔例如用于滿足某些硬件收發(fā)器的要求或降低總線負(fù)載。喚醒模式控制診斷通訊對(duì)ECU休眠/喚醒行為的影響。這些擴(kuò)展功能通常通過自定義子功能0x80-0xFE或利用87 02子功能傳遞更復(fù)雜的數(shù)據(jù)參數(shù)來實(shí)現(xiàn)。具體需要查閱對(duì)應(yīng)ECU的診斷規(guī)范。3. 實(shí)戰(zhàn)演練一個(gè)完整的波特率切換流程與CAPL腳本示例理論說得再多不如一行代碼。下面我將以最常見的場(chǎng)景——在CANoe/CANalyzer環(huán)境中使用CAPL腳本實(shí)現(xiàn)“驗(yàn)證并切換至500kbps”——為例展示完整的操作流程和注意事項(xiàng)。我們假設(shè)當(dāng)前診斷波特率為125kbps標(biāo)識(shí)符0x01。目標(biāo)波特率為500kbps標(biāo)識(shí)符0x03。診斷請(qǐng)求ID物理尋址0x7E0診斷響應(yīng)ID0x7E83.1 步驟分解與CAPL實(shí)現(xiàn)步驟一連接與初始會(huì)話建立首先你需要確保診斷儀與ECU在默認(rèn)波特率下已經(jīng)建立了通訊并且進(jìn)入了非默認(rèn)會(huì)話例如擴(kuò)展診斷會(huì)話0x10 03因?yàn)?x87服務(wù)通常需要在非默認(rèn)會(huì)話下才被啟用。// CAPL腳本示例 - 初始化與建立會(huì)話 variables { // 定義標(biāo)識(shí)符 const long DEFAULT_BAUD_ID 0x01; // 125kbps const long TARGET_BAUD_ID 0x03; // 500kbps byte positiveResponse[4096]; dword responseLength; } on start { // 1. 確保CAN通道波特率已設(shè)置為當(dāng)前波特率125kbps canSetBaudrate(1, 125); // 假設(shè)通道1125代表125kbps // 2. 發(fā)送10 03進(jìn)入擴(kuò)展會(huì)話 byte request_10_03[] {0x10, 0x03}; diagSendRequest(request_10_03); // 等待并檢查肯定響應(yīng) 50 03 // ... (省略響應(yīng)檢查代碼) }步驟二驗(yàn)證目標(biāo)波特率使用子功能0x01在會(huì)話建立成功后先驗(yàn)證ECU是否支持我們想要切換的波特率標(biāo)識(shí)符。// 函數(shù)驗(yàn)證波特率 int verifyBaudrate(byte baudId) { byte request[3]; request[0] 0x87; // SID request[1] 0x01; // Sub-function: verifyBaudrateTransitionWithFixedBaudrate request[2] baudId; // Baudrate Identifier // 發(fā)送請(qǐng)求 diagSendRequest(request); // 設(shè)置超時(shí)等待響應(yīng) setTimer(udsTimeout, 2000); // 2秒超時(shí) // 在on diagResponse事件中處理響應(yīng) // 如果收到 C7 01 [baudId]返回1成功 // 如果收到 7F 87 33返回0不支持 // 如果超時(shí)返回-1通訊失敗 // ... (具體響應(yīng)處理邏輯需在 on diagResponse 中實(shí)現(xiàn)) return waitForResponse(); // 假設(shè)此函數(shù)阻塞等待并返回結(jié)果 } on key v { // 按鍵盤v觸發(fā)驗(yàn)證 int result verifyBaudrate(TARGET_BAUD_ID); if (result 1) { write(驗(yàn)證成功ECU支持切換到波特率標(biāo)識(shí)符 0x%02X, TARGET_BAUD_ID); } else if (result 0) { write(驗(yàn)證失敗ECU不支持該波特率標(biāo)識(shí)符。); } else { write(驗(yàn)證超時(shí)通訊異常。); } }步驟三執(zhí)行波特率切換使用子功能0x03驗(yàn)證成功后執(zhí)行實(shí)際的切換操作。這是最關(guān)鍵的步驟需要處理好切換前后的波特率同步。// 函數(shù)執(zhí)行波特率切換 int transitionBaudrate(byte baudId) { byte request[3]; request[0] 0x87; request[1] 0x03; // Sub-function: transitionBaudrate request[2] baudId; diagSendRequest(request); // 特別注意 // ECU會(huì)以舊波特率回復(fù) C7 03然后立即切換。 // 因此我們需要在發(fā)送請(qǐng)求后立即準(zhǔn)備切換診斷儀端的CAN接口波特率。 // 通常在確認(rèn)收到肯定響應(yīng)后或在一個(gè)極短的確定延時(shí)后進(jìn)行切換。 setTimer(switchTimer, 50); // 假設(shè)50ms后執(zhí)行切換確保已收到響應(yīng) return 1; } on timer switchTimer { // 停止當(dāng)前測(cè)量 stopMeasurement(); // 切換CAN通道的波特率設(shè)置 // 注意這里的數(shù)值需要根據(jù) TARGET_BAUD_ID 的實(shí)際含義來設(shè)置 // 假設(shè) 0x03 對(duì)應(yīng) 500kbps canSetBaudrate(1, 500); // 將通道1波特率改為500kbps write(診斷儀端波特率已切換至500kbps。); // 重新啟動(dòng)測(cè)量 startMeasurement(); // 可選發(fā)送一個(gè)簡(jiǎn)單的診斷請(qǐng)求如0x3E 80 保持會(huì)話來測(cè)試新波特率下的通訊 byte testerPresent[] {0x3E, 0x80}; diagSendRequest(testerPresent); write(正在測(cè)試新波特率下的通訊...); } on diagResponse 0x7E8 { // 處理0x87服務(wù)的響應(yīng) if (this.byte(0) 0xC7 this.byte(1) 0x03) { write(收到波特率切換肯定響應(yīng)。ECU即將切換波特率。); // 可以在這里設(shè)置一個(gè)標(biāo)志通知switchTimer可以安全執(zhí)行 } // ... 其他響應(yīng)處理 }步驟四異常處理與回退機(jī)制必須考慮切換失敗的情況。例如發(fā)送87 03后沒有收到響應(yīng)可能ECU切換異?；蛟\斷儀切換時(shí)機(jī)不對(duì)。// 在全局變量中定義一個(gè)重試機(jī)制和回退波特率 variables { int baudSwitchRetryCount 0; const int MAX_RETRY 3; } // 修改 transitionBaudrate 函數(shù)或在其調(diào)用處增加重試邏輯 on key t { // 按鍵盤t觸發(fā)切換 while (baudSwitchRetryCount MAX_RETRY) { if (executeTransition() SUCCESS) { // 假設(shè)的封裝函數(shù) baudSwitchRetryCount 0; break; } else { baudSwitchRetryCount; write(切換失敗第%d次重試。, baudSwitchRetryCount); // 重要在重試前先將診斷儀波特率切回已知可用的波特率如初始的125kbps canSetBaudrate(1, 125); testConnection(); // 測(cè)試連接是否恢復(fù) delay(1000); } } if (baudSwitchRetryCount MAX_RETRY) { write(波特率切換徹底失敗請(qǐng)檢查硬件連接或ECU配置。); // 嘗試最終回退到默認(rèn)波特率 canSetBaudrate(1, 125); } }3.2 使用CANdelaStudio (CDD) 或 ODX 文件在實(shí)際工程中波特率標(biāo)識(shí)符(Baudrate Identifier)的映射關(guān)系、0x87服務(wù)是否支持、在哪些會(huì)話下支持等信息都定義在ECU的診斷數(shù)據(jù)庫文件CDD或ODX中。在CANoe中你可以通過Diagnostics/ISO TP配置窗口導(dǎo)入這些文件CAPL腳本可以通過Diag對(duì)象以更安全、便捷的方式調(diào)用服務(wù)而無需硬編碼SID和子功能。// 使用Diag對(duì)象調(diào)用更推薦 on key c { DiagRequest drvReq; // 診斷請(qǐng)求對(duì)象 DiagResponse drvResp; // 診斷響應(yīng)對(duì)象 // 通過服務(wù)名稱獲取請(qǐng)求對(duì)象需CDD/ODX支持 drvReq DiagGetPrimitiveDataByService(LinkControl); // 設(shè)置子功能和參數(shù) drvReq.SetSubFunction(0x01); // verify drvReq.SetParameter(BaudrateIdentifier, TARGET_BAUD_ID); // 發(fā)送并等待響應(yīng) diagSendRequest(drvReq); }這種方式避免了記憶具體的SID并且參數(shù)名更直觀依賴于數(shù)據(jù)庫的完整性。4. 高階應(yīng)用、常見陷阱與調(diào)試技巧掌握了基礎(chǔ)流程我們來看看那些容易踩坑的地方和一些高級(jí)用法。4.1 為什么我的0x87服務(wù)請(qǐng)求總是被否定NRC 0x22這是最常見的問題之一。NRC 0x22代表“conditionsNotCorrect”。請(qǐng)按以下順序排查會(huì)話狀態(tài)確認(rèn)ECU是否處于支持0x87服務(wù)的診斷會(huì)話中通常是編程會(huì)話0x10 02或擴(kuò)展診斷會(huì)話0x10 03。在默認(rèn)會(huì)話0x10 01下絕大多數(shù)安全相關(guān)和配置服務(wù)都是被禁止的。解決方案先發(fā)送10 02或10 03進(jìn)入相應(yīng)會(huì)話。安全狀態(tài)0x87服務(wù)可能被定義為“安全相關(guān)服務(wù)”。這意味著在執(zhí)行前必須通過0x27服務(wù)SecurityAccess完成安全解鎖獲得足夠的權(quán)限等級(jí)。解決方案檢查診斷規(guī)范確認(rèn)是否需要先進(jìn)行0x27服務(wù)種子密鑰交換。依賴條件有些ECU要求在執(zhí)行波特率切換前必須滿足特定條件如“車輛速度為零”、“點(diǎn)火開關(guān)ON但發(fā)動(dòng)機(jī)OFF”等。這些條件不滿足也會(huì)返回0x22。解決方案仔細(xì)閱讀ECU的詳細(xì)診斷需求規(guī)范。4.2 切換波特率后“失聯(lián)”了怎么辦這是最令人緊張的狀況。發(fā)送87 03后診斷儀再也收不到任何ECU的報(bào)文。原因診斷儀沒有在ECU切換波特率后同步更改自身CAN接口的波特率設(shè)置。兩者波特率不匹配自然無法通訊。應(yīng)急恢復(fù)手動(dòng)重設(shè)在CANoe/CANalyzer的硬件配置界面手動(dòng)將對(duì)應(yīng)CAN通道的波特率改回原來的值或嘗試其他可能的值。腳本自動(dòng)回退如3.1節(jié)所述在腳本中實(shí)現(xiàn)超時(shí)檢測(cè)。如果發(fā)送87 03后在預(yù)定時(shí)間內(nèi)如100ms沒有收到任何來自ECU的報(bào)文不限于診斷響應(yīng)任何ECU發(fā)送的CAN幀則自動(dòng)將診斷儀波特率切回上一個(gè)已知有效的值并嘗試發(fā)送10 01回到默認(rèn)會(huì)話。硬件復(fù)位最徹底的方法給ECU重新上電。ECU在冷啟動(dòng)后通常會(huì)加載默認(rèn)的通信配置包括默認(rèn)的診斷波特率。4.3 0x87服務(wù)在CAN FD和DoIP中的應(yīng)用在CAN FD中CAN FD允許在數(shù)據(jù)階段使用更高的比特率。0x87服務(wù)可以用來動(dòng)態(tài)控制這個(gè)數(shù)據(jù)階段比特率。例如在刷寫大量數(shù)據(jù)時(shí)切換到更高的數(shù)據(jù)比特率如2Mbps或5Mbps以顯著提升傳輸效率。此時(shí)請(qǐng)求參數(shù)可能需要包含兩個(gè)波特率值仲裁段波特率和數(shù)據(jù)段波特率。在DoIP (Diagnostic over IP) 中雖然DoIP底層是TCP/IP但“鏈接控制”的概念依然存在。這里的0x87服務(wù)可能被用來控制DoIP實(shí)體車輛網(wǎng)關(guān)與測(cè)試設(shè)備之間的TCP數(shù)據(jù)吞吐率、激活/停用DoIP路由或控制車輛發(fā)現(xiàn)過程。其參數(shù)和語義與CAN環(huán)境完全不同需要參考ISO 13400DoIP和具體的實(shí)現(xiàn)規(guī)范。4.4 調(diào)試技巧使用CANoe的Trace和Graphics窗口Trace窗口過濾顯示0x7E0和0x7E8的報(bào)文。清晰看到87 01請(qǐng)求和C7 01響應(yīng)以及87 03請(qǐng)求和C7 03響應(yīng)。確認(rèn)時(shí)序和內(nèi)容是否正確。Graphics窗口創(chuàng)建一個(gè)信號(hào)用來顯示“當(dāng)前診斷波特率”。在CAPL腳本中每次成功切換波特率后更新這個(gè)信號(hào)的值。這樣可以在圖形上直觀地看到波特率切換的發(fā)生時(shí)刻便于與總線負(fù)載率、錯(cuò)誤幀等信號(hào)進(jìn)行關(guān)聯(lián)分析?？偩€負(fù)載率觀察在執(zhí)行切換前后觀察總線負(fù)載率的變化。從低波特率切換到高波特率在發(fā)送相同數(shù)量報(bào)文的情況下負(fù)載率會(huì)降低因?yàn)槊勘忍貢r(shí)間變短單位時(shí)間能發(fā)送更多比特。這可以間接驗(yàn)證切換是否真正生效。5. 與其他服務(wù)的協(xié)同構(gòu)建健壯的診斷序列0x87服務(wù)很少孤立使用它總是嵌入在一個(gè)更復(fù)雜的診斷操作序列中尤其是ECU軟件刷寫Programming流程。理解它在這個(gè)序列中的位置至關(guān)重要。一個(gè)簡(jiǎn)化的、包含波特率切換的刷寫前置流程可能如下進(jìn)入擴(kuò)展會(huì)話10 03安全訪問解鎖27 01- 獲取種子(Seed) - 計(jì)算密鑰(Key) -27 02 [Key]這里可能就涉及到uds capl 調(diào)用dll uds算seedkey這個(gè)熱搜詞中的場(chǎng)景即用CAPL調(diào)用外部DLL來計(jì)算密鑰。鏈接控制驗(yàn)證波特率87 01 [HighSpeedBaudID]- 響應(yīng)C7 01鏈接控制切換波特率87 03 [HighSpeedBaudID]- 響應(yīng)C7 03診斷儀在收到C7 03后立即更改CAN接口波特率設(shè)置。測(cè)試新鏈接發(fā)送3E 80TesterPresent或22 [DID]讀取數(shù)據(jù)確認(rèn)在新波特率下通訊正常。進(jìn)入編程會(huì)話10 02注意有些ECU要求在編程會(huì)話下才能進(jìn)行后續(xù)的34、36、37服務(wù)。關(guān)閉DTC設(shè)置85 02控制DTC設(shè)置通信控制28 03 [控制類型]可能禁止非診斷報(bào)文降低總線負(fù)載為高速刷寫讓出帶寬。開始刷寫流程34請(qǐng)求下載36傳輸數(shù)據(jù)37請(qǐng)求退出傳輸...在這個(gè)序列中0x87服務(wù)步驟34是提升后續(xù)34/36/37服務(wù)數(shù)據(jù)傳輸效率的關(guān)鍵準(zhǔn)備步驟。如果沒有切換到更高波特率刷寫一個(gè)幾兆字節(jié)的軟件包將耗費(fèi)難以忍受的時(shí)間。6. 測(cè)試考量如何全面測(cè)試0x87服務(wù)作為測(cè)試工程師針對(duì)0x87服務(wù)不能只測(cè)“正常流程通過”。以下是一些關(guān)鍵的測(cè)試點(diǎn)呼應(yīng)了“最全面的uds測(cè)試用例”這個(gè)需求正常功能測(cè)試在支持的會(huì)話如擴(kuò)展會(huì)話、編程會(huì)話下驗(yàn)證87 01和87 03序列成功執(zhí)行且切換后通訊正常。驗(yàn)證87 02子功能如果支持可以指定任意波特率并成功切換。無效參數(shù)測(cè)試發(fā)送87 01或87 03時(shí)使用未定義的Baudrate Identifier如0xFF應(yīng)返回NRC0x31requestOutOfRange。發(fā)送87 02時(shí)使用ECU不支持的波特率值如一個(gè)極低或極高的值應(yīng)返回NRC0x33securityAccessDenied? 這里更可能是0x31或自定義NRC具體看規(guī)范。條件不滿足測(cè)試在默認(rèn)會(huì)話下發(fā)送0x87服務(wù)請(qǐng)求應(yīng)返回NRC0x7EserviceNotSupportedInActiveSession或0x22。在未通過安全訪問時(shí)發(fā)送請(qǐng)求如果該服務(wù)受安全保護(hù)應(yīng)返回NRC0x33。在車輛行駛狀態(tài)模擬車速信號(hào)0下發(fā)送請(qǐng)求應(yīng)返回NRC0x22。序列錯(cuò)誤測(cè)試不經(jīng)過87 01驗(yàn)證直接發(fā)送87 03請(qǐng)求切換ECU應(yīng)如何處理可能返回NRC0x24-requestSequenceError或直接拒絕。連續(xù)兩次發(fā)送87 03請(qǐng)求切換波特率第二次請(qǐng)求應(yīng)如何處理異常與恢復(fù)測(cè)試中斷測(cè)試在ECU回復(fù)C7 03后診斷儀延遲切換自身波特率如延遲1秒。驗(yàn)證ECU在此期間是否還能處理以舊波特率發(fā)送的請(qǐng)求通常不能因?yàn)镋CU已經(jīng)切換?；謴?fù)測(cè)試執(zhí)行87 03切換后強(qiáng)制讓診斷儀與ECU“失聯(lián)”。然后給ECU重新上電驗(yàn)證其診斷波特率是否恢復(fù)為默認(rèn)值并能用默認(rèn)波特率重新建立連接。壓力測(cè)試在極高總線負(fù)載80%的情況下執(zhí)行波特率切換操作觀察是否會(huì)出現(xiàn)錯(cuò)誤幀或切換失敗。邊界與性能測(cè)試測(cè)試支持的最小和最大波特率。測(cè)量切換波特率操作本身所耗費(fèi)的時(shí)間從發(fā)送87 03到在新波特率下成功完成一次診斷通信的時(shí)間。這個(gè)時(shí)間對(duì)于刷寫流程的整體耗時(shí)評(píng)估很重要。通過以上這些測(cè)試你才能稱得上對(duì)0x87服務(wù)進(jìn)行了“全面”的覆蓋確保該功能在車輛各種復(fù)雜環(huán)境下都能穩(wěn)定可靠地工作。理解并掌握LinkControl服務(wù)是你從“會(huì)用UDS”到“精通UDS”道路上必不可少的一步。