汽车人眼中的网络安全关于AUTOSAR E2E及测试开发实践Word文件下载.docx

汽车人眼中的网络安全关于AUTOSAR E2E及测试开发实践Word文件下载.docx

《汽车人眼中的网络安全关于AUTOSAR E2E及测试开发实践Word文件下载.docx》由会员分享，可在线阅读，更多相关《汽车人眼中的网络安全关于AUTOSAR E2E及测试开发实践Word文件下载.docx（8页珍藏版）》请在冰豆网上搜索。

答案是否定的。

在AUTOSAR的架构中，最上层为包含SW-C（SoftwareComponent）的应用层，类似于手机应用程序中的各种APP。

对于E2E来说，数据的传递不是针对ECU到ECU的层级而是SW-C到SW-C层级。

图1AUTOSAR软件概貌

在车载网络中，信息交换通常是从一个ECU发送信号，另一个ECU接收信号。

对E2E而言，通常是从源SW-C生成信号，经过RTE（Run-TimeEnvironment）、BSW（BasicSoftware）并在物理总线上传输后到达目标SW-C。

在这个过程中，信号的传递可能由于一些故障情况（比如软件运行错误）无法到达目标终端，或是信号本身被干扰/损坏，尤其对于安全相关的信号（车速、档位、车辆/电源模式等）来说，这种情况会带来很大的隐患。

而E2E正是通过一些机制，使发送终端和接收终端的数据保持一致，保证信息的完整性。

图2错误来源的示意

2.2E2E的适用范围

E2E可适用于各种总线通信，以北汇信息参与的项目为例，E2E机制已应用于CAN、CANFD、LIN、FlexRay总线通信中，对于以太网当然可应用E2E机制，但是需考虑和留意如下的问题：

不同于上文介绍的发送端/接收端的通信模式，以太网中将会广泛应用基于SoA的客户端/服务器的通信模式，将涉及诸如客户端及其操作的序列号变化、超时检测等问题，对此应该如何定义E2E机制？

在TSN网络中Follow_Up报文每次经过交换机后都会更新其内容，此时的E2E机制又应该做何种变化？

2.3关于E2E与SecOC

除了E2E保护机制外，AUTOSAR还定义了针对PDU（ProtocolDataUnit）的保护策略，即SecOC（SecureOnboardCommunication）。

关于SecOC更多细节后续将有专门文章介绍，先对SecOC与E2E两者进行简要对比如下图3，供大家参考。

图3SecOC与E2E简要对比图

3.E2E的机制介绍

E2E策略的整体思路是CRC校验和计数，在原始数据的基础上增加控制段形成E2E报头，AUTOSAR提供了多种E2E的配置来适用各种场景，本文以E2EProfile1这种配置为例来说明。

图4E2E报头

在E2EProfile1中，发送到RTE的数据需要包含3个部分：

4个bit的Counter，1个字节的CRC以及需要被保护的原数据。

其中Counter为计数器，每发送一次值就增加；

CRC按照E2EProfile1的计算方式，对DataID、Counter和原数据进行CRC计算，并将结果填入CRC字节：

图5E2EProfile1配置示意图

DataID是一个预先定义的密钥，不会被发送到总线上。

整个E2E的过程为：

1.SW-C生成原数据

2.将Counter和原数据组成待校验数据

3.使用DataID进行CRC的校验

4.将原数据、Counter和CRC值发送给RTE

5.经过诸如总线通信等路径，原数据、Counter和CRC传递到目标RTE

6.将接收的数据拆包，校验Counter和CRC

7.目标SW-C接收到原数据

图6E2E流程示例

当然，与数据发送方相比，数据接收方需要处理的内容就显得更加复杂。

包含序列丢失处理、序列无效处理、序列重复处理、超时处理等。

图7E2E接收行为示例

E2E本身有很大的灵活性，除了本文示例外（本文示例使用了E2EProtectionWrapper），还有多种使用方式（比如COME2ECallouts），感兴趣的小伙伴可以参考AUTOSAR规范。

4.E2E测试实践

对于网络中的ECU而言，E2E测试包含E2E发送测试和E2E接收测试。

典型的E2E发送测试是将ECU发送的包含E2E信息的数据源按照E2EProfile1的方式，计算一个CRC，如果与原始发送的CRC相等则验证通过，反之亦然。

E2E接收测试包括正向和逆向测试，逆向测试主要是验证ECU在接收到错误的E2E时的行为（如丢弃该数据信息，记录E2E错误DTC等）以及再次接收到正确E2E时的行为测试，此类测试需软件层面的支持，比如定义相关的DTC方可实现黑盒测试，或提供相关的内部数据的访问接口和方法，或与功能测试相结合，总之依赖特定的条件。

本文将主要介绍E2E发送测试。

以CAN总线为例，当接收到总线上发送的一帧包含E2E信息的报文时，首先获取该E2E对应的所有信号的值，然后将信号组成数据位流进行CRC计算，在这个过程需要注意以下几点：

1.信号的打包

2.信号排序方式（取决于OEM需求）

3.信号位置的排序规则（取决于OEM需求），本例中的规则在ARXML中做了属性定义，包括CRC信号和Counter信号位置。

图8信号位置的排序规则在ARXML中的属性定义

根据属性定义和计算规则，可得到待校验的数据为040000010000018104h；

然后，在ARXML中获取该E2E的DATAID=34；

最后，使用AUTOSAR_SWS_E2ELibrary定义的算法，计算得到CRC的值为0xE6，与发送的CRC一致，则该E2E发送是正确的。

根据上面的描述，可以了解E2E验证的具体过程。

但是，当网络中有多个ECU，每个ECU又有多个E2E时，手动测试验证显然不是明智之举。

那么，如何进行自动化测试呢？

首先需要解决以下技术难点：

●E2E测试对象的提取

在ARXML文件中定义了ECU的E2E发送和E2E接收集合，其中包含了每个E2E的详细信息，可以查询该E2E原型对应的真实载体。

为此，我们专门开发了ARXML文件解析软件，通过软件来提取E2E测试对象。

图9ARXML文件E2E信息

●数据库兼容性问题

E2E属性信息是在ARXML中定义的，为了实现测试环境的仿真，可能需加载DBC、LDF、FIBEX等不同格式通信数据库。

此时，不同数据库之间信号名称的一致性问题就突显出来。

为此，开发了“位流”的解析方案，解决了数据库的兼容问题。

技术难点已被攻克，自动化测试不再是难事。

我们基于CANoe软件，开发了一套自动化在线测试脚本，已经支持了CAN、LIN、CANFD、FlexRay总线E2E测试。

图10CANoeE2E测试工程和自动生成报告

自动化在线测试有很多优点，比如可以实时监控ECU报文发送状态，可以模拟故障注入等场景.

但是，在线测试也有无法解决的场景：

●并行分析，发现潜在的或偶发的问题

针对OEM而言，ECU尚未交样的情况提前验证，或同时交样时多样件同时测试时的资源占用问题

针对以上问题，我们专门开发了一套完整的离线测试软件工具链，通过ECU通信的log数据或者实车GL记录仪存储的log数据，就可以完成E2E离线测试，过程如下。

图11E2E离线测试流程

通过ARXML

文件解析软件，提取出E2E测试对象，作为E2E测试的输入文件。

●Log文件解析和通道映射

该离线工具支持CAN、CANFD、LIN、FlexRay等报文的解析，可实现对BLF文件的解析，同时支持多总线多ECU同时测试，根据实车记录的数据，在软件中进行通道和总线的映射，实现一次性测试。

图12E2E离线测试配置

●测试执行

导入E2E测试对象文件、通道映射文件和实车BLFlog文件，执行测试。

该离线软件支持高并发处理，1GB的log数据可在几分钟内完成测试

图13E2E离线测试执行及测试结果分析

●测试结果分析

从测试执行结果分析，该ECU有两个E2E计算错误，经分析为DATAID配置错误；

1个E2E对应的报文未发送，定位为Com层问题；

1个E2E对应的信号组的UpdateBit始终未置1，与功能触发有关引起。

5.总结

道路千万条，安全第一条。

AUTOSAR所定义的安全机制较容易落地，目前在国内主流OEM中已经得到了应用，北汇也有幸参与其中。

愿与各位共同努力，分享经验，提供专业的网络安全测试解决方案。

注：

文中部分图片来源于AUTOSAR

参考文献

[1]AUTOSAR_SWS_E2ELibrary

[2]AUTOSAR_SWS_SecureOnboardCommunication