作者 | 澔然里

小編 | Crystal

引言

在汽車(chē)以太網(wǎng)的通信測(cè)試中，面對(duì)復(fù)雜的協(xié)議棧分層與交互，一個(gè)核心挑戰(zhàn)在于：如何高效、直接地對(duì)ECU內(nèi)部的網(wǎng)絡(luò)層、傳輸層等協(xié)議實(shí)現(xiàn)進(jìn)行驗(yàn)證？

僅僅通過(guò)外部網(wǎng)絡(luò)接口發(fā)送測(cè)試數(shù)據(jù)包，往往只能進(jìn)行黑盒測(cè)試，難以精準(zhǔn)觸達(dá)和控制ECU內(nèi)部通信棧的特定狀態(tài)與行為。為此，AUTOSAR測(cè)試體系中的兩大關(guān)鍵工具——上層測(cè)試器 （Upper Tester，簡(jiǎn)稱UT）與服務(wù)原語(yǔ)（Service Primitive，簡(jiǎn)稱SP），為解決這一問(wèn)題提供了標(biāo)準(zhǔn)化的“內(nèi)部通道”。

●UT是測(cè)試儀在ECU內(nèi)部的“代理”，它通過(guò)專用于測(cè)試的物理接口和測(cè)試協(xié)議，直接向ECU的Ethernet通信棧發(fā)送測(cè)試指令來(lái)配置被測(cè)協(xié)議棧的參數(shù)或觸發(fā)被測(cè)協(xié)議棧產(chǎn)生某種行為。

●SP則是UT與通信棧之間的“標(biāo)準(zhǔn)化語(yǔ)言”，它定義了測(cè)試所需的特定操作和數(shù)據(jù)接口，使UT能夠精確模擬上層服務(wù)或調(diào)用底層服務(wù)，從而控制通信協(xié)議棧進(jìn)入所需的測(cè)試狀態(tài)。

二者的聯(lián)手，實(shí)質(zhì)上是為ECU的通信協(xié)議棧賦予了一個(gè)標(biāo)準(zhǔn)化、可遠(yuǎn)程操控的測(cè)試接口。這使得諸如OPEN Alliance TC8測(cè)試規(guī)范中對(duì)TCP/IP協(xié)議棧一致性提出的嚴(yán)苛要求，得以被系統(tǒng)性地驗(yàn)證。本文將深入解析UT與SP如何協(xié)同工作，打通從外部測(cè)試工具到通信棧內(nèi)部的標(biāo)準(zhǔn)化路徑，從而實(shí)現(xiàn)對(duì)以太網(wǎng)通信棧狀態(tài)與行為的精準(zhǔn)、可編程的驗(yàn)證邏輯。

UT工作原理

在介紹UT之前，我們先得清楚IUT（被測(cè)實(shí)現(xiàn)，Implementation Under Test）的概念。在協(xié)議一致性測(cè)試的語(yǔ)境下，IUT 特指正在被測(cè)試的那個(gè)具體的、待檢驗(yàn)的協(xié)議實(shí)現(xiàn)代碼或軟件模塊。而UT本質(zhì)上是一個(gè)運(yùn)行在DUT中的應(yīng)用，用于輔助測(cè)試執(zhí)行。UT支持的指令和格式遵循AUTOSAR體系下的可測(cè)試性協(xié)議與服務(wù)原語(yǔ)規(guī)范（Testability Protocol and Service Primitives），OEM或零部件供應(yīng)商可按照規(guī)范自行開(kāi)發(fā)和集成UT，也可購(gòu)買(mǎi)第三方源代碼自行集成，或通過(guò)第三方服務(wù)商來(lái)進(jìn)行開(kāi)發(fā)或集成。

可測(cè)試性協(xié)議與服務(wù)原語(yǔ)規(guī)范中的兩種典型測(cè)試場(chǎng)景如下圖所示：

方案1（上圖左)TS（Test System）與UT之間使用專用的命令傳輸通道，這個(gè)傳輸通道可以是CAN通道、UART等。在方案2(上圖右)中TS與UT之間的命令傳輸需要借助IUT來(lái)完成，在實(shí)際應(yīng)用中，就是創(chuàng)建一個(gè)UDP Socket來(lái)收發(fā)命令。方案1的優(yōu)點(diǎn)是TS與UT之間的命令傳輸不占用IUT任何資源，缺點(diǎn)是系統(tǒng)在硬件和軟件方面都更加復(fù)雜。方案2正好相反，考慮到大多數(shù)場(chǎng)景中，Device Under Test（被測(cè)設(shè)備，以下簡(jiǎn)稱DUT）都不會(huì)專門(mén)在硬件上預(yù)留命令傳輸通道，因此方案2是在實(shí)現(xiàn)上最便捷的方案。接下來(lái)，我們將在方案2的基礎(chǔ)上，對(duì)測(cè)試原理展開(kāi)進(jìn)一步討論。

測(cè)試過(guò)程主要有以下幾個(gè)步驟：

測(cè)試命令下達(dá)（CC通道）

●步驟1 & 2: TS將需要UT執(zhí)行的命令（例如：“調(diào)用TCP的發(fā)送數(shù)據(jù)原語(yǔ)”）封裝成一個(gè)特殊的控制數(shù)據(jù)包，通過(guò)LT發(fā)送給IUT。這個(gè)數(shù)據(jù)包的目的地址和協(xié)議被設(shè)計(jì)為能被IUT正常接收和處理，但其 payload 是給UT的指令。

●步驟3: IUT收到這個(gè)數(shù)據(jù)包后，并不將其視為普通的網(wǎng)絡(luò)數(shù)據(jù)，而是通過(guò)內(nèi)部接口（這構(gòu)成了CC通道的最后一段）將其解包并傳遞給上層的UT。

觸發(fā)IUT行為（UC通道）

●步驟4 & 5: UT收到來(lái)自TS的指令后，解析它，并據(jù)此通過(guò)UC通道調(diào)用相應(yīng)的SP。例如，UT調(diào)用SEND_DATA原語(yǔ)，要求IUT發(fā)送一段特定的數(shù)據(jù)。

觀察IUT反應(yīng)（LC通道）

●步驟6 & 7: IUT在接到UT的SP調(diào)用后，開(kāi)始執(zhí)行標(biāo)準(zhǔn)的協(xié)議操作。例如，它會(huì)構(gòu)建一個(gè)真實(shí)的TCP數(shù)據(jù)包，然后通過(guò)LC通道發(fā)送給網(wǎng)絡(luò)另一端的LT。

●步驟8: LT作為網(wǎng)絡(luò)上的一個(gè)節(jié)點(diǎn)，捕獲到這個(gè)由IUT發(fā)出的TCP數(shù)據(jù)包，并將其內(nèi)容完整地上報(bào)給TS。

驗(yàn)證與判斷

●步驟9: TS將LT捕獲到的實(shí)際網(wǎng)絡(luò)報(bào)文（例如：TCP頭部的序列號(hào)、確認(rèn)號(hào)、標(biāo)志位等）與測(cè)試用例預(yù)期的結(jié)果進(jìn)行比對(duì)。

●最終判斷: 如果兩者一致（例如，發(fā)出的TCP報(bào)文序列號(hào)完全正確），則測(cè)試通過(guò)；如果不一致，則測(cè)試失敗，說(shuō)明IUT的實(shí)現(xiàn)可能存在缺陷。

可測(cè)試性協(xié)議與服務(wù)原語(yǔ)規(guī)范

（一）消息格式

TS與UT之間測(cè)試消息的格式借鑒了汽車(chē)領(lǐng)域廣泛使用的SOME/IP標(biāo)準(zhǔn)，但進(jìn)行了簡(jiǎn)化和定制，如下圖所示：

Service ID：長(zhǎng)度為16bits，服務(wù)標(biāo)識(shí)符。固定用于標(biāo)識(shí)這是一個(gè)“可測(cè)試性服務(wù)”消息。默認(rèn)值為 0x0105，但可配置

EVB：長(zhǎng)度為1bit，事件位，設(shè)置為1表示這是一個(gè)事件消息

Group ID（GID）：長(zhǎng)度為7bits，服務(wù)組標(biāo)識(shí)符對(duì)SP進(jìn)行邏輯分組(如：TCP組、UDP組、IPv4組)

Service Primitive ID（PID）：長(zhǎng)度為8bits，SP標(biāo)識(shí)符，核心字段，指定要調(diào)用的具體SP(如：SEND_DATA）

Length：長(zhǎng)度為32bits，數(shù)據(jù)長(zhǎng)度。計(jì)算方式：8字節(jié) + 參數(shù)數(shù)據(jù)的字節(jié)數(shù)，這8字節(jié)指的是從Protocol Version開(kāi)始到消息頭結(jié)束的部分

Protocol Version：8bits，協(xié)議版本，必須為常量 0x01

Interface Version：8bits，接口版本，必須為常量 0x01

Type ID(TID)：8bits，類型標(biāo)識(shí)符，決定消息類型：請(qǐng)求(Request)、響應(yīng)(Response)、事件(Event)等

Result ID(RID)：8bits，結(jié)果標(biāo)識(shí)符，在響應(yīng)消息中指示操作結(jié)果(成功/錯(cuò)誤碼)

Parameters：參數(shù)數(shù)據(jù)，可變長(zhǎng)度，由LEN字段確定，包含SP所需的輸入?yún)?shù)或返回?cái)?shù)據(jù)

（二）消息交換機(jī)制

TS與UT之間的消息交換，采用一種非阻塞的請(qǐng)求-響應(yīng)模型作為其核心機(jī)制。這意味著：

●TS發(fā)出一個(gè)請(qǐng)求后，不會(huì)等待UT完成所有工作，而是會(huì)立即得到一個(gè)“已收到”的響應(yīng)。

●這保證了通信通道不會(huì)被長(zhǎng)時(shí)間阻塞，TS可以繼續(xù)管理其他測(cè)試任務(wù)。

●任何需要等待的事件（如收到數(shù)據(jù)、連接建立）都會(huì)通過(guò)獨(dú)立的事件消息在之后異步通知TS

下圖清晰地展現(xiàn)了兩種典型場(chǎng)景：

場(chǎng)景1，如上圖左所示:

1. TS發(fā)送請(qǐng)求，命令UT執(zhí)行一個(gè)簡(jiǎn)單原語(yǔ)（例如，讀取某個(gè)內(nèi)部狀態(tài)）。

2. UT立即執(zhí)行該操作，并發(fā)送響應(yīng)，告知TS請(qǐng)求已成功執(zhí)行。

3. 整個(gè)交互結(jié)束，沒(méi)有后續(xù)的事件發(fā)生。

適合：GET_VERSION、STATIC_ADDRESS、INTERFACE_UP 等一次性動(dòng)作

場(chǎng)景2，如上圖右所示：

1. TS發(fā)送請(qǐng)求，命令UT執(zhí)行一個(gè)復(fù)雜的原語(yǔ)（例如，RECEIVE_AND_FORWARD、LISTEN_AND_ACCEPT等）。

2. UT立即返回響應(yīng)，表示“命令已收到，正在執(zhí)行”。

3. 在后續(xù)過(guò)程中，當(dāng)預(yù)設(shè)的條件滿足時(shí)（例如，數(shù)據(jù)已成功發(fā)出、收到了對(duì)方的回復(fù)），UT會(huì)主動(dòng)、異步地發(fā)送一個(gè)或多個(gè)事件消息給TS，報(bào)告這些情況。

這套消息交換機(jī)制為T(mén)C8測(cè)試提供了一個(gè)可靠、高效且靈活的通信基礎(chǔ)，使TS既能精確控制被測(cè)實(shí)現(xiàn)，又能實(shí)時(shí)感知其內(nèi)部狀態(tài)的變化，從而完成全面的協(xié)議一致性驗(yàn)證。

（三）服務(wù)組與服務(wù)原語(yǔ)

服務(wù)組是對(duì)SP進(jìn)行邏輯分組的容器，可以這樣理解：

●SP：具體的"動(dòng)作"或"命令"，例如"發(fā)送數(shù)據(jù)"、"建立連接"。

●服務(wù)組：這些動(dòng)作所屬的"功能域"或"協(xié)議層"，例如所有TCP相關(guān)的動(dòng)作都?xì)w入TCP組。

SP是TS能夠發(fā)給UT的具體命令，每一個(gè)PID都對(duì)應(yīng)一個(gè)明確的操作，同一個(gè)PID可以在不同的服務(wù)組中被定義，但其參數(shù)和行為完全不同。例如：SEND_DATA (PID=0x02) 在UDP組和TCP組中都會(huì)用到，但由于底層協(xié)議不同，其所需的參數(shù)和內(nèi)部實(shí)現(xiàn)邏輯是不同的。

為了方便理解，本文以TCP/UDP協(xié)議一致性測(cè)試使用到的SP進(jìn)行介紹。下表列出了常用的套接字通信相關(guān)的SP，這些SP模擬了應(yīng)用程序使用網(wǎng)絡(luò)套接字的行為，是測(cè)試傳輸層協(xié)議的主力。(m= mandatory, o = optional, e = extension)

TC8測(cè)試實(shí)踐與應(yīng)用

在TC8中，針對(duì)TCP/IP協(xié)議的測(cè)試用例多達(dá)數(shù)百條，覆蓋了連接建立、數(shù)據(jù)傳輸、狀態(tài)轉(zhuǎn)換、錯(cuò)誤處理等各個(gè)關(guān)鍵環(huán)節(jié)。實(shí)際上，執(zhí)行完整的TC8測(cè)試并非易事：它不僅要求測(cè)試人員深入理解TCP/IP協(xié)議細(xì)節(jié)，還需搭建穩(wěn)定的測(cè)試環(huán)境、編寫(xiě)適配腳本、分析大量日志與抓包數(shù)據(jù)，整個(gè)過(guò)程耗時(shí)耗力且容易遺漏。因此，對(duì)于大多數(shù)企業(yè)而言，直接借助專業(yè)的測(cè)試團(tuán)隊(duì)或成熟的測(cè)試服務(wù)，才是高效、可靠達(dá)成協(xié)議一致性認(rèn)證的明智選擇。接下來(lái)，我們將通過(guò)一個(gè)具體的TCP協(xié)議測(cè)試實(shí)例，為大家逐步解析TC8測(cè)試的執(zhí)行流程與關(guān)注要點(diǎn)。

測(cè)試實(shí)踐：TC8-TCP協(xié)議測(cè)試

TC8測(cè)試用例編號(hào)：TCP_CALL_RECEIVE_05

測(cè)試目的：驗(yàn)證 TCP協(xié)議在CLOSE-WAIT狀態(tài)下收到RECEIVE調(diào)用時(shí)，是否能正確將隊(duì)列中的數(shù)據(jù)返回給應(yīng)用層

測(cè)試步驟：

測(cè)試方法：目前北匯信息具備成熟的TC8自動(dòng)化測(cè)試工程，測(cè)試前需將UT集成在DUT內(nèi)部。使用VN56XX系列設(shè)備搭建好基礎(chǔ)測(cè)試環(huán)境后，將OEM或零部件供應(yīng)商提供的輸入物信息導(dǎo)入測(cè)試工程后即可開(kāi)始自動(dòng)化測(cè)試，測(cè)試過(guò)程CANoe軟件界面如下圖所示。

測(cè)試完成，將工程自動(dòng)保存的log文件加載到Wireshark中，顯示內(nèi)容如下：

TS-IP地址：192.168.1.101 、DUT-IP地址為192.168.1.1、 LT-IP地址為192.168.1.121

在Step2，Tester發(fā)送FIN置位的數(shù)據(jù)段之前，需要確保協(xié)議棧能正常接收該數(shù)據(jù)段，并將數(shù)據(jù)段轉(zhuǎn)發(fā)到上層UT。如圖(幀35及36)，TS 發(fā)送指令給UT發(fā)起RECEIVE_AND_FORWARD調(diào)用，UT立即響應(yīng) E_OK，表示IUT已準(zhǔn)備好接收數(shù)據(jù)。UT收到IUT上傳的數(shù)據(jù)后，會(huì)向 TS 發(fā)送一個(gè) 事件并攜帶接收到的數(shù)據(jù)（幀47）。此事件的發(fā)生，證明了IUT完全符合RFC 793的要求，在CLOSE-WAIT狀態(tài)下成功將排隊(duì)數(shù)據(jù)返回給了“應(yīng)用程序”。

測(cè)試完成生成的測(cè)試報(bào)告效果如下，可以針對(duì)特定的FAIL項(xiàng)進(jìn)行分析。

總結(jié)

UT 是深入?yún)f(xié)議棧底層的“調(diào)試器”，可實(shí)時(shí)追蹤與驗(yàn)證內(nèi)部邏輯；SP 則是驅(qū)動(dòng)調(diào)試器工作的一套“標(biāo)準(zhǔn)化指令集”或“遠(yuǎn)程控制命令”，為UT的每一個(gè)介入操作定義了精確的格式與語(yǔ)義。二者共同構(gòu)建起從內(nèi)部狀態(tài)到外部接口的全鏈路驗(yàn)證機(jī)制，成為汽車(chē)網(wǎng)絡(luò)通信高可靠、強(qiáng)一致的核心保障。

北匯信息作為一家專注于汽車(chē)電子測(cè)試領(lǐng)域的企業(yè)，在車(chē)載以太網(wǎng)測(cè)試方面積累了豐富經(jīng)驗(yàn)。我們可提供專業(yè)的培訓(xùn)、技術(shù)咨詢及完整的測(cè)試解決方案，協(xié)助汽車(chē)制造商與零部件供應(yīng)商確保車(chē)載以太網(wǎng)系統(tǒng)的可靠性及安全性。如您需要具體的測(cè)試服務(wù)或希望了解更多信息，歡迎隨時(shí)聯(lián)系我們。

參考文獻(xiàn)：

【1】《Testability Protocol and Service Primitives》

【2】《OA_Automotive_Ethernet_ECU_TestSpecification_Layer_3-7_v3.0》

注：文中部分圖片來(lái)源于Vector

#車(chē)載以太網(wǎng)測(cè)試#AUTOSAR#上層測(cè)試器#UT#服務(wù)原語(yǔ)#SP#協(xié)議一致性#可測(cè)試性協(xié)議#通信棧驗(yàn)證#OPENAlliance#TCPIP測(cè)試#北匯信息#汽車(chē)電子測(cè)試#TestHouse#認(rèn)證服務(wù)#TC8