簡介圍繞汽車電子電氣架構中的DoIP核心疑問這份PDF系統(tǒng)梳理了激活線激活、Routine激活、診斷路由轉發(fā)規(guī)則、診斷響應處理以及目前市面常見的兩種DoIP診斷架構。內容面向車載以太網診斷開發(fā)與測試工程師也適合想理解ISO 13400落地細節(jié)的初學者文檔以問答形式拆解Tester與邊緣節(jié)點、邊緣節(jié)點與ECU之間的連接建立、路由激活與報文轉發(fā)過程并點出源地址改寫、重復響應等易踩坑環(huán)節(jié)幫助讀者避開診斷開發(fā)中的典型問題。壓縮包內為1個PDF文件大小318KB便于離線閱讀或打印。目前已有256人學習下載適合作為車載網絡診斷方向的速查與入門參考資料。 做車載診斷的同事大概率都有這種感覺這兩年“DoIP”的出場率比過去十年加起來都高。倒不是協(xié)議本身有多新而是電子電氣架構從分布式ECU往域集中式、中央計算平臺演進診斷流量從CAN總線上搬到了以太網上DoIPDiagnostic over IP順勢成了新平臺的默認配置。很多朋友拿到項目資料第一眼看到《電子電氣架構——DoIP疑問詳解.pdf》這種標題其實核心就一個問題DoIP到底怎么連、怎么用、坑在哪。這篇按我在項目里的經驗把這些問題捋一遍從基礎的連接流程講到DHCP和AutoIP再到排查思路上來。1. 先搞清楚DoIP解決了什么E/E架構變了診斷方式必須跟著變1.1 原來的CAN診斷到底卡在哪傳統(tǒng)車載網絡以CANController Area Network為主力診斷走的是ISO 15765協(xié)議也就是常說的CAN UDS。這條鏈路在分布式架構下夠用但有幾個硬傷一是帶寬不夠。經典CAN最高也就1Mbps后來CAN FD跑到2Mbps、5Mbps但相比以太網動輒100Mbps、1Gbps差距還是數量級?，F(xiàn)代車輛一次OTA刷寫可能要下幾百MB到幾個GB的軟件包靠CAN根本刷不動。二是拓撲結構限制。CAN是總線型共享介質所有ECU掛在同一條總線上診斷儀通過網關訪問不同總線。網關成了唯一的轉發(fā)瓶頸而且多路并發(fā)診斷時網關的報文路由壓力很大。三是靈活性差。CAN診斷通常按物理地址尋址節(jié)點少、關系固定。到域控制器時代軟件功能可以動態(tài)部署到不同計算單元診斷關系也在變物理尋址的方式就很笨重。1.2 DoIP把診斷搬到了IP網絡上DoIPDiagnostic over IP是ISO 13400標準定義的診斷協(xié)議本質是讓UDS診斷報文跑在TCP/IP和UDP/IP之上。對應到OSI模型應用層仍然是UDSISO 14229傳輸層換成TCP/UDP網絡層走IPv4/IPv6物理層則用車載以太網比如100BASE-T1。換個角度理解DoIP就是把原來CAN總線上的那套診斷邏輯原封不動地搬到辦公室網絡里“能上網”的設備上。診斷儀通過網絡找到車輛建立連接然后像發(fā)普通網絡請求一樣發(fā)診斷指令。帶寬問題、并發(fā)問題、跨域路由問題瞬間都緩解了。所以你在《電子電氣架構——DoIP疑問詳解.pdf》這類文檔里看到的一堆術語——路由激活、邏輯地址、VIN識別、TCP/UDP雙通道——全是圍繞著“如何在以太網上可靠地做UDS診斷”展開的。理解了這一點后面所有疑問都能對上號。2. DoIP的網絡模型為什么一條TCP還不夠還要留一個UDP2.1 端口13400和兩種傳輸方式DoIP統(tǒng)一使用TCP端口13400和UDP端口13400這個端口號在ISO 13400里寫死了。很多新手第一步就會問為什么同一個端口TCP和UDP都要用答案是兩種協(xié)議承擔的角色完全不同。UDP是無連接、面向廣播的DoIP用它來做“發(fā)現(xiàn)”類操作。診斷儀剛連上車載網絡時還不知道車輛IP是多少、車上有沒有DoIP節(jié)點怎么找到對方靠的就是UDP廣播。車輛端在UDP 13400端口監(jiān)聽特定的Vehicle Identification Request報文收到后以廣播或單播形式回復自己的IP地址、VIN碼、邏輯地址等信息。這個過程不需要建立連接幾毫秒就能完成非常適合網絡發(fā)現(xiàn)。TCP則負責真正的診斷通信。診斷報文必須可靠到達不能丟包、不能亂序TCP的確認重傳機制天然合適。路由激活、UDS診斷請求/響應、在線刷寫全部走TCP。一句話總結UDP負責“找人”TCP負責“干活”。2.2 DoIP報文的基本結構DoIP報文統(tǒng)一由報頭Header和數據區(qū)Payload組成。報頭里最關鍵的兩個字段是負載類型Payload Type和負載長度Payload Length前者告訴接收方“這條報文是干什么的”后者告訴接收方“后面跟了多少數據”。實際項目里常用的負載類型有負載類型值含義傳輸方式0x0001通用報頭否定應答TCP/UDP0x0004車輛識別請求UDP0x0005車輛識別響應UDP0x0006路由激活請求TCP0x0007路由激活響應TCP0x8001診斷報文物理尋址請求TCP0x8002診斷報文功能尋址請求TCP0x8003診斷報文響應TCP這里想強調一下0x8001是外部診斷儀發(fā)給ECU的物理尋址請求0x8003是ECU回給診斷儀的響應。功能尋址用的是0x8002也就是一條請求可以同時發(fā)給多個ECU用在生命周期同步、總線喚醒這類場景。2.3 完整連接流程先發(fā)現(xiàn)再激活最后通信從診斷儀視角看一次DoIP會話大概是這個節(jié)奏診斷儀發(fā)送UDP廣播的車輛識別請求等待車輛回復車輛識別響應。診斷儀拿到車輛IP、ECU邏輯地址后向車輛的TCP 13400發(fā)起三次握手建立連接。TCP連接建立后診斷儀發(fā)送路由激活請求把自己要用的邏輯地址告訴車輛網關。車輛側路由激活成功后回復響應此時診斷儀和ECU之間的邏輯通路就打通了。接下來所有UDS診斷請求都以0x8001/0x8002格式封裝在TCP載荷里發(fā)送ECU的響應同樣通過TCP返回。整個過程里最容易出問題的是第3步。很多同事以為TCP連上就能發(fā)診斷結果一直收不到響應排查半天發(fā)現(xiàn)是路由激活沒做或者激活類型不被支持。路由激活沒有完成之前網關是不會轉發(fā)任何診斷報文的這一點務必記住。3. DHCP和AutoIP地址拿不到后面全白搭3.1 DoIP節(jié)點怎么獲得IP地址DoIP網絡本質上還是一個IP網絡車輛里的DoIP節(jié)點ECU、網關必須要有IP地址才能通信。地址從哪來兩種主要途徑DHCP和AutoIP。DHCPDynamic Host Configuration Protocol是標準動態(tài)地址分配協(xié)議車輛網關或者外部測試設備可以充當DHCP服務器給DoIP節(jié)點分配地址。AutoIPAutomatic Private IP Addressing則是一種無服務器的本地地址自動配置機制設備在找不到DHCP服務器的情況下會自己從169.254.0.0/16網段里挑一個地址同時通過ARP探測避免沖突。這里要提醒一句很多人搜資料時會把DHCP打成DCHP這也是標題熱詞里出現(xiàn)“doip的dchp和autoip”的原因之一。實際標準寫法是DHCP。3.2 ISO 13400對地址獲取過程的要求ISO 13400里定義了一套邏輯DoIP節(jié)點上電后先嘗試DHCP在一定超時時間內協(xié)議默認值大約2秒到5秒具體看整車廠配置如果沒拿到地址就自動切換到AutoIP給自己配置一個169.254.x.x地址。這個設計非常實用。想想你實際做測試的場景一個ECU從臺架上拿下來直接網線插到電腦網口上現(xiàn)場根本沒有DHCP服務器。如果ECU只知道DHCP一種方式那它就永遠沒有IP根本沒法通信。AutoIP的意義就在于讓設備在“沒有基礎設施”的直連場景下也能自動組成一個簡單的本地網絡地址段固定、不會和公司網絡沖突。反過來如果ECU只支持AutoIP不支持DHCP那在整車環(huán)境下所有節(jié)點都在169.254網段也沒有中心化的地址管理網絡規(guī)模一大就亂了。所以正常做法就是DHCP優(yōu)先、AutoIP兜底。3.3 實際測試里關于DHCP/AutoIP的坑我在這塊踩過的坑不少挑幾個典型的說。第一個坑DHCP服務器響應慢導致反復切換。曾經在某個項目里診斷儀把自己配成DHCP服務器車輛ECU上電時先發(fā)DHCP Discover結果診斷儀還在初始化響應慢了幾百毫秒ECU直接認為DHCP不可用切到了AutoIP。后續(xù)診斷儀按DHCP分配的地址去找ECU自然找不到。解決思路是調整診斷儀的DHCP響應速度或者手動給ECU指定靜態(tài)IP用于測試環(huán)境。第二個坑AutoIP的ARP沖突探測周期比想象中長。AutoIP在選擇地址前要發(fā)送多個ARP探測報文確認沒有其他設備占用。在Ethernet直連時一般幾十毫秒能完成但如果現(xiàn)場有多臺設備同時在起AutoIP沖突概率增加流程可能反復重試導致ECU遲遲無法響應診斷請求。遇到這種情況不要急著抓UDS報文先看ECU的IP是否已經穩(wěn)定配置好。第三個坑VLAN隔離導致UDP廣播看不見。有些新平臺的DoIP入口在域控制器上診斷儀通過OBD口的以太網接到域控制器但域控制器內部把診斷口和內部DoIP節(jié)點劃分到了不同VLAN廣播報文被交換機隔離掉車輛識別請求就永遠到不了目標ECU。排查時別光看抓包軟件先確認VLAN配置是否正確。4. 路由激活與邏輯地址讓診斷儀知道“我要找誰”4.1 邏輯地址為什么這么重要DoIP網絡里有兩個地址體系需要區(qū)分物理地址MAC/IP和邏輯地址。MAC/IP解決的是“報文怎么從一個設備到另一個設備”邏輯地址解決的才是“這條診斷命令是發(fā)給哪個功能實體”。邏輯地址分兩類診斷儀地址和ECU地址。診斷儀地址一般是一個固定的、對整個車輛網絡唯一的地址比如常見的0x0E00。ECU地址則根據整車架構分配一個物理ECU可以有一個或多個邏輯地址。車輛識別響應里會攜帶每個DoIP節(jié)點的邏輯地址列表診斷儀拿到之后才能知道目標ECU的地址。路由激活請求的關鍵載荷就是這個邏輯地址。診斷儀把自己的邏輯地址放在路由激活報文里發(fā)給車輛網關網關記錄下來之后所有來自這個邏輯地址的UDS請求都被允許轉發(fā)。這有點像一個門禁系統(tǒng)——你進門時先刷了卡后面在這個區(qū)域內走動才不會再被攔。4.2 物理尋址和功能尋址的區(qū)別UDS診斷請求里有一個地址類型字段用來區(qū)分目標地址是物理地址還是功能地址。物理尋址Target Address Type 0x02是一條請求發(fā)給一個明確的ECU響應是單獨的。絕大多數診斷診斷讀寫、例程控制、刷寫都走這種模式。功能尋址Target Address Type 0x03是一條請求發(fā)給多個ECU。響應不是單條而是收到請求的每個ECU各自回復一條診斷儀需要輪詢接收。這類請求通常用于需要整車同步的操作比如清除故障碼、進入編程會話、統(tǒng)一復位等。實際使用中功能尋址最容易出現(xiàn)的問題是響應“亂”。多個ECU同時回0x8003診斷報文TCP層沒問題但應用層需要按邏輯地址區(qū)分是哪條響應。如果診斷儀邏輯處理太簡單看到一條響應就當成完整結果很容易漏掉其他ECU的回復。所以在做功能尋址請求前務必確認診斷儀側已經做好了多響應的收集和超時管理。4.3 激活類型與安全激活路由激活請求里還有一個激活類型Activation Type字段。默認情況下用0x00即可表示標準的非安全激活。但在產線刷寫或售后高權限診斷場景整車廠往往會要求安全激活這時需要先通過TLS或其他認證機制完成身份校驗再以有效的激活類型發(fā)起路由激活請求。這部分在實際項目里最容易扯皮。診斷儀說自己發(fā)的是0x00ECU側卻說未認證。查到最后往往是ECU的激活類型配置表里根本不接受0x00必須用廠商自定義的類型值。建議拿到第一個DoIP項目時先找架構文檔確認激活類型支持表不要臆測。5. 實操過程與常見問題排查速查5.1 一套最小可復現(xiàn)的DoIP測試流程如果你手頭有一個支持DoIP的ECU或域控制器想最快驗證整個鏈路我的建議如下準備好一個支持車載以太網的網線轉接盒或開發(fā)板把ECU的以太網口和電腦網口連通。注意車載以太網是100BASE-T1和普通電腦網口的100BASE-TX不通用中間必須有轉換設備。電腦網口開啟DHCP客戶端功能。ECU上電后會自己進入DHCP或無服務器狀態(tài)電腦能從DHCP拿到地址最好拿不到也會自動配一個169.254.x.x地址兩邊大概率能互通。用Wireshark抓包。過濾條件先不要加太復雜直接看ECU啟動后有沒有發(fā)出DHCP Discover或者AutoIP ARP探測。這一步能快速確認底層鏈路是否通了。在Wireshark里用udp.port 13400過濾確認車輛識別廣播能否到達。如果沒有車輛識別響應先排除VLAN和網段問題。使用診斷工具我用過CANoe的DoIP配置和自寫Python腳本兩種方式建立TCP連接發(fā)路由激活請求。注意看響應里的路由激活狀態(tài)0x00表示成功。發(fā)送一條最簡單的UDS請求比如0x10 0x01進入默認會話或者0x22 F1 90讀VIN。如果收到有效的正響應整個DoIP鏈路就通了。5.2 常見問題速查表現(xiàn)象可能原因排查方法TCP連接能建立UDS請求超時沒做路由激活或邏輯地址不對抓包確認是否發(fā)出過0x0006路由激活請求響應狀態(tài)是否為0x00UDP車輛識別廣播發(fā)出去沒有回復廣播域隔離、VLAN配置問題或ECU不支持該識別請求檢查網絡拓撲確認VLAN用單播請求嘗試ECU遲遲不響應診斷ping也不通DHCP或AutoIP一直沒完成抓包看ARP、DHCP報文確認ECU是否拿到169.254或正式IP功能尋址請求后只收到部分響應部分ECU不在線或診斷儀多線程接收邏輯有誤用CANoe監(jiān)控所有TCP連接確認每條0x8003響應都收到刷寫過程中TCP連接中斷傳輸層超時參數太緊或ECU過載檢查ISO 13400相關timeout參數適當放大重傳間隔5.3 一些個人經驗技巧最后分享兩個我一直在用的方法。第一個先“物理”再“邏輯”。遇到DoIP不通不要上來就抓UDS。先看鏈路層PHY有沒有Link、網絡層IP能否ping通、傳輸層TCP三次握手是否成功最后才是應用層。只要IP能通90%的問題就好解決。第二個活用Wireshark的DoIP解析器。過濾框輸入doip可以直接解析DoIP報文能看到負載類型、路由激活狀態(tài)碼、診斷報文里的UDS內容。我在排查路由激活失敗時基本靠這個過濾快速定位問題。另一個小技巧是給測試電腦手動指定一個固定邏輯地址。比如診斷儀地址始終用0x0E00不要自動分配。這樣抓包時看到0x0E00出問題就能確定是診斷儀側的問題排除變量。做DoIP項目到現(xiàn)在最大的體會就是它沒有想象中那么神秘。底層還是TCP/IP那套東西上層還是UDS那套東西DoIP只是在中間做了一層封裝和路由。只要把“發(fā)現(xiàn)—連接—激活—診斷”這條主線走通了剩下的細節(jié)基本就是查表、抓包、調參數的事。本文還有配套的精品資源點擊獲取