AUTOSAR如何實作CAN Bus Off恢複的功能?

1. 什麼是CAN Bus Off ?

1.1 什麼是CAN 網絡？

汽車車輛CAN網絡由多個CAN網絡組成，如動力CAN網絡，資訊娛樂CAN網絡等。不同CAN網絡之間的通信，通過網關（Gateway）轉發。如資訊娛樂CAN網絡上需要的發動機相關的CAN信号，就需要網關從動力CAN網絡上轉發。

CAN總線網絡是一個廣播網絡，每個節點（如下圖中的ECU A）向總線請求發送CAN 資料幀，獲得允許後開始發送；每個節點發送的CAN封包都在CAN網絡傳輸，每個節點根據自身需求過濾接收到的封包，隻處理需要接收的封包。

1.2 Bus Off是什麼？

Bus Off是CAN網絡節點的一種故障狀态，即CAN網絡節點處于總線關閉狀态，接收和發送功能都關閉了。

為什麼？

為了保證CAN網絡通信的穩定可靠性。

若某個節點持續的發生發送錯誤，或者接收錯誤，直接将該節點通信功能關閉，減少CAN網絡上的錯誤幀，保護珍貴的信道資源。也就是從源頭做起，減少CAN網絡上錯誤幀，保證CAN網絡中其他節點通信正常。

CAN網絡上的節點分為三種狀态，即主動錯誤，被動錯誤，總線關閉三種狀态1。

• CAN網絡節點狀态

狀态	介紹	接收功能	發送功能
Error Active，錯誤激活（主動錯誤）	可信狀态，可以主動識别出錯誤，并發出主動錯誤幀	正常	正常
Error Passive，錯誤認可（被動錯誤）	相對可信狀态，可以識别錯誤，發出被動錯誤幀	正常	正常
Bus Off ，總線關閉	總線關閉狀态，關閉發送接收功能	關閉	關閉

Tips：如果總線上隻有一個節點，該節點發送資料幀後得不到應答，TEC最大隻能計數到128，即這種情況下節點隻會進入被動錯誤狀态而不會進入總線關閉狀态2。

• CAN網絡節點狀态機變換

TEC: 發送計數器（晶片實作），發送失敗，也就是CANoe trace 視窗上的Tx error ， TEC+8;發送成功，TEC-83。

REC：接收計數器（晶片實作），接收失敗，也就是CANoe trace 視窗上的Rx error4 ，REC減少；接收成功, REC增加。

狀态	Error Active	Error Passive	Bus Off
Error Active	TEC <= 127 OR REC <= 127	TEC > 127 OR REC >127	/
Error Passive	TEC < 128 OR REC < 128	TEC >127 OR REC >127	TEC > 255
Bus Off	Normal Request and 128 11 recessive bits	/	TEC >255

2. 整車廠關于CAN BusOff的恢複政策需求是什麼？

國内整車廠對于CAN Busoff 的測試較為嚴格，尤其是引進第三方測試團隊之後，對需求的測試覆寫度很高。無論是項目管理，還是工程師（包括系統，軟體），對此要有清晰的認識，避免在這個基本功能上犯錯誤。現将與CAN Bus Off相關的需求總結如下：

• CAN Bus off恢複政策
  • 快恢複（L1）
    • 恢複時間, <=100ms
    • 恢複次數，5~10次不等
  • 慢恢複（L2）
    • 恢複間隔, [200ms, 1s]
    • 恢複次數, 不限
• CAN Bus Off DTC 相關需求
  • 成熟條件
    • 恢複N次不能成功之後，記錄DTC，N的具體數值，各個OEM定義不同。
• 節點通信丢失類DTC 使能條件

Bus Off産生後，不再記錄通信類DTC，原因顯而易見，所有通信類DTC都會産生，記錄沒有意義，不能準确定位到是什麼通信故障發生，有一個Bus off 的DTC就夠了。

3. Autosar如何實作CAN BusOff恢複政策 ?

3.1 需求分析

根據文檔5中需求分析，對CAN Bus Off恢複功能進行需求分解，主要劃分給了CAN Driver, CAN Interface, CAN state Manager三個子產品。

• CAN Driver要做什麼？

  該子產品負責實作供一個報告CAN Bus off狀态的接口[SRS_Can_01055], 但不能自動恢複[SRS_Can_01060]

• CAN Interface 要做什麼？

​ 該子產品需要實作向上層報告CAN Bus Off狀态的接口[SRS_CAN_01029]

• CAN State Manager要做什麼？

​ The CanSm module is responsible for mode control management of all supported CAN Controllers and CAN Transceivers.

​ 該子產品需要實作為每一個CAN控制器實作CAN Bus Off恢複算法[SRS_Can_01146]

​ 該子產品需要支援CAN Bus Off恢複時間配置[SRS_Can_01143]

​ 該子產品需要提供一個接口，以在上電初始化時，支援通信模式配置（No communication，or silent communication)[SRS_Can_01144]

3.2. 靜态設計

下面根據文章，介紹下CAN Driver，CAN Interface，CAN State Manager三個子產品的靜态設計，主要内容有需求追溯表，本子產品關于Bus Off的需求定義，以及接口定義。

3.2.1 CAN Driver

需求追溯表

Requirement	Description	Satisfied by
SRS_Can_01055	The CAN Driver shall provide a notification for bus-off state	SWS_Can_00020, SWS_Can_00234
SRS_Can_01060	The CAN driver shall not recover from bus-off automatically	SWS_Can_00272, SWS_Can_00273, SWS_Can_00274

根據參考文檔6中描述， BUS OFF 事件會引起 CAN driver子產品狀态機變化，CAN Driver狀态由

STARTED

變為

STOPPED

，同時，通知CAN Interface子產品發生BUS OFF事件。

State transition caused by Bus-Off (triggered by state change of CAN controller)

[SWS_Can_00020][

• STARTED -> STOPPED
• triggered by hardware if the CAN controller reaches bus-off state
• The CanIf module is notified with the function CanIf_ControllerBusOff() after STOPPED state is reached referring to the corresponding CAN controller with the abstract CanIf Controller Id.]

[SWS_Can_00234] [

API function	Description
CanIf_ControllerBusOff	This service indicates a Controller Bus Off event referring to the corresponding CAN Controller with the abstract CanIf Controller Id.
CanIf_ControllerModeIndication	This service indicates a controller state transition referring to the corresponding CAN controller with the abstract CanIf Controller Id.
CanIf_RxIndication	This service indicates a successful reception of a received CAN Rx L-PDU to the CanIf after passing all filters and validation checks.
CanIf_TxConfirmation	This service confirms a previously successfully processed transmission of a CAN TxPDU.
Det_ReportRuntimeError	Service to report runtime errors. If a callout has been configured then this callout shall be called.
GetCounterValue	This service reads the current count value of a counter (returning either the hardware timer ticks if counter is driven by hardware or the software ticks when user drives counter).

] ( SRS_Can_01055)

[SWS_Can_00272] ⌈ After bus-off detection, the CAN controller shall transition to the state STOPPED and the Can module shall ensure that the CAN controller doesn’t participate on the network anymore. ⌋ (SRS_Can_01060)

[SWS_Can_00273] ⌈ After bus-off detection, the Can module shall cancel still pending messages. ⌋ (SRS_Can_01060)

[SWS_Can_00274] ⌈ The Can module shall disable or suppress automatic bus-off recovery. ⌋ (SRS_Can_01060)

3.2.2 CAN Interface

需求追溯表

Requirement	Description	Satisfied by
SRS_CAN_01029	The CAN Interface shall report bus-off state of a device to an upper layer	[SWS_CANIF_00014]

[SWS_CANIF_00014]

[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直接上傳(img-jBvtWg8U-1626706029118)(01_BusOff.assets/SWS_CANIF_00014.png)]

3.2.3 CAN State manager

需求追溯表

Requirement	Description	Satisfied by
[SRS_Can_01143]
[SRS_Can_01144]	The CAN State Manager shall support a configurable BusOff recovery time	SWS_CanSM_00600, SWS_CanSM_00602, SWS_CanSM_00603, SWS_CanSM_00604, SWS_CanSM_00606, SWS_CanSM_00637
[SRS_Can_01146]	The CAN State Manager shall contain a CAN BusOff recovery algorithm for each used CAN Controller	SWS_CanSM_00600, SWS_CanSM_00602, SWS_CanSM_00603, SWS_CanSM_00604, SWS_CanSM_00606, SWS_CanSM_00637

[SWS_CanSM_00606] ⌈ The callback function CanSM_ControllerBusOff (ref. to SWS_CanSM_00064) shall trigger the state machine CANSM_BSM (ref. to Figure 7-1) for the CAN network with T_BUS_OFF, if one of its configured CAN controllers matches to the function parameter ControllerId of the callback function CanSM_ControllerBusOff. ⌋ (SRS_Can_01144, SRS_Can_01146)

[SWS_CanSM_00600] ⌈ If CanSM module has got all mode indications (ref. to SWS_CanSM_00396) for the configured CAN controllers of the CAN network (ref. to ECUC_CanSM_00141) after the respective requests to start the CAN controllers of the CAN network (ref. to SWS_CanSM_00604), this shall trigger the sub state CANSM_BSM_S_SILENTCOM_BOR (ref. to Figure 7-6) of the CAN network with T_RESTART_CC_INDICATED. ⌋ (SRS_Can_01142, SRS_Can_01145, SRS_Can_01144, SRS_Can_01146)

[SWS_CanSM_00602] ⌈ After a timeout of CANSM_MODEREQ_REPEAT_TIME (ref. to ECUC_CanSM_00336) for all supposed controller started mode indications (ref. to SWS_CanSM_00600), this condition shall trigger the sub state machine CANSM_BSM_S_SILENTCOM_BOR (ref. to Figure 7-6) of the respective network with T_RESTART_CC_TIMEOUT. ⌋ (SRS_Can_01142, SRS_Can_01145, SRS_Can_01144, SRS_Can_01146)

[SWS_CanSM_00604] ⌈ As long the sub state machine CANSM_BSM_S_SILENTCOM_BOR (ref. to Figure 7-6) is in the state S_RESTART_CC, the CanSM module shall operate the do action DO_SET_CC_MODE_STARTED and therefore repeat for all configured CAN controllers of the CAN network (ref. to

ECUC_CanSM_00141) the API request CanIf_SetControllerMode (ref. to chapter 8.5.1) with ControllerMode equal to CAN_CS_STARTED, if the current

CAN controller mode (ref. to SWS_CanSM_00638) is different. ⌋ (SRS_Can_01142, SRS_Can_01145, SRS_Can_01144, SRS_Can_01146)

[SWS_CanSM_00603] ⌈ The guarding condition G_RESTART_CC_OK of the sub state machine CANSM_BSM_S_SILENTCOM_BOR (ref. to Figure 7-6) shall be passed, if all API calls of SWS_CanSM_00604 have returned E_OK. ⌋ (SRS_Can_01142, SRS_Can_01145, SRS_Can_01144, SRS_Can_01146)

[SWS_CanSM_00637]

3.2.4 接口

CAN Driver，CAN Interface，CAN State Manager三個子產品中與Bus Off 恢複相關接口定義如下圖所示，各子產品内部為其所實作的接口，各子產品之間的連接配接線，代表子產品間的依賴關系。如ComM子產品和Can State Manager子產品之間的依賴關系，表示Can State Manager子產品要使用ComM子產品實作的ComM_BusSM_ModeIndication接口，該接口由ComM子產品負責實作。其他子產品之間的依賴關系同此方式，連線圓圈端表示接口提供端，另一端為調用方。

各個函數接口的參數，傳回值，或其他特性在此不再贅述，具體可參考三個子產品的AUTOSAR标準文檔。其中，CAN State Manager 子產品使用到ComM，BswM, Dem三個子產品的函數的具體定義，可參考其相應AUTOSAR标準文檔。

3.3 動态設計

CAN網絡節點發生Bus Off事件後， AUTOSAR 标準中Bus Off恢複政策分為以下三步：

Step 1. CAN Bus Off事件上報。

Step 2. 執行CAN Bus Off 事件恢複政策。

Step 3. 根據政策，執行相應動作。

各步驟具體介紹見以下章節介紹。

3.3.1 CAN Bus off發生後，怎麼辦 ？

外設CAN controller發生Bus Off事件怎麼辦？這個可是最嚴重的事件，代表這個CAN網絡節點掉線了，不能發送消息，也不能接收消息。你在這個圈裡失聯了，讓你幹的事，你幹不了了；讓你收集的有用資訊，其他節點也擷取不到了。徹底失聯！

掉線了，這怎麼辦？

假如你在實際工作中，遇到這種緊急問題，咋辦？

我的第一反應是，趕緊告訴上司！

對，在AUTOSAR标準中，也是這麼設計的。看看下面這這幾個子產品是怎麼層層上報的。當然，每個子產品也是先要做好自己的事情，然後再上報。要不然，會挨批的。

1. CAN controller（外設，MCU晶片内部內建）檢測到Bus Off事件發生後，向 CAN Driver子產品報告事件
2. CAN Driver子產品設定 CAN controller狀态為STOPPED狀态
3. CAN Driver執行完其相應職責，調用CanIf_ControllerBusOff()函數，向上層子產品Can Interface 通知Bus Off事件
4. CAN Interface子產品收到資訊後，更改該controller狀态，重置其發送封包序列
5. CAN Interface 執行完其相應職責後，調用函數CanSM_ControllerBusOff(), 向上層CAN State Manager子產品，報告 Bus Off事件。

   

3.3.2 檢測到Bus Off後，如何處理？

AUTOSAR标準(V4.3.1) 中，定義CAN State manager子產品負責實作CAN Bus Off恢複的政策。如下圖所示，圖中内容為Can State Manager子產品實作的狀态機CANSM_BSM，控制某個CAN controller通信的狀态。

CANSM_BSM狀态機中，CANSM_BSM_S_FULLCOM，CANSM_BSM_S_SILENTCOM，這兩個狀态與Bus Off事件相關。Why??

在狀态CANSM_BSM_S_FULLCOM下需要進行Bus Off事件的處理，意味着在CAN通信處于全通信（發送，接收功能正常）狀态下，發生Bus Off事件，需要進行Bus Off。具體處理機制見子狀态機CANSM_BSM_S_FULLCOM章節的描述。

在狀态CANSM_BSM_S_SILENTCOM下，需要處理Bus Off事件。一開始看到這個狀态下需要發生Bus Off事件會有些不解，這個狀态下怎麼會發生Bus Off事件呢？Bus off事件不是在發送封包計數器TEC>255的條件下，才會發生嗎？CANSM_BSM_S_SILENTCOM這個模式，不是代表靜默模式嗎，不就是隻接收，不發送嗎？不發送CAN封包，怎麼會發送TEC > 255的情況呢？

後來想到，這個場景可能在臨界的情況下發生，也就是CAN State Manager請求進入CANSM_BSM_S_SILENTCOM狀态後，下層CAN controller外設還在發送CAN封包，發送不能成功，也就可能發生了Bus Off的事件。

CANSM_BSM_S_SILENTCOM狀态下，Bus Off恢複處理機制見子狀态機CANSM_BSM_S_SILENTCOM_BOR中的描述。

• 子狀态機CANSM_BSM_S_FULLCOM

CAN 通信網絡在在子狀态機

CANSM_BSM_S_FULLCOM

下，處于全功能通信狀态（發送，接收功能正常）。進入此狀态的條件，需要完成一系列外設初始化的條件，還有系統外圍環境的判斷，屬于狀态機CANSM_BSM的内容，與本文主題Bus Off無關，暫不贅述。

如下圖所示，

1. Trigger T_BUS_OFF

   根據參考文檔7中需求[SWS_CanSM_00500] 中描述，CanSM若收到下層子產品Can Interface關于Bus Off的事件報告後（報告方式見3.3.1章節），狀态機CANSM_BSM_S_FULLCOM中Trigger T_BUS_OFF成立(見下圖中1,2處)，執行Effect E_BUS_OFF

2. Effect E_BUS_OFF

   根據參考文檔7中需求

   [SWS_CanSM_00508] [SWS_CanSM_00521] [SWS_CanSM_00522]

   中描述，CAN State Manager擷取到發生Bus Off資訊後，需要向BswM, ComM子產品報告自己目前狀态變化，并設定Bus Off相關的DTC為

   DEM_EVENT_STATUS_PRE_FAILED

   狀态。完成上述操作後，進入S_RESTART_CC狀态。

3. S_RESTART_CC

   進入S_RESTART_CC狀态後（見下圖中3處），根據參考文檔7中需求

   [SWS_CanSM_00509]

   ， CAN State Manager 子產品應當執行改變CAN controller狀态請求，具體執行方式見3.3.3章節。

4. G_RESTART_CC_OK

   根據參考文檔7中

   [SWS_CanSM_00510]

   需求描述，需求

   [SWS_CanSM_00509]

   中所調用API 都傳回E_OK後，此條件成立，進入狀态CANSM_BSM_S_RESTART_CC_WAIT

5. T_RESTART_CC_INDICATED

   根據參考文檔7中

   [SWS_CanSM_00511]

   需求描述，若CanSM收到所有CAN Controller的mode indication（具體過程見3.3.3章節），會觸發子狀态機的T_RESTART_CC_INDICATED觸發器，執行E_TX_OFF

6. EFFECT: E_TX_OFF

   根據參考文檔7，什麼行為也不執行。進入S_TX_OFF狀态

7. S_TX_OFF

   此狀态下什麼也不執行，判斷G_TX_ON條件是否成立

8. G_TX_ON

   如下圖中8處，根據參考文檔7中[SWS_CanSM_00514]需求描述，若CanSMEnableBusOffDelay參數為FALSE，上一次BUS OFF事件發生後，若BUS OFF 恢複不成功次數小于CanSMBorCounterL1ToL2 [ECUC_CanSM_00131 ], 且L1（快）恢複間隔時間CanSMBorTimeL1 [ECUC_CanSM_00128 ]已到達，觸發器G_TX_ON條件成立；

   根據參考文檔7中 [SWS_CanSM_00515] 需求描述，若CanSMEnableBusOffDelay參數為FALSE，上一次BUS OFF事件發生後，若BUS OFF 恢複不成功次數大于，或者等于CanSMBorCounterL1ToL2 [ECUC_CanSM_00131 ], 且L2（慢）恢複間隔時間CanSMBorTimeL2[ECUC_CanSM_00129 ]已到達，觸發器G_TX_ON條件成立；

   根據參考文檔7中 [SWS_CanSM_00636] 需求描述，若CanSMEnableBusOffDelay參數為TRUE，則需求[SWS_CanSM_00514]，[SWS_CanSM_00515] 中觸發器G_TX_ON成立條件，需要額外加上有回調函數<User_GetBusOffDelay>制定的時間；

   **EFFECT: E_TX_ON **

   Guard condition G_TX_ON條件成立後，子狀态機執行E_TX_ON

   根據參考文檔7中[SWS_CanSM_00516] [SWS_CanSM_00648] [SWS_CanSM_00517] [SWS_CanSM_00518] 需求描述，如果ECU 處于被動通信（PASSIVE）狀态下，CanSM需要将相應controller的狀态設定為

   CANIF_TX_OFFLINE_ACTIVE

   ；若非被動通信狀态下，将CANIF狀态設定為

   CANIF_ONLINE

   。

   同時，需要同時BswM8，ComM9子產品，已處于

   CANSM_BSWM_FULL_COMMUNICATION

   ,

   COMM_FULL_COMMUNICATION

   狀态下。

   然後進入S_BUS_OFF_CHECK狀态，表示

9. G_BUS_OFF_PASSIVE

   根據參考文檔7中需求描述，G_BUS_OFF_PASSIVE成立的條件有兩種：

   一種以需求[SWS_CanSM_00496] 中描述，當配置參數

   CanSMBorTxConfirmationPolling [ECUC_CanSM_00339]

   為假時，需要等待配置參數

   CanSMBorTimeTxEnsured [ECUC_CanSM_00130]

   定義時間，以確定Bus OFF恢複。

   或者，以需求[SWS_CanSM_00497] 中描述，當配置參數

   CanSMBorTxConfirmationPolling [ECUC_CanSM_00339]

   為真時，需要API CanIf_GetTxConfirmationState (ref. to

   chapter 8.5.1) 傳回狀态

   CANIF_TX_RX_NOTIFICATION

   。

   G_BUS_OFF_PASSIVE成立後，執行E_BUS_OFF_PASSIVE，也就是按[SWS_CanSM_00498]需求中定義，調用

   Dem_SetEventStatus()

   設定BUS OFF相關DTC為

   DEM_EVENT_STATUS_PASSED.

   狀态

• 子狀态機CANSM_BSM_S_SILENTCOM_BOR

如下圖所示，為CANSM_BSM_S_SILENTCOM_BOR子狀态機圖

1. Effect: E_BUS_OFF

   根據參考文檔7 [SWS_CanSM_00605] 需求描述，CanSM需要調用

   Dem_SetEventStatus()

   向DEM子產品通告BUS OFF DTC prefailed資訊

   State operation:

   根據參考文檔7 [SWS_CanSM_00604] 需求描述，子狀态機在S_RESTART_CC狀态下，CanSM會向所有CAN controller發送狀态設定為

   CAN_CS_STARTED

   的請求。該請求具體執行過程見3.3.3章節

2. Trigger: T_RESTART_CC_INDICATED

   根據參考文檔7[SWS_CanSM_00600] 需求描述，若CanSM收到所有CAN Controller的mode indication（具體過程見3.3.3章節），會觸發子狀态機的T_RESTART_CC_INDICATED觸發器，執行E_TX_OFF

3. Guard：G_RESTART_CC_E_OK

   根據參考文檔7[SWS_CanSM_00603] 需求描述，若CanSM收到在S_RESTART_CC狀态下所有設定行為的傳回值E_OK，則此條件成立，進入CANSM_BSM_S_RESTART_CC_WAIT狀态。

4. Trigger: T_RESTART_CC_INDICATED

   行為同下圖中2處Trigger

5. Trigger: T_RESTART_CC_TIMEOUT

   根據參考文檔7 [SWS_CanSM_00602]需求描述，子狀态機若在定時器CANSM_MODEREQ_REPEAT_TIME[refer to]時間内，未收到所有CAN controller的mode indication，視為請求逾時，觸發器T_RESTART_CC_TIMEOUT條件成立。重新進入S_RESTART_CC狀态

6. Effect: E_TX_OFF

   根據參考文檔7，什麼行為也不執行。然後，直接退出狀态，根據狀态機CANSM_BSM圖中所示，進入狀态CANSM_BSM_S_SILENTCOM。

在子狀态機CANSM_BSM_S_SILENTCOM_BOR中，有了下圖中的路徑2，為什麼需要狀态CANSM_BSM_S_RESTART_CC_WAIT？

根據我目前的了解，狀态CANSM_BSM_S_SILENTCOM_BOR表示，設定所有CAN Controller的請求已經發出，且傳回值OK。但CAN controller真正恢複情況的狀态還不可知，此時也不能再次請求設定CAN controller狀态，在狀态下S_RESTART_CC呆着也不合适，因為此狀态下，要一直請求設定CAN controller狀态。是以，需要一個設定操作完成，等待CAN controller恢複的狀态。歸根到底，如此設計的原因是CAN controller狀态不會一下子就會從BUS OFF狀态下恢複的，需要等待。這也就是下圖中路徑2與路徑3,4同時存在的原因。

3.3.3 如何執行，控制CAN controller 狀态

如下圖中1處所示，為CanSM子產品擷取BUS OFF 事件發生後，請求設定CAN controller的執行流程。

下圖中2處表示，Can controller狀态恢複為

STARTTED

狀态後，向CanSM子產品報告狀态的流程。

3.4 還需要幹什麼？

按照客戶關于BUS OFF快恢複，慢恢複的時間，次數要求，配置以下參數值：

• CanSMBorTimeL1 [ECUC_CanSM_00128 ]：快恢複時間
• CanSMBorTimeL2 [ECUC_CanSM_00129 ]： 慢恢複時間
• CanSMBorCounterL1ToL2 [ECUC_CanSM_00131 ] : 如下文中定義，此參數定義了由快恢複轉變為慢恢複的次數，也就是說，若配置此參數為6次，則在第6次恢複時變為慢恢複，則快恢複次數實際上是5次。也可參考需求[SWS_CanSM_00514] [SWS_CanSM_00515]的定義。

This threshold defines the count of bus-offs until the bus-off recovery switches from level 1 (short recovery time) to level 2 (long recovery time). 
           

• 還需要指定BUS OFF引用的DTC

4. 如何驗證CAN Bus Off恢複功能？

4.1 如何制造BusOff

• 工具，CAN disturbance（VECTOR VH 6501）, 可參考 3
• CAN_H, CAN_L 短接
• CAN_H，或者CAN_L短接地
• 如何觀察CAN Bus Off現象

4.2 測試用例開發關注點

• L1（快） 恢複

恢複時間

恢複次數

• L2 （慢）恢複

恢複時間

• Bus Off DTC
• 對其他通信丢失類DTC的影響

5. 後感

CanSM, CanIf, CanDrv子產品中應用的設計原則

• 單一職責
• 對擴充打開，對修改關閉

應用到的設計模式：

• 封裝，封裝下層驅動接口，是上層隔離下層驅動的變化。切換MCU平台時，不影響上層邏輯。

通道負責通道的活，例如CanIf, CanDrv, 不涉及到BUS OFF邏輯處理，隻負責為上層提供控制接口。

CanSM負責CAN controller的狀态機邏輯控制。

标準之是以可以成為标準，在于其可以擁抱變化。也許你會說，這麼寫代碼，得占用多少ROM啊？誠然，為CAN 驅動，加上層層的封裝，增加了很多備援代碼。不如直接通路底層驅動，多麼簡單！如果你經曆過産品換了一個晶片平台，你就會認識到這個設計的意義所在。

或者說，我們做的産品隻有一個CAN 通道，不需要寫這麼複雜吧？為了适配這種更複雜的硬體平台，AUTOSAR确實增加了備援代碼，

CanSM, CanIf, CanDrv這種模式，可作為今後實作外設狀态管理的參考模式。

6. Ref

1. CAN總線錯誤處理機制及Bus off問題現象分析 ↩︎
2. CAN總線學習總結2——CAN錯誤及CAN busoff處理機制 ↩︎
3. CAN總線Busoff/快慢恢複原理以及利用Vector VH6501 CAN幹擾儀觸發Busoff ↩︎ ↩︎
4. CAN總線的通信錯誤及其處理 ↩︎
5. Requirements on CAN, V4.3.1, AUTOSAR_SRS_CAN.pdf. ↩︎
6. Specification of CAN Driver, V4.3.1, AUTOSAR_SWS_CANDriver.pdf. ↩︎
7. Specification of CAN State Manager V4.3.1, AUTOSAR_SWS_CANStateManager.pdf ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
8. AUTOSAR模式管理看這一篇就夠了-吐血整理 ↩︎
9. CP Classic AUTOSAR功能棧簡介-ComM通信管理 ↩︎