電子發(fā)燒友App
]
摘 要：采用基于CAN總線(xiàn)的匹配標(biāo)定協(xié)議,對(duì)汽車(chē)控制器局域網(wǎng)絡(luò)中的電子控制單元進(jìn)行匹配標(biāo)定。分析了CCP協(xié)議用于標(biāo)定的工作機(jī)理,討論了利用CANape進(jìn)行基于CCP標(biāo)定的實(shí)現(xiàn)方法,闡述了如何生成CANape與控制器底層程序的軟件接口及具體標(biāo)定流程。實(shí)際應(yīng)用結(jié)果表明,這種方法可以快速有效地實(shí)現(xiàn)對(duì)汽車(chē)網(wǎng)絡(luò)中各控制器的匹配標(biāo)定。
| 關(guān)鍵詞：汽車(chē)電控單元 CAN總線(xiàn) CCP協(xié)議 標(biāo)定 CANape |
|
目前基于CAN(Controller Area Network)總線(xiàn)的分布式系統(tǒng)在汽車(chē)電子領(lǐng)域得到廣泛應(yīng)用,電子控制單元的標(biāo)定已成為汽車(chē)電子控制裝置開(kāi)發(fā)的一個(gè)重要環(huán)節(jié)。CCP(CAN Calibration Protocol)是一種基于CAN總線(xiàn)的ECU(Electronic Control Unit)標(biāo)定協(xié)議[1],已經(jīng)在許多歐美汽車(chē)廠(chǎng)商得到應(yīng)用,采用CCP協(xié)議可以快速而有效地實(shí)現(xiàn)對(duì)汽車(chē)電控單元的標(biāo)定。 然而基于CCP協(xié)議的標(biāo)定,需要在ECU內(nèi)部實(shí)現(xiàn)支持CCP協(xié)議的驅(qū)動(dòng)程序(CCP driver)。目前大多數(shù)應(yīng)用都采用Vector提供的free CCP driver[2]?？紤]到ECU底層程序與CAN驅(qū)動(dòng)程序的實(shí)現(xiàn)各不相同,將CCP驅(qū)動(dòng)程序結(jié)合到ECU中[3]并不是一件一蹴而就的事,這需要對(duì)CCP協(xié)議本身、標(biāo)定工具及標(biāo)定工具與ECU之間的通信有詳細(xì)和深入的了解。在整個(gè)標(biāo)定系統(tǒng)的開(kāi)發(fā)過(guò)程中,大量時(shí)間被耗費(fèi)在前期CCP驅(qū)動(dòng)程序與ECU結(jié)合上。本文在簡(jiǎn)單介紹CCP協(xié)議的基礎(chǔ)上,提供了一個(gè)通用的ECU與CCP驅(qū)動(dòng)程序結(jié)合的實(shí)例,以幫助縮短整個(gè)標(biāo)定開(kāi)發(fā)周期。 CANape[4]是一款ECU標(biāo)定和測(cè)試工具。與CCP協(xié)議相結(jié)合,不僅能完成對(duì)ECU的標(biāo)定,同時(shí)還能在ECU運(yùn)行期間直接訪(fǎng)問(wèn)內(nèi)存并進(jìn)行操作。這使得CANape不僅是一款功能強(qiáng)大的標(biāo)定工具,也是一款電控單元開(kāi)發(fā)的得力助手。然而在使用方面,CANape的前期配置比較繁瑣,目前國(guó)內(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作為一個(gè)應(yīng)用系統(tǒng)標(biāo)準(zhǔn)化工作小組,其目的在于提供通用軟、硬件接口標(biāo)準(zhǔn),以解決由于不同制造商提供的控制器存在的接口不匹配問(wèn)題。 1.1 CCP通信方式 基于CCP協(xié)議的ECU標(biāo)定采用主-從通信方式,如圖1。主設(shè)備通過(guò)CAN總線(xiàn)與多個(gè)從設(shè)備相連,其中主設(shè)備是測(cè)量標(biāo)定系統(tǒng)MCS(Measurement Calibration System),從設(shè)備是需要標(biāo)定的ECU,在汽車(chē)電子中即為車(chē)載控制器。  圖1 CCP通信方式 根據(jù)CCP協(xié)議,主設(shè)備首先與其中一個(gè)從設(shè)備建立邏輯鏈接,然后通過(guò)主設(shè)備向從設(shè)備發(fā)送命令來(lái)起始兩者間的數(shù)據(jù)通信。當(dāng)主設(shè)備要訪(fǎng)問(wèn)另一個(gè)從設(shè)備時(shí),首先斷開(kāi)與當(dāng)前從設(shè)備的邏輯連接,與下一個(gè)從設(shè)備建立新的邏輯連接后再開(kāi)始通信。 1.2 CCP協(xié)議的工作模式 CCP定義了兩種工作模式:Polling(查詢(xún))模式及DAQ(Data Acquisition Command)模式。查詢(xún)模式下,主設(shè)備與從設(shè)備間的每一次通信都由主設(shè)備發(fā)送命令來(lái)起始,從設(shè)備收到主設(shè)備的命令后,執(zhí)行相應(yīng)的操作并反饋一幀報(bào)文。這種工作模式由于需要主機(jī)與從機(jī)之間進(jìn)行“一問(wèn)一答”的信息交互,工作效率不高,但實(shí)現(xiàn)簡(jiǎn)單,而且占用ECU內(nèi)存資源較小。 DAQ模式使從設(shè)備可以脫離主設(shè)備的命令控制按一定周期自動(dòng)向主設(shè)備上傳數(shù)據(jù)。DAQ模式下,主設(shè)備首先發(fā)送一條請(qǐng)求DAQ的命令,從設(shè)備收到后,按命令中的參數(shù)自行配置并組織需要上傳的數(shù)據(jù),然后按一定周期自主向主設(shè)備上傳數(shù)據(jù)。這種模式由于不需要主機(jī)通過(guò)命令逐步控制,工作效率高,但實(shí)現(xiàn)較復(fù)雜,如果需要上傳的數(shù)據(jù)量很大,會(huì)占用大量ECU內(nèi)存空間。 1.3 CCP報(bào)文幀結(jié)構(gòu) 基于CCP協(xié)議的標(biāo)定只占用兩幀CAN報(bào)文,分別是命令接收對(duì)象CRO(Command Receive Object)和數(shù)據(jù)傳輸對(duì)象DTO(Data Transmission Object),如圖2所示。CRO由主設(shè)備發(fā)給從設(shè)備,DTO是從設(shè)備反饋的報(bào)文。兩者分別通過(guò)一個(gè)自己的ID標(biāo)識(shí)符進(jìn)行標(biāo)識(shí)(CRO_ID與DTO_ID)。  圖2 CCP協(xié)議主、從設(shè)備通信 CRO與DTO的ID標(biāo)識(shí)符由通信協(xié)議自行定義,CCP協(xié)議只對(duì)CRO及DTO的數(shù)據(jù)場(chǎng)做了詳細(xì)定義。按照CCP協(xié)議,CRO數(shù)據(jù)場(chǎng)的第1個(gè)字節(jié)為命令代碼CMD(Command Code),CCP協(xié)議共規(guī)定了28條命令[1]。從設(shè)備通過(guò)CMD代碼判斷主設(shè)備請(qǐng)求的是哪條命令。數(shù)據(jù)場(chǎng)的第2個(gè)字節(jié)是命令計(jì)數(shù)器CTR(Command Counter)。剩余6個(gè)字節(jié)均為命令參數(shù),每條命令有各自對(duì)應(yīng)的命令參數(shù)。 從設(shè)備反饋的報(bào)文稱(chēng)為DTO。按CCP協(xié)議,DTO又細(xì)分為三類(lèi): ·命令返回消息CRM(Command Return Message):由從設(shè)備發(fā)送,針對(duì)CRO的反饋報(bào)文。 ·事件消息(Event Message):當(dāng)從設(shè)備檢測(cè)到內(nèi)部發(fā)生錯(cuò)誤機(jī)制時(shí),由從設(shè)備自行向主設(shè)備發(fā)送,報(bào)告其當(dāng)前的運(yùn)行狀態(tài),并請(qǐng)求主設(shè)備暫停當(dāng)前工作進(jìn)程以處理發(fā)生的錯(cuò)誤。 ·DAQ-DTO(Data Acquisition-DTO):用在DAQ模式中,由從設(shè)備組織,定期向主設(shè)備發(fā)送。 DTO報(bào)文的第1個(gè)字節(jié)PID(Packet ID)定義了DTO的類(lèi)型,255代表CRM, 254代表事件消息。第2個(gè)字節(jié)為命令返回/錯(cuò)誤代碼ERR(Command Return-/Error Code)。對(duì)于CRM,主設(shè)備由該字節(jié)獲知命令的執(zhí)行情況;對(duì)于事件消息,主設(shè)備由該位獲知從設(shè)備內(nèi)部發(fā)生了哪種錯(cuò)誤。第3字節(jié)CTR是命令計(jì)數(shù)器,該位數(shù)值與其對(duì)應(yīng)的CRO的CTR值相對(duì)應(yīng)。剩余5個(gè)字節(jié)是數(shù)據(jù)場(chǎng),存放主設(shè)備請(qǐng)求的數(shù)據(jù)或信息。 2 基于CCP協(xié)議的接口程序?qū)崿F(xiàn) 基于CCP協(xié)議進(jìn)行標(biāo)定,需要MCS與ECU的應(yīng)用程序都能夠支持CCP協(xié)議,這部分應(yīng)用程序稱(chēng)為CCP driver。本文采用Vector提供的free CCP driver[2]。由于CCP協(xié)議基于CAN總線(xiàn),因此CCP driver與ECU的結(jié)合主要分為與CAN driver及與其他應(yīng)用程序兩方面。 CCP driver與CAN driver的結(jié)合如圖3,主要分為以下兩方面:  圖3 CCP標(biāo)定程序接口 ·發(fā)送端:DTO通過(guò)CAN driver的發(fā)送子函數(shù)以CAN報(bào)文的格式上傳給MCS。 ·接收端:主設(shè)備發(fā)送的命令以CAN報(bào)文的格式首先進(jìn)入CAN driver的接收子函數(shù),由其判斷為CRO后,進(jìn)一步交給命令處理器處理。 命令處理器作為CCP driver的一個(gè)主要組成部分,負(fù)責(zé)將接收到的CRO,通過(guò)其CRM代碼進(jìn)行命令解釋,執(zhí)行相應(yīng)操作,組織反饋數(shù)據(jù)并調(diào)用CAN發(fā)送子函數(shù)。DAQ處理器支持DAQ工作模式,當(dāng)命令處理器判斷收到的命令為DAQ請(qǐng)求后,進(jìn)一步將數(shù)據(jù)傳給DAQ處理器,由DAQ處理器組織數(shù)據(jù)并直接調(diào)用CAN 發(fā)送子函數(shù),以DAQ-DTO的形式定期向主設(shè)備上傳。 基于CCP協(xié)議的基本CAN通信流程如圖4所示。ECU接收到報(bào)文后,轉(zhuǎn)入CAN接收子函數(shù),在常規(guī)接收流程后,對(duì)報(bào)文的ID標(biāo)識(shí)符進(jìn)行判斷,如為CRO_ID,則將CCP標(biāo)志位(Ccp_indicator)置位。由于采用中斷方式接收?qǐng)?bào)文,為了避免占用過(guò)多中斷時(shí)間而影響其他函數(shù)或中斷級(jí)別較低的程序運(yùn)行,在對(duì)ID標(biāo)識(shí)符進(jìn)行判斷后,并不直接在函數(shù)中調(diào)用CCP driver的命令處理器。命令處理器的調(diào)用會(huì)在主函數(shù)中進(jìn)行。  圖4 接口程序基本流程圖 主函數(shù)通過(guò)判斷標(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()通過(guò)調(diào)用CAN driver中的CCP發(fā)送子函數(shù)ccpSend()發(fā)送一幀DTO。ccpSend()須在CAN driver中實(shí)現(xiàn),由CCP driver調(diào)用。按實(shí)際情況,將CAN發(fā)送子函數(shù)直接以ccpSend()的形式實(shí)現(xiàn),或在保留原有發(fā)送子函數(shù)的基礎(chǔ)上添加一個(gè)ccpSend()子函數(shù),在其中調(diào)用CAN發(fā)送子函數(shù),以完成DTO的發(fā)送。 CCP協(xié)議為確保主設(shè)備與ECU之間正常通信,每次發(fā)送后,程序必須通過(guò)調(diào)用CCP driver中的ccpSendCallback()子函數(shù)檢查剛才的DTO是否已經(jīng)發(fā)送,否則不能發(fā)送下一幀報(bào)文。針對(duì)不同的CAN driver實(shí)現(xiàn),該函數(shù)調(diào)用的位置不同。最后主函數(shù)將CCP標(biāo)志位清空,等待下一條CRO命令。 一個(gè)完整的CCP driver 接口還包括與ECU其他應(yīng)用程序的接口。每次單片機(jī)初始化后,主函數(shù)調(diào)用一次CCP driver的CCP初始化子函數(shù)ccpInit(),將上次標(biāo)定殘留在ECU內(nèi)存中的數(shù)據(jù)清空,為下次標(biāo)定與測(cè)量做準(zhǔn)備。 CCP協(xié)議共定義了28條命令,每條命令在CCP driver中都對(duì)應(yīng)一組相應(yīng)的子函數(shù),代表不同的功能,如EEPROM標(biāo)定、DAQ工作模式等。用戶(hù)可根據(jù)實(shí)際需要,選擇實(shí)現(xiàn)其中部分或全部功能。每增加一個(gè)新的功能,必須在底層程序中添加開(kāi)放該項(xiàng)功能的程序接口[3]。如對(duì)EEPROM標(biāo)定,首先ECU應(yīng)用程序中應(yīng)包含EEPROM模塊子函數(shù),同時(shí)還需實(shí)現(xiàn)命令處理器與EEPROM模塊之間的調(diào)用接口。 3 利用CANape實(shí)現(xiàn)基于CCP的標(biāo)定 CANape[4]是德國(guó)Vector公司出品的一款基于ASAP標(biāo)準(zhǔn)的ECU測(cè)試和標(biāo)定工具。它通過(guò)一個(gè)控制器硬件接口與ECU相連,兩者之間常用的物理連接是基于CCP協(xié)議的CAN總線(xiàn)。只有控制器的底層程序中有支持CCP協(xié)議的程序接口, CANape才能與控制器通信。 CANape提供了多種功能:在線(xiàn)數(shù)據(jù)評(píng)估、離線(xiàn)評(píng)估、數(shù)據(jù)管理、FLASH編程、參數(shù)標(biāo)定及ASAP2數(shù)據(jù)編輯器等。此外,測(cè)試過(guò)程中由CAN總線(xiàn)上傳的數(shù)據(jù)還可以通過(guò)CANape在計(jì)算機(jī)顯示和保存,以進(jìn)行離線(xiàn)標(biāo)定和數(shù)據(jù)評(píng)估。 3.1 ASAP2控制器描述文件及ASAP2編輯器 CANape與控制器間的通信需要一個(gè)描述文件支持,這個(gè)文件稱(chēng)為ASAP2控制器描述文件[4]。CANape對(duì)控制器的參數(shù)標(biāo)定和數(shù)據(jù)測(cè)量都是基于這個(gè)文件,該文件記錄了控制器中各參數(shù)的詳細(xì)信息,如標(biāo)定參數(shù)和測(cè)量變量在控制器中的存儲(chǔ)地址、存儲(chǔ)結(jié)構(gòu)、數(shù)據(jù)類(lèi)型和轉(zhuǎn)換公式等。在CANape中,每個(gè)標(biāo)定參數(shù)和測(cè)量數(shù)據(jù)都會(huì)有一個(gè)變量名,如發(fā)動(dòng)機(jī)溫度、冷卻水溫度。當(dāng)CANape需要訪(fǎng)問(wèn)某個(gè)變量,就在ASAP2描述文件中根據(jù)變量名,找到該變量在控制器中的存儲(chǔ)地址、數(shù)據(jù)長(zhǎng)度等信息,然后進(jìn)行操作,如圖5。  圖5 ASAP2控制器描述文件 為了方便用戶(hù)對(duì)ASAP2文件進(jìn)行維護(hù)和修改,CANape集成了一個(gè)ASAP2數(shù)據(jù)庫(kù)編輯器,用以生成和修改ASAP2控制器描述文件。所有的信息都能通過(guò)對(duì)話(huà)框的形式進(jìn)行設(shè)置和修改。該數(shù)據(jù)庫(kù)編輯器還能工作在獨(dú)立模式下,以生成一個(gè)ASAP2格式的控制器描述文件。 當(dāng)ECU底層程序修改后,一些標(biāo)定參數(shù)和測(cè)量數(shù)據(jù)的內(nèi)存地址可能發(fā)生變動(dòng),CANape雖然仍能進(jìn)行標(biāo)定,但修改的已不是原來(lái)需要標(biāo)定的參數(shù),而是程序變動(dòng)后原先地址下當(dāng)前存放的某個(gè)新的未知數(shù)據(jù)。為了簡(jiǎn)化手工修改地址的繁瑣,防止因?yàn)殡S意修改某個(gè)數(shù)據(jù)而破壞程序的正常運(yùn)行,CANape支持通過(guò)linker map文件自動(dòng)更新ASAP2文件里的信息。Map文件是ECU底層程序在編譯時(shí)由編譯器生成的一種映射文件,通過(guò)Map文件可以自動(dòng)更新ASAP2文件。 3.2 CANape使用配置 每個(gè)需要標(biāo)定的ECU都要在CANape中進(jìn)行配置。 CANape共定義了28條命令,用以實(shí)現(xiàn)不同的功能,在配置頁(yè)面里均有復(fù)選框與其對(duì)應(yīng)?？刂破鞯呐渲帽仨毰cCCP Driver在ECU底層程序的具體實(shí)現(xiàn)相匹配,只有對(duì)某個(gè)功能的程序接口已經(jīng)開(kāi)放,才能在CANape中選擇使用該項(xiàng)功能[2][5]。 3.3 CANape中的參數(shù)標(biāo)定 在CANape中,需要標(biāo)定的變量稱(chēng)為標(biāo)定參數(shù),CANape將標(biāo)定定義為修改駐扎在ECU內(nèi)存中的變量的內(nèi)容。CANape支持多種標(biāo)定方法。這里標(biāo)定方法指如何對(duì)標(biāo)定參數(shù)所在的內(nèi)存區(qū)域進(jìn)行初始化、數(shù)據(jù)改寫(xiě)及保存。根據(jù)標(biāo)定參數(shù)所在不同地址空間(ROM、FLASH或EEPROM),CANape規(guī)定了不同的標(biāo)定方法。 當(dāng)標(biāo)定參數(shù)需要存放在FLASH或ROM中時(shí),在ECU上電初始化后,程序首先將標(biāo)定參數(shù)的初始值復(fù)制到RAM中,在CANape中該段用來(lái)存放標(biāo)定參數(shù)的RAM稱(chēng)為Calibration RAM。標(biāo)定過(guò)程中,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。此外,也可對(duì)EEPROM中的參數(shù)直接進(jìn)行改寫(xiě),實(shí)現(xiàn)這種方法需要對(duì)EEPROM進(jìn)行頻繁擦寫(xiě)操作,但不占用額外的RAM空間。 由于汽車(chē)電子網(wǎng)絡(luò)系統(tǒng)已開(kāi)始得到廣泛的使用,基于網(wǎng)絡(luò)連接的電子控制單元的匹配標(biāo)定和傳統(tǒng)的匹配標(biāo)定方法已有了很大的不同,特別是基于CAN總線(xiàn)的匹配標(biāo)定技術(shù),目前已成為研究和應(yīng)用的重點(diǎn)。 采用CANape進(jìn)行基于CCP的匹配標(biāo)定,實(shí)現(xiàn)了標(biāo)定工具和內(nèi)容的統(tǒng)一。根據(jù)這種方法能夠快速有效地進(jìn)行汽車(chē)電子控制單元的匹配標(biāo)定,在實(shí)際開(kāi)發(fā)應(yīng)用中取得了良好的效果。 |
工商網(wǎng)監(jiān)
評(píng)論