基于AUTOSAR标准的E2E保护

方晓颖

（同济大学 201804）

0 引言

AUTOSAR（Automotive Open System Architecture）标准是汽车电子系统开发的新理念。基于AUTOSAR 标准的汽车电子系统开发实现了应用软件设计与底层硬件的分离，是汽车电子嵌入式系统发展的趋势。ISO26262 是汽车功能安全的新标准，包括了安全周期、汽车安全集成等级（ASIL）以及安全需求规范等核心概念[1]。为了支持功能安全，AUTOSAR 标准结合ISO26262功能安全标准，在基础软件层从安全执行、安全通讯以及安全内建测试三方面做了规范。其中，安全通信包括两个方面，ECU 内部通讯和ECU 之间的通信。AUTOSAR 对于安全通信提供了三种机制，数据顺序控制、PDU 复制和K/N 的投票机制以及端到端（End to End，简称E2E）的保护机制。本文针对ECU 内部数据元素层面的E2E 保护，重点阐述其保护机制、使用限制、E2E结构1（E2E profile1）以及基于E2E 保护包的E2E 库实现方式。

1 E2E 保护

“E2E 保护”是指对安全相关的数据在交互过程中进行保护以防止通讯故障造成的影响。

E2E 的保护机制借助于端到端保护库（E2E 库）来实现。比如，随机性的硬件故障，由于EMC 造成的CAN 收发器故障，或者诸如RTE、IOC、COM 以及网络堆栈等VFB 软件通讯故障。

1.1 E2E 库功能

E2E 库是基于其内部功能行为开发的，具体体现在通讯保护机制以及E2E 结构上。

1.1.1 通讯保护

图1 E2E 配置结构体

图2 Comspec 设置

通讯保护机制的重要意义之一是它对于不同目的标准化和灵活性，这可以通过配置E2E 结构中函数调用参数来解决。有些E2E 结构有标准的变量。每个E2E 变量是E2E 结构提供的一组配置选项。比如，在E2E 结构1 中，CRC 和Counter 的位置是可以配置的。E2E 变量1A 指定了CRC 的起始位是bit0，Counter 的起始位是bit8。除了E2E 结构外，E2E 库还提供基本的功能（比如多字节CRC）来建立的安全协议。

发送：对于传输的数据，有CRC 或Counter 这样的额外控制域。

接收：从接收的数据中评估和计算控制域，比如计算接收数据的CRC，与收到的值做比较。

图3 E2E_Comspec 模块封装

每种E2E 结构有特定的控制区域设置，包括特定的功能行为和用于监测通讯故障的特定属性。

1.1.2 E2E 结构

E2E 结构提供了一系列数据保护的机制，用于对故障模型中考虑进去的故障的保护。每一种E2E 结构通过不同的算法，提供了一种可选的方式来保护通讯。然而每种E2E 结构几乎都有确定的API。每种E2E 结构必须使用如下保护机制集合。

（1）CRC，由CRC 库提供。

（2）序列计数器（Sequence Counter）每次根据传输需求增加，由接收方检查增加数值的正确性。

（3）存活计数器（alive Counter）每个根据传输需求增加，接收方仅检查数值是否改变，但不检查是否改变正确。

（4）通过同一端口的数据元素有指定ID。每一组I-PDU 有一个指定ID。

（5）超时监测：接收通信通讯超时；发送确认超时。

（6）本文使用比较常用的E2E 结构1 及其变量1A 来进行数据保护开发。

2 应用层E2E 库使用

为了合理使用E2E 库，该库的获取方案有多种。这些方案的选择取决于RTE、COM 软件及底层其余软件单元的集成方式。所以使用者有责任选择合适的使用方式来实现安全相关系统的需求。

2.1 E2E 库的实现方式

E2E 库可以由以下不同方式来实现。

（1）E2E 保护包——无标准的集成软件来保护数据，用于RTE 之上，即应用层。

（2）COM callouts——无标准的集成代码来保护I-PDUs

（3）以上混合使用。

（4）RTE 层的Out-of-box 保护。

2.2 基于E2E 保护包的E2E 库使用

本文运用E2E 保护包来实现E2E 库的调用。E2E 保护包的功能由Rte_Write 和Rte_read 实现，并提供给应用层。应用层软件需要包含了E2EPW_xxx.h（xxx 为运行体名）。E2EPW_xxx.h 和E2EPW_xxx.c 即E2Ewapper 代码，属于RTE 接口代码的一部分，通过RTE 配置后，存在于RTE 代码生成过程。RTE_xxx.h 包含了运行体RTE 实现相关的声明和宏定义，同样在RTE 代码生成过程中产生。如果RTE 配置中建立某一运行体的实例，则RTE 代码包含相应的RTE_xxx.h 和RTE_xxx_Type.h。其余E2E_P01.h 和E2E.h 由底层软件供应商提供。本文研究对象为TGI 软件组件。首先，定义E2E 配置结构体（Config）。该配置结构体需要应用层和底层共同确认，根据变量1A 的规则。原则上该配置应该由底层软件完成。但在SystemDesk 也有实践，完成之后生成描述文件如图1所示。

其次，在SystemDesk 中建立软件组件TGI，除内部行为外，重点通过添加Comspec 对需要E2E 保护的数据进行端口属性配置：依次关联相应的接口，并设UseEndtoEndProtection属性为on，在IniValueRef 中设置初始值。软件组件设计完后，从SystemDesk 中导出描述文件，并导入TargetLink。比如，对于供型端口的设置及Comspec 在DD 中体现如图2。对于需型端口也做同样设置。

图4 接收端保护机制

接着，在TargetLink 中生成框架模型TGI.slx，添加TL AR Utilities 中“E2E 库”，进行端口配置和调试。如果调试成功，E2E_Comspec 模块将封装成如图3，不仅对需要进行保护的端口承载信号打包，同时生成status 信号。

最后，生成TGI.slx 的AUTOSAR 代码。以接收端为例，在TGI.c 中如预期生成了E2E 保护包的调用函数E2EPW_Read_C2L_E2e_L2_In(TGI_E2e_L2_In_t＊ E2ESignal)。而在E2EPW_TGI.c 中如期生成RTE 数据更新状态返回值Rte_Read_C2L_L2_E2e_L2_In(E2ESignal)。

以接收端为例，其保护机制和调用关系如图4所示。

（1）应用层激活E2EPW_Read_

_(&dataEI)（ 即E2EPW_Read_C2L_E2e_L2_In(TGI_E2e_L2_In_t＊ E2ESignal)）。

（2）E2EPW激活RTE读取接口Rte_Read__(&DataEl)（即Rte_Read_C2L_L2_E2e_L2_In(E2ESignal)），获取最新的数据元素。

（3）如果获取最新元素成功，Rte_Read 返回没有错误。

（4）调用E2E 库中E2E_P01Check(&Config, &State, &Data)。

（5）E2E 库计算CRC，完成检查：E2E 库激活CRC 库若干次来计算数据和数据ID 的CRC，并检查CRC、计数器、最新数据元素，最后根据检查结果，更新State。

（6）更新状态值State->Status。

（7）评估接收到的数据元素是否可信，或者触发错误后处理。

3 结论

目前，E2E 保护仍处于研发阶段。作为AUTOSAR 提供的ISO26262 标准中安全通讯保护的实现方式，其研发成果不仅可以用于ECU 内部数据元素的保护，还能用于整车CAN 通讯的保护。