基于車載以太網(wǎng)的刷寫過程問題故障診斷案例

【摘" 要】隨著車載以太網(wǎng)的逐漸普及，應(yīng)用場景也越來越多。在主機(jī)廠，總裝線體會(huì)在電檢工位進(jìn)行診斷、刷寫、檢測、維修。售后市場也會(huì)存在檢測、維修，呈現(xiàn)多種多樣的故障類型。文章通過借用Wireshark的TCP分析器跟蹤每個(gè)TCP會(huì)話的狀態(tài)，對TCP數(shù)據(jù)包常見問題結(jié)構(gòu)進(jìn)行剖析。

【關(guān)鍵詞】車載以太網(wǎng)；刷寫；診斷；測試

中圖分類號：U463.6" " 文獻(xiàn)標(biāo)識碼：A" " 文章編號：1003-8639（ 2024 ）04-0085-04

Fault Diagnosis Case of Flashing Process Problems Based on Onboard Ethernet

WANG Yusen，LIU Yafei，LIU Changling，LIU Ke，LI Jiaming，ZHANG Yujing

（Zhejiang Jirun Automobile Co.，Ltd.，Ningbo 315000，China）

【Abstract】With the gradual popularization of in car Ethernet，the application scenarios are also increasing. In the host factory，the final assembly line will be diagnosed，flashed，inspected，and repaired at the electrical inspection station；The after-sales market also involves detection and maintenance，presenting a variety of fault types. This article analyzes the common problem structures of TCP packets by borrowing Wireshark's TCP analyzer to track the status of each TCP session.

【Key words】vehicle ethernet；brush writing；diagnosis；test

在軟件定義汽車的時(shí)代，多傳感器數(shù)據(jù)融合、高精度地圖、車內(nèi)網(wǎng)絡(luò)與車外網(wǎng)絡(luò)的交互等已成常態(tài)化，信息量的變化引導(dǎo)著帶寬的變化，而車載以太網(wǎng)的應(yīng)用也成為OEM的主流選擇。隨著幾代汽車工程師的努力，已將安全要求高、協(xié)議復(fù)雜、測試更嚴(yán)格的車載以太網(wǎng)變得更加穩(wěn)定。作為主干網(wǎng)絡(luò)、中央網(wǎng)關(guān)的引入，DoIP診斷通過TCP/IP和以太網(wǎng)進(jìn)行，實(shí)現(xiàn)遠(yuǎn)程和高速診斷，速度高達(dá)100Mb/s，使得DoIP診斷比CAN診斷快200倍，可以在復(fù)雜的診斷任務(wù)和刷新應(yīng)用的情況下極大地節(jié)約時(shí)間和成本，但也相比傳統(tǒng)總線處理經(jīng)驗(yàn)更少，更難排查。

1" 常見故障

當(dāng)刷寫歷程中斷后，原因分析、現(xiàn)狀調(diào)查等需要查閱大量資料來應(yīng)對刷寫故障，使用Wireshark抓包會(huì)出現(xiàn)幾種常見故障。本文以吉利某車型為例，收集、整理如下。

1）TCP Dup ACK（重復(fù)應(yīng)答）。在滿足以下所有條件時(shí)設(shè)置：①段大小為0；②窗口大小不為0，并且未更改；③下一個(gè)預(yù)期的序列號和上次看到的確認(rèn)號不為0（連接已建立）。未設(shè)置SYN、FIN和RST。如圖1所示，XXX表示第幾個(gè)包（164），X表示第幾次請求（#1，#2，#3）。丟包或者亂序的情況下，會(huì)出現(xiàn)該標(biāo)志。圖1紅框?yàn)榈?64序列第0次請求389的包，重復(fù)3次申請。

2）TCP Fast Retransmission（快速重傳）。一般快速重傳算法在收到3次冗余的ACK，即3次[TCP Dup ACK XXX#X]后，發(fā)送端進(jìn)行快速重傳。因?yàn)?次Duplicated ACK肯定是亂序造成的，丟包肯定會(huì)造成3次Duplicated ACK。

如圖1所示，車輛（物理地址：169.254.19.1）與設(shè)備（物理地址：169.254.4.20）之間的通信過程中，第169個(gè)序列數(shù)據(jù)包丟失，第178個(gè)序列數(shù)據(jù)快速重傳，UDS診斷2711發(fā)送成功，第184也回復(fù)了這個(gè)指令。

3）TCP Retransmission（超時(shí)重傳）。如果一個(gè)包丟了，又沒有后續(xù)包可以在接收方觸發(fā)Dup ACK，或者Dup ACK也丟失的情況下，TCP會(huì)觸發(fā)超時(shí)重傳機(jī)制。如圖2所示，設(shè)備發(fā)出的第175個(gè)序列數(shù)據(jù)車并沒有回答，而是在第187個(gè)序列重復(fù)應(yīng)答，設(shè)備重傳后，第198個(gè)序列車輛第2次響應(yīng)UDS診斷27 11指令。

由圖1、圖2可知，在報(bào)文交互過程中車輛對設(shè)備響應(yīng)2次UDS診斷2711指令，需要車輛回復(fù)ECU隨機(jī)生成數(shù)，第1次回復(fù)值為8B 45 4D，第2次為89 24 52，但設(shè)備計(jì)算結(jié)果只有一個(gè)76 37 C1，解鎖不成功，導(dǎo)致車輛報(bào)NRC 0x35 InvalidKey。

4）TCP Out-of-Order（TCP發(fā)送端傳輸過程中報(bào)文亂序）。TCP亂序會(huì)在滿足以下所有條件時(shí)設(shè)置：①不是保持連接的數(shù)據(jù)包；②在正向方向上，段長度大于0或設(shè)置SYN或FIN；③下一個(gè)預(yù)期的序列號大于當(dāng)前序列號；④下一個(gè)預(yù)期的序列號和下一個(gè)序列號不同；⑤最后一個(gè)段到達(dá)無序RTT閾值內(nèi)。閾值是SEQ/ACK分析下的iRTT（tcp.analysis.initial_rtt）字段中顯示的值（如果存在）或者默認(rèn)值3ms（如果不存在）。綜合以上，TCP“報(bào)文亂序”提示取代“重新傳輸”。

如圖3所示，從設(shè)備發(fā)出的第5356個(gè)序列數(shù)據(jù)（Seq=20175，ACK=10145，Len=19）開始，第5357個(gè)序列的數(shù)據(jù)沒有回復(fù)，而且第5362、5365個(gè)序列的數(shù)據(jù)直到第5379個(gè)序列仍未回復(fù)，時(shí)間間隔為5.389s，其中第5368個(gè)序列的數(shù)據(jù)（Seq=10431，ACK=20194，Len=14）是先發(fā)后至的數(shù)據(jù)，所以Wireshark會(huì)標(biāo)記為亂序；而UDS診斷指令31 03 20 11重傳過后，車輛接收設(shè)備發(fā)出的3E 80指令已超過5s，退出了安全訪問（要求為5s），所以在第5379個(gè)序列，車輛報(bào)NRC 0x31 request Out-of-Range。

5）TCP Previous Segment Not Captured（當(dāng)前序列號大于下一個(gè)預(yù)期序列號）。在TCP發(fā)送端傳輸過程中，該Seq前的報(bào)文缺失了。一般在網(wǎng)絡(luò)擁塞的情況下，造成TCP報(bào)文亂序、丟包時(shí)會(huì)出現(xiàn)該標(biāo)志。TCP發(fā)送端傳輸過程中報(bào)文亂序，未捕獲TCP上一段，設(shè)置當(dāng)前序列號大于下一個(gè)預(yù)期序列號。

如圖4所示，從設(shè)備發(fā)出的第102個(gè)序列數(shù)據(jù)（Seq=38643，ACK=411，Len=14）開始，第103個(gè)序列的數(shù)據(jù)（Seq=512，ACK=38629，Len=0），其中411～512之間的報(bào)文丟失，一直到第114個(gè)序列仍未到達(dá)，其間無3E 80保持會(huì)話，導(dǎo)致車輛退出BOOT，刷寫歷程失敗。

6）Keep-alive ACK（TCP保持活動(dòng)狀態(tài)ACK）。在滿足以下所有條件時(shí)設(shè)置：①段大小為0；②窗口大小不為0，并且未更改；③當(dāng)前序列號與下一個(gè)預(yù)期序列號相同；④當(dāng)前確認(rèn)號與上次看到的確認(rèn)號相同；⑤最近在相反方向上看到的數(shù)據(jù)包保持連接；⑥數(shù)據(jù)包不是SYN、FIN或RST。綜合以上，TCP保持活動(dòng)取代“快速重傳”、“無序”、“虛假重傳”和“重傳”。Keep-alive ACK如圖5所示。

保活計(jì)時(shí)器使用在某些實(shí)現(xiàn)中，用來防止在2個(gè)TCP之間的連接出現(xiàn)長時(shí)間的空閑。假定客戶端接通了到服務(wù)器的連接，傳送了一些數(shù)據(jù)，然后就保持靜默了，也許這個(gè)客戶端出故障了。在這種情況下，這個(gè)連接將永遠(yuǎn)處于接通狀態(tài)。在大多數(shù)的實(shí)現(xiàn)中都是使服務(wù)器設(shè)置保活計(jì)時(shí)器。每當(dāng)服務(wù)器收到客戶端的信息，就將計(jì)時(shí)器復(fù)位。通常設(shè)置為2h，若服務(wù)器過了2h還沒有收到客戶端的信息，就發(fā)送探測報(bào)文段。若發(fā)送了10個(gè)探測報(bào)文段（每一個(gè)相隔75s）還沒有響應(yīng)，就假定客戶端出了故障，直接硬性中斷和客戶端的TCP連接。

7）TCP回復(fù)無報(bào)文。如圖6所示，從設(shè)備發(fā)出的第1042個(gè)序列數(shù)據(jù)開始，車輛已無回復(fù)，之后在1052個(gè)序列之后車輛廣播VIN號，但未與設(shè)備連接，調(diào)查設(shè)備電壓發(fā)現(xiàn)在450～500s之間存在掉電情況，導(dǎo)致TCP中斷，如圖7所示。從設(shè)備發(fā)出的指令未在2s發(fā)送3E 80（要求為2s發(fā)送3E 80保持喚醒），導(dǎo)致車輛主動(dòng)中斷，如圖8所示。

8）TCP Zero Window（TCP零窗口）。每個(gè)TCP標(biāo)頭中的窗口字段通告接收方可以接收的數(shù)據(jù)量。如果接收方不能接收更多數(shù)據(jù)，它將窗口值設(shè)置為0，告訴發(fā)送方暫停其傳輸。在某些特定情況下，這是正常的，例如，打印機(jī)可能會(huì)使用零窗口來暫停打印作業(yè)的傳輸，同時(shí)加載或反轉(zhuǎn)一張紙。但是，在大多數(shù)情況下，這表示接收端存在性能或容量問題。恢復(fù)暫停的連接可能需要很長時(shí)間（有時(shí)幾分鐘），即使導(dǎo)致零窗口的基本條件很快清除也是如此。

2" 錄取故障

因?yàn)橐蕴W(wǎng)的總線只能一對一通信，不能如CAN總線一樣廣播，所以在錄取車載以太網(wǎng)Log時(shí)，若沒有CANoe等專業(yè)設(shè)備，就可以引入交換機(jī)來協(xié)助錄取報(bào)文分析，如圖9所示。

3" 結(jié)束語

綜上所述，本文介紹了TCP數(shù)據(jù)包常見問題，限于本人認(rèn)知水平，對常見故障進(jìn)行了簡要分析，希望能為同仁提供參考。

參考文獻(xiàn)：

[1] ISO 14229-1：2020，道路車輛-統(tǒng)一診斷服務(wù)（UDS）-第1部分：應(yīng)用層[S]. 2020.

[2] 李志濤，耿偉峰. 車載以太網(wǎng)DoIP協(xié)議測試的研究與分析[J]. 汽車電器，2022（9）：21-24.

[3] 繆學(xué)勤. 實(shí)時(shí)以太網(wǎng)技術(shù)現(xiàn)狀與發(fā)展[J].自動(dòng)化博覽，2005（2）：21-24，26.

（編輯" 楊凱麟）