autosar_standard_spec_v4.4/Communication/AUTOSAR_SRS_E2E.md

# E2E 通信保护需求规范

## 元信息

| 项目 | 内容 |
|------|------|
| 文档标题（中文） | E2E 通信保护需求规范 |
| 文档标题（英文） | Requirements on E2E Communication Protection |
| 文档所有者 | AUTOSAR |
| 文档责任方 | AUTOSAR |
| 文档标识号 | 651 |
| 文档状态 | Final（最终） |
| 所属 AUTOSAR 标准 | Classic Platform（经典平台） |
| 所属标准发布版本 | 4.4.0 |
| 对应原文 PDF | `AUTOSAR_SRS_E2E.pdf` |
| 翻译状态 | 已完成 |
| 翻译日期 | 2026-06-12 |

## 文档标识

| 字段 | 值 |
|------|----|
| Document Title（文档标题） | Requirements on E2E Communication Protection |
| Document Owner（文档所有者） | AUTOSAR |
| Document Responsibility（文档责任方） | AUTOSAR |
| Document Identification No（文档标识号） | 651 |
| Document Status（文档状态） | Final |
| Part of AUTOSAR Standard（所属 AUTOSAR 标准） | Classic Platform |
| Part of Standard Release（所属标准发布版本） | 4.4.0 |

## 文档变更历史

| 日期 | 发布版本 | 变更人 | 变更说明 |
|------|----------|--------|----------|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | - 将文档迁移到"Classic Platform"标准<br>- 次要更正/澄清/编辑性修改；有关详细信息，请参阅 ChangeDocumentation |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | - 次要更正/澄清/编辑性修改；有关详细信息，请参阅 ChangeDocumentation |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | - 考虑新配置文件 7、11、22 更新需求<br>- 更新需求追踪 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | - 初始发布 |

## 目录

1. [Scope of Document（文档范围）](#1-scope-of-document)
2. [Conventions to be used（使用的约定）](#2-conventions-to-be-used)
3. [Acronyms and abbreviations（缩略语和缩写）](#3-acronyms-and-abbreviations)
4. [Requirements tracing（需求追踪）](#4-requirements-tracing)
5. [Requirements Specification（需求规范）](#5-requirements-specification)
   - 5.1 [Functional Overview（功能概述）](#51-functional-overview)
   - 5.2 [Functional Requirements（功能需求）](#52-functional-requirements)
     - 5.2.1 [General use case（一般用例）](#521-general-use-case)
     - 5.2.2 [E2E transformer（E2E 转换器）](#522-e2e-transformer)
     - 5.2.3 [E2E Library（E2E 库）](#523-e2e-library)
6. [References（参考资料）](#6-references)

## 1 Scope of Document

本文档定义了根据 ISO26262 的 E2E 通信保护需求。这些需求应用作详细 E2E 机制及其在 AUTOSAR 实现中使用的规范基础，最高可达 ASIL D 系统。

## 2 Conventions to be used

- AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中指定的表格。
- 在需求中，应使用以下特定语义（基于互联网工程任务组 IETF）。

本文档中关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应解释为：

- **SHALL**：此词表示该定义是规范的绝对要求。
- **SHALL NOT**：此短语表示该定义是规范的绝对禁止。
- **MUST**：此词表示由于法律问题，该定义是规范的绝对要求。
- **MUST NOT**：此短语表示由于法律约束，该定义是规范的绝对禁止。
- **SHOULD**：此词或形容词 "RECOMMENDED" 表示在特定情况下可能存在忽略某项的有效理由，但在选择不同方案之前必须充分理解并仔细权衡其影响。
- **SHOULD NOT**：此短语或短语 "NOT RECOMMENDED" 表示在特定情况下某特定行为可能是可接受甚至有用的，但在实现任何以此标签描述的行为之前，应充分理解其影响并仔细权衡该情况。
- **MAY**：此词或形容词 "OPTIONAL" 表示某项是真正可选的。

## 3 Acronyms and abbreviations

本文档中使用的所有技术术语（除下表所列的术语外）都可以在官方 AUTOSAR 词汇表中找到。

| 缩写/首字母缩写 | 描述 |
|----------|------|
| E2E | End-to-End（端到端） |

## 4 Requirements tracing

| 需求 | 描述 | 由以下需求满足 |
|------|------|----------------|
| RS_BRF_00110 | AUTOSAR 应提供保护安全相关数据通信免受损坏的方法 | SRS_E2E_08527, SRS_E2E_08528, SRS_E2E_08529, SRS_E2E_08530, SRS_E2E_08533, SRS_E2E_08536, SRS_E2E_08537, SRS_E2E_08539 |
| RS_BRF_00113 | AUTOSAR 应检测信号超时 | SRS_E2E_08528, SRS_E2E_08529 |
| RS_BRF_01056 | AUTOSAR BSW 模块应提供标准化接口 | SRS_E2E_08527, SRS_E2E_08538 |
| RS_BRF_01280 | AUTOSAR RTE 应提供软件组件之间以及软件组件和 BSW 之间的外部接口 | SRS_E2E_08538 |
| RS_BRF_02096 | AUTOSAR 应提供作为库的循环冗余校验和的校验和计算 | SRS_E2E_08533 |
| RS_BRF_02104 | AUTOSAR 应以库形式提供端到端保护支持 | SRS_E2E_08527, SRS_E2E_08528, SRS_E2E_08529, SRS_E2E_08530, SRS_E2E_08531, SRS_E2E_08534, SRS_E2E_08536, SRS_E2E_08537, SRS_E2E_08539, SRS_E2E_08540 |

## 5 Requirements Specification

在本章中规定了 AUTOSAR 模块 E2E 库和 E2E 转换器两者的需求。

### 5.1 Functional Overview

安全相关的汽车系统通常使用安全数据传输来保护组件之间的通信（ISO 26262 要求），这意味着：
1. 应防止通信错误（例如通过适当的软件架构和验证手段）
2. 如果仅错误预防不足够（例如对于 ECU 间通信），则应在运行时以足够的程度检测错误（参见诊断覆盖率、安全失效分数），并且未检测到的危险错误率低于某个允许的限制（参见残余错误率、每小时危险失效概率或需求时危险失效概率）。

为了在 SW-C 之间提供安全的端到端通信，应将一个解决方案集成到 AUTOSAR 方法中，该解决方案不需要或需要很少的额外非标准代码（如 RTE 之上的包装器）。

端到端通信保护的功能应由以下 AUTOSAR 模块支持：
- E2E 库
- E2E 转换器

E2E 转换器提供：
- 符合 RTE API 的通信抽象
- 保护通过 COM 栈通过 RTE 交换的信息的序列化交换，独立于 RTE 实现和 RTE 内部数据类型
- 到 E2E 库的接口

E2E 库提供：
- 配置文件 1、2、4、5、6、7、11 和 22 的定义，包括检查和保护功能。
- 描述独立于所用配置文件的 E2E 监视逻辑算法的状态机。

如果这些模块用于通信保护，则 RTE、转换器、E2E 转换器、E2E 库、CRC 库、OS 上下文切换和调度被假定为安全相关模块。因此，在混合 ASIL 环境中，必须通过安全分析表明 QM 或低 ASIL 软件无法访问 E2E 缓冲区，以确保免于干扰。

### 5.2 Functional Requirements

#### 5.2.1 General use case

##### 5.2.1.1 [SRS_E2E_08540] E2E 通信保护应支持周期性发送方-接收方通信

⌈

| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | E2E 通信保护应支持周期性发送方-接收方通信。 |
| Rationale（原理） | 根据通信行为和属性，应提供对有限时序违规的容忍度。例如，CAN 上的周期性消息可能由于高利用率和高级别消息而引入大量抖动。 |
| Use Case（用例） | 通信总线和网络上的安全相关消息的周期性发送。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | 采样型周期性消息通常用于安全相关通信，因为它们确保检测通信丢失、延迟、序列变化，并允许对单个故障消息的容忍。单向通信是普遍情况，在接收方提供通信故障检测（从而拒绝故障消息）。但是，不能严格假设同步周期性通信，因为发送方和接收方可能不完全同步，具有相同的周期或彼此有限的抖动。 |

⌋( RS_BRF_02104)

#### 5.2.2 E2E transformer

E2E 转换器通过 RTE 调用，位于 RTE 和 E2E 库之间。它负责 E2E 保护的配置和状态管理。

##### 5.2.2.1 [SRS_E2E_08538] 应提供 E2E 转换器

⌈

| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 应提供 E2E 转换器，可通过 RTE 调用，位于调用方（RTE）和 E2E 库之间。它应负责 E2E 保护的配置和状态管理，并应提供对由至少 Some/IP 和基于 COM 的转换器序列化的消息的保护。 |
| Rationale（原理） | E2E 库的配置和管理的全部复杂性保留在 E2E 转换器内。由于此原因，可以在没有额外集成代码的情况下实现 E2E 保护。 |
| Use Case（用例） | 主底盘 ECU SW-C 和动力转向 ECU SW-C 之间的通信。<br>Some/IP 是以太网的序列化协议。基于 COM 的转换器通常用于 CAN、FlexRay、CanFD。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |

⌋( RS_BRF_01056, RS_BRF_01280)

#### 5.2.3 E2E Library

E2E 库提供一组安全协议，以由 SW-C 调用的库函数形式。该协议应通过 QM 通信栈提供足够用于传输高达 ASIL D 的安全相关数据的错误检测。它提供：
1. E2E 配置文件 1、2、4、5、6、7、11、22。
2. E2E 状态机

##### 5.2.3.1 [SRS_E2E_08528] E2E 库应提供 E2E 配置文件，其中每个 E2E 配置文件完全定义特定的安全协议

⌈

| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | E2E 库应提供 E2E 配置文件，其中每个 E2E 配置文件完全定义特定的安全协议（包括报头结构、作为状态机的行为、错误处理等）。每个 E2E 配置文件应是底层特定 AUTOSAR 通信栈（以太网、FlexRay、CAN、CAN FD 或 LIN）和交换信号的 ASIL 等级的特定有效解决方案。<br>注意：<br>每个通信栈（例如 FlexRay）具有不同的错误率，取决于：<br>- 通道上的位错误率<br>- HW 的 FIT 值<br>- ECU 数量<br>- 拓扑（例如 CAN->Gateway->FR）<br>- 开放/封闭传输系统<br>- 安全相关消息的频率<br>基于经过使用验证的解决方案，配置文件应涵盖上述因素的典型组合。 |
| Rationale（原理） | 太多标准化的配置文件会降低应用程序之间的互操作性。此外，它引入了过多的规范和开发工作。 |
| Use Case（用例） | CAN 使用 8 位 CRC 的协议，FlexRay 长信号使用 16 位 CRC 的协议。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |

⌋( RS_BRF_02104, RS_BRF_00113, RS_BRF_00110)

##### 5.2.3.2 [SRS_E2E_08527] E2E 库应以库函数的形式提供 E2E 配置文件

⌈

| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | E2E 库应以库函数的形式提供一组安全协议。该协议应通过以 QM 软件实现的通信栈，提供足够用于传输高达 ASIL D 的安全相关数据的错误检测。 |
| Rationale（原理） | E2E 通信保护是汽车安全相关系列产品中的最新技术。 |
| Use Case（用例） | 主底盘 ECU SW-C 和动力转向 ECU SW-C 之间的通信。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |

⌋(RS_BRF_01056, RS_BRF_02104, RS_BRF_00110)

##### 5.2.3.3 [SRS_E2E_08529] 每个定义的 E2E 配置文件应使用特定保护机制的适当子集

⌈

| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 每个定义的 E2E 配置文件应使用以下机制的适当子集：<br>1. 序列号（可能有不同的大小；在现有技术中也称为活动计数器或连续编号）<br>2. CRC 长度：8、16、32、64 位<br>3. ID：源 ID、目标 ID、数据 ID<br>4. 超时：接收超时<br>换句话说，不应使用未列出的机制。<br>在每个 E2E 配置文件中，序列号和 ID（如果使用）应全部是所传输数据元素的一部分。但是，允许在给定的配置文件中，序列号和/或 ID"隐藏"（不传输），但包含在 CRC 中。 |
| Rationale（原理） | 这些是安全协议使用的典型措施，它们可以通过 AUTOSAR 实现。 |
| Use Case（用例） | 示例配置文件中使用的机制：4 位序列计数器、CRC8、数据 ID、超时。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |

⌋( RS_BRF_02104, RS_BRF_00110, RS_BRF_00113)

##### 5.2.3.4 [SRS_E2E_08530] 每个 E2E 配置文件应具有唯一 ID，以半正式方式精确定义一组机制及其行为

⌈

| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 在库中定义的每个 E2E 配置文件应：<br>1. 具有唯一 ID（E2E_01 到 E2E_16 的 ID 保留用于标准 AUTOSAR 配置文件）。<br>2. 精确定义一组机制（例如特定多项式的 CRC）<br>3. 以半正式方式定义其行为（包括状态机、错误处理等）。 |
| Rationale（原理） | 协议不仅仅是机制列表（例如 CRC8 + 序列号），而是管理该过程的整个逻辑。报头的标准化远远不够。需要标准化的行为来实现互操作性。 |
| Use Case（用例） | 通常每个通信伙伴的每个配置文件一个状态机（发送方、接收方、客户端服务器）就足够了。<br>ECU1 和 ECU2 通信。ECU1 具有与 ECU2 不同的 E2E 库实现。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |

⌋( RS_BRF_02104, RS_BRF_00110)

##### 5.2.3.5 [SRS_E2E_08531] E2E 库应调用 CRC 库的 CRC 例程

⌈

| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | E2E 库不应提供 CRC 例程实现。相反，它应调用 CRC 库的 CRC 例程（文档 UID 016）。 |
| Rationale（原理） | 重用现有的 AUTOSAR 功能 |
| Use Case（用例） | CRC 库的 CRC8 用于保护 CAN 通信的配置文件之一。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |

⌋( RS_BRF_02104)

##### 5.2.3.6 [SRS_E2E_08533] E2E 配置文件中使用的 CRC 应与底层物理通信协议使用的 CRC 不同

⌈

| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 每个 E2E 配置文件中使用的 CRC 应与底层通信协议（Wi-Fi、Ethernet、IP、UDP、TCP、FlexRay、CAN、CAN FD、LIN）使用的 CRC 不同，给定配置文件应与这些协议一起使用。 |
| Rationale（原理） | 两次使用相同的多项式（一次在 com 栈中，一次在 E2E 中）提供的联合检测率显著低于使用两个不同的多项式。<br>AUTOSAR R3.1 中可用的多项式无论如何都不适合 E2E。 |
| Use Case（用例） | 如果配置文件 X 旨在仅用于 FlexRay，则其 CRC 应与 FlexRay 的 CRC 不同。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |

⌋( RS_BRF_02096, RS_BRF_00110)

##### 5.2.3.7 [SRS_E2E_08534] E2E 库应为每种类型的检测到的通信故障提供单独的错误标志和错误计数器

⌈

| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | E2E 库应为应用层提供每种类型的检测到的通信故障的单独错误标志和错误计数器。<br>换句话说，如果 E2E 配置文件 X 旨在使用序列计数器和 CRC，则以下错误标志应对应用层可用：<br>• 数据损坏<br>• 错误序列<br>• 重复<br>• 数据丢失 |
| Rationale（原理） | 错误处理策略是"应用相关的"，不能"先验定义"。 |
| Use Case（用例） | 启用使用 E2E 库的 SW-C 的错误相关反应。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |

⌋( RS_BRF_02104)

##### 5.2.3.8 [SRS_E2E_08536] SW-C 或 E2E 库应计算应用数据元素的中间 CRC

⌈

| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | SW-C 或 E2E 库应计算应用数据元素的中间 CRC。E2E 库应使用中间 CRC 作为初始 CRC 值，并应计算序列计数器（如果使用）和 ID（如果使用）的 CRC。 |
| Rationale（原理） | 在复杂数据元素的情况下，E2E 库无法计算数据元素的 CRC（因为库不知道数据元素的布局 — 数据类型可以是例如指向数据结构的指针数组，不占用连续地址空间）。在这种情况下，应用需要计算数据元素的 CRC，并将计算的 CRC 传递给库。但是，无论谁调用 CRC 计算（SW-C 或库），使用的 CRC 都是所用 E2E 配置文件的 CRC。 |
| Use Case（用例） | -- |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |

⌋(RS_BRF_02104, RS_BRF_00110)

##### 5.2.3.9 [SRS_E2E_08537] 使用 E2E 配置文件 1/2 时，SW-C 应容忍至少一个无效/损坏但未被 E2E 检测到的接收数据元素

⌈

| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 使用 E2E 配置文件 1/2 时，SW-C 应容忍至少一个无效/损坏但未被 E2E 检测到的接收数据元素。 |
| Rationale（原理） | 要求 100% 错误由 E2E 协议检测对 E2E 库的实现有很大影响（例如需要 SW 或/和 HW 冗余）。允许在接收信号序列中有一个未被 E2E 检测到错误的信号。 |
| Use Case（用例） | 示例 1：生成与原始信号相同 CRC 的多位错误（例如 5 个损坏位）。<br>示例 2：E2E 库中的随机 HW 故障或 SW 故障导致 CRC 序列计数器计算未检测到错误。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |

⌋(RS_BRF_02104, RS_BRF_00110)

##### 5.2.3.10 [SRS_E2E_08539] 应提供用于大型数据 ECU 间通信的 E2E 保护机制

⌈

| 字段 | 内容 |
|------|------|
| Type（类型） | Valid |
| Description（描述） | 此 E2E 机制应支持保护长度高达 4MB 的动态长度大型复合数据。 |
| Rationale（原理） | 大型复合数据需要特定的保护机制。 |
| Use Case（用例） | 主底盘 ECU SW-C 和动力转向 ECU SW-C 之间的通信、视觉数据的通信、配置数据的传送、闪存软件更新的传送。 |
| Dependencies（依赖） | -- |
| Supporting Material（支持材料） | -- |

⌋(RS_BRF_02104, RS_BRF_00110)

## 6 References

无

## 翻译说明

本文档为 AUTOSAR Classic Platform Release 4.4.0 中关于 E2E 通信保护的软件需求规范（SRS），对应英文文档 `AUTOSAR_SRS_E2E.pdf`。

翻译过程中遵循以下原则：
1. 保留了所有 API 标识符、模块缩写、协议名（如 E2E、CRC、ASIL、RTE、SW-C、Some/IP、CAN FD 等）
2. 保留了所有需求 ID（如 `SRS_E2E_08xxx`）
3. 保留了 AUTOSAR 方框符 `⌈⌋`
4. 保留了所有 ISO 标准引用和文档间交叉引用
5. 表格内容、章节描述、需求说明均已翻译为中文