原创 聊聊车载以太网测试：（2）以太网测什么

上回先从“关于测试”（聊聊车载以太网测试：（1）关于测试-面包板社区 (eet-china.com)）聊起，让我们对汽车电子测试面向的对象的复杂度有了了解，也认识到要想成为“专业优秀”的汽车电子测试人员，需兼顾软硬件知识储备，不仅要知其然，更要“知其所以然”。上回算是一个引言，本次正式进入正题，咱们来聊聊以太网究竟测什么？剩下两个主题“以太网-如何测”、“以太网-测试策略”的文章后续将陆续发布，敬请持续关注！

引言

对以太网及以太网测试的“慌”源自何处：

1，你真的了解你的“对象”是什么”吗，懵圈；

2，“对象”过于高深，无从下手，迷茫；

3，时间阀门、领导期盼、同仁对手进步，紧张

于是按部就班想从那本几千页白皮枕头书（奉为宝典）以及文山文海中找寻答案，发现书中各种跳转索引，毕其一生无法阅尽（其实是字典），更慌了。如何是好？

先来说说“道”

一个中心：无论是何“线”/何“网”，都是服务与整车功能和特性的；所以你的以太网用来做什么，应用场景是什么，这是首要问题？ 有的放矢；

两个基本点：

其一，测试源自需求规范，直白点：你或你的客户（OEM）的需求规范定义了啥，自然就要测啥，需求的可验证性也是判断需求是否合理的标准。

其二，立足与自身角色和职责（你是谁，在做什么）

再来聊聊“术”

复杂问题简单化，把庞杂的以太网需求/测试规范粗暴划分为两块。

行业通用需求及测试规范体系

此类规范针对ECU级或Component级。

OPEN

下图（如需visio版可联系）从ECU及ECU交互性角度而绘制的OPEN所定义的规范集，其中测试规范为TC8&TC1&TC12（1000Base-T1），针对TC8-2.0来个走马观花：何为重点，为何重点？

L1-PMA：ETH通信速度的大幅提升，使得通信“品质”对物理链路特性更敏感、更矫情，匹配电路的设计、Layout布局和布线长度、连接器、线束的选择（别被宣传材料误导，传统CAN线束是无法直接用作量产ETH），甚至在车中的走线路径都对通信带来至关重要的影响，所以PMA测试重要且是前提。当然，从系统的层面需要考虑设计不同测试场景验证耦合影响（这一点是TC8中未曾涉及的）。

L1-IOP（交互性测试）：首先，从以太网的通信机制上物理层面需建立Link才可进行后续的通信，这是基础，和传统车载总线不是一个套路；其次，感兴趣同仁的可以研究下NXP Marvell BR的PHY UserManual，都遵循802.3bw中定义通用特性和状态机，但实现细节是各显神通，即使是一家厂商的PHY，配置的不同也会带来影响，从OEM角度要保证各个节点之间可通信交互，从Tier1角度要证明自己可以和其它节点通信；综上，为何IOP测试重要，为何须对PHY有深入的知识储备才可以支撑该测试；剧透，TC8-IOP所提供的测试项也是不够的，还有很多场景是需要从车辆实际使用的角度去追加考量的；

L3-L5：侧重于对通信软件的逻辑性和部分格式参数的验证，对于逻辑性如果选用如Vector的通信代码Package是很有保障的；但是代码包再专业，需要配置好，需要和硬件结合好，如下Vector AUTOSAR-ETH代码中需配置的参数几百个之多，复杂度可见一斑，所以对于“参数”类的测试是需要着重留意的。

图：DaVinci以太网参数配置界面

AUTOSAR-ETH

AUTOSAR组织针对嵌入式资源有限的特点，对传统TCP/IP/UDP代码做了优化（内存访问机制做了优化），同时提供了对应的测试验证规范，对于采用AUTOSAR架构的以太网节点，当然需要覆盖该测试。

AVnu

针对AVB（包括TSN），提供完整的需求规范和测试规范的定义，个人觉得AVB规范体系很成熟和完善，但是对于车载应用，成本和性能的严苛要求，让AVB节点开发实现难度很大，对软硬件整体开发能力要求很高，与之对应AVB相对的测试功能和性能测试成为发现问题的重要支撑；

RFC

关于RFC提到最多的是RFC2889、2544、3918，其中2889和2544常被用作Switch芯片level的验证用以代替TC8-L2，个人观点如果测试的是芯片本身的“天然属性”，Tier1/OEM Review报告即可，如果涉及与上层代码的的交互或用户的配置，就当引起重视了，补充一点2544的测试项所隐含的Concept是值得学习和和借鉴的。对于3918的IGMP测试完全取决与是否使用了该协议。

OEM定制需求及测试

包括部件级、系统级和实车级，当然对于系统和实车的测试主体仅为OEM。

部件级

基础测试：比如通信电压、休眠唤醒等相关测试，后者最闹心，有了问题往往会引发馈电，但对当前的以太网应用基本不经由以太网唤醒（虽然PHY支持），缓期执行可稍心安一阵；

数据库的一致性验证：对OEM定义的参数进行一致性验证，比如数据场格式、数值范围、VLAN-ID、SOME/IP报文格式，报文时间参数等；

通信应用测试：SOME/IP应用测试、UDP-NM，其中UDP-NM和AUTOSAR-NM换汤不换药，网络管理状态机相同，但是前面已提到，短期内不会被应用，至于原因，篇幅受限，可自行了解PHY的Link机制和过程、NXP等datasheet、TC10规范就会有个清晰认识了；待TC10推广，ETH作为主干网了UDP-NM就逃不掉了。

通信鲁棒性和性能测试：部分测试点来自于OEM正向需求，更多的源自对网络特性、对车辆使用场景的理解；

基于以太网的诊断和刷写：以太网PHY提供了太多的寄存器可配置，PHY状态复杂，从整车功能应用的角度相当多的状态须通过诊断方式进行操控，所以其诊断将会比传统的复杂，影响诊断设计，同样直接影响了测试范畴；关于刷写，ISO13400做了框架性的定义，但毋容置疑各OEM会做自定义Detail（比如激活方式、DoIP报文类型），同时需要区分边缘节点和内部节点，是存在差别的，需定制开发的；

系统级：

这是OEM的核心关注点之一，从目的上与传统总线通信系统级测试无二异，需验证系统层面的通信逻辑及逻辑稳定性、鲁棒性和性能指标，单就测试条目，确存在部分条目与部件级相同，但是测试方法是有很大差异的；另外有些测试点在系统层面才会更有意义，比如不同模式（哪些模式呢？）下的带宽监测、延时等；除通信外，系统层面的刷写特性也是需要验证的。

实车级

同样的问题，实车和系统、部件又有何区别呢？要弄明白这个问题，就要考虑，总线网络/通信是用来干嘛的？所以到了实车阶段网络测试，已和功能测试密切耦合了（尤其是用SOME/IP），但是从场景选择及目的，测试的关注点，是存在差异的，比如触发车辆的特定模式、触发特定的功能应用场景，验证通信的稳定性。当然环境不同，考量点也存在差异，以刷写为例，实车层面需考虑车辆操作状态对刷写的影响同样需观测刷写对实车电子电器部件带来的“作用”。

小结：

哪些需要重点测试？总的来说，对部件级而言涉及自定义需求，自设计方案，软硬结合的，系统和实车需结合应用场景和使用环境。希望文中的concept和思路可供借鉴，技术细节涉及Know-How，犹抱琵琶半遮面了，欲知详情如何，面对面跟您细细道来！