陳江波， 涂將輝， 夏永強， 趙能卿， 李 娟， 賈和平

（江鈴汽車股份有限公司， 江西 南昌 330001）

下線EOL診斷儀是汽車主機廠生產(chǎn)下線時的重要生產(chǎn)工具［1］，整車項目開發(fā)后期需要進行EOL設(shè)備進行聯(lián)調(diào)以滿足生產(chǎn)的需求［2］。EOL設(shè)備一般具有讀取模塊軟件故障碼、清除模塊軟件故障碼、模塊軟件功能自動識別配置、特殊功能學習、模塊軟件刷寫更新等功能［3］。EOL功能指令的發(fā)送時序與時間參數(shù)的設(shè)置是根據(jù)產(chǎn)線工序、軟件特殊需求、下線流程來定義［4］。ECU Bootloader刷寫是根據(jù)UDS協(xié)議開發(fā)定義［5］。

1 軟件刷寫電氣原理

圖1為EPS模塊（電動助力轉(zhuǎn)向） 診斷通信的路徑，刷寫指令由EOL設(shè)備發(fā)送，經(jīng)網(wǎng)關(guān)從動力CAN路由轉(zhuǎn)發(fā)至EPS所在總線上，EOL發(fā)送指令，各模塊根據(jù)診斷通信規(guī)范做出正響應(yīng)或否定響應(yīng) （設(shè)定條件不符時），EOL根據(jù)得到的響應(yīng)進行下一步的指令發(fā)送。

圖1 EPS模塊診斷通信的路徑

圖2 EPS模塊刷寫流程

圖2 為EPS軟件刷寫流程，EPS進入刷寫之前需要對診斷模式切換，需要從默認會話模式（正常工作狀態(tài)） 進入拓展會話模式（響應(yīng)拓展模式下的指令），再進入編程模式 （響應(yīng)編程模式下的編程指令可以對EPS進行刷寫操作）。通過圖2步驟實現(xiàn)整車軟件刷寫過程，這些流程按照順序執(zhí)行，任何步驟出現(xiàn)問題，如出現(xiàn)負響應(yīng)，EPS的刷寫過程都會被中斷導致刷寫失敗。

2 故障現(xiàn)象

項目投產(chǎn)階段總裝工廠反饋有部分下線車輛配置線上出現(xiàn)EPS刷寫一次測試不通過情況，經(jīng)過錄制數(shù)據(jù)跟蹤問題主要是以下兩種失敗情況：①10臺左右車失敗的原因為31 01 FF 02回復(fù)了7F 31 7F。②EPS模塊未有任何響應(yīng)（含7DF指令和721），功能尋址10 83/85 82發(fā)出EPS并沒有正響應(yīng)。針對以上兩種刷寫失敗情況，得到問題出現(xiàn)的3種可能原因。

1） 反饋負響應(yīng)的模塊有SWM （組合開關(guān)）、EPS （電動助力轉(zhuǎn)向）、SRS （安全氣囊），3個模塊均對28指令反饋7F，這3個模塊在CCAN上，而EOL設(shè)備發(fā)送指令是在PCAN上，說明很大概率是網(wǎng)關(guān)丟幀導致包括10 83指令在內(nèi)的很多指令未成功轉(zhuǎn)發(fā)至模塊終端，指令缺失導致不符合EPS刷寫流程，EPS對后面轉(zhuǎn)發(fā)過來的指令給出7F反饋，不執(zhí)行后續(xù)的刷寫命令。

2） EPS軟件問題，軟件未按照流程開發(fā)，導致出現(xiàn)報錯情況。

3） 轉(zhuǎn)向盤異動導致失敗，可能會影響刷寫模塊出現(xiàn)負響應(yīng)。

3 問題分析

3.1 情況1問題分析

針對以上兩個刷寫失敗的情況，經(jīng)過確認情況①EOL設(shè)備31 01 FF 02回復(fù)7F 31 22，下線在對EPS進行刷寫時，方向盤被有意觸動后，電動助力轉(zhuǎn)向系統(tǒng)轉(zhuǎn)向機扭矩會出現(xiàn)波動，容易產(chǎn)生EPS刷寫失?。籈PS刷寫時需要監(jiān)控的因素主要有方向盤扭矩處、車速、發(fā)動機狀態(tài)、供電電壓，其中任何一個條件不滿足都無法完成刷寫流程。EPS在進入編程模式時觸碰方向盤導致EPS內(nèi)部的扭矩傳感器波動，出于整車安全考慮，EPS軟件刷寫編程是不允許出現(xiàn)扭矩波動情況（上限值2.5Nm），出于安全考慮的原因是確保在無駕駛員操作車輛，即EPS處于非工作狀態(tài)，EPS軟件才能進入再編程模式。

3.2 情況2問題分析

根據(jù)圖3所示問題數(shù)據(jù)1分析，在T=150.434542和T=150.693814兩個時間點，PCAN上有診斷報文7DF，但網(wǎng)關(guān)未將其轉(zhuǎn)發(fā)至CCAN。直到T=150.953830時，PCAN上出現(xiàn)第3幀診斷報文時，網(wǎng)關(guān)GW才開始將診斷報文路由到CCAN。之后各模塊反饋否定響應(yīng)碼7F導致刷寫失敗。根據(jù)數(shù)據(jù)分析刷寫失敗原因初步定位為網(wǎng)關(guān)未轉(zhuǎn)發(fā)診斷報文導致 （CAN1：PCAN，CAN6：CCAN，CAN8：BCAN）。

網(wǎng)關(guān)未轉(zhuǎn)發(fā)診斷報文是否正常需要繼續(xù)分析，從圖3中T=144.311722可知BCAN上下線測試設(shè)備在BCAN上發(fā)送0x763 TBOX診斷請求及診斷響應(yīng)，當前診斷優(yōu)先級為BCAN；之后0x763報文停發(fā)，BCAN上做其他模塊 （0x732/0x7E0） 本地診斷，當前診斷不需要網(wǎng)關(guān)處理，網(wǎng)關(guān)會從最后一幀0x763開始5s診斷報文超時計時；而在T=150.434542時，發(fā)送第1幀0x7DF時，此時網(wǎng)關(guān)會認為BCAN/PCAN診斷報文已超時，如果超時后TCAN上有診斷報文，則會將診斷優(yōu)先級切換至TCAN；此時再請求0x7DF會涉及一次診斷優(yōu)先級從TCAN-＞PCAN的過程，而這一過程中，TCAN診斷報文未超時，此時會有500ms延時處理PCAN診斷請求的計時器，這也就是前面0x7DF報文網(wǎng)關(guān)未處理，而在T=150.953830時，0x7DF開始從PCAN正常路由至CCAN。因此，根據(jù)進一步分析，網(wǎng)關(guān)漏轉(zhuǎn)報文是因為TBOX有診斷請求導致。

圖3 問題數(shù)據(jù)1

根據(jù)深入分析發(fā)現(xiàn)：按照下線匹配流程，在問題數(shù)據(jù)2（圖4） 中T=85s，下線設(shè)備對TBOX進行了一次硬件復(fù)位；按照TBOX和網(wǎng)關(guān)握手認證策略，此時TBOX需要發(fā)起握手認證流程，如未握手認證成功，TBOX會一直發(fā)0x760嘗試和網(wǎng)關(guān)進行握手認證；又由于網(wǎng)關(guān)未經(jīng)過重啟，不滿足網(wǎng)關(guān)握手的條件，未進入等待握手流程狀態(tài)。

圖4 問題數(shù)據(jù)2

綜上所述，從流程上梳理問題根本原因如下所述。

1） 根據(jù)EOL下線流程，需要先完成TBOX模塊與PEPS模塊之間的匹配認證（TBOX學習完成SC碼），然后會執(zhí)行硬件復(fù)位，復(fù)位后就開始和網(wǎng)關(guān)進行認證 （TBOX會發(fā)出網(wǎng)關(guān)診斷0x760報文）。

2） 按照TBOX與網(wǎng)關(guān)握手認證策略，GW網(wǎng)關(guān)未執(zhí)行上下電操作，網(wǎng)關(guān)不會對該握手認證指令進行響應(yīng)。導致TBOX握手失敗情況，總線上會一直發(fā)送網(wǎng)關(guān)診斷0x760報文。

3） 在完成TBOX和PEPS匹配認證后，EOL流程會等待6s后才開始執(zhí)行EPS模塊刷寫操作，此時TBOX還在發(fā)送網(wǎng)關(guān)診斷0x760報文。

4） 按照網(wǎng)關(guān)診斷策略，Tester/EOL設(shè)備的診斷優(yōu)先級高于T-Box模塊自身的診斷優(yōu)先級，如果BCAN、PCAN上5s未收到任何診斷指令時，此時如TCAN上出現(xiàn)診斷報文，網(wǎng)關(guān)會將本地診斷模式切換為遠程模式。車子下線時，出現(xiàn)TBOX握手報文，正好處于5～6s的時間段內(nèi)，網(wǎng)關(guān)將會把診斷路由模式切換為遠程模式。

5） 當網(wǎng)關(guān)在PCAN收到EPS刷寫的第1條報文時，此時依據(jù)本地診斷優(yōu)先級高于遠程診斷策略原則，會將診斷路由模式切換為本地診斷模式，但考慮遠程診斷還在進行，預(yù)留了一個500ms的切換時間。該段時間內(nèi)的本地診斷報文不會路由，從而導致EPS刷寫失敗。

4 整改方案優(yōu)選

按照刷寫失敗原因分析，有以下3個方案去解決該問題。

1） 網(wǎng)關(guān)修改軟件，將網(wǎng)關(guān)的等待握手流程開始的條件修改為任意時刻。當前只有上電或者喚醒時，網(wǎng)關(guān)會響應(yīng)進行握手協(xié)議。把網(wǎng)關(guān)的等待握手流程修改為任意時刻，只要TBOX發(fā)送握手協(xié)議指令，網(wǎng)關(guān)響應(yīng)后停止發(fā)送指令，就可以完全避免出現(xiàn)EPS刷寫時從診斷報文不會路由的情況?？紤]到更改GW軟件時間周期較長，且涉及開發(fā)費用，因此建議不采用。

2） TBOX修改軟件，TBOX按照其他項目，在下線的前20min內(nèi)不進行診斷。此次刷寫失敗的原因主要是因為TBOX需要進行診斷，進行診斷之前需要通過握手實現(xiàn)診斷通信，前20min不進行握手通信，就可以完全避免出現(xiàn)EPS刷寫時出現(xiàn)漏轉(zhuǎn)發(fā)診斷信號的情況。但是由于修改TBOX軟件時間周期長，同時還需要進行聯(lián)調(diào)測試，因此建議不采用。

3） 修改EOL流程，調(diào)整硬件復(fù)位時間，由于EOL在整個流程結(jié)束會進行一次7DF的硬件復(fù)位，將TBOX學習完SC碼后的硬件復(fù)位取消。在EPS刷寫過程中不會出現(xiàn)握手指令，使得GW始終處于本地診斷模式，GW進行正確的報文轉(zhuǎn)發(fā)，不會出現(xiàn)停止發(fā)送報文的情況。且該方案不涉及開發(fā)費用，經(jīng)評估方案可行，同時經(jīng)過聯(lián)調(diào)測試，該方法測試驗證通過，未對其他下線流程產(chǎn)生影響。綜上所述，此方案為最優(yōu)方案。

5 結(jié)論

針對下線EOL設(shè)備對EPS模塊進行Bootloader刷寫時出現(xiàn)偶發(fā)性失敗情況，對問題進行跟蹤并錄制CAN總線數(shù)據(jù)進行分析，結(jié)合下線流程詳細分析了出現(xiàn)問題的根本原因，同時提出3種修改策略。對3種修改策略分別分析方案的可行性，分析結(jié)果表明：通過調(diào)整下線流程取消TBOX的硬件復(fù)位，并在整個下線流程結(jié)束后進行整車所有模塊硬件復(fù)位，徹底解決了這類問題。