車身模塊偶發休眠異常的深入研究及分析

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

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

1 背景

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

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

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

2 車輛設防及休眠原理

2.1 車輛正常設防的條件

1）通過CAN Lock發起設防

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

2）機械鑰匙設防

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

3）二次上鎖發起設防

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

4）行李廂再閉鎖設防

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

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

2.2 休眠原理

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

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

圖1 防盜系統框圖

3 原因分析

3.1 從軟件邏輯角度分析

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

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

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

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

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

防盜系統并未處于設防狀態，BCAN處于未休眠的狀態。

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

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

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

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

導致不休眠代碼：

／*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休眠模塊軟件分析

無法休眠的狀態如圖3所示。

圖3 無法休眠的狀態圖

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

4 改進建議

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