基于AUTOSAR標準的車輛電氣系統(tǒng)CAN通信協(xié)議棧研究

，， ，

(中國北方車輛研究所，北京 100072)

基于AUTOSAR標準的車輛電氣系統(tǒng)CAN通信協(xié)議棧研究

李艷明，倪永亮，李申，喬鳳普

(中國北方車輛研究所，北京100072)

AUTOSAR是面向車輛電子電氣領域的開放式軟件體系架構標準;在充分學習研究AUTOSAR軟件體系標準的基礎上，開發(fā)了具有層次化、模塊化、標準化接口的的CAN底層通信協(xié)議棧，并在飛思卡爾16位微控制器MC9S12XEP100的平臺中進行了加載測試；測試證明該協(xié)議棧能夠很好地實現CAN總線各層間的通信，能夠滿足車輛電子電氣系統(tǒng)對總線通信方面的要求，具有較強的兼容性和移植性，可以顯著地提高不同硬件平臺間軟件代碼的移植速度，節(jié)省了軟件開發(fā)時間，提升了軟件代碼的可靠性。

車輛開放系統(tǒng)架構； 軟件構件； 協(xié)議棧； 協(xié)議數據單元；回調函數；傳輸層

0 引言

隨著現代車輛電子技術的發(fā)展，信息化程度日益增高、電子控制單元不斷增多、軟件代碼量急速上升；從而導致車輛電子控制系統(tǒng)的軟件開發(fā)周期較長、產品的人力成本較高、軟件可移植率較低等方面，因此車輛電子控制軟件常規(guī)開發(fā)方法面臨巨大挑戰(zhàn)。為了解決這些突出問題，由世界上主要的車輛制造商及零部件供應商，于2003 年聯合制定了車輛開放系統(tǒng)框架( automotive open system architecture，AUTOSAR)[1]，旨在提出一套針對車輛電子軟件開發(fā)標準化、模塊化、通用化的方案，從而達到提升軟件研發(fā)速度，規(guī)范軟件研發(fā)流程的目的。AUTOSAR的理念、方法論和軟件架構已經被越來越多的OEM和供應商認可。目前，AUTOSAR組織成員即涵蓋了奔馳、寶馬、等著名的車輛生產廠商，也涵蓋了Vector、Mentor、ETAS等著名的零部件制造商，我國上汽、一汽、北京經緯恒潤公司等也加入了該組織。

在充分學習研究車輛AUTOSAR技術的基礎上，將其CAN通信底層規(guī)范應用于車輛電子控制領域，旨在提升車輛電子控制軟件的開發(fā)效率、統(tǒng)一車輛電子控制系統(tǒng)軟件架構、夯實車輛電子控制系統(tǒng)軟件可靠性。

1 AUTOSAR規(guī)范概述

AUTOSAR體系結構主要分為三層，如圖1 所示。從上至下依次為應用層、RTE層、基礎軟件層(BSW)，其中基礎軟件層細分為服務層、ECU 抽象層、微控制器抽象層及一個特殊的復雜驅動層[2]。

圖1 AUTOSAR通信協(xié)議棧架構

應用層由各應用軟件構件SWC構成。各軟件構件間的通信以及軟件構件與底層硬件平臺間的信息交互都是通過RTE上的標準接口來實現的。

RTE 層實質是一個虛擬功能總線(VFB)，主要為應用層提供通信服務[3]。RTE層主要實現了上層應用軟件與下層基礎軟件之間的隔離，使軟件工程師更加關注于上層應用軟件的邏輯及算法，無須對底層硬件平臺及基礎軟件進行過多的精力投入，從而大大提升了應用軟件的開發(fā)速度及其邏輯可靠性。

基礎軟件層提供系統(tǒng)服務、硬件驅動及實時任務處理等功能，服務層與硬件平臺之間加入ECU抽象層和微控制器抽象層。通過抽象設計屏蔽硬件功能的實現細節(jié)，并向操作系統(tǒng)和RTE層提供符合規(guī)范的標準接口[4]。其中服務層主要包括系統(tǒng)服務、存儲服務及通信服務，主要提供操作系統(tǒng)管理、基于UDS(統(tǒng)一診斷服務)的診斷事件控制及管理、Flash存儲管理以及通信協(xié)議的解析處理等；ECU抽象層主要實現對硬件平臺除微控制器外的其它外設(如鐵電)等的AUTOSAR抽象化，使之滿足上層服務的要求；微控制器抽象層主要是將微控制器內部的資源(如ADC、SCI)等的接口驅動函數進行AUTOSAR標準化，以方便上層應用的調用；復雜驅動位于RTE 層與硬件平臺之間，用于驅動對時序嚴格要求的復雜傳感器和執(zhí)行器(如電機的實時性驅動)。

本文主要針對CAN 通信模塊的底層驅動CanDrive、接口層CanIf、傳輸層CanTp進行了研究與開發(fā)，并基于飛思卡爾微控制器MC9S12XEP100實現了基本通信功能。

2 CAN通信協(xié)議流程

CAN通信協(xié)議棧主要參考ISO-15765 診斷協(xié)議進行開發(fā)， ISO-15765傳輸層協(xié)議用于發(fā)送、接收數據報文并報告發(fā)送、接收的結果。ISO 15765協(xié)議適用于基于CAN通信網絡的車輛診斷系統(tǒng)。如圖2所示。

圖2 ISO 15765體系結構圖

由于CAN總線每幀報文最多只能包含8個字節(jié)，因此數據傳輸方式分為兩種方式。對于數據長度小于或等于8個字節(jié)的情況，使用一幀CAN報文即可完成傳輸，該形式被稱為單幀傳輸；對于數據長度大于8個字節(jié)的情況，需先將數據分段打包后通過發(fā)送多個CAN報文來實現，接收時再將這些CAN報文重新組合，該形式稱為多幀傳輸。傳輸過程定義了單幀、首幀、連續(xù)幀和流控制幀4種基本類型[2]。其傳輸過程如圖3所示。

圖3 單幀、多幀傳輸過程

在多幀傳輸過程中，發(fā)送方和接收方要不斷進行信息交換。發(fā)送方首先發(fā)送“第一幀”，告知接收方將要發(fā)送數據的總長度；接收方分配好資源，準備接收數據，然后以一幀“流控制幀”告知發(fā)送方一次可以發(fā)送的數據包數目和時間間隔；發(fā)送方接下來就根據接收方的接收能力將編好序號的數據包依次發(fā)送過去，這種傳輸機制稱為流控制機制。圖4描述了流控制機制的流程。接收方通過發(fā)送“流控制幀”可授權發(fā)送方繼續(xù)發(fā)送/延遲發(fā)送剩余的連續(xù)幀，或在將要發(fā)送的數據長度超過自身接收緩存的時候取消目前的分段數據接收，流控制幀中標識接收方能力的兩個參數包括。

1)塊大小(BS)，即接收方允許發(fā)送方一次發(fā)送CAN報文的最大數量，然后需等待一個授權來繼續(xù)發(fā)送剩余的CAN報文；

2)最短間隔時間(STmin)：發(fā)送方在發(fā)送兩個連續(xù)幀之間等待的最短時間。

3 CAN通信模塊設計

3.1 CAN驅動模塊(CanDrv)

該模塊主要實現CAN控制器的初始化、發(fā)送和接收以及提供CAN控制器的狀態(tài)查詢。

CAN驅動模塊與其他模塊接口交互如圖4所示。

圖4 CAN驅動模塊軟件接口關系圖

該模塊文件關系如圖5所示。

圖5 CAN模塊文件關系圖

其中Can.c主要包含CAN模塊內部使用的全局數據類型和函數的定義；Can.h主要包含為其他模塊所用到的常量，全局變量，數據類型定義和服務函數的外部聲明；Can_Cfg.h主要包含在預編譯階段本模塊可配置的常量和宏的定義；Can_PBcfg.c 主要包含可執(zhí)行程序建立后的可配置參數定義；ComStack_Types.h主要包含CAN通信協(xié)議棧軟件通用的數據類型定義的頭文件；Std_Types.h主要包含標準類型定義的頭文件；Platform_Types.h 主要包含平臺類型定義頭文件，包含與平臺相關的類型和符號定義；Compiler.h 包含將與特定編譯器相關的關鍵字進行抽象處理的宏定義。

該模塊主要函數功能介紹如下。

1)Can_Init()：該函數用于初始化與整個CAN 控制器相關的設置及相關的標志位，并初始化所有的CAN controller。初始化后所有CAN controller由CAN_UNINT狀態(tài)轉換到了CAN_STOPPED狀態(tài)，此時其還不能參與總線的通信，需要由應用程序單獨將每個controller由CAN_STOPPED狀態(tài)切換到CAN_STARTED狀態(tài)。

2)Can_SetControllerMode()：該函數執(zhí)行由軟件觸發(fā)的CAN controller狀態(tài)轉換。該函數會一直查詢CAN的狀態(tài)寄存器相關flag，直到該flag指示轉換生效或超時，若轉換生效，則通知上層轉換成功完成。

3)Can_Write()：該函數主要用于將CAN緩沖區(qū)中的報文發(fā)送出去。

4)Can_MainFunction_Write()：當發(fā)送模式設置為輪詢時，該函數用于執(zhí)行對成功發(fā)送確認(TX Confirmation)的輪詢及處理。

5)Can_MainFunction_Read()：當接收模式設置為輪詢時，該函數用于執(zhí)行對成功接收指示(RX indication)的輪詢及處理。

6)Can_EnableControllerInterrupts()：該函數用于將指定CAN controller的中斷恢復到禁止中斷前的狀態(tài)。

3.2 CAN 接口模塊(CanIf)

CAN Interface模塊位于最底層(CAN Driver)和上層通信服務層的中間，其充當CAN Driver和上層通信服務層的接口層，主要完成發(fā)送請求服務、發(fā)送確認服務，接收指示服務，CAN控制器模式控制服務，PDU的模式控制服務等。

CAN接口模塊與其他模塊接口交互如圖6所示。

圖6 CAN接口模塊軟件接口關系圖

該模塊文件關系如圖7所示。

圖7 Can Interface模塊文件關系圖

其中CanIf.c包含了Can Interface模塊運行時所有的內核代碼；CanIf.h是Can Interface模塊的頭文件，包含了對變量、函數以及類型的外部聲明；CanIf_Type.h包含對某些通用的Can Interface類型的聲明，CanIf.h需包含該頭文件；CanIf_Cbk.h聲明了所有在Can Interface模塊中執(zhí)行，但被Can Driver模塊調用的回調函數；CanIf_Cfg.h及CanIf_Lcfg.c為該模塊的配置文件，主要定義了預編譯時間、連接時間的值。

該模塊主要函數功能如下。

1)CanIf_Init()：該函數用于初始化CAN Interface模塊中的全局變量和數據結構，包括標志位和緩存區(qū)等。

2)CanIf_SetControllerMode()：該函數用于改變Controller的模式。

3)CanIf_Transmit()：該函數用于發(fā)起對某CAN L-PDU的發(fā)送請求。當發(fā)送緩存被使能時，如果某個L-PDU在發(fā)送請求時被CanDrv拒絕了，CanIf會將其存儲到CanIf transmit L-PDU buffer中，此時如果其相應的CanIfTxBuffer已經滿了，則CanIf會用新的L-PDU覆蓋舊的L-PDU。

4)CanIf_TxConfirmation()：該函數用于確認前一個被成功發(fā)送的CAN L-PDU。

5)CanIf_RxIndication()：該函數用于指示經過硬件濾波后成功接收到的某個L-PDU。

3.3 CAN 傳輸模塊(CanTP)

傳輸模塊主要實現通信雙方之間的基于ISO 15765協(xié)議的CAN通信功能；收發(fā)單幀和多幀報文，對多幀報文進行解包和組包；控制數據流；檢測報文收發(fā)過程中的各類錯誤，并向上層報告。

該模塊文件關系如圖8所示。

圖8 CanTp模塊文件關系圖

其中CanTp.c包含CanTp模塊內部使用的全局數據類型和函數的定義；CanTp.h包含被其他模塊所用到的常量，全局變量，數據類型定義和服務函數的外部聲明；CanTp_Cbk.h包含回調函數的外部聲明；CanTp_Cfg.h：包含在預編譯階段本模塊可配置的常量和可定制數據的定義；CanTp_PBcfg.c包含可執(zhí)行程序建立后的可配置參數定義。

該模塊主要函數功能如下：

1)CanTp_Init()：該函數初始化CanTp模塊，包括內部變量初始化和CanTp狀態(tài)初始化。

2)CanTp_MainFunction()：該函數是傳輸層模塊的主任務處理函數，實現TP內部狀態(tài)轉換，執(zhí)行定時發(fā)送連續(xù)幀(CF)，流控制幀(FC)，重發(fā)，超時處理等操作。該函數必須被固定周期調用，調用周期可配置。

3)CanTp_Transmit()：發(fā)送CAN N-SDU報文，發(fā)送單幀或多幀的第一幀。

4)CanTp_RxIndication()：處理接收到的CAN幀(SF，FF，CF，FC)，并調用用戶提供的回調函數將數據拷貝到用戶提供的緩存中。

5)CanTp_TxConfirmation()：在任意類型的CAN幀被執(zhí)行發(fā)送后，執(zhí)行該函數確認該幀發(fā)送成功。

4 CAN通信流程

4.1 CAN發(fā)送流程

首先上層診斷模塊DCM向傳輸協(xié)議層發(fā)送傳輸請求并調用請求函數Can_Tp_TxMainFunction()，進而調用Can_TP_CanTransmit(CanTxPduId,pduInfoPtr)起動一次數據的傳輸;其中CanTxPduId是CAN數據包的PduID，pduInfoPtr是一個指向數據結構的指針，其定義如圖10所示,該指針主要包含指向待發(fā)送數據的指針以及待發(fā)送數據的長度；該函數根據數據長度自動調用長幀傳輸或者短幀傳輸。

圖9 CAN通信發(fā)送流程

圖10 待發(fā)送數據結構體定義

再次，傳輸層將待發(fā)送數據傳遞至CANIF接口層，調用一個函數Can_If_Transmit()來發(fā)起CAN 發(fā)送。該函數在待發(fā)送序列CanIfTxPduConfig(CANIF_CFG_TOTAL_TXPDUID)中進行查詢是否存在該發(fā)送任務,若存在該任務則直接調用底層Can_Write()函數進行發(fā)送，同時將待發(fā)送數據存放于臨時緩沖區(qū)中，以防發(fā)送失敗對數據進行重新發(fā)送，并且調用CanIf_TxConfirmation()向上層發(fā)送確認；若不存在則取消發(fā)送。

最后，CAN底層驅動層調用Can_Write()函數將數據填充到CAN硬件緩沖區(qū)中，并觸發(fā)硬件起動一次CANBuffer的發(fā)送[3]。

4.2 CAN接收流程

接收過程如圖11所示，當物理總線上有接收數據時，當程序配置為接收中斷方式時，將觸發(fā)CAN_PH0_Rx_ISR()來接收數據；當程序配置為查詢接收時，將觸發(fā)CAN_MainFunction_Read()來接收數據。

圖11 CANIF接口層數據結構定義

再次，通過調用CAN_Controller_Rx_handler()函數將數據存入對應的存儲區(qū)中；若接收成功則調用接收指示函數CanIf_RxIndication()通知接口層成功接收一幀數據，并進行接收確認。

其次，接口層主要調用CanIfRxPduConfig(CANIF_CFG_TOTAL_RXPDUID)函數對收到的數據進行識別與過濾，主要包括接收PduID、CAN總線ID、CANID類型、CAN數據長度、CAN接收緩沖區(qū)、CAN接收應用服務程序等，其示例如圖12所示。

圖12 CAN通信接收流程

最后接口層調用接收確認函數CanTp_RxIndication()通知傳輸層接收到新的數據,傳輸層開辟相應的數據存儲空間將接收到的數據放置于緩沖區(qū)中，并通知上層函數接收到新數據[4]。

5 通信協(xié)議棧測試與分析

基于MC9S12XEP100的硬件平臺，配合Vector公司的CANoe進行通信協(xié)議棧的測試。將上位機CANoe定義為數據接收端，物理尋址ID設定為0x777，功能尋址ID設定為0x7DF；下位機MC9S12XEP100的硬件平臺定義為數據發(fā)送端，ID 設定為0x77F。

首先上位機發(fā)送了10單幀服務請求(02 10 03 00 00 00 00 00)，10服務用于使能不同的診斷會話。診斷會話包括默認會話模式、編程模式和擴展模式，不同的診斷會話具有不同的功能，且定時參數和安全訪問級別也不一樣。此10服務用于進入擴展模式，在擴展模式下，所有的診斷服務均可以使用。下位機接收后返回一個首幀肯定響應(06 50 03)，證明下位機已經進入擴展模式，已經做好準備接收命令。

其次上位機發(fā)送了27單幀服務請求(02 27 01 00 00 00 00 00)。27服務用于安全訪問，主要獲取下位機的安全種子，經過安全算法計算后返回給下位機安全密鑰，經下位機驗證正確后方可實現對下位機的解鎖；下位機接收后返回一個首幀肯定響應(06 67 01 0C 0C 0C 0C 55)，下位機返回的種子為67 01 0C 0C 0C 0C；上位機經過運算下發(fā)安全密鑰(06 27 02 00 00 00 01 00)，安全密鑰為27 02 00 00 00 01；下位機經過核對返回安全密鑰肯定響應(02 67 02 55 55 55 55 55)，證明下位機已經完全解鎖，做好準備接收服務請求。

最后，上位機發(fā)送了22服務請求數據傳輸(03 22 F1 90 00 00 00 00)。22服務是依據數據標識符ID來讀取對應的數據記錄，該數據ID為F1 90；下位機接收后返回一個首幀肯定響應(10 14 62 F1 90 00 00 00 00)，定義傳輸數據長度為20個字節(jié)，并且已經發(fā)送前6個字節(jié)；上位機依據接收的數據長度發(fā)送流控制幀(30 00 02 00 00 00 00 00)，定義下位機傳送2個連續(xù)幀；下位機開始進行數據傳輸直到兩個連續(xù)幀傳送完畢。

實驗結果表明該CAN總線傳輸通信協(xié)議棧符合ISO15765傳輸規(guī)范，傳輸時序符合最大時延要求；在時延要求范圍內能夠可靠穩(wěn)定地實現CAN總線通信，CAN通信各層均能夠正常運行，能夠很好地將AUTOSAR通信服務加載于16位微控制器平臺中。

6 總結

本文基于目前流行的車輛軟件開放架構標準AUTOSAR，設計了車輛電子控制系統(tǒng)基于硬件平臺飛思卡爾微控制器MC9S12XEP100的CAN底層通信協(xié)議棧。經過測試，該協(xié)議棧可以成功高效地完成CAN總線通信，提升了軟件的可讀性及可移植性，提升了在不同硬件平臺下應用軟件的移植速度，縮短了開發(fā)周期，對車輛電子平臺化發(fā)展具有重要的意義。

[1] AUTOSAR. layered software architecture[Z].2013.

[2] 馮 川,胡 杰,顏伏伍,等.符合AUTOSAR標準的CAN底層通信研究[J].武漢理工大學學報(信息與管理工程版),2013,35(6):842-845,855.

[3] 宋 波，王安軍，王正樹.符合AUTOSAR規(guī)范的MCU驅動設計與實現[J].研究與開發(fā)，2011，：56-60.

[4] 王安軍,蔣建春,陳培然.符合AUTOSAR規(guī)范的底層驅動軟件開發(fā).計算機工程[J]，2011，37(9)：62-64.

ResearchonCANCommunicationProtocolStackofVehicleE/ESystemBasedonAUTOSARCriterion

Li Yanming, Ni Yongliang, Li Shen, Qiao Fengpu

(China North Vehicle Research Institute，Beijing 100072,China)

AUTOSAR is a open software architecture standard in automotive E/E system. On the basis of full study and research of AUTOSAR structure，the CAN Communication Protocol Stack was developed with hierarchy and standardization，also loaded and tested on the micro controller of MC9S12XEP100.The results prove that the Protocol Stack can greatly realize communication between different layers of CAN，which can meet the requirements of Vehicle bus communication；it is also capable of compatibility and transportation，which can observably increase the code transporting speed between different hardware platforms, decrease the software developing time and also increase the code reliability.

AUTomotive open system ARchitecture(AUTOSAR)；SWC；communication protocol stack；PDU；callback function; transportation layer

2017-09-05；

2017-09-27。

李艷明(1981-)，男，副研究員，碩士，主要從事車輛機電綜合管理技術方向的研究。

1671-4598(2017)11-0239-05

10.16526/j.cnki.11-4762/tp.2017.11.061

TP3

A