---

前言

在专栏文章仿真CAN报文发送的CRC校验算法（附CAPL代码）和同星TSMaster中如何自定义E2E校验算法中分别给出了CRC算法和E2E校验实现，从中也明白了为什么在测试中需要去做这些仿真。在车载网络测试中经常会出现CRC、E2E、checksum、rollcounter这几个词，这篇文章想搞清楚这几个概念具体的含义及用途。

---

1、E2E

E2E（End to End），端到端通信保护机制，目的是检测和减轻由于软件故障（系统级）、硬件故障（随机）以及外部干扰引起的瞬态故障等原因造成的通信问题。在AUTOSAR_SWS_E2ELibrary规范中提供了很多种E2E校验算法并给出了算法实现细节，如下图在第7部分功能规范中列举出如E2E_P01Protect、E2E_P02Protect、E2E_P04Protect、E2E_P011Protect等等。

E2E校验算法是可以采用CRC算法实现的，可以理解为CRC算法是E2E校验的一种方式，在实际测试中用的更多的还是基于CRC算法的“变体”，来增强通信安全。如上图，以E2E_P02Protect算法为例，每一个CAN报文都规定有一个唯一与之对应的DataID，在进行E2E校验的时候采用CRC8H2F算法对接收报文进行异或运算，之后把运算结果与DataID进行异或运算来得到E2E校验值写入到Data[0]中来完成整个的E2E校验过程。

2、CRC

CRC（Cyclic Redundancy Check），循环冗余检查，是数据通信领域中最常用的一种查错校验机制。以下图CAN报文为例，CRC校验码是单独存在于CRC场，算法相对Checksum来说更为复杂，常用的算法包括CRC-8、CRC-16、CRC-32。CRC校验的计算对象范围从SOF开始到数据场，主要用来错误帧的监测。

基本原理：
收发双方共同选定一个多项式，原数据帧进行模2除法差错检测，得到余数；将计算出的CRC校验码（余数）添加在原数据帧后，然后发送到接收端；接收端对收到的（新）数据帧做上述同样的除法运算，验证余数是否为0，为0则校验正确、无错误。

3、Checksum

Checksum校验和，一种数据校验码，来检查通信数据完整性，它通常直接添加在传输数据的末端。同样，它也存在多种算法实现，如累加和校验算法、异或校验算法、直接累加和算法。像LIN的校验和段采用的翻转八位和的校验方式就是一种累加和校验算法。CAN报文中Checksum通常放在数据场第一个或最后一个字节。通过报文FCU_1可以看到，Checksum是出于数据场内容之中的。Checksum的计算对象是CAN报文的数据场信号。

4、Rollingcounter

Rolling Counter，滚动计数器，主要是用于报文顺序的收发，计数从0-15之间进行循环。即每发送一帧CAN报文，Rollingcounter计数加1，累积到15后变为0继续循环。不难看出，Rollingcounter的主要作用是检测是否有丢帧或漏发帧的现象，保证通信数据的完整性。如上图，Rollingcounter通常也在CAN报文的数据场中。

---

总结

在车载网络测试中，E2E校验更注重端到端也就是ECU到ECU的完整性校验；CRC则注重于报文的错误检测；Checksum注重于报文数据段的完整性保护；Rollcounter则确保不丢帧漏帧。它们在车载网络通信中都必不可少，各有特点的保护着控制器通信的实时性和安全性。