一文详解Checksum和RollingCounter校验

对于汽车控制器的软件开发和功能安全方面的需求，我相信大家或多或少都听说过E2E（End2End，端到端）保护或AutoSAR E2E profile保护机制。那它们到底什么？如果你继续了解会发现有ID、长度、Checksum和Counter等校验方法。在E2E概念尚未正式提出之前，其实主要的一些校验方法就广泛应用到CAN通讯中，也就是大家在CAN通讯矩阵或DBC文件就常常可以看到Checksum信号和Rolling Counter信号，如下所示：

Source: https://www.tosunai.com/crc-e2e-checksum-methods/

为什么需要使用这两个信号？ 因为CAN报文信号在汽车CAN总线网络中传输会出现衰减，也会受外界环境因素影响，比如电磁干扰，CAN总线网络遭到黑客入侵或攻击等现象，这些都可能导致接收端接收到的信号与发送端发出的信号不一致，因此就需要应用一些校验机制来确保CAN报文数据的完整性、真实性和可靠性。 

那为什么最常采用Checksum和Rolling counter校验而不是其他校验机制？这就有必要详细探究这两者，因此下文将对Checksum和Rolling counter校验展开详细的介绍。

Checksum即校验和，Checksum是一种高效的错误检测机制，其原理是：发送端先通过规定的计算方法得到一个Checksum值，再作为一个信号添加到CAN报文的数据段，发送出去；接收端接收到该报文后，先使用相同的计算方法重新计算出一个Checksum值，然后与接收到的Checksum值进行比较。如果结果一致就说明接收数据正确，否则就认为数据有错误。下图示意一个Checksum计算与校验的例子：

Source：Checksum (myreadingroom.co.in)

发送方：

• 先初始化Checksum值为 0，并将所有数据项相加，结果为36；

• 再通过一套特定的算法计算得到最终Checksum值为 9；

• 最后发送方将数据和Checksum值一起打包发送给接收方。

接收方：   

• 先解包所接收的数据，再采用与发送方相同的方法相加所有数据；

• 然后通过一套规定的算法计算得到最终Checksum值，最终接收方计算出的Checksum值为 0，这意味着数据未损坏。

这就是Checksum的基本概念，那么应用到汽车控制器的CAN报文的具体情况是怎样的？

1）首先，针对CAN报文（数据帧），要注意Checksum和CRC的区别，这两者不是同一个概念，但很多人认为两者是同一个东西！我最开始也这么认为的，因为都涉及CRC。

注意这两者在CAN报文中的定义，如下所示：

这两者有几点区别：

• 两者的位置。Checksum在CAN报文的数据段，一般在数据场的第一个字节或者最后一个字节，而CRC在CAN报文的CRC段；   

• 两者的计算对象。Checksum是针对CAN报文数据段的信号采用相应的CRC校验算法（常使用CRC8, 16, 32）计算出Checksum值，而CRC是针对CAN报文的帧起始、仲裁段、控制段和数据段采用相应的CRC校验算法（常使用CRC1, 15, 17和21）计算出CRC值；

Source: http://www.zlgcan.com/canfd/399/

• 两者的作用。Checksum是用来校验数据被正确的打包和解包、确保数据的加密和数据的可信度，而CRC用来保证数据传输的正确性和完整性。

2）其次，在汽车控制器的CAN报文中有2种Checksum的应用方式。一种是一条报文有一个Checksum值；另一种是一个信号组对应一个Checksum值，即一条报文多个Checksum，这样有助于提高破解数据的难度。总的来说Checksum的应用方式是很灵活的，可以根据自身需要制定。

3）然后，关于Checksum计算方法，通过具体代码的例子来看，比如采用CRC8（G(x) = x8 + x5 + x3 + x2 + x + 1）计算Checksum，如下所示： 

Source: CRC校验码计算，以常用CRC-8为例_算法_up up day

即输入数据及其长度，即可计算到相应的Checksum值。当然在工程上，要综合考虑费计算的资源和时间，直接调用CRC计算函数去处理数据较多的情况会耗资源耗时间，因此在工程实现上普遍采用查表法，即先穷举出所有的结果，在软件中以常量数组形式存在，此时计算CRC只需要给定输入查表，就可以输出相应的Checksum值，如下所示：

Source: CRC校验码计算，以常用CRC-8为例_算法_up up day   

最后，根据比对Checksum值进行判断，一般规定连续三帧以上信号的Checksum不对，则认为该报文数据有问题，并丢弃该报文数据，以此防止发送的报文出错。

回顾上述过程，发送方根据报文数据段数据计算出Checksum值并将其置于CAN报文数据段，发送报文到CAN总线；接收方也会根据收到的CAN报文后用规定的算法计算出Checksum值，与接收到的对比来判断所接收的数据是否准确。

Source: https://baijiahao.baidu.com/s?id=1656396925096307630

通过上图不难理解，如果通讯出现间歇或中断、或者ECU不工作，从Rolling counter的波形很容易可以看出。Rolling counter 的作用是用来判断报文传输过程是否出现漏帧，如果出现计数不连续或首尾值不对，接收方会认为丢帧，同时会报报文丢失或超时故障码。通常规定连续五次出现相同的rolling counter值，或连续3次连续两帧之间的rolling counter差值大于2，则认为rolling counter发生错误。 

总的来说，结合使用Checksum和Rolling Counter，可以实现对CAN总线网络数据的精确校验和顺序监测。Checksum确保CAN报文数据内容未被破坏，而Rolling Counter则确保数据帧的连续性和有序性，两者相辅相成，这样既保证了数据的正确性，也检测了数据的完整性与顺序性，这对于汽车这样对通讯网络实时性和安全性要求极高的系统至关重要。

最后再着重提下CRC与Checksum的区别：

1）数据检查。CRC是针对CAN物理通信机制本身的信号校验，CRC段的数据校验解决的是数据从一个CAN节点到另一个CAN节点的信号无损传输问题；而Checksum用来信号校验，数据场的Checksum校验算法的应用是为了校验数据被正确打包和拆包，与CRC场固定的校验算法不同，Checksum校验算法由ECU控制器开发供应商自行制定，在CRC的计算方式的基础上，Checksum计算规则高度灵活。

怎么理解这点，这就好比你网上买了一辆自行车，快递到了要签收，你需要确认两点：第一包装是否完整，是否有破损；第二拆开包装，检查零部件是否齐全，是否有损伤。类比的话，CRC就是第一点的包装检查，大家的检查方法基本一样，肉眼可见；Checksum就是第二点的零部件检查，可能每个人的检查方法还不同，两者皆好，那就认为没问题。

2）数据加密。CAN节点接入CAN总线是不需要使用加密手段，只要有DBC文件，那么就有可以破解CAN报文信息，如果汽车的一些关键信息被篡改，那么可能会严重汽车的行驶安全和财产安全。比如曾经热点事件：网络安全盛会-2015美国黑帽大会上，安全研究专家Charlie Miller和Chris Valasek同样就他们是如何黑客入侵Jeep大切吉诺。   

如果对一些车速，油门和制动等关键信号，添加增加一个Checksum计算，那么将意味着这时要侵入CAN通讯网络，不仅需要有DBC文件，还需要这些关键信号的Checksum计算方法，因此不难理解，通过这样的方式对CAN通讯进行数据加密，肯定是能提升汽车网络的安全性的，而CRC的计算对象和计算方法很固定，破解难度相对小了很多，这也是更需要Checksum的点。

3）信号的可靠性。CRC循环校验只有15位，信号的可信度并非100%，在多个字节中即使某些bit传输错误，CRC的计算值可能不变。而对于Checksum计算采用的CRC计算方法，据统计：CRC8校验的错误率大概为1/256，CRC16校验的错误率为1/65536。也就是说通过Checksum校验能提高数据的可靠性。

参考：

[1] 新能源汽车CAN和CANFD通信中的校验算法

[2] CRC校验码计算，以常用CRC-8为例_算法   

[3] 干货分享 | 详解TSMaster CAN 与 CANFD 的 CRC&E2E 校验方法

[4] CAPL编程的进阶应用 ——Checksum算法的实现   

/ END /