作者 | 主隊

小編 | CACTUS

前言

隨著車內(nèi)通信技術(shù)（如OTA、SOME/IP、DDS）的快速發(fā)展，網(wǎng)關(guān)作為整車網(wǎng)絡(luò)的核心樞紐，其路由能力至關(guān)重要。OTA 升級對網(wǎng)關(guān)的診斷路由性能提出了更高要求；而 SOME/IP 和 DDS 等通信技術(shù)的普及，則要求網(wǎng)關(guān)具備強大的 S2S（Signal to Service）路由能力。本文將重點探討網(wǎng)關(guān)的診斷路由功能，并分享其性能測試方案。

網(wǎng)關(guān)功能介紹

依據(jù)在整車網(wǎng)絡(luò)中的核心角色，網(wǎng)關(guān)通常具備以下關(guān)鍵功能：

1.協(xié)議轉(zhuǎn)換：實現(xiàn)不同總線協(xié)議之間的數(shù)據(jù)轉(zhuǎn)換與轉(zhuǎn)發(fā)（如信號路由：CAN ETH；診斷路由：DoIP DoCAN）

2.路由功能：基于預(yù)定義規(guī)則或策略（如路由映射表），實現(xiàn)數(shù)據(jù)幀/報文在不同網(wǎng)絡(luò)域間的定向轉(zhuǎn)發(fā)

3.部分網(wǎng)絡(luò)（PN)管理：依據(jù)整車休眠喚醒策略，協(xié)調(diào)并控制所連接各網(wǎng)絡(luò)域的休眠與喚醒時序

4.外部通信接口：作為整車網(wǎng)絡(luò)與外部環(huán)境（如診斷儀、云端服務(wù)器）進行數(shù)據(jù)交換的核心接口

5.網(wǎng)絡(luò)安全防護：作為關(guān)鍵安全邊界節(jié)點，實施嚴(yán)格防護機制（如防火墻、訪問控制、安全診斷路由、安全刷寫等），隔離外部威脅，防范未授權(quán)訪問、惡意攻擊及數(shù)據(jù)泄露

6.其它功能：如數(shù)據(jù)過濾、時間同步等

面向智能網(wǎng)聯(lián)汽車高度集中化、服務(wù)化（SOA）的電子電氣架構(gòu)（EEA）演進，網(wǎng)關(guān)的核心角色與功能需進行相應(yīng)優(yōu)化與強化。

1.域間中樞：在域跨域融合/域集中式架構(gòu)下，網(wǎng)關(guān)的核心作用更加凸顯，成為連接動力域、底盤域、車身域、智駕域、座艙域等關(guān)鍵區(qū)域的核心通信樞紐。

2.高效數(shù)據(jù)處理：需支持更高帶寬和更低延遲的數(shù)據(jù)交換，以滿足智能駕駛、車聯(lián)網(wǎng)等對實時性要求極高的應(yīng)用需求。

3.服務(wù)化支持：在SOA架構(gòu)中，網(wǎng)關(guān)的信號路由功能需擴展支持服務(wù)（Service）的發(fā)現(xiàn)、路由和轉(zhuǎn)換（如SOME/IP），實現(xiàn)跨域的服務(wù)調(diào)用與數(shù)據(jù)共享。

4.支持OTA與診斷：需提供安全、可靠且高效的通道，支持大規(guī)模的固件空中升級（OTA）和遠程診斷（Remote Diagnostics）。

AUTOSAR軟件架構(gòu)示意圖

在AUTOSAR軟件架構(gòu)下，網(wǎng)關(guān)的路由功能根據(jù)是否經(jīng)過COM → RTE → SWC處理，可分為以下兩個層級：

01. PDU路由

機制：直接基于完整的協(xié)議數(shù)據(jù)單元（PDU）進行轉(zhuǎn)發(fā)，不解析PDU內(nèi)部的信號內(nèi)容。

范疇：報文路由（如CAN幀轉(zhuǎn)發(fā)）、診斷路由（如DoIP報文轉(zhuǎn)發(fā)）均屬于此層級。

02. 信號路由

機制：解析PDU中的具體信號或服務(wù)，實現(xiàn)跨總線/域的信號映射、重組與轉(zhuǎn)換。

范疇：信號到信號的轉(zhuǎn)換（Signal to Signal）、信號到服務(wù)的轉(zhuǎn)換（Signal to Service， S2S）均屬于此層級。

診斷路由功能介紹

綜上所述，作為整車網(wǎng)絡(luò)的核心通信樞紐，網(wǎng)關(guān)需支持多層次路由能力（如PDU路由、信號路由）以滿足復(fù)雜功能需求。其中，診斷路由因其應(yīng)用場景的顯著差異，需進行定制化設(shè)計與實現(xiàn)。主要包含以下三類：

01. OBD診斷路由

OBD診斷路由是指診斷請求源自O(shè)BD端口的診斷報文路由。根據(jù)OBD端口類型（DoIP端口或CAN端口）及使用場景，其路由實現(xiàn)存在差異

（1）DoIP端口路由：

典型場景：

樣件軟件更新：診斷測試儀通過DoIP端口連接網(wǎng)關(guān)。網(wǎng)關(guān)需支持DoIP CAN(FD)/LIN協(xié)議轉(zhuǎn)換：診斷請求DoIP →其他總線協(xié)議，診斷響應(yīng)為其他總線協(xié)議→DoIP。

ZEV (零排放車輛) 診斷：為滿足法規(guī)對零排放車輛關(guān)鍵數(shù)據(jù)的標(biāo)準(zhǔn)化讀取與驗證要求，網(wǎng)關(guān)需要具備路由特定ZEV診斷服務(wù)請求至目標(biāo)ECU的功能。

DoIPDoIP路由：

DoIP DoIP路由則取決于路由策略，如果車輛內(nèi)部ETH節(jié)點IP不可見，需網(wǎng)關(guān)支持IP地址轉(zhuǎn)換（NAT）功能，以實現(xiàn)外部設(shè)備對內(nèi)部ETH節(jié)點的訪問。反之，IP可見無需支持NAT功能，可通過交換機透傳方式直接訪問內(nèi)部ETH節(jié)點

（2）CAN端口路由：

典型場景：

排放信息讀?。?/u>診斷測試儀（通常基于CAN(FD)協(xié)議）讀取排放相關(guān)數(shù)據(jù)。網(wǎng)關(guān)需支持CAN CAN(FD)協(xié)議轉(zhuǎn)換。

樣件軟件更新（J2534）：J2534標(biāo)準(zhǔn)設(shè)備（通常使用CAN）更新軟件。出口車輛網(wǎng)關(guān)必需支持 CAN擴展幀→ CAN(FD)標(biāo)準(zhǔn)幀轉(zhuǎn)換（以滿足J2534國際標(biāo)準(zhǔn)）。

特殊需求：

若OEM要求通過CAN端口（診斷儀僅支持CAN）更新整車ECU軟件，網(wǎng)關(guān)需支持CAN DoIP/CAN(FD)/LIN協(xié)議轉(zhuǎn)換。

上述協(xié)議轉(zhuǎn)換過程涉及安全防護機制或流量控制，無論源端和目標(biāo)端總線協(xié)議是否相同（如CAN轉(zhuǎn)CAN）。若需在傳輸層（TP）進行組包與拆包，其實現(xiàn)方式也歸類到協(xié)議轉(zhuǎn)換的范疇。反之，若無需協(xié)議轉(zhuǎn)換或TP層處理，可采用透傳方式，其路由方式與報文路由一致，路由性能達到最優(yōu)。

02. OTA診斷路由

OTA診斷路由是指路由路徑為診斷請求源自O(shè)TA Master（空中下載主控單元）。OTA（Over-the-Air）技術(shù)實現(xiàn)車輛軟件的遠程更新（類比手機App更新）。OTA Master作為OTA鏈路的核心車載ECU，負責(zé)存儲云端更新包并協(xié)調(diào)升級過程。其物理載體根據(jù)OEM設(shè)計，可以是TBox（遠程信息處理器）或網(wǎng)關(guān)自身。

（1）OTA Master作為TBox

診斷路由路徑為TBox → 網(wǎng)關(guān)→目標(biāo)子節(jié)點ECU。與OBD診斷的DoIP端口需求一致，網(wǎng)關(guān)必須支持 DoIP CAN(FD)/LIN等總線協(xié)議的雙向轉(zhuǎn)換（下行請求：DoIP→其他協(xié)議；上行響應(yīng)：其他協(xié)議→DoIP）。根據(jù)OEM的OTA升級策略，網(wǎng)關(guān)必須滿足與之匹配的性能要求，比如說OTA在極端情況下進行整車所有ECU推包，也就是說同時對整車所有ECU進行軟件更新，對于網(wǎng)關(guān)而言，首先必須具備并行能力，支持同時向多個不同目標(biāo)ECU轉(zhuǎn)發(fā)，為了追求更快的傳輸效率，可支持隊列傳輸。其次，網(wǎng)關(guān)必須滿足自身在進行軟件更新時還能進行路由轉(zhuǎn)發(fā)，也就是說網(wǎng)關(guān)自身的診斷功能與其路由功能實現(xiàn)必須相互獨立。

下面對并行、隊列概念進行說明：

并行：針對不同目標(biāo)ECU的診斷請求/響應(yīng)，簡單理解就是同時轉(zhuǎn)發(fā)。以并行診斷請求為例，就是網(wǎng)關(guān)可以同時轉(zhuǎn)發(fā)多個目標(biāo)ECU的診斷請求，不需要等待某個目標(biāo)ECU回復(fù)診斷響應(yīng)后才轉(zhuǎn)發(fā)另一個目標(biāo)ECU的診斷請求。

并行請求示意圖

隊列：針對相同目標(biāo)ECU 的診斷請求，簡單理解就是同時接收，注意不是同時轉(zhuǎn)發(fā)。對于相同ECU地址，必須先轉(zhuǎn)發(fā)完第一個診斷請求才能轉(zhuǎn)發(fā)第二個診斷請求。滿足隊列的網(wǎng)關(guān)必須支持全雙工，即請求轉(zhuǎn)發(fā)與響應(yīng)轉(zhuǎn)發(fā)可同時進行。

隊列請求示意圖

（2）OTA Master作為網(wǎng)關(guān)

OTA Master功能直接集成于網(wǎng)關(guān)內(nèi)，此場景下，軟件下載數(shù)據(jù)流不涉及跨節(jié)點的網(wǎng)關(guān)診斷路由功能。更新包存儲在網(wǎng)關(guān)本地。作為OTA Master，網(wǎng)關(guān)需直接管理通過其連接的各總線（CAN(FD)/LIN）向子節(jié)點ECU傳輸更新數(shù)據(jù)（本質(zhì)是網(wǎng)關(guān)作為源節(jié)點的點對點通信）

03. 遠程診斷路由

相較于OTA聚焦于將新軟件安全寫入車輛ECU（“寫”操作），遠程診斷的核心在于從車輛ECU讀取狀態(tài)信息、故障碼、實時參數(shù)等數(shù)據(jù)并上報至云端服務(wù)平臺（“讀”操作）。其典型特征為請求頻率高、單次傳輸數(shù)據(jù)量相對較?。ㄅcOTA軟件包相比）。對于網(wǎng)關(guān)功能實現(xiàn)而言只是緩存分配和路由策略存在些許差異，需要網(wǎng)關(guān)具有并行處理能力和低延遲傳輸能力（與OTA相比對緩存要求不高）。

診斷路由性能介紹

綜合前文分析，不同診斷路由方式（OBD/OTA/遠程）在網(wǎng)關(guān)基礎(chǔ)路由機制上具有高度共性，核心體現(xiàn)為：協(xié)議轉(zhuǎn)換能力（支持DoIP CAN(FD)/LIN等總線協(xié)議的雙向轉(zhuǎn)換）與資源池化架構(gòu)（并行處理能力與緩存資源可動態(tài)共享于不同路由場景）。其性能差異主要體現(xiàn)在資源調(diào)度策略優(yōu)化。下文將解析三大核心性能指標(biāo)：通信通道分配、緩存分配策略和路由延遲。

01. 通信通道分配

通信通道是協(xié)議層虛擬化的獨立數(shù)據(jù)傳輸路徑，在診斷路由中可理解為：每個目標(biāo)ECU地址的診斷會話獨占一個邏輯通道。為滿足高性能路由需求，通道分配需遵循以下核心原則：

1. 通信通道資源池的規(guī)模必須大于網(wǎng)關(guān)最大并行處理能力

2. 診斷請求通信通道和診斷響應(yīng)通信通道必須隔離

3. 功能尋址請求需分配專用高優(yōu)先級通道

02. 緩存分配策略

緩存本質(zhì)是網(wǎng)關(guān)的硬件內(nèi)存資源，其分配策略分為靜態(tài)分配和動態(tài)分配，靜態(tài)分配相較動態(tài)需預(yù)固定內(nèi)存塊，轉(zhuǎn)發(fā)效率高但資源利用率低。無論采用何種策略，網(wǎng)關(guān)性能上限由以下硬性指標(biāo)決定：

1. 最大診斷請求/響應(yīng)Buffer

2. 最小診斷請求/響應(yīng)Buffer個數(shù)

3. 最小診斷請求/響應(yīng)RAM

下面對緩存分配及硬性指標(biāo)要求進行說明：

1. 請求/響應(yīng)緩存隔離：前文所述通信通道的請求/響應(yīng)獨立，那么請求和響應(yīng)的緩存必須隔離。

2. 最小Buffer數(shù)量定義：最小的診斷請求/響應(yīng)buffer個數(shù)和網(wǎng)關(guān)的子節(jié)點個數(shù)相關(guān)聯(lián)，當(dāng)網(wǎng)關(guān)并行能力滿足所有的子節(jié)點并行刷寫要求，那么最小buffer個數(shù)和并行能力匹配即可。但是實際都是性能與成本的折中，并行能力達不到要求，這時網(wǎng)關(guān)需要保證路由過程中不丟幀，也就是需要有buffer先存放接收到的診斷數(shù)據(jù)，等待并行傳輸有資源釋放之后再進行轉(zhuǎn)發(fā)。此時最小的診斷請求buffer個數(shù)要求至少為子節(jié)點的個數(shù)*2+1。最小診斷響應(yīng)的Buffer個數(shù)和子節(jié)點個數(shù)相同即可。

3. 最大Buffer定義：最大診斷請求Buffer與整車ECU刷寫數(shù)據(jù)塊最大值關(guān)聯(lián)，最大診斷響應(yīng)Buffer與整車ECU診斷響應(yīng)數(shù)據(jù)最大值關(guān)聯(lián)。

4. 最小RAM定義：最小診斷請求/響應(yīng)RAM則為最大診斷請求/響應(yīng)buffer*最小診斷請求/響應(yīng)buffer個數(shù)。

當(dāng)然以上要求不是絕對的，畢竟所有ECU刷寫數(shù)據(jù)塊最大值也不一樣，實際實現(xiàn)需要參考所有ECU的刷寫數(shù)據(jù)塊峰值及覆蓋診斷響應(yīng)數(shù)據(jù)極值，最終在滿足基本路由功能的前提下平衡性能與成本。

03. 路由延遲

路由延遲指網(wǎng)關(guān)處理診斷報文并完成轉(zhuǎn)發(fā)的端到端時延，是OEM的核心性能指標(biāo)。比如診斷路由DoIP轉(zhuǎn)CAN(FD)，會明確要求單幀轉(zhuǎn)發(fā)的時間或者診斷請求FF轉(zhuǎn)發(fā)的時間小于10ms。針對DoIP報文路由策略，為了追求更快的路由轉(zhuǎn)發(fā)，網(wǎng)關(guān)可能接收到DoIP診斷請求不需要在回復(fù)ACK正響應(yīng)之后才轉(zhuǎn)發(fā)，當(dāng)然追求性能的同時會帶來安全風(fēng)險。反之，如果網(wǎng)關(guān)需要在回復(fù)ACK正響應(yīng)之后才轉(zhuǎn)發(fā)，則必須保證樣件的回復(fù)時間（如3ms）滿足要求，并且在達到最大的并行處理能力時同樣需要具備該回復(fù)時間要求。對于診斷響應(yīng)延遲，要求與診斷請求類似（如CAN(FD)→DoIP轉(zhuǎn)發(fā)延遲≤10ms），不再贅述。

診斷路由性能測試方案介紹

上文已詳細介紹診斷路由功能，本部分將重點闡述針對網(wǎng)關(guān)的診斷路由性能測試方案。

01. 測試環(huán)境

測試環(huán)境示意圖

測試環(huán)境配置簡潔明確：電源給GW網(wǎng)關(guān)控制器供電，采用專業(yè)測試工具進行數(shù)據(jù)仿真或采集。

02. 測試流程

使用Vector CANoe搭建自動化測試工程，為驗證診斷請求/響應(yīng)轉(zhuǎn)發(fā)的功能與性能，測試框架設(shè)計如下（后續(xù)闡述均以DoIP轉(zhuǎn)CAN(FD)為例）：

Tester測試模塊

負責(zé)與網(wǎng)關(guān)建立TCP連接

發(fā)送DoIP診斷請求和接收DoIP診斷響應(yīng)

作為測試用例流程的主開發(fā)模塊

仿真節(jié)點模塊

負責(zé)與目標(biāo)子網(wǎng)段的所有ECU節(jié)點建立傳輸協(xié)議（TP）連接

接收CAN FD診斷請求和發(fā)送CAN FD診斷響應(yīng)

DLL動態(tài)鏈接庫

負責(zé)在Tester測試模塊與仿真節(jié)點模塊之間高效傳遞數(shù)據(jù)

測試流程示意圖

03. 測試用例

以下列舉兩條關(guān)鍵性能測試用例：

（1）多網(wǎng)段并行請求/響應(yīng)路由延遲測試

測試目的：驗證網(wǎng)關(guān)在最大并行路由情況下的轉(zhuǎn)發(fā)延遲是否滿足要求

測試方法：假如網(wǎng)關(guān)每個子網(wǎng)段的最大并行能力是3，測試并行請求轉(zhuǎn)發(fā)則根據(jù)診斷路由表在每個子網(wǎng)段選擇3個ECU地址仿真發(fā)送診斷請求，檢測所有診斷請求首幀轉(zhuǎn)出的時間。測試并行診斷響應(yīng)則仿真發(fā)送功能尋址請求，等待功能尋址請求轉(zhuǎn)發(fā)后根據(jù)診斷路由表在每個子網(wǎng)段選擇3個ECU地址仿真發(fā)送診斷響應(yīng)，檢測所有診斷響應(yīng)轉(zhuǎn)發(fā)的時間。

測試報告實例：

多網(wǎng)段并行請求路由延遲測試報告示意圖

（2）多網(wǎng)段并行請求及響應(yīng)持續(xù)轉(zhuǎn)發(fā)測試

測試目的：驗證網(wǎng)關(guān)在最大并行及隊列路由情況下長時間運行的路由穩(wěn)定性（模擬刷寫場景，診斷請求數(shù)據(jù)可采用36服務(wù)）

測試方法：

默認會話：

默認會話一般不支持隊列，即在默認會話下驗證最大并行情況下的路由穩(wěn)定性。假如網(wǎng)關(guān)每個子網(wǎng)段的最大并行能力是3，測試則根據(jù)診斷路由表在每個子網(wǎng)段選擇3個ECU地址仿真發(fā)送診斷請求，每個診斷請求被路由到子網(wǎng)段之后仿真發(fā)送診斷響應(yīng)，等待診斷響應(yīng)轉(zhuǎn)發(fā)到上層網(wǎng)段之后再仿真發(fā)送診斷請求，以此類推測試執(zhí)行5min，檢測過程中的所有診斷請求和響應(yīng)轉(zhuǎn)發(fā)是否正常。

編程會話：

驗證最大并行及隊列情況下的路由穩(wěn)定性。假如網(wǎng)關(guān)每個子網(wǎng)段的最大并行能力是3，測試則根據(jù)診斷路由表在每個子網(wǎng)段選擇3個ECU地址仿真隊列發(fā)送診斷請求，每個診斷請求被路由到子網(wǎng)段之后仿真發(fā)送診斷響應(yīng)，等待診斷響應(yīng)轉(zhuǎn)發(fā)到上層網(wǎng)段之后再仿真發(fā)送診斷請求，以此類推測試執(zhí)行5min，檢測過程中的所有診斷請求和響應(yīng)轉(zhuǎn)發(fā)是否正常。

測試報告實例：

默認會話-多網(wǎng)段并行請求及響應(yīng)持續(xù)轉(zhuǎn)發(fā)測試示意圖

總結(jié)

至此，我們已完成診斷路由功能及其性能測試方案的核心內(nèi)容闡述。

北匯信息始終緊跟汽車網(wǎng)關(guān)技術(shù)前沿，依托與眾多OEM的深度合作，深入理解各類網(wǎng)關(guān)路由策略與設(shè)計需求，在汽車電子測試領(lǐng)域積累了豐富的實踐經(jīng)驗。如您有更深入的測試需求，歡迎隨時與我們聯(lián)系。

下期預(yù)告：我們將聚焦網(wǎng)關(guān)通信路由功能，詳細解析：

報文路由

信號路由

S2S (信號到服務(wù)路由)

敬請關(guān)注！

注：部分圖片來自Vector。

參考文獻：

[1] AUTOSAR_SRS_Gateway

[2] AUTOSAR_SWS_SocketAdaptor