基于XCP協議的快速原型技術*

梁恒，周文華，趙俊鵬

（浙江大學能源工程學系，浙江杭州310017）

0 引言

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

快速原型技術能夠在產品硬件完成之前，將新的控制程序放于原型系統上進行硬件實時測試，方便新的ECU開發。另一方面，快速原型也可將一部分ECU控制算法通過bypass方式擴展到原型系統上，開發人員可以更專注地實現對旁通控制模塊的開發、驗證［6］。目前，ECU與原型系統之間的數據同步主要通過基于雙端口存儲器和基于標定協議［7］。

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

1 快速原型發展現狀

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

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

圖1 旁通技術的應用

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

2.1 旁通控制模塊程序的調用

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

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

2.2 程序運行流程控制

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

圖2 bypass示意圖

2.3 RCP與ECU接口

目前實現ECU與原型系統之間的數據同步的途徑主要有兩種：基于雙端口存儲器、基于標定協議?；跇硕▍f議的主要缺陷在于協議傳輸速率相對較低。但是比起雙端口存儲器方法，基于標定協議方法也有其優勢。如一般ECU支持主流的標定協議，以標定協議作為接口這種方法無需再對ECU進行修改，而雙端口處理器方法需要對ECU硬件有所改動；標定協議的方式下數據傳輸穩定，而雙端口處理器在硬件改動后易受振動，電源等外部條件的影響。

隨著汽車總線等技術的迅猛發展以及標定協議的逐步完善，其數據傳輸速率和可靠性得到了很大的提升，基于標定協議實現旁通接口的方式的弊端正逐步減小。如目前在車載網絡中得到廣泛應用的CAN網絡最高性能極限為1 Mbps，FlexRay的網絡帶寬可以達到CAN網絡的20倍；XCP on CAN協議中的數據同步模式中每一數據幀包含的多個變量值，提高了數據傳輸速率。

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

2.4 標定系統軟實時性要求

將控制模塊旁通至PC機時，傳感器數據經ECU處理后通過接口發送至vCalitool，vCalitool調用控制模塊dll文件后將計算結果更新至ECU。該過程要求vCalitool滿足一定的實時性，否則將影響控制系統的快速響應性能。一般標定系統是基于WIN32操作系統運行的，由于操作系統消息處理機制的限制，標定系統難以實現硬實時性要求。因此筆者對標定系統軟實時性能進行優化，以滿足旁通測試的需要。

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

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

圖3 140000次測試循環時間延遲

3 基于XCP on CAN協議接口實現

目前比較通用的CCP協議主要注重于對ECU的標定的過程，沒有考慮到快速原型中數據同步的需要，因此若要將CCP協議應用于數據同步中，需要進行一定的修改。但是由于CCP協議整體框架的限制，經修改后其數據傳輸速率提升空間有限，而且修改后的CCP因為不是標準的，兼容性不夠。

為解決CCP協議在實際應用中出現的缺陷，2003年，自動化及測量系統標準協會（ASAM）基于CCP協議基礎上制定了XCP協議［10］。XCP協議中的同步激勵模式下，通過DAQ和STIM模式完成一個bypass周期只需要兩條命令，而且所要傳輸的多個變量數據同時被整合到一條DTO中傳輸，極大地提高了數據傳輸效率，可以高效、快速地完成ECU與原型系統兩者之間的同步［11］。

3.1 驅動事件

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

3.2 數據幀格式

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

圖4 ODT組成

4 應用舉例

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

為方便控制算法的開發與移植，測試的控制算法雙電位器電子油門控制算法由Simulink開發，然后通過Matlab由mdl文件生成dll文件。vCalitool工具完成對dll文件的調用，并實現相關參數的讀取。為方便標定工具控制ECU程序運行流程，本研究在ECU原有程序中添加byte型的軟件鉤software_switch，并對ECU原有程序進行相應地改動，以實現通過改變software_switch值就可以選擇切換不同的運行流程。

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

因觀察與試驗需要，本研究設定油門超下限故障臨界值APPCD_uAPP1_SRCMin_C為2 000 mV，超上限故障臨界值APPCD_uAPP1_SRCMax_C為4 000 mV，故障確認與恢復時間為2 s。設置DAQLIST0為DAQ模式，其中添加變量APPCD_stTstTrg1，第一路油門傳感器A/D采樣轉化值APPCD_uRawAPP1，第二路油門傳感器A/D采樣轉化值APPCD_uRawAPP2，事件通道為10 ms；設置DAQLIST1為STIM模式，其中添加變量加速踏板大腳油門狀態APPCD_stKickDown，過濾后傳感器信號APPCD_rFlt以及APPCD_stTstTrg1等故障狀態顯示量，事件通道為10 ms。實驗結果如圖5所示。

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

圖5 極值故障隨傳感器信號關系圖

如圖5所示，在13 s左右時，APPCD_uRawAPP1值在2 000 mV～4 000 mV范圍內，APPCD_stTstTrg1的值為32（0010 0000B），當油門值超過超上限故障臨界值4 000 mV后，APPCD_stTstTrg1的值變為66（0100 0010B），初步判定第一路油門傳感器超上限故障，當APPCD_uRawAPP1值超過4 000 mV持續時間超過故障確認時間2 s后，APPCD_stTstTrg1的值變為65（0100 0001B），當APPCD_uRawAPP1值恢復到正常值范圍后，APPCD_stTstTrg1的值變為36（0010 0100B），進入故障預恢復階段，2 s后APPCD_stTstTrg1的值又變為32（0010 0000B），ECU確認故障消失，當APPCD_uRawAPP1值低于2 000 mV時，APPCD_stTst-Trg1的值變為130（1000 0010B），初步判定第一路油門傳感器超下限故障，APPCD_uRawAPP1低于2 000 mB持續超過2 s后，APPCD_stTstTrg1的值變為129（1000 0001B），確認超下限故障，當APPCD_uRawAPP1值恢復到正常范圍后，如前所述，APPCD_stTstTrg1先進入故障預恢復，然后確認故障消失。本研究根據圖5的測試結果，將電子油門控制模塊通過XCP協議旁通后，能夠迅速將模塊輸入參數計算后反饋給ECU，對ECU的整體運行沒有產生影響。

5 結束語

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

（2）本研究所開發的vCalitool工具能充分實現BYPASS功能。通過XCP協議的同步激勵模式大大提升數據傳輸速度，迅速同步上位機與下位機數據，能夠滿足一般功能模塊的bypass需要。

（3）雖然vCalitool工具基于Windows系統開發，但是軟實時性良好。在140 000個測試循環中，延遲時間在0.6 ms～1.2 ms區間內出現頻次為占總循環數的99.99%以上能滿足bypass功能需求。

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

（5）bypass提高了在ECU設計階段時的設計靈活性，使設計不受原有ECU的RAM、I/O等條件的限制，更方便快捷地實現對新控制算法以及優化后的控制算法進行驗證，縮短了開發時間，節省項目經費。

（

）：

［1］葉險.基于模型的汽油機電控系統快速原型的研究［D］.成都：西華大學汽車工程學院，2012.

［2］謝異才.基于LabView的柴油機電控單元快速原型平臺的設計與開發［D］.昆明：昆明理工大學交通工程學院，2011.

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

［4］石琦文，孫曉民.基于Matlab的車用快速原型軟件平臺的研究與實現［J］.系統仿真學報，2005（13）：108-110.

［5］孔峰.關于EMS開發系統的研究與多功能發動機電控單元快速原型開發平臺-UECU的自主開發［D］.大連：大連理工大學能源與動力學院，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.標定和測量應用的焦點-XCP［J］.汽車零部件，2007（6）：42-44.

［9］蘇瑜，周文華，竺春狄.一種適用不同通信方式基于XCP協議的ECU標定工具的開發［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.