目前基于CAN（Controller Area Network）總線的分布式系統在汽車電子領域得到廣泛應用，電子控制單元的標定已成為汽車電子控制裝置開發的一個重要環節。CCP（CAN Calibration Protocol）是一種基于CAN總線的ECU（Electronic Control Unit）標定協議［1］，已經在許多歐美汽車廠商得到應用，采用CCP協議可以快速而有效地實現對汽車電控單元的標定。

　　然而基于CCP協議的標定，需要在ECU內部實現支持CCP協議的驅動程序（CCP driver）。目前大多數應用都采用Vector提供的free CCP driver［2］。考慮到ECU底層程序與CAN驅動程序的實現各不相同，將CCP驅動程序結合到ECU中［3］并不是一件一蹴而就的事，這需要對CCP協議本身、標定工具及標定工具與ECU之間的通信有詳細和深入的了解。在整個標定系統的開發過程中，大量時間被耗費在前期CCP驅動程序與ECU結合上。本文在簡單介紹CCP協議的基礎上，提供了一個通用的ECU與CCP驅動程序結合的實例，以幫助縮短整個標定開發周期。

　　CANape［4］是一款ECU標定和測試工具。與CCP協議相結合，不僅能完成對ECU的標定，同時還能在ECU運行期間直接訪問內存并進行操作。這使得CANape不僅是一款功能強大的標定工具，也是一款電控單元開發的得力助手。然而在使用方面，CANape的前期配置比較繁瑣，目前國內的相關資料較少。本文將介紹CANape，并著眼于如何基于CCP協議使用CANape完成ECU的標定。

　　1 CCP協議及工作原理

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

　　1.1 CCP通信方式

　　基于CCP協議的ECU標定采用主-從通信方式，如圖1.主設備通過CAN總線與多個從設備相連，其中主設備是測量標定系統MCS（Measurement Calibration System），從設備是需要標定的ECU，在汽車電子中即為車載控制器。

　　圖1 CCP通信方式

　　根據CCP協議，主設備首先與其中一個從設備建立邏輯鏈接，然后通過主設備向從設備發送命令來起始兩者間的數據通信。當主設備要訪問另一個從設備時，首先斷開與當前從設備的邏輯連接，與下一個從設備建立新的邏輯連接后再開始通信。

　　1.2 CCP協議的工作模式

　　CCP定義了兩種工作模式：Polling（查詢）模式及DAQ（Data Acquisition Command）模式。查詢模式下，主設備與從設備間的每一次通信都由主設備發送命令來起始，從設備收到主設備的命令后，執行相應的操作并反饋一幀報文。這種工作模式由于需要主機與從機之間進行“一問一答”的信息交互，工作效率不高，但實現簡單，而且占用ECU內存資源較小。 DAQ模式使從設備可以脫離主設備的命令控制按一定周期自動向主設備上傳數據。DAQ模式下，主設備首先發送一條請求DAQ的命令，從設備收到后，按命令中的參數自行配置并組織需要上傳的數據，然后按一定周期自主向主設備上傳數據。這種模式由于不需要主機通過命令逐步控制，工作效率高，但實現較復雜，如果需要上傳的數據量很大，會占用大量ECU內存空間。

　　1.3 CCP報文幀結構

　　基于CCP協議的標定只占用兩幀CAN報文，分別是命令接收對象CRO（Command Receive Object）和數據傳輸對象DTO（Data Transmission Object），如圖2所示。CRO由主設備發給從設備，DTO是從設備反饋的報文。兩者分別通過一個自己的ID標識符進行標識（CRO_ID與DTO_ID）。

　　圖2 CCP協議主、從設備通信

　　CRO與DTO的ID標識符由通信協議自行定義，CCP協議只對CRO及DTO的數據場做了詳細定義。按照CCP協議，CRO數據場的第1個字節為命令代碼CMD（Command Code），CCP協議共規定了28條命令［1］。從設備通過CMD代碼判斷主設備請求的是哪條命令。數據場的第2個字節是命令計數器CTR（Command Counter）。剩余6個字節均為命令參數，每條命令有各自對應的命令參數。

　　從設備反饋的報文稱為DTO.按CCP協議，DTO又細分為三類：

　　·命令返回消息CRM（Command Return Message）：由從設備發送，針對CRO的反饋報文。

　　·事件消息（Event Message）：當從設備檢測到內部發生錯誤機制時，由從設備自行向主設備發送，報告其當前的運行狀態，并請求主設備暫停當前工作進程以處理發生的錯誤。

　　·DAQ-DTO（Data Acquisition-DTO）：用在DAQ模式中，由從設備組織，定期向主設備發送。

　　DTO報文的第1個字節PID（Packet ID）定義了DTO的類型，255代表CRM， 254代表事件消息。第2個字節為命令返回/錯誤代碼ERR（Command Return-/Error Code）。對于CRM，主設備由該字節獲知命令的執行情況；對于事件消息，主設備由該位獲知從設備內部發生了哪種錯誤。第3字節CTR是命令計數器，該位數值與其對應的CRO的CTR值相對應。剩余5個字節是數據場，存放主設備請求的數據或信息。

　　2 基于CCP協議的接口程序實現

　　基于CCP協議進行標定，需要MCS與ECU的應用程序都能夠支持CCP協議，這部分應用程序稱為CCP driver.本文采用Vector提供的free CCP driver［2］。由于CCP協議基于CAN總線，因此CCP driver與ECU的結合主要分為與CAN driver及與其他應用程序兩方面。

　　CCP driver與CAN driver的結合如圖3，主要分為以下兩方面：

　　圖3 CCP標定程序接口

　　·發送端：DTO通過CAN driver的發送子函數以CAN報文的格式上傳給MCS.

　　·接收端：主設備發送的命令以CAN報文的格式首先進入CAN driver的接收子函數，由其判斷為CRO后，進一步交給命令處理器處理。

　　命令處理器作為CCP driver的一個主要組成部分，負責將接收到的CRO，通過其CRM代碼進行命令解釋，執行相應操作，組織反饋數據并調用CAN發送子函數。DAQ處理器支持DAQ工作模式，當命令處理器判斷收到的命令為DAQ請求后，進一步將數據傳給DAQ處理器，由DAQ處理器組織數據并直接調用CAN 發送子函數，以DAQ-DTO的形式定期向主設備上傳。

　　基于CCP協議的基本CAN通信流程如圖4所示。ECU接收到報文后，轉入CAN接收子函數，在常規接收流程后，對報文的ID標識符進行判斷，如為CRO_ID，則將CCP標志位（Ccp_indicator）置位。由于采用中斷方式接收報文，為了避免占用過多中斷時間而影響其他函數或中斷級別較低的程序運行，在對ID標識符進行判斷后，并不直接在函數中調用CCP driver的命令處理器。命令處理器的調用會在主函數中進行。

　　圖4 接口程序基本流程圖

　　主函數通過判斷標志位的狀態，調用CCP driver的ccpCommand（）子函數。該函數是命令處理器的主要組成部分，也是命令處理器與CAN driver的接口函數，它負責解釋并執行收到的CRO命令，調用CCP driver中的其他函數，進行數據處理并組織需要反饋的數據。

　　ccpCommand（）通過調用CAN driver中的CCP發送子函數ccpSend（）發送一幀DTO.ccpSend（）須在CAN driver中實現，由CCP driver調用。按實際情況，將CAN發送子函數直接以ccpSend（）的形式實現，或在保留原有發送子函數的基礎上添加一個ccpSend（）子函數，在其中調用CAN發送子函數，以完成DTO的發送。

　　CCP協議為確保主設備與ECU之間正常通信，每次發送后，程序必須通過調用CCP driver中的ccpSendCallback（）子函數檢查剛才的DTO是否已經發送，否則不能發送下一幀報文。針對不同的CAN driver實現，該函數調用的位置不同。最后主函數將CCP標志位清空，等待下一條CRO命令。

　　一個完整的CCP driver 接口還包括與ECU其他應用程序的接口。每次單片機初始化后，主函數調用一次CCP driver的CCP初始化子函數ccpInit（），將上次標定殘留在ECU內存中的數據清空，為下次標定與測量做準備。

　　CCP協議共定義了28條命令，每條命令在CCP driver中都對應一組相應的子函數，代表不同的功能，如EEPROM標定、DAQ工作模式等。用戶可根據實際需要，選擇實現其中部分或全部功能。每增加一個新的功能，必須在底層程序中添加開放該項功能的程序接口［3］。如對EEPROM標定，首先ECU應用程序中應包含EEPROM模塊子函數，同時還需實現命令處理器與EEPROM模塊之間的調用接口。

　　3 利用CANape實現基于CCP的標定

　　CANape［4］是德國Vector公司出品的一款基于ASAP標準的ECU測試和標定工具。它通過一個控制器硬件接口與ECU相連，兩者之間常用的物理連接是基于CCP協議的CAN總線。只有控制器的底層程序中有支持CCP協議的程序接口， CANape才能與控制器通信。

　　CANape提供了多種功能：在線數據評估、離線評估、數據管理、FLASH編程、參數標定及ASAP2數據編輯器等。此外，測試過程中由CAN總線上傳的數據還可以通過CANape在計算機顯示和保存，以進行離線標定和數據評估。

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

　　CANape與控制器間的通信需要一個描述文件支持，這個文件稱為ASAP2控制器描述文件［4］.CANape對控制器的參數標定和數據測量都是基于這個文件，該文件記錄了控制器中各參數的詳細信息，如標定參數和測量變量在控制器中的存儲地址、存儲結構、數據類型和轉換公式等。在CANape中，每個標定參數和測量數據都會有一個變量名，如發動機溫度、冷卻水溫度。當CANape需要訪問某個變量，就在ASAP2描述文件中根據變量名，找到該變量在控制器中的存儲地址、數據長度等信息，然后進行操作，如圖5.

　　圖5 ASAP2控制器描述文件

　　為了方便用戶對ASAP2文件進行維護和修改，CANape集成了一個ASAP2數據庫編輯器，用以生成和修改ASAP2控制器描述文件。所有的信息都能通過對話框的形式進行設置和修改。該數據庫編輯器還能工作在獨立模式下，以生成一個ASAP2格式的控制器描述文件。

　　當ECU底層程序修改后，一些標定參數和測量數據的內存地址可能發生變動，CANape雖然仍能進行標定，但修改的已不是原來需要標定的參數，而是程序變動后原先地址下當前存放的某個新的未知數據。為了簡化手工修改地址的繁瑣，防止因為隨意修改某個數據而破壞程序的正常運行，CANape支持通過linker map文件自動更新ASAP2文件里的信息。Map文件是ECU底層程序在編譯時由編譯器生成的一種映射文件，通過Map文件可以自動更新ASAP2文件。

　　3.2 CANape使用配置

　　每個需要標定的ECU都要在CANape中進行配置。

　　CANape共定義了28條命令，用以實現不同的功能，在配置頁面里均有復選框與其對應。控制器的配置必須與CCP Driver在ECU底層程序的具體實現相匹配，只有對某個功能的程序接口已經開放，才能在CANape中選擇使用該項功能［2］［5］。

　　3.3 CANape中的參數標定

　　在CANape中，需要標定的變量稱為標定參數，CANape將標定定義為修改駐扎在ECU內存中的變量的內容。CANape支持多種標定方法。這里標定方法指如何對標定參數所在的內存區域進行初始化、數據改寫及保存。根據標定參數所在不同地址空間（ROM、FLASH或EEPROM），CANape規定了不同的標定方法。

　　當標定參數需要存放在FLASH或ROM中時，在ECU上電初始化后，程序首先將標定參數的初始值復制到RAM中，在CANape中該段用來存放標定參數的RAM稱為Calibration RAM.標定過程中，CANape修改Calibration RAM中的參數值。標定全部結束后，再將該段RAM中的內容復制回FLASH或ROM中。

　　當標定參數存放在EEPROM中，有兩種標定方法。第一種與上述方法相同，首先將標定參數復制到RAM中，標定結束后再將RAM中的數據覆蓋到EEPROM.此外，也可對EEPROM中的參數直接進行改寫，實現這種方法需要對EEPROM進行頻繁擦寫操作，但不占用額外的RAM空間。

　　由于汽車電子網絡系統已開始得到廣泛的使用，基于網絡連接的電子控制單元的匹配標定和傳統的匹配標定方法已有了很大的不同，特別是基于CAN總線的匹配標定技術，目前已成為研究和應用的重點。

　　采用CANape進行基于CCP的匹配標定，實現了標定工具和內容的統一。根據這種方法能夠快速有效地進行汽車電子控制單元的匹配標定，在實際開發應用中取得了良好的效果。