CAN总线网络是一个广播网络，每个节点（如下图中的ECUA）向总线请求发送CAN数据帧，获得允许后开始发送；每个节点发送的CAN报文都在CAN网络传输，每个节点根据自身需求过滤接收到的报文，只处理需要接收的报文。
1.2BusOff是什么？
BusOff是CAN网络节点的一种故障状态，即CAN网络节点处于总线关闭状态，接收和发送功能都关闭了。
为什么？
为了保证CAN网络通信的稳定可靠性。
若某个节点持续的发生发送错误，或者接收错误，直接将该节点通信功能关闭，减少CAN网络上的错误帧，保护珍贵的信道资源。也就是从源头做起，减少CAN网络上错误帧，保证CAN网络中其他节点通信正常。
CAN网络上的节点分为三种状态，即主动错误，被动错误，总线关闭三种状态1。
CAN网络节点状态
状态介绍接收功能发送功能
Tips：如果总线上只有一个节点，该节点发送数据帧后得不到应答，TEC最大只能计数到128，即这种情况下节点只会进入被动错误状态而不会进入总线关闭状态。
CAN网络节点状态机变换
TEC:发送计数器（芯片实现），发送失败，也就是CANoetrace窗口上的Txerror，TEC+8;发送成功，TEC-83。
REC：接收计数器（芯片实现），接收失败，也就是CANoetrace窗口上的Rxerror4，REC减少；接收成功,REC增加。
CANBusoff恢复策略
1、快恢复（L1）
2、慢恢复（L2）
1、成熟条件
节点通信丢失类DTC使能条件
BusOff产生后，不再记录通信类DTC，原因显而易见，所有通信类DTC都会产生，记录没有意义，不能准确定位到是什么通信故障发生，有一个Busoff的DTC就够了。
3.1需求分析
根据文档5中需求分析，对CANBusOff恢复功能进行需求分解，主要划分给了CANDriver,CANInterface,CANstateManager三个模块。
CANDriver要做什么？
CANInterface要做什么？
CANStateManager要做什么？
TheCanSmmoduleisresponsibleformodecontrolmanagementofallsupportedCANControllersandCANTransceivers.
该模块需要实现为每一个CAN控制器实现CANBusOff恢复算法[SRS_Can_01146]
该模块需要提供一个接口，以在上电初始化时，支持通信模式配置（Nocommunication，orsilentcommunication)[SRS_Can_01144]
3.2.静态设计
3.2.1CANDriver
需求追溯表
根据参考文档6中描述，BUSOFF事件会引起CANdriver模块状态机变化，CANDriver状态由STARTED变为STOPPED，同时，通知CANInterface模块发生BUSOFF事件。
3.2.2CANInterface
3.2.3CANStatemanager
3.2.4接口
各个函数接口的参数，返回值，或其他特性在此不再赘述，具体可参考三个模块的AUTOSAR标准文档。其中，CANStateManager模块使用到ComM，BswM,Dem三个模块的函数的具体定义，可参考其相应AUTOSAR标准文档。
3.3动态设计
CAN网络节点发生BusOff事件后，AUTOSAR标准中BusOff恢复策略分为以下三步：
Step1.CANBusOff事件上报。
Step2.执行CANBusOff事件恢复策略。
Step3.根据策略，执行相应动作。
各步骤具体介绍见以下章节介绍。
3.3.1CANBusoff发生后，怎么办？
外设CANcontroller发生BusOff事件怎么办？这个可是最严重的事件，代表这个CAN网络节点掉线了，不能发送消息，也不能接收消息。你在这个圈里失联了，让你干的事，你干不了了；让你收集的有用信息，其他节点也获取不到了。彻底失联！
掉线了，这怎么办？
假如你在实际工作中，遇到这种紧急问题，咋办？
我的第一反应是，赶紧告诉领导！
对，在AUTOSAR标准中，也是这么设计的。看看下面这这几个模块是怎么层层上报的。当然，每个模块也是先要做好自己的事情，然后再上报。要不然，会挨批的。
3.3.2检测到BusOff后，如何处理？
AUTOSAR标准(V4.3.1)中，定义CANStatemanager模块负责实现CANBusOff恢复的策略。如下图所示，图中内容为CanStateManager模块实现的状态机CANSM_BSM，控制某个CANcontroller通信的状态。
Why
在状态CANSM_BSM_S_FULLCOM下需要进行BusOff事件的处理，意味着在CAN通信处于全通信（发送，接收功能正常）状态下，发生BusOff事件，需要进行BusOff。具体处理机制见子状态机CANSM_BSM_S_FULLCOM章节的描述。
在状态CANSM_BSM_S_SILENTCOM下，需要处理BusOff事件。一开始看到这个状态下需要发生BusOff事件会有些不解，这个状态下怎么会发生BusOff事件呢？Busoff事件不是在发送报文计数器TEC>255的条件下，才会发生吗？CANSM_BSM_S_SILENTCOM这个模式，不是代表静默模式吗，不就是只接收，不发送吗？不发送CAN报文，怎么会发送TEC>255的情况呢？
后来想到，这个场景可能在临界的情况下发生，也就是CANStateManager请求进入CANSM_BSM_S_SILENTCOM状态后，下层CANcontroller外设还在发送CAN报文，发送不能成功，也就可能发生了BusOff的事件。
CANSM_BSM_S_SILENTCOM状态下，BusOff恢复处理机制见子状态机CANSM_BSM_S_SILENTCOM_BOR中的描述。
CAN通信网络在在子状态机CANSM_BSM_S_FULLCOM下，处于全功能通信状态（发送，接收功能正常）。进入此状态的条件，需要完成一系列外设初始化的条件，还有系统外围环境的判断，属于状态机CANSM_BSM的内容，与本文主题BusOff无关，暂不赘述。
如下图所示，
1、TriggerT_BUS_OFF
根据参考文档7中需求[SWS_CanSM_00500]中描述，CanSM若收到下层模块CanInterface关于BusOff的事件报告后（报告方式见3.3.1章节），状态机CANSM_BSM_S_FULLCOM中TriggerT_BUS_OFF成立(见下图中1,2处)，执行EffectE_BUS_OFF
2、EffectE_BUS_OFF
3、S_RESTART_CC
进入S_RESTART_CC状态后（见下图中3处），根据参考文档7中需求[SWS_CanSM_00509]，CANStateManager模块应当执行改变CANcontroller状态请求，具体执行方式见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收到所有CANController的modeindication（具体过程见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
**EFFECT:E_TX_ON**
GuardconditionG_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_00497]中描述，当配置参数CanSMBorTxConfirmationPolling[ECUC_CanSM_00339]为真时，需要APICanIf_GetTxConfirmationState(ref.tochapter8.5.1)返回状态CANIF_TX_RX_NOTIFICATION。
如下图所示，为CANSM_BSM_S_SILENTCOM_BOR子状态机图
1、Effect:E_BUS_OFF
根据参考文档7[SWS_CanSM_00605]需求描述，CanSM需要调用Dem_SetEventStatus()向DEM模块通告BUSOFFDTCprefailed信息
Stateoperation:
根据参考文档7[SWS_CanSM_00604]需求描述，子状态机在S_RESTART_CC状态下，CanSM会向所有CANcontroller发送状态设置为CAN_CS_STARTED的请求。该请求具体执行过程见3.3.3章节
2、Trigger:T_RESTART_CC_INDICATED
根据参考文档7[SWS_CanSM_00600]需求描述，若CanSM收到所有CANController的modeindication（具体过程见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
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表示，设置所有CANController的请求已经发出，且返回值OK。但CANcontroller真正恢复情况的状态还不可知，此时也不能再次请求设置CANcontroller状态，在状态下S_RESTART_CC呆着也不合适，因为此状态下，要一直请求设置CANcontroller状态。因此，需要一个设置操作完成，等待CANcontroller恢复的状态。归根到底，如此设计的原因是CANcontroller状态不会一下子就会从BUSOFF状态下恢复的，需要等待。这也就是下图中路径2与路径3,4同时存在的原因。
3.3.3如何执行，控制CANcontroller状态
如下图中1处所示，为CanSM模块获取BUSOFF事件发生后，请求设置CANcontroller的执行流程。
下图中2处表示，Cancontroller状态恢复为STARTTED状态后，向CanSM模块报告状态的流程。
3.4还需要干什么？
4.1如何制造BusOff
恢复次数
CanSM,CanIf,CanDrv模块中应用的设计原则
应用到的设计模式：
封装，封装下层驱动接口，是上层隔离下层驱动的变化。切换MCU平台时，不影响上层逻辑。
通道负责通道的活，例如CanIf,CanDrv,不涉及到BUSOFF逻辑处理，只负责为上层提供控制接口。
CanSM负责CANcontroller的状态机逻辑控制。
标准之所以可以成为标准，在于其可以拥抱变化。也许你会说，这么写代码，得占用多少ROM啊？诚然，为CAN驱动，加上层层的封装，增加了很多冗余代码。不如直接访问底层驱动，多么简单！如果你经历过产品换了一个芯片平台，你就会认识到这个设计的意义所在。
或者说，我们做的产品只有一个CAN通道，不需要写这么复杂吧？为了适配这种更复杂的硬件平台，AUTOSAR确实增加了冗余代码，
CanSM,CanIf,CanDrv这种模式，可作为今后实现外设状态管理的参考模式。