linux can 标准帧冲突,改善错帧漏检率的方法 - CAN协议的错帧漏检率推导及改进过程简介...

3 改善错帧漏检率的方法

在本文的分析中可以见到，由于填充位规则需要收发同步执行，不同步时会极大干扰CRC校验，例如CRC校验本来可以将所有奇数个错检测出的，小于5位的多 bit错是可以检测出的，但只要有了成对的填充位错位，增加的奇数个错也可以是漏检的，增加的多bit错也可以是漏检的，如图4所示。

图4 有多位错的例子

漏检错的根源是CAN的CRC在执行填充位规则前生成，最根本的解决办法是像参考文献［3］指出的那样，要把CRC校验放在执行填充位规则之后。但是这样作就会根本修改CAN协议，在已经大量应用的情况下如何作到的改进前后的兼容性是个艰难的课题。作为局部的改正，参考文献建议加附加的检验。在数据域添加一个新的不同的CRC检验时，根据本文的分析方法，当误差多项式Ec是这个新CRC和CAN的CRC的公倍数时，仍然可以构造出漏检的实例，并计算出新条件下的漏检错帧概率。例如采用8位的DARC?8生成多项式x8+x5+x4+x3+1，它不含x+1因子，所以与CAN生成多项式的最小公倍数构成的漏错多项式Ec将有24阶，此时如2.5节所分析的那样，总帧数将增大28倍，而漏检帧数不变，漏检率就减少28。但是这种方法的缺点是不能实现自动报错，无法使节点间取得数据的一致性：有局部错的节点在添加上述措施后在收完帧后才能发现错，已无法要其他节点也丢弃该帧并要求自动重发。

本文建议采用7b/8b的编码办法，牺牲一些带宽，换取错帧漏检的避免。具体做法是在8b代码中选取不会发生填充位条件的部分，供原来7b编码使用。

其他的编码办法也是可行的，类似7b/8b的还有6b/7b、5b/6b、4b/5b，它们的区别是软件实现时的复杂程度以及开销占用数据域的多少，当用7b/8b时CAN可以每帧送7字节数据，而用4b/5b时每帧只能送6字节数据。

在附加数据域的软件补丁后，若发生在ID域和CRC域的填充位规则只有单边执行情况时，夹在它们中间的控制域就会左移或右移，帧长就会变大或变小。帧长的单位是1字节，它会使CRC域移入EOF域，CRC最多连续5位相同，就破坏了EOF的格式，或者EOF域移入CRC域，EOF的连续8位破坏了CRC的填充格式，所以此时单边执行填充位规则的错的后果是能被发现的。也就是说加软件补丁后不再有错帧漏检可能。

如果可疑Tx只发生在ID域，由于Tx有一个最短长度，相应于Ec，t= x3+x+1，这个长度是3+15+6=24位，所以对CAN2.0B的29位ID可能会出错，那么产生的后果就是接收节点收到的ID有错，这是一种假冒错(Masquerade)。在参考文献中提到了CAN防止假冒错的方法，实际上将ID分为二部分，一部分是一个附加的CRC，只要这个CRC生成多项式与CAN的不同，就不会产生假冒ID通过接收滤的可能。

4 小结

CAN的错帧漏检率对应用的可靠性有非常大的影响，本文发现了可能出错漏检的可疑帧重构的方法，从而求出的错帧漏检率高于Bosch提供的数据几个数量级。对于已经在应用的大量可靠性要求高的系统，迫且需要应对的方案，2007年CAN芯片1年的出货量为6亿，可见影响之广。本文提出了对数据添加 7b/8b编码/译码的中间软件补丁的方法。这种方法在牺牲部分带宽，增加一些个复杂性的付出后，根本上解决了填充规则对CRC检验的干扰，使CAN的错帧漏检率回到与一般通信协议中CRC检验同等的水平。数据域牺牲的带宽为8 bit，相对可能出现16 bit填充位而言，这算不了什么，而且减少了送达时间的抖动，可说是有好处的。不利之处是编码/译码需要的时间与空间。

这个方法也可以在将来加入到芯片中去，利用CAN的保留位，识别有无7b/8b编码/译码功能，从而实现与原有CAN2.0的兼容。有7b/8b编码/译码功能时，需要的7b/8b编码/译码、字长圆整以及帧长修正均可由硬件自动完成。