AUTOSAR_FO_RS_E2E

本文件范围

本文件规定了E2E协议的要求。E2E协议定义了抽象机制，以根据ISO 26262:2018（所有部分）的要求提供端到端通信保护。这些机制应允许通过非安全相关通信路径安全传输定义的所有完整性级别的安全相关数据。本文件仅涵盖协议部分，因此仅部分涵盖端到端路径。

这些要求应作为详细E2E机制规范及其在AUTOSAR实现中使用的基础。

注：该文件包含经典平台文件中的众所周知的要求，并在可预见的范围内为自适应平台带来了新的要求。

自适应平台中的E2E保护用例正在详细说明中。有关相关用例的更多详细信息将在本文档的下一版本中添加。

这是一份规范草案，旨在向AUTOSAR开发社区指明讨论的预期范围和方向。本规范的质量措施较少，合作伙伴之间的讨论较少，而且通常可能处于不太成熟的状态。

如何阅读本文档

文件约定

AUTOSAR文件中的需求表示遵循[TPSSTDT_00078]中规定的表格，参见标准化模板，可追溯性支持一章。
[TPS_STDT_00053]中规定的义务表达的口头形式应用于指示要求，参见标准化模板，可追溯性支持一章。

同义词和缩写

下面的词汇表包括与 AUTOSAR_RS_E2E 相关的首字母缩写，但不包括在 AUTOSAR 词汇表中。

缩写	描述
E2E	End-to-End
E2E Profile	一组组合的E2E度量作为特定通信堆栈的有效解决方案。
BER	比特错误率-字节流中损坏比特的比率，例如1e-5。

功能概述

与安全相关的汽车系统通常使用安全的数据传输来保护部件之间的通信（根据ISO 26262:2018（所有部件）的要求），这意味着：

1. 应防止通信错误（例如，通过适当的软件架构和验证）。
2. 如果仅预防错误是不够的（例如，对于ECU之间的通信），那么
   • 应在运行时检测到足够程度的错误（参见诊断覆盖率、安全故障率），并且
   • 未检测到的危险错误的比率应低于某个允许的限值（参见残余错误率、每小时危险故障的概率或按需危险故障的可能性）。

功能安全和通信

关于安全相关系统中的信息交换，以下列出的故障原因或影响的实时检测机制可用于设计适当的安全概念，例如，实现共享公共通信基础设施的系统元件之间不受干扰的自由度（见ISO 26262-6:2018，附件D.2.4）。

通信故障类型	描述
信息的重复	一种通信故障，其中信息被多次接收。
信息丢失	一种通信故障，从传输的信息流中删除信息或部分信息。
信息延时	一种通信故障，信息的接收时间晚于预期。
插入信息	一种通信故障，将附加信息插入传输信息流中。
伪装	一种通信故障，其中非真实信息被接收方接受为真实信息。
寻址不正确	一种通信故障，即信息被不正确的发送者或不正确的接收者接受。
信息顺序不正确	一种通信故障，它改变了传输信息流中的信息序列。
信息损坏	一种改变信息的通信故障。
来自多个接收器的不对称信息	一种通信故障，接收器确实从同一发送器接收到不同的信息。
来自发送者的信息仅由接收者的子集接收	一种通信故障，其中一些接收器没有接收到信息。
阻止访问通信信道	一种通信故障，其中对通信信道的访问被阻止。

通信故障源

E2E通信保护旨在检测和减轻以下原因引起的通信故障的原因或影响：

1. 软件故障，
2. 随机硬件故障，
3. 瞬态故障这三种来源在以下章节中进行了描述。

软件故障

通信堆栈模块和RTE等软件可能包含系统性故障。系统故障可能发生在系统生命周期的任何阶段，包括规范、设计、制造、运行和维护，并且当情况（例如根本原因的触发条件）相同时，系统故障总是会出现。软件故障的后果可能是通信故障，如数据发送中断、接收器过载（例如缓冲区溢出）或发送器欠载（例如缓冲区时空）。为了防止（或处理）由此产生的故障，必须考虑检测和处理此类故障的适当技术措施（如程序流监控或E2E监督）。

随机硬件故障

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

瞬态故障

瞬态故障通常由外部影响或环境应力引起，包括EMI、ESD、湿度、腐蚀、温度或机械应力（如振动）等影响。

安全端到端通信

为了提供安全的端到端通信，应在AUTOSAR方法中集成一个解决方案，该方法不需要或只需要少量额外的非标准代码（如包装器）。端到端通信保护的功能将由E2E协议支持。

E2E协议提供了：

• 检测[功能安全和通信]中列出的通信故障子集的机制。相关的通信故障取决于通信类型（例如，周期性、非周期性、发送器/接收器等）。
• 配置文件1、2、4、5、6、7、11和22的定义，包括单个数据传输的检查和保护功能。根据所使用的物理总线层和传输数据的大小来选择适当的配置文件。
• 一个可选的状态机，描述独立于所用配置文件的两个专用通信伙伴之间的大量数据传输的E2E监控和状态处理的逻辑算法。

E2E保护概念

E2E保护概念不仅仅是为数据元素添加足够的安全机制（例如，使用E2E配置文件1或2）。为了确保通信信道的完整性达到ISO 26262要求的安全完整性水平，E2E保护概念需要考虑通过需要保护的总线网络传输的数据的安全相关特性。本章提供了实现E2E保护概念的基本原则，该概念侧重于正确性、一致性、完整性、及时性和数据不可用性的检测。
注：对于专注于确保数据可用性的E2E保护概念，需要实现具有足够容错能力的通信信道（例如使用独立冗余信道）。
注：冗余通信信道的使用可能会产生对额外安全机制的需求（例如，确保独立传输时数据流的一致性）。

功能要求

支持的通信模型和功能

E2E协议被定义为支持不同类型的基于消息的通信。
基于信号的通信：

• 周期性/混合周期性发送器/接收器通信面向服务的通信：
  基于周期性/混周期性事件的通信
• 基于非周期性方法的通信（客户端-服务器通信）

E2E检测到的故障

E2E协议被定义为涵盖[功能安全和通信]中描述的许多故障。然而，它取决于可以检测到哪种故障的通信类型，例如，对于基于非周期性事件的通信丢失，不能通过E2E协议机制检测到通信数据。
注：E2E协议规范无法提供超时检测机制来识别非周期性方法通信中丢失或延迟的方法响应。这种机制必须由应用程序本身或作为通信管理功能的一部分来指定和实现。

E2E算法和配置

E2E协议被定义为覆盖各种大小的交换数据和不同类型的物理总线介质。因此，创建了许多E2E配置文件。

E2E协议应提供E2E配置文件，其中每个E2E配置文完全定义了一个特定的安全协议（包括报头结构、作为状态机的行为、错误处理等）。每个E2E配置文件应为下面使用的特定通信堆栈（FlexRay、CAN、CAN FD、LIN或以太网）、使用的数据长度和数据频率以及交换数据所需的完整性级别提供有效的解决方案。

注：每个通信堆栈（如FlexRay）都有不同的BER，这取决于，例如：

• 信道上的误码率
• 硬件的FIT值
• ECU数量
• 拓扑结构（如CAN->网关->FR）
• 开放/封闭传输系统。
  该配置文件应涵盖上述因素的典型组合。

定义的每个E2E配置文件应：

• 精确定义一组机制（例如，特定多项式的CRC）。
• 以半正式的方式定义其行为（包括状态机、错误处理等）。
  注：对于CP，E2E配置文件在E2E库中提供。

每个定义的E2E配置文件应使用以下机制的适当子集：

• 具有不同大小的序列计数器（可替代地用作有效计数器）
• 具有不同比特长度的CRC
• ID：源ID、目的地ID、数据ID
• 超时
• 长度
  换言之，不应使用未列出的机制。在每个E2E配置文件中，序列计数器和ID（如果使用）应该是传输数据元素的全部部分。但是，允许在给定的配置文件中，序列计数器和/或ID被“隐藏”（不传输），但包含在校验和中。

每个E2E配置文件中使用的CRC应不同于底层通信协议（FlexRay、CAN、CAN FD、LIN、以太网）所使用的CRC，给定配置文件应与之一起使用。

E2E Transformer

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

E2E Library

E2E库以SW C调用的库函数的形式提供了一组安全协议。它提供了：

1. E2E配置1、2、4、5、6、7、11、22。
2. E2E状态机
   注意：每个通信堆栈（例如FlexRay）都有不同的错误率，这取决于例如：

• 信道上的误码率
• 硬件的FIT值
• ECU数量
• 拓扑结构（例如CAN->网关->FR）
• 打开/关闭传输系统
• 安全相关消息的频率
  基于已验证的使用中解决方案的配置文件应涵盖上述因素的典型组合。