汽车以太网技术是基于传统的以太网技术发展出来的一种针对汽车领域应用的通信技术。最早由博通和宝马公司共同研制出其关键的底层技术，从2011年左右开始推广，随后在各公司、各组织的共同配合下得到大力发展，在汽车领域通信技术中占据重要地位。该技术涉及ISO OSI模型的1~7层，各层有其相应的实现手段。下文将按照ISO OSI的七层模型从下到上，对各种测试内容进行简单的介绍，阐述一下汽车以太网中每项测试的基本内容、测试意义及大致的开展思路。

1、物理层芯片层测试

此处主要指PHY芯片或集成了PHY功能的交换机芯片等，测试其物理性能，通常由芯片厂商完成。这部分内容既有公开的芯片设计标准，也会有公开的测试标准，因为不同厂商在进行芯片实现时，都需要按照同样标准来做，最终才能顺利通信。对应的设计标准在IEEE中，测试标准在IEEE和OPEN中。

芯片物理层测试内容与ECU节点的物理层测试内容有些相似，但芯片的测试项会更多更复杂，ECU的测试项有很多会引用芯片的测试项或测试方法。通常来讲对于Tier1和OEM，是不需要开展芯片级别测试的。

2、物理层PMA测试

此处指的是ECU节点的PMA测试。常用的百兆及千兆汽车以太网设备按照OPEN TC8的标准开展。

PMA主要测试的是ECU节点与外界通信时自身的能力如何，包括电压驱动能力、时钟精准度、信号损耗和衰减程度、抗干扰能力等方面。

物理层测试后如果有问题就需要改版升级，之后再测试。因为硬件改版不是一个需要重复很多次的事，所以一个零部件的物理层PMA测试通常也不会很多轮次。而同时因为物理层PMA测试的设备成本相比其他测试内容来讲会较高，所以综合投入产出比来看，很多OEM会有完整的物理层测试设备，因为他们需要测试很多以太网零部件；而很多规模较小Tier1通常不会采购物理层测试设备而把测试服务外包出去；而规模较大的Tier1则会有完整的设备，因为他们的以太网产品较多，需要测试的次数就会较多。

3、物理层IOP测试

此处指的是ECU节点的IOP测试。常用的百兆及千兆汽车以太网设备按照OPEN TC8的标准开展。

IOP主要测试的是ECU节点与其他节点进行交互的能力，即”互操作”能力，主要包括：两个以太网节点建立通信时间的能力、对于两者通信质量的判断能力、对两者通信链路中线缆故障的诊断能力等。

IOP测试后如果有问题，通常需要采用改进硬件、更换PHY芯片等措施来改善。IOP测试设备成本不高，但对于互联互通能力具有较好的体现，综合来讲性价比较好。因此通常来讲，IOP测试方面，一般从OEM到TIer1，都会有一套IOP测试设备。

4、通信通道测试

此处指的是以太网线束的测试。常用的百兆和千兆汽车以太网线束按照OPEN TC2及TC9的标准进行开展。基于光纤的通信在国内应用很少，所以也不做介绍。

通道测试主要检测的是通信过程中PHY之外的物理媒介性能。其实PHY芯片将1和0数据转成电信号之后，就要把电信号在线缆上进行传输。可以把电信号从PHY出来传输到另一端PHY的过程，简单理解为类似一端为一个水泵，中间是水管，另外一端读取水流信息的过程。那这个过程中在管路里，希望的是：水流很稳很快的到达另一端。这中间的管道不希望是一会粗一会细，也不希望管道材质用的不好阻力特别大，也不希望有漏水的地方，也不希望水管出现各种弯弯折折在管道里形成紊流影响水的流动。

那通信通道测试也是类似，因为PHY和线缆的设计是按照标准来的，PHY的驱动能力是标准给出的（不希望水泵功率太大会费钱，也不希望水泵功率太小会水压不足），线缆的驱动能力也是标准给出来的（水管的粗细和材质要求有标准，水管太粗浪费水，太细阻力大，只有匹配水泵的水管才是最合适的）。但是汽车线缆在实际的制造过程中，会涉及到线缆的性能选择、接插件的性能选择、线缆与接插件的焊接工艺、压接长度、绞线在接口处的展开长度等各种实际情况的影响。因而最终的线缆性能可能会有好有坏（特征阻抗、反射、散射等），周围线缆对以太网通信线缆的影响也不相同（比如与强电流变化的线缆绑在了一个线束里）等，这些都会对以太网通信造成影响，因此需要开展通信通道测试。

5、交换机性能测试

该测试一般按照RFC2544和RFC2889开展，测试的主要目的是验证交换机性能。交换机性能通常由交换机芯片和芯片的属性配置所决定。该测试内容是从传统通信领域引入的，在传统通信领域不同厂家的交换机方案会进行性能的验证与PK，因此也就有了这些测试内容。其实在汽车领域里，OEM会进行架构设计和通信带宽设计，通常不会把通信带宽设计到满负载运转（满负载往往意味着会丢帧，这是汽车领域里几乎不允许的），因此对于在接近甚至超过满负载层面的高性能测试，意义并没有那么大。或者从另一个角度来讲，当你测试完，你觉得性能指标比较低，那么基本上可用的方案也就是更换交换机芯片。但是高性能芯片价格高，价格合适的性能一般。

因此一般做对应的性能测试，主要是在ECU层面标定出Switch的性能结果，并以此反向指导应用在新产品的选型及架构、通信带宽设计。而此项测试的设备费用通常是比较高的，所以一般OEM或Tier1会通过测试服务商来开展此项测试，但若涉及到产品的不断迭代与比较，有一套设备执行测试也是很需要的。

6、数据链路层功能测试

此项测试针对二层配置，包括交换机也包括终端节点，需要按照OPEN TC8的测试标准开展。这个测试往往是必须的，在汽车以太网的应用中，为了实现更好的通信效果，需要对交换机进行各种配置，包括报文转发机制、过滤机制、不同端口的设置、地址管理等。

交换机的配置，对于当前国内汽车市场的工程师来讲还具有一定的难度。因为在传统以太网通信行业里，往往不会做特别复杂的交换机配置，而汽车行业原有的汽车电子工程师，对交换机这一套东西又不是特别熟悉。所以就出现了一种情况，传统通信行业和汽车电子行业都没有专家对这块内容非常了解。没有了足够多的人才也就不会有非常多的行业经验，也就会在这些层面出现问题。因此第二层-数据链路层的测试，往往是需要的，也是难度较大的。这些测试可以采用自动化测试系统进行，也可以手动进行。

7、TCP/IP测试

此项针对L3~L4，通常包括ARP、ICMP、IPv4、TCP、UDP这五个协议，一般遵循OPEN TC8测试。

如果采用AUTOSAR方案，则AUTOSAR中也有针对IPv4、TCP、UDP这三者的测试，与TC8有所区别，但关键测试项基本一致。TCP/IP测试是对一致性的测试，即：要保证用代码来实现的TCP/IP协议，要与标准保持一致，只有大家都与标准保持一致，才能保证不同厂家所生产出来的产品能够顺利握手通信。

这么来看，TCP/IP协议的测试，在供应商和OEM都需要进行测试。供应商进行的更多的是开发过程中的不断迭代性测试，整个产品开发过程中，供应商对以太网通信协议的实现中，要进行不断的代码开发、参数配置、不断通过测试来验证效果，并进行迭代更新，所以需要进行的是少量节点的多轮次测试。而OEM则需要进行”进门验收”测试，往往是一个ECU做一次到两次的测试，但是需要针对一款车型里所有的以太网节点，所以OEM进行的是大量节点的少轮次测试。

TCP/IP测试中会涉及到使用UpperTester，这是一个需要集成在被测件中的代码模块，可以简单理解为它就是一个潜伏在被测ECU内部的”间谍”。因为TCP/IP的有些行为，需要上一层的模块来激发或者进行监测，所以这个”间谍”就起到了类似的作用。那么OEM在给以太网节点的供应商下发设计任务的时候，别把这个事给忘了，需要让供应商在其节点内部把这个”间谍”功能实现，以支撑后续的测试。TCP/IP测试通常采用相对简单的工具就能够实现，能够给ECU供电，有接口卡能够使得测试系统（软件环境为主）与ECU进行稳定的以太网通信，测试系统中能够仿真故障，能够监测数据，基本上也就可以了。综上来看，TCP/IP测试通常是必测的，且一般都采用自动化测试。

8、SOME/IP Server及SD测试

SOME/IP测试通常按照OPEN TC8来实现，属于应用层的测试。当前阶段SOME/IP协议放到了AUTOSAR中，而测试规范放在了OPEN TC8中。这里的测试项，对SOME/IP的基本通信格式、通信行为等进行了测试。只需要在节点外部搭建基本的测试环境即可：“被测ECU、电源、接口卡、测试主机+软件”基本上就够了。这里测试的难点是对SOME/IP协议本身的理解，测试中出现的问题，很多是开发者和测试者对于协议理解不够导致的。如果你使用了SOME/IP协议，那么这些测试都建议是必须开展的。一般采用自动化测试方案。

9、SOME/IP ETS测试

ETS中文为增强测试服务，是在TC8中为了加强对SOME/IP的测试（即在前文提到的测试内容上继续加强），专门设计了一种服务，在这个服务中定义好了服务ID、方法等内容。

ETS也可以理解为跟UpperTester类似的一种”间谍”，因为SOME/IP的很多能力，必须依赖于服务本身才能实现。就相当于如果你想检验一条高速公路的运营，你就需要在路上跑上一些车。而ETS，就是跑在了SOME/IP这条高速路上的那些车。

ETS最终实现时，就是一堆代码，这些代码要集成在被测ECU中，要跟SOME/IP协议栈匹配好。跟UpperTester类似，OEM在给以太网节点的供应商下发设计任务时，也别把ETS的事给忘了，需要让供应商在其节点内部把这个ETS功能实现，以支撑后续的测试工作。这里的难点也是对SOME/IP协议本身的理解。测试中出现的问题，很多是开发者和测试者对于协议理解不够导致的。如果你使用了SOME/IP协议，那么这些测试都建议是必须开展的。一般采用自动化测试方案。

10、DoIP测试

DoIP协议是ISO13400，当前在汽车电子圈，仅有公开的设计规范，没有公开的测试规范。此项测试往往依据OEM的经验或者借助服务商的经验，形成车厂的企业标准进行。

DoIP是诊断功能基于以太网实现的中间件——上层是诊断功能，下层是以太网通信。DoIP解决的是上下衔接，对特定的诊断数据按照特定的格式进行打包和解包的事。DoIP通常都是必做的，供应商自己要对自己的代码实现效果进行验证，OEM也需要对供应商的的实现效果进行检测。DoIP的大部分测试内容（80%甚至90%以上）都可以统一下来，少量内容需要依据不同OEM的要求（因为对诊断功能的设计不同）进行定制。一般采用自动化测试方案。

11、UDS测试

UDS（统一诊断服务）是诊断的应用层实现，UDS在以太网中实现，与在CAN中的实现类似，是都需要进行测试的。因为是同样的协议内容，所以其测试项目在以太网中和CAN中也是基本类似的。但其测试系统，是要基于以太网来实现的。此项测试比较经典，不做展开介绍。

12、AVB/TSN测试、DDS测试

AVB/TSN以及DDS，是以太网场景中的两个特殊的协议，分别解决了不同的问题。测试内容既包括协议一致性测试，也包括各种配置参数测试，也包括系统级甚至整车级的测试。属于相对比较前沿应用数量较少的测试，此处不做展开介绍。

13、基本通信性能及稳定性测试、SOME/IP的服务测试

这两项测试属于具体应用的测试。基本通信性能是在以太网的节点或者系统层面，对以太网通信的基本功能或基本性能进行测试，不属于协议一致性测试，而是属于以太网技术在具体落地过程中的整体效果的测试。包括数据库中的一致性检测（应该有哪些报文不该有哪些报文，时间要求，转发要求等）、通信负载、长时间通信稳定性、故障注入测试等内容。服务测试则是对那些基于SOME/IP的，在数据库中进行设计，并在节点中所实现的各种服务功能的测试，这些测试项包括特定服务的服务接口测试、服务序列测试（一个服务正常实现时，应该先发什么再发什么的对话顺序）、服务的基本参数测试等内容。这些测试项，因为每家实现的功能和期望的最终效果都不一样，因此没有公开的测试标准。需要依据每家的实现特点，进行特定的测试用例的设计和实现。这些测试项既可以通过手动测试，也可以进行自动化测试。

14、以太网系统级测试、以太网实车测试

这两项测试也属于具体应用的测试，是在系统层面和整车层面对汽车以太网的落地效果进行测试，不属于协议一致性测试。这里的测试项，属于定制化比较强的测试，要针对OEM对以太网的设计需求，进行测试用例设计。汽车以太网的系统级测试和实车测试与CAN总线有非常大的不同，因为CAN是总线式通信，只需要把测试设备挂在CAN总线上，就能检测通信内容了。但因为以太网是点对点通信，测试设备没办法直接加入到通信网络中，因此想要获取以太网通信内容，要么通过Bypass模式，要么通过交换机端口镜像的模式。

Bypass模式会涉及到相对比较复杂的测试设备（支持Bypass的线束）和测试接口卡（支持Bypass的接口卡），相对来讲其测试的复杂度会高一些。而端口镜像的方式，一般网关节点也很少预留一个通道出来专门做测试，所以难度也比较大。最简单的实现，就是在功能层面，如果基于以太网的节点之间的预定的功能实现了，那就默认以太网是实现正确的，但此种情景之下的测试覆盖度肯定是不够的。综上，系统级和实车级的以太网测试，有较大难度，但也最好能够开展，因为其具备一定的意义。

15、其他相关测试

前边介绍的各种测试内容基本验证了通信相关的各种能力（协议一致性、实现后的基本功能和基本性能），而在这些内容之上的还会有具体的应用实现的测试，主要的是SOA测试。SOA测试是对服务的验证，属于功能测试范畴。测试内容可能是在一个功能域内，也可能是跨不同功能域，因为是功能相关的测试，因此会有对应的SIL测试和HIL测试，通过这些内容对服务所实现的各种功能和性能进行测试，此处也不做展开。