基于模型設計的電動車整車控制器開發研究

田韶鵬，闕同亮

（武漢理工大學 現代汽車零部件技術湖北省重點實驗室 汽車零部件技術湖北省協同創新中心，武漢 430070）

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

本文根據目標電動車需求設計整車控制器的控制策略，利用Matlab/Simulink建立控制模型，生成應用層代碼，并將代碼與底層驅動集成后下載到目標硬件平臺進行硬件實測，驗證代碼的有效性。

1 整車控制策略開發

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

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

圖1 整車控制結構Fig.1 Structure diagram of the target vehicle

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

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

1.2 整車控制策略開發

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

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

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

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

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

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

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

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

2.1 模型的搭建

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

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

圖3 車輛狀態機模型的Design Verifier報告Fig.3 Design Verifier report of vehicle state machine

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

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

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

2.2 自動代碼生成技術

要進行自動代碼生成，在Simulink模型中至少有3部分需要配置：解算器（sovler）；系統目標文件（system target file）；目標硬件設置（hardware implementation）。

由于模型只生成應用層代碼，手動集成應用層與底層軟件，目標硬件設置為通用即可，芯片類型根據使用芯片的規格，選擇16位嵌入式處理器。

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

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

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

2.3 生成代碼的優化

生成代碼優化通常可分為兩方面，一是優化模型中模塊的參數和信號線的數據類型和存儲類型。二是優化子系統的代碼生成，使生成的代碼存放在指定文件的指定函數中。

默認情況下信號線以double型變量定義，并且參數和信號線都以結構體形式生成代碼，這會使得參數和信號線在調用時都產生冗長的代碼，降低可讀性，并加重RAM的儲存和單片機的計算負擔。

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

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

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

2.4 代碼驗證與軟件在環測試

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

進行SiL仿真前，要先根據使用的16位MCU設置仿真環境，以模擬實際運行環境。使用Model reference模塊，調用經過調試的驅動力計算模型，調用后可設置為以正常方式仿真，或將模型編譯成C代碼再進行仿真。利用Design Verifier生成的測試用例作為輸入，將Simulink模型運行結果與代碼運行結果比較，并計算兩者間的誤差。

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

圖6 驅動力模塊SiL結果Fig.6 Result of SiL test of driving force model

3 軟件集成與處理器在環測試

3.1 應用層與底層驅動的集成

完成優化并驗證代碼后，可進行與底層驅動的集成工作。生成代碼會產生如圖7所示文件。

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

3.2 硬件實測

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

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

圖8 硬件結果Fig.8 Result of hardware test

從測試結果可看出，整車控制器的運行可以達到預期效果，能夠實時地對輸入信號做出反應，根據輸入信號切換車輛的運行狀態，并能夠正確計算出車輛狀態、車速、檔位等關鍵信息。證明了自動生成的代碼能夠滿足設計要求，運行穩定可靠。

4 結語

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

[1]周兵，萬吉奎，劉志遠，等.動機控制器虛擬測試系統的開發與驗證[J].現代制造工程，2015（8）：126-131.

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

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

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

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

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

[7]徐凱.純電動汽車整車控制系統研究和設計[D].太原：太原理工大學，2016.