車載底層 CAN 通信與上層 UDS 診斷協(xié)議開發(fā)技術文檔做車載軟件開發(fā)這幾年我越來越覺得 CANController Area Network控制器局域網(wǎng)和 UDSUnified Diagnostic Services統(tǒng)一診斷服務這兩塊內容是所有想入行或者正在做車載測試、嵌入式開發(fā)的人必須邁過去的兩道坎。你光會點單片機、會點 C 語言在車載領域里其實很難走遠因為車上幾乎所有 ECUElectronic Control Unit電子控制單元之間的信息交互都跑在 CAN 總線上而整車下線檢測、售后故障排查又基本全依賴 UDS 診斷協(xié)議。這篇文章我就圍繞“車載底層 CAN 通信與上層 UDS 診斷協(xié)議開發(fā)”這個主題把我從實際項目里踩過的坑、用過的工具、總結出的方法論完整地分享出來不整虛的。這篇文章適合三類人看一是剛轉行做車載測試或者嵌入式軟件開發(fā)的新人你需要搞懂 CAN 和 UDS 到底是怎么工作的二是已經(jīng)在做 CAN 通信、但想往診斷方向深入一點的工程師本文能幫你把 UDS 那套服務流程理順三是準備面試車載相關崗位的朋友里面不少內容都是高頻考點比如 CAN 時鐘誤差怎么解決、UDS 19 服務 01 子功能怎么用、27 服務種子密鑰流程等等我盡量用大白話講清楚。1. 項目背景與整體架構設計思路1.1 為什么車載開發(fā)離不開 CAN 和 UDS 這條技術鏈路先聊聊背景?，F(xiàn)代汽車里面 ECU 數(shù)量早就不是幾十個的概念了稍微智能一點的車型整車 ECU 數(shù)量能突破一百個。每個 ECU 都要跟其他 ECU 通信比如 BMSBattery Management System電池管理系統(tǒng)要把電池電壓、溫度、SOC 發(fā)給 VCUVehicle Control Unit整車控制器VCU 又要把扭矩請求發(fā)給 MCUMotor Control Unit電機控制器。這么多控制器之間如果全用點對點的線束連接整車線束會重得離譜、成本也壓不住所以必須有一條共享的通信總線。CAN 總線就是干這個事的。CAN 總線是 Bosch 公司在 1986 年提出的一種串行通信協(xié)議最初就是為了解決汽車內部大量控制單元之間的數(shù)據(jù)交換問題。它用兩條差分信號線CAN_H 和 CAN_L就能掛載幾十個節(jié)點抗干擾能力強、實時性好、成本低。直到現(xiàn)在CAN 依然是車載網(wǎng)絡里最主流的底層通信方式。但光是能通信還不夠。車用著用著可能出毛病售后技師得知道是哪個 ECU 報的故障、能不能讀到實時數(shù)據(jù)、要不要刷寫新程序。這時候就需要一套統(tǒng)一的上層診斷協(xié)議讓外部診斷儀能跟任意一個 ECU 對話。UDS 就是這套標準它定義在 ISO 14229 里跑在 CAN 總線之上通過 CAN 幀把診斷請求發(fā)出去ECU 再把診斷響應發(fā)回來。所以你會發(fā)現(xiàn)CAN 是“路”UDS 是“跑在路上的車”兩者是一個底一個上的關系做車載開發(fā)必須把這條鏈路從頭到尾打通。1.2 項目技術架構的分層設計方法這個項目從架構上可以分成三層來看物理層與數(shù)據(jù)鏈路層對應 CAN 控制器和收發(fā)器負責電平轉換、幀收發(fā)、錯誤檢測、仲裁等開發(fā)時主要關心波特率配置、終端電阻、采樣點這些參數(shù)。傳輸層與會話層對應 ISO 15765-2通常叫 TP 層Transport Protocol 傳輸協(xié)議負責把超長的診斷數(shù)據(jù)拆分到多個 CAN 幀里傳輸并在接收端重組。應用層對應 UDS 協(xié)議本身處理各種診斷服務的請求和響應包括會話控制、安全訪問、數(shù)據(jù)讀取、故障碼操作、例程控制等。我們在實際開發(fā)中通常也會按這個分層來組織代碼底層驅動CAN Driver 傳輸協(xié)議層CAN TP 診斷應用層UDS Stack。這樣做的好處是模塊間解耦底層換芯片換了不影響上層邏輯上層增加診斷服務也不用改動傳輸和驅動代碼。我記得第一個完整的項目里我們就直接在 NXP 的 S32K 系列芯片上做這套東西。S32K 的 FlexCAN 模塊用來收發(fā) CAN 幀上層配一個 CAN TP 模塊再往上是自己寫的診斷服務處理邏輯。整個架構理順之后后續(xù)接什么新項目都很快基本就是修改服務表和路由表的事。1.3 關鍵技術點選型與整體開發(fā)流程開發(fā)流程上這個項目大體分為需求分析、AUTOSAR 與非 AUTOSAR 方案選型、協(xié)議棧開發(fā)與集成、臺架/實車測試幾個階段。方案選型這一步很多團隊容易忽略細節(jié)。如果你的項目是基于 AUTOSARAutomotive Open System Architecture汽車開放系統(tǒng)架構的那 CAN Driver、CanIf、CanTp、Dcm 這些模塊都是現(xiàn)成的你主要做配置和集成如果是不帶 AUTOSAR 的裸機開發(fā)或者普通 RTOS 環(huán)境就得自己實現(xiàn)或者移植一套協(xié)議棧。我自己的經(jīng)驗是小項目或者學習階段優(yōu)先考慮自己寫或者用開源的小型協(xié)議棧省去 AUTOSAR 工具鏈那套復雜流程但是量產(chǎn)項目除非團隊里有非常熟悉協(xié)議棧的專家否則還是走 AUTOSAR 成熟方案更穩(wěn)因為診斷協(xié)議棧的邊界情況太多了自己寫很容易漏。這個項目里核心的關鍵技術點有這么幾個CAN 波特率與采樣點計算、CAN 時鐘誤差容錯處理、DBC 報文矩陣設計與解析、UDS 服務分發(fā)與子功能處理、ISO 15765-2 傳輸層分包重組、安全訪問種子密鑰算法、故障碼 DTC 的讀寫清除邏輯。每一個點我都會在后面的章節(jié)里展開講。2. 底層 CAN 通信核心技術解析2.1 CAN 報文結構與總線仲裁機制先過一遍 CAN 報文的組成。標準 CAN 2.0A 的數(shù)據(jù)幀由幀起始SOF、仲裁域Identifier 標識符 RTR 遠程發(fā)送請求位、控制域IDE、DLC 數(shù)據(jù)長度代碼、數(shù)據(jù)域0~8 字節(jié)、CRC 校驗域、ACK 確認位和幀結束組成。開發(fā)時最常打交道的是仲裁域里的 ID這個 ID 不只是報文的標識還決定了總線訪問優(yōu)先級。CAN 總線是載波監(jiān)聽多路訪問/沖突避免CSMA/CA機制多個節(jié)點同時發(fā)報文時靠仲裁段逐位比較顯性位邏輯 0會覆蓋隱性位邏輯 1所以 ID 數(shù)值越小的報文優(yōu)先級越高。比如動力系統(tǒng)的報文一般會給比舒適系統(tǒng)更小的 ID保證優(yōu)先傳輸。我在做 DBCCAN database 數(shù)據(jù)庫文件解析工具的時候經(jīng)常用 python-can 庫來讀報文再結合 cantools 把 DBC 文件轉成解析代碼。這里提一句DBC 文件里每個信號定義了起始位、長度、字節(jié)序Intel 還是 Motorola、縮放因子和偏移量解析時最容易搞錯的是 Motorola 格式也叫大端格式的位序換算很多新手在這兒栽跟頭。我自己的辦法是寫完解析代碼后先用已知報文回灌驗證不要指望一把過。2.2 CAN 時鐘誤差的成因與重同步機制做 CAN 底層驅動或者調試總線故障時時鐘誤差是一個繞不開的問題。每個 CAN 節(jié)點都有自己的晶振晶振本身有精度誤差同時溫度變化、老化也會導致時鐘漂移。當總線上某個節(jié)點的時鐘頻率和主節(jié)點偏差超過一定范圍就會導致采樣點偏移進而產(chǎn)生位錯誤、CRC 錯誤嚴重時整個網(wǎng)絡都通信異常。CAN 協(xié)議為了解決這個問題設計了兩類同步機制硬同步和重同步。硬同步發(fā)生在幀起始的 SOF 位所有節(jié)點重新開始位定時重同步發(fā)生在幀內遇到隱性到顯性的跳變沿時每個節(jié)點根據(jù)自己的相位誤差調整采樣點位置。CAN 控制器通過同步跳轉寬度SJWSynchronization Jump Width來限制每次重同步的最大調整量。項目里有一次現(xiàn)象非常典型某塊板子單獨測 CAN 收發(fā)正常但掛到臺架上就瘋狂報 BUS OFF。排查下來發(fā)現(xiàn)是板載晶振負載電容匹配不對導致實際頻率偏差超過 1.5%超出了 CAN 控制器容忍范圍。后來把晶振換成精度更高的有源晶振問題就消失了。所以選型時不要貪便宜用普通陶瓷諧振器一定要用晶振并且按芯片手冊要求配置正確的負載電容。另外在軟件里盡量把采樣點配置在位的 75%~80% 位置這個區(qū)間對各種干擾的容錯能力最好。2.3 CAN 波特率配置與采樣點計算波特率配置本質上就是給位時間分段。CAN 的一個位時間bit time被分成四段同步段SS固定 1 個時間份額、傳播時間段PTS、相位緩沖段 1PBS1、相位緩沖段 2PBS2。采樣點就是 PBS1 結束的位置。計算過程舉個例子。假設芯片外設時鐘頻率 40 MHz需要配置 500 kbps 波特率那每個位的時間就是 2 us時間份額TqTime Quantum可以做如下分配Prescaler 分頻值取 4則 Tq 4 / 40 MHz 0.1 us一個位由 20 個 Tq 組成。把同步段設為 1 TqPTS 設為 7 TqPBS1 設為 8 TqPBS2 設為 4 Tq那么采樣點 (1 7 8) / 20 80%。這樣配置可行。反過來如果已知目標采樣點比例也能反推各段長度。實際操作里我用 S32K 的 FlexCAN 或者 STM32 的 bxCAN 時都會先用邏輯分析儀抓一下實際波形測量顯性位寬度看波特率和采樣點對不對。不要完全信任代碼注釋里的計算結果因為芯片參考手冊里對傳播時間段和相位緩沖段的命名可能不同一個字母沒對上結果就完全不同。2.4 CAN FD 與車載以太網(wǎng)對底層設計的補充影響現(xiàn)在的新車型越來越多地引入 CAN FDCAN with Flexible Data-rate和車載以太網(wǎng)。CAN FD 相比經(jīng)典 CAN數(shù)據(jù)段波特率可以更高通常 2 Mbps 甚至 5 Mbps一幀最多能帶 64 字節(jié)數(shù)據(jù)對診斷刷寫這種大塊數(shù)據(jù)傳輸非常友好。做底層開發(fā)時如果工程里同時用到經(jīng)典 CAN 和 CAN FD要注意控制器是否支持混合模式以及終端電阻匹配在高速率下是否有更高的要求。CAN FD 的仲裁段和數(shù)據(jù)段波特率可以不同這意味著采樣點配置要分別計算。另外CAN FD 在總線錯誤處理上有個顯著區(qū)別經(jīng)典 CAN 發(fā)錯時所有節(jié)點都會響應錯誤幀而 CAN FD 只有錯誤節(jié)點自己發(fā)錯誤標志這部分在實際調試時容易被表象誤導需要特別留意。如果項目還涉及 UDS over Ethernet通常叫 DoIPDiagnostic over Internet Protocol基于 IP 的診斷協(xié)議那底層就完全變了不再是 CAN 幀而是一整個 TCP/IP 協(xié)議棧。DoIP 的優(yōu)勢是帶寬大適合遠程診斷和 OTA 刷寫但它在安全接入、端口管理上比 CAN 診斷復雜不少。后續(xù)如果做跨域控制器開發(fā)比如智能座艙或自動駕駛域控DoIP 幾乎是必選項這一點可以在第 7 節(jié)展開講。3. CAN 通信開發(fā)實操與驅動實現(xiàn)要點3.1 CAN 控制器初始化與收發(fā)流程我先講一下最基礎的 CAN 驅動初始化步驟以 STM32 的 bxCAN 為例使能相關時鐘GPIO 時鐘和 CAN 外設時鐘。配置 GPIO 復用引腳CAN_RX 和 CAN_TX 引腳要配置為復用功能。配置 CAN 工作模式正常模式或環(huán)回模式。調試初期建議先用環(huán)回模式Loopback不需要外部節(jié)點就能確認控制器本身收發(fā)正常。設置波特率和位時間參數(shù)。配置過濾器經(jīng)典 CAN 的報文過濾在硬件層做可以按 ID 范圍過濾也可以按掩碼匹配。如果沒有正確配置過濾器會導致收不到任何報文這是新手最容易犯的錯。使能中斷發(fā)送中斷、接收中斷、錯誤中斷、總線關閉中斷分別處理。發(fā)送流程應用層把一幀數(shù)據(jù)打包成 CAN_TxHeaderTypeDef然后調用 HAL_CAN_AddTxMessage等待發(fā)送完成中斷后在回調里釋放發(fā)送緩沖。接收流程CAN 控制器收到有效幀后觸發(fā)接收中斷在 HAL_CAN_RxFifo0MsgPendingCallback 中調用 HAL_CAN_GetRxMessage 把數(shù)據(jù)取出來再交給上層協(xié)議棧。項目中比較容易被忽略的一點是CAN 控制器的發(fā)送郵箱數(shù)量是有限的bxCAN 是 3 個郵箱如果上層短時間內投遞大量報文發(fā)送郵箱會滿此時調用 AddTxMessage 會返回錯誤。正確的做法是做一個發(fā)送隊列把待發(fā)送報文緩存到內存里然后在發(fā)送完成中斷里逐個補發(fā)。我見過有人圖省事不寫隊列結果總線負載一高診斷請求周期性丟失排查了半天。3.2 基于 S32K FlexCAN 的工程實踐S32K 的 FlexCAN 跟 STM32 的 bxCAN 差別不小。FlexCAN 使用的是消息緩沖區(qū)MBMessage Buffer機制每個 MB 可以獨立配置成發(fā)送或接收緩沖區(qū)數(shù)量多、靈活性高。開發(fā)時你需要初始化 FlexCAN 模塊選擇時鐘源、設置分頻、設置位時間。分配 MB比如 MB0~MB7 用于接收MB8~MB15 用于發(fā)送。配置中斷每個 MB 都有獨立中斷也可以通過 FIFO 模式接收。使能 FlexCAN 的協(xié)議引擎啟動模塊。我在實際項目里習慣把 FlexCAN 的接收 FIFO 打開。接收 FIFO 的好處是硬件自動緩沖收到的報文即使應用層暫時來不及處理也不容易丟幀。但要注意過濾表還是要配否則 FIFO 緩存里全是無關報文很快就會被塞滿。S32K 的時鐘配置也比較講究。FlexCAN 模塊時鐘可以來自 SIRCSlow Internal RC 慢速內部時鐘、FIRC、SOSCSystem Oscillator 系統(tǒng)振蕩器或者 PLL不同時鐘源在 CAN 波特率配置時會得到不同的 Prescaler 范圍。開發(fā)時我建議先從 SOSC 這種穩(wěn)定性高的時鐘源開始確認整車網(wǎng)絡通信正常后再去優(yōu)化功耗相關的時鐘切換不要一上來就搞復雜的時鐘樹。3.3 DBC 報文解析與波形驗證方法整車開發(fā)中每個 ECU 的 CAN 報文信號定義都會維護在 DBC 文件里。DBC 可以理解為 CAN 通信的“數(shù)據(jù)庫”里面描述了每條報文的周期、ID、數(shù)據(jù)字節(jié)、信號布局。常用工具除了 Vector CANdb還可以用開源的 cantools 庫。用 cantools 解析 DBC 報文很簡單import cantools import can db cantools.database.load_file(vehicle.dbc) bus can.interface.Bus(channelcan0, bustypesocketcan) for msg in bus: if msg.arbitration_id db.get_message_by_name(VCU_Status).frame_id: data db.decode_message(msg.arbitration_id, msg.data) print(data)代碼里 db.decode_message 返回一個字典鍵是信號名比如 vcu_speed、soc 等。開發(fā)前期我強烈建議準備一套可復現(xiàn)的測試腳本每收到一幀報文就打印再跟 DBC 信號的值人工比對確認解析正確。波形驗證方面示波器或邏輯分析儀是必需品。我調試波特率時經(jīng)常用邏輯分析儀抓 CAN_H 與 CAN_L 的差分波形測量最短顯性位的時間。如果時鐘配置正確最短顯性位寬度應該正好等于 1/fdfd 為數(shù)據(jù)段波特率。如果測出來偏寬或偏窄就能反過來校準 Prescaler 和位時間參數(shù)。這個方法在任何一款 MCU 上都通用不用依賴廠商調試工具。4. 上層 UDS 診斷協(xié)議開發(fā)與實現(xiàn)細節(jié)4.1 UDS 協(xié)議?？蚣芘c尋址模式UDS 是 ISO 14229 定義的應用層診斷協(xié)議。它跑在不同傳輸協(xié)議之上CAN、LIN、以太網(wǎng)等但在 CAN 上最常用的載體是 ISO 15765-2CAN TP。UDS 的核心思路是“請求-響應”外部診斷儀發(fā)出請求ECU 執(zhí)行后返回響應。診斷儀和 ECU 之間是一問一答的模式。尋址方式分為物理尋址和功能尋址。物理尋址是點對點通信請求幀的目標地址是某個具體 ECU 的診斷地址只有這個 ECU 響應功能尋址是廣播式的比如給所有 ECU 發(fā)“進入擴展會話”的請求ID 通常是 0x7DF所有支持該服務的 ECU 都會響應。這個差異在開發(fā)測試中時要特別注意用功能尋址發(fā)“讀取 DID”請求會收到多個 ECU 的響應數(shù)據(jù)解析不能只按單 ECU 處理。從開發(fā)實現(xiàn)角度看UDS 協(xié)議棧可以拆成三層CAN 驅動負責收發(fā)原始幀CAN TP 層負責處理長報文的分包傳輸將 4095 字節(jié)的最大診斷消息分成多個單幀/連續(xù)幀并在接收端重組UDS 層負責解析請求報文里的 SIDService Identifier 服務標識符和子功能調用對應的處理函數(shù)再組響應報文。4.2 UDS 常用服務功能拆解19 27 31 34 36 37開發(fā)診斷功能時最常用到的 UDS 服務是以下幾個診斷會話控制0x10包括默認會話、編程會話和擴展會話。很多診斷服務只在非默認會話下才能執(zhí)行所以收到請求后先切會話是標準操作。比如 0x10 03 進入擴展會話ECU 如果支持則回 0x50 03。安全訪問0x27涉及種子和密鑰的交換用于保護寫入類操作。先發(fā)請求種子比如 0x27 01ECU 返回一個種子值診斷儀用特定算法計算密鑰0x27 02發(fā)回ECU 校驗一致后解鎖。注意安全訪問有失敗計數(shù)器和延遲時間連續(xù)輸錯密鑰會鎖死一段時間。例程控制0x31執(zhí)行 ECU 內部特定程序比如擦除 Flash、檢查通信、學習轉向角傳感器等。典型流程是 0x31 01 開始例程、0x31 02 停止例程、0x31 03 查詢例程結果。例程編號通常是 2 字節(jié)或 3 字節(jié)的 DID 地址。請求下載0x34、傳輸數(shù)據(jù)0x36、請求退出傳輸0x37這三個服務合起來構成完整的 Flash 刷寫流程。先通過 0x34 告訴 ECU 要下載的數(shù)據(jù)長度和內存地址ECU 回一塊最大傳輸字節(jié)數(shù)比如 64 字節(jié)之后診斷儀分成多個 0x36 請求把數(shù)據(jù)塊發(fā)過去最后用 0x37 結束傳輸。讀取 DID0x22和寫入 DID0x2E用來讀寫 ECU 內部數(shù)據(jù)標識符Data Identifier比如 VIN、軟硬件版本號、標定參數(shù)、采集的電壓溫度等。讀取 DID 是售后診斷里最常用的服務沒有之一。讀取/清除故障碼0x19、0x140x19 有很多子功能其中 01 表示按狀態(tài)掩碼讀取故障碼02 表示讀取特定故障碼的快照數(shù)據(jù)04 表示讀取故障碼擴展數(shù)據(jù)。清除故障碼用 0x14一般格式是 0x14 FF FF FF FF 清除所有 DTC。實際項目里UDS 服務的返回碼NRCNegative Response Code要格外重視。ECU 不支持請求的服務時要返回 0x7F SID NRC。常見的 NRC 有 0x10一般拒絕、0x11服務不支持、0x12子功能不支持、0x13報文長度或格式錯誤、0x22條件不滿足、0x31請求超出范圍、0x33安全訪問被拒絕、0x78請求正在處理需要診斷儀等待。在協(xié)議棧里我建議把 NRC 處理做成一張映射表方便上層直接查。4.3 會話管理、安全訪問與 DTC 管理的核心流程UDS 的狀態(tài)管理是整個診斷邏輯里最容易出問題的地方。每個 ECU 必須知道自己當前處在什么會話里因為不同會話能執(zhí)行的服務集合不同。默認會話0x01下只能執(zhí)行基本讀操作擴展會話0x03下能執(zhí)行寫操作和例程控制編程會話0x02下主要執(zhí)行刷寫相關服務。會話還有超時機制一般在非默認會話停留超過一定時間通常是 5 秒ECU 要自動回到默認會話。這個超時時間在實車上往往被測試團隊專門拿出來考協(xié)議棧里一定要做成可配置的參數(shù)。DTCDiagnostic Trouble Code 診斷故障碼的管理是我建議單獨寫成一個模塊的。DTC 的狀態(tài)信息不是簡單的 0/1而是由多個狀態(tài)位構成比如當前存在、歷史存在、當前失敗、上次失敗、測試未完成等0x19 服務可以按不同子功能讀取。開發(fā)時我習慣用一組 bit 掩碼表示每個 DTC 的狀態(tài)需要上報時再按 UDS 要求的格式填充成響應報文。清除 DTC 時要考慮條件——很多 ECU 只有在特定條件下才允許清除比如車速為 0、點火開關 ON如果條件不滿足要返回 0x22 條件不滿足。4.4 基于 CAN TP 的 UDS 報文分包傳輸原理當 UDS 報文超過 8 字節(jié)時就需要 CAN TP 來分包。ISO 15765-2 定義了四種幀類型單幀SFSingle Frame數(shù)據(jù)長度 7 字節(jié)如果使用擴展地址則更少直接一幀發(fā)完。首幀F(xiàn)FFirst Frame數(shù)據(jù)長度超過 7 字節(jié)時發(fā)送第一幀包含 12 位總長度信息。連續(xù)幀CFContinuous Frame后續(xù)數(shù)據(jù)幀每幀最多 7 字節(jié)數(shù)據(jù)帶序列號。流控幀F(xiàn)CFlow Control接收方告訴發(fā)送方每次可以連續(xù)發(fā)多少個連續(xù)幀以及兩個連續(xù)幀之間的最小間隔時間。實際刷寫 ECU 時一次請求下載的數(shù)據(jù)大小可能到 1 MB分包和重組都是在 CAN 驅動之上自動完成的。我在實現(xiàn) CAN TP 模塊時踩過一個比較典型的坑接收方向發(fā)送方發(fā)完流控幀后如果連續(xù)幀之間的間隔控制得不夠有些 CAN 控制器在 FIFO 溢出的情況下會靜默丟幀而上層還在干等重組完成最后導致整個診斷會話超時。解決辦法是增加 CAN 接收 FIFO 深度并且在應用層做超時重傳機制不要完全依賴 CAN 控制器的錯誤處理。5. 上層診斷與底層 CAN 的銜接方式5.1 從 UDS 服務到 CAN 幀的完整數(shù)據(jù)流我畫一下我自己平時腦中的完整數(shù)據(jù)流診斷儀發(fā)送一個 0x22 F1 90 的請求要讀取 VIN 碼的前幾個字節(jié)。這個請求先經(jīng)過 UDS 層封裝成診斷消息包含 SID 和參數(shù)CAN TP 層根據(jù)長度決定用單幀還是多幀發(fā)送最終交給 CAN 驅動打包成 CAN 報文發(fā)出。ECU 收到這個報文后CAN 驅動先確認收幀CAN TP 層把分片重組UDS 層解析出 SID0x22、DID0xF190查表找到 VIN 碼存儲位置將數(shù)據(jù)組裝成響應報文再按照 CAN TP 的分包規(guī)則逐幀發(fā)回給診斷儀。數(shù)據(jù)流向說起來簡單但真在代碼里實現(xiàn)時最麻煩的是異步并發(fā)。比如 ECU 正在執(zhí)行一個耗時的例程控制期間又收到一個讀取 DID 的請求協(xié)議棧必須保證不能因為正在響應上一個請求就忽略新請求。我的做法是讓診斷模塊維護一個簡單狀態(tài)機空閑狀態(tài)、等待 CAN TP 發(fā)送完成狀態(tài)、等待應用處理完成狀態(tài)。只有狀態(tài)機處于空閑時新請求才會被接受否則適當?shù)胤祷?0x78 請求處理中讓診斷儀稍后重試。5.2 診斷報文與底層驅動的接口設計接口設計的核心是解耦。我在代碼里定義了一組操作函數(shù)指針比如CAN_Transmit(uint32_t id, uint8_t* data, uint8_t len)CAN_Receive(uint32_t* id, uint8_t* data, uint8_t* len)CANTP_Send(uint8_t* data, uint16_t len)CANTP_Receive(uint8_t* data, uint16_t* len)所有上層 UDS 邏輯只跟 CANTP_Send/CANTP_Receive 打交道不直接操作 CAN 驅動。這樣做的好處是后續(xù)要從 CAN 切到 LIN 或者以太網(wǎng)只需要替換底層傳輸接口的實現(xiàn)UDS 層代碼完全不用變動。我還習慣在接口層加一個環(huán)形緩沖區(qū)存放接收到的診斷報文。CAN 接收中斷里只負責把數(shù)據(jù)拷貝進環(huán)形緩沖區(qū)然后置一個事件標志主循環(huán)里檢測到事件后調用 CAN TP 和 UDS 流程處理。這種方式比直接在中斷里做完整協(xié)議解析要安全得多不會因為中斷耗時過長導致丟幀。5.3 上層應用如何正確映射診斷結果UDS 服務執(zhí)行后結果不只是 0x00成功或 NRC還可能攜帶大量數(shù)據(jù)。比如 0x19 02 讀取 DTC 快照響應里會包含 DTC 編號、DTC 狀態(tài)、快照記錄編號、DID 列表和數(shù)據(jù)。上層應用比如儀表盤上的故障燈邏輯不能只是簡單判斷“有故障碼”還必須正確解析 DTC 的狀態(tài)位區(qū)分“當前故障”和“歷史故障”。我見過一個低級但不罕見的 bug上層代碼把 0x19 01 響應的 DTC 狀態(tài)字節(jié)直接當作布爾值導致只要歷史故障存在故障燈就常亮不滅。正確的做法是按位解析狀態(tài)比如 bit01 表示測試失敗當前故障bit41 表示歷史存在但不一定是當前故障。這些細節(jié)做不到位排查問題會浪費大量時間。6. 開發(fā)工具鏈與實測環(huán)境搭建6.1 常用的 CAN 上位機工具與總線分析儀開發(fā) CAN 通信和 UDS 診斷手里沒有幾把趁手的工具不行。我常用的是CANoeVector功能最全支持 CAPL 腳本、DBC 加載、UDS 診斷控制是車廠和 Tier1 的標配工具。缺點就是貴個人學習不建議直接上。PCAN-View / PCAN-ExplorerPEAK便宜實用適合日?？磮笪暮秃唵卧\斷。CANable / 兼容虛擬串口的 USB-CAN 工具適合個人開發(fā)開源的 cantools Python 就能配合做自動化測試。周立功 ZCANPRO國產(chǎn)工具里不錯的界面順手支持 CAN FD。如果你是剛入門我建議直接從 PCAN 或者國產(chǎn) USB-CAN 開始配合 Wireshark 的 CAN 解析插件能直觀看到每一幀的 ID、長度、數(shù)據(jù)還能統(tǒng)計總線負載率和錯誤幀。等需要做復雜仿真和自動化測試時再考慮上 CANoe。6.2 搭建一套可復現(xiàn)的 UDS 自動化測試腳本自動化測試是保證診斷協(xié)議棧質量的關鍵。我自己習慣用 Python 寫一套輕量級測試框架核心代碼類似import can import cantools import uds bus can.interface.Bus(channelPCAN_USBBUS1, bustypepcan) ecu uds.Client(bus, request_id0x7E0, response_id0x7E8) # 進入擴展會話 resp ecu.request(0x10, 0x03) assert resp.sid 0x50 and resp.data[0] 0x03 # 讀取 VIN resp ecu.request(0x22, 0xF1, 0x90) print(resp) # 安全訪問示例 seed ecu.request(0x27, 0x01).data[0] key calculate_key(seed) resp ecu.request(0x27, 0x02, key) assert resp.sid 0x67這套腳本跑起來后基本能在一個晚上把常用的 UDS 服務全部回歸一遍。我特別建議在自動化腳本里加隨機性測試隨機間隔發(fā)送診斷請求、隨機切換會話、隨機輸入非法參數(shù)很多協(xié)議棧的隱藏問題就是在這種壓力測試下暴露出來的。6.3 臺架與實車聯(lián)調時的注意事項臺架測試時要確保 CAN 網(wǎng)絡里沒有其他 ECU 干擾最好用獨立電源避免地電位差異影響通信。實車聯(lián)調時需要注意的點更多一定要先確認整車上電狀態(tài)不要讓診斷儀誤觸發(fā)了高壓部件相關例程另外實車 CAN 網(wǎng)絡負載率高診斷響應時間往往會比臺架慢腳本里的超時時間不能設得太短。有一次我在實車上做刷寫測試刷到一半總線出現(xiàn)大量錯誤幀后來發(fā)現(xiàn)是 OBD 口上同時掛了好幾臺診斷設備節(jié)點太多終端電阻被破壞導致了反射。后來規(guī)定測試時只允許掛一個診斷儀其他設備全部拔掉問題就沒了。這個教訓讓我記住了一件事現(xiàn)場排查 CAN 問題第一步永遠先檢查物理連接再看波形最后才懷疑軟件協(xié)議棧。7. 常見問題與排查技巧實錄7.1 CAN 總線 BUS OFF 與錯誤幀的定位思路CAN 總線出現(xiàn) BUS OFF 時節(jié)點會暫時離開總線不再參與通信。排查思路我一般按下面的順序用總線分析儀看錯誤幀的類型是位錯誤、填充錯誤、CRC 錯誤還是 ACK 錯誤。檢查波特率是否一致最快速的方法是抓波形測一個位的寬度對比各節(jié)點配置。檢查終端電阻總線上應該在兩端各有一個 120 歐的電阻萬用表測 CAN_H 和 CAN_L 之間的電阻應該約 60 歐。檢查是否有節(jié)點在總線空閑時主動發(fā)送數(shù)據(jù)導致持續(xù)沖突。錯誤幀里最容易忽略的是 ACK 錯誤。CAN 幀在發(fā)送完成后發(fā)送節(jié)點期望至少有一個其他節(jié)點回 ACK 顯性位。如果總線上只有發(fā)送節(jié)點一個節(jié)點或者接收節(jié)點的控制器沒有配置成監(jiān)聽模式發(fā)送就會一直報 ACK 錯誤。這在單節(jié)點臺架測試時非常常見但不代表協(xié)議棧有問題屬于測試環(huán)境配置問題。7.2 診斷超時與無響應的常用排查路徑UDS 請求發(fā)出去ECU 一直沒響應。我排查時第一步不是看協(xié)議棧而是先看 CAN 層診斷儀能不能看到自己發(fā)的報文ECU 有沒有收到如果 CAN 層有收發(fā)再確認響應 ID 是否和 DBC 里一致。很多新開發(fā)的項目ECU 的物理尋址請求 ID 和響應 ID 配置錯了比如請求 ID 是 0x7E0響應用了 0x7E8結果診斷儀在 0x7E9 上等必然無響應。如果 CAN 層正常再看會話狀態(tài)。ECU 可能還停留在默認會話而請求的服務只能在擴展會話下執(zhí)行此時 ECU 會回 NRC 0x22 或直接無響應。此時手動先發(fā)一個 0x10 03 進入擴展會話再重新發(fā)原請求往往問題就解決了。最后再看安全訪問狀態(tài)寫操作被拒絕時先執(zhí)行 0x27 流程再重試。7.3 UDS 協(xié)議棧狀態(tài)機常見狀態(tài)卡死問題說一個我在自己項目里修過的問題。ECU 在執(zhí)行 0x31 例程控制時如果例程內部因為硬件等待卡住UDS 狀態(tài)機一直停留在“正在處理例程”狀態(tài)之后診斷儀發(fā)任何服務都不響應。后來我在例程執(zhí)行邏輯里加了一個看門狗計數(shù)器超過 3 秒強制返回 NRC 0x10 并恢復空閑狀態(tài)這個問題才算解決。協(xié)議棧狀態(tài)機設計的時候一定要考慮所有可能卡死的路徑。比如正在等待 CAN TP 發(fā)送完成時如果 CAN 控制器因為總線錯誤關閉了狀態(tài)機會永遠等不到發(fā)送完成標志。這時候需要一個全局超時超時后強制復位傳輸層狀態(tài)。我在代碼里專門加了一個診斷模塊的 tick 函數(shù)每 10 ms 調用一次負責檢查各種超時條件。這個設計雖然簡單但在項目里救了很多次場。7.4 常見問題速查表問題現(xiàn)象可能原因快速排查方法總線上收不到任何報文MCU 引腳復用不對檢查 GPIO 配置和 CAN TX/RX 波形偶發(fā)丟幀總線錯誤率高采樣點配置不匹配抓波形計算位寬調整位時間參數(shù)UDS 請求無響應請求 ID / 響應 ID 不一致核對 DBC 和診斷配置服務報 NRC 0x31請求參數(shù)超出范圍檢查 DID、例程編號、數(shù)據(jù)長度清除 DTC 失敗清除條件不滿足檢查整車狀態(tài)條件比如車速、擋位刷寫中途失敗0x36 塊大小或序列號錯誤核對最大傳輸字節(jié)和塊序號安全訪問一直被拒種子密鑰算法不匹配從種子生成模塊排查確認 key 長度和字節(jié)序8. 后續(xù)擴展與接口趨勢分析8.1 從 CAN 診斷到 DoIP 的架構演進現(xiàn)在很多新車型開始引入 DoIP主要是因為軟件刷寫的包越來越大傳統(tǒng) CAN 刷寫一個控制器可能要幾十分鐘而以太網(wǎng)只需幾分鐘。DoIP 的協(xié)議棧跟 CAN 時代的思路完全不同它基于 TCP/IP診斷報文使用 ISO 13400 封裝邏輯上更接近網(wǎng)絡開發(fā)。如果之前只做過 CAN 上的 UDS轉向 DoIP 時要重點理解三個概念DoIP 實體通過 UDP 廣播做車輛發(fā)現(xiàn)Vehicle Announcement 車輛公告TCP 建立可靠的診斷連接每個診斷請求響應通過 payload type 區(qū)分不同的消息類型。物理和邏輯上DoIP 的診斷儀要先拿到車的 IP 地址再發(fā)起 TCP 連接連接建立后才能發(fā)送 UDS 數(shù)據(jù)。8.2 CAN FD 和以太網(wǎng)對上層診斷協(xié)議的支撐變化CAN FD 對 UDS 最大的幫助就是單幀能帶的字節(jié)數(shù)變多了。經(jīng)典 CAN 一次只能傳 8 字節(jié)很多 UDS 響應要拆好幾幀CAN FD 一幀能到 64 字節(jié)0x22 讀取大塊 DID 的響應很多時候一幀就搞定了。但要注意UDS over CAN FD 的地址格式和 N_PDU 結構與經(jīng)典 CAN 并不完全一致傳輸層在數(shù)據(jù)長度對齊上有區(qū)別實現(xiàn)時不能直接把經(jīng)典 CAN TP 代碼拿來改個名字就用。以太網(wǎng)場景下UDS 可以走 TCP/IP使用 DoIP 封裝診斷請求和響應的體量不再受 CAN 幀長限制但仍然要遵循 UDS 的請求響應模型。對于刷寫類服務0x34/0x36/0x37DoIP 為大量數(shù)據(jù)的快速傳輸提供便利同時配合 TLS 做加密通道這對車載信息安全也是加分項。8.3 信息安全需求對 UDS 開發(fā)的影響現(xiàn)在主機廠對診斷安全的要求越來越嚴。以前 0x27 安全訪問可能只是簡單的種子固定算法密鑰現(xiàn)在很多項目要求用 AES 對稱加密做密鑰校驗還有的在傳輸層就要求加密通信。UDS 開發(fā)者也必須了解安全啟動Secure Boot和刷寫校驗的機制比如在 0x34 請求下載階段就要把固件的校驗信息哈希值或簽名一并傳給 ECUECU 在寫入和啟動時做校驗防止未授權程序被刷進去。信息安全這塊很容易被只做功能開發(fā)的工程師忽略但說實話直接決定一個 ECU 能不能過車廠的安全審核。我自己在這方面的經(jīng)驗是盡早讓安全團隊介入?yún)f(xié)議設計不要等代碼寫完了再補另外種子和密鑰算法的實現(xiàn)一定不要硬編碼在 UDS 層代碼里做成一個獨立的安全模塊方便審計和替換。9. 項目總結與經(jīng)驗沉淀9.1 關鍵技術難點回顧整個項目做下來我覺得最考驗人的不是單個協(xié)議的理解而是多層協(xié)議棧的聯(lián)調和異常處理。CAN 層要考慮物理層信號質量、時鐘誤差、總線仲裁CAN TP 層要處理分包重組和流控UDS 層要管理會話、安全、服務分發(fā)和 NRC 映射。任何一層出現(xiàn)問題最終表現(xiàn)可能都是“診斷沒響應”但根因可能在完全不同的層面。這也是為什么我特別強調逐層排查的方法論。9.2 踩坑之后總結的幾條開發(fā)原則第一先做最小可行鏈路。在寫任何復雜診斷業(yè)務之前先讓 CAN 驅動能自發(fā)自收一個單幀 UDS 請求比如 0x10 01 回 0x50 01。這條路通了再往上加功能會省去大量聯(lián)調時間。第二協(xié)議棧代碼必須可觀測。我建議在每個模塊的入口和出口都加可配置的日志打印開發(fā)階段打開量產(chǎn)階段關閉。沒有日志車載現(xiàn)場出現(xiàn)問題時只能靠猜。第三所有超時都做成可配置的。不同的總線負載、不同的 ECU 性能診斷超時時間差異很大。把超時時間定義成宏或者配置項而不是直接在代碼里寫死后續(xù)做跨項目移植時會非常省心。9.3 從項目本身延伸出去的進一步學習路徑如果你看完文章想繼續(xù)深入我建議按這個路徑走先自己寫一個基于 STM32 的最小 CAN 驅動把收發(fā)調通然后用 PCAN 加 PCAN-View 看報文再寫一個簡單的 CAN TP 模塊用自己的上位機測試 UDS 0x10 和 0x22 服務最后再考慮集成安全訪問和刷寫功能。每一步都有明確的驗證手段不會覺得迷茫。另外強烈建議多讀幾遍 ISO 14229 和 ISO 15765-2 的原文。雖然看標準文檔很枯燥但所有工具的底層邏輯都源自這幾份文檔。等你在實際項目里碰到協(xié)議棧的邊界問題再回頭看標準里的描述會突然有種豁然開朗的感覺。最后就留一句我自己的體會車載開發(fā)這一行技術棧再深終究是給整車質量兜底的工程活。把每一個報文、每一個狀態(tài)位、每一個超時時間都摳清楚比追求新潮框架更有意義。希望這篇文章能幫你少踩幾個坑。