|
CAN是應用非常廣泛的現場總線。它已經被大部分汽車廠商用作車內控制器交換信息的通信干線，是分布式嵌入式系統的關鍵部分。但是它有一種以前未討論過的與安全有關的故障，當某一處于消極報錯狀態的節點由于干擾而產生一個本地錯后，因標準考慮欠周，該節點會與其他節點幀啟停失去同步，在其他掛起待發的消息發送時不斷出錯，形成等同于離線的狀態，無法提供服務，從而危及安全。本文討論處于消極報錯狀態的發送節點，由于同樣的原因失去同步后的演變過程。這里不同的是，因為標準中的另一個規定，它可能經歷一個真正的離線狀態。 1 CAN標準的安全漏洞 在討論該問題時假定讀者對CAN的標準已有充分的了解，由于中文譯法的差別，本文采用的術語可能有所不同，相信不會影響讀者的理解。在Bosch CAN2.O規范3．1．3款中說：“為了使報錯幀正確結束，消極報錯節點可能需要處于空閑狀態至少有3bit時間(如果消極報錯接收節點發生本地錯)，因此總線不應滿負荷運行�！薄@是引起應用出故障的原因。因為節點問并無時間同步，即便總線有空閑時間，也不能保證像上述要求那樣的分布。掛起待發的消息將在服務間隔(intermission，圖中縮寫為I．M．)后立即發送。這在規范中也有規定：“在另一條消息發送過程中掛起待發的消息在服務間隔后的第一位啟動(發送)”。ISO11898標準沒有提到3位空閑問題，但是CAN一致性測試標準ISO16845的具體條文會有這種要求(雖然該空閑要求還是不充分的)。CAN規定處于消極報錯狀態的節點在發現錯之后發出6位隱位的消極報錯標志(Passive error flag)，如讀回6個連續的相同位時，就確認報錯標志發完，如沒發現6個連續的相同位，就繼續發隱位，直到得到確認，然后開始消極報錯幀分界符的發送。分界符從發出隱位讀回也是隱位時開始計算，總共為8個連續的隱位。在CAN一致性測試標準ISO16845的7．5．6款與8．5．13款中，規定了接收節點與發送節點在發消極報錯幀分界符時的格式錯檢查辦法。它規定，在消極報錯幀分界符開始后的8位中不得有顯位；如有顯位，就視為出錯，開始新的報錯幀。 如果一個處于消極報錯狀態的節點發現一個本地錯(即有一種誤判或漏判)，由于其他節點不發主動報錯幀，那么它發的消極報錯幀標志就不會及時得到確認，往往要到圖1所示的數據幀或遠程幀的EOF第5位才會得到確認；而它的消極報錯幀分界符將延續到幀的服務間隔之后，它就和其他節點的幀啟停失去了同步。其他節點開始新幀的SOF將被它視為格式錯，而開始發新的消極報錯幀。當其他節點有掛起待發的幀不斷發送時，這個處于消極報錯狀態的節點一直處于不斷出錯的狀態，不能發送也不能接收，即等同于離線狀態。 這種源自標準考慮不周的故障會使CAN的優先級逆轉(在處于消極報錯狀態的節點中的高優先級消息無法發送)；同時，基于優先級進行的調度分析失靈。以此為算法設計得到的消息最壞送達時間將是不可靠的，車的安全會受影響。在參考文獻[1]中，討論了修改消極報錯幀分界符長度來解決該故障的方法。 
2 處于消極報錯狀態發送節點本地錯的后果 處于消極報錯狀態的發送節點在有本地錯時，其行為傾向更差。標準ISO16845的8．6．9款對發送節點在消極報錯幀分界符內的格式錯規定了發送錯計數器TEC+8，第7．6．12款對處于消極報錯狀態的接收節點在消極報錯幀分界符內的格式錯規定了接收錯計數器REC+1。而且標準規定REC是有上限的，它不會導致節點成為離線狀態；但TEC會一直加上去，當TEC=256時節點就成為離線狀態，直到在總線上讀到128個連續的11個隱位，然后它變為主動報錯狀態。因此弄清楚節點是接收還是發送的地位非常重要。 Bosch CAN 2．O規范3．2款對節點的定義是這樣的：“開始一個消息的單元被稱為該消息的發送節點。在總線空閑之前，或該單元在仲裁中失敗之前，該單元一直是發送節點�！薄耙粋�節點被稱為一條消息的接收節點的條件是：它不是該消息的發送節點且總線不空閑”。國際標準ISO11898-1：2003第4．18款有類似的定義：“發送節點是指開始一個數據幀或遠程幀的節點，在總線再次空閑之前或在仲裁失敗之前，它仍是發送節點”。第4．16款：“不是發送節點且總線不空閑時節點是接收節點”。標準考慮了如下幾種情況： ①一個節點開始發送ID，仲裁失敗，在此段時間里它是發送節點，而后它是接收節點。 ②一個節點開始發送ID，仲裁勝出，發送完數據幀或遠程幀，在整個發送時段及其后的服務間隔內，它是發送節點。 ③一個節點開始發送ID，其中發生錯誤，或者在仲裁勝出后繼續發送中出錯，那么從開始到報錯幀結束及其后的服務間隔內，它是發送節點。因為總線空閑最早在服務間隔之后。 ④一個節點開始發送ID，仲裁勝出，發完數據幀或遠程幀，但由于某種原因(EOF的最后一位為顯位，或其后的服務間隔內第一、二位為顯位)，接了一個超載幀。那么在整個上述時段及其后的服務間隔內，它是發送節點。 CAN協議沒有考慮重復出錯的情況：第一次是處于消極報錯狀態的節點發現一個本地錯，其后是因為消極報錯幀結束時與其他節點幀啟停失去同步而造成新錯。在圖2中，處于消極報錯狀態的發送節點在ACK位發現一個本地錯，它發的消極報錯幀被其他節點視為EOF和服務間隔。其他節點發的新幀SOF被它視為格式錯。該處于消極報錯狀態的發送節點無法見到它預期的服務間隔的結束，它就以發送節點的地位一直錯下去。圖3中，處于消極報錯狀態的發送節點在EOF部分發現一個本地錯，其后續演化與圖2相似。
只要有掛起待發的消息，此錯就重復發生。由于發送節點的地位未變，它的TEC就一直加上去，直到TEC≥256，節點成為真正的離線狀態。這不是本文第1 節所說的等同離線狀態。在離線狀態下，如果能從總線上讀到128次連續的11位隱位，它就可以恢復為主動報錯狀態�？偩�上不足11位的隱位將不被計入。因此，這種離線狀態一般要長于參考文獻[1]所說的等同離線狀態。為了作比較，假定幀長均為含2字節數據的幀(66位)，在掛起的消息傳送16次后，該處于消極報錯狀態的發送節點成為離線，即16×(66+3)=1 104位后離線；又假設最壞情況下有分散的10位空閑，那么節點處于離線的時間為128×(66+3+10)=10112位。該處于消極報錯狀態的發送節點發現一個本地錯后，將有11 216位的時間不能正常收發。同樣情況下，一個處于消極報錯狀態的接收節點發現一個本地錯后在第一次遇到足夠空閑時間時，其等同離線狀態就會結束。 這種處于消極報錯狀態的發送節點變為真正離線的過程是無法從高層加以干預的，因為發送節點／接收節點的地位不是一個軟件可控制的參數。 3 為什么需要消極報錯狀態 理論上，解決這一故障有三種可能的方案：第一種方案是，將消極報錯幀分界符長度按一定的規則改變，使處于消極報錯狀態的節點發現一個錯后總能與其他節點幀啟停保持同步。在本文討論的處于消極報錯狀態的發送節點變為離線狀態的例子中，僅僅改變判斷發送節點／接收節點的規則也是不夠的，因為它僅能把可能的真正離線變為等同離線。所以隨情況改變，消極報錯幀分界符長度仍然是需要的。這一方案對應用的改動最小，僅CAN通信控制器芯片要修改。第二種方案是采用某種形式的CAN時間觸發CAN協議，預留出一些總線空閑時間，使處于消極報錯狀態的節點發現一個本地錯后仍能與其他節點幀啟停同步；但是迄今為止討論的 CAN時間觸發協議都缺少足夠的糾錯能力，它們都禁止CAN的出錯自動重發機制，在出錯后會導致數據的丟失。第三種可能的解決方案是，放棄消極報錯狀態，沒了消極報錯狀態就沒了消極報錯幀，就不會有不同步的情況出現，也就不會有離線和等同離線的情況出現。 消極報錯狀態使通信控制器在正常工作與停工之間有一個中間狀態，在此種狀態下，它仍可發送和接收。唯一的差別是它的報錯能力被限制到很�。褐挥邪l送節點在 ACK以前的本地錯會被其他節點知道。在其他情況下，消極報錯幀不會影響其他節點的收發，不管這種錯是本地錯還是全局錯。這樣，如果這個處于消極報錯狀態的節點不正常，那么它對系統性能下降的影響就很��；如果它工作正常，則系統的性能沒有損失。 對汽車類的應用來說，環境很惡劣，出錯是不可避免的，然而在現場進行排障或修理是有難度或不可能的(例如上天或人海的應用)。在那里，能“跛”著回家是最好的策略。這種策略不僅適用于機械部分，也適用于工作失常的電子通信系統。消極報錯狀態符合這種策略。當車子在這種“跛”著回家方式下工作時，某些暫時性的故障有可能消失。例如，環境溫度、電磁場、振動都可能因工況的不同或路段的不同而改變。隨著通信恢復正常，節點的狀態也可由消極報錯狀態回到主動報錯狀態。如果節點只有主動報錯和離線二種狀態，那么離線時節點就要不斷測試通信是否恢復，或者等一段時間測試一下。顯然，這些方法效率要低，不像消極報錯狀態時仍能提供服務，意味著提供服務的時間的減少。延長處于主動報錯狀態的時間，而去掉消極報錯狀態，會使有本地故障的節點對系統的干擾時間也延長。因此廢棄消極報錯狀態不是一個好的選擇。從Bosch CAN2．0規范里也可以體會到這一點：它規定一個處于消極報錯狀態的節點一定不得發主動報錯標志。消極報錯狀態的想法也為FlexRay所采用，在它的協議運行控制部分規定有三種狀態，分別是POC：NormalActive、POC：Normeal Passive和POC：Halt。 4 小結 上述分析表明：處于消極報錯狀態的CAN發送節點在某些條件下會因一次誤判而進入離線狀態。其離線的時間一般比處于消極報錯狀態的接收節點因一次誤判而進入的等同離線狀態要長。為了避免這種類型的失效，最好的解決方案是采用可變長消極報錯幀分界符，使消極報錯狀態的節點總能與系統內的其他節點保持幀啟停的同步。在同步的情況下，假設現有CAN調度分析的理論沒有大的缺失，例如沒有此類故障，沒有引起超載幀的條件，可以提供較為可信的結果。 參考文獻 1. 楊福宇 CAN 總線系統中的一種安全隱患 [期刊論文] -單片機與嵌入式系統應用2009(1) 2. Robert Bosch GmbH CAN Specification Version 2.0 1991 3. ISO/TC 22/SC3.International standard:ISO 11898-1 "Road Vehicles-Controller Area Network (CAN)-Part1  ata link layer and physical signalling" 20034. ISO/TC 22/SC3.International standard:ISO 16845 "Road Vehicles-Controller Area Network (CAN)-Conformance test plan" 2004 作者：重慶工業自動化儀表研究所 楊福字 來源：單片機與嵌入式系統應用 |
