文章目录
- 介绍
- 端到端中的端指的是ECU吗
- 为什么要做 E2E
- E2E 的保护和校验机制
- 需要知道的名词
- 1. Checksum
- 2. Counter
- Timeout
- DataID
- E2E Profile
- 1. E2E Profile 01
- 2. E2E Profile 02
- 3. E2E Profile 04
- 4. E2E Profile 05
- 5. E2E Profile 06
- 计算 checksum 示例
- Counter
- 1、Rolling counter/ sequence counter
- 2、Alive counter
- E2E 状态机
- 示例
- 模块功能关系图
- 功能点
- 参考
介绍
E2E(End to End)模块， 中文即端到端的通信保护，是 `BSW`` 的组成部分， 目的在于提供数据保护与校验机制， 在数据交互时对数据进行保护与校验， 以防通信链路内故障的影响。
E2E模块保护数据的算法其实就是CRC，它主要就是定义了怎样使用CRC算法来确保数据的准确性。
端到端中的端指的是ECU吗
不是，对于E2E来说，数据的传递不是针对ECU到ECU的层级而是SW-C到SW-C层级。
在车载网络中，信息交换通常是从一个ECU发送信号，另一个ECU接收信号。对E2E而言，通常是从源SW-C生成信号，经过RTE（Run-Time Environment）、BSW（Basic Software）并在物理总线上传输后到达目标SW-C。在这个过程中，信号的传递可能由于一些故障情况（比如软件运行错误）无法到达目标终端，或是信号本身被干扰/损坏，尤其对于安全相关的信号（车速、档位、车辆/电源模式等）来说，这种情况会带来很大的隐患。而E2E正是通过一些机制，使发送终端和接收终端的数据保持一致，保证信息的完整性。
为什么要做 E2E
E2E保护概念的核心是针对安全相关的数据交换，需要在运行时进行保护，以消除通信链路中可能的失效带来的影响。
关于数据交换过程中可能的失效模式有哪些，这个问题ISO26262中有总结，如下:
- 信息的重复发送(RepetitionofInformation)，相同的信息被收到了多次
- 信息的丢失(LossofInformation)，整条或者信息的一部分在通信过程中丢失
- 信息的延迟(DelayofInformation)，接收信息的时间异于期望的时间
- 信息的插入(InsertionofInformation)，多余的内容被插入到信息中
- 假冒的或者不正确的寻址(MasqueradeorIncorrectAddressingofInformation)，假冒的发送者发送未认证的信息被接收端接受，或者正确的信息被错误的接收端接受
- 信息顺序错误(IncorrectSequenceofInformation)，数据流中的信息顺序错误
- 信息破损(CorruptionofInformation)，信息的内容被篡改
- 向多个接收端发送非对称信息(AsymmetricinformationsentfRomasendertomultiplereceivers)，接收端收到的数据不一致
- 仅部分接收端收到发送者的信息(Informationfromasenderreceivedbyonlyasubsetofreceivers）
- 阻塞通信通道(Blockingaccesstocommunicationchannel)
E2E 的保护和校验机制
E2E 的保护与校验机制需要发送端和接收端的配合使用
- 对待发送的数据调用
E2E_PxxProtectAPI 执行数据保护， 将使用Crc算法计算的Crc校验信息、 计数器信息(根据选用不同保护策略， 还可能包括数据ID 信息与数据长度信息)回填至数据一同发送至总线。 - 在接收方， 调用
E2E_PxxCheckAPI， 使用同样的Crc算法计算Crc值， 校验Crc是否一致， 并校验计数器信息(与数据 ID 信息与数据长度信息)以确保发送端和接收端的数据保持一致， 保证信息的完整性。
与数据发送方相比，数据接收方需要处理的内容就显得更加复杂。包含序列丢失处理、序列无效处理、序列重复处理、超时处理等。
需要知道的名词
1. Checksum
顾名思义，和的校验，一般指CRC，在数据处理和数据通信领域中，用于校验目的的一组数据项的和，这些数据项目可以是数字或在计算校验总和过程中看作数字的其他字符串
2. Counter
以profile 01为例，在报文中占4bit，范围0~15(profile1)，用于计数，发送端每发送一帧报文，计数+1，ECU1将计数值发给ECU2，ECU2对收到的counter进行比较，确认是否及时接收，当达到15，下次重新开始计数。
Timeout
通过counter来评估报文是否丢失、延迟等。
DataID
一般为2个byte，是ECU1和ECU2之间提前定好的特殊字段，AutoSARprofile1中对E2E_P01DataIDMode定义几种模式：BOTH、ALT、LOW、NIBBLE，DataID用于报文checksum，但是特别注意的是这一段DID并不作为报文传输数据的一部分放在总线上，仅仅作为报文密钥，这就好比特务接头，开始聊正文之前，总要私下先确认好暗号，以证明“我接收的指令确实是期待的发送方所发送的”。
E2E Profile
E2E 提供 P01、 P02、 P04、 P05 与 P06 五种数据保护与校验方法， 每种 Profile 提供不同的保护策略。
无论何种profile，基本可分为以下两步骤：
- Step1：发送端通过增加控制字段拓展数据结构，控制字段一般包含：checksum、counter等，扩展处的字段由RTE进行发送，如下图所示：
- Step2：接收端对上述整个字段内的数据进行验证，如果pass，则移除其中控制字段，并将应用数据交给SWCs处理；如果nopass，则执行安全保护机制。
1. E2E Profile 01
E2E Profile01使用8-bit SAE J1850 Crc校验， 最大数据保护长度为30 Bytes。
| Mechanism | size |
|---|---|
| Counter | 4 Bits |
| DataID | 16 Bits |
| Crc | 8 Bits |
在 E2E Profile 1 中， Crc、 Counter 信息、 当 E2E_P01 DataID Mode = E2E_P01_DATAID_NIBBLE 时的DataID 信息在数据中位置由用户定义
Counter： 值范围为 0 至 15, 参与数据传输, 参与 Crc 计算。Data ID有四种模式：-
E2E_P01_DATAID_BOTH
-
E2E_P01_DATAID_ALT
-
E2E_P01_DATAID_LOW
-
E2E_P01_DATAID_NIBBLE
- 当
E2E_P01 DataID Mode = E2E_P01_DATAID_BOTH时， DataID 的长度为 16Bits。 DataID 两个字节均参与 Crc 的计算， 但是不参与数据传输； - 当
E2E_P01 DataID Mode = E2E_P01_DATAID_ALT时， DataID 的长度为 16Bits。- 当 Counter 为偶数时， DataID 的低字节参与 Crc 的计算， 但不参与数据传输
- 当 Counter 为奇数时， DataID 的高字节参与 Crc 的计算， 不参与数据传输；
- 当
E2E_P01 DataID Mode = E2E_P01_DATAID_LOW时， DataID 的高字节不使用， 应置为 0x00，此时相当于可用 Data ID 长度为 8Bits。 DataID 的低字节参与 Crc 的计算， 但不参与数据传输； - 当
E2E_P01 DataID Mode = E2E_P01_DATAID_NIBBLE时， DataID 高字节的高半字节不使用， 应置为 0x00， 此时相当于可用 DataID 的长度为 12Bits， 且此时 Data ID 高字节的低半字节不仅参与 Crc 计算，还与数据一起传输， 位置由 DataIDNibbleOffset 决定
- 当
-
2. E2E Profile 02
E2E Profile02使用8-bit 0x2F polynomial Crc校验， 最大数据保护长度为32 Bytes。
| Mechanism | size |
|---|---|
| Counter | 4 Bits |
| Data ID[16] | 8 Bits |
| Crc | 8 Bits |
区别于 E2E Profile 1， 在 E2E Profile 2 中， Crc 与 Counter 信息位置固定， 如下：
| Data[0] | Data[1] | Data[2] | ... | ... | Data[N-1] | Data[N] | |||||||
| Crc | Counter | ... | ... | ... | ... | ... | |||||||
Crc信息位于数据第 1 字节， Counter 信息位于数据第 2 字节低半字节。Counter： 值范围为 0-15， 参与数据传输, 参与 Crc 计算。DataID： 不参与数据传输, 只参与 Crc 计算， 且 DataID 的值动态变化， 与 Counter 相关， DataID = DataIDList[Counter]。
3. E2E Profile 04
E2E Profile04使用32-bit 0xF4ACFB13 polynomial Crc校验， 最大数据保护长度为 4K Bytes。
| Mechanism | size |
|---|---|
| length | 16 Bits |
| Counter | 16 Bits |
| Data ID | 32 Bits |
| Crc | 32 Bits |
Profile4 一般用于传输较大数据， Profile 4 中定义了一个 Header， 格式如下：
| Transmission order | 0 | 1 | 2 | 3 |
| 0 | E2E Length | E2E Counter | ||
| 4 | E2E Data ID | |||
| 8 | E2E Crc | |||
- 数据长度信息位于 Header 第 1、 2 字节，参与数据传输, 参与 Crc 计算, 便于动态改变传输数据的长度
- Counter 信息位于 Header 第 3、 4 字节， 参与数据传输, 参与 Crc 计算。
- DataID 信息位于 Header 第 5 至 8 字节，参与数据传输, 参与 Crc 计算。
- Crc 校验信息位于 Header 第 9 至 12 字节
- Header 在数据中的位置由 Offset 决定
4. E2E Profile 05
E2E Profile05使用16-bit CCITT-FALSE Crc校验， 最大数据保护长度为 4K Bytes。
| Mechanism | size |
|---|---|
| Crc | 16 Bits |
| Counter | 8 Bits |
| Data ID | 16 Bits |
Profile5 同样定义了一个 Header， 格式如下：
| Transmission order | 0 | 1 | 2 |
| 0 | E2E Crc | E2E Counter | |
- Crc 校验信息位于 Header 第 1 至 2 字节
- Counter 信息位于 Header 第 3 字节， 参与数据传输, 参与 Crc 计算。
- Header 在数据中的位置由 Offset 决定
- DataID： 不参与数据传输, 参与 Crc 计算。
5. E2E Profile 06
E2E Profile06使用16-bit CCITT-FALSE Crc校验， 最大数据保护长度为 4K Bytes。
| Mechanism | size |
|---|---|
| Crc | 16 Bits |
| length | 16 Bits |
| Counter | 8 Bits |
| Data ID | 16 Bits |
Profile6 同样定义了一个 Header， 格式如下：
| Transmission order | 0 | 1 | 2 | 3 |
| 0 | E2E Crc | E2E length | ||
| 4 | E2E Counter | |||
- Crc 校验信息位于 Header 第 1 至 2 字节
- 数据长度信息位于 Header 第 3、 4 字节，参与数据传输, 参与 Crc 计算, 便于动态改变传输数据的长度。
- Counter 信息位于 Header 第 5 字节， 参与数据传输, 参与 Crc 计算。
- Header 在数据中的位置由 Offset 决定
- DataID： 不参与数据传输, 参与 Crc 计算。
计算 checksum 示例
例如，AutosarE2Eprofile1规定采用CRC-8-SAEJ1850，对应多项式为0x1D(x8+x4+x3+x2+1)，通常情况下报文数据场中Byte0用于存放报文CheckSum数据，byte1~byte7存放报文其它数据，具体步骤如下。
Step1：计算DataID字段内CRC值(注：实际初始值为初始值取反)。
Step2：计算Byte1~Byte7字段内CRC值(注：实际初始值为上一步校验值取反)。
Step3：将上一步校验值取反，得到最终值。
Counter
在不同的标准，应用中经常听到不同的counter，但他们的本质是相关的，是一个计数器，并根据其数值变化来进行诊断数据的实时性。下面举两个例子
1、Rolling counter/ sequence counter
顾名思义，每当执行一次后，计数器先increment，达到最大值后清0，以rolling的形式周期性变化，这里强调的是每次执行都会增加固定数值，通常是1，接受端应该对增加量进行诊断。
常见的有0 -> 1 -> 2 -> 3-> … -> 14 -> 15 -> 0 -> 1 -> …以此类推，共占用4个Bit，也可以把其中某一数值作为无效值，常见的是15。
2、Alive counter
强调counter的实时性，只需要counter实时变化以体现输出者处于alive状态，接收端可只对数值是否变化进行判断，甚至不以counter的形式，比如以0101交替的形式也可以达到目的。
故alive counter至少是一个会不断变化的值。
E2E 状态机
E2E 状态机对监控窗口内的 E2E_PxxCheck 函数的结果建立一个状态， 提供给 Rte/SWC/Com。 E2E 状态机状态切换如下：
-
通过调用
E2E_SMCheckInitAPI 完成状态机初始化 ， 状态机状态由E2E_SM_DEINIT切换为E2E_SM_NODATA， 若监测到 E2E 校验结果为 E2E_P_ERROR 或 E2E_P_NONEWDATA， 状态机维持在此状态， 此时数据不可用， 否则， 状态机切换至 E2E_SM_INIT 状态； -
状态机在
E2E_SM_INIT状态下， 继续监测校验结果，若校验结果中校验结果为 E2E_P_ERROR 的次数不超过配置的最大错误次数且校验结果为 E2E_P_OK 的次数不少于配置的最小 OK 次数 ， 切换状态机状态至 E2E_SM_VALID， 此时数据可用，若在 E2E_SM_INIT 状态下， 校验结果为 E2E_P_ERROR 的次数超过配置的最大错误次数， 则状态切换至E2E_SM_INVALID， 此时数据不可用； -
状态机在
E2E_SM_VALID状态下， 同样地， 若校验结果为 E2E_P_ERROR 的次数不超过保持此状态允许的最大错误次数且校验结果为 E2E_P_OK 的次数不少于维持此状态的最小 OK 次数 ， 状态机维持在此状态， 此时数据可用， 否则状态机状态切换至 E2E_SM_INVALID 状态； -
状态机在
E2E_SM_INVALID状态下， 若校验结果为 E2E_P_ERROR 的次数不超过将状态更改为E2E_SM_VALID 所允许的最大错误次数且检验结果为 E2E_P_OK 的次数不少于将状态更改为 E2E_SM_VALID 所 需 的 E2E_P_OK 的最小检查次数，状态机切换至 E2E_SM_VALID 状态， 否则状态机维持 E2E_SM_INVALID 状态， 此时数据不可用。
示例
模块功能关系图
功能点
- 校验传输过程中是否存在数据的重复发送。 (通过 Counter 校验)
- 校验发送过程中是否存在消息丢失。 (通过 Counter 校验)
- 校验是否在指定时间内接收到信息。 (通过 Counter 校验)
- 校验传输过程中是否存在数据插入。 (通过 DataID 校验)
- 校验是否接收到伪装正确源地址的消息。 (通过 DataID /Crc 校验)
- 校验传输过程中是否发生数据损坏。 (通过 Crc 校验)
- 校验传输过程中是否发生数据顺序错误。 (通过 Counter 校验)
- 校验接收方是否从同一发送方接收到不同的信息。 (通过 Crc 校验)
- 校验发送方信息是否仅由一部分接收者接收。 (通过 Counter 校验)
- 提供 P01、 P02、 P04、 P05、 P06 数据保护与校验方法。
参考
- https://zhuanlan.zhihu.com/p/384692925
- http://www.shouxieziti.cn/30942.html
- https://www.sohu.com/a/573143632_121424192
- https://zhuanlan.zhihu.com/p/486553536?utm_id=0
- https://www.kuazhi.com/post/525980.html
- https://zhuanlan.zhihu.com/p/656805579?utm_id=0
