透過中介測試驗證汽車乙太網路

概觀

汽車乙太網路驗證需要的不只是傳統方法。NI MitM 測試解決方案為工程師提供 MAC 層級控制功能,支援在實際條件下進行故障植入、時序分析與壓力測試。NI 透過 FPGA 架構的硬體、靈活的軟體與先進的自動化功能,協助 OEM 與 1 級供應商打造更安全、更具智慧效能的車輛。

內容

背景說明

汽車乙太網路的複雜度超越了舊款通訊協定,如 Controller Area Network (CAN) CAN 或 Local Interconnect Network (LIN)。雖然較高階的軟體驗證相當普遍,但低階的通訊錯誤 (例如訊框損壞、時序違規或電子雜訊) 通常會被商用 NIC 過濾掉,因而未能偵測到。這些故障可能會顯示在 ECU 軟體鎖定、無法解釋的錯誤訊息、潛時突波,或是如 TC10 等休眠/覺醒通訊協定的故障。

為了確保穩定性與安全性,工程師需要可在這些問題發生的 MAC 層進行測試的工具。MitM 測試可主動操作即時流量,包括損壞框架檢查序列 (FCS) 等異常情況,以在實際條件下評估系統穩定性,進而消除此落差。這項功能對於現代車輛而言非常重要,因為乙太網路可支援時效性與安全性關鍵性的應用。

 

透過中介測試驗證汽車乙太網路

隨著車輛的連線、自動化與軟體定義程度越來越高,汽車乙太網路也成為車用通訊的骨幹。從先進駕駛輔助系統 (ADAS) 到資訊娛樂、車輛到各種 (V2X),汽車乙太網路可在日益複雜的電子控制單元 (ECU) 中進行高速、低潛時的資料交換。

然而,傳統的驗證方法往往會忽略低階通訊故障,這些故障可能會導致軟體鎖定、時序問題,以及難以預測的行為。此技術文章介紹了人中介 (MitM) 測試的強大技術,可用來找出潛在問題,並驗證汽車乙太網路的可靠性。

工程師可運用模組化 NI 硬體平台 (尤其是 NI PXIe-6592 (用於 MitM 與特性/Sim-DUT)),模擬實際的故障、插入流量並精確監控 ECU 回應。

什麼中介人 (MitM) 測試?

MitM 測試會在 2 個通訊裝置 (通常是 ECU 或門道) 之間插入可程式化測試系統,用於攔截、操作與分析 MAC 層的網路流量。MitM 不同於被動式監控,可讓工程師主動操作即時流量,進而導入受控的干擾,以驗證故障容錯與錯誤處理機制。

 

圖 1: MitM 架構圖

MitM 的運作方式

傳統的 NIC 會捨棄無效的框架,因此無法插入故障。PXIe-6592 高速序列模組會繞過作業系統 (OS) 與網路介面卡 (NIC) 層,直接存取無論是有效或損壞的乙太網路框架,而且可達到 微秒延遲與次微秒時間戳記準確度。工程師可以使用 Google 遠端程序呼叫 (gRPC) 應用程式設計介面 (API),中斷 FCS、插入來自檔案或即時來源的流量、觸發 TC10 休眠/醒目指令、將流量記錄至封包捕捉 (PCAP) 檔案,並自動化測試。


圖 2: MitM 工作流程圖

NI MitM 測試平台功能細節

為了大規模進行中介測試,NI 模組化平台經過精心設計,可針對汽車乙太網路流量進行高效能的精確控制。不同於傳統的 NIC 架構解決方案,此平台結合 FPGA 等級的靈活性與 PXI 的同步化與擴充性,相當適合用於故障植入、時序分析與通訊協定驗證。此系統的核心整合了適用於即時框架操作的專業硬體,以及支援自動化、遠端控制與深度封包偵測的軟體堆疊。

硬體:PXIe-6592 含 4 個支援 100/1000BASE-T1 與其他乙太網路型號的 SFP 連接埠。

軟體:適用於自動化與 PCAP 整合的 NI LabVIEW 與 gRPC API,適用於封包分析。

MitM 測試汽車乙太網路時,有 2 項核心功能定義了工程師在 MAC 層操作與分析網路流量的方式:

  • FCS 作業—這些作業會改變乙太網路框架中的框架檢查序列,以模擬毀損並驗證錯誤處理機制。MitM 隨附數種 FCS 斷路模式。
  • 注入方式 — 這類方法是將合成或重現的額外流量導入通訊串流,以便在真實或極端條件下對 ECU 進行壓力測試。

結合這些功能之後,工程師就能重現現場問題、插入受控的故障,並且在各種情境下驗證穩定性,而傳統的 NIC 或被動式監控是無法達到的。

讓我們深入了解每個產品的功能。

FCS 分解模式

下圖顯示了套用 FCS 斷路功能 (紅色矩形) 的位置;在連接埠 0 上取得的流量會傳送至 FCS 斷路功能,接著再傳送修改過的流量至混合器。

圖 3: MitM FCS 突破功能位置

 

MitM 支援多種 FCS 操作模式。這些模式會以載入至 Wireshark®* 的 PCAP 檔案為例,部分螢幕截圖則會於附錄 A 中提供。

  • 全部啟用:所有框架均有錯誤的 FCS。
  • 全部停用:所有框架均具備正確的 FCS。
  • 1 週期—50%:一半的框架已破壞 FCS。
  • N 週期—50%:其他每個框架均打破了 FCS。
  • 隨機:隨機化的 FCS 腐敗。
  • 百分比:使用者定義的框架損壞百分比。
  • 客制化:使用者將上傳 1 個陣列 (最多 8192 個元素),以利精確控制。

圖 4 顯示 FPGA 如何將 FCS 中斷設定套用至傳入流量。

圖 4: FCS 分解 FPGA 演算法

注入方式

MitM 支援 2 種注入方式:

框架產生器 (DMA) 可產生框架以進行壓力測試,並且插入連接埠,可混合源於連接埠 1 的即時流量與已產生的框架。

插入的流量會結合 FCS 修改的框架,以模擬實際的網路條件。圖 5 的紅色矩形代表注入路徑。

圖 5: 注入

 

附錄 B 詳細說明框架產生器 (DMA) 注入方式的測試條件與結果。

第二組 PXIe-6592 用於測試 MitM。其執行名為「Sim/DUT」的不同 FPGA 特性,

 

圖 6: MitM 含測試設定 (Sim/DUT)

產業使用案例

1.針對已知故障進行測試

當現場問題追蹤到特定的損壞框架或時序異常時,MitM 測試可提供精確的故障情境重現功能;因此,工程師可以:

  • 重播從現場獲取的確切流量模式,包含錯形影格與時序不規則。
  • 監控 MAC 層的 ECU 行為,確保對錯誤處理常式與協定堆疊回應的能見度。
  • 在部署前,可於相同條件下驗證修正軟體修補程式,進而降低生產環境中的迴歸風險。

 

2.完整匯流排負載進行壓力測試

MitM 系統會注入大量的混合流量 (實際流量和模擬流量),進而控制乙太網路匯流排的飽和,因此工程師可以:

  • 將頻寬推至理論限制,在最壞情況下驗證傳輸率與潛時。
  • 進行 ECU 效能的特性分析,包括框架優先化與緩衝管理。
  • 找出時序中可能會影響重要安全用途精確通訊的問題與瓶頸。

 

3.睡眠/覺醒通訊協定驗證 (TC10)

在電動車中,TC10 協定會控制有功狀態與低功率狀態之間的轉換。MitM 測試可透過下列方式,確保符合規範與穩定性:

  • 以微秒的精確度觸發休眠/醒目序列,模擬實際的時序限制。
  • 導入受控制的雜訊或延遲,以驗證 ECU 對不完美的網路條件的彈性。
  • 量測潛時與功率轉換行為,提供適用於 OEM 電源管理需求的量化資料。

結論

採用 MitM 系統進行乙太網路驗證,代表著汽車網路測試與保證的進步相當大。這些解決方案可精確控制流量插入、故障模擬與通訊協定驗證,讓工程師能夠重建實際的網路條件、徹底評估 ECU 行為,並驗證是否符合嚴格的產業需求。在完整的匯流排負載下進行壓力測試,以及嚴格的休眠/覺醒通訊協定驗證,確保不但能量測頻寬、潛時與電源管理等重要參數,還能針對安全性與穩定性進行最佳化。能夠辨別瓶頸、時序違規與抗擾不良條件的能力,可為開發新一代電動與連線載具奠定穩定的基礎。

隨著汽車乙太網路持續演進,對 OEM 與 1 級供應商而言,整合 FPGA 架構硬體與靈活自動化軟體等先進驗證工具仍然十分重要。這些技術不但能簡化開發流程,還能提升車輛安全、連線與效率的標準。展望未來,以實際測試為基礎的完整驗證策略,將是因應日益複雜的車輛架構需求,並確保未來行動解決方案能順暢運作的重要關鍵。

附錄 A:FCS 分解模式插圖

本節說明 MitM 提供的不同 FCS 斷路模式。

註:在下列螢幕截圖範例中,我們使用 Wireshark®;將其設為:

  • 檢查 FCS,並預期會有 FCS。
  • 以無效 FCS 的紅色字型框架顯示。

 

啟用模式

在全啟用模式下,所有框架的 FCS 都會中斷。

圖 7: 全方位的 FCS 分解模式全方位的 FCS 分解模式 – 所有獲取的乙太網路框架均顯示無效的 FCS,原因是 MitM 毀損。

 

停用模式

在全停用模式中,沒有任何框架的 FCS 發生損壞。

圖 8: 全停用 FCS 分解模式 – 顯示所有訊框的正常乙太網路流量的接線束 (Wireshark) 記錄

 

1 週期 50% 模式

在此範例中,程式方塊大小為 20 個框架。這表示,區塊 (10 框架) 的 50 % 的 FCS 已損壞,而其他 (10 框架) 的 FCS 則未受影響。

圖 9: 週期 50% FCS 分解模式 – 每個區塊中的一半框架已中斷 FCS,另一半仍有效。

 

N 週期 50% 模式

在此範例中,其他每個框架的 FCS 都已中斷。

圖 10N 週期 50% FCS 分解模式 – 其他每個乙太網路框架都會故意中斷其 FCS。

 

百分比 (%) 模式

在此模式中,程式方塊大小為 100 個框架,使用者通過的百分比則是 80。這表示 80 % 的區塊 (80 個框架) 的 FCS 已損壞,而其他 (20 個框架) 的 FCS 則未受影響,因此重複進行。

圖 11: 百分比 (百分比) 的 FCS 分解模式:重複以 100 個框架為單位的區塊,其中 80% 的框架有故意分解 FCS,而 20% 的區塊仍然有效。

 

隨機模式

在此範例中,使用者定義了區塊大小 (最多 8192);隨機值 (True 或 False) 會合成,並用於定義框架 FCS 發生中斷時。然後重複進行。

 

圖 12: 隨機 FCS 分解模式:乙太網路框架會根據使用者定義的區塊大小內的隨機模式,循環分解其 FCS。

附錄 B:框架產生器 (DMA) 方法測試

本節說明插入式 (框架產生器 (DMA) 的用途。

 

測試條件

這是以 1 Gb/s 進行測試的結果。

  • MitM 的連接埠 0 會透過 1000BASE-T1 連結連接至資料來源。
  • 連接埠 2 和 3 可透過直接 SFP 連接線連接至其他測試連接埠。測試連接埠可用來量測收到的訊框數量。
  • 我們使用 PCAP 偵測功能,用於量測混合器的輸出流量 (MitM Tx 資料)。這樣一來即可提供非常準確的作業時間戳記。
  • 測試分三個階段:
    • 階段一:我們開始將流量套用至連接埠 0 (MitM Rx)。流量是由 20 個串流構成,週期是 100 μs。串流大小會隨著 5 位元的增量而變化,從 78 位元到 173 位元不等。MAC 來源是:00:2F:80:17:29:68.此流量是由另一組 FPGA 架構訊號源所產生,並搭配 SFP 1000BASE-T1 轉接器使用。
    • 第 2 階段:仍在將流量套用至連接埠 0 時,我們會啟動框架產生器 。產生器的流量與套用至連接埠 0 的流量相同,但其 MAC 來源不同: 00:2F80:11:25:34.
    • 階段 3.連接埠 0 沒有更多流量,只有插入框架產生器 的流量。
  • 資料總量為 1,200,000 個框架。分解:
    • 600,000 個框架 (30,000 個框架每個串流,20 個串流),套用至 MitM Rx,MAC 來源:00:2F:80:17:29:68.
    • 600,000 個框架 (30,000 個框架每個串流,20 個串流),由框架產生器 (DMA) 產生,MAC 來源:00:2F80:11:25:34.

 

測試結果

階段 1

我們僅提供 MitM Rx。圖 13 為串流對時間的呈現方式。每個條的寬度與串流大小成正比。

圖 13: 測試結果 – 第 1 階段 (僅限 MitM Rx) – 使用條寬表示相對串寬,隨時間串流活動。

 

圖 14 顯示以 100 μs 週期發出的 20 個串流每個區塊。同樣的結果,放大為一個期間。

圖 14: 測試結果 – 第 1 階段 (縮放檢視) – 一個 100 μs 週期的縮放圖,顯示 20 個接收串流的區塊,序列發出。

 

預期 2 個連續的串流開始時間為 4 μs。

圖 15 顯示了第一階段期間的資料子集。我們會計算每個串流週期的平均值、週期的標準差 (s) 與變化 (s2)。在此,我們只能看到來自 MAC 來源 00:2F:80:17:29:68 的資料,框架產生器尚未執行。

圖 15: 測試結果 第 1 階段子集:MAC 00:2F:80:17:29:68 的每個串流週期統計 (平均, σ、 σ2);框架產生器關閉。

 

另一項有趣的量測項目,就是連續兩個串流之間的時間。圖 16 顯示結合期間的圖形。預期為 4 μs。

圖 16: 測試結果 第 1 階段:串聯期間的串流間時間,串流之間的間隔為 ~4 μs。

 

第 2 階段

在此階段中,我們會同時看到 MitM Rx 與框架產生器的流量。圖 17 顯示不同流量來源的不同串流。

圖 17: 測試結果 – 第 2 階段 – 隨時間串流,顯示來自多個來源的 MitM Rx 流量與框架產生器流量並行。

 

平條圖是來自 MitM Rx 的圖 (MAC 來源為:00:2F:80:17:29:68)。其他 (非簡易) 為注入 (框架產生器) 所產生的訊號,MAC 來源為:00:2F:80:11:25:34.來自 MitM Rx 的流量優先於插入流量。因此,如果 MitM Rx 和 Injection 均具有框架,則 MitM Rx 的框架會優先考量。

在以下範例情況下,插入流量可能會影響 MitM Rx 流量時序,例如:在混合器中,當未要傳送 MitM Rx 的框架,而是要傳送插入的框架時,就會傳送插入框架。若在 MitM Rx 的注入期間可用,則會延後發射時間。如果我們在該階段中觀察到電流間的時間,即可看出這一點。想提醒一下,理論上是 4 μs。

圖 18: 測試結果 – 第 2 階段的流程間時序 – 在插入流量佔用混合器時,流程間時間顯示延遲的 MitM Rx 框架,儘管 MitM Rx 優先。

 

如果我們在測試期間查看串流的統計資料,且均分仍為 100 μs,我們也可以看到標準差 (與第一階段相比) 對時序的影響。

圖 19: 測試結果 – 第 2 階段的串流統計 – 平均串流週期保持在 100 微秒,而增加的標準差會強調並行插入流量帶來的時序變化。

 

階段 3

在此階段中,我們只會收到框架產生器的流量。MAC 來源是 00:2F:80:11:25:34.

圖 20: 測試結果 – 第 3 階段 – 隨著時間串流活動,僅顯示 MAC 00:2F:80:11:25:34 的框架產生器流量。

 

完成第 3 階段流量概述之後,我們將縮放至較小的時段,以強調在沒有 MitM Rx 流量時,個別框架產生器串流的時間分配。

圖 21: 測試結果 – 第 3 階段 (縮放式檢視) – 框架產生器隨時間串流的縮放式檢視,顯示未造成 MitM Rx 干擾的穩定串流間距。

 

除了時域視覺化功能之外,當只有框架產生器流量存在時,框架間統計資料也能進一步掌握時序行為,確認傳輸間隔穩定,且在沒有 MitM Rx 干擾的情況下,抖動較低。

圖 22: 測試結果 – 第 3 階段框架間統計 – 第 3 階段期間的僅供注入流量各流程框架間時序指標。

 

整體

總而言之,我們會彙整所有階段的統計資料,以評估所有串流的整體傳輸率與時序穩定性。

圖 23: 整體測試統計 – 彙整結果顯示 1,200,000 個截圖的總量,對應於每個串流的 30,000 個截圖。

 

最後,我們會檢驗整個測試的全域流間時序,以比較具有 MitM 有效接收流量的相位 (第一階段和第二階段) 與僅供注入流量的相位的系統行為,並強調並行訊號源對整體時序特性的影響。

 

圖 24: 全域流程間時間圖顯示第一階段期間的平間間隔是 ~4 μs,且第二階段期間的時序變化增加,而僅供注入的第三階段則沒有可見的流程間資料。

*Wireshark® 是 Wireshark Foundation 的註冊商標。本文件並非 Wireshark Foundation 所聯繫、核准或贊助。*Wireshark® 的所有參照均僅供參考之用。如需官方資訊與資源,請造訪 https://www.wireshark.org