End-to-End

最新推荐文章于 2024-07-05 15:19:42 发布
最新推荐文章于 2024-07-05 15:19:42 发布
阅读量1k 收藏 25
点赞数 17
分类专栏： AUTOSAR E2E 文章标签： 汽车
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/ywtiex/article/details/138197716
版权

目的

由于功能安全项目需要开发E2E模块（非采用AUTOSAR工具开发），本文记录E2E开发过程中一些问题和归纳，方便后来者可以借鉴。

标准文档

在这里插入图片描述

注：如果想深入的了解E2E设计，可以先阅读标准文档，建议按下面先后顺序依次阅读，反之可以跳过这一步骤，直接按本文介绍内容阅读后，直接开发，如果有不理解之处，再有选择性的阅读标准。

[[AUTOSAR_FO_RS_E2E]]

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

[[AUTOSAR_CP_SWS_E2ETransformer]]

本规范规定了AUTOSAR基础软件模块E2E转换器的功能、API和配置。

[[AUTOSAR_FO_PRS_E2EProtocol]]

描述了有关E2E保护和可检测故障模式的一般限制。

[[AUTOSAR_CP_SWS_E2ELibrary]]

本文档包含PRS E2E协议的特定平台实现要求。这包括所使用的接口和数据类型。

使用E2E库的应用方案

为了提供解决灵活性和标准化问题的适当解决方案，AUTOSAR指定了一组灵活的E2E配置文件，用于实现E2E保护机制的适当组合。每个指定的E2E配置文件都有固定的行为，但它有一些功能参数的配置选项（例如，CRC相对于要保护的数据的位置）。

从以下位置调用E2E库：

  1. E2E Transformer（R4.2.1中引入的调用E2E的一种新的标准化方法）
  2. E2E Protection Wrapper （保护数据的非标准集成商软件，在RTE的上层）
  3. COM E2E Callout（保护 I-PDU 的非标准集成器代码）

无论在哪里执行E2E，E2E保护都适用于数据元素。在与总线上传输的位布局相同的位布局上，对数据元素的串行表示执行E2E保护。这意味着：

  • 如果使用E2E Transformer，则串行化由E2E转换器以上的转换器执行（基于COM的转换器或Some/IP变压器）。
  • 在使用E2E Protection Wrapper的情况下，包装器需要将数据元素序列化为相应信号组的序列化形式（换句话说，包装器创建I-PDU的一部分，该部分表示信号组，同时表示数据元素）。
  • 如果使用COM调用，则串行化由通信堆栈（RTE、COM）完成，因此调用直接在I-PDU中的串行化信号组上操作。
    数据元素（和相应的信号组）要么完全受E2E保护，要么不受保护。保护它的一部分是不可能的。
    I-PDU可以携带若干数据元素（以及相应的信号组）。可以独立地对这些数据元素的子集进行E2E保护。
    根据ASIL D要求，单独适当使用E2E库不足以实现安全的E2E通信。用户仅负责证明所选配置文件为所考虑的网络提供了足够的错误检测能力（例如，通过评估硬件故障率、误码率、网络中节点的数量、消息的重复率和网关的使用）。

E2E Protection Wrapper

警告:E2E Wrapper方法涉及不受AUTOSAR标准约束的技术，并被高级E2E Transformer方法（由AUTOSAR完全标准化）所取代。因此，新项目（没有遗留部件造成的遗留限制）应使用完全标准化的E2E Transformer方法。
E2E Protection Wrapper详细描述见[[AUTOSAR_CP_SWS_E2ELibrary#E2E Protection Wrapper]]。

序列图-读取和写入

写入
在这里插入图片描述

读取
在这里插入图片描述

E2E COM Callouts

该解决方案适用于RTE为ECU间通信提供的所有通信模型和倍数。调出调用E2E库，为给定I-PDU中的每个E2E保护信号组调用一次。
该解决方案可用于提供COM和RTE操作完整性的系统。

功能概述

对于每个I-PDU，都有一个单独的调出功能。每个I-PDU调出功能“知道”是否以及如何保护/检查I-PDU的每个信号组。
这意味着调用具有适当设置和状态参数的E2E库功能。E2E库现在可以“了解”信号组及其设置——整个信息作为函数参数传递给E2E库函数。
在接收方和发送方，如果调用返回TRUE，则COM将继续。如果COM E2E Callout返回FALSE，则COM停止处理给定的I-PDU（在此循环中）。当且仅当存在内部错误时，COM E2E Callout才会返回FALSE，例如程序流错误、E2E库中的数据损坏错误。
如果没有检测到运行时错误（例如错误的参数），则发送器调用始终为TRUE，否则为FALSE。如果未检测到运行时错误，并且检查结果为E2E_P02STATUS_OK或E2E_P02TATUS_OKSOMELOST，则接收器调出接收器返回TRUE。

下图总结了发送方的COM E2E Callout解决方案。SW-C完全不受影响，COM中唯一的附加活动是调用生成的callout（步骤6）。如果调出的返回值为TRUE，则由E2E库修改的IpduData随后由PDU路由器传输。如果为false，则COM在此循环中停止对此I-PDU的进一步处理。
在这里插入图片描述

下图总结了接收方COM E2E Callout解决方案。非常重要的一步是，E2E库通过检查状态位（E2E_PXXCheckStateType）覆盖信号组中的CRC字节。然后，这个重写的CRC字节由COM转换为信号，然后由RTE转换为数据元素。结果，SW-C在CRC数据元素中接收E2E校验位，而不是CRC值。
在这里插入图片描述

发送/呼叫

在发送方COM侧，当I-PDU已经从信号构建并且转换（例如Endianness）已经发生，并且I-PDU已经准备好时，COM调用调用callout函数。每个I-PDU都有一个单独的标注（如果已定义）。调用返回后，COM调用PDU路由器来传输数据（功能PduR_COM传输）。
生成调出功能是为了保护一个I-PDU的信号组，并使用正确的硬编码设置简单地调用E2E库（每个受E2E保护的信号组一次）。硬编码设置是根据上一节中描述的设置生成的。
当callout返回TRUE时，COM调用PduR_ComTransmit（），通过网络路由IPDU。
在这里插入图片描述

接收

在接收器COM侧，当I-PDU在PDU路由器上可用时，PDU路由器调用COM的函数COM_RxIndication（）。COM然后调用生成的I-PDU调出（如果为给定的I-PDU配置）。专门为该I-PDU生成的调用调用具有特定参数的E2E库（每个受E2E保护的信号组一次）。E2E库执行检查并将检查结果存储在状态中。
一旦E2E库检查功能返回，调用就会将状态复制到CRC字节中，以便在需要时由接收器SW-C进行分析。
在这里插入图片描述

E2E Transformer

E2E Transformer详细描述见[[AUTOSAR_CP_SRS_Transformer]]。

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概要文件。

[!NOTE] CRC在线计算：
http://www.sunshine2k.de/coding/javascript/crc/crc_js.html

E2E Profile 1

配置文件1是旧配置文件，仅出于兼容性原因才进行维护。新项目应使用配置11。
配置文件1应提供以下机制：计数器、超时监测、数据ID、CRC。

机制描述
Counter4位（明确发送），表示在每次发送请求时递增的从0到14的数字。活动计数器和序列计数器机制都由E2E配置文件1提供，评估相同的4位。
Timeout monitoring超时由E2E监督通过对计数器的评估，通过接收器处的非阻塞读取来确定。E2E监督通过E2E_P01CheckStatusType中的状态标志向调用方报告超时。
Data ID16位，唯一编号，包含在CRC计算中。
对于等于0、1或2的dataIdMode，不传输数据ID，而是将其包括在CRC计算中（隐式传输）。
对于等于3的dataIdMode：
•不使用DataID的高字节的高半字节（它是0x0），因为DataID被限制为12位，
•在计算数据上的CRC时，明确传输DataID的高字节的低半字节，并由CRC计算覆盖。
•低字节不传输，但它作为第一个值包含在CRC计算中（隐式传输，如dataIDMode等于0、1或2）
CRCCRC-8-SE J1850-0x1D（x8+x4+x3+x2+1），但具有不同的起始值和XOR值（起始值和异或值均为0x00）。
本CRC由CRC监督机构提供。从AUTOSAR R4.0开始，CRC监督的SAE8 CRC功能使用0xFF作为起始值和XOR值。为了补偿CRC监督的不同行为，E2E监督从R4.0开始应用额外的XOR 0xFF运算，以产生0x00作为开始值和XOR值。
注：此CRC多项式与FlexRay、CAN和LIN使用的CRC多项式不同。

E2E机制可以检测以下故障或故障的影响：

E2E机制检测到通信故障
Counter重复、丢失、插入、顺序错误、阻塞
定期传输，并使用E2E监督进行超时监测丢失、延迟、阻塞
Data ID + CRC伪装和不正确的寻址、插入
CRC损坏、信息不对称
API规范

本章规定了E2E库的API。

E2E P01ConfigTypes

在这里插入图片描述

E2E_P01CheckStateType

在这里插入图片描述

头布局

E2E Profile 1由三个字段组成，Counter、DataID、CRC，最大数据保护长度为32 - 2 Bytes。[1]

CounterData IDCRC
4 Bits16 Bits8 Bits

[注1]：[[AUTOSAR_FO_PRS_E2EProtocol#数据、通信总线的最大长度]]。

Counter

在E2E配置文件1中，在发送方，对于数据元素的第一个传输请求，计数器应初始化为0，并且对于每个后续发送请求（来自发送方SW-C），计数器应递增1。当计数器达到值14（0xE）时，下一个发送请求（即应跳过值0xF）。

Data ID

唯一的数据ID用于验证每个传输的安全相关数据元素的身份。

在计算一字节CRC时，两字节数据ID应具有以下四种包含模式：

  1. E2E_P01_DATAID_BOTH：CRC中包括DataID两个字节，首先是低字节，然后是高字节，但不参与数据传输。
  2. E2E_P01_DATAID_ALT：CRC中包含两个字节，当计数器为偶数时，只有低字节参与CRC计算，但不参与数据传输；当计数器为奇数时，只有高字节参与CRC计算，但不参与数据传输。
  3. E2E_P01_DATAID_LOW：只包含低字节，不使用高字节。这等于数据ID仅为8位的情况。
  4. E2E_P01_DATAID_NIBBLE：DataID 高字节的高半字节不使用， 应置为 0x00， 此时相当于可用 DataID 的长度为 12Bits， 且此时 Data ID 高字节的低半字节不仅参与 Crc 计算，还与数据一起传输， 位置由 DataIDNibbleOffset 决定，DataID低字节参与CRC计算，但不参与数据传输。
CRC

AUTOSAR R4.0开始，CRC采用[[CRC#CRC8_SAE_J1850]]使用0xFF作为起始值和XOR值。R4.0之前，采用[[CRC#CRC8_SAE_J1850_ZERO]]使用0x00作为起始值和XOR值。

下图显示了E2E_P01_DATAID_BOTH的通信CRC，以下配置为：

  1. CRC是消息中的第0个字节（即以比特偏移量0开始）
  2. 活动计数器位于第一个字节的最低4位（即从位偏移8开始）
  3. E2E_P01DataIDMode=E2E_P01_DATAID_BOTH
  4. unusedBitPattern=0xFF
    ![[Pasted image 20240420160612.png]]
    下图显示E2E_P01_DATAID_NIBBLE的通信CRC，以下配置为：
  5. CRC是消息中的第0个字节（即以比特偏移量0开始）
  6. 活动计数器位于第一个字节的最低4位（即从位偏移8开始）
  7. 数据ID半字节位于第一字节的最高4位（即以位偏移12开始）
  8. E2E_P01DataIDMode=E2E_P01_DATAID_NIBBLE
  9. unusedBitPattern=0xFF
    在这里插入图片描述
示例

以下示例假设的默认配置，采用[[CRC#CRC8_SAE_J1850_ZERO]]算法：

E2E_P01ConfigType field值
CounterOffset8
CRCOffset0
DataID0x123
DataIDNibbleOffset12
DataIDMode\
DataLength64
MaxDeltaCounterInit1
MaxNoNewOrRepeatedData15
SyncCounterInit0
DataIDMode set to E2E_P01_DATAID_BOTH

E2E_P01Protect（）的结果数据，数据等于全零（0x00），Counter=0：

Byte01234567
Data0xCC0x000x000x000x000x000x000x00
FieldCRCCounterData<-<-<-<-<-

[!NOTE] CRC
[0x23 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00] = 0xCC

E2E_P01Protect（）的结果数据，数据等于全零（0x00），Counter=0：

Byte01234567
Data0x910x010x000x000x000x000x000x00
FieldCRCCounterData<-<-<-<-<-

[!NOTE] CRC
[0x23 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00] = 0x91

DataIDMode set to E2E_P01_DATAID_ALT

E2E_P01Protect（）的结果数据，数据等于全零（0x00），Counter=0：

Byte01234567
Data0xCE0x000x000x000x000x000x000x00
FieldCRCCounterData<-<-<-<-<-

[!NOTE] CRC
[0x23 0x00 0x00 0x00 0x00 0x00 0x00 0x00] = 0xCE

E2E_P01Protect（）的结果数据，数据等于全零（0x00），Counter=1：

Byte01234567
Data0x020x010x000x000x000x000x000x00
FieldCRCCounterData<-<-<-<-<-

[!NOTE] CRC
[0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00] = 0x02

DataIDMode set to E2E_P01_DATAID_LOW

E2E_P01Protect（）的结果数据，数据等于全零（0x00），Counter=0：

Byte01234567
Data0xCE0x000x000x000x000x000x000x00
FieldCRCCounterData<-<-<-<-<-

[!NOTE] CRC
[0x23 0x00 0x00 0x00 0x00 0x00 0x00 0x00] = 0xCE

E2E_P01Protect（）的结果数据，数据等于全零（0x00），Counter=1：

Byte01234567
Data0x930x010x000x000x000x000x000x00
FieldCRCCounterData<-<-<-<-<-

[!NOTE] CRC
[0x23 0x01 0x00 0x00 0x00 0x00 0x00 0x00] = 0x93

DataIDMode set to E2E_P01_DATAID_NIBBLE

E2E_P01Protect（）的结果数据，数据等于全零（0x00），Counter=0：

Byte01234567
Data0x770x100x000x000x000x000x000x00
FieldCRCCounterData<-<-<-<-<-

[!NOTE] CRC
[0x23 0x10 0x00 0x00 0x00 0x00 0x00 0x00] = 0x77

E2E_P01Protect（）的结果数据，数据等于全零（0x00），Counter=1：

Byte01234567
Data0x2A0x110x000x000x000x000x000x00
FieldCRCCounterData<-<-<-<-<-

[!NOTE] CRC
[0x23 0x11 0x00 0x00 0x00 0x00 0x00 0x00] = 0x2A

[!NOTE] 总结
Data ID放在最前面，采用小端序（跟传输介质有关，以AUTOSAR_FO_PRS_E2EProtocol > 字节序为准），依次是Counter、Data。

E2E Profile 2

配置文件2是传统配置文件，仅出于兼容性原因才进行维护。新项目应使用Profile 22。
配置文件2应提供以下机制：Couter、DataID、CRC。

机制描述
Counter4位（明确发送），表示在发送方的每个发送请求（Data[1]的位0:3）上从0到15的数字加1。计数器在每次调用E2E_P02Protect（）函数时递增，即在SW-C的每次传输请求时递增。
Data ID8位（未明确发送）用于计算CRC的特定数据ID取决于计数器的值，并且是预定义的一组数据ID的元素（计数器的值作为选择用于保护的特定数据标识的索引）。对于每个Data元素，取决于计数器的每个值的数据ID列表都是唯一的。
Data ID + CRC伪装和不正确的寻址、插入
CRC0x2F（x8+x5+x3+x2+x+1）起始值：0xFF最终异或值：0xFF注意：此CRC多项式与FlexRay和CAN使用的CRC多项式不同。
Timeout monitoring超时由E2E监督通过对计数器的评估，通过接收器处的非阻塞读取来确定。E2E监督通过E2E_P02CheckStatusType中的状态标志向调用方报告超时。
配置文件2提供的机制能够检测除消息延迟之外的相关故障模式：
由于该配置文件是在Supervisory中实现的，Supervisory的E2E_P02Check（）函数本身无法确保定期调用。因此，必须在调用者中实现针对未检测到的消息延迟（例如超时）的所需保护机制。

E2E机制可以检测以下故障或故障的影响：

E2E机制检测通信故障
Counter重复、丢失、插入、顺序错误、阻塞
Data ID + CRC伪装和不正确的寻址、插入
CRC信息被破坏、信息不对称
API规范
E2E_P02ConfigType

\

E2E_P02CheckStateType

在这里插入图片描述

头布局

E2E Profile 2由三个字段组成，Counter、DataID、CRC，最大数据保护长度为32 - 2 Bytes。[1]
在这里插入图片描述

[注1]：[[AUTOSAR_FO_PRS_E2EProtocol#数据、通信总线的最大长度]]。

Counter

在E2E配置文件2中，计数器应为数据[1]的低半字节（位0…位3）。
在E2E配置文件2中，计数器的值范围应为[0…15]。
当计数器达到其上限15（0xF）时，它将在0处重新启动。

Data ID

在E2E配置文件2中，用于计算特定CRC的特定数据ID的长度应为8位。
在E2E配置文件2中，应使用计数器的值作为索引，从预定义的DataIDList[16]中选择用于CRC计算的特定数据ID。
受CRC保护的每个数据都拥有一个专用的DataIDList，该DataIDList存放在发送方站点和所有接收方站点上。
预定义的DataIDList[16]是离线生成的。通常，有几个因素会影响DataIDList的内容，例如：

  1. 受保护数据的长度
  2. 受保护数据元素的数量
  3. 必须检测伪装故障内的循环数
  4. 发送器和接收器的数量
  5. CRC多项式的特性

由于8位多项式的长度有限，当评估接收到的CRC值时，可能无法在特定周期中检测到伪装故障。由于DataIDList中有足够的数据ID，可以在一个连续的通信周期中检测到伪装故障。
由于DataIDList的基本规则，应用程序的系统设计必须考虑到，在评估一定数量的通信周期之前，才会检测到伪装故障。

CRC

E2E配置文件2应使用SWS CRC监督的Crc_CalculateCCRC8H2F（）函数计算Crc校验和。
E2E配置文件2应使用0xFF作为CRC计算的起始值CRC_StartValue8。
在E2E配置文件2中，CRC应为Data[0]。
CRC算法详细介绍请参照[[CRC#CRC8_8HF2]]。

示例

以下示例假设的默认配置，采用[[CRC#CRC8_8HF2]]算法：

E2E_P02ConfigType field值
DataLength64
DataIDList0x01, 0x02, 0x03, 0x04,
0x05, 0x06, 0x07, 0x08,
0x09, 0x0a, 0x0b, 0x0c,
0x0d, 0x0e, 0x0f, 0x10
MaxDeltaCounterInit1
MaxNoNewOrRepeatedData15
SyncCounterInit0
Offset0

E2E_P02Protect（）的结果数据，数据等于全零（0x00），计数器从1开始（注意：第一次使用的计数器是1，尽管计数器字段初始化为0，因为计数器在使用前递增）：

Byte01234567
Data0x1b0x010x000x000x000x000x000x00
FieldCRCCounterData<-<-<-<-<-

[!NOTE] CRC
[0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x02] = 0x1b

Byte01234567
Data0x980x020x000x000x000x000x000x00
FieldCRCCounterData<-<-<-<-<-

[!NOTE] CRC
[0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x03] = 0x98

Byte01234567
Data0x650x070x000x000x000x000x000x00
FieldCRCCounterData<-<-<-<-<-

[!NOTE] CRC
[0x07 0x00 0x00 0x00 0x00 0x00 0x00 0x08] = 0x65

[!NOTE] 总结
Data ID放在Data后面，参与CRC计算。

E2E Profile 4

配置文件4应提供以下控制字段，在运行时与受保护数据一起传输：Length、Counter、CRC、Data ID。

Control field描述
Length16位，以支持动态大小数据。
Counter16位
CRC32位，正态形式的多项式0xF4ACFB13，由CRC库提供。
注：此CRC多项式不同于FlexRay、CAN、LIN和TCPIP使用的CRC多项式。
Data ID32位
API规范
E2E_P04ConfigType

在这里插入图片描述

E2E_P04CheckStateType

在这里插入图片描述

头布局

E2E Profile 4由四个字段组成，包含Length、Counter、DataID、CRC，最大数据保护长度为4096 - 12 Bytes。[1]
在E2E配置文件4中，（要保护的数据的）用户数据布局不受E2E配置程序4的约束——只要求要保护的长度是1字节的倍数。
E2E配置文件4的标头具有一个固定布局，如下所示：在这里插入图片描述

[注1]：[[AUTOSAR_FO_PRS_E2EProtocol#数据、通信总线的最大长度]]。

Length

16位数据长度，采用显式传输。

Counter

16位计数器，从0开始递增，增至0xFFFF时反转，采用显式传输。

Data ID

32位数据ID，采用隐式传输。

CRC

32位循环冗余校验码，多项式为0xF4ACFB13。
CRC算法详细介绍请参照[[CRC#CRC32_P4]]。

示例

以下示例假设的默认配置：在这里插入图片描述

E2E_P04Protect（）的结果，数据具有短数据长度（长度16字节，表示4个实际数据字节），offset=0，Counter=0：

Byte01234567
Data0x000x100x000x000x0a0x0b0x0c0x0d
FieldLength<-Counter<-DataID<-<-<-
Byte89101112131415
Data0x860x2b0x050x560x000x000x000x00
FieldCRC<-<-<-Data<-<-<-

[!NOTE] CRC
[0x00 0x10 0x00 0x00 0x0a 0x0b 0x0c 0x0d 0x00 0x00 0x00 0x00] = 0x862b0556

E2E_P04Protect（）的结果数据，最小数据长度（4个数据字节），Offset=64，DataLength=24，Counter=0：

Byte01234567
Data0x000x000x000x000x000x000x000x00
FieldData<-<-<-<-<-<-<-
Byte89101112131415
Data0x000x180x000x000x0a0x0b0x0c0x0d
FieldLength<-Counter<-DataID<-<-<-
Byte1617181920212223
Data0x690xd70x500x2e0x000x000x000x00
FieldCRC<-<-<-Data<-<-<-

[!NOTE] CRC
[0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x18 0x00 0x00 0x0a 0x0b 0x0c 0x0d 0x00 0x00 0x00 0x00] = 0x69d7502e

[!NOTE] 总结
Data ID以大端序方式参与CRC计算，采用大端序传输（跟传输介质有关，以[[AUTOSAR_FO_PRS_E2EProtocol#字节序]]为准）。

E2E Profile 5

配置文件5应提供以下控制字段，在运行时与受保护数据一起传输：计数器、CRC、数据ID。

Control field描述
Length16位，以支持动态大小数据。
Counter8位 (显式发送)
CRC32位，正态形式的多项式0xF4ACFB13，由CRC库提供。
注：此CRC多项式不同于FlexRay、CAN、LIN和TCPIP使用的CRC多项式。
Data ID32位
API规范
E2E_P05ConfigType

在这里插入图片描述

E2E_P05ProtectStateType

在这里插入图片描述

E2E_P05CheckStateType

在这里插入图片描述

头布局

在E2E配置文件5中，（要保护的数据的）用户数据布局不受E2E配置书5的约束——只有一个要求，即要保护的长度是1字节的倍数。
E2E Profile 5的标头有一个固定布局，如下所示：
在这里插入图片描述

E2E Profile 5由3个字段组成，包含Counter、DataID、CRC，最大数据保护长度为4096 - 3 Bytes。[1] 。

[注1]：[[AUTOSAR_FO_PRS_E2EProtocol#数据、通信总线的最大长度]]。

Counter

在E2E配置文件5中，计数器被初始化、递增、重置并通过E2E配置进行检查。
在E2E配置文件5中，在发送方，对于数据元素的第一个传输请求，计数器应初始化为0，并且应针对每个后续发送请求递增1。当计数器达到最大值（0xFF）时，它将在下一个发送请求中以0重新启动。
注意：计数器值0xFF不是作为特殊无效值保留的，而是用作正常计数器值。

DataID

唯一的数据ID用于验证每个传输的安全相关数据元素的身份。
在E2E配置文件5中，应通过在CRC计算中的用户数据之后添加数据ID来隐式传输数据ID。
在E2E配置文件5中，数据ID在通信系统的网络中应该是全局唯一的（由多个ECU组成，每个ECU发送不同的数据）。

CRC

16位循环冗余校验码，多项式为0x1021。
CRC算法详细介绍请参照[[CRC#CRC16_CCITT_FALSE]]。

示例

以下示例假设的默认配置：
在这里插入图片描述

E2E_P05Protect（）的结果数据，数据长度较短（长度为8字节，实际数据字节数为5），偏移量为0，计数器为0：

Byte01234567
Data0x1c0xca0x000x000x000x000x000x00
FieldCRC<-CounterData<-<-<-<-

[!NOTE] CRC
[0x00 0x00 0x00 0x00 0x00 0x00 0x34 0x12] = 0xCA1C

E2E_P05Protect（）的结果数据，数据长度较短（长度为16字节，实际数据字节数为5），偏移量=64，计数器=1：

Byte01234567
Data0x000x000x000x000x000x000x000x00
FieldData<-<-<-<-<-<-<-
Byte89101112131415
Data0xFB0xD60x010x000x000x000x000x00
FieldCRC<-CounterData<-<-<-<-

[!NOTE] CRC
[0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x34 0x12] = 0xD6FB

[!NOTE] 总结
Data ID放在Data后面，以小端方式参与CRC计算，CRC以小端方式传输（跟传输介质有关，以AUTOSAR_FO_PRS_E2EProtocol > 字节序为准）。

E2E Profile 6

配置文件6应提供以下控制字段，在运行时与受保护数据一起传输：长度、计数器、CRC、数据ID。

Control field描述
Length16位，以支持动态大小数据。（显式发送）
Counter8位 (显式发送)
CRCCRC库提供的16位标准形式的多项式0x1021（Autosar表示法）。（明确发送）
Data ID16位，独特的系统范围。（隐式发送）
API规范
E2E_P06ConfigType

在这里插入图片描述

E2E_P06ProtectStateType

在这里插入图片描述

E2E_P06CheckStateType

在这里插入图片描述

头布局

在E2E配置文件6中，（要保护的数据的）用户数据布局不受E2E配置程序6的约束—只要求要保护的长度是1字节的倍数。
E2E配置文件6的标头具有一个固定布局，如下所示：
在这里插入图片描述

上面显示的比特编号表示比特被传输的顺序。E2E报头字段（例如，E2E计数器）被编码为：

  1. Big Endian（最高有效字节优先），适用于隐式和显式头字段-由配置文件强制执行。
  2. LSB优先（字节内最低有效位优先）-由TCP/IP总线强制执行。
Counter

在E2E配置文件6中，计数器被初始化、递增、重置并通过E2E配置进行检查。计数器未被E2E监督的调用方操作或使用。

在E2E配置文件6中，在发送方，对于数据元素的第一个传输请求，计数器应初始化为0，并且应针对每个后续发送请求递增1。当计数器达到最大值（0xFF）时，它将在下一个发送请求中以0重新启动。

请注意，计数器值0xFF不是作为特殊无效值保留的，而是用作正常计数器值。

Data ID

唯一的数据ID用于验证每个传输的安全相关数据元素的身份。
在E2E配置文件6中，数据ID应通过在CRC计算中的用户数据之后添加数据ID来隐式传输。
在E2E配置文件6中，数据ID在通信系统的网络中应该是全局唯一的（由多个ECU组成，每个ECU发送不同的数据）。

Length

在Profile 6中，引入了长度字段以支持可变大小的长度-存储序列化数据的Data[]数组在每个周期中可能具有不同的长度。在配置文件6中，存在长度的显式传输。长度包括用户数据+E2E报头（CRC+计数器+Length）。

CRC

E2E Profile 6使用16比特CRC来确保足够的检测速率和足够的汉明距离。
E2E Profile 6应使用SWS Crc监督的Crc_CalculateCCRC16（）函数来计算Crc（多项式：0x1021；Autosar表示法）。
在E2E配置文件6中，应在整个E2E报头（不包括CRC字节）上计算CRC，包括使用数据ID扩展的用户数据。
有关CRC算法的详细信息，请见[[CRC#CRC16_CCITT_FALSE]]。

示例

以下示例假设的默认配置（如果没有另行说明）不同：：
![[Pasted image 20240425130148.png]]
E2E_P06Protect（）的结果数据，数据长度较短（长度为8字节，实际数据字节数为3），偏移量为0，计数器为0：

Byte01234567
Data0xB10x550x000x080x000x000x000x00
FieldCRC<-Length<-CounterData<-<-

[!NOTE] CRC
[0x00 0x08 0x00 0x00 0x00 0x00 0x12 0x34] = 0xB155

E2E_P06Protect（）的结果数据，数据长度较短（长度为16字节，实际数据字节数为3），偏移量=64（与SOME/IP标头用例相同），计数器=0：

Byte01234567
Data0x000x000x000x000x000x000x000x00
FieldData<-<-<-<-<-<-<-
Byte89101112131415
Data0x4e0xb70x000x100x000x000x000x00
FieldCRC<-Length<-CounterData<-<-

[!NOTE] CRC
[0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10 0x00 0x00 0x00 0x00 0x12 0x34] = 0x4eb7

E2E Profile 7

配置文件7应提供以下控制字段，在运行时与受保护数据一起传输：长度、计数器、CRC、数据ID。

Control field描述
Length32位，支持动态大小数据
Counter32位
CRC64位，正态形式的多项式0x42F0E1EBA9EA3693，由CRC库提供。
注：此CRC多项式也称为“CRC64_XZ”。
Data ID32位，独特的系统范围。
CRC算法详细情况，请见[[CRC#CRC64_XZ]]。
API规范
E2E_P07ConfigType

在这里插入图片描述

E2E_P07ProtectStateType

在这里插入图片描述

E2E_P07CheckStateType

在这里插入图片描述

头布局

在E2E配置文件7中，（要保护的数据的）用户数据布局不受E2E配置程序7的约束——只要求要保护的长度是1字节的倍数。
E2E配置文件7的标头具有一个固定布局，如下所示：
在这里插入图片描述

上面显示的比特编号表示比特被传输的顺序。E2E报头字段（例如，E2E计数器）被编码为：

  1. Big Endian（最高有效字节优先）-由配置文件强制执行。
  2. LSB优先（字节内最低有效位优先）-由TCPIP总线施加。通过配置整个E2E报头的偏移量，可以将报头放置在受保护数据中的特定位置。
示例

以下示例假设的默认配置（如果没有另行说明）不同：
在这里插入图片描述

E2E_P07Protect（）的结果数据，数据长度较短（长度为24字节，表示实际的4个数据字节），偏移量=0，计数器=0：

Byte01234567
Data0x1F0xB20xE70x370xFC0xED0xBC0xD9
FieldCRC<-<-<-<-<-<-<-
Byte89101112131415
Data0x000x000x000x180x000x000x000x00
FieldLength<-<-<-Counter<-<-<-
Byte1617181920212223
Data0x0a0x0b0x0c0x0d0x000x000x000x00
FieldData ID<-<-<-Data<-<-<-

[!NOTE] CRC
[0x00 0x00 0x00 0x18 0x00 0x00 0x00 0x00 0x0a 0x0b 0x0c 0x0d 0x00 0x00 0x00 0x00] = 0x1FB2E737FCEDBCD9

E2E_P07Protect（）的结果数据，数据长度较短（长度32，表示4个实际数据字节），偏移量=64（与SOME/IP标头用例相同），计数器=0：

Byte01234567
Data0x000x000x000x000x000x000x000x00
FieldData<-<-<-<-<-<-<-
Byte89101112131415
Data0x170xf70xc80x170x320x380x650xa8
FieldCRC<-<-<-<-<-<-<-
Byte1617181920212223
Data0x000x000x000x200x000x000x000x00
FieldLength<-<-<-Counter<-<-<-
Byte2425262728293031
Data0x0a0x0b0x0c0x0d0x000x000x000x00
FieldData ID<-<-<-Data<-<-<-

[!NOTE] CRC
[0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x0a 0x0b 0x0c 0x0d 0x00 0x00 0x00 0x00] = 0x17F7C817323865A8

E2E Profile 8

配置文件8应提供以下控制字段，在运行时与受保护数据一起传输：长度、计数器、CRC、数据ID。

Control field描述
Length32位，支持动态大小数据
Counter32位
CRC32位，正态形式的多项式0xF4ACFB13。
注：此CRC多项式不同于FlexRay、CAN、LIN和TCPIP使用的CRC多项式。
Data ID32位，独特的系统范围。

CRC算法详细情况，请见[[CRC#CRC32_P4]]。

API规范
E2E_P08ConfigType

在这里插入图片描述

E2E_P08ProtectStateType

在这里插入图片描述

E2E_P08CheckStateType

在这里插入图片描述

头布局

在E2E配置文件8中，（要保护的数据的）用户数据布局不受E2E配置程序8的约束——只要求要保护的长度是1字节的倍数。
E2E Profile 8的标头具有一个固定布局，如下所示：
在这里插入图片描述

E2E报头字段（例如，E2E计数器）被编码为：

  1. Big Endian（最高有效字节优先）-由配置文件强制执行。
  2. LSB优先（字节内最低有效位优先）-由TCPIP总线施加。通过配置整个E2E报头的偏移量，可以将报头放置在受保护数据中的特定位置。
示例

以下示例假设的默认配置（如果没有另行说明）不同：
在这里插入图片描述

E2E_P08Protection（）的结果数据具有短数据长度（长度为20字节，表示4个实际数据字节），偏移量=0，计数器=0：

Byte01234567
Data0x410x490x4e0x520x000x000x000x14
FieldCRC<-<-<-Length<-<-<-
Byte89101112131415
Data0x000x000x000x000x0a0x0b0x0c0x0d
FieldCounter<-<-<-DataID<-<-<-
Byte1617181920212223
Data0x000x000x000x00
FieldData<-<-<-

[!NOTE] CRC
[0x00 0x00 0x00 0x14 0x00 0x00 0x00 0x00 0x0a 0x0b 0x0c 0x0d 0x00 0x00 0x00 0x00] = 0x41494E52

E2E_P08Protect（）的结果数据，最小数据长度（4个数据字节），偏移量=64（与某些/IP标头用例相同），数据长度=28，计数器=0：

Byte01234567
Data0x000x000x000x000x000x000x000x00
FieldData<-<-<-<-<-<-<-
Byte89101112131415
Data0xe80x910xe50xa80x000x000x000x1c
FieldCRC<-<-<-Length<-<-<-
Byte1617181920212223
Data0x000x000x000x000x0a0x0b0x0c0x0d
FieldCounter<-<-<-DataID<-<-<-
Byte2425262728293031
Data0x000x000x000x00
FieldData<-<-<-

[!NOTE] CRC
[0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1c 0x00 0x00 0x00 0x00 0x0a 0x0b 0x0c 0x0d 0x00 0x00 0x00 0x00] = 0xE891E5A8

E2E Profile 11

配置文件11与配置文件1总线兼容，但在接收器侧提供类似于配置文件4到7的“新”配置文件行为。此外，以下传统DataIDMode现已过时并被省略：E2E_P11_DATAID_LOW、E2E_P11_DATAID_ALT。
配置文件11应提供以下控制字段，在运行时与受保护数据一起传输：计数器、CRC、数据ID。

Control field描述
Counter4位。（显式发送）
CRC8位，CRC-8-SEJ1850，由CRC库提供。（显式发送）
Data ID16位或12位，唯一的系统范围。（隐式发送（16位）或部分显式发送（12位；显式发送4位，隐式发送8位）

AUTOSAR R4.0开始，CRC采用[[CRC#CRC8_SAE_J1850]]使用0xFF作为起始值和XOR值。R4.0之前，采用[[CRC#CRC8_SAE_J1850_ZERO]]使用0x00作为起始值和XOR值。

API规范
E2E_P11ConfigType

在这里插入图片描述

E2E_P11ProtectStateType

在这里插入图片描述

E2E_P11CheckStateType

在这里插入图片描述

头布局

在E2E配置文件11中，（要保护的数据的）用户数据布局不受E2E配置程序11的约束——只有一个要求，即要保护的长度是1字节的倍数。
配置文件11与配置文件1的总线布局向后兼容。这意味着，虽然所有标题字段都是可配置的，但配置文件1的配置文件变体也适用。
在这里插入图片描述

上图显示了配置文件11变体11C，其中配置如下：E2E头字段（例如CRC）像CAN和FlexRay中一样进行编码，即：

  1. CRC偏移=0
  2. 通过FlexrayCAN总线，CounterOffset=8。
  3. DataIDNibbleOffset=12对于配置文件11变体11A，不使用DataIDNibble。相反，用户数据可以放在那里。

E2E配置文件变体11A的定义如下，如下图所示：

  1. CRC是信号组中的第0个字节（即以比特偏移0开始）
  2. 活动计数器位于第一个字节的最低4位（即从位偏移8开始）
  3. E2E_P11DataIDMode=E2E_P11_DATAID_BOTH
  4. 信号IPdu.unusedBitPattern=0xFF。
    在这里插入图片描述
Counter

在E2E配置文件11中，计数器被初始化、递增、重置并通过E2E配置进行检查。
在E2E配置文件11中，在发送方，对于数据元素的第一个传输请求，计数器应初始化为0，并且对于每个后续的发送请求应增加1。当计数器达到最大值（0x0E）时，它将在下一个发送请求中以0重新启动。
注意，计数器值0x0F被保留为一个特殊的无效值，并且永远不会被E2E配置文件11使用。

DataID

唯一的数据ID用于验证每个传输的安全相关数据元素的身份。
应支持以下两种数据ID模式：

  1. E2E_P11_DATAID_BOTH：在CRC计算中使用16位数据ID的两个字节：首先是低字节，然后是高字节。
  2. E2E_P11_DATAID_NIBBLE：不使用DATAID的高字节的高半字节（它是0x0），因为DATAID被限制为12位，所以在计算数据上的CRC时，DATAID的高字节的低半字节被明确传输并被CRC计算覆盖。低字节不被发送，但是它被包括在CRC计算中作为起始值。
    在E2E配置文件11中，数据ID在通信系统的网络中应是全局唯一的（由多个ECU组成，每个ECU发送不同的数据）。
Length

在配置文件11中，没有明确的长度传输。

CRC

E2E配置11使用8比特CRC来确保足够的检测速率和足够的汉明距离。
E2E配置文件11应使用SWS Crc监督的Crc_CalculateCCRC8功能来计算Crc（CRC-8-SEA J1850）。
在数据ID模式设置为E2E_P11_DATAID_BOTH的E2E Profile11中，应通过在CRC计算中的用户数据之前先添加数据ID低字节，然后添加数据ID高字节，隐式传输数据ID。
在数据ID模式设置为E2E_P11_DATAID_NIBBLE的E2E Profile11中，数据ID的高字节的下半字节应放置在位位置DataIDNibleOffset的传输数据中，并且CRC计算应通过首先计算数据ID的低字节，然后计算0字节，再计算用户数据来完成。

示例

以下示例假设的默认配置（如果没有另行说明）不同：
在这里插入图片描述

DataIDMode set to E2E_P11DATAID_BOTH

E2E_P11Protect（）的结果数据，数据等于全零（0x00），计数器=0：

Byte01234567
Data0xcc0x000x000x000x000x000x000x00
FieldCRCCounterData<-<-<-<-<-

[!NOTE] CRC
[0x23 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00] = 0xcc

E2E_P11Protect（）的结果数据，数据等于全零（0x00），计数器=1：

Byte01234567
Data0x910x010x000x000x000x000x000x00
FieldCRCCounterData<-<-<-<-<-

[!NOTE] CRC
[0x23 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00] = 0x91

DataIDMode set to E2E_P11DATAID_NIBBLE

E2E_P11Protect（）的结果数据，数据等于全零（0x00），计数器=0：

Byte01234567
Data0x770x100x000x000x000x000x000x00
FieldCRCCounterData<-<-<-<-<-

[!NOTE] CRC
[0x23 0x10 0x00 0x00 0x00 0x00 0x00 0x00] = 0x77

E2E_P11Protect（）的结果数据，数据等于全零（0x00），计数器=1：

Byte01234567
Data0x2a0x110x000x000x000x000x000x00
FieldCRCCounterData<-<-<-<-<-

[!NOTE] CRC
[0x23 0x11 0x00 0x00 0x00 0x00 0x00 0x00] = 0x2a

这是配置P11与SOME/IP序列化程序一起使用的典型用例，它将一个8字节的标头放在序列化的用户数据前面。CRC计算包括8字节报头，然后包括有效载荷数据，不包括CRC字节本身。“偏移64”是指CRCCOffset设置为64，CounterOffset设置成72，DataIDNibleOffset设置到76。E2E_P11Protect（）的结果数据，数据等于全零（0x00），计数器=0：

Byte01234567
Data0x000x000x000x000x000x000x000x00
FieldData<-<-<-<-<-<-<-
Byte89101112131415
Data0x770x100x000x000x000x000x000x00
FieldCRCDataID-Nibble | CounterData<-<-<-<-<-

[!NOTE] CRC
[0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x23 0x10 0x00 0x00 0x00 0x00 0x00 0x00] = 0x77

E2E状态机规范

E2E配置文件检查（）-函数验证在一个周期内接收到的数据。此功能仅确定该周期中的数据是否正确。相反，状态机在接收窗口内从check（）函数的几个结果中建立一个状态，然后通过中间件接口（例如RTE API）将其提供给消费应用程序。

E2E状态机适用于所有E2E配置文件。可以通过参数进行配置。E2E状态机的使用由disableEndToEndStateMachine参数启用/禁用。

配置参数“disableEndToEndStateMachine”决定是否使用状态机。如果此参数设置为TRUE，则不应使用状态机。
在这种情况下，应用程序只能接收最新的E2E检查结果，而不能接收任何状态信息。

状态机概述

本章概述了状态机的功能，并包含了状态机行为的简化表示。状态和跃迁被完整地包括在内，但为了更好地理解，跃迁条件被广义化了。

状态机通过以下状态信息提供关于通信信道状态的汇总结果-E2E_SM_DEINIT、E2E_SM_INIT、E2E_SM_NODATA、E2E_SM_VALID、E2E_ SM_INVALID。

状态转换取决于E2E配置文件检查（）的当前ProfileStatus和以前检查的ProfileStatus值。
可以借助参数TransitToInvalidExtended来调整状态机。

通过TransitToInvalidExtended=false：状态机的行为应符合下图。没有从E2E_SM_NODATA到E2E_SM_INVALID的直接转换，也没有由于计数器相关故障（Autosar R19-11或以前的行为）而从E2E_SM_INIT到E2E_SM_INVALID的转换。
在这里插入图片描述

通过TransitToInvalidExtended=true：状态机的行为应符合下图。涵盖了从E2E_SM_NODATA到E2E_SM_INVALID的直接转换，涵盖了由于计数器相关故障而从E2E_SM_INIT到E2E_SM_INVALID的转换（状态机扩展）。
在这里插入图片描述

状态机规范

本章包含了状态机行为的详细描述。所有的转换条件都有详细的描述。
E2E 状态机应该由函数 E2E _ SMCheck ()和 E2E _ SMCheckInit ()实现。
根据配置参数 TransitToInvalidExtended，E2E 状态机将显示与函数 E2E _ SMCheck ()相关的行为。

  1. 在TransitToInvalidExtended=false的情况下：E2E_SMCheck（）的行为应符合下图。
    在这里插入图片描述

  2. 在TransitToInvalidExtended=true的情况下：E2E_SMCheck（）的行为应符合下图。
    在这里插入图片描述

  3. 当前状态（例如E2E_SM_VALID）存储在状态->SMState中。

  4. 在每次调用E2E_SMCheck时，都可以处理ProfileStatus（如逻辑步骤E2E_SMAddStatus（）所示）。

  5. 之后，检查两个计数器：State->ErrorCount和State>OKCount（在所有不同的状态下连续使用）。根据它们的值，有一个到新状态的转换，存储在状态->SMState中。

状态之间转换的条件包括在上图中表示。然而，为了更好地理解，添加了以下对状态转换的文本解释。
任何转换都是基于E2E检查功能的结果和当前E2E状态机状态触发的。E2E检查功能的结果可以总结为以下内容之一：

  • 有效数据-E2E检查给出值E2E_P_OK。
  • 数据损坏-E2E检查给出值E2E_P_ERROR。
  • 无新数据-E2E检查给出值E2E_P_NONEWDATA。

大多数转换与TransitToInvalidExtended的值集无关。仅对TransitToInvalidExtended的特定设置有效的转换在末尾标记为（如果TransitToInvalidExtended=1）或（如果TransITToInvalidExtensions=0）。

从E2E_SM_NODATA转换

从E2E_SM_NODATA到E2E_SM_INIT的转换被触发，只要从E2E的角度来看最新接收的数据是不是损坏的数据。
从E2E_SM_NODATA到E2E_SM_INVALID的转换在WindowSizeInit消息周期的间隔内无论何时都被触发，或者没有检测到新数据或损坏的数据，或者两者的混合。（如果TransitToInvalidExtended=1）

从E2E_SM_INIT转换

每当在WindowSizeInit消息周期的间隔内检测到小于配置的损坏数据的数量且大于或等于配置的有效数据的数量时，就会触发从E2E_SM_INIT到E2E_SM_VALID的转换。

每当在WindowSizeInit消息周期的间隔内检测到大于配置的损坏数据数量时，就会触发从E2E_SM_INIT到E2E_SM_INVALID的转换。（如果TransitToInvalidExtended=0）
每当在WindowSizeInit消息周期的间隔内检测到大于配置的损坏数据数或小于配置的有效数据数时，就会触发从E2E_SM_INIT到E2E_SM_INVALID的转换。（如果TransitToInvalidExtended=1）

从E2E_SM_VALID转换

每当在WindowSizeValid消息周期的间隔内检测到大于配置的损坏数据数量或小于配置的有效数据数量时，就会触发从E2E_SM_VALID到E2E_SM_INVALID的转换。

从E2E_SM_INVALID转换

从E2E_SM_INVALID到E2E_SM_VALID的转换在WindowSizeInvalid消息周期的间隔内被触发，该间隔小于配置的损坏数据的数量并且大于配置的有效数据的数量。

状态机中使用了许多函数：

  • E2E_SMAddStatus（）
  • E2E_SMCheckInit（）
  • E2E_SMClearStatus（）

E2E_SMCheck（）中的步骤E2E_SMAddStatus（ProfileStatus，State）应如下图所示。
在这里插入图片描述

E2E_SMCheckInit（）用于根据所选配置初始化状态机。
E2E状态机应具有与函数E2E_SMCheckInit（）相关的行为，如下图所示。
在这里插入图片描述

E2E_SMClearStatus（）初始化整个监控窗口（ProfileStatus窗口），以清除窗口开始。
在这里插入图片描述

如果WindowSize由于状态转换而增加，则E2E_SMClearRemainingStatus（）将初始化监控窗口（ProfileStatusWindow）的一部分。在这种情况下，通过将开头的附加窗口条目设置为E2E_P_NOTAVLABLE来清除它们。

E2E_SMCheck（）中的步骤E2E_SMClearRemainingStatus（Config，State，NextState）应具有以下行为。
在这里插入图片描述

如果触发到E2E_SM_INVALID的转换，则同时应用E2E_SMClearStatus（）和E2E_SMClearRemainingStatus（）。参数Config->ClearToInvalid表示要应用的函数：Config->ClearToInvalid=True:E2E_SMClearStatus（）Config->ClearToInvalid=False:E2E_SM ClearRemainingStatus（）。

AUTOSAR E2E配置文档 E2E Protection Transformer Chain
汽车电子电气
08-07 1759
E2E和基于COM的转换器用于安全相关数据元素的E2E保护。E2E保护带有控制数据：CRC + SC，在数据元素的序列化表示上执行。这意味着当使用E2E转换器时，序列化需要由E2E转换器上方的转换器执行，例如基于COM的转换器或Some/IP转换器。：只有在使用RTA-RTE 6.1.0之前的版本和RTA-BSW 12.0.0之前的版本时，才选择此工作流程。E2E保护的概念假定与安全相关的数据交换应在运行时受到保护，以防止通信链路内的故障影响。与RTA-BSW 12.0.0之前的版本一起使用。
Vector - CAPL - CRC算法介绍（续）
车载网络测试
04-06 2823
CAN通信测试中常见的CRC校验算法函数介绍
【E2E】E2E通信保护协议学习3 E2E Profile 1
qq_45302638的博客
09-09 7926
E2E
CRC8查表法中表的具体计算过程
热门推荐
四点能的博客
09-25 2万+
最近看CRC比较多，在翻译完一个英语文档后感觉对CRC的原理有了比较深入的了解，在理解原理后，进入CRC算法的实际应用，当我在网上查找CRC8资料时，看见最多的是这段代码: /***************************************************** 描 述： CRC8校验子程序 x^8+x^5+x^4+x^0 入口参数： 指向数组指
CRC8校验原理
tingyu522的博客
07-26 3346
CRC-8校验码计算原理
【CRC】一文搞懂CRC-8 SAE J1850 ZERO校验和
paperplaneY的博客
06-19 1万+
通过这篇文章我们讲解了什么是 CRC 校验和、如何计算 CRC8 校验和、以及如何使用查表法来实现 CRC 校验
End-to-End-Learning-of-Communications-Systems-Without-a-Channel-Model:研究论文的实施
03-11
没有通道模型的端到端通信系统学习 此回购协议是研究论文的实施：没有通道模型的通信系统的端到端学习 链接到本文： : 链接到我们的演示文稿： : usp （演示文稿为pdf）附在仓库中） 使用的库列表 ...
DETR- End-to-End Object Detection with Transformers 论文解析Yannic Kilcher版本
06-14
DETR- End-to-End Object Detection with Transformers (Paper Explained)，来自需要你懂得的网站视频，生肉版本。
TACOTRON：走向端到端语音合成 TACOTRON: TOWARDS END-TO-END SPEECH SYNTHESIS.pdf
06-28
我们提出了几个关键技术，使sequence-to-sequence框架能够很好地执行这项具有挑战性的任务。Tacotron在美式英语上获得了3.82分的主观5级平均意见分数，在自然度方面优于生产参数系统。此外，由于Tacotron在帧级别...
Machine Learning End-to-End guide for Java developers epub
10-16
Machine Learning End-to-End guide for Java developers 英文epub 本资源转载自网络，如有侵权，请联系上传者或csdn删除 本资源转载自网络，如有侵权，请联系上传者或csdn删除
【10】Towards End-to-End Speech Recognitionwith Recurrent Neural Networks.pdf
08-26
that trains the network to minimise the expectation of an arbitrary transcription loss function. This allows a direct optimisation of the word error rate, even in the absence of a lexicon or language ...
crc8查表法校验程序和校验检查软件
08-03
crc8校验的原理，程序和检验软件 CRC即循环冗余校验码（Cyclic Redundancy Check）：是数据通信领域中最常用的一种差错校验码，其特征是信息字段和校验字段的长度可以任意选定。 CRC校验可以简单地描述为：例如我们要发送一些数据（信息字段），为了避免一些干扰以及在接收端的对读取的数据进行判断是否接受的是真实的数据，这时我们就要加上校验数据（即CRC校验码），来判断接收的数据是否正确。在发送端，根据要传送的k位二进制码序列，以一定的规则（CRC校验有不同的规则。这个规则，在差错控制理论中称为“生成多项式”。）产生一个校验用的r位校验码(CRC码)，附在原始信息后边，构成一个新的二进制码序列数共k+r位，然后发送出去。在接收端，根据信息码和CRC码之间所遵循的规则（即与发送时生成CRC校验码相同的规则）进行检验，校验采用计算机的模二除法，即除数和被除数（即生成多项式）做异或运算，进行异或运算时除数和被除数最高位对齐，进行按位异或运算，若最终的数据能被除尽，则传输正确；否则，传输错误。 CRC8即最终生成的CRC校验码为1字节，其生成多项式，生成多项式为g(x)=x8+x5+x4+1，相当于g(x）=1•x8+0•x7+0•x6+1•x5+1•x4+0•x3+0•x2+0•x1+1•x0，即对应的二进制数为100110001。 CRC8校验算法： 1.CRC8校验的一般性算法： 例如： 信息字段代码为: 00000001 00000010 ———— 对应m(x)=x8+x 生成多项式为：g(x)=x8+x5+x4+1 ———— 对应g(x)的二进制代码为：100110001 现在我们将要对2字节数据0x0102生成CRC8校验码，并最终将生成的1字节CRC校验码跟在0x0102的后面，即 0x01 02 ##，（##即8为CRC码），最终生成的3字节数据就是经CRC8校验生成的数据。 先计算x8m(x)=x16+x9，对应的2进制数为：100000010 00000000 。可以看到这样运算所得到的结果其实就是将信息字段代码的数左移8位。因为最终要将生成的8位CRC8校验码附在信息字段的后面，所以要将信息字段的数左移8位。最后用x8m(x)得到的二进制数对生成多项式g(x)进行模二运算，最终的余数（其二进制数的位数一定比生成多项式g(x)的位数小）就是所要的CRC8校验码。 100000010 00000000 ^ 100110001 --------------------------- 000110011 00000000 ^ 100110 001 --------------------------- 010101 00100000 ^ 10011 0001 --------------------------- 00110 00110000 ^ 100 110001 --------------------------- 010 11110100 ^ 10 0110001 --------------------------- 00 10010110 对x8m(x)做模二运算取余得10010110（0x96），这个8位的二进制数就是CRC8校验码。所以，经CRC8校验后研发送的数据就是0x010296。 2.CRC8校验在DS18B20中的应用： 以上分析的是常规的CRC8校验方法。在DS18B20中，有两处用到CRC。一是DS18B20的8字节的序列号，最后一字节是前面七个字节的CRC码，这是为了保证序列号的唯一性与正确性；另一个是在DS18B20内部9字节的高速温度存储器，其第9字节是前面8个字节的CRC校验码，这是为了温度数据传输的正确性。而在DS18B20中生成CRC码所用到的方法不同于常规生成算法，它采用的是逆序CRC信息单元编码算法，该CRC的生成是由DS18B20中的多项式寄存器通过其中所包含的移位寄存器以及异或门对输入该多项式寄存器的每一位二进制数做一定的运算所得到的CRC码（可以查看Maxim官网上DS18B20的应用笔记Note27，专门介绍DS18B20CRC详细生成过程）。在此列举两种DS18B20CRC校验的C程序。
CRC循环冗余校验算法及模型
zataji的博客
04-26 1530
文章目录一、CRC冗余校验算法二、常见CRC参数模型 提示：以下是本篇文章正文内容，下面案例可供参考 一、CRC冗余校验算法 byte Crc_CalculateCRC8_desay(byte data[],int dataLen) { int i,j; byte polynomial; //多项式 byte initValue; //初始值 byte xorout; //结果异或值 polynomial = 0x2F; initValue = 0xFF; xorout = 0xFF; f
【ETAS CP AUTOSAR基础软件】DET、Bfx、CRC、ComStack、rba_ArxmlGen模块详解
十六宿舍的博客
06-15 3091
文章包含了AUTOSAR基础软件（BSW）中DET、Bfx、CRC、ComStack、rba_ArxmlGen模块相关的内容详解。本文从AUTOSAR规范解析，ISOLAR-AB配置以及模块相关代码分析三个维度来帮读者清晰的认识和了解DET、Bfx、CRC、ComStack、rba_ArxmlGen。
CRC校验（VB&VC)
国际海员
11-20 2706
MCRC16.bas这个就是快速 CRC ,用查表代替计算。Option ExplicitPrivate HI16(0 To 255)  As BytePrivate LO16(0 To 255)  As BytePrivate bInited         As BooleanPublic Function CRC16(Data() As Byte) As Integer    Dim C
E2E lib-P01
最新发布
qq_43370254的博客
07-05 1391
E2E 的保护与校验机制需要发送端和接收端的配合使用，对待发送的数据调用E2E_PxxProtect API 执行数据保护，将使用Crc 算法计算的Crc 校验信息、计数器信息(根据选用不同保护策略，还可能包括数据ID 信息与数据长度信息)回填至数据一同发送至总线。在接收方，调用E2E_PxxCheck API，使用同样的Crc 算法计算Crc 值，校验Crc 是否一致，并校验计数器信息(与数据ID 信息与数据长度信息)以确保发送端和接收端的数据保持一致，保证信息的完整性。如果尚未收到数据，则值为0x0。
Autosar E2E模块
m0_56208280的博客
12-14 1万+
E2E(End to End)模块， 中文即端到端的通信保护，是 `BSW`` 的组成部分， 目的在于提供数据保护与校验机制， 在数据交互时对数据进行保护与校验， 以防通信链路内故障的影响。
【CRC】CRC推导（五）CRC8的各种实现
beatfan的博客
04-30 3267
CRC8 算法实现与表格推导
SOME/IP开源库Vsomeip E2E保护实现分析
w5678912345的专栏
03-21 9468
1. 背景 E2E保护是autosar标准中定义的，主要是为了保护通信安全（功能安全相关）。因此在原有的通信协议上增加了对应E2E的保护头部分。相关E2E会修改整体的通信协议的payload部分，因此如果需要支持E2E保护，那么通信双方都需要增加E2E的保护机制。 E2E保护其实主要是在原有的包中增加了CRC校验的部分来保证消息的完整性（从安全角度来说，并不能完全保证），以及增加对应的引用计数，来判断消息是否有缺失，重复等等现象。 1.1. autosar描述profile4 在E2E pr
end-to-end memory networks
03-16
End-to-end记忆网络是一种神经网络模型，用于处理自然语言处理任务，如问答和机器翻译。它通过将输入序列转换为向量表示，并使用注意力机制来选择相关信息，从而实现对上下文的理解和推理。该模型在许多自然语言处理任务中取得了很好的效果。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Jetty.Liu

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值