标签: 定制化测试

上回先从“关于测试”（ 聊聊车载以太网测试：（1）关于测试-面包板社区 (eet-china.com) ）聊起，让我们对 汽车电子测试面向的对象的复杂度 有了了解，也认识到要想成为 “专业优秀”的汽车电子测试人员 ，需兼顾软硬件知识储备，不仅要知其然，更要“知其所以然”。上回算是一个引言，本次正式进入正题，咱们来聊聊以太网究竟测什么？剩下两个主题 “以太网 -如何测”、“以太网-测试策略” 的文章 后续将陆续发布，敬请持续关注！ 引言 对以太网及以太网测试的“慌” 源自何处： 1，你 真的 了解你的 “ 对象 ” 是什么 ” 吗 ， 懵 圈 ； 2， “对象”过于高深 ， 无从下手，迷茫 ； 3 ，时间 阀门 、 领导期盼 、 同仁 对手进步 ，紧张 于是按部就班想从那本几千页白皮枕头书 （奉为宝典） 以及文山文海 中找寻答案， 发现书中各种跳转索引，毕其一生无法阅尽 （其实是字典） ，更慌了。 如何是好？ 先来说说“道” 一个 中心： 无论是 何 “线”/ 何 “网”，都是服务与整车功能和特性的； 所以你的以太网用来做什么， 应用场景是什么， 这是首要问题？ 有的放矢； 两个基本点： 其一，测试源 自 需求规范，直白点：你或你 的 客户（O EM ）的需求规范定义了啥，自然就要测啥，需求的可验证性也是判断需求是否合理的 标准 。 其二， 立足与自身角色 和职责 （ 你是谁 ，在做什么 ） 再来聊聊“术” 复杂问题简单化， 把 庞杂 的以太网 需求/测试规范粗暴划分为两块 。 行业通用需求及测试 规范体系 此类规范针对 E CU 级或 Component 级 。 O PEN 下图（如需 visio 版可联系 ）从E CU 及E CU 交互性角度 而绘制的 OPEN 所 定义的规范 集 ，其中测试规范为T C8 & TC1 & TC12 （1 000B ase -T1 ）， 针对 T C8- 2. 0 来 个走马观花 ： 何为重点，为何重点？ L 1- P MA ： E TH 通信 速度 的大幅 提升，使得通信 “品质” 对物理链路特性更 敏感 、更 矫情 ，匹配电路的设计、 L ayout布局和布线长度、连接器、线束的选择 （ 别被宣传材料误导， 传统C AN 线 束 是无法 直接 用作量产E TH ） ，甚至在车中的走线 路径 都对通信带来至关重要的影响，所以P MA 测试重要且是 前提 。当然，从系统的层面需要考虑设计不同测试场景 验证耦合影响 （这一点是T C8 中未曾涉及的） 。 L1- I OP （交互性测试） ： 首先，从以太网的通信机制上物理层面需建立Link才可进行 后续 的 通信， 这是基础， 和传统 车载 总线不是一个套路；其次， 感兴趣 同仁 的可以研究下N XP M arvell BR 的P HY U ser M anual ， 都 遵循8 02 . 3 bw中定义 通用 特性和 状态机，但实现细节是 各显神通 ， 即使是一家厂商的P HY ，配置 的 不同也会带来影响， 从O EM 角度要保证各个节点之间可通信交互，从Tier 1 角度要证明自己可以和其它节点通信 ；综上 ， 为何 I OP 测试 重要 ，为何须对P HY 有深入的 知识储备 才可以支撑 该 测试； 剧透，T C8-IOP 所提供的 测试项也是不够的，还有很多场景是需要从车辆实际使用的角度去 追加 考量 的； L 3-L5 ： 侧重于对通信软件的逻辑性和 部分格式 参数的 验证 ， 对于 逻辑性如果选用 如 V ector 的 通信代码 Package是很有保障的； 但是 代码包再专业 ，需要配置好，需要和硬件结合好 ， 如下 Vector AUTOSAR -ET H 代码中需配置的参数 几百个之多 ， 复杂度 可见一斑，所以对于“参数”类的测试是需要着重留意的 。 图： DaVinci 以太网参数配置界面 AUTOSAR - ETH AUTOSAR 组织针对嵌入式 资源 有限的特 点 ，对传统T CP/IP/UDP 代码做了优化 （内 存 访问机制做了优化） ， 同时 提供 了对应的 测试验证规范 ，对于采用 AUTOSAR 架构的以太网节点，当然需要覆盖该测试 。 AV nu 针对A VB （包括T SN ） ，提供完整的需求规范和测试规范的定义，个人觉得A VB 规范体系 很 成熟和完善 ， 但是对于 车载 应用 ， 成本和性能的严苛要求， 让 A VB 节点 开发实现 难度 很 大 ， 对软硬件整体开发能力要求很高，与之对应A VB 相对的测试功能和性能测试成为发现问题的重要支撑 ； RFC 关于R FC 提到最多的是 R FC2889 、 2 544 、3 918 ，其中2 889 和2 544 常被用 作 Switch 芯片level 的验证 用以代替T C8-L2 ，个人观点如果测试的是芯片本身的“天然 属 性”，Tier 1 / O EM Review报告即可，如果涉及与上层代码的 的交互或 用户的配置，就当引起重视了， 补充一点 2 544 的测试项 所隐含 的Concept是值得 学习和和借鉴 的 。对于3 918 的 IGMP 测试完全取决与是否使用了该协议 。 O EM 定制需求及测试 包括部件级、系统级和实车级，当然对于系统和实车的测试主体 仅为 O EM 。 部件级 基础测试： 比如 通信电压 、休眠唤醒 等 相关测试，后者最闹心，有了问题往往会引发馈电， 但 对当前的 以太网 应用基本不 经由 以太网唤醒（虽然P HY 支持） ， 缓期执行可 稍心安 一阵 ； 数据库的一致性验证 ： 对O EM 定义的参数进行一致性验证，比如 数据场 格式、数值范围、 VLAN-ID 、 SOME/IP 报文格式 ， 报文 时间参数 等； 通信应用测试： SOME/IP 应用 测试 、 UDP-NM ，其中U DP - NM 和 AUTOSAR - NM 换汤不换药，网络管理状态机相同，但是 前面已提到，短期内不会被应用，至于原因， 篇幅受限， 可自行了解P HY 的Link 机制和 过程、N XP 等 datasheet 、 T C10 规范 就 会有个清晰认识了 ； 待T C10 推广，E TH 作为主干网了U DP-NM 就逃不掉了。 通信鲁棒性和性能测试 ： 部分 测试 点 来自 于O EM 正向 需求，更 多的源自 对网络 特性 、 对车辆使用场景的理解； 基于以太网的诊断 和刷写 ： 以太网P HY 提供了太多的寄存器 可 配置， P HY 状态复杂， 从整车 功能 应用 的 角度 相当多的状态 须 通过诊断方式 进行 操控 ，所以 其 诊断将会比传统的复杂 ， 影响诊断设计， 同样直接影响了测试范畴 ；关于刷写， ISO13400 做了框架性的定义， 但毋容置疑各 O EM 会做 自定义 Detail （比如激活方式、 Do IP 报文类型） ，同时需要区分边缘节点和内部节点，是存在差别的 ，需定制开发的 ； 系统 级 ： 这是O EM 的核心关注点 之一 ，从目的上与传统总线通信 系统级测试 无二异， 需 验证 系统层面的通信逻辑及逻辑稳定性、鲁棒性和性能 指标 ，单就测试条目，确存在部分 条目 与部件级相同，但是测试方法是有很大差异的 ； 另外有些测试 点 在系统层面 才会更有意义 ， 比如不同模式 （ 哪些 模式呢？） 下的带宽监测、延时等 ；除通信外，系统层面的刷写特性也是需要 验证的 。 实车 级 同样的问题，实车和系统 、部件 又有何 区别 呢？要弄明白这个问题，就要考虑，总线 网络 /通信 是用来干嘛的？ 所以到了实 车阶段 网络测试，已和功能测试密切耦合了 （尤其是用S OME/IP ） ，但是从场景 选择及目的，测试的 关注 点 ， 是 存在差异的， 比如 触发 车辆的特定模式、触发 特定的功能应用场景，验证通信的稳定性。 当然 环境不同， 考量 点 也 存在差异 ， 以刷写为例 ，实车层面 需 考虑车辆操作状态对刷写的影响同样需观测刷写对实车电子电器部件带来的“ 作用” 。 小结： 哪些需要重点测试？总的来说， 对部件级而言涉及 自定义需求，自设计方案，软硬结合的 ，系统和实车需结合应用场景和使用环境 。 希望文中的c oncept和思路 可 供 借鉴 ， 技术细节涉及 K now- H ow，犹抱琵琶半遮面 了 ， 欲知详情如何，面对面跟您细细道来！