利用CANape進行基于CCP的汽車控制器的匹配標定的設(shè)

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

目前基于CAN(Controller Area Network)總線的分布式系統(tǒng)在汽車電子領(lǐng)域得到廣泛應(yīng)用,電子控制單元的標定已成為汽車電子控制裝置開發(fā)的一個重要環(huán)節(jié)。CCP(CAN Calibration Protocol)是一種基于CAN總線的ECU(Electronic Control Unit)標定協(xié)議[1],已經(jīng)在許多歐美汽車廠商得到應(yīng)用,采用CCP協(xié)議可以快速而有效地實現(xiàn)對汽車電控單元的標定。

然而基于CCP協(xié)議的標定,需要在ECU內(nèi)部實現(xiàn)支持CCP協(xié)議的驅(qū)動程序(CCP driver)。目前大多數(shù)應(yīng)用都采用Vector提供的free CCP driver[2]?？紤]到ECU底層程序與CAN驅(qū)動程序的實現(xiàn)各不相同,將CCP驅(qū)動程序結(jié)合到ECU中[3]并不是一件一蹴而就的事,這需要對CCP協(xié)議本身、標定工具及標定工具與ECU之間的通信有詳細和深入的了解。在整個標定系統(tǒng)的開發(fā)過程中,大量時間被耗費在前期CCP驅(qū)動程序與ECU結(jié)合上。本文在簡單介紹CCP協(xié)議的基礎(chǔ)上,提供了一個通用的ECU與CCP驅(qū)動程序結(jié)合的實例,以幫助縮短整個標定開發(fā)周期。

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

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

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

1.1 CCP通信方式

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

圖1 CCP通信方式

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

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

CCP定義了兩種工作模式:Polling(查詢)模式及DAQ(Data Acquisition Command)模式。查詢模式下,主設(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.3 CCP報文幀結(jié)構(gòu)

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

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

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

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

·命令返回消息CRM(Command Return Message):由從設(shè)備發(fā)送,針對CRO的反饋報文。

·事件消息(Event Message):當從設(shè)備檢測到內(nèi)部發(fā)生錯誤機制時,由從設(shè)備自行向主設(shè)備發(fā)送,報告其當前的運行狀態(tài),并請求主設(shè)備暫停當前工作進程以處理發(fā)生的錯誤。

·DAQ-DTO(Data Acquisition-DTO):用在DAQ模式中,由從設(shè)備組織,定期向主設(shè)備發(fā)送。

DTO報文的第1個字節(jié)PID(Packet ID)定義了DTO的類型,255代表CRM, 254代表事件消息。第2個字節(jié)為命令返回/錯誤代碼ERR(Command Return-/Error Code)。對于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ù)或信息。

2 基于CCP協(xié)議的接口程序?qū)崿F(xiàn)

基于CCP協(xié)議進行標定,需要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,主要分為以下兩方面:

上一頁 1 2 3 下一頁