01.

硬件測(cè)試

1.1 硬件模塊化測(cè)試

硬件模塊化測(cè)試一般包含以下三個(gè)部分

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

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

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

1.2 DV/PV測(cè)試

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

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

02.

軟件接口測(cè)試

2.1 測(cè)試方案

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

第一步：輸入

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

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

Source code：通過Davinci自動(dòng)生成

第二步：執(zhí)行

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

第三步：輸出

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

2.2 測(cè)試workflow

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

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

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

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

03.

系統(tǒng)測(cè)試

3.1 CAN通訊測(cè)試

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

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

3.2 FOTA測(cè)試

FOTA測(cè)試主要分為正向測(cè)試和故障注入測(cè)試：

正向測(cè)試：

1.制作更新包

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

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

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

故障注入測(cè)試：

1.制作更新包

2.更改ICC Simulator代碼進(jìn)行故障注入

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

4.分析板子是否報(bào)告需求描述的錯(cuò)誤

3.3 診斷測(cè)試

測(cè)試方法

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

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

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

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

3.5 iECU3.1時(shí)間同步測(cè)試

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

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

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

04.

壓力與性能測(cè)試

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

4.1 CAN通訊測(cè)試（丟幀）-臺(tái)架測(cè)試方案

CAN 模擬輸入：

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

SWC：（ApCOM+MW）正常運(yùn)行

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

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

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

離線輸出：通過SCP命令

測(cè)試結(jié)果

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

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

4.2 CAN通訊丟幀測(cè)試 - 測(cè)試代碼自動(dòng)生成器

1.識(shí)別所有待測(cè)接口

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

濾出消費(fèi)方CANProxy FreeRunning SWC中所有攜帶EGT時(shí)間戳的接口

2.定義測(cè)試代碼模板

通過手動(dòng)方式，對(duì)某一PDU的EGT時(shí)間戳開發(fā)測(cè)試代碼

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

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

3.自動(dòng)生成測(cè)試代碼

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

自動(dòng)生成代碼xxx.c文件

4.編譯&刷新

在PIE包中集成測(cè)試代碼，通過Magpie單獨(dú)編譯FreeRunning SWC

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

上電后，通過QNX Shell界面觀察代碼運(yùn)行情況，確保Xavior正常啟動(dòng)

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

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

CAN數(shù)據(jù)

xxx.blf（CANoe）

Etheret數(shù)據(jù)

xxx.pcap（Wireshark）

xxx.pcap（Tcpdump）

RTE_Read數(shù)據(jù)

xxx.text

2.自動(dòng)分析

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

使用Python腳本，分別計(jì)xxx.pcap and xxx.txt file的實(shí)際丟幀率

1.計(jì)算得到測(cè)試時(shí)間長(zhǎng)度（End.Time – Start. Time）

2.計(jì)算得到該測(cè)試時(shí)長(zhǎng)的理論有效EGT采樣點(diǎn)個(gè)數(shù)

3.計(jì)算得到該測(cè)試時(shí)長(zhǎng)的實(shí)際有效EGT采樣點(diǎn)個(gè)數(shù)

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

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

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

消費(fèi)方CANProxy RTE_Read接口丟幀率

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

Aruix側(cè)？

MW of Aruix側(cè)？

MW of Xavior側(cè)？

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

4.4 性能測(cè)試

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

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

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

審核編輯 ：李倩