缸內直噴發動機的ECU自主設計及研發

本文結合公司自主研發的項目詳細分析了GDI發動機的ECU開發設計流程：Simulink模型的建立、代碼生成、主控制器的開發、底層程序集成和臺架測試等。臺架測試表明，該項目研發控制策略、硬件設計和系統集成過程都是正確的，這個過程將為汽車行業GDI發動機ECU的開發提供有益的借鑒。

隨著整車廠的競爭日趨激烈，隨之而來的是核心技術的競爭，而汽車的核心技術就是發動機技術。因此，整車廠將研發重點放在發動機技術的研發上面。隨著發動機技術的不斷提高，人們提出了直噴式汽油發動機GDI的概念。相對于傳統的發動機，它具有低油耗、低排放的優點，有利于降低車輛的運行成本和減輕環境污染。本文結合長城自主研發的項目詳細分析了GDI發動機的ECU開發設計流程：Simulink模型的建立、代碼生成、主控制器的開發、底層程序集成和臺架測試等。

Simulink模型的建立

1. 建立模型

近年來，Simulink已經成為汽車電子控制領域動態系統建模和仿真領域中應用最為廣泛的軟件之一。

Simulink采用模塊組合方式來建模，使用戶快速、準確地創建動態系統的計算機仿真模型，特別是對復雜的不確定非線性系統，更為方便。

此項目中，控制噴油點火的模型共有7個輸入量和4個輸出量。輸入量包括發動機轉速、發動機溫度、空氣流量、進氣壓力、進氣溫度、踏板開度1和踏板開度2；輸出量包括點火角、充磁時間、噴油脈寬和噴油起始角。圖1為計算點火角和噴油角的Simulink模型，其變量對應的屬性見表1。

2. 模型驗證

對該模塊進行測試仿真，數據采用的是長城發動機臺架上標定的dat文件，首先將數據轉化為Excel文本格式，然后把文本中的數據下載到Simulink的Signal Builder模塊中，進行仿真驗證。

采樣步長為0.01s，以噴油開始角的數據作為對比，仿真結果見圖2，圖中的黃線為噴油開始角的理想數據，粉線為模型的仿真結果。通過對比兩條曲線，可以看到理想數據和仿真結果之間的誤差。

從圖中明顯看出：模型仿真結果和理想數據之間的誤差很小，在允許的范圍內，而且實際的臺架測試，表明此模型生成的代碼對噴油起始角進行了很好的控制。

自動代碼生成

1. RTW介紹

Real–Time Workshop是由MathWorks公司提供的代碼自動生成工具，它可以使Simulink模型自動生成面向不同目標的代碼。

傳統的產品開發流程通常包括許多小組，各小組負責不同但又相互關聯的工作。他們之間缺乏有效的交流手段，通常是通過各種文檔、資料和數據等進行溝通。由于不同的小組專注的問題層面不同，很難準確理解和貫徹彼此的意圖，這無疑增大了產品開發的風險，延長了產品的上市時間。

在產品的開發過程中采用RTW可有效地提高產品的開發效率，進而降低成本。通過Simulink模型，RTW能自動生成面向不同目標系統的執行代碼。這樣，可以很快建立起系統模型，作為一個動態可執行規范，供各個小組快速地對系統進行檢驗，提出改進措施。自動代碼生成的功能實現了從系統設計到實現的完美過渡，大大減少了軟件工程師的編碼工作量。

2. 噴油點火模型代碼的生成

模型的仿真驗證工作完成后，對模型進行設置以自動生成代碼。以噴油點火模型為例，首先打開Configuration Parameters對話框對生成的代碼進行配置，具體配置情況見圖3。

除了對Real-Time Workshop進行配置以外，還要對Solve、Optimization和Diagnostics等進行配置。

配置完成后點擊Generate code按鈕或者使用鍵盤Ctrl+B自動生成該模型對應的C代碼（見圖4）。

將生成的所有的C文件和H文件都添加到底層程序所在的工程中，下載到控制器后就可以進行臺架試驗。

主控制器的開發

1. 硬件需求分析

項目組接到任務后，首先要做的工作就是進行硬件需求分析，撰寫硬件需求說明書。硬件需求分析在整個產品開發過程中非常關鍵，硬件工程師應對這一項內容加以重視。

硬件需求分析主要包括硬件開發目標、基本功能、基本配置、主要性能指標、運行環境、約束條件及開發經費和進度等信息。它是硬件總體設計和制訂硬件開發計劃的依據，具體編寫的內容有：系統工程組成及使用說明、硬件整體系統的基本功能和主要性能指標、硬件分系統的基本功能和主要性能指標及功能模塊的劃分等。

2. 硬件總體方案設計

硬件開發總體方案對整個系統進一步具體化。硬件開發總體設計是最重要的環節之一，總體設計不好，可能出現很嚴重的問題，造成的損失有許多是無法挽回的，產品的好壞特別是系統設計的合理性、科學性、可靠性、穩定性與總體設計關系密切。

硬件總體設計對各個分系統的任務以及關聯關系進一步明確，它是硬件詳細設計的依據。硬件總體設計應包含以下內容：系統總體結構及功能劃分、系統邏輯框圖、系統各功能模塊的邏輯框圖、電路結構圖及單板組成、單板邏輯框圖和電路結構圖，以及可靠性、安全性、電磁兼容性討論和硬件測試方案等。

3. 硬件詳細方案設計

單板硬件詳細設計，要遵守公司的硬件設計技術規范，必須對物料選用以及成本控制上加以注意。需要硬件工程師在工作中不斷應用，不斷充實和修正。

硬件詳細設計主要有：單板邏輯框圖及各功能模塊詳細說明，各功能模塊實現方式、控制方式、接口方式、接口管腳信號詳細定義、性能指標，單板原理圖、PCB圖、詳細物料清單及單板測試、調試計劃。

4. 樣品制作

取回PCB板及物料之后，焊好1～2塊單板，焊接過程中需要進行部分功能調試。同時需要對樣品進行命名。

5. 系統聯調

首先是硬件功能測試，確保每個功能都能實現，每項指標都能滿足。硬件測試沒問題之后，配合軟件工程師對系統進行聯調，撰寫系統聯調報告。聯調是整機性能提高，穩定的重要環節，可以幫助發現各單板以及整體設計的不足，也是驗證是否達到設計要求的重要方法。因此，聯調是必須預先做好聯調計劃，并對整個聯調過程進行詳細記錄。只有對各個環節驗證到位才能保證機器走向市場后工作的可靠性和穩定性。
　　
操作系統程序集成

1. 底層驅動提供函數及變量的分析

接到集成任務后，首先要對底層驅動所能提供的函數及變量進行分析，清楚從底層驅動獲取的變量的類型、單位和數據范圍等，便于在集成時對變量進行控制。此外，應掌握驅動發動機執行器的執行函數所需的參數類型，便于將上層控制策略生成的相關變量進行類型轉換和賦值操作。

2. 操作系統任務的劃分與調度

根據各模塊時間響應性及其功能，對任務進行初步劃分和調度。操作系統的調度方式分為完全搶占式調度、非搶占式調度和混合搶占式調度三種。完全搶占式調度用于保存現場的內存占用較大，理論上可以在任務的任何位置重調度， 因此任務必須同步訪問共享資源，增加了系統的復雜性。非搶占調度通過調用某些服務例程實現任務切換，即用戶設置重調度點。通過定義任務組使多個任務同時具有搶占或非搶占調度的特征。混合搶占調度適合搶占任務和非搶占任務共存于一個系統時使用。在這種情況下，調度策略依賴于正在運行任務的搶占特性，開發者通過配置任務優先級和搶占屬性來定義任務執行順序。

3. 系統聯調及測試

系統集成工作完成后，需要進行系統聯調及測試。

（1）將集成好的軟件通過編譯器進行編譯、鏈接，檢測是否存在語法錯誤及會影響系統正常運行的警告，若有，根據錯誤找出原因進行修改，直至編譯鏈接完全通過為止。

（2）將編譯鏈接后無誤的程序下載到發動機ECU中，對整個系統進行分析，直至確定操作系統的調度與預期目標一致，整個系統可以正常運轉為止。

（3）將發動機ECU與發動機信號模擬器通過線束對接，為ECU輸入相應信號，看其能否進行正常的噴油點火。若不能，找出原因并修改，直至噴油點火信號正常運行為止。

（4）通過功能試驗臺為ECU輸入所需的各種模擬的發動機傳感器相關信號，再通過發動機信號模擬器輸入傳感器的信號。此刻，ECU所需信號已經全部輸入完畢，ECU能正常工作，采集4個缸的噴油點火信號并與原機數據進行比較，觀察其誤差范圍，若噴油脈寬及點火充磁時間的誤差＜1ms，則認為此策略可用。

（5）確保以上測試均沒有任何問題后，即可進行發動機臺架試驗。

4. 噴油點火模型輸出變量

噴油執行函數包括兩個參數fuel_width_value和inj_angle，分別是噴油脈寬和噴油起始時刻，關于這兩個參數在底層驅動中的定義見表2。只需要將模型中的兩個變量分別對應上底層驅動函數中的兩個變量即可。

同樣，點火執行函數包括兩個參數ign_time和ign_angle，分別是充磁時間和跳火時刻，關于這兩個參數在底層驅動中的定義見表3。只需要將模型中的兩個變量分別對應上底層驅動函數中的兩個變量即可。

臺架測試結果

從發動機臺架測試試驗測試結果（見表4）可以看出，噴油量、噴油起始角、充磁時間和點火角都得到了很好的控制。

結語

在汽車的發動機研發過程中，隨著Simulink模型的進一步可視化、統一化及簡單化，基于模型的控制策略開發已經逐步代替了傳統的手工編寫C代碼過程，這在本文中的GDI項目中得到了很好地體現。臺架測試表明，該項目研發控制策略、硬件設計和系統集成過程都是正確的，這個過程將為汽車行業GDI發動機ECU的開發提供有益的借鑒。