，， ，

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

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

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

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

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

車輛開(kāi)放系統(tǒng)架構(gòu)； 軟件構(gòu)件； 協(xié)議棧； 協(xié)議數(shù)據(jù)單元；回調(diào)函數(shù)；傳輸層

0 引言

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

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

1 AUTOSAR規(guī)范概述

AUTOSAR體系結(jié)構(gòu)主要分為三層，如圖1 所示。從上至下依次為應(yīng)用層、RTE層、基礎(chǔ)軟件層(BSW)，其中基礎(chǔ)軟件層細(xì)分為服務(wù)層、ECU 抽象層、微控制器抽象層及一個(gè)特殊的復(fù)雜驅(qū)動(dòng)層[2]。

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

應(yīng)用層由各應(yīng)用軟件構(gòu)件SWC構(gòu)成。各軟件構(gòu)件間的通信以及軟件構(gòu)件與底層硬件平臺(tái)間的信息交互都是通過(guò)RTE上的標(biāo)準(zhǔn)接口來(lái)實(shí)現(xiàn)的。

RTE 層實(shí)質(zhì)是一個(gè)虛擬功能總線(VFB)，主要為應(yīng)用層提供通信服務(wù)[3]。RTE層主要實(shí)現(xiàn)了上層應(yīng)用軟件與下層基礎(chǔ)軟件之間的隔離，使軟件工程師更加關(guān)注于上層應(yīng)用軟件的邏輯及算法，無(wú)須對(duì)底層硬件平臺(tái)及基礎(chǔ)軟件進(jìn)行過(guò)多的精力投入，從而大大提升了應(yīng)用軟件的開(kāi)發(fā)速度及其邏輯可靠性。

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

本文主要針對(duì)CAN 通信模塊的底層驅(qū)動(dòng)CanDrive、接口層CanIf、傳輸層CanTp進(jìn)行了研究與開(kāi)發(fā)，并基于飛思卡爾微控制器MC9S12XEP100實(shí)現(xiàn)了基本通信功能。

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

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

圖2 ISO 15765體系結(jié)構(gòu)圖

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

圖3 單幀、多幀傳輸過(guò)程

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

1)塊大小(BS)，即接收方允許發(fā)送方一次發(fā)送CAN報(bào)文的最大數(shù)量，然后需等待一個(gè)授權(quán)來(lái)繼續(xù)發(fā)送剩余的CAN報(bào)文；

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

3 CAN通信模塊設(shè)計(jì)

3.1 CAN驅(qū)動(dòng)模塊(CanDrv)

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

CAN驅(qū)動(dòng)模塊與其他模塊接口交互如圖4所示。

圖4 CAN驅(qū)動(dòng)模塊軟件接口關(guān)系圖

該模塊文件關(guān)系如圖5所示。

圖5 CAN模塊文件關(guān)系圖

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

該模塊主要函數(shù)功能介紹如下。

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

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

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

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

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

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

3.2 CAN 接口模塊(CanIf)

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

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

圖6 CAN接口模塊軟件接口關(guān)系圖

該模塊文件關(guān)系如圖7所示。

圖7 Can Interface模塊文件關(guān)系圖

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

該模塊主要函數(shù)功能如下。

1)CanIf_Init()：該函數(shù)用于初始化CAN Interface模塊中的全局變量和數(shù)據(jù)結(jié)構(gòu)，包括標(biāo)志位和緩存區(qū)等。

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

3)CanIf_Transmit()：該函數(shù)用于發(fā)起對(duì)某CAN L-PDU的發(fā)送請(qǐng)求。當(dāng)發(fā)送緩存被使能時(shí)，如果某個(gè)L-PDU在發(fā)送請(qǐng)求時(shí)被CanDrv拒絕了，CanIf會(huì)將其存儲(chǔ)到CanIf transmit L-PDU buffer中，此時(shí)如果其相應(yīng)的CanIfTxBuffer已經(jīng)滿了，則CanIf會(huì)用新的L-PDU覆蓋舊的L-PDU。

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

5)CanIf_RxIndication()：該函數(shù)用于指示經(jīng)過(guò)硬件濾波后成功接收到的某個(gè)L-PDU。

3.3 CAN 傳輸模塊(CanTP)

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

該模塊文件關(guān)系如圖8所示。

圖8 CanTp模塊文件關(guān)系圖

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

該模塊主要函數(shù)功能如下：

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

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

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

4)CanTp_RxIndication()：處理接收到的CAN幀(SF，F(xiàn)F，CF，F(xiàn)C)，并調(diào)用用戶提供的回調(diào)函數(shù)將數(shù)據(jù)拷貝到用戶提供的緩存中。

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

4 CAN通信流程

4.1 CAN發(fā)送流程

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

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

圖10 待發(fā)送數(shù)據(jù)結(jié)構(gòu)體定義

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

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

4.2 CAN接收流程

接收過(guò)程如圖11所示，當(dāng)物理總線上有接收數(shù)據(jù)時(shí)，當(dāng)程序配置為接收中斷方式時(shí)，將觸發(fā)CAN_PH0_Rx_ISR()來(lái)接收數(shù)據(jù)；當(dāng)程序配置為查詢接收時(shí)，將觸發(fā)CAN_MainFunction_Read()來(lái)接收數(shù)據(jù)。

圖11 CANIF接口層數(shù)據(jù)結(jié)構(gòu)定義

再次，通過(guò)調(diào)用CAN_Controller_Rx_handler()函數(shù)將數(shù)據(jù)存入對(duì)應(yīng)的存儲(chǔ)區(qū)中；若接收成功則調(diào)用接收指示函數(shù)CanIf_RxIndication()通知接口層成功接收一幀數(shù)據(jù)，并進(jìn)行接收確認(rèn)。

其次，接口層主要調(diào)用CanIfRxPduConfig(CANIF_CFG_TOTAL_RXPDUID)函數(shù)對(duì)收到的數(shù)據(jù)進(jìn)行識(shí)別與過(guò)濾，主要包括接收PduID、CAN總線ID、CANID類型、CAN數(shù)據(jù)長(zhǎng)度、CAN接收緩沖區(qū)、CAN接收應(yīng)用服務(wù)程序等，其示例如圖12所示。

圖12 CAN通信接收流程

最后接口層調(diào)用接收確認(rèn)函數(shù)CanTp_RxIndication()通知傳輸層接收到新的數(shù)據(jù),傳輸層開(kāi)辟相應(yīng)的數(shù)據(jù)存儲(chǔ)空間將接收到的數(shù)據(jù)放置于緩沖區(qū)中，并通知上層函數(shù)接收到新數(shù)據(jù)[4]。

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

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

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

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

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

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

6 總結(jié)

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

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

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

[3] 宋 波，王安軍，王正樹(shù).符合AUTOSAR規(guī)范的MCU驅(qū)動(dòng)設(shè)計(jì)與實(shí)現(xiàn)[J].研究與開(kāi)發(fā)，2011，：56-60.

[4] 王安軍,蔣建春,陳培然.符合AUTOSAR規(guī)范的底層驅(qū)動(dòng)軟件開(kāi)發(fā).計(jì)算機(jī)工程[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-)，男，副研究員，碩士，主要從事車輛機(jī)電綜合管理技術(shù)方向的研究。

1671-4598(2017)11-0239-05

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

TP3

A