ISOCAN協議棧解析及其在飛思卡爾單片機平臺的實現

劉波，李瓊，顧蓓蓓

(南京奧聯汽車電子技術有限公司，江蘇南京 211153)

?

ISOCAN協議棧解析及其在飛思卡爾單片機平臺的實現

劉波，李瓊，顧蓓蓓

(南京奧聯汽車電子技術有限公司，江蘇南京 211153)

摘要：ISOCAN協議被廣泛應用于乘用車各電控單元間的數據交換。為確保數據在傳輸過程中的穩定性和正確性，對ISOCAN協議棧的體系結構進行分析，并對協議棧的數據鏈路層進行具體的解析，詳細分析邏輯鏈路子層(LLC)和介質訪問層(MAC)、CAN的幀結構以及CAN的錯誤檢測和管理?；陲w思卡爾單片機平臺實現了上述協議，并通過Vector公司的CAN總線仿真工具CANoe對CAN收發過程進行驗證。實驗結果表明：實現的協議?？梢詼蚀_穩定地接收和發送報文，驗證了設計的CAN通信協議的有效性。

關鍵詞：CAN；協議棧解析；飛思卡爾單片機；CANoe仿真

0引言

汽車電子技術的不斷發展，使得汽車上各電子控制系統功能更加精細，結構越發復雜，如果汽車電子系統采用以往的點對點通信的方式，則會形成大量的線束，不僅占用了大量的車內空間，還嚴重制約著汽車向經濟性和智能化方向的發展，也成為汽車輕量化和進一步電子化的最大障礙，汽車的制造和安裝也變得非常困難。因此，基于總線技術的車載網絡應運而生，它被廣泛地應用于汽車電子系統中[1-2]。

目前車載網絡的主流協議標準主要分為多媒體網絡協議標準、高安全性網絡協議標準、低速網絡協議標準和中速網絡協議標準。多媒體網絡標準協議中，面向媒體系統的傳輸協議MOST及IDB-1394是目前廣泛應用的高速通信協議[3-4]。高安全性網絡協議標準旨在滿足線控汽車設計的安全性，TTCAN(Time Triggered CAN)、FlexRay和TTP(Time Triggered Protocol)是其主要代表[5-7]。低速網絡協議標準主要應用于車內傳輸速率和安全性不是太高的ECU場合，LIN(Local Interconnect Network)就是為此類應用設計的低成本協議。LIN是單一主機系統，不但降低了硬件成本，而且很好地兼容了其他網絡協議，LIN的傳輸速率高達20 kb/s[8]。中速網絡協議標準以CAN、VAN、ABUS和SAEJ1850為代表，其中CAN最早成為國際標準的汽車總線協議，其產生和發展詳見第1節。

文中著重研究了乘用車內廣泛使用的ISOCAN，對其協議棧結構進行了分析，并重點對數據鏈路層協議進行解析。最后基于飛思卡爾單片機平臺實現了該協議，通過實驗仿真證明了CAN報文收發過程的正確性和有效性。

1CAN總線的產生及發展

CAN總線是在20世紀80年代由BOSCH公司為解決汽車電子系統中數據交換而開發的控制器局域網協議，是一種用于實時環境的串行通信總線，采用短幀結構，非破壞性總線仲裁技術，支持多種工作方式，支持點對點、一點對多點及全局廣播等多種數據收發方式，具有完善的錯誤檢測機制，能夠滿足構建高性能、高實時性系統的要求。1991年發布了CAN2.0版本的應用標準，包括A和B兩個部分，在1.2版本基礎上增加了擴展幀格式兼容[9-10]。1993年，CAN成為國際標準ISO11898(高速應用)和ISO11519(低速應用)，并在工業現場領域得到了廣泛的應用。1995年，CIA組織(CAN in Automation)頒布了完整的CANopen協議，包括應用層規范、通信協議和設備協議。

2標準化CAN協議棧解析

2.1標準化CAN的OSI模型體系結構

CAN協議遵從ISO/OSI網絡開放系統模型，圖1為標準化CAN的各層協議(包括依據的規范和標準)及其與OSI模型各層的對應關系。按照這個標準模型，CAN協議可以分為4層，從上到下依次為應用層、網絡層、數據鏈路層和物理層。圖1的右半部分為CAN數據鏈路層及物理層的詳細描述。故障界定是一種能區分短期干擾和永久故障的自校驗機制。物理層可由檢測并管理物理介質故障的實體總線故障管理和錯誤界定來監控[11-14]。

圖1　CAN的ISO網絡模型定義

數據鏈路層主要作用有：為遠程數據請求以及數據傳輸提供服務，判斷是否接受收到的報文，提供恢復管理和過載通知服務。LLC子層的功能是為數據傳送和遠程數據請求提供服務。MAC子層主要定義了傳送規則，即實現控制幀結構、執行仲裁、錯誤檢測、出錯標定、故障界定等。

2.2LLC子層

LLC子層應提供兩種類型的無連接模式發送服務：一種為未確認的數據傳輸服務，該服務為LLC用戶之間在沒有建立數據鏈路連接的情況下交換LSDU(LLC層服務數據單元)提供方法，數據傳輸方式可以為點對點、多路傳送或廣播；另一種為未確認遠程數據請求服務，該服務為LLC用戶在沒有建立數據鏈路連接的情況下提供請求遠程節點進行LSDU傳輸的方法。根據以上兩種不同的LLC服務，在用戶之間傳送的幀類型有：LLC數據幀和遠程幀。

2.3MAC子層

MAC子層服務允許本地LLC子層實體和同層LLC子層實體間交換MSDU(MAC層服務數據單元)，MAC子層提供確認數據發送、確認遠程數據請求和過載幀發送等服務。

MAC子層的功能模型如圖2所示。

圖2　MAC子層功能

該功能模型將MAC子層分成發送和接收兩個獨立的部分。幀發送實現發送數據封裝和發送介質訪問管理等功能；而幀接收實現接收媒介訪問管理及接收數據拆裝等功能。

2.4CAN的幀結構

CAN的報文主要有4個不同類型的幀：數據幀、遠程幀、錯誤幀和過載幀。

對于數據幀和遠程幀又定義了標識符ID為11位的標準幀格式和29位的擴展幀格式，兩種格式下的數據幀都由7個不同的位場組成：幀起始(SOF)、仲裁場、控制場、CRC場、應答場(ACK)和幀結束，遠程幀沒有數據場，標準幀和擴展幀的格式見圖3。

圖3　標準格式和擴展格式的數據幀

遠程幀和數據幀的不同在于遠程幀的RTR位是隱性的，而數據幀的RTR位是顯性的，且遠程幀無數據場，數據代碼長度DLC不受制約。

錯誤幀和過載幀都由兩個域組成，其結構分別如圖4 和圖5 所示。錯誤幀由兩個不同的場組成，第一個場用作為不同站提供的錯誤標志的疊加，第二個場是錯誤界定符。過載幀的兩個位場分別為過載標志和過載界定符。

圖4　錯誤幀結構

圖5　過載幀結構

2.5CAN錯誤檢測與錯誤管理

CAN通過定義完善的錯誤檢測和管理機制，成為汽車網絡中安全、可靠的技術標準。CAN總線中存在5種不同的錯誤類型，分別為位錯誤、填充錯誤、CRC錯誤、形式錯誤和應答錯誤。

為了進行故障界定，在總線上的每個節點單元中都設置有兩種計數器：發送出錯計數器和接收出錯計數器。錯誤計數器按照一系列規則進行更新。節點的狀態遷移如圖6所示。

圖6　節點狀態遷移

根據錯誤計數器的數值，節點可能處于如下3種狀態：(1)錯誤激活狀態。一個錯誤激活狀態下的節點可正常參與總線通信，并在檢測到錯誤時發送一個活動錯誤標志。(2)錯誤認可狀態。一個錯誤認可狀態下的節點不發送活動錯誤標志，它參與總線通信，但在檢測到錯誤時，發送一個認可錯誤標志。(3)總線關閉狀態。當一個節點對總線處于關閉狀態時，即處于總線關閉狀態，在該狀態下，節點既不發送也不接收任何幀。

3標準化CAN協議棧在飛思卡爾單片機平臺的實現與仿真

文中以飛思卡爾單片機MC9S12G48MLH為平臺，實現了上述解析的協議，并將該CAN節點用于模擬汽車換擋器，將采集的請求擋位信息通過CAN總線發送給CANoe仿真工具模擬的車身控制模塊(VCM)，并接收VCM模擬發送的實際擋位信號，若請求擋位與實際擋位相同，則點亮相應的擋位指示燈，否則使相應的擋位指示燈閃爍。請求擋位信號與開關霍爾輸出之間的關系及擋位指示燈與請求擋位和實際擋位的關系分別見表1和表2。

表1　請求擋位信號與開關霍爾輸出之間的關系

表2　擋位指示燈與請求擋位和實際擋位的關系

表2中，0代表P擋指示燈閃爍，1代表P擋指示燈亮；2代表R擋指示燈閃爍，3代表R擋指示燈亮；4代表N擋指示燈閃爍，5代表N擋指示燈亮；6代表D擋指示燈閃爍，7代表D擋指示燈亮。模擬的CAN節點發送報文的數據域第一個字節表示擋位請求，第二個字節表示擋位指示燈亮閃情況；接收的VCM報文第一個字節表示實際擋位，其余數據域全部設為0。

3.1硬件設計

文中選用的單片機MC9S12G48MLH內部集成了CAN控制器MSCAN，能按CAN2.0的要求對通信進行規范管理，用戶只需設置或查詢相關的控制或狀態寄存器。文中將擋位采集節點與模擬的整車控制器相連，硬件結構如圖7所示。

圖7　CAN通信硬件結構

主控制器主板CAN模塊接口外接CAN收發器，CAN收發器再連接到整車CAN總線上，文中采用的收發器為NXP公司生產的TJA1040T，其接口電路如圖8所示。圖中，L226為共模電感，目的是為了抑制共模干擾、提高電磁兼容性。兩個MMBZ33V的作用為雙重ESD保護二極管瞬態過電壓抑制。

圖8　CAN收發器接口電路

3.2軟件設計

軟件部分主要分為驅動層、數據鏈路層和應用層，其結構和各部分的作用如圖9所示。主要實現的功能是將請求擋位通過CAN報文發送給VCM，VCM將實際所處的擋位通過報文發送給GSM模塊，GSM再將接收的實際擋位與請求擋位進行比較，點亮相應的擋位指示燈。GSM發送和接收報文的流程圖分別如圖10所示。

圖9　軟件架構圖

圖10　CAN報文發送和接收流程

3.3實驗結果及分析

采用德國Vector公司的產品CANoe對實現的CAN協議進行仿真。CANoe是進行網絡和ECU開發、測試和分析的全面工具，包括模型創建、仿真、測試、診斷及通信分析等。使用CANoe對CAN總線仿真的原理見圖11，圖中的虛線部分表示可以接更多的物理節點，并模擬更多的仿真節點。文中實驗只用一個物理節點和一個仿真節點，仿真分析界面如圖12所示。

圖11　CANoe仿真原理

圖12　CANoe仿真分析界面

仿真結果分別如圖13—16所示。

圖13　模擬P擋信號發送和實際擋位接收

圖14　模擬R擋信號發送和實際擋位接收

圖15　模擬P擋信號發送和實際擋位接收

圖16　模擬R擋信號發送和實際擋位接收

圖13為模擬發送P擋的結果分析，從發送和接收的報文中可知：當請求擋位為P擋且反饋擋位為P擋時，點亮P擋指示燈(Flag=1)(圖中圈出的部分)；當請求擋位為P擋而實際擋位不為P擋時，閃爍P擋指示燈(Flag=0)。R、N和D擋的報文發送和接收情況分別見圖14—16。

4結束語

對目前乘用車廣泛應用的ISOCAN協議棧的體系結構進行了分析說明，并對協議棧的數據鏈路層進行了具體的解析。對數據鏈路層中邏輯鏈路子層(LLC)和介質訪問層(MAC)、CAN的幀結構以及CAN的錯誤檢測和管理進行了詳細的闡述。為了實現解析的協議，基于飛思卡爾單片機平臺設計了CAN物理節點來模擬汽車換擋器單元，并通過Vector公司的CAN總線仿真軟件CANoe對CAN收發過程進行驗證。實驗結果表明：設計的CAN協議可成功實現與CANoe模擬的VCM節點之間的通信。

參考文獻:

【1】朱明.現代汽車電子技術的應用現狀及發展趨勢[J].電子技術與軟件工程，2015(9):260.

【2】胡德鵬.汽車電子技術的應用與發展[J].電子技術與軟件工程， 2014(20):262.

【3】廖發良.車載MOST總線系統[J].農業裝備與車輛工程，2009(7)：55-57.

【4】胡云.對IEEE1394總線技術的研究[J].科學技術與工程，2007(3):299-302.

【5】紀光霽，萬茂松.汽車ECU通訊新平臺——FlexRay(V2.1)協議規范[J].汽車電器，2006(10):1-6.

【6】曹萬科，張天俠，劉應吉.基于混合調度算法汽車TTCAN網絡設計及實時性分析[J].中國工程機械學報，2007，5(1)：62-66.

【7】王婧，張欣.汽車網絡通信協議TTP/C和FlexRay的研究分析[J].北京汽車，2006(6):40-43.

【8】趙雙，孫天健.LIN總線技術及其在汽車電子中的應用[J].北京汽車，2007(3):44-46.

【9】閆茂德，陳金平.基于CAN總線的汽車電子系統傳輸網絡設計[J].長安大學學報(自然科學版)，2006,26(1)：86-89.

【10】李永強，宋希庚，薛冬新.CAN局域網及J1939協議在貨車和客車上的運用[J].汽車工程,2003,25(4)：377-380.

【11】ISO11898-1：Road Vehicle-controller Area Network(CAN):Part1：Data Link Layer and Physical Signaling[S]，2003.

【12】ISO11898-2：Road Vehicle-controller Area Network(CAN):Part2：High-speed Medium Access Unit[S]，2003.

【13】ISO11898-3：Road Vehicle-controller Area Network(CAN):Part3：Low-speed,Fault-tolerant,Medium-dependent Interface[S]，2003.

【14】ISO15765-2：Road Vehicle-diagnostics on Controller Area Networks(CAN):Part2：Network Layer Services[S],2004.

Analysis of ISOCAN Protocol Stack and Its Implementation Based on Platform of Freescale Microcontroller

LIU Bo, LI Qiong, GU Beibei

(Nanjing Aolian Automotive Electronic Technology Co.,Ltd., Nanjing Jiangsu 211153,China)

Abstract:ISOCAN protocol is widely applied to data exchange among each electronic control unit(ECU)of passenger vehicles. To ensure stability and correctness of data during transmission, the architecture of ISOCAN protocol stack was analyzed, then logical link layer(LLC)of protocol stack was analyzed specifically. LLC and MAC, architecture of CAN frame, and error detection & management were illustrated. Finally, the above protocol was implemented based on platform of Freescale microcontroller and the progress of CAN transmission and receive was verified throughout CAN bus simulation software CANoe produced by Vector company. Experimental results show that the implemented CAN protocol stack can be used to receive and transmit frames correctly and stably, which verifies the effectiveness of the designed CAN communication protocol proposed.

Keywords:Controller area network(CAN); Protocol stack analysis; Freescale microcontroller; CANoe simulation

收稿日期：2015-09-17

作者簡介：劉波(1989—),男，碩士，研究方向為汽車CAN協議及零部件開發。E-mail：liubo369@126.com。

中圖分類號:G64

文獻標志碼：A

文章編號：1674-1986(2016)01-028-06