王 斌，胡艷峰，王保平，鄭 欣，徐 峰

（陜西重型汽車有限公司汽車工程研究院，陜西 西安 710200）

1 故障描述

某車廠開發(fā)的一款混合動力電動汽車，有3種模式：純電動模式、混合動力模式以及發(fā)動機(jī)模式。在正常情況下，應(yīng)是發(fā)動機(jī)先自檢，確認(rèn)正常后發(fā)動機(jī)停機(jī)，然后純電動起步?，F(xiàn)在問題是，在鑰匙打到Start擋后，發(fā)動機(jī)啟動并完成自檢，且整車滿足純電起步的條件，但發(fā)動機(jī)一直工作沒有停機(jī) （或只偶爾情況下停機(jī)），即使駕駛室操作EV純電模式開關(guān)請求車輛純電模式運行，發(fā)動機(jī)仍不停機(jī)。

2 當(dāng)前發(fā)動機(jī)停機(jī)指令分析

此時的發(fā)動機(jī)停機(jī)指令，實際是借用ABS控制器發(fā)送的輔助發(fā)動機(jī)停機(jī)CAN信號來完成的。采用CAN總線信號實現(xiàn)發(fā)動機(jī)停機(jī)，通信報文見表1。

表1 發(fā)動機(jī)停機(jī)報文

發(fā)動機(jī)在接收到EBC1報文時，若Byte4 Bit6 Bit5值為“01”時，發(fā)動機(jī)控制器將控制發(fā)動機(jī)停止噴油，發(fā)動機(jī)轉(zhuǎn)速逐漸下降，直至發(fā)動機(jī)停機(jī)，因此該報文應(yīng)該持續(xù)發(fā)送直到發(fā)動機(jī)停機(jī)為止 （停機(jī)過程不可終止該報文發(fā)送）。原因是若停機(jī)的過程中，該報文接收終止，發(fā)動機(jī)轉(zhuǎn)速還在一定轉(zhuǎn)速以上時，發(fā)動機(jī)會自行恢復(fù)到正常運行狀態(tài)。車輛網(wǎng)絡(luò)架構(gòu)如圖1所示。

3 故障分析

圖1 車輛網(wǎng)絡(luò)架構(gòu)

由總線拓?fù)淇芍?，整車?條CAN線，動力CAN1及車身CAN2，通信速率都是250k。其中ABS及發(fā)動機(jī)控制器 （EEC）都在CAN1上，當(dāng)車輛ON擋后，整車高低壓都上電，此時網(wǎng)絡(luò)通信開始，ABS控制器會按照SAE J1939的要求發(fā)送自己的報文。當(dāng)Start后，發(fā)動機(jī)啟動自檢，同時混動整車控制器 （HCU）會監(jiān)測動力電池電量、氣壓等車輛相關(guān)狀態(tài)，滿足純電起步后，HCU會控制EEC停機(jī)，即發(fā)送借用的EBC1報文中的輔助發(fā)動機(jī)停機(jī)信號來使發(fā)動機(jī)停機(jī)。這時，問題出來了，ABS發(fā)送EBC1，HCU也發(fā)送EBC1，根據(jù)CAN通信的原理，一個CAN網(wǎng)段上不能出現(xiàn)2個相同的ID，因此EEC無法響應(yīng)HCU發(fā)送的EBC1報文，從而導(dǎo)致發(fā)動機(jī)無法停機(jī)。

4 解決方案

4.1 避免同一個CAN網(wǎng)段上發(fā)送2個相同ID的CAN報文

由于該車型匹配的是電控發(fā)動機(jī)，發(fā)動機(jī)在出廠前已經(jīng)內(nèi)部刷了程序，只對源地址0B的EBC1報文有響應(yīng)。因此要實現(xiàn)HCU通過EBC1控制發(fā)動機(jī)停機(jī)，只能是ABS控制器修改發(fā)送EBC1報文的源地址。但和ABS廠家溝通，廠家表示產(chǎn)品已經(jīng)批量化且符合SAE J1939規(guī)定，所以無法修改EBC1源地址。

4.2 考慮是否可以現(xiàn)場改線，更改為硬線控制

圖2為發(fā)動機(jī)控制器EEC的部分硬線輸入PIN腳。其中K67為車下發(fā)動機(jī)啟動開關(guān)，車輛維修或上裝取力時可以車下啟動發(fā)動機(jī)。車下啟停開關(guān)為選用裝置，并且用此功能停機(jī)必須在停車即車速為0的條件下才有效。因此行車過程中要停止發(fā)動機(jī)無法借用該開關(guān)，所以行車中如果遇到需要停止發(fā)動機(jī)的情況，這種硬線方式還是無法實現(xiàn)。

圖2 發(fā)動機(jī)控制器部分硬線PIN腳

4.3 總線控制

車下啟停發(fā)動機(jī)功能，除了上述的車下啟停發(fā)動機(jī)硬線開關(guān)能實現(xiàn)此功能外，發(fā)動機(jī)ECU也可以響應(yīng)總線的報文信號實現(xiàn)此功能，需要停機(jī)時，整車控制器發(fā)送CAN信號控制發(fā)動機(jī)停機(jī)。查看發(fā)動機(jī)通訊協(xié)議，發(fā)現(xiàn)有ID為0x0CFF0431的DEC1（開關(guān)控制器）報文，見表2。

表2 DEC1報文

Byte2的Bit6、5車下停止發(fā)動機(jī)信號，可以實現(xiàn)發(fā)動機(jī)的停機(jī)。根據(jù)PGN=00FF04=65284，查看SAE J1939，得知65284為一個制造商自定義的PGN。由此可以看出發(fā)動機(jī)開放DEC1報文是他們自己定義的，專門用于車下啟停發(fā)動機(jī)。由于車下啟停功能是在車輛停止的情況下才能使用的，因此該DEC1報文應(yīng)用的一個限制條件就是車速必須為0，發(fā)動機(jī)才會響應(yīng)DEC1發(fā)送的發(fā)動機(jī)停機(jī)信號。所以在行車時如果要發(fā)動機(jī)停機(jī)，DEC1還是實現(xiàn)不了，當(dāng)然我們可以屏蔽車速信號，但又存在一定的安全隱患。

4.4 又回到EBC1報文

HCU借用EBC1來停止發(fā)動機(jī)，由于與ABS也發(fā)EBC1標(biāo)識符沖突，導(dǎo)致無法停機(jī)的情況發(fā)生。上述我們試圖讓ABS廠家來修改ABS發(fā)送的EBC1的源地址沒有成功，那么，為什么不讓HCU發(fā)送的EBC1將源地址OB修改為其它呢？經(jīng)與發(fā)動機(jī)廠家溝通，發(fā)動機(jī)只接收一個源地址的PGN=F001的報文，所以只需要出廠前配置好即可，這樣就解決了ID沖突，并可以控制發(fā)動機(jī)停機(jī)。因此，修改HCU發(fā)送的EBC1報文ID為0x18F001EF，通過實驗驗證，這種方法很好地解決了發(fā)動機(jī)的停機(jī)問題。

5 故障總結(jié)

故障的出現(xiàn)是由于同一CAN網(wǎng)段上出現(xiàn)了2個相同的標(biāo)識符，通過修改HCU發(fā)送停機(jī)EBC1報文的源地址，以及發(fā)動機(jī)廠家出廠前設(shè)置好對源地址EF標(biāo)識的識別，從而最終解決了發(fā)動機(jī)無法受控停機(jī)的問題。