<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>

新聞中心

EEPW首頁(yè) > 汽車(chē)電子 > 設計應用 > 基于CCP的汽車(chē)控制器的匹配標定的設計

基于CCP的汽車(chē)控制器的匹配標定的設計

作者: 時(shí)間:2017-06-07 來(lái)源:網(wǎng)絡(luò ) 收藏

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

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

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

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

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

1.1 CCP通信方式

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

圖1 CCP通信方式

本文引用地址:http://dyxdggzs.com/article/201706/350613.htm

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

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

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

1.3 CCP報文幀結構

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

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

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

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

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

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

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

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

2 基于CCP協(xié)議的接口程序實(shí)現

基于CCP協(xié)議進(jìn)行標定,需要MCS與ECU的應用程序都能夠支持CCP協(xié)議,這部分應用程序稱(chēng)為CCP driver。本文采用Vector提供的free CCP driver[2]。由于CCP協(xié)議基于CAN總線(xiàn),因此CCP driver與ECU的結合主要分為與CAN driver及與其他應用程序兩方面。

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

圖3 CCP標定程序接口

·發(fā)送端:DTO通過(guò)CAN driver的發(fā)送子函數以CAN報文的格式上傳給MCS。

·接收端:主設備發(fā)送的命令以CAN報文的格式首先進(jìn)入CAN driver的接收子函數,由其判斷為CRO后,進(jìn)一步交給命令處理器處理。

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

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

圖4 接口程序基本流程圖

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

ccpCommand()通過(guò)調用CAN driver中的CCP發(fā)送子函數ccpSend()發(fā)送一幀DTO。ccpSend()須在CAN driver中實(shí)現,由CCP driver調用。按實(shí)際情況,將CAN發(fā)送子函數直接以ccpSend()的形式實(shí)現,或在保留原有發(fā)送子函數的基礎上添加一個(gè)ccpSend()子函數,在其中調用CAN發(fā)送子函數,以完成DTO的發(fā)送。
CCP協(xié)議為確保主設備與ECU之間正常通信,每次發(fā)送后,程序必須通過(guò)調用CCP driver中的ccpSendCallback()子函數檢查剛才的DTO是否已經(jīng)發(fā)送,否則不能發(fā)送下一幀報文。針對不同的CAN driver實(shí)現,該函數調用的位置不同。最后主函數將CCP標志位清空,等待下一條CRO命令。

一個(gè)完整的CCP driver 接口還包括與ECU其他應用程序的接口。每次單片機初始化后,主函數調用一次CCP driver的CCP初始化子函數ccpInit(),將上次標定殘留在ECU內存中的數據清空,為下次標定與測量做準備。
CCP協(xié)議共定義了28條命令,每條命令在CCP driver中都對應一組相應的子函數,代表不同的功能,如標定、DAQ工作模式等。用戶(hù)可根據實(shí)際需要,選擇實(shí)現其中部分或全部功能。每增加一個(gè)新的功能,必須在底層程序中添加開(kāi)放該項功能的程序接口[3]。如對標定,首先ECU應用程序中應包含模塊子函數,同時(shí)還需實(shí)現命令處理器與EEPROM模塊之間的調用接口。

3 利用CANape實(shí)現基于CCP的標定

CANape[4]是德國Vector公司出品的一款基于A(yíng)SAP標準的ECU測試和標定工具。它通過(guò)一個(gè)控制器硬件接口與ECU相連,兩者之間常用的物理連接是基于CCP協(xié)議的CAN總線(xiàn)。只有控制器的底層程序中有支持CCP協(xié)議的程序接口, CANape才能與控制器通信。

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

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

CANape與控制器間的通信需要一個(gè)描述文件支持,這個(gè)文件稱(chēng)為ASAP2控制器描述文件[4]。CANape對控制器的參數標定和數據測量都是基于這個(gè)文件,該文件記錄了控制器中各參數的詳細信息,如標定參數和測量變量在控制器中的存儲地址、存儲結構、數據類(lèi)型和轉換公式等。在CANape中,每個(gè)標定參數和測量數據都會(huì )有一個(gè)變量名,如發(fā)動(dòng)機溫度、冷卻水溫度。當CANape需要訪(fǎng)問(wèn)某個(gè)變量,就在A(yíng)SAP2描述文件中根據變量名,找到該變量在控制器中的存儲地址、數據長(cháng)度等信息,然后進(jìn)行操作,如圖5。

圖5 ASAP2控制器描述文件

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

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

3.2 CANape使用配置

每個(gè)需要標定的ECU都要在CANape中進(jìn)行配置。

CANape共定義了28條命令,用以實(shí)現不同的功能,在配置頁(yè)面里均有復選框與其對應??刂破鞯呐渲帽仨毰cCCP Driver在ECU底層程序的具體實(shí)現相匹配,只有對某個(gè)功能的程序接口已經(jīng)開(kāi)放,才能在CANape中選擇使用該項功能[2][5]。

3.3 CANape中的參數標定

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

當標定參數需要存放在FLASH或ROM中時(shí),在ECU上電初始化后,程序首先將標定參數的初始值復制到RAM中,在CANape中該段用來(lái)存放標定參數的RAM稱(chēng)為Calibration RAM。標定過(guò)程中,CANape修改Calibration RAM中的參數值。標定全部結束后,再將該段RAM中的內容復制回FLASH或ROM中。

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

由于汽車(chē)電子網(wǎng)絡(luò )系統已開(kāi)始得到廣泛的使用,基于網(wǎng)絡(luò )連接的電子控制單元的和傳統的方法已有了很大的不同,特別是基于CAN總線(xiàn)的技術(shù),目前已成為研究和應用的重點(diǎn)。

采用CANape進(jìn)行基于CCP的匹配標定,實(shí)現了標定工具和內容的統一。根據這種方法能夠快速有效地進(jìn)行汽車(chē)電子控制單元的匹配標定,在實(shí)際開(kāi)發(fā)應用中取得了良好的效果。



關(guān)鍵詞: 匹配標定 EEPROM CANape

評論


相關(guān)推薦

技術(shù)專(zhuān)區

關(guān)閉
国产精品自在自线亚洲|国产精品无圣光一区二区|国产日产欧洲无码视频|久久久一本精品99久久K精品66|欧美人与动牲交片免费播放
<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>