作者 | 澔然里

小編 | Crystal

引言

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

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

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

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

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

UT工作原理

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

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

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

測試過程主要有以下幾個步驟：

測試命令下達（CC通道）

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

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

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

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

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

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

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

驗證與判斷

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

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

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

（一）消息格式

TS與UT之間測試消息的格式借鑒了汽車領(lǐng)域廣泛使用的SOME/IP標準，但進行了簡化和定制，如下圖所示：

Service ID：長度為16bits，服務(wù)標識符。固定用于標識這是一個“可測試性服務(wù)”消息。默認值為 0x0105，但可配置

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

Group ID（GID）：長度為7bits，服務(wù)組標識符對SP進行邏輯分組(如：TCP組、UDP組、IPv4組)

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

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

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

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

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

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

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

（二）消息交換機制

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

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

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

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

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

場景1，如上圖左所示:

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

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

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

適合：GET_VERSION、STATIC_ADDRESS、INTERFACE_UP 等一次性動作

場景2，如上圖右所示：

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

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

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

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

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

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

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

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

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

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

TC8測試實踐與應(yīng)用

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

測試實踐：TC8-TCP協(xié)議測試

TC8測試用例編號：TCP_CALL_RECEIVE_05

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

測試步驟：

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

測試完成，將工程自動保存的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已準備好接收數(shù)據(jù)。UT收到IUT上傳的數(shù)據(jù)后，會向 TS 發(fā)送一個 事件并攜帶接收到的數(shù)據(jù)（幀47）。此事件的發(fā)生，證明了IUT完全符合RFC 793的要求，在CLOSE-WAIT狀態(tài)下成功將排隊數(shù)據(jù)返回給了“應(yīng)用程序”。

測試完成生成的測試報告效果如下，可以針對特定的FAIL項進行分析。

總結(jié)

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

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

參考文獻：

【1】《Testability Protocol and Service Primitives》

【2】《OA_Automotive_Ethernet_ECU_TestSpecification_Layer_3-7_v3.0》

注：文中部分圖片來源于Vector

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