【文章內(nèi)容簡(jiǎn)介】 典型的VISION標(biāo)定軟件的工作界面（或稱為屏幕文件）見(jiàn)圖2，其中有二維和三維的發(fā)動(dòng)機(jī)標(biāo)定數(shù)據(jù)，數(shù)據(jù)可以通過(guò)表格的方式編輯，也可以通過(guò)圖形的方式顯示和修改，并且可以在計(jì)算機(jī)屏幕上用虛擬儀表方式形象地反映標(biāo)定變量的動(dòng)態(tài)變化。三、VISION軟件在汽車發(fā)動(dòng)機(jī)標(biāo)定中的應(yīng)用（一）發(fā)動(dòng)機(jī)怠速設(shè)置的標(biāo)定圖3中，橫坐標(biāo)表示發(fā)動(dòng)機(jī)溫度變量（℃），縱坐標(biāo)表示發(fā)動(dòng)機(jī)怠速變量( r/min )，可以看到在0℃以上時(shí)，發(fā)動(dòng)機(jī)怠速設(shè)置為800r/min。在0℃以下時(shí)，由于發(fā)動(dòng)機(jī)啟動(dòng)比較困難，所以發(fā)動(dòng)機(jī)怠速隨著溫度的降低而逐步升高，直到40℃時(shí)，發(fā)動(dòng)機(jī)怠速設(shè)置為1100r/min。（二）燃油噴射系統(tǒng)的標(biāo)定燃油噴射系統(tǒng)的主要控制量是發(fā)動(dòng)機(jī)各缸的噴油量和噴油時(shí)間，在VISION標(biāo)定軟件中，設(shè)計(jì)了一個(gè)中間變量駕駛員請(qǐng)求噴油量，它是變量加速踏板位置（范圍：0～100%）和發(fā)動(dòng)機(jī)轉(zhuǎn)速的控制函數(shù)。其控制MAP圖見(jiàn)圖40其中X軸：加速踏板位置（％），Y軸：發(fā)動(dòng)機(jī)轉(zhuǎn)速（r/min），Z軸：駕駛員請(qǐng)求噴油量（mg/stroke）。 發(fā)動(dòng)機(jī)各缸的噴油量是通過(guò)改變噴油器電磁閥的位移來(lái)控制的，它是變量加速踏板位置和發(fā)動(dòng)機(jī)轉(zhuǎn)速的控制函數(shù)，其控制MAP圖見(jiàn)圖5。其中X軸：駕駛員請(qǐng)求噴油量（mg/stroke），Y軸：發(fā)動(dòng)機(jī)轉(zhuǎn)速（r/min），Z軸：噴油器電磁閥的位移（mm）。噴油時(shí)間由曲軸轉(zhuǎn)角控制，它是變量加速踏板位置和發(fā)動(dòng)機(jī)轉(zhuǎn)速的控制函數(shù)，其控制MAP圖見(jiàn)圖6。其中X軸：駕駛員請(qǐng)求噴油量（mg/stroke），Y軸：發(fā)動(dòng)機(jī)轉(zhuǎn)速（r/min），Z軸：曲軸轉(zhuǎn)角（176。）。四、結(jié)語(yǔ) VISION是目前國(guó)內(nèi)外流行的汽車ECU標(biāo)定軟件，它的系統(tǒng)功能和使用方法有很強(qiáng)的代表性。通過(guò)分析VISION軟件的開(kāi)發(fā)技術(shù)，可以了解當(dāng)前汽車ECU的研究和開(kāi)發(fā)的進(jìn)展情況，因此本文對(duì)國(guó)內(nèi)汽車ECU的開(kāi)發(fā)有一定的參考作用?；贑CP協(xié)議利用CANape進(jìn)行電控單元標(biāo)定摘　要：采用基于CAN總線的匹配標(biāo)定協(xié)議,對(duì)汽車控制器局域網(wǎng)絡(luò)中的電子控制單元進(jìn)行匹配標(biāo)定。分析了CCP協(xié)議用于標(biāo)定的工作機(jī)理,討論了利用CANape進(jìn)行基于CCP標(biāo)定的實(shí)現(xiàn)方法,闡述了如何生成CANape與控制器底層程序的軟件接口及具體標(biāo)定流程。實(shí)際應(yīng)用結(jié)果表明,這種方法可以快速有效地實(shí)現(xiàn)對(duì)汽車網(wǎng)絡(luò)中各控制器的匹配標(biāo)定。 　　關(guān)鍵詞：汽車電控單元 CAN總線 CCP協(xié)議 標(biāo)定 CANape 　　目前基于CAN(Controller Area Network)總線的分布式系統(tǒng)在汽車電子領(lǐng)域得到廣泛應(yīng)用,電子控制單元的標(biāo)定已成為汽車電子控制裝置開(kāi)發(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)的開(kāi)發(fā)過(guò)程中,大量時(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)定開(kāi)發(fā)周期。 　　CANape[4]是一款ECU標(biāo)定和測(cè)試工具。與CCP協(xié)議相結(jié)合,不僅能完成對(duì)ECU的標(biāo)定,同時(shí)還能在ECU運(yùn)行期間直接訪問(wèn)內(nèi)存并進(jìn)行操作。這使得CANape不僅是一款功能強(qiáng)大的標(biāo)定工具,也是一款電控單元開(kāi)發(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),以解決由于不同制造商提供的控制器存在的接口不匹配問(wèn)題。 CCP通信方式 　　基于CCP協(xié)議的ECU標(biāo)定采用主從通信方式,如圖1。主設(shè)備通過(guò)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è)備建立邏輯鏈接,然后通過(guò)主設(shè)備向從設(shè)備發(fā)送命令來(lái)起始兩者間的數(shù)據(jù)通信。當(dāng)主設(shè)備要訪問(wèn)另一個(gè)從設(shè)備時(shí),首先斷開(kāi)與當(dāng)前從設(shè)備的邏輯連接,與下一個(gè)從設(shè)備建立新的邏輯連接后再開(kāi)始通信。 CCP協(xié)議的工作模式 　　CCP定義了兩種工作模式olling(查詢)模式及DAQ(Data Acquisition Command)模式。查詢模式下,主設(shè)備與從設(shè)備間的每一次通信都由主設(shè)備發(fā)送命令來(lái)起始,從設(shè)備收到主設(shè)備的命令后,執(zhí)行相應(yīng)的操作并反饋一幀報(bào)文。這種工作模式由于需要主機(jī)與從機(jī)之間進(jìn)行“一問(wè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ī)通過(guò)命令逐步控制,工作效率高,但實(shí)現(xiàn)較復(fù)雜,如果需要上傳的數(shù)據(jù)量很大,會(huì)占用大量ECU內(nèi)存空間。 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)文。兩者分別通過(guò)一個(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è)備通過(guò)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ò)誤。 　　?DAQDTO(Data AcquisitionDTO):用在DAQ模式中,由從設(shè)備組織,定期向主設(shè)備發(fā)送。 　　DTO報(bào)文的第1個(gè)