Hi，大家好，我是编程小6，很荣幸遇见你，我把这些年在开发过程中遇到的问题或想法写出来，今天说一说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网络上的节点分为三种状态，即主动错误，被动错误，总线关闭三种状态¹。

• CAN网络节点状态

状态	介绍	接收功能	发送功能
Error Active，错误激活（主动错误）	可信状态，可以主动识别出错误，并发出主动错误帧	正常	正常
Error Passive，错误认可（被动错误）	相对可信状态，可以识别错误，发出被动错误帧	正常	正常
Bus Off ，总线关闭	总线关闭状态，关闭发送接收功能	关闭	关闭

Tips：如果总线上只有一个节点，该节点发送数据帧后得不到应答，TEC最大只能计数到128，即这种情况下节点只会进入被动错误状态而不会进入总线关闭状态²。

• CAN网络节点状态机变换

TEC: 发送计数器（芯片实现），发送失败，也就是CANoe trace 窗口上的Tx error ， TEC+8;发送成功，TEC-8³。

REC：接收计数器（芯片实现），接收失败，也就是CANoe trace 窗口上的Rx error⁴ ，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 需求分析

根据文档⁵中需求分析，对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

根据参考文档⁶中描述， 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

   根据参考文档⁷中需求[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

   根据参考文档⁷中需求[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处），根据参考文档⁷中需求[SWS_CanSM_00509]， CAN State Manager 模块应当执行改变CAN controller状态请求，具体执行方式见3.3.3章节。

4. G_RESTART_CC_OK

   根据参考文档⁷中[SWS_CanSM_00510]需求描述，需求[SWS_CanSM_00509]中所调用API 都返回E_OK后，此条件成立，进入状态CANSM_BSM_S_RESTART_CC_WAIT

5. T_RESTART_CC_INDICATED

   根据参考文档⁷中[SWS_CanSM_00511]需求描述，若CanSM收到所有CAN Controller的mode indication（具体过程见3.3.3章节），会触发子状态机的T_RESTART_CC_INDICATED触发器，执行E_TX_OFF

6. EFFECT: E_TX_OFF

   根据参考文档⁷，什么行为也不执行。进入S_TX_OFF状态

7. S_TX_OFF

   此状态下什么也不执行，判断G_TX_ON条件是否成立

8. G_TX_ON

   如下图中8处，根据参考文档⁷中[SWS_CanSM_00514]需求描述，若CanSMEnableBusOffDelay参数为FALSE，上一次BUS OFF事件发生后，若BUS OFF 恢复不成功次数小于CanSMBorCounterL1ToL2 [ECUC_CanSM_00131 ], 且L1（快）恢复间隔时间CanSMBorTimeL1 [ECUC_CanSM_00128 ]已到达，触发器G_TX_ON条件成立；

   根据参考文档⁷中 [SWS_CanSM_00515] 需求描述，若CanSMEnableBusOffDelay参数为FALSE，上一次BUS OFF事件发生后，若BUS OFF 恢复不成功次数大于，或者等于CanSMBorCounterL1ToL2 [ECUC_CanSM_00131 ], 且L2（慢）恢复间隔时间CanSMBorTimeL2[ECUC_CanSM_00129 ]已到达，触发器G_TX_ON条件成立；

   根据参考文档⁷中 [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

   根据参考文档⁷中[SWS_CanSM_00516] [SWS_CanSM_00648] [SWS_CanSM_00517] [SWS_CanSM_00518] 需求描述，如果ECU 处于被动通信（PASSIVE）状态下，CanSM需要将相应controller的状态设置为CANIF_TX_OFFLINE_ACTIVE；若非被动通信状态下，将CANIF状态设置为CANIF_ONLINE。

   同时，需要同时BswM⁸，ComM⁹模块，已处于CANSM_BSWM_FULL_COMMUNICATION,COMM_FULL_COMMUNICATION状态下。

   然后进入S_BUS_OFF_CHECK状态，表示

9. G_BUS_OFF_PASSIVE

   根据参考文档⁷中需求描述，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

   根据参考文档⁷ [SWS_CanSM_00605] 需求描述，CanSM需要调用Dem_SetEventStatus()向DEM模块通告BUS OFF DTC prefailed信息

   State operation:

   根据参考文档⁷ [SWS_CanSM_00604] 需求描述，子状态机在S_RESTART_CC状态下，CanSM会向所有CAN controller发送状态设置为CAN_CS_STARTED的请求。该请求具体执行过程见3.3.3章节

2. Trigger: T_RESTART_CC_INDICATED
   根据参考文档⁷[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
   根据参考文档⁷[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

   根据参考文档⁷ [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

   根据参考文档⁷，什么行为也不执行。然后，直接退出状态，根据状态机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）, 可参考 ³

• 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通信管理 ↩︎

今天的分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。