RS E2E
1. 文档范围¶
本文档规定 E2E 协议的需求。E2E 协议定义了按照 ISO 26262:2018（所有部分）[1] 的需求提供端到端（End-to-End）通信保护的抽象机制。这些机制应允许安全相关数据在非安全相关的通信路径上、按 [1] 定义的全部完整性等级进行安全数据传输。本文档只覆盖协议部分，因此也只覆盖端到端路径的一部分。
这些需求应作为详细 E2E 机制规范及其在 AUTOSAR 实现中的使用的基础。
注意： 本文档包含来自经典平台文档的众所周知的需求，并尽可能引入自适应平台的新需求。自适应平台中 E2E 保护的用例正在制定中。相关用例的更多细节将在本文档的下一版本中加入。
本文档是表明预期范围和讨论方向的草案规范。该规范经历的质量措施较少、伙伴间讨论较少，总体上可能处于不够成熟的状态。
2. 如何阅读本文档¶
2.1. 文档约定¶
AUTOSAR 文档中需求的表述遵循约束 TPS_STDT_00078 规定的表格，见 Standardization Template 的「Support for Traceability」章（[2]）。
需求的表达应使用约束 TPS_STDT_00053 规定的义务表达动词形式，见 Standardization Template 的「Support for Traceability」章（[2]）。
3. 缩略语和缩写¶
以下收录与 AUTOSAR_RS_E2E 相关、且未被 AUTOSAR 术语表 [3] 收录的缩略语和缩写。
E2E
端到端（End-to-End）
E2E Profile
E2E Profile：作为特定通信栈的高效解决方案的一组组合 E2E 措施。
BER
误码率（Bit Error Rate）——字节流中被损坏比特的比率，例如 1e-5。
4. 功能概述¶
安全相关汽车系统通常使用安全数据传输来保护组件之间的通信（如 ISO 26262:2018（所有部分）[1] 所要求），这意味着：
- 应预防通信错误（例如通过适当的软件架构和验证手段）。
- 如果仅靠错误预防不充分（例如对于 ECU 间通信），则
- 应在运行时以足够的程度检测错误（参见诊断覆盖率、安全故障分数），并且
- 未检测到的危险错误率应低于某个允许限值（参见残余错误率、每小时危险失效概率或要求时危险失效概率）。
4.1. 功能安全与通信¶
对于安全相关系统中的信息交换，可以使用以下及时检测故障原因或故障影响的机制来设计合适的安全概念，例如在共享同一通信基础设施的系统元素之间实现免受干扰（freedom from interference）（见 ISO 26262-6:2018，附录 D.2.4）。
| 通信故障类型 | 描述 |
|---|---|
| 信息的重复 | 一种通信故障：信息被接收多次。 |
| 信息的丢失 | 一种通信故障：信息或信息的一部分从被传输的信息流中被移除。 |
| 信息的延迟 | 一种通信故障：信息晚于预期被接收。 |
| 信息的插入 | 一种通信故障：附加信息被插入到被传输的信息流中。 |
| 伪装 | 一种通信故障：非真实的信息被接收方当作真实信息接受。 |
| 错误寻址 | 一种通信故障：信息来自错误的发送方或被错误的接收方接受。 |
| 信息的错误序列 | 一种通信故障：改变了被传输信息流中信息的序列。 |
| 信息的损坏 | 一种通信故障：改变了信息。 |
| 从一个发送方向多个接收方发送的非对称信息 | 一种通信故障：接收方确实从同一发送方接收到不同的信息。 |
| 来自一个发送方的信息仅被接收方的一个子集接收 | 一种通信故障：一些接收方没有接收到信息。 |
| 对通信信道的访问被阻塞 | 一种通信故障：对通信信道的访问被阻塞。 |
4.2. E2E 通信中的故障来源¶
E2E 通信保护旨在检测和缓解源自以下来源的通信故障的原因或影响：
- 软件故障，
- 随机硬件故障，
- 瞬态故障
这三种来源在以下小节中描述。
4.2.1. 软件故障¶
诸如通信栈模块和 RTE 之类的软件可能包含系统性性质的故障。系统性故障可能出现在系统生命周期的任何阶段，包括规范、设计、制造、运行和维护，并且当环境（例如根因的触发条件）相同时它们总是会出现。软件故障的后果可能是通信失效，例如数据发送的中断、接收方的超限（例如缓冲区溢出）或发送方的欠载（例如缓冲区为空）。为了预防（或处理）由此导致的失效，必须考虑检测和处理此类故障的适当技术措施（例如程序流监控或 E2E 监督）。
4.2.2. 随机硬件故障¶
随机硬件故障通常是硬件部件电气过载、退化、老化或受外部影响（例如环境应力）的结果。随机硬件故障无法完全避免，但可以评估其概率并实现适当的技术措施（例如诊断）。
4.2.3. 瞬态故障¶
瞬态故障通常由外部影响或环境应力引起，包括 EMI、ESD、湿度、腐蚀、温度或机械应力（例如振动）等影响。
4.3. AUTOSAR 中的安全端到端通信¶
为了提供安全的端到端通信，解决方案应集成到 AUTOSAR 方法论中，不要求任何或仅要求极少量的附加非标准代码（例如包装器）。
端到端通信保护的功能由 E2E 协议支持。
E2E 协议提供：
- 检测 4.1 节中所列通信故障的一个子集的机制。相关的通信故障取决于通信类型（例如周期性、非周期性、发送方/接收方等）。
- Profile 1、2、4、5、6、7、11 和 22 的定义，包括针对单次数据传输的检查（check）和保护（protect）函数。应根据所使用的物理总线层和被传输数据的大小选择合适的 Profile。
- 一个可选的状态机，描述 E2E 监控与状态处理的逻辑算法，用于两个专用通信伙伴之间的若干数据传输，与所使用的 Profile 无关。
注意： 可能需要附加的架构措施来确保 E2E 协议实现的安全运行。
4.3.1. E2E 保护概念¶
E2E 保护概念不仅仅是给数据元素添加适当的安全机制（例如使用 E2E Profile 1 或 2）。为了按照 ISO 26262 以所需的安全完整性等级确保通信信道的完整性，E2E 保护概念需要考虑经由需要保护的总线网络传输的数据的安全相关属性。本章给出实现注重正确性、一致性、完整性、时效性以及数据不可用性检测的 E2E 保护概念的基本原则。
注意： 对于注重确保数据可用性的 E2E 保护概念，需要具有足够容错能力的通信信道实现（例如使用独立冗余信道）。
注意： 冗余通信信道的使用可能产生对附加安全机制的需要（例如确保独立传输时数据流的一致性）。
有效的 E2E 保护概念的典型基本原则如下1：
- 用于数据传输的基础设施（例如总线、网关等）的设计和实现方式应使其不会系统性地干扰所使用的 E2E 保护（例如通过解包和更改受保护的数据）。
- 在数据提供期间发生内部故障的情形下，
- 数据提供方（例如发送方或客户端）确保它要么发送明确标记为无效的数据（即仅可能受该内部故障影响的特定数据元素），要么不发送数据（即在严重故障情形下发送方的失效安全（fail-safe）或失效静默（fail-silent）行为）。
- 在正常运行模式中，
- 数据提供方（例如发送方或客户端）
- 按预先确定的方式对数据进行分组（例如为一组数据确保一致性），并在传输之前使用合适的保护机制保护分组后的数据；
- 确保只发送有效数据。在此上下文中，有效数据意味着：
- 完全符合其所需安全相关属性的数据
- 在附加提供的限定符（即信号限定符（signal qualifier））所指示的范围内符合其所需安全相关属性的数据
- 明确标记为无效数据的数据（例如使用信号无效值）
- 在周期性/混合周期性通信的情形下，确保以有规律的方式（例如周期性）发送有效数据。
- 数据消费方（例如接收方、客户端或服务器）
- 以有规律的方式（例如周期性）监控新数据是否已到达，独立于来自其希望实现免受干扰的对象元素（例如通信栈）的外部触发条件；
- 能够在其确定的时间间隔内，通过评估接收数据的保护机制、以及（在周期性/混合周期性通信的情形下）其内部超时监控，检测相关的通信故障。
- 在检测到通信故障的情形下，
- 受保护数据的消费方（例如接收方、客户端或服务器）在其确定的时间间隔内自主发起必要的反应以缓解检测到的通信故障，符合系统的功能安全概念（即接收方的失效安全或失效静默行为）。
-
基于 ISO 26262，相应安全相关系统的容错时间间隔（FTTI）是允许的故障检测与缓解时间间隔，包括相关的数据交换部分和相应的通信路径。
-
关于整个系统的容错时间间隔（绝对 FTTI）：允许的时间间隔包括数据提供方（例如发送方）处故障检测与缓解的允许时间间隔、正常运行期间数据传输健壮性所需的时间间隔（例如补偿网关），以及数据消费方（例如接收方）处故障检测与缓解的允许时间间隔。
- 仅关于数据交换部分和相应通信路径的容错时间间隔（相对 FTTI）：对应于错误数据可容忍的最长持续时间，因此是数据消费方（例如接收方）处故障检测与缓解的允许时间间隔。
- 这些方面按发送方/接收方类型的通信描述，但也在大致相同的意义上适用于其他类型的通信。
4.3.2. 通信信道的完整性¶
为了确定通信的完整性并区分接收到的数据是否有效，数据的消费方（例如接收方）可以：
- 单独评估每条接收到的受保护消息，并且
- 监控在确定的用于错误检测和鉴定的时间间隔 t_EDQ 内接收到的多条受保护数据的全部评估结果，直至最后接收到的数据。
为了实现该监控功能，受保护数据的消费方（例如接收方）创建接收数据的历史。有效的接收数据按如下方式存储历史：
- 代（Generation）0 是最新（最新近）接收的有效数据
- 代 1 是次新接收的有效数据
- 代 2 是第三新接收的有效数据
- 以此类推
为此，每条最近接收的有效消息都存储为代 0，其指示数据年龄的参考值置为 0。每当受保护数据的消费方（例如接收方）检查是否有新数据到达时，它将已接收数据的年龄加 1。只要存储数据的年龄参考值小于确定的边界值 N，存储的数据就可以作为受保护数据消费方（例如接收方）提供的安全相关功能的基础。参数 N 可以通过将确定的用于错误检测和鉴定的时间间隔 t_EDQ 除以其周期性传输使用的周期时间来导出（例如，对于 t_EDQ = 160ms、常规周期时间为 20ms 的接收方，N = 160ms/20ms = 8）。
在足够新近的数据不再可用的情形下，消费方（例如接收方）的应用施加安全概念中确定的安全反应。这种反应可以是降级模式（degraded mode）。
5. 需求规格¶
5.1. 功能需求¶
5.1.1. 支持的通信模型和特性¶
E2E 协议被定义为支持不同类型的基于消息的通信。基于信号的通信：
- 周期性/混合周期性发送方/接收方通信
面向服务的通信：
- 周期性/混合周期性的基于事件的通信
- 非周期性的基于方法的通信（客户端-服务器通信）
5.1.1.1. E2E 协议应支持受保护的周期性/混合周期性通信¶
| 描述 | E2E 协议应支持受保护的周期性通信。这包括以下周期性： * 周期性 * 混合周期性 |
|---|---|
| 理由 | 面向消息的通信的 E2E 机制 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | - 数据到达时调用接收方 * 混合：数据到达时以及独立地调用接收方 |
| 支撑材料 | - |
5.1.1.2. E2E 协议应支持受保护的非周期性通信¶
| 描述 | E2E 协议应支持受保护的非周期性通信。应支持以下内容： * 同步调用（返回可用时激活客户端） * 基于 E2E 结果决定是否在服务器侧应用方法调用 |
|---|---|
| 理由 | 面向服务的通信的 E2E 机制 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | 经由 SOME/IP 方法的面向服务的客户端-服务器通信。 |
| 支撑材料 | - |
5.1.1.3. E2E 协议应支持通信对端的动态重启¶
| 描述 | E2E 协议应支持： * 通信对端的动态重启及其迟启动 * 接收方与发送方不同的消息频率/周期（过采样/欠采样） * 具有不同消息周期的多个接收方。 |
|---|---|
| 理由 | 根据通信伙伴启动行为的差异和预期的消息频率，保护机制需要处理迟启动或过采样/欠采样。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | 底盘主 ECU 应用与动力转向 ECU 应用之间的通信，以防止传输数据损坏导致错误的转向干预。 |
| 支撑材料 | - |
5.1.1.4. E2E 协议应支持可变长度的传输数据¶
| 描述 | E2E 协议应支持可变长度的传输数据。 |
|---|---|
| 理由 | 根据所用协议，保护机制需要处理静态或动态长度的传输数据。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | 经由 SOME/IP 传输受 E2E 保护的可变长度数组。 |
| 支撑材料 | - |
5.1.2. E2E 检测的故障¶
E2E 协议被定义为覆盖 4.1 节中描述的多种故障。但是，能够检测到哪类故障取决于通信类型，例如对于非周期性的基于事件的通信，E2E 协议机制无法检测到通信数据的丢失。
5.1.2.1. E2E 协议应提供超时检测机制¶
| 描述 | E2E 协议应提供可配置的机制来检测超时和延迟数据。 |
|---|---|
| 理由 | 该机制可用于检测通信数据的丢失和延迟，如 ISO 26262-6:2018 所要求。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | 周期性面向服务的通信中丢失或延迟事件的检测 |
| 支撑材料 | - |
注意： 用于识别非周期性方法通信中丢失或延迟方法响应的超时检测机制无法由 E2E 协议规范提供。这类机制必须由应用自身规定和实现，或作为通信管理功能的一部分实现。
5.1.2.2. E2E 协议应提供数据损坏的检测机制¶
| 描述 | E2E 协议应提供数据损坏的检测机制。 |
|---|---|
| 理由 | 该机制可用于检测损坏的通信数据，如 ISO 26262-6:2018 所要求。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | • 发送方/接收方通信中损坏消息的检测 * 周期性基于事件的通信中损坏消息的检测 * 非周期性方法通信中损坏的方法请求/响应的检测 |
| 支撑材料 | - |
5.1.2.3. E2E 协议应提供伪装或错误寻址的检测机制¶
| 描述 | E2E 协议应提供伪装或错误寻址的检测机制。 |
|---|---|
| 理由 | 该机制可用于检测通信数据的伪装或错误寻址，如 ISO 26262-6:2018 所要求。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | • 周期性基于事件的通信中伪装或错误寻址数据的检测 * 非周期性方法请求/响应中伪装或错误寻址数据的检测 |
| 支撑材料 | - |
5.1.2.4. E2E 协议应提供数据重复、插入或错误序列的检测机制¶
| 描述 | E2E 协议应提供数据重复、插入或错误序列的检测机制。 |
|---|---|
| 理由 | 该机制可用于检测重复、插入的通信数据或具有错误序列的数据，如 ISO 26262-6:2018 所要求。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | • 发送方/接收方通信中重复、插入的消息或错误消息序列的检测 * 周期性基于事件的通信中重复、插入的消息或错误消息序列的检测 * 非周期性方法请求中重复方法响应的检测 |
| 支撑材料 | - |
5.1.3. E2E 算法与 Profile¶
E2E 协议被定义为覆盖各种大小的交换数据和不同类型的物理总线介质。因此，创建了许多 E2E Profile。每个 E2E Profile 提供 5.1.2 节所要求的 E2E 措施集合。
5.1.3.1. E2E 协议应提供不同的 E2E Profile¶
| 描述 | E2E 协议应提供 E2E Profile，其中每个 E2E Profile 完整地定义一个特定的安全协议（包括报头结构、作为状态机的行为、错误处理等）。每个 E2E Profile 应是其下层所用特定通信栈（FlexRay、CAN、CAN FD、LIN 或 Ethernet）、所用数据长度和数据频率以及交换数据所需完整性等级（见 [1]）的高效解决方案。注意： 每个通信栈（例如 FlexRay）具有不同的 BER，它取决于例如： * 信道上的误码率 * 硬件的 FIT 值 * ECU 数量 * 拓扑（例如 CAN->Gateway->FR） * 开放/封闭传输系统 这些 Profile 应覆盖上述因素的典型组合。 |
|---|---|
| 理由 | 安全相关通信伙伴的互操作性，QM 通信系统的使用。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | • 用于 CAN/CAN FD 的带 8 位 CRC 的 E2E Profile * 用于长 FlexRay 信号的带 16 位 CRC 的 E2E Profile * 用于 Ethernet 的带 32/64 位 CRC 的 E2E Profile |
| 支撑材料 | - |
5.1.3.2. 每个 E2E Profile 应定义一组保护机制及其行为¶
| 描述 | 每个定义的 E2E Profile 应： * 精确地定义一组机制（例如特定多项式的 CRC）。 * 以半形式化的方式定义其行为（包括状态机、错误处理等）。注意： 对于 CP，E2E Profile 在 E2E 库中提供。 |
|---|---|
| 理由 | Profile 不只是机制列表（例如 CRC8 + 序列号），而是管理整个过程的整体逻辑。仅标准化报头远远不够。需要标准化的行为才能实现互操作性。应定义机制以检测 ISO 26262-6:2018 [1] 附录 D.2.4 中描述的通信故障。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | 通常每个 Profile 每个通信伙伴（发送方、接收方、客户端或服务器）一个状态机就足够了。ECU1 与 ECU2 通信。ECU1 拥有与 ECU2 不同的 E2E Profile 实现。 |
| 支撑材料 | - |
5.1.3.3. 每个 E2E Profile 应具有唯一的 Profile ID¶
| 描述 | 每个 E2E Profile 应具有唯一的 Profile ID。 |
|---|---|
| 理由 | 需要确保提供方和消费方使用相同的 E2E Profile。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | - |
| 支撑材料 | - |
5.1.3.4. 每个 E2E Profile 应使用特定保护机制的适当子集¶
| 描述 | 定义的每个 E2E Profile 应使用以下机制的适当子集： * 不同大小的序列计数器（也可用作存活计数器（alive counter）） * 不同位长的 CRC * ID：源 ID、目的 ID、数据 ID * 超时 * 长度 换言之，不得使用未列出的机制。在每个 E2E Profile 中，序列计数器和 ID（如使用）应全部是被传输数据元素的一部分。但是，允许在给定 Profile 中将序列计数器和/或 ID「隐藏」（不传输），但包含在校验和中。 |
|---|---|
| 理由 | 这些是用于通信保护的典型机制，并且它们可以由 AUTOSAR 实现。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | 一个示例 Profile 中使用的机制：4 位序列计数器、CRC8、数据 ID、超时。 |
| 支撑材料 | - |
5.1.3.5. E2E Profile 中使用的 CRC 应不同于底层物理通信协议使用的 CRC¶
| 描述 | 每个 E2E Profile 中使用的 CRC 应不同于该 Profile 预期配合使用的底层通信协议（FlexRay、CAN、CAN FD、LIN、Ethernet）所使用的 CRC。 |
|---|---|
| 理由 | 两次使用相同的多项式（一次在通信栈中、一次在 E2E 中）提供的联合检测率显著低于使用两个不同的多项式。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | 如果 Profile X 预期只用于 FlexRay，则其 CRC 应不同于 FlexRay 的 CRC。 |
| 支撑材料 | - |
5.1.3.6. E2E 协议应向应用提供 E2E Check 状态¶
| 描述 | E2E 协议应向应用层提供单个被检查数据的 E2E 状态。 |
|---|---|
| 理由 | 错误处理策略是「应用相关的」，无法「先验定义」。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | 使使用 E2E 协议的应用能够进行依赖于错误的反应。 |
| 支撑材料 | - |
5.1.3.7. E2E 协议应向应用提供 E2E 整体状态¶
| 描述 | E2E 协议应可选地向应用层提供迄今已检查数据的 E2E 整体状态。 |
|---|---|
| 理由 | 错误处理策略是「应用相关的」，无法「先验定义」。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | 使使用 E2E 协议的应用能够进行依赖于错误的反应。 |
| 支撑材料 | - |
5.1.3.8. 应提供面向短到大数据的 ECU 间通信的 E2E 保护机制¶
| 描述 | E2E 协议应支持经由 TCP/IP 以及经由 LIN/CAN/CAN TP/CAN FD/FlexRay/Ethernet 对短的（例如 8 字节）和大的（例如 4KB，直至 4MB，视应用需要）动态长度复合数据进行保护。注意： 受保护数据的最大长度取决于架构，需要在使用 E2E 协议 Profile 的项目中通过定量分析评估。 |
|---|---|
| 理由 | 大型复合数据需要特定的保护机制。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | 底盘主 ECU 应用与动力转向 ECU 应用之间的通信。 |
| 支撑材料 | - |
5.1.3.9. E2E 监督的实现应至少提供其中一个 E2E Profile¶
| 描述 | E2E 监督（E2E Supervision）的实现应至少提供其中一个 E2E Profile。 |
|---|---|
| 理由 | 协议的实现至少需要一个 Profile，否则状态机将无法工作。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | E2E 需要至少一个 Profile 来监督一次通信。 |
| 支撑材料 | - |
5.2. 功能安全适用性与整体安全假设¶
5.2.1. E2E 协议的实现应符合 ISO 26262¶
| 描述 | E2E 协议应按照 ISO 26262 [1] 实现。 |
|---|---|
| 理由 | E2E 通信保护是汽车安全相关量产产品中的先进实践。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | 底盘主 ECU 应用与动力转向 ECU 应用之间的通信。 |
| 支撑材料 | - |
5.3. E2E 转换器（E2E Transformer）¶
E2E 转换器（E2E Transformer）经由 RTE 调用，位于 RTE 与 E2E 库之间。它负责 E2E 保护的配置和状态管理。
5.3.1. 应提供 E2E Transformer¶
| 描述 | 应提供一个可经由 RTE 调用、位于调用方（RTE）与 E2E 库之间的 E2E Transformer。它应负责 E2E 保护的配置和状态管理，并且应为至少由 Some/IP 和基于 COM 的转换器序列化的消息提供保护。 |
|---|---|
| 理由 | E2E 库配置和管理的全部复杂性都留在 E2E Transformer 内部。得益于此，无需附加的集成者代码即可实现 E2E 保护。 |
| 依赖项 | - |
| 适用平台 | CP |
| 用例 | 底盘主 ECU SW-C 与动力转向 ECU SW-C 之间的通信。Some/IP 是 Ethernet 的序列化协议。基于 COM 的转换器通常用于 CAN、FlexRay、CanFD。 |
| 支撑材料 | - |
5.4. E2E 库¶
E2E 库以由 SW-C 调用的库函数的形式提供一组安全协议。它提供：
- E2E Profile 1、2、4、5、6、7、11、22。
- E2E 状态机
注意：
每个通信栈（例如 FlexRay）具有不同的错误率，它取决于例如：
- 信道上的误码率
- 硬件的 FIT 值
- ECU 数量
- 拓扑（例如 CAN->Gateway->FR）
- 开放/封闭传输系统
- 安全相关消息的频率
基于使用验证（proven-in-use）解决方案的这些 Profile 应覆盖上述因素的典型组合。
5.4.1. E2E 库应调用 CRC 库的 CRC 例程¶
| 描述 | E2E 库不应提供 CRC 例程实现。相反，它应调用 CRC 库（文档 UID 016）的 CRC 例程。 |
|---|---|
| 理由 | 复用既有的 AUTOSAR 功能 |
| 依赖项 | - |
| 适用平台 | CP |
| 用例 | 在某个 Profile 中使用 CRC 库的 CRC8 保护 CAN 通信。 |
| 支撑材料 | - |
5.4.2. SW-C 应容忍一定数量的无效/损坏的接收数据元素¶
| 描述 | SW-C 应容忍一定数量的无效/损坏但未被 E2E 检测到的数据元素，该数量按所用 E2E 协议的架构特定安全分析定义。 |
|---|---|
| 理由 | 允许（在接收到的信号序列中）至少一个未被 E2E 机制检测到的无效信号，使所应用 E2E Profile 的适用性成为可能。 |
| 依赖项 | - |
| 适用平台 | AP、CP |
| 用例 | 示例 1：产生与原始信号相同 CRC 的多位错误（例如 5 个损坏位）。示例 2：E2E 库中的随机硬件故障或软件故障导致 CRC 序列计数器计算无法检测到错误。 |
| 支撑材料 | - |
6. 参考文献¶
[1] ISO 26262:2018（所有部分）——道路车辆——功能安全
https://www.iso.org
AUTOSAR_FO_TPS_StandardizationTemplate
AUTOSAR_FO_TR_Glossary
A. 变更历史¶
A.1. R23-11 的变更历史¶
A.1.1. R23-11 中新增的需求¶
无
A.1.2. R23-11 中变更的需求¶
无
A.1.3. R23-11 中删除的需求¶
无