AUTOSAR_FO_PRS_E2EProtocol

简介和功能概述

E2E通信保护的概念假设与安全相关的数据交换应在运行时受到保护，免受通信链路故障的影响（见下图）。使用E2E通信保护在发送器和接收器之间检测到的故障包括系统软件故障，例如在发送器或接收器的较低通信层上引入的故障，以及由MCU硬件、通信外围设备、收发器、通信线路或其他通信基础设施引入的随机硬件故障。
此类故障的例子包括随机硬件故障（例如CAN收发器的损坏寄存器）、干扰（例如由于EMC）和较低通信层的系统故障（例如RTE、IOC、COM和网络堆栈）。

通过使用E2E通信保护机制，可以在运行时检测和处理较低软件和硬件层的故障。E2E监管提供了E2E通信保护机制，足以满足ASIL D要求的安全相关通信。
保护机制的算法在E2E监督中实现。
E2E监督的调用方负责正确使用E2E监督，特别是为E2E监督例程提供正确的参数。

同义词和缩写

下面的术语表包括与通信管理相关的缩写词和缩写词，这些缩写词和缩略词未包含在[2，FO_TR_Glossary]中。

相关文档

输入文档

[1] ISO 26262:2018 (all parts) – Road vehicles – Functional Safety
https://www.iso.org

[2] Glossary
AUTOSAR_FO_TR_Glossary

[3] Specification of CRC Routines
AUTOSAR_CP_SWS_CRCLibrary

[4] Specification of SW-C End-to-End Communication Protection Library
AUTOSAR_CP_SWS_E2ELibrary

约束和假设

限制

根据所使用的通信类型，E2E通信保护受到限制。从E2E的角度来看，可以区分以下类型：

• 基于信号的通信
• 与事件的面向服务的通信
• 客户端/服务器架构中的面向服务通信
• 信号到服务的转换
  通常，E2E保护机制的行为应该相同。然而，根据通信类型，存在一些限制。

一般限制

在较低层检测到的通信错误（例如以太网FCS、IP报头校验和、UDP校验和、某些/IP报头不规则）将导致丢弃相关消息。因此，这些消息可能根本无法到达应用程序。

基于信号的通信的局限性

它也被称为发送方/接收方通信。

• E2E通信保护仅限于周期性或半周期性数据通信模式，其中接收器对定期接收数据有任何期望，在通信丢失/超时或错误的情况下，它会执行错误处理。
• 如果保护（发送器）或检查（接收器）的E2E功能之一没有定期调用，则可能无法检测到某些通信故障模式（丢失、延迟）。
• 如果在数据元素级别调用E2E保护（例如，从SW Cs或从E2E保护包装器），并且使用1:N通信模型，并且使用多个IPDU发送数据元素，则所有这些I-PDU应具有相同的布局。
• 目前，AUTOSAR不提供通过使用不同的保护机制来描述和处理同一数据元素（例如RTE内）的多个布局的功能，这取决于ECU内和ECU间的通信。因此，对于1:N发送器-接收器关系，E2E保护的用户负责为要保护的数据元素选择一个适当的布局。例如，对于1:N发送器-接收器关系，消息布局可用于将受保护的数据元素传输到位于ECU内和不位于ECU内的接收器。
• 如果给定的发送器-接收器通信仅在ECU内（在微控制器内），则在配置中没有定义串行数据的布局。另一方面，由于通信是在ECU内，在双方，软件可能由同一RTE生成器生成，因此布局的决定可能特定于生成器。建议串行化数据，使CRC位于CRC的配置文件特定位置，计数器位于计数器的配置文件指定位置（类似于ECU间通信）。
• 仅考虑排队发送器-接收器通信的非阻塞特性（不支持排队通信的阻塞特性）。

面向服务的事件通信的局限性

它也称为事件通信。(注意，这里的 name 事件有点混乱，因为需要定期通信。这段视频来自于某些人/知识产权组织的活动。)

• E2E 通信保护仅限于定期或半定期数据通信范式，其中接收方对定期接收数据有任何期望，在通信丢失/超时或错误的情况下，它执行错误处理。
• 如果用于保护(发送方)或检查(接收方)数据的 E2E 功能之一没有定期调用，则可能无法检测到某些通信故障模式(丢失、延迟)。

客户/服务器体系结构中面向服务通信的局限性

指定的方法的 E2E 通信保护限于

• N 个客户端和一个专有服务器之间的通信(N: 1) ，这意味着，一个受 E2E 保护的服务由每个系统正好一个服务器提供。换句话说，如果在数据元素级别调用 E2E 保护，则不支持 N: 1多样性、隐式通信和其他通信模型(特别是客户机-服务器模型)。
  方法的指定 E2E 通信保护可能无法检测到所有的通信故障模式:
• 如果方法请求没有定期调用，那么服务器上接收到的请求可能无法检测到某些通信故障模式(丢失、延迟)。
• 由于定义的 E2E 保护机制不假设服务器对请求数据的客户端有任何先验知识(N: 1通信) ，因此服务器上接收到的请求可能无法检测到特定于客户端的通信故障模式(重复、插入)。在这种情况下，需要在应用层面实施额外的措施，以解决这些未检测到的故障模式，并提供完整的 E2E 保护或论据，表明这些故障模式与特定项目无关。
  以下E2E参数的值由标准定义，不得更改。
• dataIdMode
• counterOffset
• crcOffset
• dataIdNibbleOffset
• offset
  E2E配置文件1、2、11和22不建议在客户端-服务器通信中使用。

信号到服务的翻译

信号到服务的转换仅限于发送方/接收方之间的转换以及与事件的面向服务的通信。

适用于汽车领域

E2E监督适用于实现安全相关的汽车系统，该系统由分布在车辆中不同ECU上的各种SWC实现，并通过通信链路进行交互。监督也可用于ECU内部通信（例如，在同一微控制器中的存储器分区、进程、OSe/VM之间，在CPU核或微控制器之间）。

功能规范

本章包含了E2E监督的内部功能行为规范，包括如何定义E2E标头的布局、如何创建E2E标头、如何评估E2E标头以及如何定义E2EStatemachine。有关E2E监管的一般介绍，请参阅第1章。
像[PRS_E2E_UC_xxx]这样的用例项表示如何使用E2E协议的一般提示。但是，它们不应被理解为要求或限制。

通信保护概述

通信保护机制的一个重要方面是其标准化和针对不同目的的灵活性。这是通过具有一组E2E配置文件来解决的，这些配置文件定义了保护机制、消息格式和一组配置参数的组合。
此外，一些E2E配置文件具有标准的E2E变体。E2E变体只是与给定的E2E配置文件一起使用的一组配置选项。例如，在E2E配置文件1中，CRC和计数器的位置是可配置的。E2E变体1A要求CRC从比特0开始并且计数器从比特8开始。
E2E通信保护的工作原理如下：

• 发送方：在传输的数据中添加CRC或计数器等控制字段；
• 接收器：根据接收的数据评估控制字段，计算控制字段（例如，对接收的数据进行CRC计算），将计算的控制字段与预期/接收的内容进行比较。
  每个E2E配置文件都有一组特定的控制字段，这些字段具有特定的功能行为和用于检测通信故障的特定属性。

E2E配置概况

E2E配置文件提供了一套一致的数据保护机制，旨在防止故障模型中考虑的故障。
每个E2E配置文件通过不同的算法提供了保护通信的替代方式。然而，E2E配置文件具有类似的接口和行为。
每个E2E配置文件都使用以下数据保护机制的子集：

1. CRC，由CRC监督提供；
2. 序列计数器在每次传输请求时递增，在接收器侧检查该值是否正确递增；
3. 活动计数器在每次传输请求时递增，如果值发生变化，则在接收器侧检查该值，但未检查正确的递增；
4. 通过端口发送的每个端口数据元素的特定ID或每个消息组的特定ID（全局到系统，其中系统可能包含几个ECU）；
5. 数据元素或消息组的每个源（例如客户端）的特定ID;
6. 在方法的E2E通信保护的情况下，区分请求和响应的消息类型;
7. 在方法的E2E通信保护情况下，区分正常响应和错误响应的消息结果;
8. 超时检测：
   a) 接收器通信超时
   b) 发件人确认超时
   根据所使用的通信和网络堆栈，这些机制的适当子集被定义为E2E通信配置文件。
   上面的一些机制是在RTE、COM和/或通信堆栈中实现的。然而，为了减少或避免将安全要求分配给这些模块，不考虑这些模块：E2E监管在内部提供所有机制（仅使用CRC监管）。
   E2E配置文件可用于ECU内部和内部通信。E2E配置文件是为特定的通信基础设施指定的，如CAN、CAN FD、FlexRay、LIN、以太网。
   根据系统，用户从E2E监督提供的E2E配置文件中选择要使用的E2E概要文件。

错误检测

内部监督机制错误检测和报告应根据本文件中规定的预定义E2E配置文件执行。

常见类型的E2E配置文件

一些E2E配置文件使用不同配置文件之间共享的常见数据类型这些共享类型将在本节中介绍，而不是在配置文件特定的部分中介绍。

E2E配置文件的一般功能

每个E2E配置文件提供以下3个功能：

1. 保护
2. 转发
3. 检查

“保护”功能，简称为“保护功能”，可创建E2E标头，从而保护要通过通信介质发送的数据。
“转发”功能，简称为“转发功能”，类似于保护功能，为要传输的数据创建标头，但允许对接收的E2E状态进行额外复制。该功能的主要用例是SignalService Translation，例如接收到受E2E保护的信号，并且应在输出侧复制E2E状态。
“检查”功能，简称为“检查功能”，评估接收到的消息的E2E标头，并检查是否发生通信故障。这些故障反映在返回的E2E状态中。
除了单个E2E配置文件外，E2E状态机还会在更长的时间内评估返回的E2E状态。

计数器的功能

在接收机侧，通过将接收数据的计数器与先前接收数据的计数进行比较，检测到以下情况：
1.重复：
a.自上次调用E2E监督检查功能以来，没有新的数据到达，
b.数据重复
2.OK：
a.计数器增加1（即没有数据丢失），
b.计数器增加1以上，但仍在允许的范围内（即一些数据丢失），
3.错误：
a.计数器的增量超过允许值（即数据丢失过多）。
情况1对应于失效的活动计数器检查，而情况3对应于失败的序列计数器检查。
以下文档部分中的UML图更详细地说明了上述需求。

超时检测

当接收器独立于数据传输运行时，即当接收器没有被阻止等待数据元素或相应的消息时，而是当接收器读取当前可用的数据时（即，检查新数据是否可用），前面提到的机制（例如，配置5:CRC、计数器、数据ID）能够检查接收到的数据元素的有效性。然后，通过计数器，接收器可以检测通信丢失和超时。
属性State->NewDataAvailable = FALSE表示传输介质（例如RTE）报告在传输介质上没有新的数据元素可用。属性State->Status=E2E_PXXSTATUS_REPEATED表示传输介质（如RTE）提供了新的有效数据元素，但该数据元素具有与先前有效数据元素相同的计数器。这两种情况都表示自上一个周期以来更新的有效数据不可用。

循环冗余检查

循环冗余校验，简称CRC，用于确定比特是否在消息传输过程中翻转。
与基于计数器评估指示的错误相反，CRC错误不太可能是“错误警报”（例如，当使用良好的CRC多项式时，检测到的CRC错误指示发生了数据损坏）。考虑到这一事实，没有任何检测到的CRC错误的数据流包含大量未检测到的损坏数据是不可信的。
因此，对CRC错误作出更严格的反应是足够的。在检测到后续数据流上的第一CRC错误之后，可能包含大量未检测到的损坏数据。
接收器可容忍的CRC错误的最大数量应受到限制，因为在其错误检测和鉴定时间间隔内，接收到多个未检测到的错误消息的概率不容忽视。错误的CRC表示通信信道的完整性受到影响。
接收器中设计的容错（见UC_E2E_00170）可能会因此而被超过。

E2E配置规范-通用部分

本章包含用于多个配置文件规范的E2E配置文件规范部分。E2E配置文件的行为独立于特定配置文件进行描述。文本和图形使用占位符，如“XX”，这些占位符被特定于配置文件的值或文本所取代。所有配置文件特定的内容，包括这些占位符，都在相应的配置文件特定子章节中定义。本章不适用于方法配置文件。本章仅适用于DataID和Length字段是配置文件头的一部分的配置文件。E2E机制可以检测以下故障或故障的影响：

计数器

在E2E配置文件中，计数器通过E2E配置进行初始化、递增、重置和检查。
计数器未被E2E监督的调用方操作或使用。
在E2E配置文件中，在发送方，对于数据元素的第一个传输请求，计数器应初始化为0，并应为每个后续发送请求增加1。当计数器达到最大值时，它将在下一个发送请求中以0重新启动。计数器的最大值取决于计数器的大小。它是0xFF（8位计数器）、0xFF’FF（16位计数器）或0xFF’FF’FF（32位）。

数据ID

唯一的数据ID用于验证每个传输的安全相关数据元素的身份。
在E2E配置文件中，数据ID在通信系统的网络中应该是全局唯一的（由多个ECU组成，每个ECU发送不同的数据）。
在使用E2E监管来保护数据元素的情况下（即从RTE调用），由于通信的多样性（1:1或1:N），数据元素的消费者只期望特定的数据元素，该数据元素由E2E监管使用数据ID进行检查。
在使用E2E监督来保护消息（即从COM调用）的情况下，接收方COM在接收时仅期望特定消息，该消息由E2E监督使用数据ID进行检查。

长度

引入Length字段是为了支持可变大小的长度-存储序列化数据的Data[]数组在每个周期中可能具有不同的长度。长度包括用户数据+E2E报头（CRC+计数器+长度+DataID）。

CRC

E2E配置文件根据消息的长度使用不同长度的CRC，以确保高检测率和高汉明距离。
CRC应在整个E2E报头（不包括CRC字节）和用户数据上进行计算。

超时检测

前面提到的机制（CRC、计数器、数据ID、长度）能够在独立于数据传输执行接收器时，即当接收器没有被阻止等待数据元素或相应的消息时，而是如果接收器读取当前可用的数据（即，检查新数据是否可用），检查接收到的数据元素的有效性。然后，通过计数器，接收器可以检测通信丢失和超时。

创建E2E头

E2E_PXXProtect

函数E2E_PXXProtect（）执行本节下图中指定的步骤。

E2E_PXXProtect（）中的步骤“Verify inputs of the protection function”应如下图所示。

E2E_PXXProtect（）中的步骤“Compute offset”应如下图所示。

E2E_PXXProtect（）中的步骤“Write Length”应如下图所示。

E2E_PXXProtect（）中的步骤“Write Counter”应如下图所示。

E2E_PXXProtect（）中的步骤“Write DataID”应如下图所示。

E2E_PXXProtect（）中的步骤“Compute CRC”应如下图所示。

E2E_PXXProtect（）中的步骤“Write CRC”应如下图所示。

E2E_PXXProtect（）中的步骤“Increment Counter”应如下图所示。

E2E_PXXForward

E2E配置文件的E2E_PXXForward（）函数由SW-C调用，以保护其应用程序数据并转发接收到的E2E状态，用于将基于信号的转换为面向服务的通信等用例。如果接收到的E2E状态等于E2E_P_OK，则函数的行为应与E2E_PXXProtect（）相同。

函数E2E_PXXForward（）执行本节下图中指定的步骤。

E2E_PXXForward（）中的步骤“Verify inputs of the forward function”应如下图所示。

E2E_PXXForward（）中的步骤“Write Counter”应如下图所示。

E2E_PXXForward（）中的步骤“Write DataID”应如下图所示。

评估E2E头

E2E_PXXCheck

函数 E2E_PXXCheck ()执行本节中的以下图表所指定的操作，如下图所示。

E2E _ PXXCheck ()中的“Verify input of the check function”步骤应该如下图所示。

E2E _ PXXCheck ()中的“Read Length”步骤应该如下图所示。

E2E _ PXXCheck ()中的“Read Counter”步骤应该如下图所示。

E2E _ PXXCheck ()中的“Read DataID”步骤应该如下图所示。

E2E _ PXXCheck ()中的“Read CRC”步骤应该如下图所示。

E2E _ PXXCheck ()中的“Do Checks”步骤应该如下图所示。

协议使用和指南

本章包含在设计和实施安全相关系统时使用E2E监督的要求，这些系统依赖于E2E通信保护，与某些特定功能没有直接关系。请注意，[功能规范]还提供了一些关于用法的要求。
像[PRS_E2E_UC_xxx]这样的用例项表示如何使用E2E协议的一般提示。但是，它们不应被理解为要求或限制。

E2E和SOME/IP

对于E2E通信保护与SOME/IP的组合，需要有一个通用的在线协议定义。根据体系结构属性，需要相应地配置和使用实现组件。

通常，所有可用的E2E配置文件都可以与SOME/IP组合使用。然而，它们可能有限制，例如数据的最大可用长度，或者仅限于固定长度的消息。

E2E标头的大小取决于所选的E2E配置文件。
对于配置文件1、2、4、5、6、7、11和22，应在串行化的SOM/IP消息的以下部分上计算E2E CRC。

1. 请求ID（客户端ID/会话ID）[32位]
2. 协议版本[8位]
3. 接口版本[8位]
4. 消息类型[8位]
5. 返回代码[8位]
6. 有效载荷[可变大小]

对于4m、7m、8m和44m剖面，应在串行化的SOM/IP消息的以下部分上计算E2E CRC。

1. 有效载荷[可变大小]

根据所选的偏移值，E2E标头应放置在返回代码之后。默认的偏移量是64位，它将E2E标头正好放在返回代码之后。

客户端-服务端通信

当客户端向服务器发送请求时，无论是常规响应还是错误响应，服务器都应该使用接收到的计数器作为响应的序列计数器。

创建了一些用于客户端-服务器通信的特殊配置文件。这些配置文件的名称由字母“m”标识。它们包含用于客户端-服务器通信的特殊功能。

但是，所有其他配置文件也可以用于客户端-服务器通信。在这种情况下，必须考虑以下因素：
对于客户端-服务器通信，服务器端的MaxDeltaCounter应设置为序列计数器值范围的最大值。
对于客户端-服务器通信，客户端上的MaxDeltaCounter应设置为1。

由于客户端的发送间隔不同，使用的计数器将以不同的速率递增，因此计数器跳跃是不可避免的。由于使用了计数器范围的最大值，所有可能的跳跃都是有效的。

尽管如此，服务器可以从两个或多个客户端接收相同的计数器，这将在服务器端引发E2E_P_REPEATED错误。由于客户端-服务器通信的E2E保护无法可靠地检测服务器端的计数器相关错误，因此检查功能可能引发的E2E_P_REPEATED状态代码可以解释为E2E_P_OK。

为了检测特定的通信故障模式，例如丢失，需要在客户端进行最后期限监控。由于请求和响应计数器必须相等，因此无法通过E2E协议进行最后期限监控，这必须由E2E协议用户实现。

定期使用E2E检查

E2E检查功能应在FTTI中至少调用一次（FTTI用于安全目标，从中得出该E2E检查的要求）。

错误处理

E2E监督本身不处理检测到的通信错误。它只检测单个接收到的数据元素的此类错误，并将此信息返回给呼叫者（例如，SW Cs），呼叫者必须做出适当的反应。应用程序错误处理的一般标准化通常是不可能的。
E2E监督的用户（呼叫者），特别是接收器，应该为E2E监督检测到的故障提供错误处理机制。

数据、通信总线的最大长度

对于给定的CRC，消息的长度和所实现的汉明距离是相关的。为了确保所需的诊断覆盖范围，需要适当选择CRC保护的数据元素的最大长度。E2E配置文件旨在保护ECU之间的通信，其长度如表9.1所示。本节中所述的所有长度值都是基于特定场景下适当汉明距离的假设，而没有明确列出这些假设。因此，实际合适的值可能会根据用例场景而有所不同。

在E2E配置文件1和2中，汉明距离是2，直到给定的长度。由于采用了8位CRC，突发错误检测最多可达8位。

在通过FlexRay进行ECU间通信的情况下，受E2E配置文件1、2、11或22保护的完整数据（包括应用程序数据、CRC和计数器）的长度不应超过32字节。

该要求仅包含在E2E型材设计期间评估的合理最大长度。用户仍有责任确保对特定系统使用E2E监督实现的E2E通信保护的充分性。

在通过FlexRay、CAN、CAN FD进行ECU间通信的情况下，如果可以通过对特定用例或网络架构的分析来证明，则可以采用（扩展或减少）以太网建议的最大数据长度。

在CAN或LIN的情况下，受E2E配置文件1或11保护的完整数据元素（包括应用程序数据、CRC和计数器）的长度不应超过8字节。

受E2E配置文件4、5、6或4m保护的完整数据（包括应用程序数据和E2E标头）的长度不应超过4kB。

受E2E配置文件7或7m保护的完整数据（包括应用程序数据和E2E标头）的长度不应超过4MB。

功能安全要求

当使用E2E监督时，使用E2E监管的特定系统的功能或技术安全概念的设计者应评估该系统中受保护数据的最大允许长度，以确保适当的错误检测能力。

因此，特定系统的特定最大长度可能比为E2E配置文件定义的推荐最大适用长度更短（或者在某些罕见情况下甚至更长）。

如果受保护的数据长度超过网络总线帧限制（或有效载荷限制），则可以在E2E通信保护之后在发送方对数据进行分段，并在E2E评估之前在接收方对数据进行组装。在分段/取消分段过程中可能发生的故障可被视为“信息损坏”。

在设计特定系统的功能或技术安全概念时，E2E的任何用户都应确保在发送器和接收器之间的数据元素序列中，由配置文件1、11、2、22保护的一个未检测到的错误数据元素的传输不会直接导致违反该系统的安全目标。

换言之，SW-C应能够容忍一个错误数据元素的接收，其错误未被E2E监督检测到。不需要的是SW-C容忍两个连续的未检测到的错误数据元素，因为两个连续数据不太可能是错误的，并且对于这两个数据，错误仍然未被E2E监督检测到。

当使用LIN作为底层通信网络时，对于总线上相同的比特错误率，协议级别的残余错误率要高出几个数量级（与FlexRay和CAN相比）。与FlexRay（CRC-24）和CAN（CRC-15）的协议CRC相比，LIN校验和具有不同的特性（例如，hamming距离），导致来自总线的未检测到的错误数量更高（例如。

由于EMV）。为了在应用级别上实现最大允许的残余错误率，根据总线协议级别上的保护强度，可能需要应用CRC的不同错误检测能力。

具有E2E_P01DataIDMode=E2E_P01_DATAID_BOTH的E2E配置文件1和具有E2E_P11DataIDMode＝E2E_P11_DATAID-BOTH的E2E配置文件11使用隐式2字节数据ID，在该隐式数据ID上计算CRC8。由于两个不同2字节数的CRC可能会导致相同的CRC，因此用户必须采取一些预防措施。请参见SWS_E2E_UC_00072和PRS_E2EE_UC_00073库项目。

E2E监管的任何用户都应确保，在通信网络的一个实施方案中，受E2E监管保护的每个安全相关数据源都有一个唯一的源ID（E2E配置文件4m、7m）。

消息布局

本章提供了关于如何定义或应该定义安全相关信息的一些要求和建议。这些建议也可以扩展到非安全相关的数据传输。

信号与字节限制的对齐

本章提供了关于如何定义或可以定义安全相关数据结构的一些要求和建议。如果发现足够的话，它们也可以扩展到非安全相关的数据结构。
当使用E2E配置文件时，长度＜8位的消息应分配给消息的一个字节，即它们不应跨越两个字节。
使用E2E配置文件时，长度>=8位的消息应以消息的字节限制开始或结束。

当使用E2E配置文件时，要保护的数据的长度应该是8位的倍数。
前面的建议导致uint8、uint16和uint32类型的信号分别精确地适合消息的一个、两个或四个字节。这些建议还导致对于uint8、uint16和uint32，比特偏移是8的倍数。

下图是没有与字节对齐的信号（CRC、Alive和Sig1）示例。

未使用的位

在受保护的数据结构中，可能会出现某些位不被使用的情况。在这种情况下，发送方不发送由这些位表示的信号，接收方也不期望接收由这些位表示的信号。为了有一个系统定义的数据结构和发送方-接收方行为，未使用的位被设置为已定义的默认值之前，计算 CRC。
任何使用 E2E-Profiles 的发送方都应该将消息的所有未使用区域填充为消息配置的默认值。
对于 I-PDU 的基于信号的通信，这在系统模板参数 ISignalIpdu.unusedBitPattern 中定义。UnusedBitPattern 属性实际上是一个8位 Byte 模式。它可以取0x00到0xFF 之间的任何值。通常使用0xFF。

字节序

对于每个大于1字节的信号(例如 uint16，uint32) ，信号的字节需要放置在相关的 endianness 中。有两种方法可以做到这一点:

1. 首先从最小有效字节开始-字节的重要性随着字节重要性的增加而增加。这就是所谓的小恩典(也就是说，首先是小尾巴)。
2. 首先从最重要的字节开始-字节的重要性随着字节重要性的增加而降低。这就是所谓的大端(即大端优先)。

对于信号通信，相反，底层 COM 堆栈负责将每个信号复制到/从 I-PDU 中(即将一组变量序列化到一个数组中)。一个 I-PDU 是通过网络传输的，没有任何改变。在将信号放入 I-PDU 之前，如果需要，COM 可以将字节 Endianness 的值更改为:

1. 发送方转换数据的字节 Endianness 值。
2. 发送方在 I-PDU (序列化信号)上复制转换后的数据，同时仅从信号中复制使用的位。
3. 发送者 COM 将未改变的 I-PDU 交付给接收者 COM (I-PDU 只是一个未被网络栈的下层改变的字节数组) 。
4. 接收器 COM 转换接收的 I-PDU 中信号的 Endianness (如果配置的话)。它也可以做符号扩展(如果配置) 。
5. 接收器 COM 返回转换后的信号。
   为了实现高水平的互操作性，汽车网络建议使用特定的字节顺序，如下表所示。
   
   E2E 最初瞄准的网络是 FlexRay、 CAN 和 LIN，这些网络是 Little Endian，其结果是满足以下要求:
   E2E 配置文件的任何用户都应该将多字节数据放置在与底层通信网络相同的字节顺序中。

数据ID的配置约束

数据ID

为了能够验证数据元素或信号组的身份，在通信 ECU 的一个系统中不允许两个元素中的任何一个具有相同的数据 ID (E2E 配置文件1,4,5,6,7,11,4m,7m)或相同的 DataIDList [](E2E 配置文件2,22)。

建议数据 ID 的值由中央机构而不是由软件组件的开发人员分配。数据 ID 在基于组件的软件工程模板中定义，然后在 E2E_pXXconfig 结构中实现。

E2E 协议的任何用户都应该确保在通信网络的一个实现中，受 E2E 协议保护的每个与安全相关的数据元素都具有唯一的数据 ID (E2E 概要1,4,5,6,7,11,4m,7m)或唯一的 DataIDList [](对于 E2E 概要2,22)。

注意: 对于配置文件1的要求(PRS_E2E_UC_00071)在某些情况下可能不够，因为数据 ID 比 CRC 长，这导致了额外的要求 PRS_E2E_UC_00072和 PRS_E2E_UC_00073。在配置文件1的情况下，ID 可以通过双重数据 ID 配置(每次数据 ID 的两个字节都包含在 CRC 中)在 CRC 中进行编码，或者在交替的数据 ID 配置(数据 ID 的高字节或低字节可以放在 CRC 中，取决于 Counter 的奇偶性)中，有不同的附加要求/约束在下面的章节中描述。

E2E配置文件1和11的双数据ID配置

在E2E配置文件1和11中，CRC是8比特，而数据ID是16比特。在双数据ID配置中（数据ID的两个字节每次都包括在CRC中），就像在E2E变体1A中一样，所有16位总是包括在CRC计算中。因此，数据元素DE1和DE2的两个不同的16比特数据ID DI1和DI2可以具有相同的8比特CRC值。现在，一种可能的故障模式是例如网关错误地将安全相关信号DE1路由到DE2的接收器。DE2的接收器接收DE1，但由于DI1和DI2相同，接收器可能接受该消息（这假设意外地计数器也是正确的，并且数据长度可能与DE1和DE2相同）。

为了解决这个问题，还有一些限制ID空间使用的附加要求。具有ASIL B及以上的数据元素的数据ID应具有唯一的CRC，具有ASIL A要求的信号在给定数据元素/信号长度的数据ID上应具有唯一CRC。

双数据ID配置中的配置文件1或11的任何用户应确保假设同一系统（车辆）上有两个数据元素DE1和DE2：对于具有数据ID DI1的ASIL B、ASIL C或ASIL D要求的任何数据元素DE2，不应存在具有数据ID DI2的任何其他数据元素（任何ASIL的）DE2，其中：

存在具有数据ID DI2的（任何ASIL的）任何其他数据元素DE2，其中：

上述要求将具有ASIL B、C、D的数据的数据ID的使用限制在给定ECU中的255个不同值，但提供了在16位命名空间内定义数据ID的灵活性。

对于具有ASIL A要求的数据元素，该要求较弱——它要求相同长度的ASIL A信号不存在CRC冲突：

双数据ID配置中配置文件1或11的任何用户应确保，假设在同一系统（车辆）上有两个数据元素DE1和DE2：对于具有数据ID DI1的ASIL A要求的任何数据元素DE2，不应存在具有数据ID DI2且长度与DE1相同的任何其他数据元素DE2（具有ASIL A需求），其中

以上两个需求PRS_E2E_UC_0072和PRS_E2E.UC_0073假设DE1和DE2在同一系统上。如果DE1和DE2是排他性的（即，使用DE1或DE2，但决不能在同一系统/车辆配置中同时使用，例如，DI在轿跑车配置中可用，DI2在旅行车配置中可用），则允许CRC（DI1）=CRC（DI2）。

E2E配置文件1和11的替代数据ID配置

在交替数据ID配置中，根据计数器的奇偶性，数据ID的高字节或低字节被交替地放入CRC中。在此配置中，需要两个连续的数据来验证数据标识。这与校验和或软件的可靠性无关，而是算法约束，因为在每个单个数据上，只有一个数据ID字节被传输，因此需要两次连续接收来验证接收到的数据的数据ID。

配置E2E配置文件1和11

在E2E配置1和11的半字节数据ID配置中，低字节不被发送，而是被包括在CRC中。因为低字节的长度为8位，所以它与CRC相同。因此，如果两个数据ID在低字节中不同，则在数据ID低字节上产生不同的CRC。
数据ID配置中配置文件1或11的任何用户都应确保：

1. 数据ID的高字节的高半字节等于0。
2. 数据ID的高字节的低半字节在范围0x1…0xE内（以避免与在该半字节上具有0x0的其他E2E配置文件1配置发生冲突并排除无效值0xF）。
3. 数据ID的低字节不同于在双数据ID配置中使用E2E配置文件的同一总线中存在的任何数据ID的高字节。
   在一个总线/系统中使用E2E配置文件变体1/11A和1/11C时，应遵守以下规定：
4. 1/11A数据应使用<256的ID（这意味着高字节应始终=0）。
5. 1/11C数据应使用>=256（这意味着高位字节总是!=0）和<4096（0x1000-这意味着它们适合12位）的ID。
6. 1/11C数据id的任何低字节都应不同于1/11A数据id的任意低字节。
   得益于根据上述要求进行的数据ID分发，可以检测寻址错误：特别是，当1/11C消息到达1/11A目的地时，可以检测到寻址错误。如果1/11C消息接收到1/11A目的地，则如果发送的1/11C消息的低字节等于预期的1/11A地址，则CRC检查将通过，并且这被上述要求排除在外。
   示例：1A可以使用地址0到199，而1C可以使用低字节为200到255，高字节在1到15之间的地址。这允许使用额外的（256-200）*15=840个数据ID。一旦知道，就应该使用相应的E2E库CRC例程。

附录A: E2E配置文件2和22的DataID列表的使用和生成

为E2E配置文件2和22中的DataIDList适当选择DataID允许增加可能检测到伪装的消息的数量。
在计算消息的CRC校验和时使用DataID，而DataID不是发送消息本身的一部分，即接收器接收的消息不包含该信息。
预期消息的任何接收方都需要先验地知道DataID。只有当且仅当接收方的假定DataID与发送方使用的DataID相同时，在接收方对接收到的CRC进行的检查才匹配。因此，DataID允许保护消息不被伪装。重要的是，所使用的DataID仅由预期的发送者和预期的接收者知道。
对于恒定的DataID（独立于计数器），可以使用E2E配置2独立保护的消息的最大数量受到CRC长度的限制（即，对于8比特的CRC长度，独立DataID的数量是2*8=256，这等于用于检测伪装的独立消息的最大数量）。
然而，E2E简档2和22使用一种方法，通过利用单个错误接收的消息内容不违反安全目标（在接收SW Cs的应用程序的设计中采用的基本假设）的先决条件，允许保护更多的消息不被伪装。
E2E配置文件2和22中的基本思想是使用具有在动态行为中选择的几个DataID的DataIDList来计算CRC校验和。DataID是通过从DataIDList中选择一个元素来确定的，使用Counter的值作为索引（有关详细描述，请参阅E2E配置文件2）。
选择下面给出的示例来显示两个示例性使用情况。它演示了如何执行伪装的检测。
尽管这些例子对配置进行了一些假设，但论证是有效的，不失一般性。为了简单起见，以下示例中不解释这些附加约束。