圈外人看E2E保护

安全在每个领域都是一个永恒的话题，汽车也不例外，而随着最近几年汽车电动化、智能化和网联化的发展，汽车安全也越来越受到用户及开发人员的重视，安全的要素也是多方面的，例如用户可能关心在使用车机系统时的隐私安全、打开ACC等辅助驾驶功能时的人身安全等；站在攻城狮的角度则会关注和考虑整车E/E架构、硬件以及软件等方面的可靠和安全，比如硬件的EMC和随机故障、软件功能设计及控制器内部和外部的通讯安全等等。每个安全要素作为系统目标的重要组成部分只为保证整车的可靠性和安全性，从而保护用户的人身安全。

对单个控制器的而言，其功能设计要求的实现不仅涉及自身内部功能模块的数据交互，还涉及与其他控制器之间进行数据的传输和通讯，而如何保证数据传输的正确性从而避免非期望的输出和控制呢？针对该问题，方式也有很多，例如我们CAN通讯的Checksum和RollingCounter校验就是一种相对比较简单和粗糙的安全保护措施，还有之前楼主写过的CK和RC的加强版本SecOC等，这次乡下人简单聊下AutoSAR中的E2E保护。

E2E保护介绍

E2E（End-to-End）保护是一种端对端保护机制，举个例子：控制器中某个安全关键性功能模块的输出计算要依赖于内部某个非安全性的模块或其他安全等级要求不高的硬件通过总线传输过来的数据，因安全相关数据可能因通讯故障而丢失或篡改，那么如何保证数据交换的正确性呢？此时就可借助E2E保护。从上面的例子，我们可大体知道，数据传输的链路主要存在如下三种：

1、不同控制器之间的数据传输，例如通过CAN、LIN、以太网、OTA等方式的数据传输。

2、控制器内部ASW与ASW之间的数据传输。

3、控制器内部ASW与BSW之间的数据传输。

E2E保护既可用于控制器内部功能模块之间的数据保护，也可用于不同控制器之间的数据保护

在整个链路里面，会存在硬件和软件相关的两种故障源，如上图所示：

典型的软件相关故障源有如下几种：

S1: 因RTE带来的错误

S2: 因COM自动和手工代码引入的错误

S3 ：网络堆栈错误

S4: 跨核通讯IOC或者OS的错误

硬件相关的故障源则有：

H1：通信网络故障

H2：电磁兼容性导致通信网络的接口故障

H3：微控制器故障，例如上下文切换时寄存器失效等

通过采用 E2E 通信保护机制可以在运行时，实时检测到通信链中出现的错误，E2E 库提供了相关的保护验证机制来保证与功能安全相关的通信。

AutoSAR标准里，采用E2E保护的算法是在E2Elibrary中实现的，调用者要负责该库使用的正确性，AutoSAR E2E可将通过RTE发送的安全相关数据元素加上保护控制流，并校验从RTE接收到的安全相关数据元素是否正确，若存在问题还需报出错误供负责接收的SWC做相应处理。

E2E实现方式

在 AutoSAR标准中，E2E 保护的实现有三种不同方式：

1、 E2E Transformer：这是一种在AutoSAR 4.2.1中首次被提出的全新且标准化的 E2E 实现方式，并这种实现方式下，RTE 会调用 E2E Transformer 的 API，E2E Transformer 的 API 进一步调用E2E Lib 提供的函数库，实现 E2E的保护和校验。所有的函数调用全部封装在 RTE 内部实现，这是标准要求最终实现的目标。

2、采用 E2E Protection Wrapper（E2EPW）：这种在 RTE 之上进行了一次封装，E2EPW负责调用 E2E Lib 提供的函数库，实现 E2E 的保护和校验，并通过RTE 的 API 进行发送和接收。这是一种较为通用的方式，可适用于不同层次软件组件之间的通信，小到同一个核上的 SWC 之间的通信，大到跨 ECU SWC 之间的通信都是适用的，如下图所示。

基于E2EPW方式，如下是进行跨ECU通讯的E2E保护示例图：

3、针对跨 ECU 之间的通信，COM E2E Callout 的 E2E 保护和校验是在基础软件层做的，在这种实现方式下检验的单元是以 PDU 的形式存在的，某一个 PDU 发送或者接收时，会触发该 PDU 的 Callout 函数，在 Callout 函数内部实现 E2E 的保护和校验，例如对于发送方示例如下：

而对于接收方如下：