汽車電子的高速發展決定了基礎軟件所面臨的要求將會更加嚴格，其要求會覆蓋軟件的安全性、穩定性、可擴展性等方方面面。為了提高軟件質量，降低軟件應用風險，構建高安全、高可靠性、高效率實施的基礎軟件驗證平臺則是必不可少的一環。

當前，汽車電子廠商大多采用 V 模式進行新產品開發，相應的，基礎軟件驗證也可以參照 V 模型流程，持續進行不同層面的驗證。

充分的測試驗證需實現需求階段至系統階段的全覆蓋。

在需求分析階段，要考慮系統驗證的計劃，包括確保每一個需求點都是可驗證的，并設計相應的初步系統驗證用例；

在概要設計階段，要考慮部件驗證計劃，設計相應用例，驗證高級模塊的功能以及模塊之間的接口關系；

在詳細設計階段，要考慮單元驗證計劃，編制單元驗證用例。

總體而言，每部分的軟件驗證包括五個基本過程：測試需求分析、測試策劃、設計與實現、測試執行、測試總結 。

那對于車載ECU通信而言，有哪些驗證項呢？

01. 網絡通信測試驗證

網絡通信是實現汽車各控制器進行信息交互的橋梁，無論是傳統的分布式電子電氣架構，還是域控制器架構，或是基于中央大腦的電子電氣架構，其在汽車主干網中常用的總線通信類型大致包含CAN總線、LIN 總線、以太網三類。此外，智能網聯化的發展也對車輛的網絡通信提出了大帶寬、高時效，功能及信息安全防護等要求。上述三類網絡通信方式的組合及其在基礎軟件驗證平臺的應用，基本能夠滿足汽車在不同架構類型及不同功能場景下的通信需求。與之相對應的基礎測試驗證則成為了檢驗基礎軟件是否滿足通信需求的重要一環。

1.需求分析

基礎軟件雖然具備軟硬件的解耦、接口的可復用性、平臺的可移植性等優勢，但是其可靈活配置的特性也決定了其面向整車系統時配置參數具有差異化或在基礎軟件代碼開發移植階段存在不滿足整車通信需求的情況。例如某一車型平臺或某一架構下各個控制器的基礎軟件在開發階段的通信參數設置、信號交互、總線通信故障處理邏輯等與期望不一致的情況。這些差異化的內容往往會導致汽車總線無法通信、功能無法正常執行等問題，因此網絡通信測試的驗證務必在單個控制器開發完成后進行，以保證裝車后的通信質量。

2.驗證方法

CAN/LIN 網絡通信的驗證主要針對通信配置參數、總線容錯處理及恢復邏輯、報文交互等內容進行驗證，因此測試設計方法主要為需求分析方法、邊界值分析、等價類法。為實現網絡通信驗證，需視不同的需求搭建測試環境。網絡通信驗證的測試環境可分為基于示波器的測試、基于總線分析儀的測試、基于總線干擾儀的測試三類。

3.驗證范圍

依據 OSI 模型，為保證基礎軟件開發嚴格按照需求進行，需針對通信需求內容進行覆蓋。網絡通信的測試驗證主要包含數據鏈路層、交互層、應用層測試。數據鏈路層主要針對采樣點、波特率、幀類型兼容等層面進行基礎軟件通信配置參數的驗證；交互層主要針對車輛的報文交互是否嚴格按照通信定義開發進行驗證，應用層主要針對總線故障及 busoff 等網絡容錯處理恢復策略進行驗證。此外，如有功能或信息安全的應用，需基于交互層進行算法邏輯的驗證。如下表為網絡通信基礎驗證的部分用例，詳細測試用例中的每條用例應包含有唯一的編號、需明確需求點、測試目的、測試環境、測試步驟、評價標準等內容。

CAN 驗證范圍

LIN 驗證范圍

Ethernet 驗證范圍

02. 網絡管理測試驗證

網絡管理主要負責對汽車上控制器進行配置管理和協調工作的，無論是傳統的汽油車，還是新興的電動車，其控制器的供電均是通過蓄電池來提供的。網絡管理可以通過車載網絡，設計一套規則，來實現各控制器的睡眠和喚醒，以此來減少蓄電池的耗電。例如：AUTOSAR-NM 是基于 AUTOSAR 架構提出的網絡管理方案，通過 BusSleep、PreSleep、Network 三個狀態及其子狀態，來實現整車控制器的協同睡眠和喚醒。因此，網絡管理測試對于協同睡眠和喚醒功能的驗證是整車功能實現的重要保障。

1.需求分析

AUTOSAR 架構雖然完整定義了網絡管理組件中網絡狀態的類型以及不同網絡狀態之間跳轉的條件，但是實際控制器的網絡管理協議棧成熟度各不相同，并且軟件模塊之間如果沒有較好地進行解耦，進而就會造成車輛上下電的不穩定性，某些功能場景也會受到影響。所以不論是單部件環境下的休眠和喚醒還是整車環境下協同休眠和喚醒，都是保障汽車通信和功能實現的重要前提。

2.驗證方法

控制器的網絡狀態往往在總線中即可獲取到，影響其狀態跳轉的因素基本可分為本地條件與遠程條件兩類。本地條件與供電關聯較強，遠程條件與總線狀態交互較強，因此結合影響因素，其網絡管理的測試驗證環境如下圖所示：

總線分析儀：用來模擬除控制器外的其他節點發送和接收報文；記錄監測總線報文；對控制器進行 ACK 應答。

電源：通過 PC 可控模擬不同供電電壓。?

R1：120Ω；R2:120Ω。?

注：若控制器內部含有 120Ω 終端電阻則無需匹配 R2；若控制器內部不含有120Ω 終端電阻則需同時匹配 R1 和 R2。

注：若控制器為 Ethernet 控制器，CAN_H/CAN_L 為 ETH_P/ETH_N，無終端電阻。

3.驗證范圍

為保證單部件控制器網絡管理行為的正確性，需要對控制器的網絡管理策略進行全方位的測試。網絡管理的測試驗證主要包含網絡管理報文數據格式測試、網絡管理狀態轉換策略測試、特殊網絡管理策略測試。網絡管理報文數據格式測試主要用來驗證控制器的網絡管理報文格式是否和需求定義保持一致。網絡管理狀態轉換策略測試主要用來驗證控制器的網絡狀態跳轉是否滿足規范要求。特殊網絡管理策略測
試主要用來驗證控制器在極端總線條件下（如總線高負載率或總線 busoff）的狀態跳轉是否受到影響。如下表為網絡管理測試驗證部分用例，詳細測試用例中的每條用例應包含的內容與網絡通信要求一致。

03. 診斷服務測試驗證

網絡診斷應用于車輛的初始目的是確定汽車工作狀態，排查汽車故障。隨著診斷協議的不斷完善，其應用場景也不斷在擴展，例如產品開發測試階段的軟件升級、生產階段的下線配置、售后階段的故障診斷、用戶使用過程中的 OTA 遠程升級以及遠程診斷等。這些診斷功能場景基本涵蓋了車輛的全生命周期，診斷協議則是實現這些功能的基礎原則。因此，診斷服務測試驗證是實現診斷功能場景的基本保證。

1.需求分析

ECU 診斷功能是由內部自診斷功能及相關診斷協議組成。通常大多數診斷功能是由兩者共同完成的，診斷服務中包含 ECU 自診斷的數據，維修車輛則是通過診斷協議讀取自診斷的數據。例如車輛行駛過程中可能會發生一些故障 , 當故障發生時會以點亮報警燈等方式來提示駕駛員。但具體故障的原因是無法通過報警燈體現的，這時則需要通過車上的 OBD 接口連接診斷儀來將故障代碼讀取出來。而診斷測試可實現 ECU 診斷功能的驗證及診斷協議一致性檢測，從而確保裝車后車輛診斷功能能夠正常運行。

2.驗證方法

診斷測試的驗證主要針對控制器收發多幀報文情況、診斷服務、子功能、診斷會話控制、安全狀態和相關定時參數等內容進行驗證。為實現網絡診斷驗證，搭建下面基于總線分析儀的測試環境。基于總線分析儀的測試設備包括電源、總線分析儀，測試環境如下圖所示：

總線分析儀：用來模擬除控制器外其他節點發送和接收報文；記錄監測總線報文；對控制器進行ACK 應答。

電源：可模擬不同供電電壓。

R1R2：選配型終端電阻 120 Ω。對于終端型控制器，需選配 R1 或 R2；對于非終端型控制器，需同時配置 R1 與 R2。

注：若控制器為 Ethernet 控制器，CAN_H/CAN_L 為 ETH_P/ETH_N，無終端電阻。

3.驗證范圍

網絡診斷的測試驗證主要包含傳輸層及應用層測試。傳輸層主要針對控制器能夠進行多幀報文的收發等層面進行診斷配置參數的驗證；應用層主要針對診斷服務、子功能、診斷會話控制、安全狀態和相關定時參數進行驗證。如下表為網絡診斷基礎驗證的部分用例，詳細測試用例中的每條用例應包含有唯一的編號、需明確需求點、測試目的、測試環境、測試步驟、評價標準等內容。

04. 時間同步測試驗證

時鐘同步功能給車載系統提供統一的時間基準，在高級別智能駕駛、視音頻時鐘同步、數據上傳分析等場景中發揮著越來越重要的作用。目前以太網時鐘同步協議中，使用最多的為精準時鐘同步協議（Generalized Precision Time Protocol, gPTP），遵循 IEEE 802.1AS 標準。在 AUTOSAR 中也有對應的模塊eth_stync 實現該協議。

1.需求分析

gPTP 分為 Grand Master 和 slave，顧名思義，前者為系統中提供授時的節點，后者將自己的本地時間同步到 Grand Master 的時鐘進行同步。gPTP 網絡拓撲示意圖如下圖所示：

2.驗證方法

gPTP 測試的驗證與被測件的角色相關，有針對 Endpoint 的測試以及 Bridge 的測試，測試環境如下圖所示：

電源：可模擬不同供電電壓。

轉換板：100/1000base-T1 轉換為 100base-Tx/1000base-T。

流量儀：包含多個車載以太網接口的流量發生設備。

電腦：安裝了測試軟件的測試電腦。

3.驗證范圍

時間同步測試主要包含 gPTP 協議一致性測試和 gPTP 配置測試，如表 3.2-6 為網絡診斷基礎驗證的部分用例，詳細測試用例中的每條用例應包含有唯一的編號、需明確需求點、測試目的、測試環境、測試步驟、評價標準等內容。時鐘同步測試驗證部分用例如下表所示：

編輯：黃飛

?