缸內(nèi)直噴發(fā)動機的ECU自主設(shè)計及研發(fā)

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

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

Simulink模型的建立

1. 建立模型

近年來，Simulink已經(jīng)成為汽車電子控制領(lǐng)域動態(tài)系統(tǒng)建模和仿真領(lǐng)域中應(yīng)用最為廣泛的軟件之一。

Simulink采用模塊組合方式來建模，使用戶快速、準(zhǔn)確地創(chuàng)建動態(tài)系統(tǒng)的計算機仿真模型，特別是對復(fù)雜的不確定非線性系統(tǒng)，更為方便。

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

2. 模型驗證

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

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

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

自動代碼生成

1. RTW介紹

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

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

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

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

模型的仿真驗證工作完成后，對模型進行設(shè)置以自動生成代碼。以噴油點火模型為例，首先打開Configuration Parameters對話框?qū)ι傻拇a進行配置，具體配置情況見圖3。

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

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

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

主控制器的開發(fā)

1. 硬件需求分析

項目組接到任務(wù)后，首先要做的工作就是進行硬件需求分析，撰寫硬件需求說明書。硬件需求分析在整個產(chǎn)品開發(fā)過程中非常關(guān)鍵，硬件工程師應(yīng)對這一項內(nèi)容加以重視。

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

2. 硬件總體方案設(shè)計

硬件開發(fā)總體方案對整個系統(tǒng)進一步具體化。硬件開發(fā)總體設(shè)計是最重要的環(huán)節(jié)之一，總體設(shè)計不好，可能出現(xiàn)很嚴(yán)重的問題，造成的損失有許多是無法挽回的，產(chǎn)品的好壞特別是系統(tǒng)設(shè)計的合理性、科學(xué)性、可靠性、穩(wěn)定性與總體設(shè)計關(guān)系密切。

硬件總體設(shè)計對各個分系統(tǒng)的任務(wù)以及關(guān)聯(lián)關(guān)系進一步明確，它是硬件詳細(xì)設(shè)計的依據(jù)。硬件總體設(shè)計應(yīng)包含以下內(nèi)容：系統(tǒng)總體結(jié)構(gòu)及功能劃分、系統(tǒng)邏輯框圖、系統(tǒng)各功能模塊的邏輯框圖、電路結(jié)構(gòu)圖及單板組成、單板邏輯框圖和電路結(jié)構(gòu)圖，以及可靠性、安全性、電磁兼容性討論和硬件測試方案等。

3. 硬件詳細(xì)方案設(shè)計

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

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

4. 樣品制作

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

5. 系統(tǒng)聯(lián)調(diào)

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

1. 底層驅(qū)動提供函數(shù)及變量的分析

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

2. 操作系統(tǒng)任務(wù)的劃分與調(diào)度

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

3. 系統(tǒng)聯(lián)調(diào)及測試

系統(tǒng)集成工作完成后，需要進行系統(tǒng)聯(lián)調(diào)及測試。

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

（2）將編譯鏈接后無誤的程序下載到發(fā)動機ECU中，對整個系統(tǒng)進行分析，直至確定操作系統(tǒng)的調(diào)度與預(yù)期目標(biāo)一致，整個系統(tǒng)可以正常運轉(zhuǎn)為止。

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

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

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

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

噴油執(zhí)行函數(shù)包括兩個參數(shù)fuel_width_value和inj_angle，分別是噴油脈寬和噴油起始時刻，關(guān)于這兩個參數(shù)在底層驅(qū)動中的定義見表2。只需要將模型中的兩個變量分別對應(yīng)上底層驅(qū)動函數(shù)中的兩個變量即可。

同樣，點火執(zhí)行函數(shù)包括兩個參數(shù)ign_time和ign_angle，分別是充磁時間和跳火時刻，關(guān)于這兩個參數(shù)在底層驅(qū)動中的定義見表3。只需要將模型中的兩個變量分別對應(yīng)上底層驅(qū)動函數(shù)中的兩個變量即可。

臺架測試結(jié)果

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

結(jié)語

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