标签: 测试规范

背景 由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，所以新版删除了与之相悖的和不合理的测试用例。 小结 通过上述分析可看出，新版修订了不少测试规范本身存在的问题，删除重复的测试用例、测试逻辑错误的测试用例以及可选择性实现的特性所对应的测试用例。最重要的是移除了很多并不适用于车载以太网通信场景的测试用例，这也让我们看到了车载以太网的基础协议测试的进化，更为“适合”和更具针对性。 尽信书则不如无书，需时刻保持独立思考。上述测试规范中的部分问题，北汇在过去两年的测试实施过程中，已经有所积累并针对性地进行了调整。篇幅所限，关于“规范比对”的更多内容和技术细节，敬请持续关注，北汇将尽力为您的车载以太网产品提供专业的测试验证服务和技术咨询！另，如有谬误之处，敬请指正！

汽车软件与C语言 随着软件定义汽车概念的兴起，汽车软件开发的工作量开始呈指数级增加，当前车载软件代码量已经达到1亿-3亿行。这是一个什么概念呢，相当于比Windows系统还高出一个数量级。据调查，大部分的车载软件都是使用C语言进行开发，因为C执行效率高、代码量小，因此在汽车的小型控制部件中被广泛使用。尽管C语言在嵌入式系统中如此流行，但仍有很多缺陷： 1. C是弱类型语言 C 是弱类型语言。 在 下面 代码中， char 类型 和 int 类型是可以直接运算的，因为 char 类型会被提升为 int ，这就是 C 中的隐式类型转换，将精度较小的转换为大精度的， 在 这个意义上讲，它并不符合强类型语言的定义。 # include int main ( void ){ char a ='a' ; int b =10 ; int c = a + b; return 0 ; } 2. C有更多操作符及优先级 C相较于其他的语言有更多的操作符，因此其也有更多不同的操作符优先级，其中的大多数都不是能直观判断的，所以通常会被程序员误解。 3. C程序一般不为常见问题提供运行时检查 ，例如运算异常（如零除），溢出，指针的有效性或者数组越界。 MISRA C编码规范 综上所述，C语言对于安全性要求很高的汽车软件而言是不安全的。汽车工业软件可靠性协会(Motor Industry Software Reliability Association,MISRA)在1998年发布了第一版针对汽车工业软件安全性的C语言编码规范---MISRA C, 让程序员有规范可 循 。 从1998年发布的MISRA C:1998，只针对汽车制造业的嵌入式开发，到MISRA C:2012，已经开始扩大覆盖范围到其他高安全性系统。 下面我们就看一下具体的MISRA C:2012规则内容。 MISRA C:2012规则介绍 MISRA C:2012 包含 159 条规则，其中 Directives 有 16 条， Rules 有 143 条。 Dir 4.12: 动态内存分配不应被使用。 图1 Dir 4.12规则 原理：任何库的动态内存分配和进程的释放都可能导致未定义的行为。 Rule 10.3:表达式的值不应分配给具有较窄基本类型或不同基本类型类别的对象。 图2 Rule 10.3规则 原理：C语言允许程序员有相当大的自由度，并允许自动形成不同算术类型之间的赋值。然而，使用这些隐式转换可能会导致意外的结果，可能会丢失值、符号或精度。如MISRA基本类型模型所强制的，使用更强的类型可以降低这些问题发生的可能性。 看到这里，相信大家有许多疑问：为什么一个是Dir而另一个是Rule呢？Category、Analysis这些又是什么呢？下面就来介绍一下MISRA规则的分类和属性。 MISRA C:2012规则分类 MISRA C:2012的规则按照性质分为两类：指令（Directives）和规则（Rules）。规则有三种不同类别：”强制(Mandatory)”、”要求(Required)”和“建议(Advisory)”；其中具体结果如下图所示。 图 3 MISRA C: 2012 规则分类 那么，在任何情况下都可以明确地说明该条代码违反了规则吗？ 出于此问题，MISRA C:2012规则的Rules具有可判定性Decidable/Undecidable，他们的区分标准为是否能在任何情况下明确回答“该代码是否遵循了这条规则”？ 图 4 MISRA C:2012 规则的可判定性 要注意的是，可判定性并不适用于Directives规则。 Rules 的分析范围 分为 Single Translation Unit/System ： 图5 Rules的分析范围 Helix QAC与MISRA C:2012 很明显，MISRA C:2012规则就是为静态测试而生的。 Perforce 公司的静态分析工具 Helix QAC，是汽车行业中主流的静态分析器，其开发团队是MISRA C&C++编码委员会的创始会员，也是MISRA C&C++委员会最具影响力的会员。Helix QAC具有业界领先的编码规范覆盖度，目前MISRA C:2004的编码规范覆盖度达到了99%，而对MISRA C:2012的编码规范覆盖度已达到100%。是嵌入式静态分析领域公认的行业领导及先驱。 图6 Helix QAC的编码规范覆盖度 下面以开源工程wget为例，演示一下Helix QAC是如何定位违反MISRA C:2012规则的代码。 图7 Helix QAC诊断消息0883 诊断消息0883：“包含文件代码不受重复包含的保护”正是MISRAC:2012规则Dir 4.10的映射，通过诊断消息开发人员就可以了解到代码违反MISRA C:2012规则的情况，从而对代码进行修改使其合规。 图8 Rule 9.1规则的不同诊断消息 Rule 9.1：对象在初始化前不能被使用。 图9 Rule 9.1规则 这里大家或许会疑惑，为什么同一个规则下会产生两种诊断消息呢？答案是：数据流分析。 数据流分析是Helix QAC的高级分析，Helix QAC通过内置的数据流分析器 分析运 行 时的 行 为。数据流分析可以识别各种问题，包括可能指示编码错误的条件，以及可能导致程序崩溃的关键未定义 行 为。 我们可以看到图中的诊断消息2962和2963虽然都是Rule 9.1产生的，但是分成了 S uspicious和 A pparent两种。我们在代码中看一下这两条诊断消息的不同。 诊断消息2963的源码如下： 在226行声明了数组saved_lengths,241行对saved_lengths进行赋值操作，在255行使用saved_lengths。但saved_lengths的赋值操作不一定会进行，因为该操作在for循环中进行，如果for循环没有达到执行条件导致并未执行，那么此时saved_lengths就没有初始化。所以此条诊断消息是Suspicious。 诊断消息2962源码如下： 可以看到，在824行声明变量dt，但后面并未对dt进行初始化。所以此条诊断消息是Apparent。 由此可见Helix QAC数据流分析功能的强大。Helix QAC的数据流功能也在不断地更新，在即将到来的新版本2022.4中，数据流计划从Helix QAC引擎中分离出来，成为自己的组件。 在近期发布的最新版本Helix QAC 2022.3中， 引入了对微软Visual Studio 2022的支持 ， 提供更广泛的编译器支持， 以及对C++20和C23的升级语言支持。 此外， 此版本具有使用“qainject”自动生成 CCT 的功能，可简化构建理解和编译器设置 。 作为Perforce公司的合作伙伴，北汇信息将为客户提供优质的静态代码测试工具和服务 。

上一期“物理层PMA测试实践（ 车载以太网 | 测试之实锤-1000BASE-T1物理层PMA测试实践-面包板社区 (eet-china.com) ） ”，咱们从环境设备组成、被测对象组成再到测试过程和测试结果，将完整的PMA测试过程做了一个经验分享。 由下层开始逐层“披沙沥金”，这一期轮到IOP测试上阵了。同样，先展示下典型的测试报告，覆盖了TC8 2.0 IOP的各项测试。 图 1 ： IOP测试报告 设备环境组成 CANoe 开发并运行IOP的自动化测试脚本（CAPL） VN5640 与DUT诊断接口交互及Golden Device的控制 VT板卡 实现DUT电源回路控制和唤醒源仿真 程控电源 DUT电源供电 GoldenDevice 实物如下图2所示（Technica定制），其实质就是一个更为稳定可靠，性能更强的以太网节点，从其使用的处理器为PowerPC，可见一斑，不拿被测对象做小白鼠是它的“责任” 通过与DUT Link，获取与“本地”计算相关的测试参数和数据；提供通信链路特性仿真和故障仿真功能 提供了100Base-Tx的程控接口和基于SOME/IP的API，通过CANoe可控制其实现自动化测试 图 2 ：Golden Device实物图 被测对象组成 硬件 以太网节点及线束连接器，实物如下图3： 图 3：被测以太网节点 软件接口定义 DUT相关的诊断指令接口定义，实现PHY相关状态的读取 测试过程 测试准备 连接DUT与Golden Device、VN5640及VT 测试执行 运行IOP自动化测试脚本 ➔ 获得测试数据和报告 图 4 ：测试软件界面 测试分析 关于IOP测试的必要性 首先，从以太网的通信机制上物理层面需建立Link才可进行后续的通信，这是基础，和传统车载总线完全不是一个套路。 其次， NXP、Marvell、Broadcom的PHY UserManual都遵循802.3bw中定义通用特性和状态机，但实现细节是各显神通，即使是一家厂商的PHY，配置的不同也会带来影响，从OEM角度要保证各个节点之间可通信交互，从Tier1角度要证明自己可以和其它节点通信。 综上，为何IOP测试重要，为何须对PHY有深入的知识储备才可以支撑该测试？剧透：TC8-IOP所提供的测试项也是不够的，还有很多场景是需要从车辆实际使用的角度去追加考量的。 关于测试规范及实现方案 TC8 1.0 到 2.0的IOP存在几处变化，TC8 2.0中关于SQI测试的描述“the respective artificial noise injection ”引起大家焦虑，如何实现“noise injection（噪声注入）”？ 需要用抽丝剥茧的方法进行分析： SQI测试目的/目标 SQI值应随着通信信号质量的变化而“相向”变化，当SQI值小于40%时，应停止通信 对应的应用场景 应用层可获得当前的通信质量状态，通信信号质量变差到一定程度，为保证数据的有效性，此时宁可不发，不能错发 通信信号变差因素 概括来说，一是来自外部的辐射，二是通信链路的物理特性。第一点可暂且忽略（原因大家可自行分析），第二点进一步剖析 通信链路物理特性的影响因素 对以太网通信而言首当其冲的是阻抗及阻抗突变，比如线束特性/长度、连接器接入等，从而引起信号衰减/反射，其中的信号反射会在原信号中产生“叠加噪声” 噪声注入，是通过现象来仿真，而引起这种现象最重要的根源是阻抗；噪声注入是可行的方案之一，但是可操控性、“性价比”较低（需信号发生器、耦合器等）。所以，接近本源的，看似简单略显粗暴的方式，其实更为有效（以下图5的SQI测试报告为证） 图 5 ： 基于 CANoe和Golden Device自动生成的SQI测试报告 测试前提条件 IOP测试需要Tier1伙伴准备大量条件和自测参数才可以完成，这些参数用于满足不同的测试条目（比如下述的测试），如PHYLink模式、PHY准备Link的时间等，这些参数与软件配置、硬件特性及设计都有一定的关联，比如并不是所有的PHY都支持SQI测试。 图 6 ：Link-Up Time测试报告 小结 尽信书则无书，面对技术疑惑/难题，不可想当然或似是而非地放过，也不必焦虑甚至恐慌；要严谨对待，从多个维度分析，并加以实践验证；分析问题的过程和方法，表象背后的原因、场景，才是需要学习和积累的核心价值。 后期将陆续更新以太网测试其他相关的干货技术文章，敬请期待！