01.

硬件測試

1.1 硬件模塊化測試

硬件模塊化測試一般包含以下三個部分

1）硬件模塊通道級測試（HW Bring-up測試）：一般是在硬件第一次生產出來，主要做各硬件模塊的通道級測試，譬如，MCU/SoC的最小系統運行是否正常；CAN/以太網通訊的基本功能是否正常；數字開關輸入/模擬信號輸入是否正常；負載驅動輸出是否正常；Camera數據流輸入/Display顯示功能是否正常等等。

2）硬件模塊信號級測試（設計驗證）：在各硬件模塊滿足通道測試的前提下，利用示波器等測試工具，對硬件模塊內部的關鍵信號進行測量，以確認驅動信號是否有振鈴產生；SoC電源的上下電時序是否滿足需求；Clock時鐘波形是否滿足spec需求等等。

3）硬件高速信號測試：在智駕域控制器中，部分告訴信號的測試已無法通過示波器的測量波形來評價信號質量的優劣，必須通過相應的一致性（Compliance Test）或者眼圖來評價告訴信號質量，例如以太網一致性測試（包括PMA測試，IOP測試），GMSL的一致性測試，LPDDR4/5的眼圖測試等等。

1.2 DV/PV測試

在上汽內部，主要參照上汽的SMTC38000001和SMTC38000006，制定產品的DV/PV測試計劃，并在OEM認可的的第三方實驗室進行相應的DV/PV測試。

根據實際項目的不同DV/PV測試會有不同的Leg圖，以上圖為列，分6個Leg測試，第一步是環境電氣，機械試驗，第二步是EMC測試，第三步是壽命測試，第四步是電性能測試，第五步是環境測試，第六個是參考樣件，根據不同的項目留不同的good sample。

02.

軟件接口測試

2.1 測試方案

創時主要提供的一個基于SOA架構的軟件，在上層應用上會提供大量的軟件接口。在測試過程中，大量的軟件接口就成為測試的一個難點，也是一個重點，如何保證測試的完整性和可靠性，目前采用的方案如下：

第一步：輸入

System model（系統模型）：通過客戶提供的系統模型（.arxml）知道整個系統在不同的host之間有多少上層RTE接口的Provider和Consumer

Communication description（通訊矩陣描述）：包括比較傳統的.dbc， 以太網、SOMEIP、CANFD用.arxml作為通訊矩陣的輸入：

Source code：通過Davinci自動生成

第二步：執行

將這些輸入全部導入到MotionWise Creator中并執行

第三步：輸出

在第三步中會生成一些.c跟.h的文件，這些test code主要用于把這些測試代碼集成到上層RTE接口，另外它會生成一些CANOE的.can文件CAPL文件跟xml文件，這樣測試的上位機和待測軟件的測試代碼就已經生成好了。

2.2 測試workflow

接口測試的主要分為兩個部分，第一個是輸入中模型輸入，模型輸入主要包含上層SWC之間的通信接口，第二個是通訊矩陣的描述，通訊矩陣描述包含外圍的CAN總線跟以太網信號傳輸到樣件中，因此相應會做一個RTE READ測試。

以系統模型輸入為例，比如兩個SWC之間的測試驗證。假設在客戶端的兩個SWC之間，通過模型識別到左側的test SWC作為一個provider，右側的SWC作為consumer，上一步已經生成了一些.C文件跟一些CAPL的或者是.can的一些測試腳本，那么當集成完整個測試鏈路之后，首先，外部會有Test PC， Test PC現在主要是基于CANoe的以太網的一個UDP的報文進行控制，Test PC會發一些UDP報文，然后通過ETH Stack發送給待測host，待測host通過IP地址跟UDP的port口直接將這條控制報文發送給上層待測的SWC， SWC通過報文內容的PayLoad，會知道現在是想要測試的哪一個接口、想用的測試方法是最大還是最小還是一個典型值，然后待測SWC會將這個數據通過RTE write的方式寫入這個接口。寫入完成之后，待測SWC會把寫入成功的返回值又通過以太網的報文發送，那么我們知道我們其實成功觸發的這條測試案例，下一步右側待測的SWC，會通過主播報文，把它所收到的值通過UDP的主播報文發送到以太網上面，然后通過一個反序列化的操作，去解析是否它跟這個測試觸發想要設置的命令跟拿到的命令對比，如果是一致的，那就認為這條測試案例，這個接口在provider端跟consumer端都是測試通過的。

跨HOST的測試也是用同樣的方式。比如現在左側test SWC是一個待測的話，它只是相當于把自己接收到的數據，通過RTE接口，再通過Switch發送到了右端另外一個host上一個待測的SWC，右側SWC也是會通過UDP的主播報文，把它接收到的數據返回到總線然后回傳給test PC，依然是利用一個反序列化的一個動作去解析到底設置的值跟得到的值是否是一致。

如果是對外總線的驗證測試，整體的思路是一樣的，只是走的鏈路可能不一樣。在測CAN或者是測包括以太網的時候，主要會把外圍的真實的CAN的環境接進去，上層待測SWC數據接收方式走真實CAN drv的方式往上層傳輸，傳輸到最上層接收端ApCom，然后ApCom會再把這些數據，根據模型把它RTE write到不同的待測SWC中，那么待測SWC也依然會往外發它所接收到值的組播報文，然后test PC通過這些定義好的組播報文的地址跟PayLoad的做一個反序列化，然后把數據進行對比。

03.

系統測試

3.1 CAN通訊測試

CAN通訊測試跟前面類似，根據客戶的arxml輸入，包括模型跟dbc的輸入去識別到它到底有哪些接口，開發相應的CAPL測試腳本，來觸發dot所需要接收到的值，發送它的最大最小，然后還會額外關心通訊的報文周期、DLC的長度、不同signal的PayLoad排布方式、mapping的方式。然后把它再整合到整個CANoe工程中，最后通過test module方式，將整個CAN總線的測試結果反饋出來。

有時候會通過串口或者勞特巴赫去檢測CAN內部通信，比如說測試過程中對內有需求，如當DLC長度小于定義的時候，它不應該往上傳輸，這樣就要配合勞特巴赫去ApCom，或者CAN Stack里面去看一下這一幀的數據，在這個故障注入的時候，到底有沒有往RTE接口上去傳。

3.2 FOTA測試

FOTA測試主要分為正向測試和故障注入測試：

正向測試：

1.制作更新包

2.用ICC simulator觸發更新

3.用Tcpdump記錄板子和外部的通信

4.在串口顯示更新成功后，上載板子里的更新軟件與所做的更新包進行對比

故障注入測試：

1.制作更新包

2.更改ICC Simulator代碼進行故障注入

3.用TCPdump記錄板子和外部的通信

4.分析板子是否報告需求描述的錯誤

3.3 診斷測試

測試方法

1.將用于模擬DID（Data ID），RID（Routine ID）的測試代碼以及用來模擬DTC觸發的錯誤注入代碼插入到對應的SWC中。DSC作為其中的一個SWC通過RTE接口來收集其他SWC發送過來的診斷相關模擬信號

2.基于ISO-14229的基本診斷服務主要放置DCM（Diagnostic Communication Manager）和DEM（Diagnostic Event Manager）中。這塊可以通過DiVa插件在CANoe中進行測試。

3.4 以太網通訊測試

在一些需求里面，有些報文是不走SOMIP服務，可能只是走單純的UDP或者TCP的一個鏈路，那么在這個過程中，一樣是通過客戶的arxml的輸入，通過腳本自動生成測試代碼；然后使用腳本，注入通過XCP需要觀測的一些變量，添加到A2L文件中；第三步通過CAPL觸發Eth的package發送去板端，發送的過程中，數據從電腦或CANoe，通過Eth的Switch傳送到上層的EthCom，然后再傳遞SWC接口，SWC接口所收到的數據可以通過XCP的方式觀測到，然后在一個測試周期里面把所有的上層RTE接口跟發送UDP報文里面的這些關鍵的signal進行對比。

3.5 iECU3.1時間同步測試

時間同步主要分為兩個域——AGT和EGT， EGT可以認為是板子內部Domain0的一個域， AGT是對外部有GrandMaster的一個域。

EGT域通過TCPdump的方式去抓取域內通訊的PTP報文，然后觀察它：比如syn跟follow_up是否是正常成對出現，時間同步報文里面SequenceCounter或者ClockIdetify是否都是滿足于預期; 其次會觀察Pdelay request跟Response 和Response ACK是否能被正確的交互出來。

AGT測試目前是通過CANoe或者樹莓派模擬發送AGT的報文，AGT的報文通過串口或UDP報文把它的時間打印出來，然后將內部的AGT時間域通過串口的信息打印出來，或者通過其他的UDP報文也發送出來，這樣可以通過UDP報文之間一個時間的對比的差值，來反映同步上的這個狀態誤差到底在多少。目前，AGT是可以做到在十毫秒左右，基本上都是可以滿足客戶的要求。

04.

壓力與性能測試

大部分的feature在簡單工況下面可以滿足測試或者滿足需求的，但是如果真的是在一個壓力測試環境中，它或多或少會出現一些異常項。因此會做大量的壓力跟性能測試快速的檢測出軟件里面的薄弱環節。

4.1 CAN通訊測試（丟幀）-臺架測試方案

CAN 模擬輸入：

通過CAPL 腳本模擬發送所有DUT接受報文

SWC：（ApCOM+MW）正常運行

在CANProxy FreeRunning SWC中增加測試代碼，通過RTE接口讀取所有PDU的EGT時間戳

測試數據將通過以下方式輸出：

在線輸出：UART接口，以太網接口

離線輸出：通過SCP命令

測試結果

基于在線（或者離線所得到的測試數據）

利用自動化分析腳本，導入測試后的數據，得到所有PDU EGT時間戳的差值與數量，通過對應工時計算諸葛輸出各個PDU在消費方CANProxy FreeRunning SWC的丟幀率

4.2 CAN通訊丟幀測試 - 測試代碼自動生成器

1.識別所有待測接口

解析通訊模型輸入文件 Host .arxml（SH or PH）

濾出消費方CANProxy FreeRunning SWC中所有攜帶EGT時間戳的接口

2.定義測試代碼模板

通過手動方式，對某一PDU的EGT時間戳開發測試代碼

集成并測試此PDU的丟幀率，驗證測試結果是否有效

基于上述有效的測試方法，定義測試代碼模板，以推廣至所有待測PDU

3.自動生成測試代碼

利用Python腳本，將前序識別到的待測PDU接口全部應用至已定義的測試代碼模板中

自動生成代碼xxx.c文件

4.編譯&刷新

在PIE包中集成測試代碼，通過Magpie單獨編譯FreeRunning SWC

將編譯所得xxx.bin文件更新至待測樣件中

上電后，通過QNX Shell界面觀察代碼運行情況，確保Xavior正常啟動

4.3 CAN通訊丟幀測試 - 測試數據自動解析器

1.獲取測試數據

CAN數據

xxx.blf（CANoe）

Etheret數據

xxx.pcap（Wireshark）

xxx.pcap（Tcpdump）

RTE_Read數據

xxx.text

2.自動分析

通過EGT時間戳，對其所有測試數據

使用Python腳本，分別計xxx.pcap and xxx.txt file的實際丟幀率

1.計算得到測試時間長度（End.Time – Start. Time）

2.計算得到該測試時長的理論有效EGT采樣點個數

3.計算得到該測試時長的實際有效EGT采樣點個數

4.將計算輸出帶入公式=（1-實際采樣點個數/理論采樣點個數）%，得到實際丟幀率

3.輸出最終測試結果

以太網Tcpdump丟幀率

消費方CANProxy RTE_Read接口丟幀率

通過丟幀率數據，識別丟幀現象出現在鏈路

Aruix側？

MW of Aruix側？

MW of Xavior側？

重復測10次，保證測試樣本足夠，統計后得到最終測試結果

4.4 性能測試

實際測試過程是在一個上層沒有布真實客戶算法的空RTE環境中，那么怎么保證在空的環境里面跟集成客戶算法的環境里SOA的穩定性呢？這需要做一個性能測試，主要分為task跟core兩個層面。

目前用到了一個內部叫做Perf的測試工具，它也是通過以太網的方式，支持python2或者3。敲一段命令之后，它可以觸發到軟件內部的Check point進行一個計算，最后計算的Summary以CSV格式保存下來。

最終perf會把這些數據全部匯總到Core上面，這樣就可以看到在未集成算法的時候整個SOA它的負載率是多少。這個工具不僅可以用到未集成上層算法的環境中，如果客戶集成了他自己的應用算法，他想看一下在集成應用算法的時候，到底自己的WCET負載率到底有沒有超出預期，也是可以通過這個工具非常直觀的看出，或者可以做一個標定的用途，來滿足整體的系統設計需求。

審核編輯 ：李倩