基于CCP協(xié)議利用CANape進(jìn)行電控單元標(biāo)定

目前基于can(controller area network)總線的分布式系統(tǒng)在汽車電子領(lǐng)域得到廣泛應(yīng)用,電子控制單元的標(biāo)定已成為汽車電子控制裝置開發(fā)的一個重要環(huán)節(jié)。ccp(can calibration protocol)是一種基于can總線的ecu(electronic control unit)標(biāo)定協(xié)議[1],已經(jīng)在許多歐美汽車廠商得到應(yīng)用,采用ccp協(xié)議可以快速而有效地實現(xiàn)對汽車電控單元的標(biāo)定。

然而基于ccp協(xié)議的標(biāo)定,需要在ecu內(nèi)部實現(xiàn)支持ccp協(xié)議的驅(qū)動程序(ccp driver)。目前大多數(shù)應(yīng)用都采用vector提供的free ccp driver[2]?？紤]到ecu底層程序與can驅(qū)動程序的實現(xiàn)各不相同,將ccp驅(qū)動程序結(jié)合到ecu中[3]并不是一件一蹴而就的事,這需要對ccp協(xié)議本身、標(biāo)定工具及標(biāo)定工具與ecu之間的通信有詳細(xì)和深入的了解。在整個標(biāo)定系統(tǒng)的開發(fā)過程中,大量時間被耗費在前期ccp驅(qū)動程序與ecu結(jié)合上。本文在簡單介紹ccp協(xié)議的基礎(chǔ)上,提供了一個通用的ecu與ccp驅(qū)動程序結(jié)合的實例,以幫助縮短整個標(biāo)定開發(fā)周期。

canape[4]是一款ecu標(biāo)定和測試工具。與ccp協(xié)議相結(jié)合,不僅能完成對ecu的標(biāo)定,同時還能在ecu運行期間直接訪問內(nèi)存并進(jìn)行操作。這使得canape不僅是一款功能強(qiáng)大的標(biāo)定工具,也是一款電控單元開發(fā)的得力助手。然而在使用方面,canape的前期配置比較繁瑣,目前國內(nèi)的相關(guān)資料較少。本文將介紹canape,并著眼于如何基于ccp協(xié)議使用canape完成ecu的標(biāo)定。

1 ccp協(xié)議及工作原理

ccp協(xié)議是asap(arbeitskreis zur standardisierung von applikationssystemen)標(biāo)志的有機(jī)組成部分。asap作為一個應(yīng)用系統(tǒng)標(biāo)準(zhǔn)化工作小組,其目的在于提供通用軟、硬件接口標(biāo)準(zhǔn),以解決由于不同制造商提供的控制器存在的接口不匹配問題。

1.1 ccp通信方式

基于ccp協(xié)議的ecu標(biāo)定采用主-從通信方式,如圖1。主設(shè)備通過can總線與多個從設(shè)備相連,其中主設(shè)備是測量標(biāo)定系統(tǒng)mcs(measurement calibration system),從設(shè)備是需要標(biāo)定的ecu,在汽車電子中即為車載控制器。

根據(jù)ccp協(xié)議,主設(shè)備首先與其中一個從設(shè)備建立邏輯鏈接,然后通過主設(shè)備向從設(shè)備發(fā)送命令來起始兩者間的數(shù)據(jù)通信。當(dāng)主設(shè)備要訪問另一個從設(shè)備時,首先斷開與當(dāng)前從設(shè)備的邏輯連接,與下一個從設(shè)備建立新的邏輯連接后再開始通信。

1.2 ccp協(xié)議的工作模式

ccp定義了兩種工作模式:polling(查詢)模式及daq(data acquisition command)模式。查詢模式下,主設(shè)備與從設(shè)備間的每一次通信都由主設(shè)備發(fā)送命令來起始,從設(shè)備收到主設(shè)備的命令后,執(zhí)行相應(yīng)的操作并反饋一幀報文。這種工作模式由于需要主機(jī)與從機(jī)之間進(jìn)行“一問一答”的信息交互,工作效率不高,但實現(xiàn)簡單,而且占用ecu內(nèi)存資源較小。 daq模式使從設(shè)備可以脫離主設(shè)備的命令控制按一定周期自動向主設(shè)備上傳數(shù)據(jù)。daq模式下,主設(shè)備首先發(fā)送一條請求daq的命令,從設(shè)備收到后,按命令中的參數(shù)自行配置并組織需要上傳的數(shù)據(jù),然后按一定周期自主向主設(shè)備上傳數(shù)據(jù)。這種模式由于不需要主機(jī)通過命令逐步控制,工作效率高,但實現(xiàn)較復(fù)雜,如果需要上傳的數(shù)據(jù)量很大,會占用大量ecu內(nèi)存空間。

1.3 ccp報文幀結(jié)構(gòu)

基于ccp協(xié)議的標(biāo)定只占用兩幀can報文,分別是命令接收對象cro(command receive object)和數(shù)據(jù)傳輸對象dto(data transmission object),如圖2所示。cro由主設(shè)備發(fā)給從設(shè)備,dto是從設(shè)備反饋的報文。兩者分別通過一個自己的id標(biāo)識符進(jìn)行標(biāo)識(cro_id與dto_id)。

cro與dto的id標(biāo)識符由通信協(xié)議自行定義,ccp協(xié)議只對cro及dto的數(shù)據(jù)場做了詳細(xì)定義。按照ccp協(xié)議,cro數(shù)據(jù)場的第1個字節(jié)為命令代碼cmd(command code),ccp協(xié)議共規(guī)定了28條命令[1]。從設(shè)備通過cmd代碼判斷主設(shè)備請求的是哪條命令。數(shù)據(jù)場的第2個字節(jié)是命令計數(shù)器ctr(command counter)。剩余6個字節(jié)均為命令參數(shù),每條命令有各自對應(yīng)的命令參數(shù)。

從設(shè)備反饋的報文稱為dto。按ccp協(xié)議,dto又細(xì)分為三類:

·命令返回消息crm(command return message):由從設(shè)備發(fā)送,針對cro的反饋報文。

·事件消息(event message):當(dāng)從設(shè)備檢測到內(nèi)部發(fā)生錯誤機(jī)制時,由從設(shè)備自行向主設(shè)備發(fā)送,報告其當(dāng)前的運行狀態(tài),并請求主設(shè)備暫停當(dāng)前工作進(jìn)程以處理發(fā)生的錯誤。

·daq-dto(data acquisition-dto):用在daq模式中,由從設(shè)備組織,定期向主設(shè)備發(fā)送。

dto報文的第1個字節(jié)pid(packet id)定義了dto的類型,255代表crm, 254代表事件消息。第2個字節(jié)為命令返回/錯誤代碼err(command return-/error code)。對于crm,主設(shè)備由該字節(jié)獲知命令的執(zhí)行情況;對于事件消息,主設(shè)備由該位獲知從設(shè)備內(nèi)部發(fā)生了哪種錯誤。第3字節(jié)ctr是命令計數(shù)器,該位數(shù)值與其對應(yīng)的cro的ctr值相對應(yīng)。剩余5個字節(jié)是數(shù)據(jù)場,存放主設(shè)備請求的數(shù)據(jù)或信息。

2 基于ccp協(xié)議的接口程序?qū)崿F(xiàn)

基于ccp協(xié)議進(jìn)行標(biāo)定,需要mcs與ecu的應(yīng)用程序都能夠支持ccp協(xié)議,這部分應(yīng)用程序稱為ccp driver。本文采用vector提供的free ccp driver[2]。由于ccp協(xié)議基于can總線,因此ccp driver與ecu的結(jié)合主要分為與can driver及與其他應(yīng)用程序兩方面。

ccp driver與can driver的結(jié)合如圖3,主要分為以下兩方面:

·發(fā)送端:dto通過can driver的發(fā)送子函數(shù)以can報文的格式上傳給mcs。

·接收端:主設(shè)備發(fā)送的命令以can報文的格式首先進(jìn)入can driver的接收子函數(shù),由其判斷為cro后,進(jìn)一步交給命令處理器處理。

命令處理器作為ccp driver的一個主要組成部分,負(fù)責(zé)將接收到的cro,通過其crm代碼進(jìn)行命令解釋,執(zhí)行相應(yīng)操作,組織反饋數(shù)據(jù)并調(diào)用can發(fā)送子函數(shù)。daq處理器支持daq工作模式,當(dāng)命令處理器判斷收到的命令為daq請求后,進(jìn)一步將數(shù)據(jù)傳給daq處理器,由daq處理器組織數(shù)據(jù)并直接調(diào)用can 發(fā)送子函數(shù),以daq-dto的形式定期向主設(shè)備上傳。

基于ccp協(xié)議的基本can通信流程如圖4所示。ecu接收到報文后,轉(zhuǎn)入can接收子函數(shù),在常規(guī)接收流程后,對報文的id標(biāo)識符進(jìn)行判斷,如為cro_id,則將ccp標(biāo)志位(ccp_indicator)置位。由于采用中斷方式接收報文,為了避免占用過多中斷時間而影響其他函數(shù)或中斷級別較低的程序運行,在對id標(biāo)識符進(jìn)行判斷后,并不直接在函數(shù)中調(diào)用ccp driver的命令處理器。命令處理器的調(diào)用會在主函數(shù)中進(jìn)行。

主函數(shù)通過判斷標(biāo)志位的狀態(tài),調(diào)用ccp driver的ccpcommand()子函數(shù)。該函數(shù)是命令處理器的主要組成部分,也是命令處理器與can driver的接口函數(shù),它負(fù)責(zé)解釋并執(zhí)行收到的cro命令,調(diào)用ccp driver中的其他函數(shù),進(jìn)行數(shù)據(jù)處理并組織需要反饋的數(shù)據(jù)。

ccpcommand()通過調(diào)用can driver中的ccp發(fā)送子函數(shù)ccpsend()發(fā)送一幀dto。ccpsend()須在can driver中實現(xiàn),由ccp driver調(diào)用。按實際情況,將can發(fā)送子函數(shù)直接以ccpsend()的形式實現(xiàn),或在保留原有發(fā)送子函數(shù)的基礎(chǔ)上添加一個ccpsend()子函數(shù),在其中調(diào)用can發(fā)送子函數(shù),以完成dto的發(fā)送。

ccp協(xié)議為確保主設(shè)備與ecu之間正常通信,每次發(fā)送后,程序必須通過調(diào)用ccp driver中的ccpsendcallback()子函數(shù)檢查剛才的dto是否已經(jīng)發(fā)送,否則不能發(fā)送下一幀報文。針對不同的can driver實現(xiàn),該函數(shù)調(diào)用的位置不同。最后主函數(shù)將ccp標(biāo)志位清空,等待下一條cro命令。

一個完整的ccp driver 接口還包括與ecu其他應(yīng)用程序的接口。每次單片機(jī)初始化后,主函數(shù)調(diào)用一次ccp driver的ccp初始化子函數(shù)ccpinit(),將上次標(biāo)定殘留在ecu內(nèi)存中的數(shù)據(jù)清空,為下次標(biāo)定與測量做準(zhǔn)備。

ccp協(xié)議共定義了28條命令,每條命令在ccp driver中都對應(yīng)一組相應(yīng)的子函數(shù),代表不同的功能,如eeprom標(biāo)定、daq工作模式等。用戶可根據(jù)實際需要,選擇實現(xiàn)其中部分或全部功能。每增加一個新的功能,必須在底層程序中添加開放該項功能的程序接口[3]。如對eeprom標(biāo)定,首先ecu應(yīng)用程序中應(yīng)包含eeprom模塊子函數(shù),同時還需實現(xiàn)命令處理器與eeprom模塊之間的調(diào)用接口。

3 利用canape實現(xiàn)基于ccp的標(biāo)定

canape[4]是德國vector公司出品的一款基于asap標(biāo)準(zhǔn)的ecu測試和標(biāo)定工具。它通過一個控制器硬件接口與ecu相連,兩者之間常用的物理連接是基于ccp協(xié)議的can總線。只有控制器的底層程序中有支持ccp協(xié)議的程序接口, canape才能與控制器通信。

canape提供了多種功能:在線數(shù)據(jù)評估、離線評估、數(shù)據(jù)管理、flash編程、參數(shù)標(biāo)定及asap2數(shù)據(jù)編輯器等。此外,測試過程中由can總線上傳的數(shù)據(jù)還可以通過canape在計算機(jī)顯示和保存,以進(jìn)行離線標(biāo)定和數(shù)據(jù)評估。

3.1 asap2控制器描述文件及asap2編輯器

canape與控制器間的通信需要一個描述文件支持,這個文件稱為asap2控制器描述文件[4]。canape對控制器的參數(shù)標(biāo)定和數(shù)據(jù)測量都是基于這個文件,該文件記錄了控制器中各參數(shù)的詳細(xì)信息,如標(biāo)定參數(shù)和測量變量在控制器中的存儲地址、存儲結(jié)構(gòu)、數(shù)據(jù)類型和轉(zhuǎn)換公式等。在canape中,每個標(biāo)定參數(shù)和測量數(shù)據(jù)都會有一個變量名,如發(fā)動機(jī)溫度、冷卻水溫度。當(dāng)canape需要訪問某個變量,就在asap2描述文件中根據(jù)變量名,找到該變量在控制器中的存儲地址、數(shù)據(jù)長度等信息,然后進(jìn)行操作,如圖5。

為了方便用戶對asap2文件進(jìn)行維護(hù)和修改,canape集成了一個asap2數(shù)據(jù)庫編輯器,用以生成和修改asap2控制器描述文件。所有的信息都能通過對話框的形式進(jìn)行設(shè)置和修改。該數(shù)據(jù)庫編輯器還能工作在獨立模式下,以生成一個asap2格式的控制器描述文件。

當(dāng)ecu底層程序修改后,一些標(biāo)定參數(shù)和測量數(shù)據(jù)的內(nèi)存地址可能發(fā)生變動,canape雖然仍能進(jìn)行標(biāo)定,但修改的已不是原來需要標(biāo)定的參數(shù),而是程序變動后原先地址下當(dāng)前存放的某個新的未知數(shù)據(jù)。為了簡化手工修改地址的繁瑣,防止因為隨意修改某個數(shù)據(jù)而破壞程序的正常運行,canape支持通過linker map文件自動更新asap2文件里的信息。map文件是ecu底層程序在編譯時由編譯器生成的一種映射文件,通過map文件可以自動更新asap2文件。

3.2 canape使用配置

每個需要標(biāo)定的ecu都要在canape中進(jìn)行配置。

canape共定義了28條命令,用以實現(xiàn)不同的功能,在配置頁面里均有復(fù)選框與其對應(yīng)?？刂破鞯呐渲帽仨毰cccp driver在ecu底層程序的具體實現(xiàn)相匹配,只有對某個功能的程序接口已經(jīng)開放,才能在canape中選擇使用該項功能[2][5]。

3.3 canape中的參數(shù)標(biāo)定

在canape中,需要標(biāo)定的變量稱為標(biāo)定參數(shù),canape將標(biāo)定定義為修改駐扎在ecu內(nèi)存中的變量的內(nèi)容。canape支持多種標(biāo)定方法。這里標(biāo)定方法指如何對標(biāo)定參數(shù)所在的內(nèi)存區(qū)域進(jìn)行初始化、數(shù)據(jù)改寫及保存。根據(jù)標(biāo)定參數(shù)所在不同地址空間(rom、flash或eeprom),canape規(guī)定了不同的標(biāo)定方法。

當(dāng)標(biāo)定參數(shù)需要存放在flash或rom中時,在ecu上電初始化后,程序首先將標(biāo)定參數(shù)的初始值復(fù)制到ram中,在canape中該段用來存放標(biāo)定參數(shù)的ram稱為calibration ram。標(biāo)定過程中,canape修改calibration ram中的參數(shù)值。標(biāo)定全部結(jié)束后,再將該段ram中的內(nèi)容復(fù)制回flash或rom中。

當(dāng)標(biāo)定參數(shù)存放在eeprom中,有兩種標(biāo)定方法。第一種與上述方法相同,首先將標(biāo)定參數(shù)復(fù)制到ram中,標(biāo)定結(jié)束后再將ram中的數(shù)據(jù)覆蓋到eeprom。此外,也可對eeprom中的參數(shù)直接進(jìn)行改寫,實現(xiàn)這種方法需要對eeprom進(jìn)行頻繁擦寫操作,但不占用額外的ram空間。

由于汽車電子網(wǎng)絡(luò)系統(tǒng)已開始得到廣泛的使用,基于網(wǎng)絡(luò)連接的電子控制單元的匹配標(biāo)定和傳統(tǒng)的匹配標(biāo)定方法已有了很大的不同,特別是基于can總線的匹配標(biāo)定技術(shù),目前已成為研究和應(yīng)用的重點。

采用canape進(jìn)行基于ccp的匹配標(biāo)定,實現(xiàn)了標(biāo)定工具和內(nèi)容的統(tǒng)一。根據(jù)這種方法能夠快速有效地進(jìn)行汽車電子控制單元的匹配標(biāo)定,在實際開發(fā)應(yīng)用中取得了良好的效果。