日本在线视频一区二区,91丨九色丨国产女黑色jk,强奸乱伦一区二区

作者 | 澔然里

小編 | Crystal

引言

在汽車以太網的通信測試中，面對復雜的協議棧分層與交互，一個核心挑戰在于：如何高效、直接地對ECU內部的網絡層、傳輸層等協議實現進行驗證？

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

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

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

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

UT工作原理

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

可測試性協議與服務原語規范中的兩種典型測試場景如下圖所示：

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

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

測試命令下達（CC通道）

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

●步驟3: IUT收到這個數據包后，并不將其視為普通的網絡數據，而是通過內部接口（這構成了CC通道的最后一段）將其解包并傳遞給上層的UT。

觸發IUT行為（UC通道）

●步驟4 & 5: UT收到來自TS的指令后，解析它，并據此通過UC通道調用相應的SP。例如，UT調用SEND_DATA原語，要求IUT發送一段特定的數據。

觀察IUT反應（LC通道）

●步驟6 & 7: IUT在接到UT的SP調用后，開始執行標準的協議操作。例如，它會構建一個真實的TCP數據包，然后通過LC通道發送給網絡另一端的LT。

●步驟8: LT作為網絡上的一個節點，捕獲到這個由IUT發出的TCP數據包，并將其內容完整地上報給TS。

驗證與判斷

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

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

可測試性協議與服務原語規范

（一）消息格式

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

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

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

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

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

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

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

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

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

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

Parameters：參數數據，可變長度，由LEN字段確定，包含SP所需的輸入參數或返回數據

（二）消息交換機制

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

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

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

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

下圖清晰地展現了兩種典型場景：

場景1，如上圖左所示:

1. TS發送請求，命令UT執行一個簡單原語（例如，讀取某個內部狀態）。

2. UT立即執行該操作，并發送響應，告知TS請求已成功執行。

3. 整個交互結束，沒有后續的事件發生。

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

場景2，如上圖右所示：

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

2. UT立即返回響應，表示“命令已收到，正在執行”。

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

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

（三）服務組與服務原語

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

●SP：具體的"動作"或"命令"，例如"發送數據"、"建立連接"。

●服務組：這些動作所屬的"功能域"或"協議層"，例如所有TCP相關的動作都歸入TCP組。

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

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

SP Name	PID	TCP	UDP	描述
CLOSE_SOCKET	0x00	m	m	關閉一個已打開的套接字。
CREATE_AND_BIND	0x01	m	m	創建并綁定一個套接字到指定的地址和端口，這是進行網絡通信的第一步。
SEND_DATA	0x02	m	m	發送數據。命令IUT從已建立的套接字發送數據。TCP和UDP的參數會不同（如TCP可能需要處理連接狀態）。
RECEIVE_AND_FORWARD	0x03	m	m	接收并轉發數據。命令IUT準備接收數據，并將收到的數據內容通過事件上報給TS。
LISTEN_AND_ACCEPT	0x04	m		監聽并接受連接。TCP特有，用于服務器端行為，等待并接受傳入的TCP連接。
CONNECT	0x05	m		建立連接。TCP特有，用于客戶端行為，主動向服務器發起TCP連接。
CONFIGURE_SOCKET	0x06	m	m	配置套接字參數，如設置超時、緩沖區大小、套接字選項等。
SHUTDOWN	0x07	e	e	關閉連接。TCP擴展，用于優雅地關閉TCP連接（可以只關閉發送或接收通道）。

TC8測試實踐與應用

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

測試實踐：TC8-TCP協議測試

TC8測試用例編號：TCP_CALL_RECEIVE_05

測試目的：驗證 TCP協議在CLOSE-WAIT狀態下收到RECEIVE調用時，是否能正確將隊列中的數據返回給應用層

測試步驟：

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

測試完成，將工程自動保存的log文件加載到Wireshark中，顯示內容如下：

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

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

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