CAN是最成功的現場總線,特別是在汽車工業的應用方面。僅2006年一年,CAN有關的控制器出貨量超過5億個。在過去16年里,有許多關于CAN在安全攸關的系統中應用時的安全問題的研究。其中大部分是針對因CAN事件觸發通信的性質引起的時間延遲問題,以及數據幀幀結束域倒數第2位出錯時造成的節點間消息不一致的問題。有些研究著力于解決CAN系統中的Babb—ling Idiot問題,尚未見到有關源于標準協議設計本身的嚴重問題的相關文獻。 1 出錯的情況 在CAN協議2.OA版3.1.3款中提到:為了使報錯幀正確結束,消極報錯節點可能需要處于空閑狀態至少3位的時間(如果消極報錯接收節點發生本地錯),因此總線不應滿負荷運行。這是引發應用故障的原因。節點間并無時間同步,因而即便總線有空閑時間,也不能保證像上述要求那樣的分布。在總線的利用率較低時,掛起待發的消息將在服務間隔(intermission,縮寫為I.M.)后立即發送。這在標準中也有規定:在另一條消息發送過程中掛起待發的消息在服務間隔后的第一位啟動(發送)。 現在考慮一種情況:由于電磁干擾,某消極報錯節點發生一個本地錯(其他節點未發現有錯),它就發一個消極報錯標志(P.E.Flag)。因為是隱位,其他節點對這個消極報錯標志也無響應。這一消極報錯幀的報錯標志在數據幀ACK分界符后的EOF部分得到確認(如圖1所示),但是它的消極報錯幀分界符 (P.E.Del)延續到EOF域最后一位以及服務間隔之后。如果此時有3位的總線空閑時間,那么新幀的開始位(SOF)將是該消極報錯節點服務間隔的第一位。按ISO16845標準,此顯位被解讀為對超載幀的請求,由消極報錯節點發送的超載幀將引起其他節點的位填充錯,使它們發送主動報錯幀。主動報錯幀與超載幀將在總線上疊合,雖然比特流的解釋對該消極報錯節點和其他節點而言是不同的,但兩種幀分界符的結束時刻是一樣的。所有節點都會在此刻復位CAN協議狀態機的狀態,使它回到開始服務間隔的狀態。這解釋了。BoschCAN協議的說明。但如果對3位總線空閑時間沒有保證,那又該如何呢? ![]() 對報錯幀分界符格式錯的檢查在國際標準化組織(ISO)的標準ISO16845中有明確的規定:在消極報錯幀分界符中的任何顯位是一種格式錯。第 7.5.6款和8.5.13款是對應消極報錯接收節點和消極報錯發送節點消極報錯幀分界符格式錯的測試方法,第7.6.12款和8.6.9款是消極報錯節點消極報錯幀分界符查到格式錯時,接收錯計數器與發送錯計數器增加機制的檢查方法。因此,消極報錯節點與其他節點不同步時,另一個節點開始發送新消息,其 SOF將被該消極報錯節點視為消極報錯幀分界符內的格式錯。它將在其他節點新幀傳送過程中開始一個新的消極報錯幀,新的消極報錯標志將在其他節點新幀的 EOF部分得到確認,新消極報錯幀分界符再一次延續到超過其他節點服務間隔之后。只要掛起的消息未發完,這一過程將不斷重復。在此時間段里,消極報錯節點不能接收或發送任何消息,因為它總在不斷發送消極報錯幀。這延遲了該節點應發送的消息,而不管消息的優先級有多高,也就引起了優先級逆轉。由于電磁干擾的隨機性,無法對系統進行調度分析。這個消極報錯節點有2種可能的方式退出循環。如果在后面不斷發送的新幀的某處出現了主動報錯幀,該消極報錯節點的消極報錯幀將與主動報錯幀重疊,重復過程結束。但在正常應用場合中,錯誤是很少發生的,因此后續的傳送越正常,該消極報錯節點等效離線狀態時間越長。另一個可能是經過一些傳送后不再有掛起待發的幀,總線空閑時間足夠長,正如協議設想的那樣,能使消極報錯幀的分界符正常結束,消極報錯幀分界符格式錯的重復也就此結束。 2 可能的情景 除了上述消極報錯接收節點的本地故障會引起等效離線的失效以外,其他情景下消極報錯節點也有可能與簇內其他節點丟失狀態同步。這些情景在三方面超出了Bosch CAN協議設計時的設想:第一,不僅消極報錯接收節點會丟失同步,而且消極報錯發送節點也會丟失同步;第二,在有些場合,為了實現同步,所需的總線空閑時間要更多(至少為10位);第三,不僅消極報錯節點的本地錯會引起問題,在少數場合,主動報錯節點的本地故障也會引起問題。下面舉一些例子,實際上有問題的情景遠不止這些。 在圖2中,消極報錯接收節點由于電磁干擾而未能查出總線上的一個全局錯(即漏判性質的本地錯),但是過后它發現了因其他節點所發送主動報錯幀引起的位填充錯,它發送的消極報錯幀將遲于其他節點的主動報錯幀結束,因此丟失了同步。 ![]() 在圖3中,消極報錯接收節點在EOF域中發生誤判性質的本地錯。 ![]() 它的消極報錯幀不會被其他節點看到,因而它們以正常方式結束收發。消極報錯節點的消極報錯幀要遠遲于其他節點的結束時刻結束,在此情況下,為使消極報錯節點能同步,最少要有10位的總線空閑時間。當總線有10位空閑時間時,新幀的SOF會被消極報錯節點看作超載幀的請求,盡管在超載幀結束后節點間實現了狀態同步,但卻因超載幀造成不必要的開銷。這里理想的總線空閑時間為13位。 在圖4中,由于電磁干擾消極報錯發送節點未能正確讀取ACK位,它發出的消極報錯幀將被其他節點看作ACK分界符和EOF域,就像消極報錯接收節點一樣,它失去了與其他節點的狀態同步。 ![]() 在圖5中,消極報錯發送節點的本地錯發生在CRC分界符處,它的消極報錯標志的第一位被其他節點的ACK位改寫,消極報錯幀的剩余部分被其他節點看作 ACK分界符和EOF域,狀態不同步再次發生。 ![]() 在圖6中,消極報錯發送節點的本地故障造成ACK分界符的誤讀,它開始一個消極報錯幀,而其他節點把它誤讀為數據幀的EOF域,此時消極報錯發送節點狀態與其他節點不同步。 ![]() 當一個規模較小的系統僅剩一個主動報錯節點時,它的本地錯將引起一個主動報錯幀。其主動報錯標志會被其他消極報錯節點視為位填充錯或格式錯,從而開始它們的消極報錯幀(見圖7)。結果是主動報錯幀較早結束,狀態的不同步再次出現。 ![]() 3 后果 當消極報錯節點出現上述分析的情景時,就沒有機會收發消息。直到總線空閑或者有一個主動報錯節點發主動報錯幀時,才可能恢復正常。由于錯誤的發生是隨機事件,在正常應用環境中其間隔會相當長。消極報錯節點逸出這種等效離線狀態的最壞情況是,它要等到總線成為空閑。此段時間為系統中所有消息的最壞響應時間中最大的那個。以Tindell改造過的SAE典型試驗數據集為例,最大最壞響應時間在總線速率為125 kbps時為49.192ms,250kbps時為14.404ms。總線的利用率相應為94.2%和47.1%。如果故障發生在收發制動壓力的消息(其周期為5 ms)的節點,則汽車可能在125 kbps時丟失10次數據,250 kbps時丟失3次數據。在此期間作用在輪子上的制動力不是所期望的,汽車將有難以預計的風險。以每小時100 km行駛的汽車將在1.4 m或O.4 m的距離上失去控制。 消極報錯節點狀態同步的丟失可能比上述最壞情況早些結束,但這完全取決于錯誤的統計學特性,超出了CAN調度分析的假設,使CAN設計工具不精確。當消極報錯節點丟失同步后,即使有一些未確知的總線空閑時間,它們可能引入超載幀,這也是調度分析時未加考慮的。因此設計工具難以給出有足夠精度的真實結果。這會危害到所設計系統的安全性。另外,超載幀也降低了總線的吞吐率。 4 解決方案 經仔細分析所有可能的全局錯和本地錯以后,各種情景和合適的消極報錯幀分界符長度間的關系就建立起來了。所謂“合適”是指消極報錯節點能在出錯后依然與其他節點的狀態保持同步。在有些場合中消極報錯幀分界符應為原來的8位長,在有些場合中它應是2位長,在另外一些場合中它應是1位長。若本地錯發生在數據幀或遠程幀的EOF域,那么為了實現正確的同步,最好的選擇是在EOF的最后一位處對CAN協議狀態自動機進行復位。需要根據總線上的數據流以及錯誤發生的位置加以判斷,該消極報錯節點是發生了全局錯還是本地錯,從而確定應有的消極報錯幀分界符長度,或者啟動協議狀態機的復位信號,完整的解決方案已申請了專利。 將消極報錯幀分界符長度簡單地改為另一個固定的長度,可能簡化實現的復雜性,在某些場合它可以避免在消極報錯節點有本地錯時產生長時間的等效離線狀態的失效,但是這一解決方案無法應對所有可能丟失同步的情景。同時它還殘留有其他的一些缺點:例如增加了消極報錯節點不能接收的機會;因重復出錯或超載幀造成調度結果確定性的下降;本節點或其他節點所發消息優先級的逆轉;因超載幀造成帶寬的無效占用。所以這種簡化造成的性能下降是得不償失的。 按修改后實現的消極報錯幀不能通過現有標準ISO16845第7.5.6款和8.5.13款的全部測試設置,因為消極報錯幀分界符的長度不再是固定的8 位。CAN標準ISO11898及ISO16845應依據應用中對安全的要求作相應的修改。 5 小結 在消極報錯幀分界符內格式錯的后果長期以來被忽視了。即使在一般應用中等效離線狀態和優先級逆轉也是不能容忍的,因為一次電磁干擾造成的1位錯所要承受的懲罰太大了。為了將CAN用于更為嚴格的安全攸關的應用中,這個問題是非解決不可的。 參考文獻 1. CAN in Automation celebrates first 15 years 2007 2. GmbH Robert Bosch CAN Specification Version 2.0 1991 3. ISO/TC 22/SC3 ISO16845-2004.Road VehiclesController Area Network (CAN)Conformance Test Plan 4. Tindell K W.Burns A Guaranteed Message Latencies for Distributed Safety-Critical Hard Real-Time Control Networks.[Technical Report YCS229] 1994 作者:重慶工業自動化儀表研究所 楊福宇 來源:單片機與嵌入式系統應用 2009 (1) |