方晓颖

摘要：为了支持功能安全，AUTOSAR标准结合IS026262功能安全标准，在基础软件层从安全通讯等方面做了规范。本文首先介绍了安全通讯机制之一的E2E保护来源，接着从E2E保护机制和E2E库功能两方面进行重点阐述。最后实践说明E2E库在应用层软件的使用方法。

关键词：AUTOSAR;E2E保护

中国分类号：U461.99 文献标识码：A

0引言

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

1E2E保护

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

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

1.1E2E库功能

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

1.1.1通讯保护

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

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

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

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

1.1.2E2E结构

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.1E2E库的实现方式

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。对于需型端口也做同样设置。

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

最后，生成TGI six的AUTOSAR代码。以接收端为例，在TGI.c中如预期生成了E2E保护包的调用函数E2EPWRead_C2L_E2e_L2_In（TGl E2e L2_In_t*E2ESignaI）。而在E2EPW TGI.c中如期生成RTE数据更新状态返回值Rte Read C2L L2E2e L2In（E2ESignaI）。

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

（1）应用层激活E2EPW_Read_

_（&dataEI）（即E2EPW_Read_C2L_E2e_L2_In（TGI_E2e_L2_In_t*E2ESignal））。

（2）E2E PW激活RTE读 取接 口Rfe-Read__（&DataEI）（即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提供的IS026262标准中安全通讯保护的实现方式，其研发成果不仅可以用于ECU内部数据元素的保护，还能用于整车CAN通讯的保护。