标签: TC8

背景 由OPEN联盟制定的《TC8 ECU and Network Test》标准，旨在验证产品是否符合RFC、IEEE以及AUTOSAR中定义的需求，该规范被OEM和Tier1广泛地作为车载以太网控制器产品的基础通信协议测试的参考测试标准。 执行并通过所有相关测试用例，能够使被测设备（DUT）获得最基础的认证，即该设备已满足车载以太网通信的基本要求。 为保证源自RFC等相关需求及相应测试项更适应于车载应用，保证测试规范（如判断标准、测试步骤）合理正确，TC8也在不断更新完善。作为OPEN Alliance SIG Adopter，北汇一直积极推动TC8在中国的测试应用。 本文以TC8新版本与2.0版本在 ARP、IPv4、ICMPv4、UDP、TCP和SOME/IP 这5个测试组中的变化对比为切入点，带您“抢鲜”解读新版本测试规范，分 析其变更背后的原因，通过追根溯源，强化对以太网通信需求及车载应用场景的深入理解，为大家提供参考，以达知其所以然的目标。 TC8新版本与2.0版本对比分析 整体对比 新版在测试用例数量上有较大幅度的删减，下表给出各测试用例组的具体测试用例数（包含子用例）对比，以下章节将对各测试包逐一进行介绍，并对新老版本间的变化做简要分析。（数据仅供参考，具体以实际发布为准。） ARP测试内容变化说明 ARP测试组中主要对ARP报文的请求，响应格式，ARP entry学习，ARP entry的更新以及ARP的timeout时间进行测试。 新版沿用历史版本中所有的ARP测试用例，并未进行修改，但增加了测试用例中所涉及的参数和常数的定义。 IPv4测试内容变化说明 IPv4测试组包括IPv4的报头，IPv4 Checksum，IPv4 TTL，IPv4 版本号字段，DUT所接收IPv4数据包的目的地址字段，IPv4的分片，IPv4重组的验证。新版主要做了以下修订： （1） 删除IP Options相关的测试用例。 RFC中定义的大多数标准的IP Options如今已经很少或从未被使用过，大多数常见协议栈对IP Options的支持也不尽相同，对于常规车载以太网通信来说，Options字段不是必要的。当然如果DUT使用了IP Options字段，对于IP Options字段的测试仍可参考2.0版本。 （2） 删除2.0版本中存在测试点重复的用例 。 例如IPv4_CHECKSUM_04与IPv4_CHECKSUM_05测试点存在重复。 （3） 增加了测试用例中涉及的参数和常数的定义。 ICMPv4测试内容变化说明 ICMPv4测试组的主要测试内容如下： （1） 验证DUT的错误处理机制 。 验证当DUT接收到某些特定报文内容，不会出现错误报文。 （2） 验证DUT是否支持不同类型的ICMPv4报文。 如：ICMP端口不可达（MAY）、ICMP echo响应报文等。 这部分测试用例新版中并未增减，仅增加了测试用例中使用参数和变量的描述。 UDP测试内容变化说明 （1） 删除IP Options相关的测试用例 。 具体原因见前文描述。 （2） 由于许多协议栈并不支持通过应用程序动态设置发送的UDP数据包的TOS和TTL，且车载以太网中TTL和TOS的值通常是静态配置的，动态设置这两个字段不符合实际的应用场景，可能出于这样的考虑，新版中移除了与之相关的测试组。 （3） 对于UDP应用来说，获取ICMP错误信息和TTL不是必须的功能，并且许多协议栈并不支持。因此新版中删除了与之相关的测试用例，如果对这两部分有测试需求，仍可参考2.0版本。 TCP测试内容变化说明 对于TCP测试组，新版测试用例总数相对于2.0版本减少了118条，由于被测试用例数较多，本文只针对部分典型删除用例做原因分析： （1）对于某些可以选择性实现的功能，其对应的测试用例不能作为强制的约束项，因此新版本删除了18条TCP测试包中需求属性为MAY的测试用例，如TCP_BASICS_15等。 （2）2.0中部分测试用例中所引用的需求未找到具体的出处或者是不确定的（即由参考文档不能得出相应的结论），在新版中对应的测试项被删除，如TCP_BASICS_16等。 （ 3 ）2.0中的TCP测试组存在测试用例的测试点与其它测试用例重复的情况，因此在新版中删除了这些重复的用例，如TCP_CLOSING_01等。 （ 4 ）考虑到安全因素，RFC793中定义的某些机制已不再被目前大多数的协议栈所支持，新版中删除了与之相关的测试用例。 （ 5 ）目前车内较少存在三层路由，即使有路由器存在，其转发路径是固定的，也就是路径上的MTU是已知的，不需要通过路径发现的方式去估算路径MTU，这可能是删除Host Specification and MSS等用例的原因。 （ 6 ）RFC原始需求中定义，当应用程序调用TCP SEND/OPEN等时，协议栈能够返回具体错误的状态至应用程序。随着技术发展，协议栈根据实际用户的需求进行优化，和原需求会产生差异，此特性目前大多数协议栈都不支持。因此，与之相关的测试用例被移除。 SOME/IP测试内容变化说明 对于SOME/IP测试组，新版测试用例总数相对于TC8 2.0减少了19条。如下针对部分被删除的测试用例进行了分析： （ 1 ） 删除与其它测试用例重复的测试用例。 如SOMEIPSRV_SETUP_01等。 （2） 删除11条非通用性的需求所对应的测试用例 。 SOMEIPSRV_ONWIRE_08等。 （ 3 ）实际应用中，在特定条件下， SubscribeEventgroupAck 有可能不带Options。此外，Index 1st Options 可不为 0，所以新版删除了与之相悖的和不合理的测试用例。 小结 通过上述分析可看出，新版修订了不少测试规范本身存在的问题，删除重复的测试用例、测试逻辑错误的测试用例以及可选择性实现的特性所对应的测试用例。最重要的是移除了很多并不适用于车载以太网通信场景的测试用例，这也让我们看到了车载以太网的基础协议测试的进化，更为“适合”和更具针对性。 尽信书则不如无书，需时刻保持独立思考。上述测试规范中的部分问题，北汇在过去两年的测试实施过程中，已经有所积累并针对性地进行了调整。篇幅所限，关于“规范比对”的更多内容和技术细节，敬请持续关注，北汇将尽力为您的车载以太网产品提供专业的测试验证服务和技术咨询！另，如有谬误之处，敬请指正！

什么是A TS ATS（Acceptance Test Specification）是由AUTOSAR释放的针对AUTOSAR不同软件组件的标准测试规范。根据软件类型的不同，ATS分为了应用测试（Application level）和总线测试（Bus level）： 应用测试 包括了例如RTE，BSW服务等组件的测试 总线测试 包括了CAN，LIN，FlexRay，Ethernet等总线的测试，也包括了更高层级协议的测试，比如网络管理，诊断通信等协议的测试 为什么需要A TS 我们知道AUTOSAR的通信协议栈（Communication Stack）是高度可配置的。对于同一协议栈，不同的用户会根据其具体项目中的应用需求来进行针对性的配置。 站在测试的角度，如果我们对这些不同配置的软件都进行单独的测试，这无疑存在很多重复性的工作，因为软件模块的基础都是相同的，只是因为配置的不同才产生了多种不同的变体。 于是我们把这些基础的和共性的需求梳理出来，并开发测试规范进行覆盖，这样在不同的项目中就不必再重复的执行这些测试了，而这些测试就是ATS定义的内容。 这样做的益处是显而易见的。 站在OEM的角度，他们不需要自己去开发和维护这些测试规范，甚至都不需要执行这些测试，只需审核供应商提交的报告 站在供应商的角度，针对同一软件组件的“标准接受性”测试只需要执行一次（针对同一硬件平台和编译环境） 站在测试服务商的角度，测试脚本只需开发一次，来自不同供应商的软件可以复用同一测试脚本主体。 所以不管站在谁的角度，这都极大的降低了测试的成本和工作量。 ATS 在整个测试活动中的位置与作用 图1： AUTOSAR 软件组件 完整 测试 活动 示意 一般来说，AUTOSAR软件组件一般经过如下几个阶段的测试： Unit Tests 单元级别的白盒测试。 Standard Acceptance Tests ATS定义的测试内容，可由第三方的测试服务商（Test House）完成，OEM可要求供应商来提交ATS的测试报告，作为“准入条件”。该要求由OEM制定，AUTOSAR并没有强制要求。 OEM Specific Qualification Tests 由OEM根据自己的企业标准或需求定制的测试，作为“认证”测试。只有经过“认证”的软件才可以在具体的项目中使用。和ATS类似，这个阶段也不包含配置相关的验证，所以测试方法可以参考ATS，也可在ATS的基础上进行扩展。 Project Specific Tests 与具体项目有关的配置测试。 因为ATS只覆盖了非常基础的和共性的需求，项目相关的或配置相关的需求都不在范围之内，覆盖度是非常有限的，所以ATS只能作为初步的验收测试，不能取代其他测试。就这一点来说，TC8也是类似的。 A TS 中 针对车载 以太网 的 相关 测试 ATS中涵盖了TCP/IP的IPv4，UDP，TCP三个部分，分别定义在AUTOSAR_ATS_IPv4, AUTOSAR_ATS_UDP，AUTOSAR_ATS_TCP三份规范中。 相信不少人有这样的疑问：为什么ATS中没有ARP，ICMP，DHCP等等这些内容？ 经过上面几个部分的介绍，答案应该显而易见，那就是ATS中只覆盖基础的和共性的需求，而ARP，ICMP，DHCP等部分目前不属于这个范围，如果OEM有相关的需求，需要自行开发测试规范。 关于更多AUTOSAR架构下的TCP/IP特点分析，以及AUTOSAR架构下TCP/IP是如何优化配置使其更加适用于车内网络的话题，请持续关注北汇信息公众号后续的分享。 ATS规范体系中有一篇要特别介绍一下，那就是 AUTOSAR_PRS_TestabilityProtocolAndServicePrimitives 。 这篇文档中定义了一种测试桩（Test Stub）协议，用来支持车载以太网的测试，也就是我们常说的Upper Tester。我们在做TC8 TCP/IP测试时用到的Upper Tester，一般也是按照这份规范去开发的。更多关于Upper Tester的内容，可参考之前的文章 车载以太网-TC8 TCP/IP协议一致性测试实践-面包板社区 (eet-china.com) 中的介绍。 ATS与T C8 因为ATS本身属于AUTOSAR体系，所以ATS一般只适用于AUTOSAR节点。而TC8并没有对测试对象做要求，不论是AUTOSAR节点还是非AUTOSAR节点，都可以依照TC8进行测试。 但是有一点需要注意，有些商用AUTOSAR协议栈自带的Upper Tester（也称ETM）一般只能满足ATS中定义的测试，也就是只包含IPv4，UDP，TCP三个部分，如果需要完整的执行TC8的ARP，ICMP，DHCP等测试，需要进行额外的开发。 在TCP/IP的测试环境和测试方法方面，ATS与TC8并无本质的区别，可参考之前的文章 车载以太网-TC8 TCP/IP协议一致性测试实践-面包板社区 (eet-china.com) 进行了解。 在覆盖度方面，二者即有交集又有区别，我们做了一个简单的对比统计可供参考。 图2： AUTOSAR ATS 与 O PEN T C8 的 覆盖度 对比 大家可能有这样的疑问，针对ATS与TC8重叠的部分，所对应的测试脚本是否可以复用呢？答案是否定的，因为测试用例虽覆盖了相同的需求，但测试用例的设计方法不尽相同，所以测试脚本是不能完全复用的。 A TS 测试实践 下图展示了 A UTOSAR ATS TCP 部分 的 测试报告。 图3： A UTOSAR ATS TCP 的 测试报告 示意 可以看到TCP部分共有44条测试用例，其中有如下2条失败的条目。 IUT sends an ACK after receiving a data segment in FIN-WAIT-1 state IUT sends an ACK after receiving a data segment in FIN-WAIT-2 state 我们来分析一下失败的原因。 这两条测试用例分别验证了DUT作为TCP客户端时在FIN-WAIT-1和FIN-WAIT-2状态下接收数据的能力。 当客户端准备关闭连接时，会立即发送FIN，ACK来通知服务端，之后立即进入FIN-WAIT-1状态，当服务端应答之后，客户端会进入FIN-WAIT-2状态。 理论上，当TCP客户端发送FIN，ACK之后，就意味着客户端已经没有数据要发送了，但是此时还应具备接收数据的能力，也就是连接处于“半双工”（half-duplex）的状态，若此时收到服务端发送的数据，客户端应能够正确应答。 但是实际上被测设备并没有应答，而是发送了RST以通知服务端数据发生了丢失，这就导致了测试不通过。 关于连接半关的需求，最初源于RFC793，但是在RFC1122中重新进行了讨论，因为很多协议栈都由于操作系统的限制，不支持这个机制，在这些操作系统中，如果应用发起TCP关闭请求（比如调用close()）之后，就不再具备发送或者接收数据的能力。 而我们可以在AUTOSAR_SWS_TcpIp的 这条需求中看到，AUTOSAR中其实并没有要求节点实现连接半关，这是测试用例的属性标记为“MAY“的原因。 图 4 ： AUTOSAR_SWS_TcpIp 节选 如果协议栈不支持这个机制，就意味着在客户端发起连接关闭请求之后，如果服务端继续发送数据，这部分数据会被客户端丢掉，这在设计业务流程时要格外注意。 参考文档： AUTOSAR_EXP_AcceptanceTestsOverview.pdf AUTOSAR_ATS_IPv4.pdf AUTOSAR_ATS_UDP.pdf AUTOSAR_ATS_TCP.pdf AUTOSAR_SWS_TcpIp.pdf

背景 信号质量指数（ SQI）被用于表征以太网通信链路质量。因此，可以通过读取到的SQI值判断控制器当前通信链路质量。 另外，在控制器通讯过程中， PHY芯片会实时监控SQI值，当监测到的SQI值低于阈值时，PHY芯片将会断开通信链路，以保证通信的可靠性。 SQI值作为评判以太网通信链路质量的依据，其值的正确性直接影响到PHY芯片之间通信链接的“行为”，因此SQI值的测试非常必要和重要。 测试方案对比 在 TC8 1.0中，使用Technica-Golden Device，在BR+/BR-之间注入电阻噪声的方式进行测试 。 在 TC8 2.0中，采用Rohde & Schwarz信号发生器仿真高斯噪声，通过定向耦合器将高斯噪声耦合到以太网通信线束上的方式进行测试，此时Link Partner将不会受到噪声的干扰，只关注DUT本身的SQI、Link Status与噪 声等级之间的关系，Link Partner的作用被弱化 。 测试原理 说明 TC8 1.0的噪声注入原理图如下所示，通过改变Technica-Golden Device并联在BR+/BR-之间电阻的阻值，以达到改变噪声注入等级的目的。 图 1 TC8 1.0 IOP SQI测试原理框图 （图片来源： OPEN Alliance Automotive Ethernet ECU Test Specification_TC8 V1.0） TC8 2.0的噪声注入原理图如下所示，Rohde & Schwarz信号发生器仿真的高斯噪声，通过定向耦合器耦合到通信链路上。通过改变仿真的高斯噪声幅值，来改变耦合到通信链路上的噪声等级。 图2 T C8 2.0 IOP SQI 测试原理框图 测试 实现说明 T C8 1.0 IOP SQI测试 基于 Vector公司的CANoe CAPL，北汇信息自主定制开发了TC8 1.0 IOP的自动化测试工程，控制Technica-Golden Device注入电阻噪声，获得DUT SQI与Link状态，自动生成测试报告。 图3 T C8 1.0 IOP SQI 测试环境 T C8 2.0 IOP SQI测试 基于 Vector公司的CANoe CAPL，北汇信息自主定制开发了TC8 2.0 IOP自动化测试工程。 测试步骤： 将 Technica- Golden Device作为Link Partner，设置与DUT相对的Master/Slave模式 Rohde & Schwarz 信号发生器初始化并设置高斯噪声带宽 设置 Rohde & Schwarz 信号发生器高斯噪声幅值 读取DUT SQI/Link状态，次数为100次 重复步骤c、d（设置高斯噪声幅值递增/递减） 自动生成测试报告 图 4 TC8 2.0 IOP SQI 测试环境 为保证测试效率，开发专用的自动化测试脚本，实现： 支持通过RS232、CAN/LIN、ADB通信接口，实现对被测对象的PHY寄存器读写 实现对 Rohde & Schwarz 信号发生器程控，实现如下功能： 仿真信号类型选择 高斯噪声文件加载、带宽设置、幅值设置 信号发生器通道阻抗设置和通道使能 测试总结 方案对比 图 5 T C8 1.0/2.0 IOP SQI测试 对比图 测试结果对比 图6 TC8 1.0 IOP SQI测试结果 图 7 TC8 2.0 IOP SQI测试结果 分析 影响SQI值的因素主要为外部环境的辐射和控制器通信链路的物理特征，如线束材质、长度、绞距以及接入连接器的特性，所引起通信链路阻抗匹配以及突变情况，从而导致传输信号衰减和反射，其中信号反射又对原信号产生“叠加噪声”。 由此可见，通信链路的阻抗变化为“本因”，噪声为“现象”，本方案通过“本因”和“现象”两种测试方法对比SQI测试结果。 根据两种测试方法的测试结果，被测控制器出现SQI值不稳定的位置相同，测试结果无太大差异。 小结 TC8 1.0与TC8 2.0中注入噪声的类型本质都是高斯噪声，通过上述的实践对比，两种方案均满足IOP SQI的测试要求。 北汇信息可提供基于 Vector公司的CANoe、Technica的Golden Device、Rohde & Schwarz的信号发生器及定向耦合器组合的100BASE-T1 IOP测试解决方案，同时满足TC8 1.0和TC8 2.0的IOP测试要求，提供测试验证服务。 感谢 Vector、Rohde & Schwarz、Technica对本测试方案给予的专业支持。 基于现有的 Vector-VN5640、Te chnica-Golden Device等设备，北汇信息已实现了1000BASE-T1 IOP测试的过渡方案，敬请关注后续分享。 参考文献 【 1 】 OPEN Alliance Automotive Ethernet ECU Test Specification_TC8 V1.0 【 2 】 OPEN Alliance Automotive Ethernet ECU Test Specification_TC8 V2.0 【 3 】 Datasheet ： TJA1100 — 100BASE-T1 PHY for Automotive Ethernet.pdf 【 4 】 OA_100BASE-T1_Interoperability_Test_Suite_V1.0 【 5 】 1000BASE-T1_罗德与施瓦茨 汽车以太网一致性测试.pdf 【 6 】 Golden Device Manual.pdf

概述 在车载以太网标准化的进程中，O PEN 联盟起到了重要的推动作用。汽车行业中很多O EM ，供应商，以及芯片制造商都加入了联盟， 旨在 确保车载以太网的兼容性和互操作性。 其中T C8 是针对E CU 级别的车载以太网一致性测试规范。 Vec tor 在今年第二季度推出了CAN oe 的1 2.0 版本， 其中 最引人注目的新特性之一便是对 TC8 的支持。 Vector将其作为一个示例工程 （Sample Configuration） 提供给了用户， 本文将向大家详细介绍此工程的使用 方法 。 下图展示了执行T C8 测试所涉及到的工具链。 图1：使用v TESTstudio 和C AN oe执行T C8 测试 v TESTstudio v TESTstudio 是Vector推出的一款测试设计工具， 在Vector提供的T C8 示例工程中，所有的 测试脚本都由v TESTstudio 进行开发和管理。用户可以在此修改或者添加测试脚本，但一般是不需要的。脚本编译过后，将生成的文件导入CANoe中进行测试执行。 在执行T C8 测试之前，有很多测试参数需要配置。 根据测试内容的不同（比如A RP ，I CMP v 4 ，I Pv4 等等）， v TESTstudio 工程中也划分了不同的测试单元（Test Unit） ， 每一个测试单元都需要独立进行配置 。测试参数分为两种，第一种 是通用参数， 比如I P 地址，M AC 地址等等， 在 "GeneralTestParameters.vparam" 这个文件中定义， 这些参数只需设置一次，不同测试单元都引用此文件中的参数 ；第二种是特有参数，每个测试单元都有独立的参数文件，比如 “ ArpParameters.vparam ” ，这个文件定义了A RP 测试时需要的特殊参数 。 图2：测试脚本 图 3 ：通用参数 图 4 ：特殊参数 在通用参数中 ， 有一类参数需要特别介绍一下—— 测试桩（Upper Tester） 参数 ，位于 “ Testability Parameters ” 这个分组中 。 测试桩是集成在被测对象中的一个应用程序，用来接收测试系统的指令，来使被测对象进入某种状态或发送某些指定的数据。 测试桩参数是用来配置测试桩行为的一组参数。 目前测试脚本中的测试桩指令基于“ AUTOSAR testability protocol ” ——一个由AUTOSAR定义的测试桩协议。在执行测试之前，用户需要确认被测设备中已经集成了测试桩，并且支持此协议。 需要注意的是，目前版本的“ AUTOSAR testability protocol” 中定义的功能是不足以支持TC8所有测试的，比如ARP的部分测试，此示例工程中的实现仅仅是一种“示例”，理论上这部分测试桩的功能需要用户自行定义，并在 vTESTstudio中修改或添加脚本。 CAN oe CAN oe 提供了TC8测试的执行环境，如果用户仅仅需要执行测试，而不需要修改脚本，那么上面提到的v TESTstudio 是不需要的。执行T C8 测试所需的软件最低版本为1 2.0 ，并且带有E thernet option 。 图5：CANoe中的执行环境 至于硬件接口设备，理论上可以使用任何支持I EEE 100BASE-T1 的V ector 以太网接口硬件，但是不同的硬件提供了不同的功能，比如V T6306 ，由于支持一些以太网 线缆 故障的仿真，故可以支持部分物理层测试的自动化执行，这是V N56XX 系列硬件所不具备的 。 除此之外，部分被测设备可能需要特殊的唤醒方式，比如C AN 唤醒，这时便需要支持C AN 通道的接口设备。 测试用例执行完成之后，CAN oe 可生成H TML 格式的测试报告，测试报告中展示了测试结果统计，以及每个测试用例、每个测试步骤详细的执行内容和结果。 图 6 ： 测试报告中的 测试结果统计 图 7 ： 测试报告中的 详细测试执行情况 示例工程中还提供了一个仿真节点，此节点实现了完整的测试桩功能，用户可将工程的执行环境设置为“Simulated”，便可以 将 这个 仿真节点作为被测节点，作为展示和学习使用。 至于覆盖度方面，截至CAN oe 12.0 SP3 版本，T C8 各类测试的覆盖情况如下表所 示， 可以看到其中某些测试目前还不支持，相信在后续的小版本更新中会逐渐补充上来。 图 8 ： T C8 覆盖情况统计 总结 CANoe具备仿真，分析，诊断，测试功能于一身，同时对传统总线技术的支持，以及丰富的I/O板卡资源，能够非常大的提高TC8测试的效率和自动化程度；同时采用了vTESTstudio进行测试用例的开发和管理，使易用性得以提升，用户花费较少的学习成本即可熟练使用。 作为汽车行业的标杆产品， CANoe在车载总线测试领域深耕多年，获得了行业内广大用户的认可。随着车载以太网的发展和应用，CANoe也不断扩展其功能来应对新的需求和挑战，支持CAN、CAN FD、LIN、FlexRay、MOST和车载以太网等总线技术的仿真和测试。此次对TC8的支持是一次非常重要的更新，对于汽车行业的用户来说，可以从CANoe的仿真和测试功能上获得更多的支持，将大力推动车载以太网的普及。

前言 车载以太网测试 实践系列， 我们 还会分享 PMA测试 实践 、 IOP测试 实践，敬请期待 。本期给大家介绍的是TC8中的TCP/IP协议一致性测试（以下简称TCP/IP测试）。 TCP/IP 测试-设备环境组成 TTworkbench TTworkbench是 思博伦 旗下一款功能强大的 测试自动化平台 ，它能够提供 完整特性的集成式测试开发和执行环境（IDE）， 可进行测试脚本开发、编译，测试参数配置，测试执行，测试监控，生成测试报告。 图 1 TTworkbench平台示意 TT suite 思博伦 提供了 多种 现成可用的货架式测试 套装（TT suite ），包括 OPEN Alliance SIG一致性测试 （T C8 ） ， 汽车AVB一致性测试 ， AUTOSAR一致性测试 等 套装 ， 每个测试套装都包含多种经过验证的测试 用 例 ，配合TTworkbench， 能够实现车载以太网常见协议 的 一致性测试 的自动化执行 。 C 50 C50 是思博伦推出的一款性能强大 的硬件 ，具有 第2至3层流量生成和分析能力 ，可搭配不同的网卡（1 00BASE-T1 、 100BASE-TX 等）来满足不同 用户 的需求 。通过网线连接至 PC 后 ，可实现 TT suite的远程执行，即测试脚本运行在 C50 中，P C 监控测试过程，收集测试数据，生成测试报告 等 。 图 2 C50实物图 Upper Tester （U T ） Upper Teste r（U T ）本质上是一个运行在 DUT 中的应用，用于辅助测试执行。它能够接收T est System发送的指令，来配置被测协议栈 （I UT ） 的参数，或触发被测协议栈产生某种行为。U T 支持的指令和格式遵循A UTOSAR 体系下的《 Testability Protocol and Service Primitives 》规范，目前新版的T Tsuite 已经支持到了 1.2.0 版本。 O EM 或供应商可按照规范自行开发和集成U T ， 也可购买第三方源代码自行集成， 或 通过第三方服务商来进行开发或集成。目前，北汇信息 可 提供U T 的 集成 服务。 图 3 Upper Tester（UT）工作原理 TCP/IP 测试-被测对象组成 D UT 被测设备为实现了T CP/IP 协议栈的非A UTOSAR 控制器。 调试接口 为了更好 地 监视测试过程，D UT 最好能提供一个调试 接口 ， 这样 U T 可通过这个接口输出一些调试信息，以帮助测试工程师更好 地 判定问题。 这个接口可以是串口 、 S SH 、 或T ELNET 等，具体的类型并不限定。 需要注意的一点是 ，《 Testability Protocol and Service Primitives 》目前不支持T C8 中的A RP 测试 ，这时候就必须依赖上面提到的调试接口才能进行测试， 并需要支持清除 ARP动态缓存等配置和功能（详情可面对面沟通） 。 若提供的是S SH 调试接口，可配合 TT suite实现A RP 自动化测试，若是其他接口类型，则只能进行半自动化测试。 TCP/IP 测试-测试过程 测试准备 连接Test System与D UT 加载对应的T T suite 配置TTsuite参数，如I P 地址 ，M AC 地址等 启动U T 图 4 配置测试参数 执行测试 运行测试脚本 图 5 测试脚本运行示意图 获得测试数据和测试报告 图 6 测试报告示意图 TCP/IP 测试- 小结 我们经常会听到这样的问题，TCP/IP协议栈已经发展了近30年，想必是十分成熟可靠了，那么为什么还要投入精力去测试呢？ 这个问题回答起来很简单，只需要举一个例子即可。 很多车载信息娱乐域的控制器采用了Linux系统，因为它成熟可靠，性能强大，应用资源丰富，且开源免费。但是对于Linux的TCP/IP协议栈，大多参数都采用缺省的配置，这就使有些特性可能不满足车载的应用要求。比如，在缺省情况下，任意目的IP地址的ARP数据包都会被Linux接收，而TC8 要求 DUT 应忽略掉非指向自己的数据包，以提高安全性。 这些细节也是做正向架构设计和参数配置需要约束的，是测试带来的价值之一，尤其是在当前摸石头过河的阶段。深入的测试完全可以“反哺”设计，当然这需要对应用场景和协议本身（缺一不可）有足够的认知。 所以我们想表达的是，TCP/IP更多的是为互联网设计的，它的很多机制只有在海量用户和数据，并且在非常复杂且未知的网络环境下才会起作用，否则可能起到相反的效果。 我们必须意识到，车内的局域网是相对静态的、封闭的、简单的，我们必须做一些针对性的优化，才能达到更好的网络性能和更高的安全性。而TC8的意义，可能就在于此。 图片来源：www.eenewsautomotive.com