馮少嬋，朱景海，姜 浙，王東生，王魯姣

（北京汽車研究總院有限公司，北京 101300）

1 背景

隨著社會經(jīng)濟的發(fā)展，汽車已經(jīng)成為人類社會中不可缺少的交通運輸工具。而中國已經(jīng)是世界上汽車保有量最大的國家，且每年仍在快速增加，汽車工業(yè)成為國家的支柱產(chǎn)業(yè)。隨著車身控制技術的發(fā)展，人們對于汽車的使用性、便利性的要求也越來越高。

目前，汽車電器件越來越多，對于汽車發(fā)電機的功率及蓄電池的容量也提出了更高的要求。眾所周知，多數(shù)汽車在點火時，需要蓄電池供電起動機打火，所以對于汽車在發(fā)動機不工作的狀態(tài)下，為了保護蓄電池的電量不流失，車身控制模塊休眠問題是整車設計時必不可少的考慮因素之一。

某車型在設計開發(fā)階段中的實車動態(tài)測試過程中發(fā)現(xiàn)車輛正常遙控閉鎖后，此車輛偶發(fā)以下故障：故障車輛進行設防操作時，能正常設防，中控鎖門鎖都已經(jīng)上鎖，但是轉向燈會閃爍2次 （車輛正常設防時，轉向燈常亮；車輛正常解防時，轉向燈閃爍2次）。使用CANoe多次監(jiān)測網(wǎng)絡報文，故障車輛偶發(fā)未處于設防狀態(tài)，故此車輛偶發(fā)不能進入休眠狀態(tài)。

2 車輛設防及休眠原理

2.1 車輛正常設防的條件

1）通過CAN Lock發(fā)起設防

當所有車門關閉，從CAN信號的PEPS上鎖命令LOCK_CMD==Lock all doors被BCM成功執(zhí)行，ATWS功能將發(fā)起設防過程，BCM進入設防狀態(tài)。

2）機械鑰匙設防

在解防狀態(tài)下當所有車門 （4門1蓋1行李廂）關閉，機械鑰匙閉鎖 （BCM必須執(zhí)行閉鎖動作），此時可以進入設防狀態(tài)。

3）二次上鎖發(fā)起設防

當二次上鎖命令 （RELOCK）成功執(zhí)行，ATWS功能將直接進入設防狀態(tài) （僅限于遙控閉鎖）。

4）行李廂再閉鎖設防

在設防狀態(tài)下，單獨解行李廂鎖后，直到行李廂再次關閉，5 s后則重新進入設防狀態(tài)。并按外燈系統(tǒng)文檔遙控信號指示章節(jié)中遙控閉鎖的燈光功能執(zhí)行閉鎖閃爍。

車輛正常設防時，燈光報警狀態(tài)為轉向燈常亮；車輛正常解防時，燈光報警狀態(tài)為轉向燈閃爍2次。防盜系統(tǒng)框圖如圖1所示。

2.2 休眠原理

當不再有高功率模式的請求應用時 （也就是說，沒有任何輸入端口被激活，永久性激活的端口輸入將被忽略），BCM將進入低功率模式。此外，停發(fā)CAN總線數(shù)據(jù)，所有喚醒信號無效5s后停止發(fā)送報文并發(fā)送睡眠的請求。

當以下所有條件有效時，BCM能夠進入低功率模式：點火鑰匙狀態(tài)為OFF位置 （點火鑰匙KL R狀態(tài)將使BCM處于高功率模式）；節(jié)點輸出被關閉；危險警告燈未被激活；制動燈開關未被激活；位置燈開關和近光燈開關未被激活；近光燈或位置燈沒有被外部燈光舒適性功能激活；防盜報警系統(tǒng)處于設防或解防 （強制休眠）狀態(tài)；BCM不處于正在等待自動重新閉鎖的狀態(tài)；BCAN處于休眠模式；LIN處于休眠模式；對任何可控的負載，沒有輸出 （如：門鎖執(zhí)行器、尾門鎖電機輸出）；所有軟件定時器都停止。

圖1 防盜系統(tǒng)框圖

3 原因分析

3.1 從軟件邏輯角度分析

滿足休眠條件的判斷邏輯如圖2所示。

從軟件邏輯角度分析，BCM須同時滿足如下條件才能進入休眠狀態(tài)：點火鑰匙狀態(tài)OFF；對可控負載無輸出；節(jié)點輸出關閉；BCM不處于正在等待自動重新閉鎖的狀態(tài)；喚醒源信號未被激活；防盜系統(tǒng)處于設防狀態(tài)；BCAN／LIN處于休眠模式；定時器都停止。

圖2 滿足休眠條件的判斷邏輯圖

對CANoe錄取的報文進行分析，排查結果報文符合休眠，影響休眠的條件不在報文中。通過多次測試并確定故障現(xiàn)象，發(fā)現(xiàn)燈光提醒現(xiàn)象和解鎖現(xiàn)象一致。初步懷疑是車輛設防后某種條件觸發(fā)立即解防。由于鎖會在第1次鎖動作后屏蔽鎖指令，正好可以解釋中控鎖與門鎖沒有解鎖的現(xiàn)象。

經(jīng)過多次對故障車進行CANoe報文采集，故障車上保持點火鑰匙處于OFF狀態(tài)、關閉故障車上所有的負載，并且錄制的網(wǎng)絡報文中顯示網(wǎng)絡點火鑰匙為OFF狀態(tài)、未有輸出信號發(fā)送、節(jié)點輸出關閉、喚醒源信號未被激活、BCM不處于正在等待自動重新閉鎖的狀態(tài)。

防盜系統(tǒng)并未處于設防狀態(tài)，BCAN處于未休眠的狀態(tài)。

多次對故障車進行故障復現(xiàn)和報文分析，網(wǎng)絡報文上發(fā)現(xiàn)當OFF擋后，EMS仍然發(fā)送一段時間認證成功EMS5_St_AuthenticatedResult==authentication success的事件信號（CAN信號）延遲發(fā)送30 s。

然后排查軟件與模型，發(fā)現(xiàn)當BCM處于設防后接收到EMS認證成功信號會立即解防，然后在臺架上仿真EMS認證成功信號，遙控設防車輛，出現(xiàn)燈光閃爍2次，中控鎖閉鎖一次，與故障車的現(xiàn)象一致，確認是設防后，立即被EMS認證成功信號解防的。

3.2 從BCM休眠模塊代碼邏輯分析

然后開始梳理BCM休眠模塊代碼邏輯，針對每一個條件進行Debug，排查每一個可能導致不休眠的條件。經(jīng)過一個條件的排查，發(fā)現(xiàn)當BCM通過遙控閉鎖后，車輛需要是設防狀態(tài)或者重新解鎖中控鎖，車輛才可以休眠。而此時車輛并不符合休眠條件，所以可以確認問題是條件沖突造成的。

導致不休眠代碼：

／*lock check*／

if（lockflag==FALSE）

{

if（（g_outCentralLockupSts==SYS_LOCKSRC_KEY）

||（g_outCentralLockupSts==SYS_LOCKSRC_PEPS））

{

lockflag=TRUE；

}}

else

{

if（（g_outCentralUnLockCmd==ON）

||（g_outTrunkReleaseCmd==ON））

{

lockflag=FALSE；

}}

／*wake up source*／

／*RKELINCANKL15ACCKEYINPOSLAMPLOWBEAMBRAKETRUNK*／

if（（（g_inIgnOnSts==OFF）

&&（g_inIgnAccSts==OFF）

&&（g_BrakeLightSwitchHw==OFF）

&&（g_inLowBeamSWSts==OFF）

&&（g_inRKELockSts==OFF）

&&（g_inRKEUnlockSts==OFF）

&&（g_inRKETrunkSts==OFF）

&&（g_inPositionLampSWSts==OFF）

&&（g_outPositionLampCmd==OFF））

&&（g_inTrunkSts==ON）||（g_inHoodSts==ON）

||（LockFlag==FALSE））））

{

contStartFlag=TRUE；

if（g_inTrunkSts==ON）

{

sleepSrc|=SYS_EIGHTMINUTE_SLEEP_SRC_TRUNK；

……

……

}

從代碼可知，當lockFlag為FALSE時才可休眠，而此路徑中通過PEPS閉鎖的，lockFlag被置為TRUE，然后一直再等待中控鎖解鎖和后備廂解鎖 （此代碼在車輛出游解防時的檢測睡眠路徑）。

3.3 從BCM休眠模塊軟件分析

無法休眠的狀態(tài)如圖3所示。

圖3 無法休眠的狀態(tài)圖

從軟件分析，進入休眠的路徑有3條：第1條路徑，ATWS設防，輸入輸出無效，近光燈、位置燈開關無效；第2條路徑，ATWS設防，近光燈開關或位置燈開關有效；第3條路徑，其他都不符合時判斷鎖狀態(tài)判斷，若是中控鎖未經(jīng)PEPS／鑰匙閉鎖，其他條件滿足，可以休眠。若是中控鎖通過PEPS／鑰匙閉鎖，需要后備廂解鎖或者中控解鎖才可以休眠或者通過。潛在的默認中控鎖通過PEPS／鑰匙閉鎖后車輛一定處于設防狀態(tài)，此條件與本次現(xiàn)象不符，才導致車輛無法休眠。而此現(xiàn)象是中控鎖PEPS／鑰匙閉鎖后，但緊接著又被EMS認證信號給解防。不符合車輛休眠條件，所以無法休眠。

4 改進建議

點火鑰匙OFF擋位狀態(tài)，收到遙控鑰匙／PEPS／左前門機械鑰匙閉鎖等網(wǎng)絡信號后，接收到EMS認證成功信號后不進行認證信號解防處理操作；統(tǒng)一只使用設防狀態(tài)而不使用鎖狀態(tài)，車輛解防時檢測睡眠路徑時，不再等待中控鎖和尾門鎖而使用設防狀態(tài)進行檢測；點火鑰匙OFF擋位狀態(tài)，EMS發(fā)送認證成功EMS5_St_AuthenticatedResult==authentication success的事件信號 （CAN信號）延遲發(fā)送時間縮短到毫秒級。