杨福宇老师多年研究CAN总线在汽车中的应用，文章非常有实用价值，为了方便汽车行业的工程师关注杨老师的研究成果，本公众号特别开设了《杨福宇专栏》，敬请期待更多精彩内容。杨老师邮箱：[email protected],欢迎交流探讨！
当你的控制系统作功能安全评估时，不可避开通信系统的安全指标。ISO CAN FD已经对CAN的错帧漏检作了较多的修补，例如：更长的CRC多项式，可以把填充位也算进去，从而避免填充规则的不对称执行造成的收发位流的错位引起CRC计算中出现错误增多；引入了格雷码的填充位计数器及其奇偶校验位、格式校验位，以更多的校验来避免漏检。
但是这些措施依然有漏洞。这些漏洞造成的漏检率的数值分析异常冗长，这里仅把实例举出，让大家有一个基本的了解。
第一个出错的现象是关键字的读错未能查出来
在ISO CAN FD中有一位BRS用于切换位速率，如果这一位读错了，那么有可能发送节点以高速传送，而接收节点以低速读取。在一定条件下，他们最后又是对齐的，这就跳过了ISO CAN FD的补充检验。这是以前CAN没有的漏错场景，而且是只有一个错。
图1 BRS出错的收发的不同理解
图1中举了速度不同而对齐的情况，其中没有考虑增加填充位时传送对齐的例子，例如高速传送中加了填充位而低速读取时没遇到填充位规则的满足条件，或者反之，相信再花些力气总可以找到这样的例子，不过麻烦些。
以图1中2倍速为例，CRC域部分含22位CRC17及5位填充位计数器共27位，Rx碰巧读到的数据符合漏检概率为2-27（这已经比CAN的CRC15检验多了12位，即漏检率为原来的2-12=1/4096），2字节数据时，BRS出错概率为1/77，于是Pun BRS=2-31/77=6*10-12。
图2 BRS前面的关键字
BRS前面的关键字出错会间接影响到BRS的解释，所以也要把这种情况考虑进去。假定Tx发送CAN FD 的扩展帧，有Tx-BRS=1 和 Tx-IDE=1。接收SOF 晚1位的错，早1位的错，IDE反转的错都可以导致BRS解释错。例如接收节点把IDE读为0，就会认为收到基本帧Rx-BRS= Tx-ID15，如果 Tx-ID15=0, BRS就错了。
毛刺也可能引起BRS移位而出错，这里从略。总计下来Pun BRS=8.4*10-11。当正常速率为1M/s, 数据速率为5M/s, 帧长 110 bit (4数据字节，不含填充位)
, 总线利用率40%, 则每小时送1.7*帧。当ber=0.01,qbad=0.001时, 关键位出错造成的失效率为Pfailure,key bit=1.7*107*0.01*0.001*8.4*10-11=1.4*10-8/h。
这10倍于分配给通信的容许值Pfailure=1*10-9/h。
第二个出错现象是检验设计的漏洞
CAN FD仍然采用动态填充位规则，当发生动态填充位规则不对称执行时， 帧长就有变化，Rx填充位计数器的检验域与Tx填充位计数器的检验域处在位流的不同位置。
例如图3中，当发生动态填充位规则不对称执行时1次时，Tx动态填充位规则执行2次而Rx动态填充位规则执行1次，Tx多加了一个填充位，这个填充位使Tx的数据d0比Rx的d0延后一位。然后数据流有了不同的解释，Tx的填充位计数器的检验域S210P=0（011）0被Rx解释为210PS（001）10，它符合Rx计算出的填充位计数器的检验值（注意这里011、001均是格雷码），所以有错而检不出。
图3 填充位规则不对称执行被漏检的例子
这部分出错之后漏检的分析比较复杂，此处略去。基本的方法是在数据域用计算机搜索，从假设有1个错查起，如没有漏错例子，就假设有2个错查，如此执行。当假设出现3个错时，发现了漏检错的实例。即满足动态填充位规则不对称执行1次时（例如Tx填充位计数器=1,Rx填充位计数器=2），且数据流移一位后CRC17检验通得过的情况。
图4是分析中用于数据流移一位后求取出错多项式的例子
在CAN FD 中规定，发送1位CRC分界符时读到2位CRC分界符时是容许的，所以收发帧长差1位将不会报错。
在分析长度不同帧的Er多项式时，要按较长帧到达的位置来考虑CRC0位置的Er0。此时要补充短的一方的对应CRC0*。当Tx早结束时，Tx方将补充一个逻辑值0，当Rx方早结束时，Rx方将补充一个逻辑值0。这是因为短的一方的码字已经结束，再加1个0不影响它的CRC检验结果：如果无错，CRC寄存器内本来就该是0，再移1位并最低位补0时CRC寄存器内依然是是0。
由图4可得到Ertail=1000,1000,1000,1000,1000,11。然后搜到满足要求的数据域出错的位置I,j,k，使I,j,k的出错满足Er是CRC17的倍数，从而发生漏检。
Solution1: CRC (3, 31, 111) =1001,0110,0011,1110,0
Solution2: CRC (19, 83, 95) =1001,0110,0011,1110,0
Solution3: CRC (22, 26, 52) =1001,0110,0011,1110,0
Solution4: CRC (15, 33) =1000,0110,0011,1110,0
Solution5: CRC (16, 35) =1101,0110,0011,1110,0
Solution6: CRC (53, 58) =1001,0100,0011,1110,0
图5 描述数据流移一位时后面检验是如何通过的例子
这种情况时算的漏检的概率是相当大的，细节略去。
Pun.asym=sum of (Pstuff*mswop*Plocation*Pfix*msckcase*PSCk)
=5*2-4*3*3!/(110*109*108)*2-5*(4+4+1)*1/8
=1.52*10-7
但是由于要发生3个错，每个错对应的ber=0.01，所以失效率不是很大:
Pfailure,asym~1.7*107*0.013*0.001*1.52*10-7=2.6*10-9/h
第三个是数据域内发生毛刺引起数据流的移位而漏检
图6 由毛刺引起的数据流移位的例子
图6是毛刺引起丢失1位的情形，然后发生了数据流的移位。在填充位计数器的stuff（或parity）位传送时产生了bit flip，满足了填充位计数器检验的格式要求。因此漏检的条件有2条：一次毛刺加一次位反转，即有2个错。
这里与动态填充位规则不对称执行时（第2节）的情况不同，发生在Tx与Rx填充位计数器均为000或111时，产生的出错多项式是：
Ercrc=***1***1***1***1*
Ertail1=10000○cErcrc (here sign ○c mean concatenation)
有2种论证漏检率的方法，用于不同的帧长度：
（1）如果数据域长于17位。那么我们可以在数据域任意地方划出一片连续17位的区，称为RCRC，然后用逆向算法，把Ertail1反算到RCRC（此方法在我的文章“看明白了CAN的错帧漏检，车厂就不能敷衍你了！”有简介），那么RCRC和Ertail1就是互相抵消的，每一种特定的Ertail1就有对应的一种RCRC，由RCRC和Ertail1构成的Er就是一个出错实例。因为Ertail1中的*有212种组合，而RCRC有217种组合，所以漏检率是2-5。
假设我们把RCRC放在数据域的d24~d8(17位)，反算的方法是：
○A取Ertail1=10000***1***1***1***1*的逆序
Ertail1R= *1***1***1***1***00001
○b将代表Er=0的Erd1~d7=0串在Ertail1R之后有
Ertail1R= *1***1***1***1***000010000000
○c取CRC17生成多项式G=110110100001011011的逆序GR
GR=110110100001011011（很巧有GR=G）
○d用GR对Ertail1R求CRC值得到RCRCR
○e对RCRCR求逆序得到RCRC。
（2）当无法在数据域开辟RCRC时，用计算机搜索的方法。例如在d3d2d1的各种可能的组合中试探是否有满足Ertail1的情况。图7是搜索到的部分实例，这些Er是CRC17的倍数，所以会造成错帧漏检。
对于数据域较长的情况，这两种方法的例子同时存在，漏检率需要叠加。经过一番修正（例如错发生在帧长特定位置的概率，填充位计数器为特定111、000的概率，重构的TxCRC满足原来帧CRC的概率、帧变长或缩短的情况，连续位流造成毛刺引起帧变长或缩短的概率等）之后可以得到Pun.G+F=2.23*10-7。这是相当大的，因为只有2个错（一次毛刺加一次位反转），在与前面相同的负载率=40%、qbad=0.001、ber=0.01下有：Pfailure,G+F~1.4*107*0.012*0.001*2.23*10-7=3.1*10-7/h
这是100倍于分配给通信的容许值Pfailure,key bit=1*10-9/h。
图7 搜索到的毛刺移位引起漏检的例子
总结上述3种漏检情况，ISO CAN FD的漏检率相当大，它造成的失效率百倍于分配给通信的失效率，所以ISO CAN FD依然达不到功能安全的要求。
我在“看明白了CAN的错帧漏检，车厂就不能敷衍你了！”中已提到了错帧漏检对用户安全与舒适度的影响，这里再多说几句。
错帧漏检造成系统内数据的不一致，因为现代的车控系统是多个执行器协调动作的，信息需要共享。而很多错是局部错，它漏检了没报错，就会破坏动作的协调性。这种动作失调会使车有未预计的运动。
在应用层加防范就需要3中选2的措施（重传3次），这会使总线负载需求大为增加，即使只对安全有关的帧传送3次，把CAN FD 增加的带宽吃掉很大部分。
如果不在应用层加措施，要说车控系统达到功能安全ASIL C、ASIL D，那是自欺欺人了。如果你现在去问你的芯片供应商，它们的销售工程师的回答恐怕很难满足你的要求，但你需要的话就应该向他们提改进的要求，只要做，这种改进总是可能的。