田韶鵬，闕同亮

（武漢理工大學(xué) 現(xiàn)代汽車零部件技術(shù)湖北省重點實驗室 汽車零部件技術(shù)湖北省協(xié)同創(chuàng)新中心，武漢 430070）

隨著電動汽車的快速發(fā)展，企業(yè)對電子控制系統(tǒng)的性能與開發(fā)效率提出了越來越高的要求，傳統(tǒng)手寫代碼的開發(fā)方式周期長、調(diào)試難度大，逐漸不適用于現(xiàn)代電控系統(tǒng)的開發(fā)。而隨著Matlab/Simulink的廣泛應(yīng)用，基于模型的設(shè)計流程越來越多地應(yīng)用在電控系統(tǒng)開發(fā)過程中[1-2]。利用Matlab/Simulink工具搭建控制模型，在設(shè)計初期就可以直觀地反映設(shè)計需求，進(jìn)行系統(tǒng)設(shè)計，并通過不斷仿真對設(shè)計進(jìn)行驗證。在實現(xiàn)階段可利用模型直接生成代碼，完成軟硬件的集成，可以大大提高開發(fā)效率[3]。同時生成的代碼還具有規(guī)范、安全、高效的特點。

本文根據(jù)目標(biāo)電動車需求設(shè)計整車控制器的控制策略，利用Matlab/Simulink建立控制模型，生成應(yīng)用層代碼，并將代碼與底層驅(qū)動集成后下載到目標(biāo)硬件平臺進(jìn)行硬件實測，驗證代碼的有效性。

1 整車控制策略開發(fā)

1.1 整車研究對象和需求分析

本文以某小型純電動物流車作為研究平臺，開發(fā)其適用的整車控制器，其整車控制結(jié)構(gòu)如圖1所示。

圖1 整車控制結(jié)構(gòu)Fig.1 Structure diagram of the target vehicle

整車控制器需要接收來自加速踏板、制動踏板、變速器、點火開關(guān)等的信號，通過CAN總線傳輸?shù)碾姍C(jī)控制器、電池的CAN報文，根據(jù)相應(yīng)的控制方法輸出對電機(jī)、電池、高壓配電柜的控制信號。具體功能有：①整車控制器需要采集駕駛員的操作動作，并通過對其他控制器的控制實施駕駛員的操作意圖，實現(xiàn)車輛的正常行駛并具有限速功能；②整車控制器能夠?qū)φ嚹芰窟M(jìn)行管理，調(diào)度電池能量輸出，以增大電動車的行駛里程；③整車控制器還需要具有故障診斷和管理功能，能夠根據(jù)故障嚴(yán)重程度進(jìn)行合理的故障處理，如提示駕駛員或跛行模式，保障行車安全；④研究對象電動車使用五檔變速器，但不具有檔位位置傳感器和車速傳感器，因此整車控制器還需要根據(jù)變速器兩端轉(zhuǎn)速的比值進(jìn)行判斷檔位位置，并利用計算得到的檔位進(jìn)行車速計算。在倒檔時整車控制器還需要控制相關(guān)設(shè)備發(fā)出提示。

控制器的處理芯片來自飛思卡爾公司的MC9S12XEP100單片機(jī)，底層軟件已經(jīng)完成開發(fā)，具有可靠的實時運行環(huán)境，利用底層環(huán)境預(yù)留的接口函數(shù)，即可獲得信號輸入和輸出控制信號。因此在開發(fā)階段開發(fā)人員專注于控制策略的開發(fā)即可。

1.2 整車控制策略開發(fā)

本項目從純電動汽車的運行工況角度出發(fā)，設(shè)計整車控制策略，將電動車控制策略分為起步模式、正常行駛模式、制動能量回收模式和跛行模式。

起步模式指電動車啟動開關(guān)打開并掛在前進(jìn)檔，但加速踏板開度為0的狀態(tài)。起步模式的主要功能是防止電動車在上坡起步時溜車。根據(jù)電機(jī)控制器輸出的電機(jī)轉(zhuǎn)向和轉(zhuǎn)速，整車控制器可判斷車輛是否處于上坡起步狀態(tài)，如檢查到處于上坡起步狀態(tài)，將控制電機(jī)輸出一克服坡度的正轉(zhuǎn)矩，到達(dá)不溜車的目的。

電動車處于正常行駛模式時，需要根據(jù)電機(jī)轉(zhuǎn)速、加速踏板開度，并結(jié)合加速踏板解析策略，計算加速轉(zhuǎn)矩。對于加速踏板的解析策略，如圖2所示通常分為3種[4-7]。曲線A偏重動力性，曲線C偏重經(jīng)濟(jì)性，曲線B作為折中方案，處理關(guān)系簡單，易于實現(xiàn)，考慮車輛的主要用途和成本，選曲線B作為加速踏板基礎(chǔ)解析策略。

圖2 加速踏板的解析策略Fig.2 Analysis strategy of acceleration pedal

由于研究對象電動車以氣壓制動系統(tǒng)為主進(jìn)行制動，只有制動踏板開關(guān)傳感器，且機(jī)械制動無法調(diào)整。因此采用輕度制動能量回饋策略，設(shè)置一恒定的較小的電制動力，并以某一斜率遞增到此恒定值。電機(jī)高轉(zhuǎn)速時受到最大功率限制，低轉(zhuǎn)速時回饋效率低，所以能量回饋只在兩區(qū)間內(nèi)進(jìn)行。另外SOC較高時，為防止過度充電，也不進(jìn)行能量回饋。

當(dāng)電動車需要進(jìn)行能量管理或故障管理時，即進(jìn)入跛行模式。當(dāng)電池SOC或電壓低于某一值時，整車控制器將限制電機(jī)的輸出轉(zhuǎn)矩，以達(dá)到增大電動車行駛里程的目的。本項目中使用階梯式的轉(zhuǎn)矩限制策略，隨著SOC的逐漸降低，對轉(zhuǎn)矩的限制逐漸增大。

當(dāng)整車控制器接收到電機(jī)控制器、電池管理系統(tǒng)或高壓配電柜出現(xiàn)故障時，整車控制器將根據(jù)故障等級進(jìn)行故障處理。本項目中將故障分為3級，一級故障屬于嚴(yán)重故障，故障處理方式為強(qiáng)制停車；二級故障將限制電機(jī)輸出，使電動車進(jìn)入跛行模式，并提醒駕駛員靠邊停車檢查或前往維修點檢測；三級故障為輕微故障，將使用儀表提示駕駛員出現(xiàn)故障，不影響電機(jī)輸出。

2 控制模型的搭建與自動代碼生成

2.1 模型的搭建

控制策略的實現(xiàn)是由自動代碼生成完成，模型的搭建需要考慮生成代碼功能的清晰劃分。所以根據(jù)功能的相關(guān)程度進(jìn)行模塊化建模，將控制模型分為高壓上電模塊、驅(qū)動力計算模塊、制動能量回饋模塊、檔位計算模塊、能量管理模塊和故障管理模塊。同時將模型的輸入輸出端和控制模型分離，以使上層應(yīng)用軟件與底層驅(qū)動集成方便，行車模式的建模使用Stateflow創(chuàng)建有限狀態(tài)機(jī)模型，根據(jù)功能模塊的計算結(jié)果和輸入信號進(jìn)行模式轉(zhuǎn)換。

完成建模后還需要對模型進(jìn)行功能檢查。使用Simulink自帶的Design Verifier可檢查模型的設(shè)計錯誤，包括是否存在死循環(huán)、數(shù)據(jù)溢出等。在運行Design Verifier后，可得到相關(guān)報告，內(nèi)容包括檢查的目標(biāo)、使用的分析方法、每個信號的取值范圍等。

圖3 車輛狀態(tài)機(jī)模型的Design Verifier報告Fig.3 Design Verifier report of vehicle state machine

檢查設(shè)計錯誤后，還可以利用Design Verifier自動生成測試用例。根據(jù)需要選擇測試的內(nèi)容，主要包括了決策覆蓋、條件覆蓋、MC/DC覆蓋、Lookup table覆蓋等。

以車輛狀態(tài)機(jī)模型為例，在覆蓋度上選擇前三項覆蓋內(nèi)容，生成測試用例，并進(jìn)行仿真，仿真后可得到覆蓋度報告。覆蓋度報告可以看出Design Verifier將每種條件組合，生成測試用例，檢查每個帶有判斷條件的模塊能否實現(xiàn)。100%覆蓋度表明測試用例覆蓋了判斷條件的每個分支，說明狀態(tài)機(jī)模型不存在死循環(huán)或無法達(dá)到的狀態(tài)。

圖4 測試用例的部分覆蓋度報告Fig.4 Part of coverage report of the test model

2.2 自動代碼生成技術(shù)

要進(jìn)行自動代碼生成，在Simulink模型中至少有3部分需要配置：解算器（sovler）；系統(tǒng)目標(biāo)文件（system target file）；目標(biāo)硬件設(shè)置（hardware implementation）。

由于模型只生成應(yīng)用層代碼，手動集成應(yīng)用層與底層軟件，目標(biāo)硬件設(shè)置為通用即可，芯片類型根據(jù)使用芯片的規(guī)格，選擇16位嵌入式處理器。

對于解算器，其類型需設(shè)置為固定步長。由于模型是用于生產(chǎn)嵌入式代碼，并下載到單片機(jī)中運行，而單片機(jī)總是以時鐘源提供的穩(wěn)定頻率運行，無法進(jìn)行變步長運算，所以兩采樣點間的時間間隔要設(shè)為固定。步長的大小取決于對計算精度和速度的平衡，步長越小，精度越高，而計算的速度越慢。在目標(biāo)硬件為通用的情況下，對代碼生成沒有影響，本文設(shè)置為0.01 s。

其次將系統(tǒng)目標(biāo)文件選擇為Embedded Coder的ert.tlc。Embedded Coder是可生成用于嵌入式單片機(jī)的實時C代碼的編碼器。TLC文件的作用是將模型編譯出的RTW文件轉(zhuǎn)換為支持某平臺或硬件的代碼。

完成以上設(shè)置后，點擊Build Model即可生成代碼。但是此時生成代碼的可讀性和執(zhí)行效率都較差，不具備于底層驅(qū)動集成的條件。所以必須優(yōu)化代碼生成過程，以生成質(zhì)量更高的代碼。

2.3 生成代碼的優(yōu)化

生成代碼優(yōu)化通?？煞譃閮煞矫?，一是優(yōu)化模型中模塊的參數(shù)和信號線的數(shù)據(jù)類型和存儲類型。二是優(yōu)化子系統(tǒng)的代碼生成，使生成的代碼存放在指定文件的指定函數(shù)中。

默認(rèn)情況下信號線以double型變量定義，并且參數(shù)和信號線都以結(jié)構(gòu)體形式生成代碼，這會使得參數(shù)和信號線在調(diào)用時都產(chǎn)生冗長的代碼，降低可讀性，并加重RAM的儲存和單片機(jī)的計算負(fù)擔(dān)。

模塊參數(shù)優(yōu)化方式是將參數(shù)設(shè)置為以內(nèi)聯(lián)（Inline）形式生成代碼，這樣在參數(shù)調(diào)用時會以常數(shù)形式展開到代碼中，并將常數(shù)儲存在單片機(jī)的ROM中，大大增強(qiáng)代碼可讀性，并減少了RAM占用。對于信號線的優(yōu)化，首先在Matlab中創(chuàng)建數(shù)據(jù)對象，同時為模型中的信號線賦上相同名稱，并設(shè)置信號線與同名數(shù)據(jù)對象綁定，即可在Base Workspace中對信號線統(tǒng)一進(jìn)行設(shè)置。根據(jù)不同的計算要求，修改變量的數(shù)據(jù)類型，將默認(rèn)的double型按需改為不同長度的整型或定點型。信號線的存儲類型為ExportedGlobal，這樣信號線變量以全局變量的形式定義，接近傳統(tǒng)編程習(xí)慣。信號線定義優(yōu)化前后對比如圖5所示。

圖5 信號線的定義優(yōu)化前后對比Fig.5 Signal definition comparison between before and after optimization

對于子系統(tǒng)，優(yōu)化前其代碼直接展開在代碼生成框架的model_step函數(shù)中不利于功能的劃分和函數(shù)調(diào)用。因此在創(chuàng)建子系統(tǒng)時，將其設(shè)置為原子系統(tǒng)，并按需將子系統(tǒng)的函數(shù)打包方式設(shè)置為不可重用和可重用函數(shù)，這樣在代碼生成時，會為每個子系統(tǒng)生成函數(shù)，在與底層軟件集合時，方便調(diào)用和重用。

2.4 代碼驗證與軟件在環(huán)測試

為了保證生成的C代碼與模型功能的一致性，驗證C代碼，查找可能存在的缺陷，在代碼與底層集合前還需要進(jìn)行軟件在環(huán)（SiL）或硬件在環(huán)測試（HiL）。本項目由于缺乏HiL相關(guān)設(shè)備，故使用SiL方法測試代碼。

進(jìn)行SiL仿真前，要先根據(jù)使用的16位MCU設(shè)置仿真環(huán)境，以模擬實際運行環(huán)境。使用Model reference模塊，調(diào)用經(jīng)過調(diào)試的驅(qū)動力計算模型，調(diào)用后可設(shè)置為以正常方式仿真，或?qū)⒛Ｐ途幾g成C代碼再進(jìn)行仿真。利用Design Verifier生成的測試用例作為輸入，將Simulink模型運行結(jié)果與代碼運行結(jié)果比較，并計算兩者間的誤差。

SiL仿真結(jié)果如圖6所示。第一幅圖為加速踏板的模擬量輸入，實際電壓值為范圍為0～5 V，對應(yīng)單片機(jī)的模擬量輸入為0～4095。為了避免踏板位置傳感器的誤差，以0.7 V和3.8 V作為踏板輸入的起始點。在此范圍外的輸入會以0%或100%踏板位置計算；第二幅圖為Simulink模型計算的驅(qū)動力，從圖中可看出其變化趨勢與輸入相同，并在踏板輸入超過限值時以最大轉(zhuǎn)矩110 N·m和0 N·m輸出；第三幅為模型與代碼計算的誤差；第四幅圖為模型編譯成C代碼后的計算結(jié)果。從最后2幅圖可看出C代碼計算結(jié)果變化趨勢與模型設(shè)計的基本相同，計算誤差在0～1.6 N·m范圍內(nèi)，滿足使用要求。證明該模塊生成的C代碼可用。

圖6 驅(qū)動力模塊SiL結(jié)果Fig.6 Result of SiL test of driving force model

3 軟件集成與處理器在環(huán)測試

3.1 應(yīng)用層與底層驅(qū)動的集成

完成優(yōu)化并驗證代碼后，可進(jìn)行與底層驅(qū)動的集成工作。生成代碼會產(chǎn)生如圖7所示文件。

其中ert_main.c為Embedded Coder根據(jù)模型生成的簡單邏輯主函數(shù)文件，集成時不需要使用。rtwtypes.h主要存放數(shù)據(jù)類型別名和復(fù)雜數(shù)據(jù)類型的定義，由于底層驅(qū)動已經(jīng)定義好數(shù)據(jù)類型，同時建模時使用的數(shù)據(jù)類型依照驅(qū)動的定義，此文件也無需使用。其他文件加入到CodeWarrior集成開發(fā)環(huán)境中，在底層驅(qū)動中調(diào)用變量和函數(shù)，即可完成與驅(qū)動的集合。

3.2 硬件實測

整車控制器本身支持CCP協(xié)議的通訊方式，可以通過支持CCP的標(biāo)定監(jiān)控軟件在電腦上讀取程序在整車控制器的運行情況，監(jiān)控和標(biāo)定整車控制器內(nèi)部變量。本項目中，為了驗證生成代碼在硬件上運行的有效性，利用信號發(fā)生器和CAN通訊卡產(chǎn)生加速踏板，制動踏板信號，電機(jī)狀態(tài)報文等，模擬車輛運行的不同狀態(tài)。標(biāo)定監(jiān)控軟件如圖8所示。

圖7 生成文件Fig.7 Files genarated by embedded coder

圖8 硬件結(jié)果Fig.8 Result of hardware test

從測試結(jié)果可看出，整車控制器的運行可以達(dá)到預(yù)期效果，能夠?qū)崟r地對輸入信號做出反應(yīng)，根據(jù)輸入信號切換車輛的運行狀態(tài)，并能夠正確計算出車輛狀態(tài)、車速、檔位等關(guān)鍵信息。證明了自動生成的代碼能夠滿足設(shè)計要求，運行穩(wěn)定可靠。

4 結(jié)語

本文采用代碼自動生成方式設(shè)計并實現(xiàn)了整車控制器的應(yīng)用層程序，充分利用Simulink工具，驗證模型并優(yōu)化代碼生成過程，減少代碼尺寸，提高了代碼可讀性和運行效率，最后利用硬件實測驗證了代碼的有效性。代碼自動生成方式開發(fā)整車控制器，不僅能在功能設(shè)計階段就將需求和模型整合，還能減少手寫編程和代碼調(diào)試的時間，大大提高了開發(fā)效率，加快項目進(jìn)展。

[1]周兵，萬吉奎，劉志遠(yuǎn)，等.動機(jī)控制器虛擬測試系統(tǒng)的開發(fā)與驗證[J].現(xiàn)代制造工程，2015（8）：126-131.

[2]許保同.基于Simulink的純電動汽車VCU控制策略設(shè)計方法[J].汽車工程師，2016（5）：19-21.

[3]孫忠瀟.Simulink仿真及代碼生成技術(shù)入門到精通[M].北京：北京航天航空大學(xué)出版社，2015.

[4]朱曉琪.純電動汽車整車控制器開發(fā)[D].吉林：吉林大學(xué)，2015.

[5]劉永山.純電動汽車整車控制器開發(fā)及控制策略研究[D].武漢：武漢理工大學(xué)，2014.

[6]吳敏.電動汽車整車控制器基礎(chǔ)軟件開發(fā)及控制策略研究[D].吉林：吉林大學(xué)，2014.

[7]徐凱.純電動汽車整車控制系統(tǒng)研究和設(shè)計[D].太原：太原理工大學(xué)，2016.