CAN 總線Babbling Idiot 問題研究

楊 康，張鳳登

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

0 引言

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

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

1 Babbling Idiot 故障定義

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

1.1 軟件導致的Babbling Idiot 故障

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

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

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

1.2 硬件導致的Babbling Idiot 故障

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

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

2 Babbling Idiot 故障解決策略

2.1 FlexCAN 模型及總線監守

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

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

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

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

通信控制器和總線監視器共同控制傳輸，在FlexCan架構中，不考慮主輔節點的時間誤差；當通信控制器傳輸消息時，總線管理器從啟用變為抑制傳輸，在這種情況下，所有其他節點檢測到一個錯誤發生，如CRC 錯誤、填充錯誤或其他錯誤類型，就通過通信網絡傳輸錯誤幀［17］。

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

總線監守算法的工作狀態主要有4 種，如圖2 所示，通過Port 口賦值確定當前的運行狀態。下文結合圖2 闡述該系統狀態機的工作原理。

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

狀態2：主控制器通過設置TxReq=1，即Port=1，請求通信。如果inhibit_time 抑制時間已經結束，通信使能，總線可以正常通信，即BsEn=0；

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

狀態4：數據傳輸完成后，主控制器清除發送請求TxReq，此時Port=2，進入空閑狀態。

Fig.1 Implementation of bus supervisor圖1 總線監守實現

Fig.2 Bus supervisor state machine圖2 總線監守狀態機

2.2 CAN 總線標識符可變策略

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

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

Table 1 Priority level and number of examples表1 優先級級別和編號例子

Table 2 Priority arbitration based on CAN bus表2 基于CAN 總線優先級仲裁

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

Table 3 Variable bus priority arbitration based on CAN bus identifier表3 基于CAN 總線標識符可變總線優先級仲裁

3 實驗驗證及結果分析

3.1 CAN 總線標識符可變策略驗證

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

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

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

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

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

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

Table 8 Comparison results of system delay time between CAN and CAN bus with variable identifier表8 CAN 和CAN 總線標識符可變兩者的系統延遲時間比較結果

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

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

3.2 實測與評估

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

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

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

Fig.4 Steady state curve of magnetic levitation ball control system圖4 磁懸浮小球控制系統穩態曲線

4 結語

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