最近感觉很累，做项目有很深的无力感。这种状态估计会持续到5月底。好久没更新了。让我们利用假期放松一下，简单谈谈E2E的相关内容。
(一)
在汽车控制器的研发中，控制器之间(或者同一产品的主板和从板之间)的通信是必不可少的。在发送方和接收方的数据交换过程中，如果数据完整性被破坏，正常的通信功能可能会出现问题，从而影响到安全相关的功能。
(二)
在这里，我们来看看与通信相关的故障，以及如何理解这些故障模式。还可以查看ISO-26262标准第5部分-附录D，表D.1 -》D6通信总线或第6部分-附录D，D.2.4信息交换。
信息的重复；-消息收到很多次了吗？
信息丢失；-信息或部分信息是否从传输的信息流中删除？
信息延迟；-收到的信息是否晚于预期？
信息的插入；-传输的信息流中是否插入了附加信息？
伪装或不正确的信息地址；masquerade的不真实信息被接收方认为是真实信息吗？-"不正确的地址信息从错误的发送方或接收方接收信息？
信息顺序不正确；-信息顺序改变了吗？
信息腐败；-信息是否被破坏，从而改变了信息？
从一个发送者发送到多个接收者的不对称信息；-接收方是否从同一发送方收到不对称/不同的信息？
来自发送者的信息仅由接收者的子集接收；or-消息是否只被部分收件人收到？
阻止对通信信道的访问。-通信信道接入是否受阻？
(图片来自Autosar官网文档)
(3) 3)
26262中的通信保护需要使用E2E(端-2-端保护)机制。E2E保护的概念是假设与安全相关的数据交换在运行时应该受到保护，以避免通信链路中故障的影响。此类故障的例子——随机硬件故障(如CAN收发器的寄存器损坏)、干扰(如EMC因素)、ECU内部实现VFB通信的软件(如IOC、RTE、COM、网络栈)的系统故障；当然也有外部故障，比如网关。
这里我们借鉴AUTOSAR对E2E的描述：从软件组装的角度来看，通过RTE传输数据的行为类似于简单的点对点连接。然而，这种抽象的实现需要由应用层、通信栈、驱动程序和底层硬件组成的复杂基础设施。随着复杂性的增加，潜在故障源的数量也在增加。E2E保护机制的使用假设在通信期间必须保持安全相关数据的完整性，以保护数据免受通信链路故障的影响。E2E保护最重要的方面是保护能力的标准化和机制的灵活运用。
(4).
E2E保护的架构实现如下。由应用数据组成的数据元素扩展了发送方的附加控制信息，即E2E报头。控制信息通常包含校验和、计数器和其他选项。扩展数据元素被提供给RTE进行传输，如下图所示。E2E的基本原理得到了论证。通过根据应用数据处理E2E报头的内容，在接收机处验证数据元素。在接收的数据元素被处理并被接受为正确之后，控制信息被移除，并且应用数据被提供给目标软件组件。错误处理是在接收端执行的。
(5)
对于E2E的配置文件，这里仍然借用了AUTOSAR的描述。E2E的配置文件使用以下数据保护机制子集：
1)- CRC校验和，由CRC库提供；
2)-序列计数器在每个传输请求时递增，并检查该值在接收端是否正确递增；
3)-有效计数器对每个传输请求递增。如果它改变了，则在接收端检查该值，但是不检查正确的增量。
4)-特定ID通过端口发送的每个端口数据元素的特定ID(对于系统是全局的，其中系统可以包含多个ECU)；);
5)-超时检测：接收方通信超时，发送方确认超时；
AUTOSAR中有三种E2E配置文件(配置1有两种变体)。
注意：通常，只应用标准配置文件。非标准E2E配置文件只能用于特殊情况，如遗留软件。
让我们来看看每个配置文件的保护机制：
注：E2E Profile 4是专为符合ASIL-D标准的长数据传输而设计的。
这篇文章主要是关于E2E可以保护哪些错误。至于E2E保护，还涉及到E2E状态机、E2E保护封装、E2E传输管理、RTE数据传输、检测响应等等，这里就不细说了。感兴趣的朋友可以去AUTOSAR官网查看相关信息。
编辑：李倩
