做了這么多年車載ECU軟件開(kāi)發(fā)UDS協(xié)議棧幾乎是每個(gè)項(xiàng)目都繞不開(kāi)的坎。每次新項(xiàng)目啟動(dòng)團(tuán)隊(duì)里最常問(wèn)的一句話就是“這次用誰(shuí)家的診斷?！?。這問(wèn)題看著簡(jiǎn)單回答起來(lái)卻特別費(fèi)勁。說(shuō)一個(gè)UDS協(xié)議?！翱孔V”遠(yuǎn)不是它能響應(yīng)“0x10 00 00”這種標(biāo)準(zhǔn)會(huì)話切換那么簡(jiǎn)單。UDS協(xié)議棧的本質(zhì)是把診斷儀與ECU之間那一來(lái)一回的診斷語(yǔ)義、狀態(tài)遷移、超時(shí)節(jié)奏和異常恢復(fù)全部處理干凈而且要在臺(tái)架上測(cè)試不出錯(cuò)、產(chǎn)線上刷不掛、4S店里查得快。這篇文章我不想逐條抄ISO 14229規(guī)范而是想結(jié)合我自己的真實(shí)項(xiàng)目經(jīng)歷聊聊UDS協(xié)議棧放在整車環(huán)境里到底承擔(dān)什么角色、哪些核心機(jī)制決定它靠不靠譜、集成過(guò)程中最常見(jiàn)的坑有哪些。不管是準(zhǔn)備選型、正在集成還是打算自己寫一套的同行應(yīng)該都能從中找到點(diǎn)參考。1. UDS協(xié)議棧放在整車環(huán)境里究竟承擔(dān)什么角色1.1 一條診斷消息從診斷儀到ECU的完整旅程很多剛?cè)腴T的朋友會(huì)把UDS協(xié)議棧理解為“一串處理函數(shù)”這個(gè)理解太窄了。一條診斷請(qǐng)求從診斷儀發(fā)出到ECU給出響應(yīng)沿途要經(jīng)過(guò)好幾層診斷儀應(yīng)用層構(gòu)造UDS報(bào)文比如“讀取ECU當(dāng)前故障碼”的0x19服務(wù)請(qǐng)求然后走到傳輸層如果數(shù)據(jù)長(zhǎng)度超過(guò)單幀CAN報(bào)文能承載的8字節(jié)就需要按ISO 15765-2把數(shù)據(jù)拆成多幀發(fā)送這就是常說(shuō)的CAN TP報(bào)文通過(guò)CAN總線到達(dá)ECU的CAN控制器觸發(fā)接收中斷驅(qū)動(dòng)層把幀收進(jìn)來(lái)CAN TP模塊完成重組再把完整的UDS數(shù)據(jù)交給協(xié)議棧核心解析。UDS協(xié)議棧真正負(fù)責(zé)的就是從“拿到完整應(yīng)用層請(qǐng)求”到“返回完整應(yīng)用層響應(yīng)”這一段。它要判斷服務(wù)標(biāo)識(shí)符是否支持、子功能是否合法、當(dāng)前會(huì)話是否允許執(zhí)行、安全等級(jí)是否足夠、參數(shù)長(zhǎng)度是否匹配然后調(diào)用對(duì)應(yīng)的服務(wù)處理函數(shù)最后把響應(yīng)按同樣的路線傳回去。如果這臺(tái)ECU里面還跑著RTOS那么協(xié)議棧還要考慮消息隊(duì)列從中斷上下文到任務(wù)上下文的切換如果ECU同時(shí)控制多個(gè)總線協(xié)議棧還要能感知到請(qǐng)求是從哪條總線來(lái)的響應(yīng)就該回到哪條總線。這些聽(tīng)著瑣碎但任何一處處理不當(dāng)都會(huì)變成真實(shí)路線上“偶發(fā)無(wú)響應(yīng)”的疑難雜癥。1.2 產(chǎn)線、售后、法規(guī)三個(gè)典型場(chǎng)景對(duì)棧的要求不一樣同一個(gè)UDS協(xié)議棧在不同場(chǎng)景下被“考驗(yàn)”的點(diǎn)是完全不同的。產(chǎn)線刷寫場(chǎng)景要求的是高吞吐和強(qiáng)實(shí)時(shí)。刷寫B(tài)ootloader時(shí)診斷儀會(huì)連續(xù)不斷地發(fā)送0x36請(qǐng)求下載固件每一包數(shù)據(jù)ECU都要盡快寫入Flash而且要通過(guò)CRC校驗(yàn)、合法性校驗(yàn)。這個(gè)場(chǎng)景下協(xié)議棧不能頻繁丟幀不能因?yàn)檎{(diào)度優(yōu)先級(jí)問(wèn)題導(dǎo)致連續(xù)幀接收超時(shí)。售后診斷場(chǎng)景要求的是功能覆蓋和穩(wěn)定性。維修工用診斷儀讀故障碼、做執(zhí)行器測(cè)試、標(biāo)定傳感器可能一整天都在反復(fù)切換會(huì)話、反復(fù)做安全訪問(wèn)。這時(shí)候如果安全訪問(wèn)嘗試計(jì)數(shù)偶爾出錯(cuò)或者會(huì)話切換后服務(wù)可達(dá)性狀態(tài)沒(méi)復(fù)位就會(huì)讓維修工誤以為ECU壞了。法規(guī)檢測(cè)場(chǎng)景也就是我們常說(shuō)的OBD相關(guān)服務(wù)要求的是嚴(yán)格符合排放法規(guī)規(guī)定的服務(wù)集合和報(bào)文時(shí)序。這一塊兒診斷儀通常是法規(guī)認(rèn)證的設(shè)備它會(huì)按照固定的順序輪詢服務(wù)協(xié)議棧多回了不該回的數(shù)據(jù)、少回了某個(gè)DTC狀態(tài)位都可能導(dǎo)致檢測(cè)失敗。我在評(píng)估一個(gè)協(xié)議棧的時(shí)候第一件事就是拿這三個(gè)場(chǎng)景分別過(guò)一遍。不是說(shuō)產(chǎn)品要同時(shí)滿足三條產(chǎn)線才叫靠譜而是說(shuō)協(xié)議棧的對(duì)外表現(xiàn)必須能適配不同應(yīng)用策略而不是寫死了只為一套流程服務(wù)。1.3 正常路徑誰(shuí)都能做異常路徑才見(jiàn)真章我見(jiàn)過(guò)不少協(xié)議棧演示Demo做得花里胡哨正常的0x10、0x22、0x27請(qǐng)求響應(yīng)全都沒(méi)問(wèn)題測(cè)試報(bào)告拉出來(lái)綠油油一片。但真正把它跑進(jìn)一個(gè)復(fù)雜ECU項(xiàng)目之后問(wèn)題才開(kāi)始冒出來(lái)。所謂異常路徑包含這樣幾類診斷儀在ECU處理前一個(gè)請(qǐng)求還沒(méi)結(jié)束時(shí)又發(fā)來(lái)了新的請(qǐng)求多幀診斷報(bào)文中間斷了一幀后面又續(xù)上了一個(gè)不完整的首幀兩個(gè)診斷儀同時(shí)通過(guò)功能尋址廣播訪問(wèn)ECU安全訪問(wèn)密鑰校驗(yàn)失敗連續(xù)多次刷寫過(guò)程中地址超出了合法范圍。這些情況在ISO 14229里都規(guī)定了明確的行為但實(shí)現(xiàn)協(xié)議棧的人有沒(méi)有把每條都做到位測(cè)試的人有沒(méi)有把這些工況都測(cè)進(jìn)來(lái)直接決定了你拿到的棧是“演示級(jí)”還是“量產(chǎn)級(jí)”。我后來(lái)甚至習(xí)慣先不做正向功能驗(yàn)證上來(lái)就故意發(fā)錯(cuò)報(bào)文、亂切會(huì)話、超時(shí)中斷看協(xié)議棧的“抗打擊能力”。抗得住再談別的。2. 會(huì)話、安全訪問(wèn)和傳輸時(shí)序決定協(xié)議棧成色的三塊硬骨頭2.1 會(huì)話狀態(tài)機(jī)不是“切到哪個(gè)會(huì)話”那么簡(jiǎn)單UDS的會(huì)話管理由0x10服務(wù)控制典型的狀態(tài)有默認(rèn)會(huì)話、編程會(huì)話、擴(kuò)展會(huì)話。簡(jiǎn)單理解ECU在默認(rèn)會(huì)話下只開(kāi)放少量診斷服務(wù)進(jìn)入擴(kuò)展會(huì)話或編程會(huì)話后才能碰Flash、標(biāo)定、刷寫這些高風(fēng)險(xiǎn)操作。但“切換會(huì)話”這件事兒麻煩在這些細(xì)節(jié)上切換到編程會(huì)話時(shí)協(xié)議棧應(yīng)當(dāng)同步調(diào)整自己能處理的服務(wù)集合比如禁止一些非診斷應(yīng)用請(qǐng)求打擾Bootloader默認(rèn)會(huì)話下允許的服務(wù)到編程會(huì)話下可能必須拒絕會(huì)話之間切換還要把當(dāng)前會(huì)話相關(guān)的狀態(tài)復(fù)位比如正在進(jìn)行的0x27安全訪問(wèn)解鎖狀態(tài)、臨時(shí)寫入的數(shù)據(jù)緩沖、DTC設(shè)置的抑制狀態(tài)都要一并處理干凈。大多數(shù)“不靠譜”的協(xié)議棧做的是“每個(gè)服務(wù)進(jìn)來(lái)時(shí)查一下當(dāng)前會(huì)話”但沒(méi)有把“會(huì)話切換”本身當(dāng)成一次狀態(tài)遷移事件去處理。結(jié)果就是從擴(kuò)展會(huì)話切回默認(rèn)會(huì)話后之前打開(kāi)的安全訪問(wèn)狀態(tài)依然有效或者從編程會(huì)話跳回默認(rèn)會(huì)話后0x3E維持會(huì)話的計(jì)時(shí)器沒(méi)有被停止導(dǎo)致明明已經(jīng)回默認(rèn)了ECU還在按編程會(huì)話的超時(shí)策略走兩個(gè)狀態(tài)機(jī)互相打架。我自己的習(xí)慣是收到0x10請(qǐng)求、確定切換目標(biāo)會(huì)話合法之后先執(zhí)行“離開(kāi)舊會(huì)話的清理動(dòng)作”再執(zhí)行“進(jìn)入新會(huì)話的初始化動(dòng)作”最后才發(fā)送肯定響應(yīng)。這個(gè)順序是不能反的因?yàn)閰f(xié)議棧內(nèi)部的服務(wù)權(quán)限表、安全等級(jí)、會(huì)話超時(shí)定時(shí)器都依賴一套單一的會(huì)話狀態(tài)作為唯一事實(shí)來(lái)源。2.2 安全訪問(wèn)的種子-密鑰、重試計(jì)數(shù)和延遲鎖定0x27服務(wù)是UDS里最容易出幺蛾子的地方。正常情況下診斷儀發(fā)0x27請(qǐng)求種子ECU返回一串隨機(jī)數(shù)種子診斷儀用約定的算法算出密鑰發(fā)回來(lái)ECU比對(duì)通過(guò)后就把當(dāng)前會(huì)話的安全等級(jí)提到允許執(zhí)行敏感操作的水準(zhǔn)?？孔V的協(xié)議棧至少要把這幾件事做對(duì)種子只能一次性使用不能被重放密鑰錯(cuò)誤時(shí)ECU要記錄錯(cuò)誤計(jì)數(shù)連續(xù)錯(cuò)誤達(dá)到一定次數(shù)需要進(jìn)入延遲鎖定狀態(tài)返回NRC 0x36超過(guò)嘗試次數(shù)或者NRC 0x37延遲時(shí)間未過(guò)安全解鎖狀態(tài)只有在當(dāng)前會(huì)話有效切換會(huì)話、ECU復(fù)位后必須強(qiáng)制回到鎖定態(tài)密鑰的校驗(yàn)算法不能放在中斷里跑否則長(zhǎng)密鑰運(yùn)算會(huì)阻塞整個(gè)中斷響應(yīng)。我在實(shí)際項(xiàng)目里見(jiàn)過(guò)一個(gè)典型的坑協(xié)議棧把安全訪問(wèn)的嘗試次數(shù)做成了每個(gè)會(huì)話獨(dú)立計(jì)數(shù)刷寫B(tài)ootloader過(guò)程中診斷儀做了兩次安全訪問(wèn)第一次失敗、第二次成功但那個(gè)失敗計(jì)數(shù)在切換到新會(huì)話后沒(méi)有清零導(dǎo)致第三次真正需要解鎖時(shí)直接被拒。最后查了半天發(fā)現(xiàn)是狀態(tài)遷移沒(méi)做干凈計(jì)數(shù)跟著會(huì)話殘留了。所以好協(xié)議棧一定會(huì)把安全訪問(wèn)狀態(tài)和會(huì)話狀態(tài)綁在一起復(fù)位而不是單獨(dú)維護(hù)一套“永遠(yuǎn)不清零”的歷史計(jì)數(shù)。2.3 P2/P2*和NRC 0x78是診斷儀和ECU的“心跳約定”這一塊兒是區(qū)分“懂UDS”和“真懂UDS”的地方。ISO 14229規(guī)定ECU在收到診斷請(qǐng)求后需要在P2server時(shí)間內(nèi)給出響應(yīng)默認(rèn)是50ms如果ECU真的來(lái)不及處理可以在P2server內(nèi)先回一個(gè)NRC 0x78請(qǐng)求已正確接收響應(yīng)延遲然后ECU和診斷儀之間的響應(yīng)超時(shí)時(shí)間就切換到P2*server通常是5000ms。這是給ECU爭(zhēng)取處理時(shí)間的合法機(jī)制但前提是0x78必須盡早回而不是處理完才發(fā)現(xiàn)超時(shí)了再補(bǔ)一個(gè)0x78。很多協(xié)議棧實(shí)現(xiàn)者把0x78當(dāng)成“萬(wàn)金油”一旦任務(wù)忙就回0x78拖延。但其實(shí)0x78還有一層隱含語(yǔ)義ECU告訴診斷儀“我已經(jīng)收到這個(gè)請(qǐng)求正在處理你別急著報(bào)超時(shí)”。在ECU返回0x78之后如果診斷儀緊接著又發(fā)來(lái)第二個(gè)請(qǐng)求ECU是有權(quán)暫時(shí)不處理的因?yàn)橥粋€(gè)診斷時(shí)序里只允許一個(gè)請(qǐng)求在途。我踩過(guò)的坑是協(xié)議?；亓?x78之后沒(méi)有把診斷應(yīng)用層的“單飛行請(qǐng)求”標(biāo)志置位結(jié)果后續(xù)請(qǐng)求被分組接收、分組解析甚至一個(gè)Flash擦除正在進(jìn)行時(shí)另一個(gè)線程又來(lái)調(diào)斷言擦除接口直接把Flash狀態(tài)機(jī)搞亂了?？煽康淖龇ㄊ窃谑盏秸?qǐng)求進(jìn)入處理的那一刻就把請(qǐng)求消息保存在固定的請(qǐng)求緩沖里處理完成、響應(yīng)發(fā)出后才允許接收下一條請(qǐng)求。0x78只是把一個(gè)長(zhǎng)耗時(shí)操作“合法地”拉長(zhǎng)它不能成為并發(fā)同時(shí)進(jìn)入ECU的入口。2.4 NRC不是隨便返回的優(yōu)先級(jí)和時(shí)機(jī)都標(biāo)在規(guī)范里NRC否定響應(yīng)碼是UDS里診斷儀判斷ECU到底“哪里不對(duì)”的唯一線索。正面響應(yīng)只有一種格式但否定響應(yīng)必須告訴對(duì)方具體原因比如服務(wù)不支持、子功能不支持、消息長(zhǎng)度錯(cuò)誤、安全訪問(wèn)失敗、條件不滿足。我見(jiàn)過(guò)不少協(xié)議棧處理NRC時(shí)是“誰(shuí)先發(fā)現(xiàn)錯(cuò)誤誰(shuí)先回”這其實(shí)是錯(cuò)的。ISO 14229的各個(gè)服務(wù)定義里其實(shí)隱含了NRC檢查順序的要求。比如一個(gè)0x2E寫入請(qǐng)求通常是先檢查服務(wù)是否支持、再檢查會(huì)話是否允許、再檢查安全等級(jí)、再檢查地址和長(zhǎng)度、最后檢查數(shù)據(jù)是否成功寫入。如果協(xié)議棧把“地址超出范圍”的檢查放在了“安全等級(jí)不足”之前那么診斷儀在安全未解鎖時(shí)就會(huì)優(yōu)先收到0x31而不是0x33導(dǎo)致診斷儀判定錯(cuò)誤分支做出錯(cuò)誤的用戶提示。說(shuō)實(shí)話這份檢查優(yōu)先級(jí)不是所有協(xié)議棧文檔都會(huì)給你畫清楚的判斷是否靠譜就要看它有沒(méi)有把檢查順序做成一張明確可讀的判定表。完整的協(xié)議棧應(yīng)該對(duì)每個(gè)SID都維護(hù)一條清晰的NRC優(yōu)先級(jí)鏈路并且在代碼注釋里寫明“為什么先查A再查B”方便后續(xù)工程師維護(hù)。3. 給協(xié)議棧做體檢我評(píng)估靠譜程度的六項(xiàng)清單3.1 標(biāo)準(zhǔn)符合性服務(wù)列表全不代表行為正確第一項(xiàng)體檢是拿ISO 14229-1和ISO 15765-2的正文對(duì)著協(xié)議棧的行為逐條走讀。走讀不是看它支持0x22、0x27、0x19這么簡(jiǎn)單而是看它每個(gè)服務(wù)的肯定響應(yīng)格式、否定響應(yīng)條件、時(shí)序、子功能支持范圍是否符合規(guī)范。我通常會(huì)讓協(xié)議棧供應(yīng)商提供一個(gè)“服務(wù)矩陣”每列一個(gè)SID每行一個(gè)條件比如“默認(rèn)會(huì)話下是否支持”“擴(kuò)展會(huì)話下是否支持”“安全訪問(wèn)前是否支持”“長(zhǎng)度錯(cuò)誤時(shí)回什么NRC”“地址越界時(shí)回什么NRC”。這張矩陣?yán)鰜?lái)協(xié)議棧實(shí)現(xiàn)者有沒(méi)有真正理解規(guī)范一目了然。如果供應(yīng)商說(shuō)“我們只是把開(kāi)源協(xié)議棧改了改打包給你”那我對(duì)標(biāo)準(zhǔn)符合性的信任度會(huì)打折扣。因?yàn)楹芏嚅_(kāi)源棧的側(cè)重點(diǎn)是“常見(jiàn)服務(wù)能用”而不是“所有邊界情況符合規(guī)范”。后者需要投入大量的人力去逐條驗(yàn)證商業(yè)棧的溢價(jià)也主要花在這里。3.2 硬件和OS接口抽象裸機(jī)、RTOS、多核都要能落第二個(gè)體檢項(xiàng)是看協(xié)議棧的代碼分層?？孔V的協(xié)議棧一定做了嚴(yán)格的硬件抽象CAN收發(fā)是由驅(qū)動(dòng)層回調(diào)的定時(shí)器、任務(wù)鎖、消息郵箱這些基礎(chǔ)組件都抽象成接口不會(huì)直接去操作某個(gè)具體芯片的寄存器。我見(jiàn)過(guò)最頭疼的集成是供應(yīng)商給的協(xié)議棧里面直接塞了某款MCU的頭文件換一款芯片就編譯不過(guò)。后來(lái)?yè)Q的協(xié)議棧通過(guò)一個(gè)t_transport_if結(jié)構(gòu)體把所有底層依賴都包了起來(lái)我們只需要實(shí)現(xiàn)CAN發(fā)送、CAN接收回調(diào)、獲取系統(tǒng)時(shí)間戳、臨界區(qū)進(jìn)入/退出四個(gè)接口就能跑起來(lái)。多核芯片越來(lái)越常見(jiàn)協(xié)議棧還要能明確告知“哪些函數(shù)可以在中斷上下文調(diào)用、哪些函數(shù)只能在任務(wù)上下文調(diào)用”。比如UDS應(yīng)用層的服務(wù)處理函數(shù)通常允許耗時(shí)較長(zhǎng)就不適合放在中斷里而CAN TP的接收解包函數(shù)適合放在中斷后半段。如果協(xié)議棧不做這層區(qū)分集成方很容易在中斷里誤調(diào)用一個(gè)需要信號(hào)量的函數(shù)直接拋硬件異常。3.3 資源占用與實(shí)時(shí)性RAM、ROM、CPU負(fù)載UDS協(xié)議棧不是那種可以隨便揮霍資源的模塊。ECU的Flash和RAM預(yù)算卡得很緊尤其Bootloader更是寸土寸金。評(píng)估時(shí)我會(huì)問(wèn)幾個(gè)非常具體的問(wèn)題只保留0x10、0x11、0x19、0x22、0x27、0x2E、0x31、0x34、0x36、0x37這些核心服務(wù)時(shí)ROM占用大概多少接收一條多幀診斷報(bào)文比如0x36傳輸數(shù)據(jù)一次20KBRAM緩沖需要多大這個(gè)緩沖是靜態(tài)分配還是動(dòng)態(tài)分配滿負(fù)載地連續(xù)收CAN TP連續(xù)幀時(shí)每幀重組耗時(shí)是多少微秒這些數(shù)字不能只在PPT里看我會(huì)直接拉一份編譯后的map文件核對(duì)ROM段再寫一個(gè)專門的benchmark用例來(lái)測(cè)CPU負(fù)載。別嫌麻煩協(xié)議棧說(shuō)“我支持最多4095字節(jié)的多幀數(shù)據(jù)”結(jié)果它緩沖區(qū)按最大長(zhǎng)度預(yù)分配了4KB靜態(tài)內(nèi)存一個(gè)項(xiàng)目里用了三個(gè)診斷實(shí)例直接小一半RAM不見(jiàn)了這種案例我見(jiàn)過(guò)好幾次。3.4 可觀測(cè)性日志、Trace和錯(cuò)誤統(tǒng)計(jì)“靠譜”不只是運(yùn)行時(shí)不崩還得在出問(wèn)題時(shí)能快速定位。好協(xié)議棧一定會(huì)提供多級(jí)日志接口可以把CAN TP的接收狀態(tài)、UDS請(qǐng)求解析狀態(tài)、NRC返回原因、會(huì)話切換事件都輸出出來(lái)并且能編譯時(shí)開(kāi)關(guān)關(guān)閉。我還會(huì)看協(xié)議棧有沒(méi)有暴露一組診斷統(tǒng)計(jì)計(jì)數(shù)收到的請(qǐng)求總數(shù)、返回的肯定響應(yīng)數(shù)、否定響應(yīng)數(shù)、NRC 0x78次數(shù)、CAN TP丟幀數(shù)。因?yàn)榱慨a(chǎn)之后如果客戶報(bào)“刷寫偶發(fā)失敗”光靠日志遠(yuǎn)遠(yuǎn)不夠更需要的是運(yùn)行計(jì)數(shù)器的現(xiàn)場(chǎng)導(dǎo)出能立刻看出是哪個(gè)環(huán)節(jié)丟的包是CAN層丟的還是協(xié)議棧主動(dòng)丟的。如果協(xié)議棧完全不提供這些觀測(cè)接口那它在我的評(píng)估名單里基本會(huì)被直接劃掉。哪怕它行為再正確我看不見(jiàn)它的內(nèi)部狀態(tài)就用不了“把它訓(xùn)好”的機(jī)會(huì)。3.5 交付物與長(zhǎng)期維護(hù)源碼、文檔和追溯最后看交付物完整度。源碼交付最好實(shí)在不行也得有條件地把核心狀態(tài)機(jī)的邏輯開(kāi)源給集成方走查。文檔至少要有集成手冊(cè)、服務(wù)矩陣、NRC判定表、CAN TP參數(shù)配置說(shuō)明、已知缺陷清單。長(zhǎng)期維護(hù)更關(guān)鍵。主機(jī)廠的項(xiàng)目生命周期很長(zhǎng)協(xié)議棧發(fā)布后還會(huì)有Bug修復(fù)、需求變更、新增OEM擴(kuò)展診斷服務(wù)。如果協(xié)議棧沒(méi)有明確的版本管理、變更記錄、回滾機(jī)制那今天看著沒(méi)問(wèn)題三年后一出新問(wèn)題就可能找不到人管。我會(huì)問(wèn)供應(yīng)商“你們這個(gè)?；€版本是什么最近一次變更提交涉及哪些文件”回答含含糊糊的基本可以預(yù)期后面維護(hù)會(huì)很難受。4. 真實(shí)項(xiàng)目集成復(fù)盤從空工程到刷寫流程全通4.1 搭建最小工程CAN收發(fā)、消息隊(duì)列和協(xié)議棧初始化我在“模擬項(xiàng)目X”里用的是一塊某款主流車規(guī)MCU帶兩路CAN跑了一個(gè)簡(jiǎn)單裸機(jī)調(diào)度。集成第一步不是塞診斷服務(wù)而是先把CAN底層的收發(fā)跑通CAN控制器初始化、消息RAM配置、接收中斷里把幀收進(jìn)FIFO然后在主循環(huán)里把FIFO里攢著的CAN幀輪詢?nèi)∽?。我?xí)慣把它做成一個(gè)環(huán)形緩沖區(qū)接收中斷只負(fù)責(zé)往環(huán)形緩沖里丟“原始CAN幀”診斷任務(wù)從緩沖里取出來(lái)再喂給協(xié)議棧。這樣做的原因是CAN中斷頻率可能很高診斷任務(wù)卻可能因?yàn)镕lash擦寫被卡住幾十毫秒緩沖區(qū)能防丟幀。協(xié)議棧初始化則按三步走先注冊(cè)傳輸層接口把CAN發(fā)送函數(shù)和定時(shí)器函數(shù)填進(jìn)去再創(chuàng)建診斷應(yīng)用層的唯一請(qǐng)求緩沖和響應(yīng)緩沖最后啟動(dòng)會(huì)話狀態(tài)機(jī)讓它默認(rèn)落在默認(rèn)會(huì)話。初始化完成后不給任何診斷請(qǐng)求先跑幾分鐘空轉(zhuǎn)看狀態(tài)機(jī)有沒(méi)有因?yàn)榭辙D(zhuǎn)產(chǎn)生異常響應(yīng)。4.2 最容易卡殼的尋址與過(guò)濾物理尋址和功能尋址很多第一次集成的同事會(huì)在這里卡很久。CAN上的診斷報(bào)文分為物理尋址和功能尋址。物理尋址是“點(diǎn)對(duì)點(diǎn)”比如診斷儀用0x7E0發(fā)給ECUECU必須用0x7E8單獨(dú)回復(fù)功能尋址是“一對(duì)多”比如診斷儀用0x7DF廣播所有ECU都能收到但只有允許功能尋址的服務(wù)才能參與廣播且ECU不需要回復(fù)否則總線上多個(gè)ECU同時(shí)回就會(huì)撞車。當(dāng)時(shí)我把接收濾波器配置成了只接收物理尋址報(bào)文結(jié)果用功能尋址廣播發(fā)0x10會(huì)話切換ECU毫無(wú)反應(yīng)排查了很久才想起過(guò)濾器把0x7DF給濾掉了。正確做法是濾波器同時(shí)接收物理尋址和功能尋址兩個(gè)CAN ID然后在協(xié)議棧上層根據(jù)報(bào)文ID區(qū)分當(dāng)前請(qǐng)求是物理尋址還是功能尋址再?zèng)Q定哪些服務(wù)可以響應(yīng)、是否需要響應(yīng)。這里面還有一個(gè)容易忽略的點(diǎn)0x3E維持會(huì)話這類服務(wù)如果通過(guò)功能尋址廣播進(jìn)來(lái)ECU即使不回復(fù)也要維持會(huì)話狀態(tài)而0x10這類不允許功能尋址的服務(wù)通過(guò)0x7DF進(jìn)來(lái)時(shí)應(yīng)該靜默丟棄還是回NRC不同OEM的約定也不同集成時(shí)要跟需求方對(duì)齊別自己拍腦袋。4.3 經(jīng)典刷寫鏈路0x10、0x27、0x34、0x36、0x37、0x11刷寫流程是UDS集成驗(yàn)收里最嚴(yán)格的一條鏈路我把它作為“協(xié)議棧是否合格”的終極測(cè)試。標(biāo)準(zhǔn)鏈路大致是這樣第一步診斷儀發(fā)0x10 02進(jìn)入編程會(huì)話ECU切換到Bootloader模式。第二步發(fā)0x85 02或者0x28來(lái)抑制DTC記錄防止刷寫過(guò)程中的臨時(shí)性錯(cuò)誤被存成故障碼。第三步發(fā)0x27安全訪問(wèn)請(qǐng)求種子ECU返回種子診斷儀算好密鑰發(fā)回解鎖安全權(quán)限。第四步發(fā)0x31例程控制比如“檢查刷寫預(yù)條件”確認(rèn)電壓、上鎖狀態(tài)、版本匹配都滿足。第五步發(fā)0x34請(qǐng)求下載ECU返回允許下載的最大塊長(zhǎng)度和起始地址。第六步循環(huán)發(fā)0x36傳輸數(shù)據(jù)每包數(shù)據(jù)ECU會(huì)驗(yàn)CRC、寫Flash、回響應(yīng)。第七步發(fā)0x37請(qǐng)求退出傳輸確認(rèn)整個(gè)刷寫數(shù)據(jù)完整。最后發(fā)0x11復(fù)位ECU讓新程序跑起來(lái)。這其中協(xié)議棧要處理的坑非常多。0x34的maxNumberOfBlockLength如果寫小了刷寫吞吐就極低寫大了ECU的接收緩沖裝不下直接回0x31。0x36每包數(shù)據(jù)寫入Flash的時(shí)機(jī)必須放在響應(yīng)之前寫完確實(shí)成功后才回肯定否則刷寫完成后的校驗(yàn)大概率會(huì)掛。0x37之后協(xié)議棧還應(yīng)當(dāng)再做一次整體完整性校驗(yàn)比如校驗(yàn)整個(gè)Flash的CRC再?zèng)Q定是否允許跳轉(zhuǎn)應(yīng)用。還要特別注意刷寫期間保持會(huì)話心跳。擦寫Flash動(dòng)輒幾十毫秒到幾百毫秒這段時(shí)間內(nèi)ECU無(wú)法及時(shí)響應(yīng)診斷儀發(fā)來(lái)的0x3E維持會(huì)話請(qǐng)求。如果不做任何處理診斷儀P2超時(shí)后會(huì)認(rèn)為ECU失聯(lián)中止刷寫?？孔V的方案有兩種一種是在進(jìn)入長(zhǎng)時(shí)間Flash操作前先主動(dòng)回復(fù)一個(gè)NRC 0x78把P2定時(shí)器拉開(kāi)等Flash寫完了再補(bǔ)最終響應(yīng)另一種是把0x3E的維持邏輯挪到獨(dú)立的定時(shí)器任務(wù)里中斷被Flash操作屏蔽時(shí)靠定時(shí)器任務(wù)維持一個(gè)“仍在活著”的標(biāo)志。兩種方式我都用過(guò)更推薦第二種因?yàn)?x78只能應(yīng)對(duì)單條請(qǐng)求維持會(huì)話的心跳需要的是能連續(xù)出現(xiàn)的時(shí)間片。4.4 收到“半成功”狀態(tài)的處理超時(shí)回滾與恢復(fù)真實(shí)刷寫最怕的不是整包失敗而是“半成功”前面0x34返回了支持的最大長(zhǎng)度你發(fā)了幾十包0x36都寫成功了結(jié)果最后一包校驗(yàn)發(fā)現(xiàn)整體CRC不對(duì)。這時(shí)候ECU必須能回到一個(gè)穩(wěn)定可重試的狀態(tài)。協(xié)議棧在這個(gè)點(diǎn)上要做到刷寫失敗后不能直接鎖死要允許診斷儀重新發(fā)起0x34請(qǐng)求下載從失敗的起始地址重新寫如果當(dāng)前刷寫地址狀態(tài)混亂要能通過(guò)重啟Bootloader回到初始狀態(tài)會(huì)話超時(shí)后如果ECU已經(jīng)退回了默認(rèn)會(huì)話診斷儀仍能通過(guò)0x10重新進(jìn)入編程會(huì)話。這一套“回滾”能力需要在協(xié)議棧里把刷寫狀態(tài)機(jī)做成分步可恢復(fù)而不是只做一個(gè)線性的“開(kāi)始-進(jìn)行-結(jié)束”標(biāo)志。在評(píng)估商棧時(shí)我會(huì)專門問(wèn)供應(yīng)商要一份“刷寫異常恢復(fù)測(cè)試報(bào)告”里面應(yīng)該有各種中斷時(shí)機(jī)下的表現(xiàn)掉電中斷、總線拔掉、會(huì)話超時(shí)、地址越界、長(zhǎng)度不符、CRC錯(cuò)。如果這些恢復(fù)路徑的測(cè)試不齊我基本不會(huì)采用。5. 那些年我踩過(guò)的協(xié)議棧的坑每一處都是真實(shí)教訓(xùn)5.1 診斷請(qǐng)求風(fēng)暴下的狀態(tài)機(jī)競(jìng)態(tài)有一次我們?cè)谧鲭姶偶嫒轀y(cè)試診斷儀以極快的周期連續(xù)發(fā)送0x3E維持會(huì)話請(qǐng)求。測(cè)試持續(xù)一段時(shí)間后ECU突然對(duì)下一個(gè)0x10請(qǐng)求不響應(yīng)了。抓總線看CAN上明明有請(qǐng)求ECU卻靜默。定位下來(lái)發(fā)現(xiàn)問(wèn)題出在協(xié)議棧的狀態(tài)機(jī)變量被多個(gè)上下文同時(shí)訪問(wèn)。接收中斷里做的狀態(tài)更新和診斷任務(wù)里做的狀態(tài)跳轉(zhuǎn)訪問(wèn)了同一個(gè)全局狀態(tài)而且沒(méi)有任何臨界區(qū)保護(hù)。診斷請(qǐng)求風(fēng)暴時(shí)中斷頻繁觸發(fā)任務(wù)調(diào)度被打斷兩個(gè)上下文的寫操作交錯(cuò)執(zhí)行狀態(tài)機(jī)的會(huì)話標(biāo)識(shí)被寫壞。這個(gè)坑教育了我協(xié)議棧的數(shù)據(jù)一致性不是“用不用RTOS”的問(wèn)題而是必須在設(shè)計(jì)上明確所有狀態(tài)更新的執(zhí)行上下文。后來(lái)我改成了“中斷只入隊(duì)診斷狀態(tài)只在診斷任務(wù)上下文里更新”才徹底穩(wěn)定下來(lái)。5.2 0x78掛起之后忘了還有P2*這回事另一個(gè)記憶深刻的坑是一個(gè)Bootloader項(xiàng)目在刷寫中途出現(xiàn)“偶發(fā)中斷”診斷儀報(bào)告“請(qǐng)求超時(shí)”但ECU邏輯上又沒(méi)死。最詭異的是用總線分析儀扎上去看ECU在收到0x36后確實(shí)回復(fù)了0x78過(guò)了大概1秒又回復(fù)了正常的0x36肯定響應(yīng)但診斷儀還是判定超時(shí)。原因在于我們的協(xié)議棧在回復(fù)0x78之后把P2定時(shí)器的起點(diǎn)算錯(cuò)了。診斷儀按ISO 14229的規(guī)則在收到0x78后P2的計(jì)時(shí)是從0x78響應(yīng)完成那一刻開(kāi)始算的而我們內(nèi)部卻把P2*起點(diǎn)算到了請(qǐng)求收到那一刻。Flash擦寫耗掉了800ms總時(shí)間接近2秒本身沒(méi)超可統(tǒng)計(jì)口徑一錯(cuò)診斷儀那邊覺(jué)得等待時(shí)間過(guò)了上限。這個(gè)坑的教訓(xùn)是0x78不是簡(jiǎn)單地“回一個(gè)碼”就行所有響應(yīng)超時(shí)相關(guān)的定時(shí)都必須嚴(yán)格對(duì)齊規(guī)范里“響應(yīng)完成時(shí)刻”這個(gè)語(yǔ)義。改完統(tǒng)計(jì)口徑后刷寫再也沒(méi)出現(xiàn)過(guò)這類誤報(bào)超時(shí)。5.3 刷寫途中會(huì)話超時(shí)Bootloader直接“半跪”還是在刷寫場(chǎng)景。某一次做產(chǎn)線聯(lián)調(diào)刷寫程序跑到約三分之一時(shí)診斷儀暫停發(fā)送0x36去執(zhí)行其他的預(yù)檢流程結(jié)果超過(guò)會(huì)話超時(shí)時(shí)間沒(méi)有發(fā)任何請(qǐng)求。ECU按規(guī)范退回了默認(rèn)會(huì)話安全訪問(wèn)狀態(tài)被復(fù)位Bootloader里的刷寫緩沖也被清空。診斷儀回來(lái)后傻了眼接著發(fā)0x36ECU回NRC 0x21請(qǐng)求序列錯(cuò)誤或者0x33安全訪問(wèn)被拒絕。這個(gè)現(xiàn)象其實(shí)完全符合規(guī)范問(wèn)題出在產(chǎn)線流程設(shè)計(jì)和協(xié)議棧容錯(cuò)策略上。后來(lái)的解決方案是產(chǎn)線流程里在長(zhǎng)時(shí)間暫停時(shí)主動(dòng)發(fā)0x10重新進(jìn)入編程會(huì)話并對(duì)Bootloader做“會(huì)話超時(shí)不下電”的配置讓它超時(shí)后還能在Bootloader里等待重新解鎖而不是直接回到應(yīng)用軟件。協(xié)議棧本身是嚴(yán)格按照規(guī)范走的沒(méi)有這個(gè)容錯(cuò)策略就會(huì)變成“使用者覺(jué)得棧不穩(wěn)”。這件事也讓明白了一個(gè)道理一個(gè)協(xié)議棧不能只考慮單一診斷儀場(chǎng)景要考慮“診斷儀性能夠不夠穩(wěn)定、會(huì)不會(huì)中途暫?！边@種真實(shí)世界的不完美。協(xié)議棧最好能提供一些合規(guī)范圍內(nèi)的容錯(cuò)開(kāi)關(guān)比如允許配置會(huì)話超時(shí)時(shí)間、允許配置0x78最大延遲時(shí)間讓應(yīng)用層根據(jù)風(fēng)險(xiǎn)場(chǎng)景動(dòng)態(tài)調(diào)整。5.4 多核MCU上的共享數(shù)據(jù)保護(hù)多核MCU普及以后共享數(shù)據(jù)保護(hù)成了新的重災(zāi)區(qū)。我們的控制器一顆核負(fù)責(zé)CAN通信和診斷協(xié)議棧另一顆核負(fù)責(zé)應(yīng)用控制算法兩個(gè)核需要共享一個(gè)“診斷當(dāng)前請(qǐng)求數(shù)據(jù)”的緩沖。最開(kāi)始圖省事直接用了全局變量沒(méi)有加鎖結(jié)果高負(fù)載時(shí)偶發(fā)出現(xiàn)請(qǐng)求內(nèi)容錯(cuò)亂診斷儀收到的響應(yīng)里字段錯(cuò)位。后來(lái)在協(xié)議棧的傳輸層與應(yīng)用層之間加了一層“帶自旋鎖的共享緩沖”寫操作和讀操作都走鎖才把問(wèn)題壓下去。更穩(wěn)妥的方案是直接把整個(gè)診斷協(xié)議棧固定在通信核上另一個(gè)核絕不直接訪問(wèn)診斷緩沖所有跨核數(shù)據(jù)交互走核間消息這樣從設(shè)計(jì)上消滅了競(jìng)爭(zhēng)條件。選擇協(xié)議棧時(shí)一定要確認(rèn)它對(duì)多核場(chǎng)景有明確的部署建議和鎖接口不能用單核時(shí)代的思維硬套。5.5 黑盒交付的堆棧出問(wèn)題只能靠猜我早期接過(guò)一個(gè)項(xiàng)目協(xié)議棧以靜態(tài)庫(kù)形式交付核心代碼不開(kāi)源只能調(diào)幾個(gè)API。前幾個(gè)月用得很順后來(lái)做OTA升級(jí)需要臨時(shí)在特定條件下改一下會(huì)話超時(shí)行為結(jié)果發(fā)現(xiàn)庫(kù)里面根本沒(méi)有這個(gè)配置項(xiàng)。更麻煩的是壓測(cè)時(shí)遇到一個(gè)偶發(fā)丟響應(yīng)的問(wèn)題供應(yīng)商只能靠加日志定位一來(lái)一回就拖了兩周。那次之后我對(duì)黑盒協(xié)議棧有了陰影UDS協(xié)議棧是深度融入ECU應(yīng)用層面的東西不是你調(diào)完就扔在那里不動(dòng)的模塊。它跟Flash驅(qū)動(dòng)、網(wǎng)絡(luò)管理、信息安全、診斷策略都有交互你必須有完全可見(jiàn)的代碼和接口才能做系統(tǒng)級(jí)調(diào)試。所以我現(xiàn)在選型有一條硬標(biāo)準(zhǔn)要么提供完整源代碼要么提供一個(gè)可以完全替代的“內(nèi)部實(shí)現(xiàn)鏡像”并且文檔里寫清楚每個(gè)函數(shù)的調(diào)用上下文和狀態(tài)遷移圖。達(dá)不到這條要求的再好也不碰。6. 選型心得自研、商業(yè)還是開(kāi)源以及未來(lái)的事6.1 三種獲取路徑的適用邊界自研UDS協(xié)議棧適合診斷功能高度定制、長(zhǎng)期多次復(fù)用的平臺(tái)型項(xiàng)目投入周期比較長(zhǎng)但換來(lái)的是完全可控的行為和積累多年的內(nèi)部經(jīng)驗(yàn)。商業(yè)授權(quán)協(xié)議棧適合項(xiàng)目周期短、需要第三方背書、以及團(tuán)隊(duì)沒(méi)有足夠精力深研標(biāo)準(zhǔn)的場(chǎng)合。開(kāi)源協(xié)議棧適合Demo驗(yàn)證、學(xué)習(xí)研究和沒(méi)有嚴(yán)格合規(guī)要求的項(xiàng)目但如果直接搬到量產(chǎn)車上穩(wěn)定性和長(zhǎng)期維護(hù)成本都要打個(gè)問(wèn)號(hào)。我在選型時(shí)會(huì)把項(xiàng)目階段拉出來(lái)。如果是預(yù)研階段做概念驗(yàn)證開(kāi)源棧最快如果是量產(chǎn)車型的診斷需求商業(yè)?；蜷L(zhǎng)期自研棧是正路。很多項(xiàng)目掛在開(kāi)源棧上出問(wèn)題不是開(kāi)源棧本身不可用而是用錯(cuò)了階段缺少了按量產(chǎn)標(biāo)準(zhǔn)做完整驗(yàn)證的預(yù)算和人力。6.2 面向OTA、DoIP和信息安全的擴(kuò)展性現(xiàn)在的UDS協(xié)議棧早已不只在CAN總線上工作。DoIP基于以太網(wǎng)的診斷意味著傳輸層要從CAN TP換成TCP/UDP加上DoIP協(xié)議頭這要求協(xié)議棧把“傳輸層接口”抽象得足夠干凈否則換傳輸就要重寫應(yīng)用層。這在選型時(shí)是個(gè)很關(guān)鍵的隱形門檻。OTA遠(yuǎn)程升級(jí)比產(chǎn)線刷寫更復(fù)雜它要跟車聯(lián)網(wǎng)平臺(tái)、云端證書、信息安全模塊協(xié)同。協(xié)議棧需要能支持更長(zhǎng)的數(shù)據(jù)塊、更高的吞吐量、更靈活的安全策略。很多舊架構(gòu)的協(xié)議棧把傳輸緩沖固定成CAN時(shí)代的2KB一搬到OTA就不夠用了。所以我現(xiàn)在會(huì)關(guān)注協(xié)議棧對(duì)“大數(shù)據(jù)塊連續(xù)傳輸”的支持程度以及它的緩沖策略是否能配置為更大容量。信息安全方面安全訪問(wèn)的種子-密鑰算法、刷寫數(shù)據(jù)的加密保護(hù)、UDS服務(wù)的可信執(zhí)行環(huán)境都需要協(xié)議棧在設(shè)計(jì)上預(yù)留接口比如密鑰算法可插拔、安全訪問(wèn)等級(jí)可擴(kuò)展、服務(wù)處理器可以被安全模塊替換。一個(gè)寫死的、不支持安全擴(kuò)展的UDS棧在未來(lái)的項(xiàng)目里會(huì)處處碰壁。6.3 我的“靠譜”定義寫在最后說(shuō)了這么多我其實(shí)想收個(gè)尾。做了那么多年我對(duì)“超靠譜的UDS協(xié)議?！钡亩x從來(lái)不是“支持的功能列表最長(zhǎng)”或者“跑分的響應(yīng)時(shí)間最短”而是它在異常情況下能不能保持行為可預(yù)期、問(wèn)題可定位、狀態(tài)可恢復(fù)。這個(gè)標(biāo)準(zhǔn)說(shuō)穿了就是協(xié)議棧的邊界質(zhì)量。再分享一個(gè)小經(jīng)驗(yàn)吧。我現(xiàn)在每次接到新協(xié)議棧第一件事就是拿到手先干一件很“土”的事——把ISO 14229里所有NRC的觸發(fā)條件整理成一張表然后對(duì)著協(xié)議棧代碼一行行核對(duì)。這個(gè)過(guò)程很枯燥但每次都能找出幾個(gè)還沒(méi)被測(cè)試用例覆蓋到的邊界行為。把這些邊界行為補(bǔ)齊比多支持十個(gè)服務(wù)都值錢。畢竟量產(chǎn)之后用戶不會(huì)夸你“這個(gè)ECU支持0x22”只會(huì)質(zhì)問(wèn)你“為什么偶發(fā)回了一個(gè)0x31”。把那些“為什么”都消滅掉才是我心里真正靠譜的協(xié)議棧。