基于CCP的汽車控制器的匹配標(biāo)定的設(shè)計(jì)

　　目前基于CAN（Controller Area Network）總線的分布式系統(tǒng)在汽車電子領(lǐng)域得到廣泛應(yīng)用，電子控制單元的標(biāo)定已成為汽車電子控制裝置開發(fā)的一個(gè)重要環(huán)節(jié)。CCP（CAN Calibration Protocol）是一種基于CAN總線的ECU（Electronic Control Unit）標(biāo)定協(xié)議［1］，已經(jīng)在許多歐美汽車廠商得到應(yīng)用，采用CCP協(xié)議可以快速而有效地實(shí)現(xiàn)對(duì)汽車電控單元的標(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)的開發(fā)過程中，大量時(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)定開發(fā)周期。

　　CANape［4］是一款ECU標(biāo)定和測(cè)試工具。與CCP協(xié)議相結(jié)合，不僅能完成對(duì)ECU的標(biāo)定，同時(shí)還能在ECU運(yùn)行期間直接訪問內(nèi)存并進(jìn)行操作。這使得CANape不僅是一款功能強(qiáng)大的標(biāo)定工具，也是一款電控單元開發(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)，以解決由于不同制造商提供的控制器存在的接口不匹配問題。

　　1.1 CCP通信方式

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

　　圖1 CCP通信方式

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

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

　　CCP定義了兩種工作模式：Polling（查詢）模式及DAQ（Data Acquisition Command）模式。查詢模式下，主設(shè)備與從設(shè)備間的每一次通信都由主設(shè)備發(fā)送命令來起始，從設(shè)備收到主設(shè)備的命令后，執(zhí)行相應(yīng)的操作并反饋一幀報(bào)文。這種工作模式由于需要主機(jī)與從機(jī)之間進(jì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ī)通過命令逐步控制，工作效率高，但實(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)文。兩者分別通過一個(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è)備通過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)文稱為DTO.按CCP協(xié)議，DTO又細(xì)分為三類：

　　·命令返回消息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的類型，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)用程序稱為CCP driver.本文采用Vector提供的free CCP driver［2］。由于CCP協(xié)議基于CAN總線，因此CCP driver與ECU的結(jié)合主要分為與CAN driver及與其他應(yīng)用程序兩方面。

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

　　圖3 CCP標(biāo)定程序接口

　　·發(fā)送端：DTO通過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，通過其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è)備上傳。