随着克罗地亚2-1绝杀英格兰，世界杯决赛两强正式出炉。双雄争霸，最后谁能捧走大力神杯，是群星云集的法国队还是一路高歌猛进的克罗地亚队？让我们麻小扎啤小板凳，相约一起看决赛！
麻小扎啤龙门阵，聊聊车载以太网测试：（2）以太网测什么
回到咱们汽车届“世界杯级明星”车载以太网，上回先从“关于测试”（点击此处回顾→）聊起，让我们对汽车电子测试面向的对象的复杂度有了了解，也认识到要想成为“专业优秀”的汽车电子测试人员，需兼顾软硬件知识，不仅要知其然，更要“知其所以然”。上回算是一个引言，本次正式进入正题，咱们来聊聊以太网究竟测什么？剩下两个主题“以太网-如何测”、“以太网-测试策略”的文章将陆续发布，敬请持续关注！
风哥有话说
对以太网及以太网测试的“慌”源自何处：
你真的了解你的“对象”是什么吗——懵圈
“对象”过于高深，无从下手——迷茫
时间阈门、领导期盼、同仁对手进步——紧张
于是按部就班想从那本几千页白皮枕头书（奉为“宝典”
先来说说“道”
一个中心
无论是何“线”/何“网”，都是服务于整车功能和特性的；所以你的以太网用来做什么，应用场景是什么，这是首要问题，有的放矢。
两个基本点
其一：测试源自需求规范，直白点：你或你的客户（OEM）的需求规范定义了啥，自然就要测啥，需求的可验证性也是判断需求是否合理的标准；
其二：立足于自身角色和职责（你是谁，你在做什么）。
再来聊聊“术”
复杂问题简单化，把庞杂的以太网需求/测试规范粗暴划分为两块。
行业通用需求及测试规范体系
此类规范针对ECU级或Component级。
OPEN Alliance
下图从ECU及ECU交互性角度所涉及的OPEN Alliance所定义的规范，其中测试规范为TC8 & TC1 & TC12（1000Base-T1），针对TC8-2.0来个走马观花：何为重点，为何重点？
车载以太网通信速度的大幅提升，使得通信“品质”对物理链路特性更敏感、更矫情，匹配电路的设计、Layout布局和布线长度、连接器、线束的选择（别被宣传材料误导，传统CAN线束是无法直接用作量产车载以太网），甚至在车中的走线路径都对通信带来至关重要的影响，所以PMA测试重要且是前提。当然，从系统的层面需要考虑设计不同测试场景验证耦合影响（这一点是TC8中未曾涉及的）。
首先，从以太网的通信机制上物理层面需建立Link才可进行后续的通信，这是基础，和传统车载总线完全不是一个套路。
其次，感兴趣的同仁可以研究下NXP、Marvell、Broadcom的PHY UserManual，必然都遵循802.3bw中定义通用特性和状态机，但实现细节是各显神通，即使是一家厂商的PHY，配置的不同也会带来影响，从OEM角度要保证各个节点之间可通信交互，从Tier1角度要证明自己可以和其它节点通信。
综上，为何IOP测试重要，为何须对PHY有深入的知识储备才可以支撑该测试？剧透：TC8-IOP所提供的测试项也是不够的，还有很多场景是需要从车辆实际使用的角度去追加考量的。
侧重于对通信软件的逻辑性和部分格式参数的验证，对于逻辑性如果选用如Vector的通信代码包是很有保障的。
但是代码包再专业，需要配置好，需要和硬件结合好，如Vector MICROSAR.ETH代码中需配置的参数几百个之多，复杂度可见一斑，所以对于“参数”类的测试是需要着重留意的。
AUTOSAR-Ethernet
AUTOSAR组织针对嵌入式资源有限的特点，对传统TCP/IP/UDP代码做了优化（内存访问机制做了优化），同时提供了对应的测试验证规范，对于采用AUTOSAR架构的以太网节点，当然需要覆盖该测试。
AVnu
针对AVB（包括TSN），AVun提供完整的需求规范和测试规范的定义，个人觉得AVB规范体系很成熟和完善，但是对于车载应用，成本和性能的严苛要求，让AVB节点开发实现难度很大，对软硬件整体开发能力要求很高，与之对应AVB相对的测试功能和性能测试成为发现问题的重要支撑。
RFC
关于RFC提到最多的是RFC2889、2544、3918，其中2889和2544常被用作Switch芯片级的验证用以代替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推广，车载以太网作为主干网了，UDP-NM就逃不掉了。
部分测试点来自于OEM正向需求，更多的源自对网络特性、对车辆使用场景的理解。
以太网PHY提供了太多的寄存器可配置，PHY状态复杂，从整车功能应用的角度相当多的状态须通过诊断方式进行操控，所以其诊断将会比传统的复杂，影响诊断设计，同样直接影响了测试范畴。
关于刷写，ISO 13400做了框架性的定义，但毋容置疑各OEM会做自定义Detail（比如激活方式、DoIP报文类型），同时需要区分边缘节点和内部节点，是存在差别的，需定制开发的。
系统级
这是OEM的核心关注点之一，从目的上与传统总线通信系统级测试无二，需验证系统层面的通信逻辑及逻辑稳定性、鲁棒性和性能指标，单就测试条目，的确存在部分条目与部件级相同，但是测试方法是有很大差异的；另外有些测试点在系统层面才会更有意义，比如不同模式（哪些模式呢？）下的带宽监测、延时等；除通信外，系统层面的刷写特性也是需要验证的。
实车级
同样的问题，实车和系统、部件又有何区别呢？要弄明白这个问题，就要考虑，总线网络/通信是用来干嘛的？所以到了实车阶段网络测试，已和功能测试密切耦合了（尤其是用SOME/IP），但是从场景选择及目的，测试的关注点，是存在差异的，比如触发车辆的特定模式、触发特定的功能应用场景，验证通信的稳定性。
当然环境不同，考量点也存在差异，以刷写为例，实车层面需考虑车辆操作状态对刷写的影响，同样需观测刷写对实车电子电器部件带来的“作用”。
小结
哪些需要重点测试？总的来说，对部件级而言涉及自定义需求，自设计方案，是软硬结合的；系统和实车需结合应用场景和使用环境。希望文中的concept和思路可供借鉴，技术细节涉及Know-How，先来个“提纲挈领”吧，犹抱琵琶半遮面，欲知详情如何，面对面跟您细细道来！
如需了解如上内容更多信息，
可以随时联系北汇信息！
电话：021-34716271
邮箱：info@polelink.com
微信ID：Polelink_Info
北汇信息｜专注电控、新能源、MES技术
长按二维码关注北汇信息