梁恒，周文華，趙俊鵬

（浙江大學(xué)能源工程學(xué)系，浙江杭州310017）

0 引言

在發(fā)動(dòng)機(jī)ECU開發(fā)過程中，在對(duì)原有算法進(jìn)行優(yōu)化或者添加新算法后往往需要對(duì)算法進(jìn)行不斷地測(cè)試和修正，直至ECU功能測(cè)試合格。隨著ECU控制系統(tǒng)越來越復(fù)雜，以及ECU需要不斷更新完善來滿足新需求，如果按照傳統(tǒng)開發(fā)模式將嚴(yán)重耗費(fèi)人力物力。為加快和簡化測(cè)試過程、縮短開發(fā)周期，快速原型技術(shù)在最近幾年得到了快速的發(fā)展。DSpace，ETAS，Continental等公司都相繼開發(fā)了用于快速原型的軟、硬件系統(tǒng)，其產(chǎn)品已經(jīng)廣泛應(yīng)用于具有一定實(shí)力的汽車企業(yè)以及科研機(jī)構(gòu)［1-3］。國內(nèi)對(duì)快速原型技術(shù)也進(jìn)行了深入研究，清華大學(xué)開發(fā)的多功能動(dòng)力總成控制器軟、硬件平臺(tái)已應(yīng)用于汽車控制系統(tǒng)的開發(fā)［4］，大連理工大學(xué)與江奎科技聯(lián)合開發(fā)的“多功能汽車發(fā)動(dòng)機(jī)電子控制單元快速開發(fā)平臺(tái)”UECU已經(jīng)應(yīng)用于共軌柴油機(jī)和氫燃料發(fā)動(dòng)機(jī)的開發(fā)［5］。

快速原型技術(shù)能夠在產(chǎn)品硬件完成之前，將新的控制程序放于原型系統(tǒng)上進(jìn)行硬件實(shí)時(shí)測(cè)試，方便新的ECU開發(fā)。另一方面，快速原型也可將一部分ECU控制算法通過bypass方式擴(kuò)展到原型系統(tǒng)上，開發(fā)人員可以更專注地實(shí)現(xiàn)對(duì)旁通控制模塊的開發(fā)、驗(yàn)證［6］。目前，ECU與原型系統(tǒng)之間的數(shù)據(jù)同步主要通過基于雙端口存儲(chǔ)器和基于標(biāo)定協(xié)議［7］。

本研究基于XCP on CAN協(xié)議為接口提出一種成本低廉的快速原型方式，將需要旁通的功能代碼通過標(biāo)定工具加載后放于PC機(jī)上運(yùn)行，以提高快速原型方法的靈活性，減少原有ECU中內(nèi)存、I/O以及Processor處理能力等的約束。

1 快速原型發(fā)展現(xiàn)狀

在快速原型方式剛產(chǎn)生時(shí)，其主要作用是在硬件產(chǎn)品開發(fā)出來之前就可以實(shí)時(shí)測(cè)試所開發(fā)的控制程序，以加快項(xiàng)目開發(fā)進(jìn)度。隨著技術(shù)的發(fā)展，基于模型的控制策略開發(fā)得到了廣泛的應(yīng)用，其所有的控制策略都利用框圖化的基本模塊建立起來。這種模塊化程序設(shè)計(jì)環(huán)境使得新增或者修改已有的功能模塊具有相對(duì)獨(dú)立性。所以快速原型方式開始應(yīng)用于旁通部分功能模塊旁通至原型系統(tǒng)，以實(shí)現(xiàn)對(duì)新增或修改后的功能模塊進(jìn)行測(cè)試。通過這種旁通方式，研究者可以將新開發(fā)或者修改過后功能模塊程序直接在原有ECU上進(jìn)行實(shí)時(shí)測(cè)試，極大地縮短了開發(fā)周期。

旁通技術(shù)的應(yīng)用如圖1所示，部分控制模塊（如電子油門控制模塊）旁通后在原型機(jī)上運(yùn)行，其余的控制模塊、發(fā)動(dòng)機(jī)傳感器等的底層驅(qū)動(dòng)程序依舊在原ECU上運(yùn)行。ECU所采集的傳感器數(shù)據(jù)經(jīng)處理后通過CAN總線發(fā)送至原型系統(tǒng)，原型系統(tǒng)接收數(shù)據(jù)并運(yùn)算完后將運(yùn)算結(jié)果通過CAN總線發(fā)送至ECU。通過這種方式，旁通模塊與ECU原有控制模塊構(gòu)成一個(gè)整體以控制發(fā)動(dòng)機(jī)的正常工作。

圖1 旁通技術(shù)的應(yīng)用

2 基于XCP on CAN快速原型原理

2.1 旁通控制模塊程序的調(diào)用

傳統(tǒng)的快速原型方法中旁通控制模塊程序一般存儲(chǔ)于外部硬件或者原有ECU空余的RAM或ROM中，不過基于特殊實(shí)時(shí)硬件的解決方案價(jià)格昂貴，開發(fā)部門中這類設(shè)備也可能為數(shù)不多；將旁通模塊程序存儲(chǔ)于原有ECU則要求ECU有足夠的內(nèi)存［8］。

本研究通過vCalitool工具在PC機(jī)中加載旁通的控制模塊，消除對(duì)ECU的內(nèi)存需求?？刂颇Ｐ陀蒘imulink開發(fā)，通過matlab將mdl文件生成dll文件，vCalitool直接加載dll文件以實(shí)現(xiàn)對(duì)控制算法的調(diào)用。其中vCalitool作為XCP主設(shè)備，可完成PC上旁通模型與原有ECU之間的數(shù)據(jù)通信。ECU參數(shù)和模型參數(shù)都可通過vCalitool進(jìn)行標(biāo)定。

2.2 程序運(yùn)行流程控制

在測(cè)試過程中，程序測(cè)試人員需要改變控制程序運(yùn)行流程以完成對(duì)指定功能代碼的測(cè)試。其運(yùn)行流程的控制通過軟件鉤來實(shí)現(xiàn)。程序開發(fā)人員在設(shè)計(jì)程序時(shí)根據(jù)需要定義軟件鉤變量，測(cè)試人員根據(jù)所提供的標(biāo)定信息（A2L文件），通過標(biāo)定工具更改軟件鉤變量值以完成對(duì)程序運(yùn)行流程的控制。bypass示意圖如圖2所示，當(dāng)hook值為0時(shí)，ECU代碼原始運(yùn)行流程為A，B，C，D。當(dāng)測(cè)試人員將hook通過標(biāo)定工具改為1時(shí)，ECU代碼運(yùn)行流程為A，F(xiàn)，C，D。相比A，B，C，D功能模塊，功能F從ECU中獨(dú)立出來在PC機(jī)上運(yùn)行。

圖2 bypass示意圖

2.3 RCP與ECU接口

目前實(shí)現(xiàn)ECU與原型系統(tǒng)之間的數(shù)據(jù)同步的途徑主要有兩種：基于雙端口存儲(chǔ)器、基于標(biāo)定協(xié)議?；跇?biāo)定協(xié)議的主要缺陷在于協(xié)議傳輸速率相對(duì)較低。但是比起雙端口存儲(chǔ)器方法，基于標(biāo)定協(xié)議方法也有其優(yōu)勢(shì)。如一般ECU支持主流的標(biāo)定協(xié)議，以標(biāo)定協(xié)議作為接口這種方法無需再對(duì)ECU進(jìn)行修改，而雙端口處理器方法需要對(duì)ECU硬件有所改動(dòng)；標(biāo)定協(xié)議的方式下數(shù)據(jù)傳輸穩(wěn)定，而雙端口處理器在硬件改動(dòng)后易受振動(dòng)，電源等外部條件的影響。

隨著汽車總線等技術(shù)的迅猛發(fā)展以及標(biāo)定協(xié)議的逐步完善，其數(shù)據(jù)傳輸速率和可靠性得到了很大的提升，基于標(biāo)定協(xié)議實(shí)現(xiàn)旁通接口的方式的弊端正逐步減小。如目前在車載網(wǎng)絡(luò)中得到廣泛應(yīng)用的CAN網(wǎng)絡(luò)最高性能極限為1 Mbps，F(xiàn)lexRay的網(wǎng)絡(luò)帶寬可以達(dá)到CAN網(wǎng)絡(luò)的20倍；XCP on CAN協(xié)議中的數(shù)據(jù)同步模式中每一數(shù)據(jù)幀包含的多個(gè)變量值，提高了數(shù)據(jù)傳輸速率。

由于CAN網(wǎng)絡(luò)在車載網(wǎng)絡(luò)中應(yīng)用最廣，本研究選擇基于XCP on CAN協(xié)議作為旁通接口［9］。bypass示意圖如圖2所示，支持XCP協(xié)議的vCaliTool工具通過DAQ和STIM模式實(shí)現(xiàn)與ECU數(shù)據(jù)同步，輸入?yún)?shù)x通過DAQ模式周期性更新至vCaliTool，x經(jīng)被vCali-Tool調(diào)用旁通功能模塊程序運(yùn)算后獲得輸出參數(shù)y，然后vCaliTool將y值通過STIM模式發(fā)送至ECU。

2.4 標(biāo)定系統(tǒng)軟實(shí)時(shí)性要求

將控制模塊旁通至PC機(jī)時(shí)，傳感器數(shù)據(jù)經(jīng)ECU處理后通過接口發(fā)送至vCalitool，vCalitool調(diào)用控制模塊dll文件后將計(jì)算結(jié)果更新至ECU。該過程要求vCalitool滿足一定的實(shí)時(shí)性，否則將影響控制系統(tǒng)的快速響應(yīng)性能。一般標(biāo)定系統(tǒng)是基于WIN32操作系統(tǒng)運(yùn)行的，由于操作系統(tǒng)消息處理機(jī)制的限制，標(biāo)定系統(tǒng)難以實(shí)現(xiàn)硬實(shí)時(shí)性要求。因此筆者對(duì)標(biāo)定系統(tǒng)軟實(shí)時(shí)性能進(jìn)行優(yōu)化，以滿足旁通測(cè)試的需要。

為測(cè)試標(biāo)定系統(tǒng)的軟實(shí)時(shí)性，本研究對(duì)vCalitool工具的軟實(shí)時(shí)性進(jìn)行了測(cè)試。測(cè)試在Window7操作系統(tǒng)上進(jìn)行，處理器為Intel（R）Core（TM）i5-2310@2.90 GHz，測(cè)試時(shí)關(guān)閉了其他非相關(guān)的應(yīng)用程序。vCalitool工具以10 ms的間隔周期性發(fā)送數(shù)據(jù)至ECU，通過邏輯分析儀測(cè)試延遲時(shí)間，測(cè)試結(jié)果如圖3所示。在140 000個(gè)測(cè)試循環(huán)中，平均時(shí)間延遲為0.77 ms，在0.6 ms～1.0 ms區(qū)間中出現(xiàn)頻次占總循環(huán)數(shù)的98.8%以上，0.6 ms～1.2 ms區(qū)間內(nèi)出現(xiàn)頻次為占總循環(huán)數(shù)的99.99%以上。時(shí)間延遲最長為7.5 ms，出現(xiàn)了4次。所以對(duì)于時(shí)間延遲上限大于1.2 ms的BYPASS任務(wù)，基于XCP協(xié)議的方式能夠滿足要求。

由圖3可知，盡管標(biāo)定系統(tǒng)軟實(shí)時(shí)性能良好，但是不能排除少數(shù)因總線通訊等因素所引起的超時(shí)。為保證ECU的安全正常運(yùn)行，ECU和vCalitool應(yīng)設(shè)置等待超時(shí)處理機(jī)制。ECU以及vCalitool同時(shí)存在一個(gè)計(jì)時(shí)器，在ECU等待vCaliTool的STIM數(shù)據(jù)包或vCalitool等待ECU的DAQ數(shù)據(jù)包超過一定的等待時(shí)間后，自動(dòng)將上一周期所收到的數(shù)據(jù)作為當(dāng)前周期值。

圖3 140000次測(cè)試循環(huán)時(shí)間延遲

3 基于XCP on CAN協(xié)議接口實(shí)現(xiàn)

目前比較通用的CCP協(xié)議主要注重于對(duì)ECU的標(biāo)定的過程，沒有考慮到快速原型中數(shù)據(jù)同步的需要，因此若要將CCP協(xié)議應(yīng)用于數(shù)據(jù)同步中，需要進(jìn)行一定的修改。但是由于CCP協(xié)議整體框架的限制，經(jīng)修改后其數(shù)據(jù)傳輸速率提升空間有限，而且修改后的CCP因?yàn)椴皇菢?biāo)準(zhǔn)的，兼容性不夠。

為解決CCP協(xié)議在實(shí)際應(yīng)用中出現(xiàn)的缺陷，2003年，自動(dòng)化及測(cè)量系統(tǒng)標(biāo)準(zhǔn)協(xié)會(huì)（ASAM）基于CCP協(xié)議基礎(chǔ)上制定了XCP協(xié)議［10］。XCP協(xié)議中的同步激勵(lì)模式下，通過DAQ和STIM模式完成一個(gè)bypass周期只需要兩條命令，而且所要傳輸?shù)亩鄠€(gè)變量數(shù)據(jù)同時(shí)被整合到一條DTO中傳輸，極大地提高了數(shù)據(jù)傳輸效率，可以高效、快速地完成ECU與原型系統(tǒng)兩者之間的同步［11］。

3.1 驅(qū)動(dòng)事件

發(fā)動(dòng)機(jī)控制策略由燃油量控制、噴油正時(shí)控制等組成，分別有時(shí)間和事件驅(qū)動(dòng)控制任務(wù)，因此為更好地實(shí)現(xiàn)原型系統(tǒng)與ECU的數(shù)據(jù)同步、降低CAN總線的負(fù)載率，需要有不同類型的中斷以觸發(fā)同步數(shù)據(jù)幀的發(fā)送。在XCP協(xié)議中，每個(gè)DAQlist對(duì)應(yīng)一個(gè)事件通道，測(cè)試人員根據(jù)不同的變量同步需求選擇合適的時(shí)間通道。在DAQ及STIM模式開啟后，ECU在DAQlist中所設(shè)置的事件觸發(fā)下向vCalitool發(fā)送數(shù)據(jù)，數(shù)據(jù)接收完畢后vCalitool調(diào)用旁通模塊程序運(yùn)算，其運(yùn)算結(jié)果通過STIM模式發(fā)送至ECU中。

3.2 數(shù)據(jù)幀格式

在XCP協(xié)議中同步數(shù)據(jù)傳輸模式（DAQ和STIM）開啟后，標(biāo)定系統(tǒng)與ECU之間通過同步數(shù)據(jù)傳送體（DTO）完成信息的同步。DTO與ECU內(nèi)存的關(guān)系由ODT建立，ODT中的每個(gè)ODT entry包含了每個(gè)變量的信息，如變量地址和長度信息，ODT組成如圖4所示。在開啟同步數(shù)據(jù)傳輸模式開啟前，需要對(duì)所操作的變量選擇工作模式（DAQ或STIM）以及觸發(fā)事件，并初始化ODT［12］。模式開啟后，主機(jī)和從機(jī)會(huì)在DAQlist所屬的事件觸發(fā)下，根據(jù)ODT描述組織DTO并發(fā)送，以完成主、從機(jī)中特定變量的數(shù)據(jù)同步。

圖4 ODT組成

4 應(yīng)用舉例

本研究在柴油機(jī)高壓共軌控制系統(tǒng)基礎(chǔ)上旁通了雙電位器電子油門控制模塊，對(duì)vCalitool工具進(jìn)行了測(cè)試。從機(jī)ECU微處理器為英飛凌XC2785x-104L80F，通過英特佩斯valuecan3與建立主從機(jī)之間CAN通訊。

為方便控制算法的開發(fā)與移植，測(cè)試的控制算法雙電位器電子油門控制算法由Simulink開發(fā)，然后通過Matlab由mdl文件生成dll文件。vCalitool工具完成對(duì)dll文件的調(diào)用，并實(shí)現(xiàn)相關(guān)參數(shù)的讀取。為方便標(biāo)定工具控制ECU程序運(yùn)行流程，本研究在ECU原有程序中添加byte型的軟件鉤software_switch，并對(duì)ECU原有程序進(jìn)行相應(yīng)地改動(dòng)，以實(shí)現(xiàn)通過改變software_switch值就可以選擇切換不同的運(yùn)行流程。

本研究選擇雙電位電子油門控制算法中的極值故障算法作為被旁通模塊進(jìn)行測(cè)試。為直觀、方便地監(jiān)測(cè)故障，控制策略設(shè)置byte型變量APPCD_stTstTrg1記錄故障狀態(tài)，其各位表征含義如表1所示。

因觀察與試驗(yàn)需要，本研究設(shè)定油門超下限故障臨界值A(chǔ)PPCD_uAPP1_SRCMin_C為2 000 mV，超上限故障臨界值A(chǔ)PPCD_uAPP1_SRCMax_C為4 000 mV，故障確認(rèn)與恢復(fù)時(shí)間為2 s。設(shè)置DAQLIST0為DAQ模式，其中添加變量APPCD_stTstTrg1，第一路油門傳感器A/D采樣轉(zhuǎn)化值A(chǔ)PPCD_uRawAPP1，第二路油門傳感器A/D采樣轉(zhuǎn)化值A(chǔ)PPCD_uRawAPP2，事件通道為10 ms；設(shè)置DAQLIST1為STIM模式，其中添加變量加速踏板大腳油門狀態(tài)APPCD_stKickDown，過濾后傳感器信號(hào)APPCD_rFlt以及APPCD_stTstTrg1等故障狀態(tài)顯示量，事件通道為10 ms。實(shí)驗(yàn)結(jié)果如圖5所示。

表1 電子油門第一路傳感器極值故障各位含義

圖5 極值故障隨傳感器信號(hào)關(guān)系圖

如圖5所示，在13 s左右時(shí)，APPCD_uRawAPP1值在2 000 mV～4 000 mV范圍內(nèi)，APPCD_stTstTrg1的值為32（0010 0000B），當(dāng)油門值超過超上限故障臨界值4 000 mV后，APPCD_stTstTrg1的值變?yōu)?6（0100 0010B），初步判定第一路油門傳感器超上限故障，當(dāng)APPCD_uRawAPP1值超過4 000 mV持續(xù)時(shí)間超過故障確認(rèn)時(shí)間2 s后，APPCD_stTstTrg1的值變?yōu)?5（0100 0001B），當(dāng)APPCD_uRawAPP1值恢復(fù)到正常值范圍后，APPCD_stTstTrg1的值變?yōu)?6（0010 0100B），進(jìn)入故障預(yù)恢復(fù)階段，2 s后APPCD_stTstTrg1的值又變?yōu)?2（0010 0000B），ECU確認(rèn)故障消失，當(dāng)APPCD_uRawAPP1值低于2 000 mV時(shí)，APPCD_stTst-Trg1的值變?yōu)?30（1000 0010B），初步判定第一路油門傳感器超下限故障，APPCD_uRawAPP1低于2 000 mB持續(xù)超過2 s后，APPCD_stTstTrg1的值變?yōu)?29（1000 0001B），確認(rèn)超下限故障，當(dāng)APPCD_uRawAPP1值恢復(fù)到正常范圍后，如前所述，APPCD_stTstTrg1先進(jìn)入故障預(yù)恢復(fù)，然后確認(rèn)故障消失。本研究根據(jù)圖5的測(cè)試結(jié)果，將電子油門控制模塊通過XCP協(xié)議旁通后，能夠迅速將模塊輸入?yún)?shù)計(jì)算后反饋給ECU，對(duì)ECU的整體運(yùn)行沒有產(chǎn)生影響。

5 結(jié)束語

（1）vCalitool工具通過調(diào)用由Simulink導(dǎo)出的dll文件來加載被旁通的功能模塊，操作簡單迅速。

（2）本研究所開發(fā)的vCalitool工具能充分實(shí)現(xiàn)BYPASS功能。通過XCP協(xié)議的同步激勵(lì)模式大大提升數(shù)據(jù)傳輸速度，迅速同步上位機(jī)與下位機(jī)數(shù)據(jù)，能夠滿足一般功能模塊的bypass需要。

（3）雖然vCalitool工具基于Windows系統(tǒng)開發(fā)，但是軟實(shí)時(shí)性良好。在140 000個(gè)測(cè)試循環(huán)中，延遲時(shí)間在0.6 ms～1.2 ms區(qū)間內(nèi)出現(xiàn)頻次為占總循環(huán)數(shù)的99.99%以上能滿足bypass功能需求。

（4）基于XCP協(xié)議來實(shí)現(xiàn)旁通功能，不需要其他昂貴的硬件設(shè)備，成本低廉，測(cè)試新開發(fā)代碼時(shí)不需重復(fù)燒寫ECU全部代碼，節(jié)省時(shí)間，縮短了研發(fā)周期。

（5）bypass提高了在ECU設(shè)計(jì)階段時(shí)的設(shè)計(jì)靈活性，使設(shè)計(jì)不受原有ECU的RAM、I/O等條件的限制，更方便快捷地實(shí)現(xiàn)對(duì)新控制算法以及優(yōu)化后的控制算法進(jìn)行驗(yàn)證，縮短了開發(fā)時(shí)間，節(jié)省項(xiàng)目經(jīng)費(fèi)。

（

）：

［1］葉險(xiǎn).基于模型的汽油機(jī)電控系統(tǒng)快速原型的研究［D］.成都：西華大學(xué)汽車工程學(xué)院，2012.

［2］謝異才.基于LabView的柴油機(jī)電控單元快速原型平臺(tái)的設(shè)計(jì)與開發(fā)［D］.昆明：昆明理工大學(xué)交通工程學(xué)院，2011.

［3］章健勇，呂世亮，陳林，等.基于快速原型系統(tǒng)的汽油機(jī)控制策略開發(fā)［J］.車用發(fā)動(dòng)機(jī)，2011（2）：25-28.

［4］石琦文，孫曉民.基于Matlab的車用快速原型軟件平臺(tái)的研究與實(shí)現(xiàn)［J］.系統(tǒng)仿真學(xué)報(bào)，2005（13）：108-110.

［5］孔峰.關(guān)于EMS開發(fā)系統(tǒng)的研究與多功能發(fā)動(dòng)機(jī)電控單元快速原型開發(fā)平臺(tái)-UECU的自主開發(fā)［D］.大連：大連理工大學(xué)能源與動(dòng)力學(xué)院，2006.

［6］ROGERS D，CHURCH M，PATEL U，et al.The Evolution of Rapid Prototyping［N］.SAE Paper，2013-01-09.

［7］YACOUB Y，CHEVALIER A.Rapid Prototyping with the Controller Area Network（CAN）［N］.SAE Paper，2001-03-05.

［8］PATZER A.標(biāo)定和測(cè)量應(yīng)用的焦點(diǎn)-XCP［J］.汽車零部件，2007（6）：42-44.

［9］蘇瑜，周文華，竺春狄.一種適用不同通信方式基于XCP協(xié)議的ECU標(biāo)定工具的開發(fā)［J］.汽車工程，2010，32（1）：81-85.

［10］SCHUERMANS R，ZAISER R，HEPPER L E F，et al.XCP-the Universal Measurement and Calibration Protocol Family Version1.0 Part1 Overview［S］.Association for Standardization of Automation and Measuring Systems.2003.

［11］SCHUERMANS R，ZAISER R，HEPPER L E F，et al.XCP-the Universal Measurement and Calibration Protocol Family Version1.0 Part2 Protocol Layer Specification［S］.Association for Standardization of Automation and Measuring Systems.2003.

［12］SCHUERMANS R，ZAISER R，HEPPER L E F，et al.XCP-the Universal Measurement and Calibration Protocol Family Version1.0 Part 5 Example Communication Sequences［S］.Association for Standardization of Automation and Measuring Systems.2003.