导语：近期项目中遇到一些E2E的诊断故障，涉及到整车需求和AutoSAR配置，对这个概念重新做了下梳理，与大家交流。由于E2E机制比较成熟，本文章内容更多出自于AutoSAR标准、ISO 26262 和相关文献，这里只捡重点和个例对这个概念做下解读。
1. 什么是E2E？
2. 为什么要做E2E？
3. 怎么做E2E？
4. 常用的保护形式有哪些?
5. E2E状态机与配置参数
1. 什么是E2E？
首先明确一点，E2E并非只是在汽车领域应用，任何通信领域都会涉及，只不过是AutoSAR对这一协议/机制做了规范。
E2E，全称End to End，中文即端到端的通信保护，是一种针对安全相关数据，为防止通信链路中可能存在的故障（HW/SW）， 在 通信节点 之间 执行的 一种数据保护协议/机制。其适用于多种网络结构：CAN、 CANFD、FlexRay、Ethernet等。
具体，如下图所示,假设有两个ECU： ECU1和ECU2，两节点之间通过CAN总线通信，ECU1要将某一安全信号传输至ECU2，如果采用E2E profile1保护协议（AutoSAR E2E Library），ECU1在对必要信息数据做传递之外，还要补充CRC和Counter信息给至ECU2，ECU2在接收到这帧数据后，会计算CRC，然后与接收到的进行比较，ECU2会根据校验结果执行下一步动作（这就涉及到故障的处理，之前有做过简要概述，可参见文章《 电动汽车动力系统的"望闻问切" | 故障诊断 》）。
不知道是否注意到，所谓的E2E其实是对两个关键对行为的保护：发送端（sender）和接收端（receiver）。标准中定义如下：
E2E所涉及的所有保护机制都围绕这两个行为展开的。
2. 为什么要做E2E？
通过上述简介，可以get到，E2E保护概念的核心是针对安全相关的数据交换，需要在运行时进行保护，以消除通信链路中可能的失效带来的影响，这就是为什么要做E2E的本质原因。另外，E2E也是汽车动力系统实现ASIL D的必要手段。
那么，数据交换过程中可能的失效模式 有哪些呢？关于这个问题ISO26262 中有总结，如下:
● 信息的重复发送 (Repetition of Information)，相同的信息被收到了多次
● 信息的丢失 (Loss of Information)，整条或者信息的一部分在通信过程中丢失
● 信息的延迟 (Delay of Information)，接收信息的时间异于期望的时间
● 信息的插入 (Insertion of Information)，多余的内容被插入到信息中
● 假冒的或者不正确的寻址 (Masquerade or Incorrect Addressing of Information)，假冒的发送者发送未认证的信息被接收端接受，或者正确的信息被错误的接收端接受
● 信息顺序错误 (Incorrect Sequence of Information)，数据流中的信息顺序错误
● 信息破损 (Corruption of Information)，信息的内容被篡改
● 向多个接收端发送非对称信息 (Asymmetric information sent from a sender to multiple receivers)，接收端收到的数据不一致
● 仅部分接收端收到发送者的信息 (Information from a sender received by only a subset of receivers
● 阻塞通信通道 (Blocking access to communication channel)
这些失效可能发生的数据交换的场景包括，与I/O外设的通信，基于数据总线的通信等等。产生失效的原因包括系统性失效与随机失效，在软件端面，如生成代码过程中的错误，手动编码引入的错误，网络协议栈的错误等等；硬件端面，如处理器的故障，网络硬件的故障，电磁辐射等等。
3. 怎么做E2E?
AutoSAR中有对E2E Library 的定义，其中提供了多种用于E2E保护的函数供选择，每种profile都有自己特定的机制、参数和数据格式，用户可以根据需求选择。无论何种profile，基本可分为以下两步骤：
Step1： 发送端通过增加控制字段拓展数据结构，控制字段一般包含：checksum、counter等，扩展处的字段由RTE进行发送，如下图所示：
Step2： 接收端对上述整个字段内的数据进行验证，如果pass，则移除其中控制字段，并将应用数据交给SWCs处理；如果no pass，则执行安全保护机制。
那么，在具体对profile做配置时，常用的保护保护形式有哪些呢?
4. 常用的保护形式有哪些呢？
这里对profile中提到的一些保护机制做下解释。
CRC
循环冗余校验，是一种根据网络数据包或文件等数据简短固定位数校核码的快速算法，主要用来检测或校验数据传输或保存后，可能出现的错误，利用除法及余数的原理。
此外，ISO26262-5 中明确说明CRC的覆盖率主要取决于报文长度、CRC字段大小和多项式形式，详情可参见ISO26262文档。
特别说明，我们习惯说“CRC checksum校验”，其实这里涉及两种校验方法。
Checksum
顾名思义，和的校验，在数据处理和数据通信领域中，用于校验目的的一组数据项的和，这些数据项目可以是数字或在计算校验总和过程中看作数字的其他字符串，其类型有多种：XOR checksum, 1's complement Checksum, 2's complement Checksum等。
Counter
在报文中占4bit，范围0~14 (profile1)，用于计数，发送端每发送一帧报文，计数+1，ECU1将计数值发给ECU2，ECU2对收到的counter进行比较，确认是否及时接收，当达到14，重新开始计数。
Timeout
通过counter来评估报文是否丢失、延迟等。
Data ID
一般为2个byte，是ECU1和ECU2之间提前定好的特殊字段，AutoSAR profile1中对E2E_P01DataIDMode定义几种模式：BOTH、ALT、LOW、NIBBLE，Data ID用于报文checksum，但是特别注意的是这一段DID并不作为报文传输数据的一部分放在总线上，仅仅作为报文密钥，这就好比特务接头，开始聊正文之前，总要私下先确认好暗号，以证明“我接收的指令确实是期待的发送方所发送的”。
特别说明下增加Data ID字段的报文如何计算checksum：
例如，Autosar E2E profile 1 规定采用CRC-8-SAE J1850 ，对应多项式为0x1D (x8 + x4 + x3 + x2 + 1)，通常情况下报文数据场中Byte0 用于存放报文CheckSum 数据，byte 1~byte7 存放报文其它数据，报文数据场存放数据下图所示。
具体步骤如下。
Step1：计算Data ID字段内CRC值 （注：实际初始值为初始值取反）。
Step2：计算Byte1~Byte7字段内CRC值（注：实际初始值为上一步校验值取反）。
Step3： 将上一步校验值取反，得到最终值。
以下是AutoSAR中针对profile1保护机制的原始定义，供参考：
5. E2E状态机与配置参数
E2E数据的接收是周期性的，接收方在每个周期内，调用对应的profile的检测接口，针对接收到的数据进行检测，验证这个周期内接收到的数据是正确的，并提供额外信息说明检测到的失效形式。下图给出了状态及迁移的说明，从中可以看到数据是否有用是根据窗口期内error数和ok数来做判断。
那么，E2E保护需要的配置参数有哪些呢？
以AUTOSAR E2E Protocol Specification1.3.0 为例，目前E2E中系统支持配置的设置信息如下图所示：
以上就是对E2E概念和保护逻辑做的简要介绍，它是汽车动力总成实现ASIL D的必经之路，更多内容大家感兴趣可以直接查看标准《AutoSAR E2E Protocol Specification》。
【Reference】
《AutoSAR E2E Protocol Specification》
《ISO 26262 - "Road vehicles - Functional safety"》
最后做个统计，臭皮匠试验室暂定年底前举办一次培训交流会，形式待定，培训主题： 电动汽车三合一电驱动系统标准解读与试验开发。 具体暂定以下几方面内容：
1）结合项目经验，从整车需求角度，对三合一系统试验标准进行梳理，建立试验标准思维导图；
2）理解FMEA与试验的关联性；
3）讲解项目开发不同阶段下的试验如何分布；
4)路谱的采集与转化，以及对三合一系统和部件的影响；
5）对系统疲劳耐久、环境适应性、高低压电气负荷适应性中的关键点、难点做解读。
详细交流会信息后续会正式推送给大家。感兴趣的可以私信。
最后，感谢大家一直以来的支持，感谢有你！