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

摘　要：采用基于CAN總線(xiàn)的匹配標定協(xié)議,對汽車(chē)控制器局域網(wǎng)絡(luò )中的電子控制單元進(jìn)行匹配標定。分析了CCP協(xié)議用于標定的工作機理,討論了利用CANape進(jìn)行基于CCP標定的實(shí)現方法,闡述了如何生成CANape與控制器底層程序的軟件接口及具體標定流程。實(shí)際應用結果表明,這種方法可以快速有效地實(shí)現對汽車(chē)網(wǎng)絡(luò )中各控制器的匹配標定。

關(guān)鍵詞：汽車(chē)電控單元 CAN總線(xiàn) CCP協(xié)議 標定 CANape

目前基于CAN(Controller Area Network)總線(xiàn)的分布式系統在汽車(chē)電子領(lǐng)域得到廣泛應用,電子控制單元的標定已成為汽車(chē)電子控制裝置開(kāi)發(fā)的一個(gè)重要環(huán)節。CCP(CAN Calibration Protocol)是一種基于CAN總線(xiàn)的ECU(Electronic Control Unit)標定協(xié)議[1],已經(jīng)在許多歐美汽車(chē)廠(chǎng)商得到應用,采用CCP協(xié)議可以快速而有效地實(shí)現對汽車(chē)電控單元的標定。
 
然而基于CCP協(xié)議的標定,需要在ECU內部實(shí)現支持CCP協(xié)議的驅動(dòng)程序(CCP driver)。目前大多數應用都采用Vector提供的free CCP driver[2]?？紤]到ECU底層程序與CAN驅動(dòng)程序的實(shí)現各不相同,將CCP驅動(dòng)程序結合到ECU中[3]并不是一件一蹴而就的事,這需要對CCP協(xié)議本身、標定工具及標定工具與ECU之間的通信有詳細和深入的了解。在整個(gè)標定系統的開(kāi)發(fā)過(guò)程中,大量時(shí)間被耗費在前期CCP驅動(dòng)程序與ECU結合上。本文在簡(jiǎn)單介紹CCP協(xié)議的基礎上,提供了一個(gè)通用的ECU與CCP驅動(dòng)程序結合的實(shí)例,以幫助縮短整個(gè)標定開(kāi)發(fā)周期。
 
CANape[4]是一款ECU標定和測試工具。與CCP協(xié)議相結合,不僅能完成對ECU的標定,同時(shí)還能在ECU運行期間直接訪(fǎng)問(wèn)內存并進(jìn)行操作。這使得CANape不僅是一款功能強大的標定工具,也是一款電控單元開(kāi)發(fā)的得力助手。然而在使用方面,CANape的前期配置比較繁瑣,目前國內的相關(guān)資料較少。本文將介紹CANape,并著(zhù)眼于如何基于CCP協(xié)議使用CANape完成ECU的標定。

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

CCP協(xié)議是ASAP(Arbeitskreis zur Standardisierung von Applikationssystemen)標志的有機組成部分。ASAP作為一個(gè)應用系統標準化工作小組,其目的在于提供通用軟、硬件接口標準,以解決由于不同制造商提供的控制器存在的接口不匹配問(wèn)題。

1.1 CCP通信方式

基于CCP協(xié)議的ECU標定采用主-從通信方式,如圖1。主設備通過(guò)CAN總線(xiàn)與多個(gè)從設備相連,其中主設備是測量標定系統MCS(Measurement Calibration System),從設備是需要標定的ECU,在汽車(chē)電子中即為車(chē)載控制器。

圖1 CCP通信方式

根據CCP協(xié)議,主設備首先與其中一個(gè)從設備建立邏輯鏈接,然后通過(guò)主設備向從設備發(fā)送命令來(lái)起始兩者間的數據通信。當主設備要訪(fǎng)問(wèn)另一個(gè)從設備時(shí),首先斷開(kāi)與當前從設備的邏輯連接,與下一個(gè)從設備建立新的邏輯連接后再開(kāi)始通信。

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

1.3 CCP報文幀結構

基于CCP協(xié)議的標定只占用兩幀CAN報文,分別是命令接收對象CRO(Command Receive Object)和數據傳輸對象DTO(Data Transmission Object),如圖2所示。CRO由主設備發(fā)給從設備,DTO是從設備反饋的報文。兩者分別通過(guò)一個(gè)自己的ID標識符進(jìn)行標識(CRO_ID與DTO_ID)。

圖2 CCP協(xié)議主、從設備通信

CRO與DTO的ID標識符由通信協(xié)議自行定義,CCP協(xié)議只對CRO及DTO的數據場(chǎng)做了詳細定義。按照CCP協(xié)議,CRO數據場(chǎng)的第1個(gè)字節為命令代碼CMD(Command Code),CCP協(xié)議共規定了28條命令[1]。從設備通過(guò)CMD代碼判斷主設備請求的是哪條命令。數據場(chǎng)的第2個(gè)字節是命令計數器CTR(Command Counter)。剩余6個(gè)字節均為命令參數,每條命令有各自對應的命令參數。

從設備反饋的報文稱(chēng)為DTO。按CCP協(xié)議,DTO又細分為三類(lèi):