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