AUTOSAR如何实现CANBusOff恢复的功能.docx

1、AUTOSAR如何实现CANBusOff恢复的功能AUTOSAR如何实现CANBusOff恢复的功能什么是CAN Bus Off ?1.1 什么是CAN 网络？汽车车辆CAN网络由多个CAN网络组成，如动力CAN网络，信息娱乐CAN网络等。不同CAN网络之间的通信，通过网关（Gateway）转发。如信息娱乐CAN网络上需要的发动机相关的CAN信号，就需要网关从动力CAN网络上转发。CAN总线网络是一个广播网络，每个节点（如下图中的ECU A）向总线请求发送CAN 数据帧，获得允许后开始发送；每个节点发送的CAN报文都在CAN网络传输，每个节点根据自身需求过滤接收到的报文，只处理需要接收的报文。

2、1.2 Bus Off是什么？Bus Off是CAN网络节点的一种故障状态，即CAN网络节点处于总线关闭状态，接收和发送功能都关闭了。为什么？为了保证CAN网络通信的稳定可靠性。若某个节点持续的发生发送错误，或者接收错误，直接将该节点通信功能关闭，减少CAN网络上的错误帧，保护珍贵的信道资源。也就是从源头做起，减少CAN网络上错误帧，保证CAN网络中其他节点通信正常。CAN网络上的节点分为三种状态，即主动错误，被动错误，总线关闭三种状态1。CAN网络节点状态状态介绍接收功能发送功能Tips：如果总线上只有一个节点，该节点发送数据帧后得不到应答，TEC最大只能计数到128，即这种情况下节点只会进

3、入被动错误状态而不会进入总线关闭状态。CAN网络节点状态机变换TEC: 发送计数器（芯片实现），发送失败，也就是CANoe trace 窗口上的Tx error ， TEC+8;发送成功，TEC-83。REC：接收计数器（芯片实现），接收失败，也就是CANoe trace 窗口上的Rx error4 ，REC减少；接收成功, REC增加。整车厂关于CAN BusOff的恢复策略需求是什么？国内整车厂对于CAN Busoff 的测试较为严格，尤其是引进第三方测试团队之后，对需求的测试覆盖度很高。无论是项目管理，还是工程师（包括系统，软件），对此要有清晰的认识，避免在这个基本功能上犯错误。现将与C

4、AN Bus Off相关的需求总结如下：CAN Bus off恢复策略1、快恢复（L1）恢复时间, 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恢复处理机制见

5、子状态机CANSM_BSM_S_SILENTCOM_BOR中的描述。子状态机CANSM_BSM_S_FULLCOMCAN 通信网络在在子状态机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章节），状态

6、机CANSM_BSM_S_FULLCOM中Trigger T_BUS_OFF成立(见下图中1,2处)，执行Effect E_BUS_OFF2、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_RES

7、TART_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_WAIT5、T_RESTART_CC_INDICATED根据参考文档7中SWS_CanSM_00511需求描述，若CanSM收到所有CAN Controller的m

8、ode indication（具体过程见3.3.3章节），会触发子状态机的T_RESTART_CC_INDICATED触发器，执行E_TX_OFF6、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_0

9、0131 , 且L1（快）恢复间隔时间CanSMBorTimeL1 ECUC_CanSM_00128 已到达，触发器G_TX_ON条件成立；根据参考文档7中 SWS_CanSM_00515 需求描述，若CanSMEnableBusOffDelay参数为FALSE，上一次BUS OFF事件发生后，若BUS OFF 恢复不成功次数大于，或者等于CanSMBorCounterL1ToL2 ECUC_CanSM_00131 , 且L2（慢）恢复间隔时间CanSMBorTimeL2ECUC_CanSM_00129 已到达，触发器G_TX_ON条件成立；根据参考文档7中 SWS_CanSM_00636 需

10、求描述，若CanSMEnableBusOffDelay参数为TRUE，则需求SWS_CanSM_00514，SWS_CanSM_00515 中触发器G_TX_ON成立条件，需要额外加上有回调函数制定的时间；*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_

11、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为假时，需要等待配置参数

12、CanSMBorTimeTxEnsured ECUC_CanSM_00130定义时间，以确保Bus OFF恢复。或者，以需求SWS_CanSM_00497 中描述，当配置参数CanSMBorTxConfirmationPolling ECUC_CanSM_00339为真时，需要API CanIf_GetTxConfirmationState (ref. tochapter 8.5.1) 返回状态CANIF_TX_RX_NOTIFICATION 。G_BUS_OFF_PASSIVE成立后，执行E_BUS_OFF_PASSIVE，也就是按SWS_CanSM_00498需求中定义，调用Dem_Set

13、EventStatus()设置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

14、会向所有CAN controller发送状态设置为CAN_CS_STARTED的请求。该请求具体执行过程见3.3.3章节2、Trigger: T_RESTART_CC_INDICATED根据参考文档7SWS_CanSM_00600 需求描述，若CanSM收到所有CAN Controller的mode indication（具体过程见3.3.3章节），会触发子状态机的T_RESTART_CC_INDICATED触发器，执行E_TX_OFF3、Guard：G_RESTART_CC_E_OK根据参考文档7SWS_CanSM_00603 需求描述，若CanSM收到在S_RESTART_CC状态下所有设

15、置行为的返回值E_OK，则此条件成立，进入CANSM_BSM_S_RESTART_CC_WAIT状态。4、Trigger: T_RESTART_CC_INDICATED行为同下图中2处Trigger5、Trigger: T_RESTART_CC_TIMEOUT根据参考文档7 SWS_CanSM_00602需求描述，子状态机若在定时器CANSM_MODEREQ_REPEAT_TIMErefer to时间内，未收到所有CAN controller的mode indication，视为请求超时，触发器T_RESTART_CC_TIMEOUT条件成立。重新进入S_RESTART_CC状态6、Effec

16、t: 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_RESTA

17、RT_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模块报告状态的流程

18、。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的定义。Thisthresholddefinesthec

19、ountofbus-offsuntilthebus-offrecoveryswitchesfromlevel1(shortrecoverytime)tolevel2(longrecoverytime).还需要指定BUS OFF引用的DTC如何验证CAN Bus Off恢复功能？4.1 如何制造BusOff工具，CAN disturbance（VECTOR VH 6501）, 可参考 3CAN_H, CAN_L 短接CAN_H，或者CAN_L短接地如何观察CAN Bus Off现象4.2 测试用例开发关注点L1（快） 恢复恢复时间恢复次数L2 （慢）恢复恢复时间Bus Off DTC对其他通信丢

20、失类DTC的影响后感CanSM, CanIf, CanDrv模块中应用的设计原则单一职责对扩展打开，对修改关闭应用到的设计模式：封装，封装下层驱动接口，是上层隔离下层驱动的变化。切换MCU平台时，不影响上层逻辑。通道负责通道的活，例如CanIf, CanDrv, 不涉及到BUS OFF逻辑处理，只负责为上层提供控制接口。CanSM负责CAN controller的状态机逻辑控制。标准之所以可以成为标准，在于其可以拥抱变化。也许你会说，这么写代码，得占用多少ROM啊？诚然，为CAN 驱动，加上层层的封装，增加了很多冗余代码。不如直接访问底层驱动，多么简单！如果你经历过产品换了一个芯片平台，你就会认识到这个设计的意义所在。或者说，我们做的产品只有一个CAN 通道，不需要写这么复杂吧？为了适配这种更复杂的硬件平台，AUTOSAR确实增加了冗余代码，CanSM, CanIf, CanDrv这种模式，可作为今后实现外设状态管理的参考模式。