E2E通信保护协议学习笔记
最近在做功能安全方面工作，想了解E2E保护的问题。本文试着说明两个点：
功能安全需要考虑通信失效造成的影响，因此E2E通信保护协议被提出，以满足功能安全要求；
简单介绍E2E通信保护协议机制。
如果系统的功能安全依赖于数据的完整性，那么发送方(Sender)和接收方(Receiver)之间的数据交换就可以对系统的功能安全造成影响。根据ISO 26262 Part 6的 附录D：信息交换章节，对于信息交换的接收方或发送方，一般需要考虑以下失效模式：
引自[1]
这里，对上述的这些失效模式稍作解释：
信息重复：多次收到同一条信息；
信息丢失：传输的信息流中，信息或部分信息被移除；
信息延迟：信息接收比预期晚；
信息插入：传输的信息流中，额外信息被插入；
伪装：非真实信息被接收方接收为真实信息；
不正确寻址：接收了不正确的发送方的信息或被不正确的接收方接收了信息；
信息序列不正确：修改了传输的信息流中的信息序列；
信息损坏：改变信息;
从发送方发送到多个接收方的非对称信息：接收方从同一发送方接收到了不同信息；
来自发送方的信息仅由一部分接收方接收：有些接收方没有接收到信息；
阻塞访问通信通道：通信通道的访问被阻塞。
这些失效一般由软件故障，随机硬件故障和瞬态故障引起。
软件故障：像通信栈模块，RTE等软件可能存在故障，而这些故障是系统性的，可能发生在系统生命周期的规范，设计，制造，运行和维护的任一阶段，并且在情况（例如根本原因的触发条件）相同时，它们总会出现，其后果可能导致通信失败，比如发送数据中断，接收器溢出等故障。
随机硬件故障：通常是电气过载、退化、老化的结果或暴露于硬件部件的外部影响（例如环境压力）。随机硬件故障无法完全避免，但可以评估其概率并且可以实施适当的技术措施（比如诊断）。
瞬态故障：由外部影响或环境应力引起，包括EMI、ESD、湿度、腐蚀、温度或机械应力（比如振动）等影响。
对应基于AUTOSAR架构的通讯部分，上述的故障表现如下示意：
引自[4]
上图包括软硬件导致的通信失效，其中硬件导致的通信失效有：
H1：通信的物理网络存在故障；
H2：是通信网络的接口存在电磁兼容性问题；
H3：微控制器故障，例如上下文切换时寄存器失效等
软件导致的通讯失效有：
S1: RTE生成代码出错
S2: COM服务层代码出错；
S3: 通信接口层和通信的驱动层之间可能存在问题;
H3：微控制器故障，例如上下文切换时寄存器失效等.
针对这些通讯失效，在AUTOSAR中就提出了E2E通信保护协议，即在系统运行过程中，动态地识别软硬件故障引起通信失效，保证ECU之间以及ECU内部不同核之间，不同SWC 之间数据的安全通信。
引自[2]
基于E2E需求，E2E通信保护协议采用结合CRC（循环冗余校验），Counter（计数器），Timeout monitoring（超时监控）和Data ID来实现，如下所示：
| E2E保护机制 | 检测出的失效模式 |
|---|---|
| Counter | 信息的重复，丢失，插入，不正确的序列，阻塞 |
| Time monitoring | 信息的丢失，延迟，阻塞 |
| Data ID + CRC | 信息的伪装，不正确寻址，插入 |
| CRC | 信息的损坏，不对称 |
具体这些机制是如何能够检测出对应的失效呢？
考虑到E2E通信保护协议需要涵盖各种大小的交换数据和不同类型的物理总线介质。因此就创建了多种E2E profiles（配置文件），即每个profiles包括一组保护机制，如下所示：
引自[3]
在[3] E2E Protocol Specification 中可以详细了解到8中E2E profiles 1，2，4，5，6，7，11，22的定义。这些E2E profiles是根据ISO26262开发，用于与安全相关的项目，没有特定于某控制器，可以满足ASIL D需求的安全相关通信（之前思考一个问题：对于不同ASIL等级，需要采用哪种E2E profiles，我觉得都可以，因为每种E2E profiles都满足ASIL D等级，就看各家如何选取，谁有补充么？）。
以E2E profiles 2为例，它包含3个保护方式：分别是循环冗余校验，计数器和数据ID，如下：
引自[3]
这四种E2E机制可检测出的失效如下：
引自[3]
这套机制是如何运行呢？借助[7]解释如下：
[7]: 通过E2E Profile 2处理后的数据 Buffer分布如下所示。E2E Profile 2规定Data[0]必须存放CRC校验和，Data[1]的低4个位必须存放Sequence Counter。从Data[2]开始存放需要保护的数据。
[7]: 其中参与CRC校验和计算的字段可以根据用户配置而定， 我们采用的是下图的方式，校验和包含Data ID部分和排除 CRC存储字段外的所有的数据，虽然Data ID并没有显性的通过报文发送出去，但是它的校验信息包含在CRC中，其中需要填充的部分统一填充为0xF。
[7]: 采用E2E Profile 2安全通信需要 额外的引入两个数据元素，分别是 Sequence Counter与 CRC校验和，它们 必须随着被保护数据一起从发送端传送到接收端。在进行软件组件接口定义的时候必须定义相关的数据元素，尤其是在跨ECU通信中还必须在DBC中预留出相关的信号用于传输Sequence Counter与CRC校验和。
E2E ProfiIe 2的发送端和接收端，分别维护着一个E2E 发送端的状态机和一个E2E接收端的状态机。在发送端， E2E 会根据发送端的状态机，首先计算Sequence Counter并写入数据Buffer，然后根据被保护的数据、静态配置好的数据ID列表以及Sequence counter，计算CRC校验和，并写入发送 Buffer。完成上述操作后，E2E就返回数据Buffer给调用者， 最终由调用者将CRC校验和、Sequence Counter与被保护的数据一起发送出去。被保护的数据并不会被E2E改变， E2E并不负责加密。
在接收端，E2E根据接收端状态机先计算出预期的Sequence Counter，再根据静态配置好的数据ID列表、Sequence Counter和接收到的数据，计算出CRC校验和。这里，接收到的数据仅仅指发送端发送的需要被保护的数据。
计算出CRC校验和后，E2E会与发送端发过来的CRC校验和进行比较，如果一致，则继续判断Sequence Counter是否与期望的Sequence Counter一致。 如果校验结果完全正确或者在容忍的范围内，则E2E Profile 2返回正确的返回值；如果校验结果有问题， 则需要进一步解析出错的类型，并将错误状态更新到E2E的状态机。
E2E只做数据准确性的校验，至于出现数据丢失或者重复，应用层是否采用此数据，那是应用层数据访问的策略，与E2E无关。
为什么根据CRC，Counter，ID可以检测出相应的通讯失效？
AUTOSAR是怎么实现E2E通信保护协议机制？
待理解更深入，能更通俗易懂地更新本文，比如失效模式的详细解释。
。。。。。。
CRC（Cyclic Redundancy Check），即循环冗余检验，是基于数据计算一组校验码码，用于核对数据传输过程中是否被更改或传输错误。假设有一组原始数据：1101011011，如何获取其CRC？见下图右方：
第1步：选取CRC算法，即生成多项式，也就是E2E profiles就采用了CRC-8，CRC-16, CRC-32。像E2E profile 1采用x8 + x4 + x3 + x2 + 1，即1 0001 1101。此处选用4位CRC算法，x4 + x1 + 1，即1 0011。
第2步：因此选用4位CRC算法，1 0011，注意宽度是4位，不是5位，这时原始数据需要在右边填充4位，0000，后面用来存放4位CRC，变为：1101011011 0000。
第3步，使用XOR运算，计算CRC，过程如下图左方：
第4步：将CRC更新到原始数据的右4位，则数据变为：11010110111110。这个数据将发送给其他控制器。
[1] ISO26262-6: Road vehicles - Functional safety Part 6: Product development at the software level
[2] Requirements on E2E
[3] E2E Protocol Specification
[4] Specification of SW-C End-toEnd Communication Protection Library
[5] Specification of Module E2E Transformer
[6] Specification of CRC Routines
[7] 基于AUTOSAR的点到点安全通信的实现
