汽車控制模塊掉線問題的分析與解決

王魯蛟

（北京汽車研究總院，北京 101300）

汽車設(shè)計時，考慮在復(fù)雜多樣的環(huán)境中使用，其中很多工況非常惡劣，因此汽車產(chǎn)品必須滿足更為嚴(yán)格的測試要求和試驗要求。采用CAN網(wǎng)絡(luò)通信可滿足汽車各控制系統(tǒng)高可靠性和智能化的要求，但是總線模塊在設(shè)計和試驗過程中易出現(xiàn)掉線的問題，而總線掉線問題原因繁多，增加了分析和解決問題的難度。本文從實際試驗過程中出現(xiàn)的問題，總結(jié)了總線掉線的排查方法和問題應(yīng)對措施，為解決模塊掉線問題提供參考。

1 故障描述

試驗過程中，VIN60號車后視鏡折疊展開功能只有左后視鏡有輸出控制，右后視鏡無輸出控制，經(jīng)網(wǎng)絡(luò)監(jiān)測發(fā)現(xiàn)門模塊應(yīng)用報文及網(wǎng)絡(luò)管理報文都不發(fā)送，但是轉(zhuǎn)向燈及門鎖控制功能正常，后續(xù)掉電后網(wǎng)絡(luò)恢復(fù)正常；后續(xù)VIN60號又出現(xiàn)問題：車輛自動行駛過程中反復(fù)自動落鎖，經(jīng)網(wǎng)絡(luò)監(jiān)測發(fā)現(xiàn)門控制模塊應(yīng)用報文及網(wǎng)絡(luò)管理報文都不發(fā)送，但是轉(zhuǎn)向燈功能正常，后續(xù)掉電后網(wǎng)絡(luò)恢復(fù)正常。VIN80號車在使用診斷讀取前車身控制模塊及乘客側(cè)模塊版本號時無診斷應(yīng)答，經(jīng)網(wǎng)絡(luò)監(jiān)測發(fā)現(xiàn)前車身控制模塊和乘客側(cè)模塊的應(yīng)用報文及網(wǎng)絡(luò)管理報文都不發(fā)送，但是轉(zhuǎn)向燈輸出正常，修車過程中無意掉電后網(wǎng)絡(luò)恢復(fù)正常。

2 故障分析

根據(jù)試驗車輛出現(xiàn)的故障現(xiàn)象，將從6個方面展開掉線問題的分析。

2.1 bus-off導(dǎo)致網(wǎng)絡(luò)不正常

在問題車輛CAN線人為制造bus-off后恢復(fù)，各個模塊的bus-off都能恢復(fù)。在臺架上也模擬樣車控制器狀態(tài)每次busoff都能恢復(fù)。

2.2 地漂導(dǎo)致網(wǎng)絡(luò)不正常

在對前車身控制模塊地漂0.5 V、0.9 V、1.2 V的情況下查看網(wǎng)絡(luò)狀態(tài)均未出現(xiàn)節(jié)點(diǎn)不發(fā)送任何報文的情況。在地漂產(chǎn)生情況下同時制造bus-off也未復(fù)現(xiàn)該問題，但是如果是地漂按邏輯應(yīng)該對接收也是有影響的。

2.3 CAN內(nèi)部問題導(dǎo)致網(wǎng)絡(luò)不正常

當(dāng)前控制器是通過幀模式控制當(dāng)前網(wǎng)絡(luò)發(fā)送的報文，對于從模塊支持3個幀模式：Normal模式 （應(yīng)用報文、網(wǎng)絡(luò)管理報文及診斷報文都發(fā)送）；Quiet模式 （只發(fā)送網(wǎng)絡(luò)管理報文及診斷報文）；Silent模式 （除了診斷報文，網(wǎng)絡(luò)管理及應(yīng)用報文都不發(fā)送）。從邏輯上即使幀模式切換異常，在能接收的情況下診斷報文應(yīng)該是能正常發(fā)送接收的，但問題描述在該問題出現(xiàn)時診斷報文也是不能進(jìn)行發(fā)送的，說明控制器的報文發(fā)送是有問題，而網(wǎng)絡(luò)接收及邏輯功能正常。為了驗證幀模式切換的問題，在樣車軟件版本基礎(chǔ)上定制特殊程序連續(xù)切換幀模式同時制造bus-off，經(jīng)過多次測試未出現(xiàn)問題現(xiàn)象。

查詢CAN Transiver TJA1040未發(fā)現(xiàn)相關(guān)只收不發(fā)的情況；查詢MC9S12XDT256 DataSeet發(fā)現(xiàn)對于CAN控制器有一種監(jiān)聽模式 （網(wǎng)絡(luò)報文只發(fā)不收），但是實際控制邏輯中會將其禁止掉。

2.4 睡眠喚醒及網(wǎng)絡(luò)管理導(dǎo)致網(wǎng)絡(luò)不正常

在臺架上結(jié)合24V模塊及網(wǎng)關(guān)模塊測試，連續(xù)睡眠喚醒（各個模塊的喚醒源）周期性測試也未復(fù)現(xiàn)該問題；通過網(wǎng)絡(luò)監(jiān)測設(shè)備在網(wǎng)絡(luò)正常狀態(tài)下發(fā)送異常的單個的網(wǎng)絡(luò)管理幀 （比如單獨(dú)發(fā)送一個32睡眠確認(rèn)幀），周期性測試也未復(fù)現(xiàn)該問題；對于出現(xiàn)該問題時，其它節(jié)點(diǎn)網(wǎng)絡(luò)睡眠喚醒正常，但是對于問題節(jié)點(diǎn)，因為不能進(jìn)行幀的發(fā)送所以對于問題節(jié)點(diǎn)在達(dá)到睡眠條件后也是不能進(jìn)入低功耗模式 （網(wǎng)絡(luò)管理必須發(fā)送完相應(yīng)的網(wǎng)絡(luò)管理報文后才能確認(rèn)睡眠），相當(dāng)于在正常的網(wǎng)絡(luò)節(jié)點(diǎn)睡眠后，問題節(jié)點(diǎn)按照邏輯還在運(yùn)行未進(jìn)入低功耗。

2.5 總線負(fù)載率異常過高導(dǎo)致網(wǎng)絡(luò)不正常

正常網(wǎng)絡(luò)總線負(fù)載大約20%，網(wǎng)絡(luò)仿真增加網(wǎng)絡(luò)負(fù)載到96%，同時制造bus-off，在bus-off恢復(fù)后網(wǎng)絡(luò)正常，在不制造bus-off的情況下，網(wǎng)絡(luò)睡眠喚醒后網(wǎng)絡(luò)還是正常。

2.6 軟件問題引起網(wǎng)絡(luò)不正常

軟件與通信相關(guān)的部分包含如下幾個模塊：電源管理、網(wǎng)絡(luò)管理、診斷處理、錯誤處理、COM模塊內(nèi)部故障。分別對每個模塊展開分析。

1）電源管理對于通信的影響

在過壓和欠壓情況下會關(guān)閉通信，但是不會關(guān)閉診斷通信，按照如下步驟操作可以復(fù)現(xiàn)網(wǎng)絡(luò)管理及應(yīng)用報文都不發(fā)送的情況。

第1步：DDM模塊在過壓情況下休眠。

第2步：DDM在過壓情況下通過其它節(jié)點(diǎn)網(wǎng)絡(luò)管理報文喚醒。

第3步：電壓恢復(fù)正常。

通過如上3步，DDM模塊不發(fā)送應(yīng)用報文及網(wǎng)絡(luò)管理報文，但是通過硬線喚醒，控制器可以重新發(fā)送應(yīng)用及網(wǎng)絡(luò)管理報文，且在該情況下，診斷是可以正常響應(yīng)的。在EP3的實驗車上，出現(xiàn)問題是：現(xiàn)場工程師 （權(quán)瑩甲）進(jìn)行了硬線喚醒、診斷、bus-off等操作，均未能使控制器功能恢復(fù)，該模擬現(xiàn)象與測試車輛現(xiàn)象不一致，原因排除。

2）網(wǎng)絡(luò)管理對于通信的影響

網(wǎng)絡(luò)管理模塊會對CAN通信進(jìn)行相關(guān)的管理，包括模式切換、OFF Line、ON Line等操作，測試及分析可以排除相關(guān)的問題，原因如下：幀模式操作，目前BCM從模塊的所有幀模式中都支持診斷幀，所以不管切換到什么模式下，診斷應(yīng)該有響應(yīng)，與試驗車上診斷命令沒有響應(yīng)現(xiàn)象不符，原因可以排除；如果網(wǎng)絡(luò)管理進(jìn)行了OFF Line操作，收發(fā)都將關(guān)閉，與試驗車上能收不能發(fā)的現(xiàn)象不符，原因可以排除。

3）診斷對于通信的影響

診斷服務(wù)CC（Communication Control）對于通信的影響，通過CC服務(wù)可以關(guān)閉Tx及Rx，但是在EP3的軟件上，該功能沒有實現(xiàn)，且收發(fā)關(guān)閉不針對診斷幀，所以不能解釋診斷幀不通的問題，原因排除。復(fù)位服務(wù)ER（ECU Reset）對于通信的影響，該服務(wù)從設(shè)計上不會對通信產(chǎn)生影響。但是從實際測試情況看，在有FBL的情況下，如果發(fā)送ER服務(wù)，若使用看門狗復(fù)位，因為配置的原因，可能導(dǎo)致復(fù)位不起來，從而導(dǎo)致控制器死機(jī)，網(wǎng)絡(luò)管理報文、應(yīng)用報文及診斷都將不通，這些現(xiàn)象與車上現(xiàn)象一致，但是在該情況下，控制器功能也將失效，與試驗車上控制器仍然能接收且有功能現(xiàn)象不符，原因排除。

4）錯誤處理對于通信的影響

對于通信有影響的錯誤有過壓、欠壓 （在電源管理對通信的影響中已經(jīng)描述），總線故障對于通信的影響，通過各種方式制造總線故障，如：CANH對電源 （到24V）、對搭鐵短路；CANL對電源 （到24V）、對搭鐵短路；CANH及CANL同時對電源及對搭鐵短路；CANH對CANL短路。在總線通信過程中使用信號發(fā)生器及CAN Spider進(jìn)行總線干擾，進(jìn)行了大量的測試，包括在休眠喚醒階段注入相應(yīng)的故障，通信均可以恢復(fù)，因為出現(xiàn)故障，都切換的是幀模式或者CAN OFF Line。如果是幀模式切換，不能解釋為什么診斷通信不通；如果是CAN OFF Line，不能解釋為什么還能接收，且有功能錯誤可能引起的其它問題。目前的分析沒有發(fā)現(xiàn)其它異常。

5）COM模塊內(nèi)部故障導(dǎo)致通信異常

COM模塊出現(xiàn)該問題的原因只有在自己的專屬內(nèi)存被異常改寫的情況下可能出現(xiàn)，COM模塊的專屬內(nèi)存存放模塊內(nèi)部的標(biāo)準(zhǔn)及狀態(tài)位，如果被異常改寫，可能導(dǎo)致不能發(fā)送，也有可能出現(xiàn)試驗車上的現(xiàn)象。

3 解決方案

試驗場再次出現(xiàn)DDM模塊掉線，我們將故障時的數(shù)據(jù)記錄到了DFLASH中，并在發(fā)送COM初始后，故障恢復(fù)，將故障時的數(shù)據(jù)讀出，進(jìn)行數(shù)據(jù)還原。在COM中，發(fā)送報文的處理由一個內(nèi)部函數(shù)s_com_process_empty_tx_slots實現(xiàn)。該函數(shù)處于COM的臨界區(qū)中，執(zhí)行時需要關(guān)閉中斷，防止意外的代碼重入。

根據(jù)問題現(xiàn)象分析、故障節(jié)點(diǎn)內(nèi)存提取、臺架問題復(fù)現(xiàn)實驗等一系列的手段，節(jié)點(diǎn)丟失的根本原因已經(jīng)定位：函數(shù)s_com_process_empty_tx_slots執(zhí)行到某段位置時被函數(shù)s_com_connect_node中斷，造成COM內(nèi)部報文發(fā)送標(biāo)志處理流程異常，無法被清除。此時若再發(fā)生幀模式切換請求（調(diào)用函數(shù)s_com_set_fmd），COM將會由于發(fā)送標(biāo)志存在無法正常切換幀模式，進(jìn)入只能接收不能發(fā)送的狀態(tài)，即實驗車上發(fā)現(xiàn)的節(jié)點(diǎn)丟失現(xiàn)象。函數(shù)s_com_process_empty_tx_slots中的臨界代碼見圖1。

節(jié)點(diǎn)在臨界區(qū)調(diào)用s_com_connect_node的原因是發(fā)生了bus-off事件，而bus-off處理代碼在軟件中的運(yùn)行時機(jī)為立即執(zhí)行 （在中斷中進(jìn)行處理）。節(jié)點(diǎn)在bus-off事件發(fā)生時的處理代碼見圖2。

圖1 函數(shù)s_com_process_em pty_tx_slots中的臨界代碼

圖2 bus-off處理代碼

發(fā)生問題的臨界區(qū)代碼執(zhí)行時間為微秒級，根據(jù)初步估算小于1μs，而正巧在此時發(fā)生一次bus-off的概率極低，導(dǎo)致該問題非常難以捕捉，只有長時間行車才能提高其發(fā)生的頻率。

根據(jù)其根本原因，該問題有以下2種解決方案：①增加臨界區(qū)保護(hù)代碼 （實現(xiàn)COM提供的中斷操作回調(diào)函數(shù)）；②將bus-off處理代碼置于任務(wù)上下文中執(zhí)行。

保證函數(shù)s_com_process_empty_tx_slots在執(zhí)行時不會被s_com_connect_node中斷，從而解決因此導(dǎo)致的節(jié)點(diǎn)丟失問題。

將程序重新規(guī)劃，對于以前不合理及導(dǎo)致此次問題的COM模塊接口均進(jìn)行了優(yōu)化，ECU喚醒后重新初始COM模塊，確保ECU起來后COM模塊的內(nèi)存中的數(shù)據(jù)不會出現(xiàn)異常；將原程序在中斷處理中調(diào)用的s_dirnm_tx_process、s_dirnm_rx_process、s_dirnm_can_error從中斷中移走，在中斷中設(shè)置標(biāo)識，在任務(wù)中查詢標(biāo)識后調(diào)用；增加中斷保護(hù)功能，在關(guān)鍵的操作處理過程中不允許中斷打斷；查詢COM模塊的Pending狀態(tài)，如果持續(xù)Pending超過5 s，重新初始化COM模塊，確保故障能恢復(fù)。

通過對試驗車輛的長期跟蹤，模塊未再次發(fā)生掉線問題，證明了我們分析的合理性和程序修訂的可靠性。

4 結(jié)論

隨著現(xiàn)代汽車功能的復(fù)雜性的提高，汽車電子控制模塊的數(shù)量也越來越多，需要通信的信號也相應(yīng)增多，CAN總線通信是現(xiàn)在汽車中主流的信號通信方式，可滿足現(xiàn)代汽車信號交互的需求。但是CAN總線通信模塊在設(shè)計過程中，出現(xiàn)模塊掉線的情況很多。掉線的情況又各種各樣，增加了分析的難度。本文通過對總線掉線的各種情況展開分析，有效解決了試驗過程中的掉線問題，對后續(xù)其他CAN總線模塊的設(shè)計具有借鑒參考價值。