汽車乙太網路驗證需要的不只是傳統方法。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 測試會在 2 個通訊裝置 (通常是 ECU 或門道) 之間插入可程式化測試系統,用於攔截、操作與分析 MAC 層的網路流量。MitM 不同於被動式監控,可讓工程師主動操作即時流量,進而導入受控的干擾,以驗證故障容錯與錯誤處理機制。
圖 1: MitM 架構圖
傳統的 NIC 會捨棄無效的框架,因此無法插入故障。PXIe-6592 高速序列模組會繞過作業系統 (OS) 與網路介面卡 (NIC) 層,直接存取無論是有效或損壞的乙太網路框架,而且可達到 微秒延遲與次微秒時間戳記準確度。工程師可以使用 Google 遠端程序呼叫 (gRPC) 應用程式設計介面 (API),中斷 FCS、插入來自檔案或即時來源的流量、觸發 TC10 休眠/醒目指令、將流量記錄至封包捕捉 (PCAP) 檔案,並自動化測試。
圖 2: MitM 工作流程圖
為了大規模進行中介測試,NI 模組化平台經過精心設計,可針對汽車乙太網路流量進行高效能的精確控制。不同於傳統的 NIC 架構解決方案,此平台結合 FPGA 等級的靈活性與 PXI 的同步化與擴充性,相當適合用於故障植入、時序分析與通訊協定驗證。此系統的核心整合了適用於即時框架操作的專業硬體,以及支援自動化、遠端控制與深度封包偵測的軟體堆疊。
硬體:PXIe-6592 含 4 個支援 100/1000BASE-T1 與其他乙太網路型號的 SFP 連接埠。
軟體:適用於自動化與 PCAP 整合的 NI LabVIEW 與 gRPC API,適用於封包分析。
MitM 測試汽車乙太網路時,有 2 項核心功能定義了工程師在 MAC 層操作與分析網路流量的方式:
結合這些功能之後,工程師就能重現現場問題、插入受控的故障,並且在各種情境下驗證穩定性,而傳統的 NIC 或被動式監控是無法達到的。
讓我們深入了解每個產品的功能。
下圖顯示了套用 FCS 斷路功能 (紅色矩形) 的位置;在連接埠 0 上取得的流量會傳送至 FCS 斷路功能,接著再傳送修改過的流量至混合器。
圖 3: MitM FCS 突破功能位置
MitM 支援多種 FCS 操作模式。這些模式會以載入至 Wireshark®* 的 PCAP 檔案為例,部分螢幕截圖則會於附錄 A 中提供。
圖 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)
當現場問題追蹤到特定的損壞框架或時序異常時,MitM 測試可提供精確的故障情境重現功能;因此,工程師可以:
MitM 系統會注入大量的混合流量 (實際流量和模擬流量),進而控制乙太網路匯流排的飽和,因此工程師可以:
在電動車中,TC10 協定會控制有功狀態與低功率狀態之間的轉換。MitM 測試可透過下列方式,確保符合規範與穩定性:
採用 MitM 系統進行乙太網路驗證,代表著汽車網路測試與保證的進步相當大。這些解決方案可精確控制流量插入、故障模擬與通訊協定驗證,讓工程師能夠重建實際的網路條件、徹底評估 ECU 行為,並驗證是否符合嚴格的產業需求。在完整的匯流排負載下進行壓力測試,以及嚴格的休眠/覺醒通訊協定驗證,確保不但能量測頻寬、潛時與電源管理等重要參數,還能針對安全性與穩定性進行最佳化。能夠辨別瓶頸、時序違規與抗擾不良條件的能力,可為開發新一代電動與連線載具奠定穩定的基礎。
隨著汽車乙太網路持續演進,對 OEM 與 1 級供應商而言,整合 FPGA 架構硬體與靈活自動化軟體等先進驗證工具仍然十分重要。這些技術不但能簡化開發流程,還能提升車輛安全、連線與效率的標準。展望未來,以實際測試為基礎的完整驗證策略,將是因應日益複雜的車輛架構需求,並確保未來行動解決方案能順暢運作的重要關鍵。
本節說明 MitM 提供的不同 FCS 斷路模式。
註:在下列螢幕截圖範例中,我們使用 Wireshark®;將其設為:
在全啟用模式下,所有框架的 FCS 都會中斷。
圖 7: 全方位的 FCS 分解模式全方位的 FCS 分解模式 – 所有獲取的乙太網路框架均顯示無效的 FCS,原因是 MitM 毀損。
在全停用模式中,沒有任何框架的 FCS 發生損壞。
圖 8: 全停用 FCS 分解模式 – 顯示所有訊框的正常乙太網路流量的接線束 (Wireshark) 記錄
在此範例中,程式方塊大小為 20 個框架。這表示,區塊 (10 框架) 的 50 % 的 FCS 已損壞,而其他 (10 框架) 的 FCS 則未受影響。
圖 9: 週期 50% FCS 分解模式 – 每個區塊中的一半框架已中斷 FCS,另一半仍有效。
在此範例中,其他每個框架的 FCS 都已中斷。
圖 10: N 週期 50% FCS 分解模式 – 其他每個乙太網路框架都會故意中斷其 FCS。
在此模式中,程式方塊大小為 100 個框架,使用者通過的百分比則是 80。這表示 80 % 的區塊 (80 個框架) 的 FCS 已損壞,而其他 (20 個框架) 的 FCS 則未受影響,因此重複進行。
圖 11: 百分比 (百分比) 的 FCS 分解模式:重複以 100 個框架為單位的區塊,其中 80% 的框架有故意分解 FCS,而 20% 的區塊仍然有效。
在此範例中,使用者定義了區塊大小 (最多 8192);隨機值 (True 或 False) 會合成,並用於定義框架 FCS 發生中斷時。然後重複進行。
圖 12: 隨機 FCS 分解模式:乙太網路框架會根據使用者定義的區塊大小內的隨機模式,循環分解其 FCS。
本節說明插入式 (框架產生器 (DMA) 的用途。
這是以 1 Gb/s 進行測試的結果。
我們僅提供 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。
在此階段中,我們會同時看到 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 微秒,而增加的標準差會強調並行插入流量帶來的時序變化。
在此階段中,我們只會收到框架產生器的流量。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。