前言

最近遇到一個(gè)CAN報(bào)文超時(shí)Notification不上報(bào)導(dǎo)致ECU不休眠的偶發(fā)問題，本文分享解決問題的思路及影響報(bào)文超時(shí)上報(bào)的機(jī)制，希望能給各位讀者一點(diǎn)啟發(fā)。

參考文檔：

1.Specification of CommunicationAUTOSAR Release 4.3.0

本文使用的AUTOSAR配置工具為：Vector公司的Davinci

正文

1.問題描述

背景：ECU下電的兩個(gè)必要條件是：本地硬線IGN== IgOff && CAN報(bào)文中的點(diǎn)火信號(hào)等于IgOff，如果包含點(diǎn)火信號(hào)的CAN報(bào)文丟失，則判斷該報(bào)文是否Timeout。

問題場(chǎng)景描述

初始狀態(tài)：IgOn，CAN報(bào)文中點(diǎn)火信號(hào)等于IgOn

執(zhí)行動(dòng)作：IgOff，直接拔掉CAN工具（等同于所有報(bào)文掉線）

問題表現(xiàn)：偶發(fā)ECU不能休眠下電

初步分析：ECU不能下電時(shí)的Log中顯示，IgOff后點(diǎn)火信號(hào)一直還是IgOn且沒有收到點(diǎn)火信號(hào)所在報(bào)文的Timeout標(biāo)志。

進(jìn)一步分析：點(diǎn)火信號(hào)所在報(bào)文的超時(shí)標(biāo)志是在Com模塊配置的PDU的Signal的Callout函數(shù)中置位的，也就是說問題發(fā)生的時(shí)候報(bào)文超時(shí)的Callout沒有被調(diào)用。

所以該問題的直接原因就是：IGN信號(hào)所在的報(bào)文偶發(fā)報(bào)文丟失不上報(bào)Timeout。

2.嘗試的復(fù)現(xiàn)辦法

按照上訴步驟嘗試20次復(fù)現(xiàn)問題，無論是從ECU表現(xiàn)（ECU休眠，電流接近為0）來看還是Debug斷點(diǎn)調(diào)試（報(bào)文Timeout的Callout進(jìn)入）來看都是正常的，無法復(fù)現(xiàn)問題……

思考：是不是下電流程或者某種機(jī)制導(dǎo)致Com的超時(shí)判斷不再運(yùn)行導(dǎo)致的，而且這個(gè)機(jī)制有效的時(shí)候正好在超時(shí)判斷之前就會(huì)導(dǎo)致這個(gè)問題。如果是這樣的話，我們把報(bào)文的超時(shí)時(shí)間配置更大，這個(gè)問題應(yīng)該就會(huì)必現(xiàn)。

把超時(shí)時(shí)間配置為10 S，果然這個(gè)問題必現(xiàn)了 !

3.原因分析

Step 1: 先看下正常的ComTimeoutNotification的調(diào)用棧（方便分析是哪里出問題導(dǎo)致的）。

正常情況下，Com_MainFunctionRx_ComMainFunctionRx àCom_MainFunctionRxInternal àCom_RxDlMon_MainFunctionRx àCom_RxDlMon_CallTimeOutNotifications調(diào)用各個(gè)Notification