看明白了CAN的錯幀漏檢,車廠就不能敷衍你了!

錯幀漏檢是指幀內發生了錯誤但是沒有被協議的所有檢錯機制查出來,這樣的幀就被接收節點收下,會引起應用使用錯誤數據,導致功能性錯誤或失效。

CAN的主要查錯機制是CRC檢驗,在CAN 中CRC校驗失效的2個原因是:

1.由於填充位規則的非對稱執行,收發幀的有效數據位產生了錯位,在進行CRC計算時相當於引入了大量的錯,錯的數目超過了CAN的CRC的檢驗能力(HD=6),造成CAN的錯幀漏檢率很高。

2.CAN的CRC多項式支持的數據字(word code)的長度不夠,只有112位,不能把可能的填充位都包括進去,例如CAN擴展幀的8字節數據的data word 最小長度爲39+64=103,最多可以有103/4=25個填充位,data word多達128位,所以不得不把填充位剔除在外,無法加以改進。

我小時候有很多節日,五月一日是勞動節,六月一日是兒童節,七月一日是共產黨的生日,八月一日是共產黨軍隊的生日,十月一日是共產黨中國的生日,還有元旦和春節,因爲我父親是北方人,這些日子我就能喫到包子或者餃子。

圖1 發生填充位機制不對稱執行的情況

圖1(A)中第3位傳送中出了錯,發送節點在第5位見到5個連續相同位時添加了填充位,但是接收節點在第5位處沒有見到5個連續相同位,所以它認爲這裏不應有填充位,它把發送節點添加的填充位作爲信息位收下。圖1(B)中也是第3位發生了傳送錯,發送節點沒有添加填充位,而接收節點由於第3位的錯而見到5個連續相同位,所以它把發送的第6位作爲填充位刪去了。

於是,在有填充位不對稱執行時便有發送節點計算CRC時的位流與接收節點計算CRC的位流的錯位。

填充位不對稱執行時有二種幀結束的可能:

1.CRC計算結束時沒有對齊,此時因爲CRC錯或其它格式檢查而發現錯/或者漏檢;

2.CRC計算結束時是對齊的,此時不會受到其它格式檢查影響,但此時因爲CRC計算時位流的錯位而造成漏檢,這是影響CAN錯幀漏檢率高的主要因素,因爲只要發生2個填充位不對稱執行時錯就可以形成對齊而錯位的情形。

我小時候有很多節日,五月一日是勞動節,六月一日是兒童節,七月一日是共產黨的生日,八月一日是共產黨軍隊的生日,十月一日是共產黨中國的生日,還有元旦和春節,因爲我父親是北方人,這些日子我就能喫到包子或者餃子。

CRC檢驗的方法是把數據字的位流除以生成多項式,其餘數便是CRC校驗和。在發送方Tx(x)=Ut(x)*g(x)*x15+Tcrc(x),在接收方Rx(x)=Ur(x)*g(x)*x15 +Rcrc(x)。當Rcrc(x)=Tcrc(x)時CRC檢驗就通過了。

當發生傳送錯時可以將Rx(x)表示爲Rx(x)=Tx(x)+Ex(x)。那麼只要Ex(x)=U*g(x),就會有Rcrc(x)=Tcrc(x),即發生漏檢錯誤,所以只要找出填充位不對稱執行時滿足Ex(x)=U*g(x)的概率,便可以確定錯幀漏檢率。

圖2 CAN最短的漏檢代碼片斷共23位

 圖2是重構出的一個錯幀漏檢代碼的片斷。最高部分是滿足漏檢的一種Ex,它被下面用來重構出Tx。具體U的選擇方法不在本文中敘述。這個例子中,本來只有發生在第4、21位的2個位錯(中間例),由於填充位的不對稱執行,變爲CRC計算中Ex有10個錯(>HD=6)的漏檢錯。漏檢共4種狀況(圖中的2種把1/0互換又有2種)。所以此類片斷在所有23位的片斷中佔2-21=4.76*10-7。此片斷在幀CRC域前面的103位中可處於任何位置,即可能發生的片斷有103-23=80處,所以一幀的漏檢片斷出現概率爲P1=80*4.76*10-7=3.81*10-5。2個錯出現在片斷特定位置的概率爲P2=1/103/102*2=1.9*10-4。漏檢錯率爲Pun=P1*P2 =7.25*10-9,僅這一種片斷就200倍大於CAN聲稱的Pun=4.7*10-11。

填充位不對稱執行時造成錯幀漏檢的情況是Bosch自己已經發現了的。(參見J. Unruh, H.J. Mathony, K.H. Kaiser: "Error Detection Analysis of Automotive Communication Protocols". SAE Int. Congress, No. 900699, Detroit, USA, 1990.)。但是他們沒有找到正確的計算方法,把造成錯幀漏檢代碼的片斷取長了,丟失了錯幀漏檢率的主要貢獻者。 

因爲沒有從根本機理上進行分析,所以就導致歸納上的錯誤。錯幀漏檢代碼的片斷在該文中用critical sequence(CS)表示。從上面截圖上可以見到長度的範圍爲30~80bit。這一限定就把許多短的CS排除在外了,例如長度23~29的CS是非常主要的錯幀漏檢實例的貢獻者。CS的長度越短,貢獻越大,這有兩方面的原因,一是特定CS實例在L長的所有可能位流中佔的比率是與長度有關的,一個23位CS實例佔的比率是2-23,而一個30位實例佔的比率是2-30,也就是說,一個23位長度CS實例對漏檢的貢獻是一個30位實例CS對漏檢的貢獻的128倍;其次,簡化分析時只須考慮CAN的數據域和CRC域,這裏沒有其他的格式檢驗。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的constk,但由於Estuff(L)的低估,造成即使在CS長度爲30~80時Bocsh的漏檢率也有很大低估。

錯幀漏檢有什麼後果?

理論上講,漏檢的錯幀可以使數據變大或變小、邏輯值變反。直到現在我們還經常聽到汽車變速箱的各種投訴,其中有一些是可以用CAN錯幀漏檢來解釋的。

 

上圖可見到跳檔的投訴,當錯誤的數據例如油門踏板的位置傳到變速箱時,便有可能跳檔,而且服務無法解決此類問題。

網上見到的噪聲、抖動、頓挫的投訴屢見不鮮,而廠家的迴應往往是含糊其詞、矇混過關。

但是由於錯幀漏檢本身是無法檢測出的(如果可檢測出就可以設計出不漏檢的規則),所以也不會有出錯代碼保存,發生漏檢事件是不會留下證據的,這造成了“沒有留下出錯碼就沒有發生CAN錯幀漏檢“抗辯不成立的理由。

但是CAN漏檢是完全可以說明出現故障的因果關係的。例如2013年大衆雙離合器召回事件中與失去動力故障不同的是有更多的抖動、異響、頓挫的投訴,他們均未被細究,但又是可以用CAN錯幀漏檢來分析的。爲此我們要先看DSG的特性,簡單地說,DSG控制器通過兩個離合器來選擇所需要的齒輪齧合對,當一對齒輪組在工作時,另外一對齒輪已經齧合好,所以換檔只是鬆開一個離合器+合上另一個離合器,所需的時間很短。當然由於防止打齒,齧合過程有專門的同步器實現,因爲車輪帶着車廂慣性大,發動機側慣性小,同步器在升降檔時需要的時間是不同的,特別是降檔時要求發動機側的齒輪要稍加速纔行,所以還有自動給發動機加油的命令。Direct-Shift Gearbox - Wikipedia, the free encyclopedia上提到DSG升檔的時間可達到8ms,降檔時爲600ms。另外,DSG有跳檔的功能,當油門踏板踩地板油(kick-down function)時可根據當時車速、油門開度自動選合適的檔位。注意這一句:This kick-down may be engaged by any increased accelerator pedal opening,跳檔可以因任何踏板開度的增加引起。

DSG是根據車速、油門開度及變化來決定檔位的,油門開度的信號是通過CAN總線送到DSG控制器的,而在干擾下CAN有錯幀漏檢的可能性,假定油門開度爲50%,但是在干擾下,這個信號被DSG讀爲80%,DSG自然會認爲駕駛員要加速(實際上駕駛員什麼也沒做),便很快升檔,甚至跳檔,假定發動機傳給DSG信號的週期是20ms,那麼就可以跳2~3檔。假定下一20ms到達的刷新信號是正確的,仍是50%,那麼DSG認爲應回到原檔位,就執行降檔,由於降檔時間長,需要1200~1800ms,在這一段時間裏發動機的功率實際沒變化,而檔位經歷了升檔,當然就會使車速下降,使人感到有1~2秒的失去動力,急促升降檔就會引起噪聲、抖動、頓挫的體驗。

從這樣的例子可以看到錯幀漏檢不但對功能安全有極大的影響,而且對用戶體驗有極大的影響,這個影響涉及的用戶數要遠遠大於發生安全事故的用戶數,而且錯幀漏檢是無法設計出故障診斷方法的,車廠用無故障診斷碼可以糊弄用戶,但是無法改變用戶的口碑,改變這一局面的唯一辦法是不發生錯幀漏檢:或者改進電磁環境,或者改進CAN的錯幀漏檢率。設計時的電磁環鏡在應用中惡化了,這是不可控的,但改進CAN的錯幀漏檢率是可以做到的。


1.虛擬圓桌會議Part 1——嵌入式系統信息安全

2.華爲5G的祕密原來掌握在一個土耳其人的手中?!

3.半導體最新排名出爐,英偉達實現50%增長!

4.【MCU】一種"靈活且省資源"的IAP升級方案

5.RISC-V爲什麼會成爲熱點?

6.適合開發人員看的鴻蒙OS介紹~

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章