原创 你必须要知道风险的根源

你必须要知道风险的根源

因为现在的中国已进入了汽车社会，年轻人或迟或早会有自己的车，而每台车上都用CAN总线在控制刹车、转向…，所以你要知道CAN的风险。我对CAN总线的出错漏检率的分析最近又进了一步：发现了Bocsh的数据为什么会错。我想这篇博客在你需要打官司时对你是一定是有用的证词。

Bocsh的数据是25年前（1990）的一篇报告中给出的，虽经这么长时间，他一直在引用其结论。

下面的讨论带一点学术性，不过我尽量讲得科普些。

一个帧传送中数据是否出了错，要有检验机制，在CAN中这是由随着帧一起送的CRC校验和进行的：发送方按自己送出的数据一起送校验和，接收方按收到的数据算出校验和，如果数据有错，校验和就对不上了，接收方可以丢弃这个错误的数据，等待重发的真的有效数据。可是如果CRC校验失效，错的数据就会被收下并经过控制机构执行，比如当你减速的时候，经CAN传送的命令被解释为加速，是否可怕？

不幸的是CAN总线的CRC校验确实存在这样的漏洞，其原因是CAN的帧中有一种填充位规则，每传送5个相同的位值必须填充一个相反的位值：接收方见到5个相同的位值必须删去一个相反的位值。这是为了避免太长的相同位序列造成同步的困难。如果接收方发现有6个相同的位值，就表示出错了，就会报错等待重发。可是如果这5个相同位发送中有一位出了错，接收方就收不到5个连续相同位，就不执行填充位规则；或者发送方没有5个连续相同位，不执行填充，但是由于传送中有一位错而接收方见到了5个连续相同位，它就执行删除操作。这种不对称执行填充位规则造成了收发双方数据的移位，将它们位对位逐位比较，就可能发现出了大量的错。

这些大量的错在某些条件下会使CRC校验失效，Bocsh发现了这种失效机制，他的文章就是评估究竟会造成多大的错帧漏检率，他的最终结论是Pun=4.7*10^-11。暂不说这个数据对安全是否够，这个数据是大大低估了，我求得的是Pun=1.37*10^-7。

Bocsh把这种可能出错的数据流称为critical sequence，然后通过大量随机的搜索来找这种序列（CS），在找的过程中找规律，其中找到的规律是二条：对于有二位错构成的CS漏检的比率为const_k=4.5*10^-7；CS在数据域与CRC域内出现的多次引起贡献量的修正值是Estuff(L)=0.5~1.4。他把每一种长度（L）不同的CS对错帧漏检率的贡献都看作一样，然后再在长度范围内求和，得到总的错帧漏检率。

那么这种方法错在那里？我再三细读了文章，发现了他们工作失误的原因。为了说明的方便，我把文章的部分内容截图如下：（根据我国2001年版著作权法第二十二条第二款，我这是合理使用：为介绍、评论某一作品或者说明某一问题，在作品中适当引用他人已经发表的作品。）

因为没有从根本机理上进行分析，所以就导致归纳上的错误，从截图上可以见到长度的范围为30~80bit。这一限定就把许多短的CS排除在外了，例如长度23~29的CS是非常主要的错帧漏检实例的贡献者。CS的长度越短，贡献越大，这有二方面的原因，一是特定CS实例在L长的所有可能位流中占的比率是与长度有关的，一个23位CS实例占的比率是2^-23，而一个30位实例占的比率是2^-30，也就是讲，一个23位长度CS实例对漏检的贡献是一个30位实例CS对漏检的贡献的128倍；其次，CS可以在64位数据域与15位CRC域中存在在任何地方，一个23位的CS可出现的位置有57种，而一个30位的CS可能出现的位置有50种。所以Bocsh的数据漏掉了主要贡献者，拣了芝麻，丢了西瓜。

其次归纳上的错误还表现在Estuff(L)上。因为CS漏检的根本机理是：特定位出错后，收发位流的移相造成的误差流是CRC生成多项式的倍数，而与一帧中出现填充位的概率是无关的。Estuff(L)是对实例数的一种修正，就像上段所讲同一CS可以在不同位置上，所以Estuff(L)是低估许多了。对于CS长度为30~80的实例发生在特定位置时，漏检的比率与我的推导是一致的，即15*2^-25=4.47*10^-7~Bocsh的const_k，但由于Estuff(L)的低估，造成Bocsh在CS长度为30~80时漏检率有很大低估。

图1. Bosch 文章中限定CS长度的部分

有兴趣的读者可以详读本博可下载文章Residual Error Rate of CAN FD中的附录。

那么在应用上添加额外的CRC检验是否有用？分为二种情况讨论：

第1是只有一个接收节点要用此数据。此时附加的CRC检验可以查出错。但是没有新的正确的数据来刷新，就看应用的时限容许不容许。有些控制系统设计比较鲁棒，丢一个数据没关系。但是这种情况下不能再有其他故障，例如使新的有效数据迟迟来不了的情况。不幸的是，CAN有一种消极报错状态时的等效离线状态，它可以产生几十到上百ms的等效离线，此时节点总在报错状态，既不能收，也不能发，那来新的正确的数据？

第2是一个数据要被多个节点用，比如新能源车的4轮驱动，它们要同步加速，如果添加附加CRC检验后一个轮子发现错了不加速，那么车就转向了：因为控制系统的安全设计是在丢包后最合理的估计值是原来的数据，而原来值在红灯时是停止，三个轮子加速，一个轮子停止就转圈了，会有转到逆向车道可能。此时除了第一种情况下的问题外，节点间又有不同步安全风险。

所以在应用层添加额外CRC检验是不得已的方法，要证明有效是很难做到的，你能证明不发生等效离线吗？你能证明不同步没关系吗？

有车的各位请在4S点维修时请留意有没有CAN通信的故障记录，例如我以前博文中讨论VW的DSG故障时提到过的一些，发动机也有（详细请有关的维修专家补充）。换档时大的响声，很可能是发动机与离合器动作没协调，而不协调的原因是CAN通信出了错，然后又重发刷新了，这个错短于250m时还不会记下来。如果有记录，表明你的车干扰大，CAN错帧漏检与等效离线隐患发作的风险正在加大，就一定要保留证据，以便不时之需。

CAN FD正在升温，我对它的错帧漏检率进行了分析，作为可下载文件附在后面，对CAN2.0的分析作为该文附录。这篇文章很长（45页），恐怕看的人很少了，ISO TC22的CAN专家们告诉我，他们正在研究这篇文章，希望有志将来为中国发出声音的年轻人不要错过这件事，你们可以与专家门同步研究这篇文章。真是谢谢互联网，通信和下载省去了许多繁文缛节。