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

【摘" 要】隨著車載以太網的逐漸普及，應用場景也越來越多。在主機廠，總裝線體會在電檢工位進行診斷、刷寫、檢測、維修。售后市場也會存在檢測、維修，呈現多種多樣的故障類型。文章通過借用Wireshark的TCP分析器跟蹤每個TCP會話的狀態，對TCP數據包常見問題結構進行剖析。

【關鍵詞】車載以太網；刷寫；診斷；測試

中圖分類號：U463.6" " 文獻標識碼：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

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

1" 常見故障

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

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

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

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

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

由圖1、圖2可知，在報文交互過程中車輛對設備響應2次UDS診斷2711指令，需要車輛回復ECU隨機生成數，第1次回復值為8B 45 4D，第2次為89 24 52，但設備計算結果只有一個76 37 C1，解鎖不成功，導致車輛報NRC 0x35 InvalidKey。

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

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

5）TCP Previous Segment Not Captured（當前序列號大于下一個預期序列號）。在TCP發送端傳輸過程中，該Seq前的報文缺失了。一般在網絡擁塞的情況下，造成TCP報文亂序、丟包時會出現該標志。TCP發送端傳輸過程中報文亂序，未捕獲TCP上一段，設置當前序列號大于下一個預期序列號。

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

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

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

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

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

2" 錄取故障

因為以太網的總線只能一對一通信，不能如CAN總線一樣廣播，所以在錄取車載以太網Log時，若沒有CANoe等專業設備，就可以引入交換機來協助錄取報文分析，如圖9所示。

3" 結束語

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

參考文獻：

[1] ISO 14229-1：2020，道路車輛-統一診斷服務（UDS）-第1部分：應用層[S]. 2020.

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

[3] 繆學勤. 實時以太網技術現狀與發展[J].自動化博覽，2005（2）：21-24，26.

（編輯" 楊凱麟）