基于caname的汽車控制器ccp標(biāo)定

目前，以控制區(qū)域網(wǎng)絡(luò)為基礎(chǔ)的分割系統(tǒng)（co）在電子車輛行業(yè)得到了廣泛應(yīng)用。電子控制單元的測量是電子控制裝置發(fā)展的重要組成部分。CCP(CANCalibrationProtocol）是一種基于CAN總線的ECU(ElectronicControlUnit）標(biāo)定協(xié)議，已經(jīng)在許多歐美汽車廠商得到應(yīng)用，采用CCP協(xié)議可以快速而有效地實現(xiàn)對汽車電控單元的標(biāo)定。然而基于CCP協(xié)議的標(biāo)定，需要在ECU內(nèi)部實現(xiàn)支持CCP協(xié)議的驅(qū)動程序（CCPdriver）。目前大多數(shù)應(yīng)用都采用Vector提供的freeCCPdriver。考慮到ECU底層程序與CAN驅(qū)動程序的實現(xiàn)各不相同，將CCP驅(qū)動程序結(jié)合到ECU中并不是一件一蹴而就的事，這需要對CCP協(xié)議本身、標(biāo)定工具及標(biāo)定工具與ECU之間的通信有詳細和深入的了解。在整個標(biāo)定系統(tǒng)的開發(fā)過程中，大量時間被耗費在前期CCP驅(qū)動程序與ECU結(jié)合上。本文在簡單介紹CCP協(xié)議的基礎(chǔ)上，提供了一個通用的ECU與CCP驅(qū)動程序結(jié)合的實例，以幫助縮短整個標(biāo)定開發(fā)周期。CANape是一款ECU標(biāo)定和測試工具。與CCP協(xié)議相結(jié)合，不僅能完成對ECU的標(biāo)定，同時還能在ECU運行期間直接訪問內(nèi)存并進行操作。這使得CANape不僅是一款功能強大的標(biāo)定工具，也是一款電控單元開發(fā)的得力助手。然而在使用方面，CANape的前期配置比較繁瑣，目前國內(nèi)的相關(guān)資料較少。本文將介紹CANape，并著眼于如何基于CCP協(xié)議使用CANape完成ECU的標(biāo)定。1有機組成部分CCP協(xié)議是ASAP(ArbeitskreiszurStandardisierungvonApplikationssystemen）標(biāo)志的有機組成部分。ASAP作為一個應(yīng)用系統(tǒng)標(biāo)準(zhǔn)化工作小組，其目的在于提供通用軟、硬件接口標(biāo)準(zhǔn)，以解決由于不同制造商提供的控制器存在的接口不匹配問題。1.1ccp協(xié)議的原理基于CCP協(xié)議的ECU標(biāo)定采用主-從通信方式，如圖1。主設(shè)備通過CAN總線與多個從設(shè)備相連，其中主設(shè)備是測量標(biāo)定系統(tǒng)MCS(MeasurementCalibrationSystem），從設(shè)備是需要標(biāo)定的ECU，在汽車電子中即為車載控制器。根據(jù)CCP協(xié)議，主設(shè)備首先與其中一個從設(shè)備建立邏輯鏈接，然后通過主設(shè)備向從設(shè)備發(fā)送命令來起始兩者間的數(shù)據(jù)通信。當(dāng)主設(shè)備要訪問另一個從設(shè)備時，首先斷開與當(dāng)前從設(shè)備的邏輯連接，與下一個從設(shè)備建立新的邏輯連接后再開始通信。1.2daq模式下的工作模式CCP定義了兩種工作模式：Polling（查詢）模式及DAQ(DataAcquisitionCommand）模式。查詢模式下，主設(shè)備與從設(shè)備間的每一次通信都由主設(shè)備發(fā)送命令來起始，從設(shè)備收到主設(shè)備的命令后，執(zhí)行相應(yīng)的操作并反饋一幀報文。這種工作模式由于需要主機與從機之間進行“一問一答”的信息交互，工作效率不高，但實現(xiàn)簡單，而且占用ECU內(nèi)存資源較小。DAQ模式使從設(shè)備可以脫離主設(shè)備的命令控制按一定周期自動向主設(shè)備上傳數(shù)據(jù)。DAQ模式下，主設(shè)備首先發(fā)送一條請求DAQ的命令，從設(shè)備收到后，按命令中的參數(shù)自行配置并組織需要上傳的數(shù)據(jù)，然后按一定周期自主向主設(shè)備上傳數(shù)據(jù)。這種模式由于不需要主機通過命令逐步控制，工作效率高，但實現(xiàn)較復(fù)雜，如果需要上傳的數(shù)據(jù)量很大，會占用大量ECU內(nèi)存空間。1.3ccp協(xié)議關(guān)于dto的定義基于CCP協(xié)議的標(biāo)定只占用兩幀CAN報文，分別是命令接收對象CRO(CommandReceiveObject）和數(shù)據(jù)傳輸對象DTO(DataTransmissionObject），如圖2所示。CRO由主設(shè)備發(fā)給從設(shè)備，DTO是從設(shè)備反饋的報文。兩者分別通過一個自己的ID標(biāo)識符進行標(biāo)識（CRO＿ID與DTO＿ID）。CRO與DTO的ID標(biāo)識符由通信協(xié)議自行定義，CCP協(xié)議只對CRO及DTO的數(shù)據(jù)場做了詳細定義。按照CCP協(xié)議，CRO數(shù)據(jù)場的第1個字節(jié)為命令代碼CMD(CommandCode),CCP協(xié)議共規(guī)定了28條命令。從設(shè)備通過CMD代碼判斷主設(shè)備請求的是哪條命令。數(shù)據(jù)場的第2個字節(jié)是命令計數(shù)器CTR(CommandCounter）。剩余6個字節(jié)均為命令參數(shù)，每條命令有各自對應(yīng)的命令參數(shù)。從設(shè)備反饋的報文稱為DTO。按CCP協(xié)議，DTO又細分為三類：·命令返回消息CRM(CommandReturnMessage）：由從設(shè)備發(fā)送，針對CRO的反饋報文?！な录ⅲ‥ventMessage）：當(dāng)從設(shè)備檢測到內(nèi)部發(fā)生錯誤機制時，由從設(shè)備自行向主設(shè)備發(fā)送，報告其當(dāng)前的運行狀態(tài)，并請求主設(shè)備暫停當(dāng)前工作進程以處理發(fā)生的錯誤?！AQ-DTO(DataAcquisition-DTO）：用在DAQ模式中，由從設(shè)備組織，定期向主設(shè)備發(fā)送。DTO報文的第1個字節(jié)PID(PacketID）定義了DTO的類型，255代表CRM,254代表事件消息。第2個字節(jié)為命令返回/錯誤代碼ERR(CommandReturn-/ErrorCode）。對于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ù)或信息。2ccp協(xié)議的基本程序基于CCP協(xié)議進行標(biāo)定，需要MCS與ECU的應(yīng)用程序都能夠支持CCP協(xié)議，這部分應(yīng)用程序稱為CCPdriver。本文采用Vector提供的freeCCPdriver。由于CCP協(xié)議基于CAN總線，因此CCPdriver與ECU的結(jié)合主要分為與CANdriver及與其他應(yīng)用程序兩方面。CCPdriver與CANdriver的結(jié)合如圖3，主要分為以下兩方面：·發(fā)送端：DTO通過CANdriver的發(fā)送子函數(shù)以CAN報文的格式上傳給MCS?！そ邮斩耍褐髟O(shè)備發(fā)送的命令以CAN報文的格式首先進入CANdriver的接收子函數(shù)，由其判斷為CRO后，進一步交給命令處理器處理。命令處理器作為CCPdriver的一個主要組成部分，負責(zé)將接收到的CRO，通過其CRM代碼進行命令解釋，執(zhí)行相應(yīng)操作，組織反饋數(shù)據(jù)并調(diào)用CAN發(fā)送子函數(shù)。DAQ處理器支持DAQ工作模式，當(dāng)命令處理器判斷收到的命令為DAQ請求后，進一步將數(shù)據(jù)傳給DAQ處理器，由DAQ處理器組織數(shù)據(jù)并直接調(diào)用CAN發(fā)送子函數(shù)，以DAQ-DTO的形式定期向主設(shè)備上傳?；贑CP協(xié)議的基本CAN通信流程如圖4所示。ECU接收到報文后，轉(zhuǎn)入CAN接收子函數(shù)，在常規(guī)接收流程后，對報文的ID標(biāo)識符進行判斷，如為CRO＿ID，則將CCP標(biāo)志位（Ccp＿indicator）置位。由于采用中斷方式接收報文，為了避免占用過多中斷時間而影響其他函數(shù)或中斷級別較低的程序運行，在對ID標(biāo)識符進行判斷后，并不直接在函數(shù)中調(diào)用CCPdriver的命令處理器。命令處理器的調(diào)用會在主函數(shù)中進行。主函數(shù)通過判斷標(biāo)志位的狀態(tài)，調(diào)用CCPdriver的ccpCommand()子函數(shù)。該函數(shù)是命令處理器的主要組成部分，也是命令處理器與CANdriver的接口函數(shù)，它負責(zé)解釋并執(zhí)行收到的CRO命令，調(diào)用CCPdriver中的其他函數(shù)，進行數(shù)據(jù)處理并組織需要反饋的數(shù)據(jù)。ccpCommand()通過調(diào)用CANdriver中的CCP發(fā)送子函數(shù)ccpSend（）發(fā)送一幀DTO。ccpSend（）須在CANdriver中實現(xiàn)，由CCPdriver調(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)用CCPdriver中的ccpSendCallback()子函數(shù)檢查剛才的DTO是否已經(jīng)發(fā)送，否則不能發(fā)送下一幀報文。針對不同的CANdriver實現(xiàn)，該函數(shù)調(diào)用的位置不同。最后主函數(shù)將CCP標(biāo)志位清空，等待下一條CRO命令。一個完整的CCPdriver接口還包括與ECU其他應(yīng)用程序的接口。每次單片機初始化后，主函數(shù)調(diào)用一次CCPdriver的CCP初始化子函數(shù)ccpInit()，將上次標(biāo)定殘留在ECU內(nèi)存中的數(shù)據(jù)清空，為下次標(biāo)定與測量做準(zhǔn)備。CCP協(xié)議共定義了28條命令，每條命令在CCPdriver中都對應(yīng)一組相應(yīng)的子函數(shù)，代表不同的功能，如EEPROM標(biāo)定、DAQ工作模式等。用戶可根據(jù)實際需要，選擇實現(xiàn)其中部分或全部功能。每增加一個新的功能，必須在底層程序中添加開放該項功能的程序接口。如對EEPROM標(biāo)定，首先ECU應(yīng)用程序中應(yīng)包含EEPROM模塊子函數(shù)，同時還需實現(xiàn)命令處理器與EEPROM模塊之間的調(diào)用接口。3ccp協(xié)議與canpr接CANape是德國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在計算機顯示和保存，以進行離線標(biāo)定和數(shù)據(jù)評估。3.1canpe通過數(shù)據(jù)庫模塊更新數(shù)據(jù)文件CANape與控制器間的通信需要一個描述文件支持，這個文件稱為ASAP2控制器描述文件。CANape對控制器的參數(shù)標(biāo)定和數(shù)據(jù)測量都是基于這個文件，該文件記錄了控制器中各參數(shù)的詳細信息，如標(biāo)定參數(shù)和測量變量在控制器中的存儲地址、存儲結(jié)構(gòu)、數(shù)據(jù)類型和轉(zhuǎn)換公式等。在CANape中，每個標(biāo)定參數(shù)和測量數(shù)據(jù)都會有一個變量名，如發(fā)動機溫度、冷卻水溫度。當(dāng)CANape需要訪問某個變量，就在ASAP2描述文件中根據(jù)變量名，找到該變量在控制器中的存儲地址、數(shù)據(jù)長度等信息，然后進行操作，如圖5。為了方便用戶對ASAP2文件進行維護和修改，CANape集成了一個ASAP2數(shù)據(jù)庫編輯器，用以生成和修改ASAP2控制器描述文件。所有的信息都能通過對話框的形式進行設(shè)置和修改。該數(shù)據(jù)庫編輯器還能工作在獨立模式下，以生成一個ASAP2格式的控制器描述文件。當(dāng)ECU底層程序修改后，一些標(biāo)定參數(shù)和測量數(shù)據(jù)的內(nèi)存地址可能發(fā)生變動，CANape雖然仍能進行標(biāo)定，但修改的已不是原來需要標(biāo)定的參數(shù)，而是程序變動后原先地址下當(dāng)前存放的某個新的未知數(shù)據(jù)。為了簡化手工修改地址的繁瑣，防止因為隨意修改某個數(shù)據(jù)而破壞程序的正常運行，CANape支持通過linkermap文件自動更新ASAP2文件里的信息。Map文件是ECU底層程序在編譯時由編譯器生成的一種映射文件，通過Map文件可以自動更新ASAP2文件。3.2復(fù)選框命令的實現(xiàn)每個需要標(biāo)定的ECU都要在CANape中進行配置。CANape共定義了28條命令，用以實現(xiàn)不同的功能，在配置頁面里均有復(fù)選框與其對應(yīng)?？刂破鞯呐渲帽仨毰cCCPDriver在ECU底層程序的具體實現(xiàn)相匹配，只有對某個功能的程序接口已經(jīng)開放，才能在CANape中選擇使用該項功能。3.3cali-rom中的標(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ū)域進行初始化、數(shù)據(jù)改寫及保存。根據(jù)標(biāo)定參數(shù)所在不同地址空間（ROM、FLASH或EEPROM),CANape規(guī)定了不同的標(biāo)定方法。當(dāng)標(biāo)定參數(shù)需要存放在FLASH或ROM中時，在E-CU上電初始化后，程序首先將標(biāo)定參數(shù)的初始值復(fù)制到RAM中，在CANape中該段用來存放標(biāo)定參數(shù)的RAM稱為CalibrationRAM。標(biāo)定過程中，CANape修改CalibrationRAM中的參數(shù)值。標(biāo)定全部結(jié)束后，再將該段RAM中的內(nèi)容復(fù)制回FLASH或ROM中。當(dāng)標(biāo)定參數(shù)存放在EEPROM中，有兩種標(biāo)定方法。第一種與上述方法相同，首先將標(biāo)