标签: 刷写测试

前言 FlexRay 总线目前主要应用在高端品牌车型（如宝马、奔驰、奥迪、沃尔沃、捷豹路虎、凯迪拉克等），在以太网技术没有成熟之前，也有部分 OEM 将其作为主干网应用。 相对于传统的 CAN 测试， FlexRay 测试有哪些特点呢？本期我们将主要介绍 FlexRay 相关协议，并分享 FlexRay 诊断刷写测试实践经验。 FlexRay 简介 FlexRay 的出现始于二十世纪九十年代末， BMW 和 Daimler Chrysler 开始着手进行 FlexRay 的研究，其初始目标是为了实现线控等应用。 2000 年成立了 FlexRay 联盟， 2005 年发布 FlexRay V2.1 规范。 2006 年， FlexRay 首次应用于量产车——用在 BMW X5 的悬架系统中。 FlexRay 总线具有以下技术特点： · 时间确定性 FlexRay 静态段采用基于时间触发的媒体访问策略，保证了消息传输的时间确定性。 · 容错性 FlexRay 支持单通道和双通道的容错通信，使得当一个通道出现故障无法进行通信时，另一个通道上的数据可以保证系统的正常运行。 · 灵活性 FlexRay 通信周期分为静态段和动态段，将基于时间触发和基于事件触发两种媒体访问方式相结合。 · 高带宽（相对于 CAN/CAN FD ） FlexRay 支持两个通道同时进行数据传输，每个通道的带宽最高可达 10Mbit/s 。 另外，大家可以留意下近期新的以太网通信技术 10Base-T1 ，其相关的通信技术与 FlexRay 有异曲同工之处。 FlexRay 通信协议 FlexRay 拓扑结构 FlexRay 有两个通道，即通道 A 和通道 B ，支持多种网络拓扑结构，可配置成： · 单通道或双通道总线网络 · 单通道或双通道星型网络 · 总线型和星型的混合型网络 图 1 双通道总线型拓扑结构 FlexRay帧格式 FlexRay 数据帧由帧头、有效负载数据段和帧尾三部分构成。 图 2 FlexRay 帧格式 FlexRay 媒体访问控制（ MAC ） FlexRay 媒体访问控制（ MAC ）是基于循环的通信周期来实现的，在一个通信周期中， FlexRay 协议提供两种 MAC ： · 静态段基于时分多址 TDMA （ time division multiple access ）的访问机制 · 动态段基于最小时隙的访问机制，也称灵活的时分多址 FTDMA （ flexible time division multiple access ） 通信周期是 FlexRay 媒体访问控制的基本要素，协议是通过时间分层的方法来定义通信周期的。 图 3 通信周期的时间分层 1. 通信周期层 一个通信周期包括静态段、动态段、符号窗口和网络空闲时间四个部分。 · 静态段采用 TDMA 机制进行数据传输 · 动态段采用 FTDMA 机制进行数据传输 · 符号窗口主要用来发送特征符号 · 网络空闲时间在一个通信周期的末尾，主要用来进行时钟同步 2. 仲裁网格层 在仲裁网格层中，静态段是由若干个等长的静态时隙（ static slot ）组成的，动态段是由若干个等长的最小时隙（ minislot ）组成的。 3. 最大时间节拍层 不同数目的最大时间节拍（ macrotick ）分别构成了静态时隙、最小时隙、符号窗口及网络空闲时间部分，所以整个通信周期是由若干最大时间节拍组成的。 4. 最小时间节拍层 一个最大时间节拍是由若干个最小时间节拍（ microtick ）组成的。 FlexRay 传输层协议 ISO 10681-2 规定了 FlexRay 网络层和传输层协议（本文不做区分，统称传输层协议），相对于 CAN 传输层协议， FlexRay 传输层协议具有如下不同点： 协议功能 · 支持无 ACK 应答和有 ACK 应答（带消息重传机制）的数据传输 · 支持已知消息长度和未知消息长度的数据传输 图 4-1 无 ACK 应答报文传输 图 4-2 有 ACK 应答报文传输 传输层 C_PDU 类型与 PCI 字节 图 5 C_PDU 类型与 PCI 字节 l 起始帧 分为无 ACK 的 STFU 和有 ACK 的 STFA 两种，通过 PCI 第一个字节的低 4 位来区分两者， FPL 表示该帧传输的有效净荷长度， ML 表示数据传输的总长度。 l 连续帧 一般情况下使用 CF1 ，如果有消息重传时，需要 CF1 和 CF2 之间进行切换。当发送 buffer 和接收 buffer 受限时，每个 block 的传输会以 CF_EOB （ End Of Block ）结束，用于请求接收端给出下一个流控应答。 图 6 Num Bytes of Block 与 BufferSize （ BfS ） · 流控帧 PCI 第一个字节的低四位用于区分流控状态： o 3 表示 CTS （ ContinueToSend ） o 4 表示 ACK_RET （ Acknowledge/Retry ） o 5 表示 WT （ Wait ） o 6 表示 ABT （ Abort ） o 7 表示 OVFLW （ Overflow ） · 尾帧 与 CAN 传输层协议不同， FlexRay 在分段传输时必须以 LF 结束。 接收节点的接收性能参数 · CAN ： 传输层协议通过 BlockSize （ BS ）和 SeparationTime （ STmin ）来体现， FlexRay 是通过 BufferSize （ BfS ）和 Bandwidth Control （ BC ）来体现的 · BfS ：表示接收节点当前可接收的最大 buffer · BC ：包含两个参数， separation cycle exponent （ SCexp ）和 maximum number of PDUs per cycle （ MNPC ） 传输层 C_PDU 与链路层 L_PDU 的映射 图 7 C_PDU 格式 图 8 L_PDU 格式 FlexRay 诊断刷写测试实践 F FlexRay 诊断相关的测试相对 CAN/CAN FD 而言，其测试规范的制定及测试脚本的开发相对更为复杂，如下为北汇信息基于 Vector 公司的 CANoe 及部分自定义函数在项目中实现了 FlexRay 诊断刷写测试的示例。 FlexRay 诊断报文示例 图 9 FlexRay 诊断报文示例 FlexRay 诊断测试开发 采用 CANoe 的 CAPL 脚本及部分自定义函数实现了诊断通信、诊断服务和诊断刷写的自动化测试。 图 10 FlexRay 诊断通信部分测试项示例 图 11 FlexRay 诊断服务部分测试项示例 图 12 FlexRay 诊断刷写部分测试项示例 图 13 FlexRay 诊断测试报告示例 总结 北汇信息多年来一直专注于汽车电子测试，在网络测试、诊断测试以及功能测试等领域积累了丰富的实践经验。目前，我们已实现了 CAN 、 CAN FD 、 LIN 、 FlexRay 和 Ethernet 的诊断及刷写测试，欢迎感兴趣的客户朋友与我们探讨交流 ~ 部分图片来源于 Vector 参考文献 ISO 10681-2 FlexRay Communications System Protocol Specification v3.0.1

DoIP简介 以太网最早由BMW引入车内，其应用场景就是刷写，满足类似HMI的地图数据、液晶仪表等软件数据更新，感兴趣的可查阅Thomas Konigseder 的 Automotive Ethernet 书中的介绍。由于其突出的特性，而后得到主要OEM的推崇和更广泛的应用，遂开始了国际标准化（汽车行业一直以来的“套路”）。 DoIP全称：Diagnostic communication over Internet Protocol。顾名思义，通过以太网来实现车辆诊断，其对应的国际标准为ISO 13400，其定义了DoIP协议（基于UDS）并描述了外部测试设备与车辆进行诊断数据交互的流程。 下图为DoIP及基于以太网诊断在OSI 7层模型中及在“7层之外”的“角色”和“位置”。 图1 DoIP及以太网诊断规范框架 DoIP协议要点简述 DoIP报文 DoIP报文在以太网报文中的位置如下图。 图2 DoIP报文在以太网报文中的位置示意图 DoIP报文分为三大类：节点管理类、车辆信息类、诊断类。 节点管理类主要包括报头处理流程、车辆信息获取（如EID、GID、VIN等）、路由激活流程（包括授权以及确认功能）、TCP_DATA socket处理流程。 图3 节点管理类DoIP报文 车辆信息类主要包括获取DoIP实体状态信息、车辆电源模式信息。 图4 车辆信息类DoIP报文 诊断类主要包括诊断报文处理流程以及UDS数据交互。 图5 诊断类DoIP报文示 DoIP会话流程 关闭TCP_DATA socket。 图6 DoIP会话流程 图片来源：ISO 13400-2:Road vehicles - Diagnostic communication over Internet Protocol 边缘和内部节点差异 关于DoIP协议，ISO 13400规范做了框架性的定义，但OEM会依据整车功能需求自定义细节内容，同时会区分边缘节点和内部以太网节点，聊到此处有的小伙伴可能会有疑问，“以太网节点为何要区分边缘节点和内部节点？两者是否可以支持完整的DoIP协议？”接下来我们通过实例讨论边缘节点和内部节点在DoIP报文配置方面的差别。 问题一：内部节点需要支持诊断报文肯定应答(0x8002)么？ 分析：当Tester向内部节点发送诊断请求时，首先边缘节点会先向Tester发送0x8002报文，如果内部节点也支持0x8002报文，随后边缘节点又再一次转发内部节点发送的0x8002报文和诊断应答报文到Tester。 根据DoIP协议，Tester完成诊断报文发送后会等待0x8002报文同时开启P6Client定时器来接收诊断应答报文(暂时不考虑0x8003)。所以如果内部节点支持0x8002报文从系统设计方面考虑不符合DoIP协议，而且会导致以太网系统级诊断刷写测试P6Client参数超时。 图7 内部节点支持0x8002报文交互过程示例 问题二，笔者抛块砖：不同类型节点对路由激活报文该采用何种策略？ 有兴趣的，可就此类技术细节约聊，同样此话题可扩展包括DoIP其他报文针对边缘和内部节点不同的配置和支持方案，当然还有区别最明显的对硬线激活特性支持的差异。 万变不离其宗，以太网节点DoIP报文的配置要服务于整车功能,这部分更应该是OEM设计工程师需要从应用场景角度考虑而进行设计的。仁者见仁,智者见智,在不同拓扑、不同需求情况下设计方案也应当有所差异。 DoIP及以太网诊断测试方案和实践 DoIP及以太网诊断测试实现可以分层来介绍,当然在各层中OEM会在ISO标准需求的基础上做自定义开发。 针对ISO 13400-2的测试 测试内容包括DoIP报文格式、DoIP流程以及DoIP时间参数等，其测试脚本和测试工程通过CANoe（CAPL）定制实现。 图8 基于CANoe开发的部分测试项及测试脚本 图9 某控制器Alive_Check_Message测试报告 针对ISO 13400-3的测试 测试内容包括激活使能线等相关的测试，测试脚本同样通过CANoe（CAPL）开发实现，测试环境需借助于Vector的VT板卡，如VT2004实现硬线的仿真。 针对ISO 14229-1/-5的测试 可基于CANoe Option DiVa可实现，DiVa是Vector公司一款便捷、高效的诊断测试用例生成工具，使用DiVa实现UDSonCAN的测试大家都比较熟悉，那么对于以太网UDS测试DiVa是否也可以覆盖？答案是肯定的。DiVa可基于DoIP协议（ISO 13400）生成以太网UDS测试工程，即按照标准DoIP流程与ECU进行诊断数据交互。 图10 基于DiVa的以太网UDS测试工程 介绍到这里小伙伴们可能会有疑问，对于非标准DoIP协议的以太网节点是否也可用DiVa覆盖其测试需求？比如笔者曾遇到的OEM所定义的以太网节点仅支持DoIP净荷类型中特定的报文，或者以太网节点仅支持OEM自定义格式的诊断报文等情形。 总结 接着上面的问题，对于支持非标准DoIP协议的以太网节点UDS测试需做一 定的定制开发方可。另外，DiVa自动生成的UDS测试工程是否直接满足边缘和内部两种类型节点的测试需求呢，该如何适配？这也是笔者在项目实践过程中遇到的一些工程问题，还曾“遭遇”在DoIP测试过程中由于ARP配置而引起的“异象”以及端口固定等各类疑难杂症！限于篇幅，不做一一介绍了，感兴趣的小伙伴约起来吧！ 北汇信息已为多家主流OEM完成DoIP、以太网诊断、刷写测试相关的项目，为客户提供完整交钥匙工程服务，包括： 设计需求规范的审核完善 测试规范开发 测试脚本定制开发和测试实施服务 车载以太网技术扩散越来越快，相关测试验证工作及对测试验证深度、广度的要求也备受重视，所以实践实战的经验积累、对系统宏观层面的了解也更为关键，北汇信息希望与各位共同进步，价值分享。