车载以太网通信协议栈测试：UT和SP详解

作者 | 澔然里

小编 | 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)

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项进行分析。

总结

UT 是深入协议栈底层的“调试器”，可实时追踪与验证内部逻辑；SP 则是驱动调试器工作的一套“标准化指令集”或“远程控制命令”，为UT的每一个介入操作定义了精确的格式与语义。二者共同构建起从内部状态到外部接口的全链路验证机制，成为汽车网络通信高可靠、强一致的核心保障。

北汇信息作为一家专注于汽车电子测试领域的企业，在车载以太网测试方面积累了丰富经验。我们可提供专业的培训、技术咨询及完整的测试解决方案，协助汽车制造商与零部件供应商确保车载以太网系统的可靠性及安全性。如您需要具体的测试服务或希望了解更多信息，欢迎随时联系我们。

参考文献：

【1】《Testability Protocol and Service Primitives》

【2】《OA_Automotive_Ethernet_ECU_TestSpecification_Layer_3-7_v3.0》

注：文中部分图片来源于Vector

#车载以太网测试#AUTOSAR#上层测试器#UT#服务原语#SP#协议一致性#可测试性协议#通信栈验证#OPENAlliance#TCPIP测试#北汇信息#汽车电子测试#TestHouse#认证服务#TC8