目录
4.2 E2E Protection Wrapper解决方案示例
E2E(End-to-End)保护的概念假设与安全相关的数据交换应在运行时受到保护，免受通信链路内故障的影响（图0-1）。此类故障的示例包括：随机硬件故障（如，CAN收发器的寄存器损坏）、干扰（如，EMC）以及实现VFB通信的软件内的系统故障（例如RTE、IOC、COM和网络堆栈）。
通过使用E2E通信保护机制，可以在运行时检测和处理通信链路中的故障。E2E Library提供E2E保护机制，足以满足具有高达ASIL D需求的安全相关通信。
图0-1：E2E保护缓解的故障示例
注：
导致E2E保护检测到错误的典型干扰源：
软件相关源：
S1.大多数生成的RTE中的错误
S2.部分生成和部分手工编码的COM中的错误
S3.网络堆栈错误
S4.生成的IOC或OS错误
硬件相关源：
H1.硬件网络故障
H2.网络电磁干扰
H3.上下文切换（分区）或内核间通信期间的微控制器故障
1 常见的通讯故障以及E2E机制能够检出的通讯故障
| 通信故障类型 |
故障描述 |
| Repetition of information 信息重复 |
多次收到同一条消息。 |
| Loss of information 信息丢失 |
从传输的信息流中，信息或部分信息被删除。 |
| Delay of information 信息延迟 |
接收到的信息比预期晚。 |
| Insertion of information 插入信息 |
将附加信息插入到传输的信息流中。 |
| Masquerading 伪装/冒充 |
非真实信息被接收者接收为真实信息。 |
| Incorrect addressing 不正确的寻址 |
从错误的发送者或错误的接收者处接收信息。 |
| 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 the receivers 来自发送者的信息仅由一部分接收者接收 |
有些接收器没有收到信息。 |
| Blocking access to a communication channel 阻塞访问通信通道 |
通信通道的访问被阻塞。 |
E2E机制可以检测以下故障或故障影响：
| E2E机制 |
检出的通信故障 |
| Counter |
Repetition, Loss, Insertion, Incorrect sequence, Blocking 重复，丢失，插入，不正确的序列，阻塞 |
| Transmission on a regular basis and timeout monitoring using E2E-Library 使用E2E Library进行定期传输和超时监控 |
Loss, Delay, Blocking 丢失，延迟，阻塞 |
| Data ID + CRC |
Masquerade and incorrect addressing, Insertion 伪装/冒充和不正确的寻址、插入 |
| CRC |
Corruption, Asymmetric information 损坏，信息不对称 |
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通讯保护机制解决方案：
- E2E Protection Wrapper（用于保护数据的非标准集成商软件，在RTE的上层）
- E2E Transformer（一种新的、标准化的E2E调用方式，在Autosar4.2.1中引入）
- COM E2E Callout（用于保护I-PDU的非标准集成商代码）
也可能有混合场景，例如：
1.对于特定数据元素，发送方使用E2E Protection Wrapper，接收方使用COM E2E Callout（或反向）
2.在给定的ECU网络或一个ECU中：一些数据元素使用E2E Protection Wrapper，一些使用COM E2E Callout。
无论E2E在何处执行，E2E保护都是针对数据元素的。E2E保护是在数据元素的序列化表示上执行的，其位布局与总线上传输的位布局相同。这意味着：
- 如果使用E2E Transformer，序列化由E2E Transformer之上的transformer进行（基于COM的transformer或Some/IP的transformer）。
- 如果使用E2E Protection Wrapper，Wrapper需要将数据元素序列化为对应信号组的序列化形式（换句话说，Wrapper创建了I-PDU的一部分，它代表了信号组和数据元素）。
- 如果使用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应提供以下机制：
| 控制端 |
描述 |
| Counter |
4位 表示每次发送请求时从0到14递增的数字。 E2E Profile 1提供了Alive Counter和Sequence Counter机制，评估相同的4位。 |
| Timeout monitoring |
超时由E2E Library通过对计数器的评估，通过接收器处的非阻塞读取来确定。 E2E Library通过E2E_P01CheckStatusType中的状态标志将超时报告给调用者。 |
| Data ID |
16位，唯一编号，包含在CRC计算中。 对于等于0、1或2的dataIdMode，不传输Data ID，而是包含在CRC计算中。 对于dataIdMode等于3： •不使用DataID高字节的高半字节（它是0x0），因为DataID被限制为12位， •DataID高字节的低半字节被传输并在计算CRC over Data时被CRC计算覆盖。 •不传输低字节，但它作为起始值包含在CRC计算中（例如dataIDMode等于0、1或2）。 |
| CRC |
8位 CRC-8-SAE J1850 - 0x1D (x8 + x4 + x3 + x2 + 1)，但具有不同的起始值和XOR值（起始值和异或值都是0x00）。 该CRC由CRC Library提供。从AUTOSAR R4.0开始，CRC Library的SAE8 CRC函数使用0xFF作为起始值和XOR值。为了补偿CRC Library的不同行为，E2E Library从R4.0开始应用额外的XOR 0xFF操作，以得出0x00作为起始值和XOR值。 注意：此CRC多项式与FlexRay、CAN和LIN使用的CRC多项式不同。 |
注意：CRC和Counter在Frame中的位置可以通过各自的Offset确认。
5.2 E2E Profile 2机制
Profile 2应提供以下机制：
| 控制端 |
描述 |
| Counter |
4位 表示发送方的每个发送请求时从0到15递增的数字。 每次调用E2E_P02Protect()函数时，计数器都会递增，即，在SW-C的每个传输请求上 |
| Message Key used for CRC calculation(Data ID) 用于CRC计算的Message Key（Data ID） |
8位 用于计算CRC的特定Data ID取决于计数器的值，并且是一组预定义Data ID的元素（计数器的值作为索引以选择用于保护的特定Data ID）。对于每个数据元素，取决于计数器的每个值的Data ID列表是唯一的。 |
| CRC |
8位 多项式：0x2F(x8 + x5 + x3 + x2 + x + 1) 起始值：0xFF 最终异或值：0xFF 注意：此CRC多项式与FlexRay和CAN使用的CRC多项式不同。 |
注意：CRC和Counter在Frame中的位置可以通过同一个Offset确认。导致CRC和Counter在相邻的Byte中。
5.3 E2E Profile 4机制
Profile 4应提供以下机制：
| 控制端 |
描述 |
| Length |
16位，支持动态大小的数据。 |
| Counter |
16位. |
| CRC |
32位，多项式的范式为0x1F4ACFB13，由CRC Library提供。 注意：此CRC多项式与FlexRay、CAN和LIN以及TCP/IP使用的CRC多项式不同。 |
| Data ID |
32位，系统范围内唯一。 |
注意：CRC和Counter在Frame中的位置固定。
5.4 E2E Profile 5机制
Profile 5应提供以下机制：
| 控制端 |
描述 |
| Counter |
8位。 |
| CRC |
16位，多项式的范式为0x1021（Autosar符号），由CRC Library提供。 |
| Data ID |
16位，系统范围内唯一。 |
注意：CRC和Counter在Frame中的位置固定。
5.5 E2E Profile 6机制
Profile 6应提供以下机制：
| 控制端 |
描述 |
| Length |
16位，支持动态大小的数据。 |
| Counter |
8位。 |
| CRC |
CRC Library提供的16位多项式，采用标准形式0x1021（Autosar表示法）。 |
| Data ID |
16位，系统范围内唯一。 |
注意：CRC和Counter在Frame中的位置固定。
5.6 E2E Profile 7机制
Profile 7应提供以下机制：
| 控制端 |
描述 |
| Length |
32位,支持动态大小的数据。 |
| Counter |
32位 |
| CRC |
64位，多项式的范式为0x42F0E1EBA9EA3693，由CRC Library提供。 注意：此CRC多项式也称为“CRC-64(ECMA)”。 |
| Data ID |
32位，系统范围内唯一。 |
注意：CRC和Counter在Frame中的位置固定。
5.7 E2E Profile 11机制
Profile 11应提供以下机制：
| 控制端 |
描述 |
| Counter |
4位。 |
| CRC |
8位，CRC-8-SAE J1850，由CRC Library提供。 |
| Data ID |
16位或12位，系统范围内唯一。 |
注意：CRC和Counter在Frame中的位置固定。
5.8 E2E Profile 22机制
Profile 22应提供以下机制：
| 控制端 |
描述 |
| Counter |
4位。 |
| CRC |
8位，多项式的范式为0x2F（Autosar符号），由CRC Library提供。 |
| Data ID List |
16个8位值，链接到计数器值。有效16个不同的值，每个计数器值一个。Data ID列表在系统范围内必须是唯一的。 |
注意：CRC和Counter在Frame中的位置固定。
6 结尾
