王魯蛟

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

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

1 故障描述

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

2 故障分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1）電源管理對(duì)于通信的影響

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

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

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

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

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

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

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

3）診斷對(duì)于通信的影響

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

4）錯(cuò)誤處理對(duì)于通信的影響

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

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

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

3 解決方案

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

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

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

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

圖2 bus-off處理代碼

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

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

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

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

通過(guò)對(duì)試驗(yàn)車輛的長(zhǎng)期跟蹤，模塊未再次發(fā)生掉線問(wèn)題，證明了我們分析的合理性和程序修訂的可靠性。

4 結(jié)論

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