标签: 汽车ECU

1 .E2E 概念介绍 1.1 E2E是什么？ E2E全称为End to En d， 代表的 是AUTOSAR中的一种数据保护机制 ，从名称中 可以看出，这是一个终端到终端的逻辑 。 那么这里的终端是指ECU吗？ 答案是否定的 。在AUTOSAR的架构中，最上层为包含SW-C（Software Component）的应用层，类似于手机应用程序中的各种APP。对于E2E来说，数据的传递 不是针对ECU到ECU 的层级 而是SW-C到SW-C 层级 。 图 1 AUTOSAR软件概貌 在车载网络中， 信息交换通常是 从一个ECU发送信号，另一个ECU接收信号。对E2E而言，通常是从 源 SW-C生成信号，经过RTE（Run-Time Environment）、BSW（Basic Software） 并在物理总线上传输后到达 目标 SW-C。在这个过程中，信号的传递可能由于一些 故障 情况（比如 软件运行错误 ）无法到达目标终端， 或是 信号本身被干扰 /损坏 ，尤其对于安全相关的信号 （车速、档位、 车辆 /电源模式等） 来说，这种情况 会带来很大的隐患 。而E2E正是通过一些机制，使发送终端和接收终端的数据 保持一致 ，保证信息的完整性 。 图 2 错误来源 的示意 1.2 E2E的适用范围 E2E可适用 于 各种总线通信， 以 北汇 信息 参与 的 项目 为例 ，E2E机制 已 应用于CAN、CAN FD 、 LIN 、FlexRay总线 通信中 ， 对于以太网 当然 可应用E2E机制 ， 但是需考虑和留意如下的问题： 不同于上文介绍的发送端/接收端的通信模式，以太网中 将会广泛 应用 基于S oA 的 客户端/服务器的通信模式， 将 涉及诸如客户端及其操作的序列号变化、超时检测等问题，对此应该如何定义E2E机制？ 在TSN网络中Follow_Up报文 每次 经过交换机后都会更新其内容，此时的E2E机制又应该做何种变化？ 1.3关于E2E与SecOC 除了E2E保护机制外，AUTOSAR还 定义 了针对PDU（Protocol Data Unit）的 保护策略 ， 即 SecOC（Secure Onboard Communication）。 关于SecOC更多细节后续将有专门文章介绍，先对SecOC与E2E两者 进行 简要对比如下 图3 ，供大家参考。 图3 SecOC与E2E 简要 对比图 2 .E2E的机制 介绍 E2E策略的整体思路是 CRC校验 和计数 ，在 原始数据的基础上增加控制 段 形成E2E报头 ，AUTOSAR提供了多种E2E的配置来适用各种场景，本文以E2E Profile 1这种配置为例来说明。 图 4 E2E报头 在E2E Profile 1中， 发送到RTE的数据需要包含3个部分：4个bit的Counter，1个字节的CRC 以及需要被保护的原 数据。其中Counter为计数器，每发送一次值就增加 ；CRC按照E2E Profile 1的计算方式， 对Data ID、Counter和 原数据 进行CRC计算，并将结果填入CRC字节 ： 图 5 E2E Profile 1配置 示意图 Data ID是一个预先定义的 密钥 ，不会被发送到总线上。 整个E2E的过程为： 1. SW-C 生成原 数据 2. 将Counter 和原 数据组成待 校验数据 3. 使用Data ID进行CRC的校验 4. 将原 数据、Counter和CRC值发送给RTE 5. 经过诸如总线通信等路径 ，原 数据、Counter和CRC传递到目标RTE 6. 将接收的数据拆包，校验Counter和CRC 7. 目标SW-C接收到原数据 图 6 E2E流程示例 当然，与数据发送方相比，数据接收方需要处理的内容就显得更加复杂。包含 序列丢失 处理、 序列无效 处理、 序列重复处理 、超时处理 等 。 图 7 E2E接收行为示例 E2E本身有很大的灵活性，除了本文示例外 （本文示例使用了E2E Protection Wrapper） ，还 有多种 使用 方式 （比如COM E2E Callouts） ， 感兴趣的小伙伴 可以参考AUTOSAR规范。 3 .E2E测试实践 对于网络中的ECU而言，E2E测试包含E2E发送测试和E2E接收测试。 典型的 E2E发送测试 是将ECU发送的包含E2E信息的数据源按照E2E Profile 1 的 方式，计算 一个CRC，如果与原始发送的CRC相等则验证通过，反之亦然 。 E2E接收测试 包括正向和逆向测试，逆向测试 主要是验证ECU在接收到错误的E2E时的行为 （ 如丢弃该数据信息，记录E2E错误DTC等 ）以及再次接收到正确E2E时的行为测试 ，此类测试需软件层面的支持，比如定义相关的DTC方可实现黑盒测试，或提供相关的内部数据的访问 接口和 方法，或与功能测试相结合，总之依赖特定的条件 。 本文 将 主要介绍E2E发送测试。 以CAN总线为例，当接收到总线上发送的一帧包含E2E信息的报文时，首先获取该E2E对应的 所有 信号的值 ，然后将信号组成数据位流进行CRC计算，在这个过程需要注意以下几点： 信号 的 打包 信号排序 方式 （取决于OEM需求） 信号位置 的 排序 规则 （取决于OEM需求），本例 中的规则在 ARXML 中 做了 属性 定义 ，包括 CRC信号和Counter信号位置 。 图8 信号位置的排序规则在 ARXML 中 的 属性定义 根据 属性定义和计算规则 ， 可 得到待校验的数据为 04 00 00 01 00 00 01 81 04 h ； 然后， 在 ARXML 中获取该E2E的DATA ID=34；最后，使用AUTOSAR_SWS_E2ELibrary 定义的 算法，计算得到CRC的值为0xE6 ，与发送的CRC一致，则该E2E发送是正确的。 根据上面的描述 ， 可以 了解E2E验证的具体过程 。 但是，当网络中有多个ECU，每个ECU又有多个E2E时，手动测试验证显然不是明智之举 。那么，如何进行自动化测试呢？首先需要解决以下技术难点： E2E测试对象的提取 在 ARXML 文件中定义了ECU的E2E发送和E2E接收集合，其中包含了每个E2E的详细信息， 可以 查 询该E2E原型对应的真实载体。为此，我们专门开发了 ARXML 文件解析软件，通过软件来 提取 E2E 测试对象。 图 9 ARXML 文件E2E信息 数据库兼容性问题 E2E 属性 信息是在 ARXML 中定义的， 为了实现 测试 环境的仿真 ， 可能需 加载DBC、LDF、FIBEX 等不同格式 通信 数据库 。 此时， 不同数据库之间信号名称的一致性问题就突显出来。为此， 开发了“位流” 的 解析 方案 ，解决 了 数据库的兼容问题。 技术难点已被攻克，自动化测试 不再是难事。我们基于Vector 的 CANoe软件，开发了一套自动化在线测试脚本， 已经 支持 了 CAN、 LIN、 CAN FD、FlexRay 总线E2E测试 。 图 1 0 CANoe E2E测试工程 和自动生成报告 自动化在线测试有很多优点，比如可以实时监控ECU 报文发送状态，可以模拟故障注入等场景. 但是，在线测试也有无法解决的场景： 并行分析，发现潜在的或偶发的问题 针对OEM而言，ECU尚未交样的情况提前验证，或同时交样时多样件同时测试时的资源占用问题 针对 以上问题 ，我们专门开发了一套完整的 离线测试软件工具链， 通过 ECU通信的 log数据或者实车GL 记录仪存储的log数据，就可以完成E2E离线测试 ，过程如下。 图 1 1 E2E离线测试流程 E2E测试对象的提取 通过 ARXML 文件解析软件，提取出E2E测试对象，作为E2E测试的输入文件。 Log文件解析和通道映射 该离线工具支持CAN、CAN FD、LIN、FlexRay等报文的解析， 可 实现对BLF文件的解析 ，同时 支持多总线多ECU同时测试，根据实车记录的 数据，在软件中进行通道和总线的映射，实现一次性测试。 图 1 2 E2E离线 测试配置 测试执行 导入E2E测试对象文件、通道映射文件和实车BLF log文件，执行测试。该离线软件支持高并发处理，1GB的log数据可在几分钟内完成测试 图 1 3 E2E离线 测试执行及测试结果分析 测试结果分析 从测试执行结果分析，该ECU有两个E2E计算错误， 经分析 为DATA ID配置错误； 1个E2E对应的报文未发送， 定位 为Com层问题； 1个E2E对应的信号组的Update Bit始终未置1 ， 与功能触发有关 引起 。 5 .总结 道路千万条，安全第一条。 AUTOSAR所定义的 安全 机制较容易落地，目前在国内主流OEM中已经得到了应用，北汇也有幸参与其中。 愿与各位共同努力， 分享经验，提供专业的网络安全测试解决方案 。 注：文中部分图片来源于AUTOSAR 参考文献 AUTOSAR_SWS_E2ELibrary AUTOSAR_SWS_SecureOnboardCommunication