楊 康，張鳳登

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

0 引言

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

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

1 Babbling Idiot 故障定義

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

1.1 軟件導致的Babbling Idiot 故障

當總線上發(fā)生軟件Babbling Idiot 故障時，通常會影響某個節(jié)點發(fā)送低優(yōu)先級消息。在幀格式等協(xié)議上節(jié)點傳輸的報文無異常，但CAN 通信幀會出現(xiàn)無意義數據場情況。這種錯誤有時是由于技術人員引起的，如軟件編寫的BUG 或者是網絡攻擊、病毒軟件等。不論哪種原因引發(fā)的Babbling Idiot 故障，使用總線監(jiān)守方法都能有效解決該問題。在CAN 總線上，當一個通信節(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)機，建立一個邏輯設備和4 根連接到主控制器的通信線，還有一根連接到收發(fā)器的通信線。

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

1.2 硬件導致的Babbling Idiot 故障

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

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

2 Babbling Idiot 故障解決策略

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

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

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

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

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

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

總線監(jiān)守通過兩根導線與主控制器連接：一個用于發(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 口賦值確定當前的運行狀態(tài)。下文結合圖2 闡述該系統(tǒng)狀態(tài)機的工作原理。

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

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

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

狀態(tài)4：數據傳輸完成后，主控制器清除發(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 總線標識符可變策略

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

選取5 級節(jié)點作為案例研究。節(jié)點優(yōu)先級A 最高、E 最低，依次降序排列，優(yōu)先級數值越大優(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)先級任務阻塞，導致節(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 總線標識符可增加這些節(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 總線第七個時隙標識符與CAN 總線的第七個時隙標識符相比，提早了4 個時隙。

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

3 實驗驗證及結果分析

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

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

CAN 總線與CAN 總線標識符的系統(tǒng)延遲時間比較結果見表8。從表中可以看出，采用可變CAN 總線標識符策略后的最壞情況是第一種情況。變量CAN 總線標識符和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 總線標識符可變優(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 總線標識符可變優(yōu)先級仲裁

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

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

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

3.2 實測與評估

通過實驗評估總線監(jiān)守功能。使磁懸浮系統(tǒng)運作后，控制小球不斷調整位置，通過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 總線不能有效自主地解決這個故障，導致總線通信一直被阻塞。在引入總線監(jiān)守模型后，再次重復制造Babbling Idiot 故障，在總線監(jiān)守模塊將故障節(jié)點與總線斷開后系統(tǒng)便恢復了正常通信。圖3 是在CANoe 中監(jiān)測到正常運行情況下磁懸浮小球的幀數據信息，可以看到小球位置信息幀、PID 相關參數幀以及磁懸浮設備相關參數幀。

采用穩(wěn)態(tài)誤差來評估系統(tǒng)性能穩(wěn)定情況。在CAN 總線的Babbling Idiot 故障解決后，用系統(tǒng)的穩(wěn)態(tài)性能作為該系統(tǒng)評價指標。圖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 故障時幀數據信息

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

4 結語

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