CAN協(xié)議的錯幀漏檢率改進

表1 錯誤序列尾部形式和漏錯多項式Ut(x)

2.4 Ut的擴充形成Ec頭部

在Ut中增加高于x5的項成為U，它不會影響Ec尾部的形式，但是它會增加錯誤序列的長度。由此U生成的Ec與Tx序列也將被漏檢。Tx在數(shù)據(jù)域內(nèi)不同位置的集合就構成了所有漏檢實例。發(fā)生第一次bit錯后并不立即開始TxRx位序的錯位，要等到有填充位發(fā)生時才會有位序錯。

2.5 構造出錯實例Tx

以Ut= x4+x3+1為例，對應尾部第1位處出了傳送錯，Ut加上x6后有U=x6+x4+x3+1，計算得Ec=U×G=(1110，1111，0101，1010，0000，01)，整個錯誤序列的長度為22位。該Ec確定頭部出第1個傳送錯的位置是6，假定為漏刪填充位錯，則在尾部應取誤刪信息位錯。假定在頭部出現(xiàn)的是Tx送100000，在第6位處Rx收到的是1，出了第1個bit錯，第7位Rx得到填充位1而未刪去，Tx第7位可由Ec及Rx求得為0，然后逐位反推，得到Tx發(fā)生漏檢錯的實例，如圖3所示。

圖3 構造的會出漏檢錯的Tx實例

這個例子中Tx序列的長度為27 bit。此種長度的Tx可以有227種，每一種都可能出錯，但重構出的這一種在特定位發(fā)生2個bit錯時會漏檢。這個Tx在別的位置發(fā)生bit錯時，將可以檢出錯，因此它是一個可能被漏檢的可疑實例。Tx頭部共有4種可能：Tx=10000(0)，10000(1)，01111(1)，01111(0)。(括號中的位在傳送中出了錯)。因此這幾種可疑實例占可能Tx的2-25?？梢蒚x在64 bit的數(shù)據(jù)域中會有64-27+1=38種位置。對頭部Tx=100000和100001，其高4位可以與CAN的DLC重合，對Tx=011111和011110，其最高位可和DLC0重合，因此此種Tx實例在8字節(jié)數(shù)據(jù)域的幀中出現(xiàn)的可能數(shù)目是39種。于是這一種漏檢實例有概率39×2-25=1.16×10-6。當誤碼率為0.02時，64 bit內(nèi)出2個bit錯的概率是(1-0.02)62×0.022=1.14×10-4，由這一個實例引起的CAN錯幀漏檢率就是1.32×10-10，已經(jīng)大于Bosch的指標?？紤]U中可增加的xk中k可由6一直到43，各種xk項有237=1.37×1011種組合，需要對每一種U進行計算，雖然它們的漏檢實例概率不同，其增量還是很大的。還要考慮不同Ut的貢獻，可見CAN錯幀漏檢率是非常大的。

2.6 計算結果

根據(jù)上述分析編制了在MATLAB中運行的程序pcan.m，在MATLAB中設置format long e格式，運行pcan(ber)即可得到不同誤碼率ber時的結果，如表2所列。

表2 典型的CAN漏檢錯幀概率

表中ber=0.02的錯幀漏檢率為1.882×10-8，而參考文獻[2]在同樣誤碼率下給出的漏檢率是：低速系統(tǒng)4.7×10-14和高速系統(tǒng)8.5×10-14?？梢姴顒e極大。對500 kbps的系統(tǒng)，假定總線利用率為40%，幀長為135 bit，那么按這個結果，CAN系統(tǒng)將在9.96小時出1個漏檢錯幀。

3 改善錯幀漏檢率的方法

在本文的分析中可以見到，由于填充位規(guī)則需要收發(fā)同步執(zhí)行，不同步時會極大干擾CRC校驗，例如CRC校驗本來可以將所有奇數(shù)個錯檢測出的，小于5位的多bit錯是可以檢測出的，但只要有了成對的填充位錯位，增加的奇數(shù)個錯也可以是漏檢的，增加的多bit錯也可以是漏檢的，如圖4所示。

圖4 有多位錯的例子

漏檢錯的根源是CAN的CRC在執(zhí)行填充位規(guī)則前生成，最根本的解決辦法是像參考文獻[3]指出的那樣，要把CRC校驗放在執(zhí)行填充位規(guī)則之后。但是這樣作就會根本修改CAN協(xié)議，在已經(jīng)大量應用的情況下如何作到的改進前后的兼容性是個艱難的課題。作為局部的改正，參考文獻[3]建議加附加的檢驗。在數(shù)據(jù)域添加一個新的不同的CRC檢驗時，根據(jù)本文的分析方法，當誤差多項式Ec是這個新CRC和CAN的CRC的公倍數(shù)時，仍然可以構造出漏檢的實例，并計算出新條件下的漏檢錯幀概率。例如采用8位的DARC8生成多項式x8+x5+x4+x3+1，它不含x+1因子，所以與CAN生成多項式的最小公倍數(shù)構成的漏錯多項式Ec將有24階，此時如2.5節(jié)所分析的那樣，總幀數(shù)將增大28倍，而漏檢幀數(shù)不變，漏檢率就減少28。但是這種方法的缺點是不能實現(xiàn)自動報錯，無法使節(jié)點間取得數(shù)據(jù)的一致性：有局部錯的節(jié)點在添加上述措施后在收完幀后才能發(fā)現(xiàn)錯，已無法要其他節(jié)點也丟棄該幀并要求自動重發(fā)。

本文建議采用7b/8b的編碼辦法，犧牲一些帶寬，換取錯幀漏檢的避免。具體做法是在8b代碼中選取不會發(fā)生填充位條件的部分，供原來7b編碼使用。

其他的編碼辦法也是可行的，類似7b/8b的還有6b/7b、5b/6b、4b/5b，它們的區(qū)別是軟件實現(xiàn)時的復雜程度以及開銷占用數(shù)據(jù)域的多少，當用7b/8b時CAN可以每幀送7字節(jié)數(shù)據(jù)，而用4b/5b時每幀只能送6字節(jié)數(shù)據(jù)。

在附加數(shù)據(jù)域的軟件補丁后，若發(fā)生在ID域和CRC域的填充位規(guī)則只有單邊執(zhí)行情況時，夾在它們中間的控制域就會左移或右移，幀長就會變大或變小。幀長的單位是1字節(jié)，它會使CRC域移入EOF域，CRC最多連續(xù)5位相同，就破壞了EOF的格式，或者EOF域移入CRC域，EOF的連續(xù)8位破壞了CRC的填充格式，所以此時單邊執(zhí)行填充位規(guī)則的錯的后果是能被發(fā)現(xiàn)的。也就是說加軟件補丁后不再有錯幀漏檢可能。

如果可疑Tx只發(fā)生在ID域，由于Tx有一個最短長度，相應于Ec,t= x3+x+1，這個長度是3+15+6=24位，所以對CAN2.0B的29位ID可能會出錯，那么產(chǎn)生的后果就是接收節(jié)點收到的ID有錯，這是一種假冒錯(Masquerade)。在參考文獻[6]中提到了CAN防止假冒錯的方法，實際上將ID分為二部分，一部分是一個附加的CRC，只要這個CRC生成多項式與CAN的不同，就不會產(chǎn)生假冒ID通過接收濾的可能。