注：

导致E2E保护检测到错误的典型干扰源：

软件相关源：

S1.大多数生成的RTE中的错误

S2.部分生成和部分手工编码的COM中的错误

S3.网络堆栈错误

S4.生成的IOC或OS错误

硬件相关源：

H1.硬件网络故障

H2.网络电磁干扰

H3.上下文切换（分区）或内核间通信期间的微控制器故障

1 常见的通讯故障以及E2E机制能够检出的通讯故障

E2E机制可以检测以下故障或故障影响：

2 Functional safety功能安全对通信的要求

ISO_26262-6_2018的附录D.2.4对信息交换提出了要求，如下：

关于信息交换，可以为每个发送方或每个接收方考虑如下所列的故障原因或故障影响：

• 信息重复；

• 信息丢失；

• 信息延迟；

• 插入信息；

• 伪装/冒充或不正确的信息寻址；

• 不正确的信息序列；

• 信息损坏；

• 从一个发送者向多个接收者发送的非对称信息；

• 来自发送者的信息仅被一部分接收者接收；

• 阻塞对通信通道的访问。

3 通信故障的原因

常见引起通信故障的原因有：

1.（系统性）软件故障，

2.（随机）硬件故障，

3.外部影响引起的瞬态故障。

这三个来源在下面的部分中进行了描述。

3.1 软件故障

通信栈模块、RTE等软件可能存在系统性故障。

系统性故障可能发生在系统生命周期的任何阶段，包括规范、设计、制造、运行和维护，并且它们总是在情况（例如根本原因的触发条件）相同时出现。软件故障的后果可能是通信失败，例如数据发送中断、接收器溢出（例如缓冲区溢出）或发送器欠载（例如缓冲区为空）。

为了防止（或处理）由此产生的故障，必须考虑适当的技术措施来检测和处理此类故障（例如程序流监控或E2E）。

3.2 随机硬件故障

随机硬件故障通常是硬件部件电气过载、退化、老化或暴露于外部影响（例如环境压力）的结果。随机硬件故障无法完全避免，但可以评估其概率并实施适当的技术措施（例如诊断）。

3.3 外部影响、环境压力

这包括EMI、ESD、湿度、耐腐蚀、温度或机械应力（例如振动）等影响。

4 常见的“E2E通讯保护”解决方案

下面列举的Autosar支持的E2E通讯保护机制解决方案：

1. E2E Protection Wrapper（用于保护数据的非标准集成商软件，在RTE的上层）
2. E2E Transformer（一种新的、标准化的E2E调用方式，在Autosar4.2.1中引入）
3. COM E2E Callout（用于保护I-PDU的非标准集成商代码）

也可能有混合场景，例如：

1.对于特定数据元素，发送方使用E2E Protection Wrapper，接收方使用COM E2E Callout（或反向）

2.在给定的ECU网络或一个ECU中：一些数据元素使用E2E Protection Wrapper，一些使用COM E2E Callout。

无论E2E在何处执行，E2E保护都是针对数据元素的。E2E保护是在数据元素的序列化表示上执行的，其位布局与总线上传输的位布局相同。这意味着：

1. 如果使用E2E Transformer，序列化由E2E Transformer之上的transformer进行（基于COM的transformer或Some/IP的transformer）。
2. 如果使用E2E Protection Wrapper，Wrapper需要将数据元素序列化为对应信号组的序列化形式（换句话说，Wrapper创建了I-PDU的一部分，它代表了信号组和数据元素）。
3. 如果使用COM callout，序列化由通信栈（RTE、COM）完成，因此callout直接对I-PDU中的序列化信号组进行操作。

4.1 无E2E保护的信号数据流示例

发送方ECU示例：

接收方ECU示例：

4.2 E2E Protection Wrapper解决方案示例

发送方ECU示例：

接收方ECU示例：

4.3 E2E Transformer解决方案示例

对于这种方式的保护，需要引入ComXf或SomeIpXf模块。下面以SomeIpXf模块为例。

发送方ECU示例：

接收方ECU示例：

4.3 COM E2E Callout解决方案介绍

在这种方法中，E2E通信保护保护了COM模块之间的数据交换。保护是在COM的信号组级别完成的，由E2E Library进行保护和检查。

该解决方案适用于RTE为ECU间通信提供的所有通信模型和多样性。

回调调用E2E Library，对给定I-PDU中的每个受E2E保护的信号组调用一次。

该方案可用于提供COM和RTE操作完整性的系统。

详见《AUTOSAR_SWS_E2ELibrary（Specification of SW-C End-to-End Communication Protection Library）》。

5 E2E profile介绍

无论是E2E Protection Wrapper，E2E Transformer，COM E2E Callout，这些E2E保护解决方案都少不了调用E2E Library提供的服务。

E2E library是根据ISO 26262开发的，用于与安全相关的项目，没有特定于控制器。E2E Library提供E2E保护机制，足以满足具有高达ASIL D需求的安全相关通信。

AUTOSAR指定了一组灵活的保护机制算法（E2E profile XX）在E2E Library中实现。E2E Library的调用者负责Library的正确使用（特别是为E2E Library routines提供正确的参数）。每个 E2E Profile 都是非生成的、确定性的软件代码，其中所有输入和设置都通过函数参数传递。

E2E不包含任何调度服务，例如主函数。E2E Library不提供任何回调函数。E2E Library不提供任何可配置的接口。

每个指定的E2E profile都有一个固定的行为，但它有一些功能参数的配置选项（例如，CRC相对于要保护的数据的位置）。

每个E2E Profile应使用以下数据保护机制的一个子集：

a.一个CRC，由CRC Library提供；

b.一个Sequence Counter在每次传输请求时递增，接收方检查该值是否正确递增；

c.一个Alive Counter在每次传输请求时递增，接收方检查值是否有变化，但不检查正确的递增值；

d.通过端口发送的每个端口数据元素的特定ID或每个I-PDU组的特定ID（全局到系统，其中系统可能包含潜在的多个ECU）；

e.超时检测：

--接收方通信超时；

--发送方确认超时。

根据使用的通信和网络堆栈，这些机制的适当子集被定义为E2E通信profile。

E2E profile可用于ECU内部和内部通信。E2E profile针对CAN、FlexRay通信进行了优化，并可用于LIN。

5.1 E2E Profile 1机制

Profile 1应提供以下机制：

注意：CRC和Counter在Frame中的位置可以通过各自的Offset确认。

5.2 E2E Profile 2机制

Profile 2应提供以下机制：

注意：CRC和Counter在Frame中的位置可以通过同一个Offset确认。导致CRC和Counter在相邻的Byte中。

5.3 E2E Profile 4机制

Profile 4应提供以下机制：

注意：CRC和Counter在Frame中的位置固定。

5.4 E2E Profile 5机制

Profile 5应提供以下机制：

注意：CRC和Counter在Frame中的位置固定。

5.5 E2E Profile 6机制

Profile 6应提供以下机制：

注意：CRC和Counter在Frame中的位置固定。

5.6 E2E Profile 7机制

Profile 7应提供以下机制：

注意：CRC和Counter在Frame中的位置固定。

5.7 E2E Profile 11机制

Profile 11应提供以下机制：

注意：CRC和Counter在Frame中的位置固定。

5.8 E2E Profile 22机制

Profile 22应提供以下机制：

注意：CRC和Counter在Frame中的位置固定。

6 结尾

<--返回「Autosar_BSW高阶配置」总目录-->

<--返回「Autosar_BSW高阶配置」专栏主页-->

<--返回「个人博客」首页-->