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

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

充分的測試驗證需實現(xiàn)需求階段至系統(tǒng)階段的全覆蓋。

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

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

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

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

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

01. 網(wǎng)絡通信測試驗證

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

1.需求分析

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

2.驗證方法

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

3.驗證范圍

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

CAN 驗證范圍

LIN 驗證范圍

Ethernet 驗證范圍

02. 網(wǎng)絡管理測試驗證

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

1.需求分析

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

2.驗證方法

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

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

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

R1：120Ω；R2:120Ω。?

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

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

3.驗證范圍

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

03. 診斷服務測試驗證

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

1.需求分析

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

2.驗證方法

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

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

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

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

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

3.驗證范圍

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

04. 時間同步測試驗證

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

1.需求分析

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

2.驗證方法

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

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

轉(zhuǎn)換板：100/1000base-T1 轉(zhuǎn)換為 100base-Tx/1000base-T。

流量儀：包含多個車載以太網(wǎng)接口的流量發(fā)生設備。

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

3.驗證范圍

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

編輯：黃飛

?