CAN協(xié)議的錯幀漏檢率改進
表1 錯誤序列尾部形式和漏錯多項式Ut(x)
2.4 Ut的擴充形成Ec頭部
在Ut中增加高于x5的項成為U,它不會影響Ec尾部的形式,但是它會增加錯誤序列的長度。由此U生成的Ec與Tx序列也將被漏檢。Tx在數(shù)據(jù)域內(nèi)不同位置的集合就構(gòu)成了所有漏檢實例。發(fā)生第一次bit錯后并不立即開始TxRx位序的錯位,要等到有填充位發(fā)生時才會有位序錯。
2.5 構(gòu)造出錯實例Tx
以Ut= x4+x3+1為例,對應(yīng)尾部第1位處出了傳送錯,Ut加上x6后有U=x6+x4+x3+1,計算得Ec=U×G=(1110,1111,0101,1010,0000,01),整個錯誤序列的長度為22位。該Ec確定頭部出第1個傳送錯的位置是6,假定為漏刪填充位錯,則在尾部應(yīng)取誤刪信息位錯。假定在頭部出現(xiàn)的是Tx送100000,在第6位處Rx收到的是1,出了第1個bit錯,第7位Rx得到填充位1而未刪去,Tx第7位可由Ec及Rx求得為0,然后逐位反推,得到Tx發(fā)生漏檢錯的實例,如圖3所示。
圖3 構(gòu)造的會出漏檢錯的Tx實例
這個例子中Tx序列的長度為27 bit。此種長度的Tx可以有227種,每一種都可能出錯,但重構(gòu)出的這一種在特定位發(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 計算結(jié)果
根據(jù)上述分析編制了在MATLAB中運行的程序pcan.m,在MATLAB中設(shè)置format long e格式,運行pcan(ber)即可得到不同誤碼率ber時的結(jié)果,如表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,那么按這個結(jié)果,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)大量應(yīng)用的情況下如何作到的改進前后的兼容性是個艱難的課題。作為局部的改正,參考文獻[3]建議加附加的檢驗。在數(shù)據(jù)域添加一個新的不同的CRC檢驗時,根據(jù)本文的分析方法,當誤差多項式Ec是這個新CRC和CAN的CRC的公倍數(shù)時,仍然可以構(gòu)造出漏檢的實例,并計算出新條件下的漏檢錯幀概率。例如采用8位的DARC8生成多項式x8+x5+x4+x3+1,它不含x+1因子,所以與CAN生成多項式的最小公倍數(shù)構(gòu)成的漏錯多項式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)時的復(fù)雜程度以及開銷占用數(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有一個最短長度,相應(yīng)于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通過接收濾的可能。
評論