CAN總線中，相對其他通信類問題，Busoff問題比較難搞。本文從CanSM模塊出發，就Busoff產生、Busoff信息交互、Busoff快/慢恢復等問題展開聊一聊。

這個話題前面有聊過，可以參考前文Autosar網絡管理：說說Busoff那點事。

1Busoff產生

這里再說一次Busoff產生的條件：TEC > 255。也就是說ECU自身發出的報文錯誤，導致TEC(Transmit Error Counter)不斷累加，直到TEC超過255產生Busoff，如下所示：

舉例：ECU1::CAN1發送的錯誤幀只能使ECU1::CAN1進入Busoff狀態，而不能使ECU2::CAN1進入Busoff，如下所示：

因為錯誤由ECU1::CAN1自己產生，ECU1::CAN1有問題，自己脫離CAN總線即可，不要影響ECU2::CAN1繼續使用CAN總線。

2Busoff信息交互及Busoff恢復機制

節點產生Busoff以后，ControllerMode狀態自動切換到CANIF_CS_STOPED模式，停止發送錯誤幀，避免影響總線其他節點的通信。既然Busoff已經發生，對應的信息就需要傳遞給上層，讓上層決策后續的通信行為。怎樣通知上層呢？

Can Controller通知到上層有兩種方式：Interrupt或者Polling。

Step1、Busoff事件信息如何通知到CanSM

Interrupt方式：

Busoff中斷發生->

CanInterruptStatus()

->CanHL_ErrorHandling()->

CanIf_ControllerBusOff()

->

CanSM_ControllerBusOff()

->CanSM_BusOffIndicated()，CanSM_BusOffFlag = TRUE

...CanSM_MainFunction()周期性檢查CanSM_BusOffFlag置位情況。

Polling方式：Can_MainFunction_BusOff()

->CanHL_ErrorHandling()->

CanIf_ControllerBusOff()

->

CanSM_ControllerBusOff()

->CanSM_BusOffIndicated()，CanSM_BusOffFlag= TRUE

...CanSM_MainFunction()周期性檢查CanSM_BusOffFlag置位情況。

提示：上述函數關聯關系，除Autosar標準接口以外，其他接口，不同軟件供應商，實現上可能存在不同。

Step2、CanSM請求重啟Can Controller，通知ComM、BswM模式切換

Busoff發生以后，CanSM調用CanIf_SetControllerMode()接口，請求將ControllerMode切到CANIF_CS_STARTED模式，以便于后續嘗試恢復通信。同時關閉Tx PDU的發送，只能接收Rx PDU。所以這也是為什么在恢復期內可以收到報文的原因。CanSM調用BswM_CanSM_CurrentState()接口通知BswM進入CANSM_BSWM_BUS_OFF狀態，調用ComM_BusSM_ModeIndication()接口通知ComM進入COMM_SILENT_COMMUNICATION狀態。

Busoff發生以后，CanSM先告知ComM，ComM在請求CanSM對應Channel由FULL COMMUNICATION進入SILENT COMMUNICATION。進入CANSM_BSM_S_SILENTCOM_BOR狀態，如下所示：

Busoff發生以后，CanSM會啟動一個Busoff Timer，BusoffTimer分為兩種：

快恢復時間參數：CanSMBorTimeL1；

慢恢復時間參數：CanSMBorTimeL2。

具體BusoffTimer應該等于CanSMBorTimeL1還是CanSMBorTimeL2，取決于配置參數CanSMBorCounterL1ToL2。

如果Busoff連續發生次數 ＜CanSMBorCounterL1ToL2，BusoffTimer =CanSMBorTimeL1；

如果Busoff連續發生次數≥ CanSMBorCounterL1ToL2，BusoffTimer=CanSMBorTimeL2；

注意：CanSMBorTimeL1、CanSMBorTimeL2、CanSMBorCounterL1ToL2三個參數均在CanSM模塊配置，具體數值根據OEM需求配置。測試中，busoff的快/慢恢復行為如下所示：

在快/慢恢復時間內，可以接收報文。

Step3、CanSMBorTimeL1或者CanSMBorTimeL2耗盡

CanSMBorTimeL1或者CanSMBorTimeL2耗盡(elapse)，重新發送Tx PDU，讓故障節點再次嘗試向CAN總線發送報文。同時，CanSM通知BswM進入CANSM_BSWM_FULL_COMMUNICATION狀態，通知ComM進入COMM_FULL_COMMUNICATION狀態?？梢詥覥anSMBorTimeTxEnsured，確認Busoff是否恢復，也可以使用Confirm方式確認Busoff恢復。

Step4、CanSMBorTimeTxEnsured耗盡

在CanSMBorTimeTxEnsured時間內，Busoff再次發生，則進行下一次的Busoff恢復機制，如果CanSMBorTimeTxEnsured耗盡，則說明成功從Busoff狀態恢復。如果在CanSMBorTimeTxEnsured時間內，再次發生Busoff，則Busoff次數累加。

3Busoff發生時的網絡狀態

這里主要討論Busoff進入慢恢復期，節點在NOS(Normal Operation State)和RSS(Ready Sleep State)下是否會進行網絡狀態切換。

NOS：Busoff進入慢恢復期，如果上層不主動請求釋放網絡，網絡狀態無法進入RSS，所以，節點會一直在NOS狀態下，一直處于慢恢復狀態，如下所示：

RSS：Busoff進入慢恢復期，如果在恢復期收不到有效的網絡管理報文，NM-Timeout時間超時以后，進入PBSM(Pre Bus Sleep Mode)；如果可以收到有效的網絡管理報文，則網絡處于RSS狀態，如下所示：

如果節點在NOS狀態下，一直處于慢恢復，會帶來什么問題呢？節點一直在慢恢復期，意味著該節點不會外報文(應用報文和網絡管理報文均不會外發)，其他節點會上報對應的節點丟失故障。



審核編輯：劉清