01.

硬件測試

1.1 硬件模塊化測試

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

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

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

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

1.2 DV/PV測試

在上汽內(nèi)部，主要參照上汽的SMTC38000001和SMTC38000006，制定產(chǎn)品的DV/PV測試計劃，并在OEM認(rèn)可的的第三方實驗室進行相應(yīng)的DV/PV測試。

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

02.

軟件接口測試

2.1 測試方案

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

第一步：輸入

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

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

Source code：通過Davinci自動生成

第二步：執(zhí)行

將這些輸入全部導(dǎo)入到MotionWise Creator中并執(zhí)行

第三步：輸出

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

2.2 測試workflow

接口測試的主要分為兩個部分，第一個是輸入中模型輸入，模型輸入主要包含上層SWC之間的通信接口，第二個是通訊矩陣的描述，通訊矩陣描述包含外圍的CAN總線跟以太網(wǎng)信號傳輸?shù)綐蛹?，因此相?yīng)會做一個RTE READ測試。

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

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

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

03.

系統(tǒng)測試

3.1 CAN通訊測試

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

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

3.2 FOTA測試

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

正向測試：

1.制作更新包

2.用ICC simulator觸發(fā)更新

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

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

故障注入測試：

1.制作更新包

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

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

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

3.3 診斷測試

測試方法

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

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

3.4 以太網(wǎng)通訊測試

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

3.5 iECU3.1時間同步測試

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

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

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

04.

壓力與性能測試

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

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

CAN 模擬輸入：

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

SWC：（ApCOM+MW）正常運行

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

測試數(shù)據(jù)將通過以下方式輸出：

在線輸出：UART接口，以太網(wǎng)接口

離線輸出：通過SCP命令

測試結(jié)果

基于在線（或者離線所得到的測試數(shù)據(jù)）

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

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

1.識別所有待測接口

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

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

2.定義測試代碼模板

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

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

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

3.自動生成測試代碼

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

自動生成代碼xxx.c文件

4.編譯&刷新

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

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

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

4.3 CAN通訊丟幀測試 - 測試數(shù)據(jù)自動解析器

1.獲取測試數(shù)據(jù)

CAN數(shù)據(jù)

xxx.blf（CANoe）

Etheret數(shù)據(jù)

xxx.pcap（Wireshark）

xxx.pcap（Tcpdump）

RTE_Read數(shù)據(jù)

xxx.text

2.自動分析

通過EGT時間戳，對其所有測試數(shù)據(jù)

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

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

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

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

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

3.輸出最終測試結(jié)果

以太網(wǎng)Tcpdump丟幀率

消費方CANProxy RTE_Read接口丟幀率

通過丟幀率數(shù)據(jù)，識別丟幀現(xiàn)象出現(xiàn)在鏈路

Aruix側(cè)？

MW of Aruix側(cè)？

MW of Xavior側(cè)？

重復(fù)測10次，保證測試樣本足夠，統(tǒng)計后得到最終測試結(jié)果

4.4 性能測試

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

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

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

審核編輯 ：李倩