CAN 總線Babbling Idiot 問題研究

楊 康，張鳳登

（上海理工大學(xué)光電信息與計算機工程學(xué)院，上海 200093）

0 引言

目前大部分汽車電子控制單元間的底層通信協(xié)議以CAN 總線為主。CAN 總線本身沒有處理Babbling Idiot 故障的機制［1］，一旦通信節(jié)點發(fā)生Babbling Idiot 故障就會影響節(jié)點間通信。汽車對實時性和安全性要求很高，是不允許在通信期間發(fā)生Babbling Idiot 故障的，所以研究CAN 總線Babbling Idiot 故障并提出有效的解決方案具有非常重要的實際意義。

目前關(guān)于Babbling Idiot 故障的相關(guān)研究與文獻數(shù)量較少。Bosch 標(biāo)準(zhǔn)規(guī)定可以利用CAN 本身的錯誤約束機制在一定程度上緩解該故障。當(dāng)出現(xiàn)錯誤時，CAN 節(jié)點就發(fā)送一次出錯幀，錯誤計數(shù)器加8，節(jié)點重復(fù)發(fā)送出錯幀并持續(xù)累加計數(shù)器直至總線報文傳輸正確。每當(dāng)完成一次正確報文接收與發(fā)送，CAN 節(jié)點的計數(shù)器就會減1。若一直發(fā)送錯誤幀，節(jié)點計數(shù)器不斷累加8 直至超過255，該節(jié)點就會進入Bus Off（離線）狀態(tài)［2］，脫離總線。CAN 總線本身的糾錯機制使Babbling Idoit 故障只持續(xù)一段時間并終止，但對于汽車這種高安全行業(yè)來說還不夠迅速。Broster 等［3］提出了基于事件觸發(fā)的CAN 總線監(jiān)守模型，該模型靈活度較高，開銷小，采用同步時鐘，能防止故障節(jié)點靜默后導(dǎo)致的總線時鐘不同步；Buja［4］提出用一個總線監(jiān)守控制CAN 通信控制器向驅(qū)動器進行輸出的方法，在發(fā)消息前由主機的應(yīng)用程序向總線發(fā)申請，該消息在總線空閑時競爭發(fā)送。總線監(jiān)守到某個時間后禁止通信控制器向驅(qū)動器進行輸出，切換下個消息進行競爭發(fā)送，由此給每條消息提供一個屬于自己的時間段進行發(fā)送?？偩€在設(shè)定的時間范圍內(nèi)持續(xù)監(jiān)聽數(shù)據(jù)幀，判斷是否發(fā)生Babbling Idiot 故障，然后告知相關(guān)節(jié)點并禁止其發(fā)送，所以省去了節(jié)點消息發(fā)送的請求；Vahid 等［5］針對Flexray 提出總線監(jiān)守方案，將Buja 在CAN 總線的方法移植到Flexray 總線中；付道俊等［6］和趙琳等［7］針對CAN 總線提出了冗余的硬件方法，保證了總線網(wǎng)絡(luò)的負載均衡；周康等［8］針對CAN 總線中存在的各種軟硬件問題設(shè)計了迅速檢測與定位的模塊。

1 Babbling Idiot 故障定義

CAN 總線若在某一空閑時間有多個節(jié)點同時發(fā)送報文，根據(jù)CAN 總線的CSMA/CA 媒體訪問機制進行仲裁，通過對每個報文的標(biāo)識符判斷對應(yīng)的優(yōu)先級［9］，優(yōu)先級高的進行發(fā)送，優(yōu)先級低的退出并進入等待隊列。在發(fā)送結(jié)束后，若高優(yōu)先級報文的發(fā)送節(jié)點因為軟/硬件問題或干擾并沒有與總線斷開連接，該錯誤節(jié)點會不停地發(fā)送錯誤幀至總線。由于幀格式均正確，所以CAN 總線只能默許錯誤幀不停發(fā)送而無法進行自我修正。根據(jù)CAN 總線的仲裁規(guī)則，任何優(yōu)先級比它低的報文將被持續(xù)堵塞直至故障解除。這種情況對于汽車這種安全性要求很高的行業(yè)將會導(dǎo)致災(zāi)難性后果。因此，無論何種原因?qū)е碌腂abbling Id?diot 都必須迅速得到解決。

1.1 軟件導(dǎo)致的Babbling Idiot 故障

當(dāng)總線上發(fā)生軟件Babbling Idiot 故障時，通常會影響某個節(jié)點發(fā)送低優(yōu)先級消息。在幀格式等協(xié)議上節(jié)點傳輸?shù)膱笪臒o異常，但CAN 通信幀會出現(xiàn)無意義數(shù)據(jù)場情況。這種錯誤有時是由于技術(shù)人員引起的，如軟件編寫的BUG 或者是網(wǎng)絡(luò)攻擊、病毒軟件等。不論哪種原因引發(fā)的Babbling Idiot 故障，使用總線監(jiān)守方法都能有效解決該問題。在CAN 總線上，當(dāng)一個通信節(jié)點與其他節(jié)點信息交互時，可以使用節(jié)點本身故障靜默的方式處理正在發(fā)生的Babbling Idiot 故障。為阻止錯誤節(jié)點蔓延到總線監(jiān)守上，需要將總線監(jiān)守模塊與總線物理模塊分離并進行電磁屏蔽，給它提供一個獨立的電源與晶振。

在Robert 等［10］的時間觸發(fā)（Time-Triggered）協(xié)議里，只有節(jié)點處于自身通信的時間段才能訪問總線，此時總線監(jiān)守的工作量相對于事件觸發(fā)協(xié)議是很小的。如在安全性要求較低的情況下，若發(fā)生Babbling Idiot 故障，只需要很簡單的操作就可以使節(jié)點停止發(fā)送接收消息。Robert 在TTP/C 協(xié)議中提出總線監(jiān)守的目的是一個狀態(tài)機，建立一個邏輯設(shè)備和4 根連接到主控制器的通信線，還有一根連接到收發(fā)器的通信線。

但是靜默故障節(jié)點這個方法在事件觸發(fā)（Event -trig?gering）協(xié)議中實施起來不太容易。節(jié)點空閑的時間訪問總線和帶來沖突的低優(yōu)先級消息會造成傳輸延遲，任何總線監(jiān)守方法都必須考慮到最壞的消息傳輸時間。一種定義最小抑制時間和安排通信任務(wù)的方法如下：除了在抑制時間，該節(jié)點有權(quán)在任何時間段訪問總線，其基本原理是當(dāng)某個節(jié)點發(fā)生Babbling Idiot 故障時，由于該節(jié)點處于抑制時間而不能和其他節(jié)點通信，所以接收不到Babbling Idiot錯誤幀，這種策略已經(jīng)應(yīng)用到CAN 中?？偩€監(jiān)守是建立通信控制器和收發(fā)器作為一個輔助節(jié)點來保護被監(jiān)守節(jié)點，它只能讀取總線上的報文但不能進行任何更改操作。其工作方式是檢查報文的標(biāo)識符，當(dāng)總線監(jiān)守檢測到被保護的節(jié)點傳輸報文過于頻繁時就斷開節(jié)點收發(fā)器。這種解決方案非常有效，但有兩個缺點：①總線監(jiān)守的復(fù)雜性，因為它有嵌入式網(wǎng)絡(luò)協(xié)議，因此布置該監(jiān)守節(jié)點較為復(fù)雜；②故障檢測功能不完善，無法檢測Babbling Idiot 節(jié)點傳輸?shù)南?biāo)識符為不正確或錯誤幀消息情況。Buja 等［11］提出了該缺點的解決方案：將輸出節(jié)點與總線監(jiān)守的通信控制器連接，而不是與總線連接。

1.2 硬件導(dǎo)致的Babbling Idiot 故障

使用總線冗余解決硬件Babbling Idiot 故障是較為有效的方法［12］。一個CAN 總線網(wǎng)絡(luò)由兩個信道構(gòu)成，每個信道都有各自的收發(fā)器，使用兩個信道發(fā)送相同的數(shù)據(jù)。該方法的兩個通道物理分離，電氣絕緣，兩個收發(fā)器也相互分離。當(dāng)其中一個通道發(fā)生Babbling Idiot 故障時不會影響另一個正常通道。通過這種方式使硬件的Babbling Idiot 故障節(jié)點不阻塞CAN總線網(wǎng)絡(luò)和節(jié)點，即節(jié)點表現(xiàn)為故障可操作。

時間觸發(fā)協(xié)議如TTP/C、FlexRay 和SafeBus 都提供了總線冗余［13］（前兩個用于開發(fā)線控駕駛應(yīng)用程序，后一個用于航空航天應(yīng)用程序）；TTP/C 與FlexRay 是兩通道冗余，SafeBus 是四通道冗余。基于以上協(xié)議的總線利用冗余功能傳輸幀，達到覆蓋該Babbling Idiot 故障的目的。然而，簡單的總線冗余并不能有效解決基于事件觸發(fā)協(xié)議中的Babbling Idiot 故障，如CAN 總線傳輸?shù)膱笪木哂械牟淮_定性。事實上，比較兩個通道的數(shù)據(jù)流并沒有意義［14］。因為總線訪問受仲裁位裁決，不可能保證兩個通道消息的順序永遠是相同的。因此，要解決事件觸發(fā)類總線硬件Bab?bling Idiot 故障，不能簡單使用傳統(tǒng)的總線冗余。

2 Babbling Idiot 故障解決策略

2.1 FlexCAN 模型及總線監(jiān)守

FlexCAN 模型通過提高CAN 總線協(xié)議的安全性與可靠性滿足安全需求，采用應(yīng)用軟件修改，成本不高易于實現(xiàn)。使用商用市場常用的硬件部件，對硬件唯一的要求是主控制器可以驅(qū)動兩個或多個獨立的通信控制器。

FlexCAN 依賴于復(fù)制的節(jié)點（副本）和通道。作為一個整體，副本構(gòu)成一個容錯單元（FTU）。容錯單元的副本之間有主節(jié)點、輔助節(jié)點層次關(guān)系。在一個運行系統(tǒng)中，只有主節(jié)點有權(quán)發(fā)送消息，其他副本監(jiān)視其行為。如果次節(jié)點在預(yù)定時間間隔內(nèi)沒有在任何信道中接收到任何消息，則假定主節(jié)點失敗并開始作為主節(jié)點發(fā)送信息。如果副本（主副本除外）未通過任何復(fù)制通道接收到消息，則認為主節(jié)點沒有故障。通過這種方式可以輕松地支持總線復(fù)制，這種節(jié)點的層次結(jié)構(gòu)可以通過算法實現(xiàn)［15］。

除初始化階段外，當(dāng)容錯單元（FTU）中的節(jié)點相互發(fā)送和接收“組間信息”（特定于應(yīng)用程序的數(shù)據(jù)和其他信息，例如協(xié)議時間同步信息）時，所有FlexCAN 節(jié)點的通信時間相同，并且在周期內(nèi)不會重復(fù)發(fā)送消息的標(biāo)識符。Fl?exCAN 在開發(fā)控制中最重要的FTU 應(yīng)用類型有：傳感器FTU、控制器FTU 和執(zhí)行器FTU。傳感器FTU 是系統(tǒng)的輸入設(shè)備，它被配置為第一個軟件鏈路；第二個軟件鏈路是控制器FTU，它的任務(wù)是接收傳感器發(fā)送的信息，進行一些計算并傳輸結(jié)果；執(zhí)行器FTU 是系統(tǒng)的輸出設(shè)備，是軟件鏈中的第三個環(huán)節(jié)。它接收來自控制器FTU 的參考數(shù)據(jù)并執(zhí)行，向控制器FTU 發(fā)送反饋。FlexCAN 可以容忍單硬件的Babbling Idiot 故障，與信道或收發(fā)器引起的胡言亂語故障沒有區(qū)別。硬件Babbling Idiot 的故障被解碼成一系列錯誤幀，破壞了信道通信。假設(shè)硬件Babbling Idiot 故障是非傳播性且不影響復(fù)制的信道，則正確的通信可以繼續(xù)［16］。

總線監(jiān)視器是一個簡單的邏輯設(shè)備，連接到主控制器，如圖1 所示。通信控制器的輸出（Tx）和總線監(jiān)視器（BS）連接到或門。反過來，或門的輸出（Tx）連接到收發(fā)器的輸入端。

通信控制器和總線監(jiān)視器共同控制傳輸，在FlexCan架構(gòu)中，不考慮主輔節(jié)點的時間誤差；當(dāng)通信控制器傳輸消息時，總線管理器從啟用變?yōu)橐种苽鬏敚谶@種情況下，所有其他節(jié)點檢測到一個錯誤發(fā)生，如CRC 錯誤、填充錯誤或其他錯誤類型，就通過通信網(wǎng)絡(luò)傳輸錯誤幀［17］。

總線監(jiān)守通過兩根導(dǎo)線與主控制器連接：一個用于發(fā)送信號，從主控制器連接到總線監(jiān)守（TxReq），另一個反饋信號至CAN 控制器（BsFbk）?？偩€監(jiān)守還與CAN 控制器的輸出一起作為或門輸入，控制CAN 收發(fā)器工作，其工作方式是：主控制器在傳輸前需要向總線監(jiān)守發(fā)送傳輸請求，在一個給定的時間間隔后，總線監(jiān)守抑制或允許通信。TxReq 和BsFbk 物理連接到微控制器端口Port 的兩引腳，以兩變量的狀態(tài)組成Port 口的狀態(tài)變量，即Port=［BsFbk，TxReq］?？偩€監(jiān)守和主控制器使用獨立的時鐘，因為他們操作不需要同步。

總線監(jiān)守算法的工作狀態(tài)主要有4 種，如圖2 所示，通過Port 口賦值確定當(dāng)前的運行狀態(tài)。下文結(jié)合圖2 闡述該系統(tǒng)狀態(tài)機的工作原理。

狀態(tài)1：總線監(jiān)守抑制傳輸。主控制器沒有發(fā)送消息，這種情況下，Port=0，TxReq=0，BsFbk=0 和BsEn=1（值為1 是抑制功能，值為0 是通信使能）；

狀態(tài)2：主控制器通過設(shè)置TxReq=1，即Port=1，請求通信。如果inhibit_time 抑制時間已經(jīng)結(jié)束，通信使能，總線可以正常通信，即BsEn=0；

狀態(tài)3：總線監(jiān)守通信使能。通過BsEn 清0 和通過置位BsFbk，允許主控制器進行發(fā)送操作，此時Port=3，啟用主控制器傳輸消息；

狀態(tài)4：數(shù)據(jù)傳輸完成后，主控制器清除發(fā)送請求TxReq，此時Port=2，進入空閑狀態(tài)。

Fig.1 Implementation of bus supervisor圖1 總線監(jiān)守實現(xiàn)

Fig.2 Bus supervisor state machine圖2 總線監(jiān)守狀態(tài)機

2.2 CAN 總線標(biāo)識符可變策略

Can 總線標(biāo)識可變策略是將低優(yōu)先級節(jié)點通過提高優(yōu)先級的方法來發(fā)送消息，防止一直被高優(yōu)先級的報文阻塞。在發(fā)送消息之后，該節(jié)點優(yōu)先級會恢復(fù)。Can 總線標(biāo)識符可變方法如下：當(dāng)一個節(jié)點試圖訪問總線但由于其優(yōu)先級低而無法訪問時，其節(jié)點中的優(yōu)先級計數(shù)器將遞減，在該節(jié)點的阻塞過程中持續(xù)減少，直到節(jié)點可以訪問總線并恢復(fù)其優(yōu)先級。

選取5 級節(jié)點作為案例研究。節(jié)點優(yōu)先級A 最高、E 最低，依次降序排列，優(yōu)先級數(shù)值越大優(yōu)先級越低，如表1 所示。在第一個時隙里，A 和D 都有信息要發(fā)送，但在這個時隙訪問總線的是A，因為它的優(yōu)先級高。在下個時隙里無節(jié)點要發(fā)送報文，D 的報文在此時發(fā)送。同樣，在第三個時隙里，B、C、E 要發(fā)送報文，最后B 的報文被發(fā)送。E 節(jié)點在第三個時隙里要求訪問總線，然而由于它的優(yōu)先級低，不斷被高優(yōu)先級任務(wù)阻塞，導(dǎo)致節(jié)點E 在接下來的8 個時隙里不能成功訪問總線，如表2 所示。

Table 1 Priority level and number of examples表1 優(yōu)先級級別和編號例子

Table 2 Priority arbitration based on CAN bus表2 基于CAN 總線優(yōu)先級仲裁

如表3 所示，前兩個時隙相同，但在第三個時隙里C 和E 不能訪問總線，但是CAN 總線標(biāo)識符可增加這些節(jié)點的優(yōu)先級（減少他們的優(yōu)先級號碼），在下一個時隙里繼續(xù)判斷他們能否訪問總線。在第四個時隙里，節(jié)點E 的優(yōu)先級號碼為10-1=9，C 為6-1=5。在這個時隙中，C 的優(yōu)先級高，節(jié)點C 訪問總線，訪問完后節(jié)點C 的優(yōu)先級號碼還是之前的6。在第五個時隙里，節(jié)點E 的優(yōu)先級是10-2=8，節(jié)點A的優(yōu)先級是2，所以A 訪問總線。在第六個時隙里，B、D、E三個節(jié)點要求訪問總線，節(jié)點E 優(yōu)先級號碼是8-1=7，B 的優(yōu)先級高所以訪問總線。在第七個時隙里，節(jié)點E 優(yōu)先級號碼是8-2=6，D 為7，因此E 訪問總線。節(jié)點D 在CAN 總線第七個時隙標(biāo)識符與CAN 總線的第七個時隙標(biāo)識符相比，提早了4 個時隙。

Table 3 Variable bus priority arbitration based on CAN bus identifier表3 基于CAN 總線標(biāo)識符可變總線優(yōu)先級仲裁

3 實驗驗證及結(jié)果分析

3.1 CAN 總線標(biāo)識符可變策略驗證

為了驗證該策略的可行性和可靠性，本文采用3 個案例進行對比分析和驗證，每組5 個節(jié)點分別命名為A、B、C、D 和E，每個節(jié)點的功能含義見表1。第一種情況見表2 和表3，第二種情況見表4 和表5，第三種情況見表6 和表7。

CAN 總線與CAN 總線標(biāo)識符的系統(tǒng)延遲時間比較結(jié)果見表8。從表中可以看出，采用可變CAN 總線標(biāo)識符策略后的最壞情況是第一種情況。變量CAN 總線標(biāo)識符和CAN 總線上每個節(jié)點的延遲時間相等，另外兩種情況都比CAN 總線的系統(tǒng)延遲時間短，因此該策略是可靠的。

Table 4 The second case is based on CAN bus priority arbitration表4 第二種情況基于CAN 總線優(yōu)先級仲裁

Table 5 The second case is based on CAN bus identifier variable priority arbitration表5 第二種情況基于CAN 總線標(biāo)識符可變優(yōu)先級仲裁

Table 6 The third case is based on CAN bus priority arbitration表6 第三種情況基于CAN 總線優(yōu)先級仲裁

Table 7 The third case based on CAN bus identifier variable priority arbitration表7 第三種情況基于CAN 總線標(biāo)識符可變優(yōu)先級仲裁

Table 8 Comparison results of system delay time between CAN and CAN bus with variable identifier表8 CAN 和CAN 總線標(biāo)識符可變兩者的系統(tǒng)延遲時間比較結(jié)果

CAN 與CAN 總線標(biāo)識符變量性能比較結(jié)果如表9 所示，表9 說明采用CAN 總線標(biāo)識符變量策略的所有總線系統(tǒng)在3 種情況下延時時間分別縮短了9.3%，12%，21.5%。

Table 9 Performance comparison results of CAN and CAN bus identifier variable表9 CAN 和CAN 總線標(biāo)識符可變兩者的性能比較結(jié)果

3.2 實測與評估

通過實驗評估總線監(jiān)守功能。使磁懸浮系統(tǒng)運作后，控制小球不斷調(diào)整位置，通過vector 的工具CANoe 持續(xù)進行報文收發(fā)。在系統(tǒng)工作進入穩(wěn)定狀態(tài)后，通過編寫CA?PL 腳本讓最高優(yōu)先級的CAN 報文在某一節(jié)點不間斷發(fā)送，使系統(tǒng)進入Babbling Idiot 狀態(tài)?？吹絋race 窗口出現(xiàn)RxErr幀后監(jiān)測到Babbling Idiot 故障。在沒有總線監(jiān)守功能的系統(tǒng)中，發(fā)生此類故障后，CAN 總線不能有效自主地解決這個故障，導(dǎo)致總線通信一直被阻塞。在引入總線監(jiān)守模型后，再次重復(fù)制造Babbling Idiot 故障，在總線監(jiān)守模塊將故障節(jié)點與總線斷開后系統(tǒng)便恢復(fù)了正常通信。圖3 是在CANoe 中監(jiān)測到正常運行情況下磁懸浮小球的幀數(shù)據(jù)信息，可以看到小球位置信息幀、PID 相關(guān)參數(shù)幀以及磁懸浮設(shè)備相關(guān)參數(shù)幀。

采用穩(wěn)態(tài)誤差來評估系統(tǒng)性能穩(wěn)定情況。在CAN 總線的Babbling Idiot 故障解決后，用系統(tǒng)的穩(wěn)態(tài)性能作為該系統(tǒng)評價指標(biāo)。圖4 為消除故障后系統(tǒng)穩(wěn)態(tài)時的曲線，該曲線的誤差值在［-1.5%，1.5%］之間，因此系統(tǒng)是較為穩(wěn)定的。

Fig.3 Frame data information without Babbling Idiot fault圖3 無Babbling Idiot 故障時幀數(shù)據(jù)信息

Fig.4 Steady state curve of magnetic levitation ball control system圖4 磁懸浮小球控制系統(tǒng)穩(wěn)態(tài)曲線

4 結(jié)語

本文針對汽車常用的CAN 總線存在的Babbling Idiot故障進行分析，對軟件因素進行研究，提出總線監(jiān)守方法檢測通信節(jié)點，避免發(fā)生總線阻塞導(dǎo)致的嚴(yán)重后果。另外還提出了可變標(biāo)識符方法，通過使其自減，使得在總線通信擁堵時在一定程度上緩解擁堵，改善總線通信能力。但是本文對于硬件原因產(chǎn)生的Babbling Idiot 故障未作深入研究，僅使用了雙冗余方法采用兩個CAN 控制器，未討論如何保證總線監(jiān)守模型一直正常運行，保證自身不發(fā)生故障。對于影響監(jiān)守功能甚至主動造成節(jié)點靜默的問題還有待進一步研究。