整車下線EPS 刷寫偶發性失敗問題分析與方案優選

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

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

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

1 軟件刷寫電氣原理

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

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

圖2 EPS模塊刷寫流程

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

2 故障現象

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

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

2） EPS軟件問題，軟件未按照流程開發，導致出現報錯情況。

3） 轉向盤異動導致失敗，可能會影響刷寫模塊出現負響應。

3 問題分析

3.1 情況1問題分析

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

3.2 情況2問題分析

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

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

圖3 問題數據1

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

圖4 問題數據2

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

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

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

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

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

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

4 整改方案優選

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

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

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

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

5 結論

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