E2E 的核心定义与目标

E2E 是 End-to-End 的缩写，中文通常翻译为 “端到端” 。在汽车电子，特别是涉及功能安全的领域，它是一个至关重要的概念。

核心定义：
E2E 指的是一种保护机制，它确保在发送节点和接收节点之间的整个通信路径上，数据的完整性、真实性和时效性得到保护。

简单来说： 发送方在发出数据前，为数据加上一个“安全信封”（包含校验码、计数器等），接收方在收到数据后，会仔细检查这个“信封”。只有通过所有检查，接收方才会认为这个数据是可信、可用、最新的。

主要目标：

1. 防止数据篡改： 确保数据在总线传输过程中没有被意外或恶意修改。
2. 检测数据丢失： 确保没有丢失任何一帧数据。
3. 检测数据重复： 防止同一帧数据被重复处理。
4. 检测数据延迟： 确保接收到的数据是及时、新鲜的，而不是一个过时的旧数据。
5. 确保发送者身份真实： 确认数据确实来自于声称的发送节点。

这一切的最终目的，是为了满足 ISO 26262 道路车辆功能安全标准中对通信环节的要求。

为什么需要 E2E？

车载网络（如 CAN, CAN FD, FlexRay, Ethernet SOME/IP）本身并不是绝对可靠的。在复杂的电磁环境中，可能会发生各种通信故障：

• 物理层故障： 线路干扰、短路、断路等，导致比特翻转或数据帧损坏。
• 硬件故障： 发送节点的ECU或通信控制器故障，可能会重复发送数据、停止发送或发送错误数据。
• 软件故障： 发送方软件故障，可能写入错误的值；接收方软件故障，可能错误地解读数据。
• 网络拥堵： 导致数据延迟，接收方可能收到过时的信息。

对于非安全相关的功能（如调节空调温度），偶尔的数据错误可能影响不大。但对于安全关键系统，如刹车、转向、安全气囊等，任何数据错误都可能导致灾难性后果。E2E 保护机制就是为了在这些故障发生时，能够被及时检测到，并使系统可以进入一个安全状态。

E2E 的保护机制是如何工作的？

E2E 的核心是在应用层数据之外，增加一个 E2E Header。这个头部包含了一系列校验信息。最经典和广泛使用的模型是 AUTOSAR 定义的 E2E Profile。

关键组成部分：

1. CRC（循环冗余校验）：

   • 作用： 保护数据的完整性。它对整个或部分用户数据（Payload）进行计算，生成一个校验值。
   • 接收方检查： 接收方用同样的算法重新计算CRC，如果结果不匹配，说明数据在传输过程中被篡改或损坏。

2. Counter（计数器）：

   • 作用： 检测数据丢失和重复。发送方每发送一次新数据，计数器就加1（有上限，会循环）。
   • 接收方检查： 接收方会记录上一次收到的计数器值。如果新收到的计数器值不是预期的“上一个值+1”，则说明中间有帧丢失（如果跳变很大）或发生了重复（如果收到相同的计数值）。

3. Data ID（数据标识符）：

   • 作用： 确保数据的真实性，并将CRC与特定的数据关联起来。它是一个预先配置好的、对发送方和接收方都已知的唯一标识符。
   • 工作原理： 在计算CRC时，会将Data ID也作为输入之一。这样，即使两个不同的发送节点发送了完全相同的数据，它们的CRC也会因为Data ID不同而不同，防止了接收方混淆数据来源。

4. Timeout（超时检查）：

   • 作用： 检测数据延迟或发送方完全失效。
   • 工作原理： 接收方会监控特定数据的接收间隔。如果超过预设的时间阈值还没有收到新数据，就认为通信超时，数据已不再新鲜。

工作流程示例（以 AUTOSAR E2E Profile 1 为例）：

1. 发送端：

   • 应用程序生成了需要发送的数据（例如，车速 100 km/h）。
   • E2E保护模块介入：
     • 读取并递增计数器（例如，从 5 到 6）。
     • 结合 Data ID、计数器 6 和**用户数据 100**，计算 CRC。
     • 将 计数器 6 和 CRC 作为 E2E Header，与用户数据 100 一起打包，交给底层通信栈发送出去。

2. 传输过程：

   • 数据在CAN总线上传输，可能受到干扰，但未被检测到（CAN本身的CRC可能未能检测出极低概率的多位错误）。

3. 接收端：

   • 从总线收到数据，CAN Driver先进行基础的校验。
   • 数据被传递到应用层前，E2E保护模块介入检查：
     • CRC校验： 使用相同的Data ID、收到的计数器和用户数据重新计算CRC，与收到的CRC比对。（检查数据完整性）
     • 计数器校验： 检查收到的计数器 6 是否等于上一次收到的计数器 5 + 1。（检查数据丢失/重复）
     • 超时检查： 检查距离上次收到该数据的时间是否在允许范围内。（检查数据新鲜度）
   • 结果：
     • 所有检查通过： E2E模块将状态标记为 E2E_OK，并将纯净的用户数据 100 km/h 传递给应用程序使用。
     • 任何一项检查失败： E2E模块将状态标记为 E2E_NOT_OK、E2E_REPEATED 等，并不会将数据传递给应用程序，或者传递一个无效值。同时，系统可以根据安全策略采取相应措施（如使用默认值、报错、进入降级模式等）。

E2E 在哪些车载总线上使用？

E2E 是一种与应用层紧密相关的保护机制，理论上可以应用在任何车载总线上，只要发送和接收双方遵循相同的 E2E Profile 协议。最常见于：

• CAN / CAN FD： 这是E2E应用最广泛的场景，因为CAN总线本身没有足够强大的安全机制。
• FlexRay： 同样需要E2E来满足更高功能安全等级的要求。
• 汽车以太网（SOME/IP）： 虽然TCP/IP协议栈本身有校验和等机制，但对于安全关键的SOME/IP服务，仍然会在其之上实施E2E保护，以满足ISO 26262的严格要求。

相关标准与规范

• ISO 26262： 这是E2E机制的“需求方”。标准第6部分专门提到了对产品开发中避免和控制系统性故障的要求，其中就包括通信的可靠性。
• AUTOSAR： 这是E2E机制的“解决方案提供方”。AUTOSAR标准中明确定义了多种 E2E Profiles（如 Profile 1, 2, 5, 6, 7, 11等），针对不同的数据长度、总线类型和安全等级提供了标准化的实现方案。这是行业内事实上的标准。
• OSEK/VDX： 在AUTOSAR之前，也有相关的通信标准。

E2E Profile 1 详解

以下表格汇总了 AUTOSAR E2E Profile 1 的关键规范：

E2E Profile 1 接收端的检查状态 (E2E_P01CheckStatusType) 详细说明了通信质量，理解这些状态对于系统诊断很重要：

• E2E_P01STATUS_OK：CRC正确，计数器连续。这是理想的正常状态。
• E2E_P01STATUS_OKSOMELOST：CRC正确，但计数器有跳变（在允许的 MaxDeltaCounter 内）。表示有报文丢失，但仍在可接受范围。
• E2E_P01STATUS_REPEATED：CRC正确，但计数器与上一次相同。表明报文可能被重复发送。
• E2E_P01STATUS_WRONGSEQUENCE：CRC正确，但计数器跳变过大（超过 MaxDeltaCounter）。表示有大量报文丢失。
• E2E_P01STATUS_WRONGCRC：CRC校验失败，数据在传输中可能已损坏。
• E2E_P01STATUS_SYNC：在检测到计数器异常后，正在重新同步的过程中。
• E2E_P01STATUS_INITIAL：接收端初始化后的第一个报文，CRC正确，但计数器连续性尚未验证。
• E2E_P01STATUS_NONEWDATA：没有收到新数据。

AUTOSAR模块如何实现E2E

在AUTOSAR架构中，E2E功能的实现需要多个标准模块协同工作。下面这个表格汇总了参与实现E2E功能的核心AUTOSAR标准模块及其职责。

核心模块协作流程

在典型的E2E通信保护中，上述模块协同工作。下面的流程图直观展示了在两种常见实现路径中，数据从发送到接收校验的完整过程：

如图所示，E2E保护主要有两种实现路径：

• 路径一（E2EXf + ComXf）：这是AUTOSAR推荐的标准化、自动化路径。RTE自动调用E2EXf和ComXf，对应用层SWC透明，集成度高，但配置相对复杂。
• 路径二（E2EPW）：在SWC层手动调用，使用灵活，但SWC需要感知并处理E2E相关的状态和错误。

此外，还有一种COM Callout方式，它在COM模块处理PDU时调用E2E库，其保护单元是整个PDU。

如何选择实现方式

在实际项目中，可以参考以下思路进行选择：

• 追求标准化与自动化：在架构设计阶段就系统性地规划，优先考虑E2E Transformer (E2EXf) 方式。这是AUTOSAR大力推广的现代化实现，尤其在新项目中值得采用。
• 需要快速集成或特定灵活性：在某些特定场景或需要快速验证时，可以考虑使用E2E Protection Wrapper (E2EPW) 或 COM Callout。它们能在一定程度上提供灵活性。

参考

Autosar E2E及其实现（基于E2E_P01）（1） | CTF导航

鉴源实验室｜AUTOSAR E2E：车载通信的安全保障