#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?

发布于 2023-2-6 15:56
浏览
0收藏

01 什么是CAN Bus Off ?

1.1 什么是CAN 网络?

汽车车辆CAN网络由多个CAN网络组成,如动力CAN网络,信息娱乐CAN网络等。不同CAN网络之间的通信,通过网关(Gateway)转发。如信息娱乐CAN网络上需要的发动机相关的CAN信号,就需要网关从动力CAN网络上转发。


CAN总线网络是一个广播网络,每个节点(如下图中的ECU A)向总线请求发送CAN 数据帧,获得允许后开始发送;每个节点发送的CAN报文都在CAN网络传输,每个节点根据自身需求过滤接收到的报文,只处理需要接收的报文。

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区

1.2 Bus Off是什么?

Bus Off是CAN网络节点的一种故障状态,即CAN网络节点处于总线关闭状态,接收和发送功能都关闭了。


为什么?


为了保证CAN网络通信的稳定可靠性。


若某个节点持续的发生发送错误,或者接收错误,直接将该节点通信功能关闭,减少CAN网络上的错误帧,保护珍贵的信道资源。也就是从源头做起,减少CAN网络上错误帧,保证CAN网络中其他节点通信正常。


CAN网络上的节点分为三种状态,即主动错误,被动错误,总线关闭三种状态1。

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区


CAN网络节点状态


状态介绍接收功能发送功能

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区


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


CAN网络节点状态机变换


TEC: 发送计数器(芯片实现),发送失败,也就是CANoe trace 窗口上的Tx error , TEC+8;发送成功,TEC-83。


REC:接收计数器(芯片实现),接收失败,也就是CANoe trace 窗口上的Rx error4 ,REC减少;接收成功, REC增加。

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区


02 整车厂关于CAN BusOff的恢复策略需求是什么?

国内整车厂对于CAN Busoff 的测试较为严格,尤其是引进第三方测试团队之后,对需求的测试覆盖度很高。无论是项目管理,还是工程师(包括系统,软件),对此要有清晰的认识,避免在这个基本功能上犯错误。现将与CAN Bus Off相关的需求总结如下:


CAN Bus off恢复策略


1、快恢复(L1)


  • 恢复时间, <=100ms


  • 恢复次数,5~10次不等


2、慢恢复(L2)


  • 恢复间隔, [200ms, 1s]


  • 恢复次数, 不限


CAN Bus Off DTC 相关需求


1、成熟条件


  • 恢复N次不能成功之后,记录DTC,N的具体数值,各个OEM定义不同。


节点通信丢失类DTC 使能条件


Bus Off产生后,不再记录通信类DTC,原因显而易见,所有通信类DTC都会产生,记录没有意义,不能准确定位到是什么通信故障发生,有一个Bus off 的DTC就够了。

03 Autosar如何实现CAN BusOff恢复策略 ?

3.1 需求分析

根据文档5中需求分析,对CAN Bus Off恢复功能进行需求分解,主要划分给了CAN Driver, CAN Interface, CAN state Manager三个模块。

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区

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

需求追溯表

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区

根据参考文档6中描述, BUS OFF 事件会引起 CAN driver模块状态机变化,CAN Driver状态由 STARTED变为STOPPED,同时,通知CAN Interface模块发生BUS OFF事件。

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区


#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区

3.2.2 CAN Interface

需求追溯表

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区

3.2.3 CAN State manager

需求追溯表

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区

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标准文档。

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区

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. 1. CAN controller(外设,MCU芯片内部集成)检测到Bus Off事件发生后,向 CAN Driver模块报告事件

  2. 2. CAN Driver模块设置 CAN controller状态为STOPPED状态

  3. 3. CAN Driver执行完其相应职责,调用CanIf_ControllerBusOff()函数,向上层模块Can Interface 通知Bus Off事件

  4. 4. CAN Interface模块收到信息后,更改该controller状态,重置其发送报文序列

  5. 5. CAN Interface 执行完其相应职责后,调用函数CanSM_ControllerBusOff(), 向上层CAN State Manager模块,报告 Bus Off事件。

#百人创作先锋团#AUTOSAR如何实现CAN 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中的描述。

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区


  • 子状态机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.状态

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区


  • 子状态机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同时存在的原因。

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区

3.3.3 如何执行,控制CAN controller 状态

如下图中1处所示,为CanSM模块获取BUS OFF 事件发生后,请求设置CAN controller的执行流程。


下图中2处表示,Can controller状态恢复为STARTTED状态后,向CanSM模块报告状态的流程。

#百人创作先锋团#AUTOSAR如何实现CAN Bus Off恢复的功能?-汽车开发者社区

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

04 如何验证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的影响

05 后感

CanSM, CanIf, CanDrv模块中应用的设计原则


  • 单一职责


  • 对扩展打开,对修改关闭


应用到的设计模式:


封装,封装下层驱动接口,是上层隔离下层驱动的变化。切换MCU平台时,不影响上层逻辑。


通道负责通道的活,例如CanIf, CanDrv, 不涉及到BUS OFF逻辑处理,只负责为上层提供控制接口。


CanSM负责CAN controller的状态机逻辑控制。


标准之所以可以成为标准,在于其可以拥抱变化。也许你会说,这么写代码,得占用多少ROM啊?诚然,为CAN 驱动,加上层层的封装,增加了很多冗余代码。不如直接访问底层驱动,多么简单!如果你经历过产品换了一个芯片平台,你就会认识到这个设计的意义所在。


或者说,我们做的产品只有一个CAN 通道,不需要写这么复杂吧?为了适配这种更复杂的硬件平台,AUTOSAR确实增加了冗余代码,


CanSM, CanIf, CanDrv这种模式,可作为今后实现外设状态管理的参考模式。


文章转载自公众号:汽车电子与软件

分类
标签
收藏
回复
举报
回复
相关推荐