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

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

《AUTOSAR如何实现CANBusOff恢复的功能.docx》由会员分享，可在线阅读，更多相关《AUTOSAR如何实现CANBusOff恢复的功能.docx（21页珍藏版）》请在冰点文库上搜索。

AUTOSAR如何实现CANBusOff恢复的功能

AUTOSAR如何实现CANBusOff恢复的功能

什么是CANBusOff?

1.1什么是CAN网络？

汽车车辆CAN网络由多个CAN网络组成，如动力CAN网络，信息娱乐CAN网络等。

不同CAN网络之间的通信，通过网关（Gateway）转发。

如信息娱乐CAN网络上需要的发动机相关的CAN信号，就需要网关从动力CAN网络上转发。

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的恢复策略需求是什么？

国内整车厂对于CANBusoff的测试较为严格，尤其是引进第三方测试团队之后，对需求的测试覆盖度很高。

无论是项目管理，还是工程师（包括系统，软件），对此要有清晰的认识，避免在这个基本功能上犯错误。

现将与CANBusOff相关的需求总结如下：

CANBusoff恢复策略

1、快恢复（L1）

∙恢复时间,<=100ms

∙恢复次数，5~10次不等

2、慢恢复（L2）

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

∙恢复次数,不限

CANBusOffDTC相关需求

1、成熟条件

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

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

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

Autosar如何实现CANBusOff恢复策略?

3.1需求分析

根据文档5中需求分析，对CANBusOff恢复功能进行需求分解，主要划分给了CANDriver,CANInterface,CANstateManager三个模块。

CANDriver要做什么？

该模块负责实现供一个报告CANBusoff状态的接口[SRS_Can_01055],但不能自动恢复[SRS_Can_01060]

CANInterface要做什么？

该模块需要实现向上层报告CANBusOff状态的接口[SRS_CAN_01029]

CANStateManager要做什么？

TheCanSmmoduleisresponsibleformodecontrolmanagementofallsupportedCANControllersandCANTransceivers.

该模块需要实现为每一个CAN控制器实现CANBusOff恢复算法[SRS_Can_01146]

该模块需要支持CANBusOff恢复时间配置[SRS_Can_01143]

该模块需要提供一个接口，以在上电初始化时，支持通信模式配置（Nocommunication，orsilentcommunication）[SRS_Can_01144]

3.2.静态设计

下面根据文章，介绍下CANDriver，CANInterface，CANStateManager三个模块的静态设计，主要内容有需求追溯表，本模块关于BusOff的需求定义，以及接口定义。

3.2.1CANDriver

需求追溯表

根据参考文档6中描述，BUSOFF事件会引起CANdriver模块状态机变化，CANDriver状态由STARTED变为STOPPED，同时，通知CANInterface模块发生BUSOFF事件。

3.2.2CANInterface

需求追溯表

3.2.3CANStatemanager

需求追溯表

3.2.4接口

CANDriver，CANInterface，CANStateManager三个模块中与BusOff恢复相关接口定义如下图所示，各模块内部为其所实现的接口，各模块之间的连接线，代表模块间的依赖关系。

如ComM模块和CanStateManager模块之间的依赖关系，表示CanStateManager模块要使用ComM模块实现的ComM_BusSM_ModeIndication接口，该接口由ComM模块负责实现。

其他模块之间的依赖关系同此方式，连线圆圈端表示接口提供端，另一端为调用方。

各个函数接口的参数，返回值，或其他特性在此不再赘述，具体可参考三个模块的AUTOSAR标准文档。

其中，CANStateManager模块使用到ComM，BswM,Dem三个模块的函数的具体定义，可参考其相应AUTOSAR标准文档。

3.3动态设计

CAN网络节点发生BusOff事件后，AUTOSAR标准中BusOff恢复策略分为以下三步：

Step1.CANBusOff事件上报。

Step2.执行CANBusOff事件恢复策略。

Step3.根据策略，执行相应动作。

各步骤具体介绍见以下章节介绍。

3.3.1CANBusoff发生后，怎么办？

外设CANcontroller发生BusOff事件怎么办？

这个可是最严重的事件，代表这个CAN网络节点掉线了，不能发送消息，也不能接收消息。

你在这个圈里失联了，让你干的事，你干不了了；让你收集的有用信息，其他节点也获取不到了。

彻底失联！

掉线了，这怎么办？

假如你在实际工作中，遇到这种紧急问题，咋办？

我的第一反应是，赶紧告诉领导！

对，在AUTOSAR标准中，也是这么设计的。

看看下面这这几个模块是怎么层层上报的。

当然，每个模块也是先要做好自己的事情，然后再上报。

要不然，会挨批的。

1.CANcontroller（外设，MCU芯片内部集成）检测到BusOff事件发生后，向CANDriver模块报告事件

2.CANDriver模块设置CANcontroller状态为STOPPED状态

3.CANDriver执行完其相应职责，调用CanIf_ControllerBusOff（）函数，向上层模块CanInterface通知BusOff事件

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

5.CANInterface执行完其相应职责后，调用函数CanSM_ControllerBusOff（）,向上层CANStateManager模块，报告BusOff事件。

3.3.2检测到BusOff后，如何处理？

AUTOSAR标准（V4.3.1）中，定义CANStatemanager模块负责实现CANBusOff恢复的策略。

如下图所示，图中内容为CanStateManager模块实现的状态机CANSM_BSM，控制某个CANcontroller通信的状态。

CANSM_BSM状态机中，CANSM_BSM_S_FULLCOM，CANSM_BSM_S_SILENTCOM，这两个状态与BusOff事件相关。

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中的描述。

∙子状态机CANSM_BSM_S_FULLCOM

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

根据参考文档7中需求[SWS_CanSM_00508][SWS_CanSM_00521][SWS_CanSM_00522]中描述，CANStateManager获取到发生BusOff信息后，需要向BswM,ComM模块报告自己当前状态变化，并设置BusOff相关的DTC为DEM_EVENT_STATUS_PRE_FAILED状态。

完成上述操作后，进入S_RESTART_CC状态。

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

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

根据参考文档7中[SWS_CanSM_00515]需求描述，若CanSMEnableBusOffDelay参数为FALSE，上一次BUSOFF事件发生后，若BUSOFF恢复不成功次数大于，或者等于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成立条件，需要额外加上有回调函数制定的时间；

**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_00496]中描述，当配置参数CanSMBorTxConfirmationPolling[ECUC_CanSM_00339]为假时，需要等待配置参数CanSMBorTimeTxEnsured[ECUC_CanSM_00130]定义时间，以确保BusOFF恢复。

或者，以需求[SWS_CanSM_00497]中描述，当配置参数CanSMBorTxConfirmationPolling[ECUC_CanSM_00339]为真时，需要APICanIf_GetTxConfirmationState（ref.to chapter8.5.1）返回状态CANIF_TX_RX_NOTIFICATION。

G_BUS_OFF_PASSIVE成立后，执行E_BUS_OFF_PASSIVE，也就是按[SWS_CanSM_00498]需求中定义，调用Dem_SetEventStatus（）设置BUSOFF相关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模块通告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

根据参考文档7[SWS_CanSM_00602]需求描述，子状态机若在定时器CANSM_MODEREQ_REPEAT_TIME[referto]时间内，未收到所有CANcontroller的modeindication，视为请求超时，触发器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表示，设置所有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还需要干什么？

按照客户关于BUSOFF快恢复，慢恢复的时间，次数要求，配置以下参数值：

∙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）. 

∙还需要指定BUSOFF引用的DTC

如何验证CANBusOff恢复功能？

4.1如何制造BusOff

∙工具，CANdisturbance（VECTORVH6501）,可参考3

∙CAN_H,CAN_L短接

∙CAN_H，或者CAN_L短接地

∙如何观察CANBusOff现象

4.2测试用例开发关注点

∙L1（快）恢复

恢复时间

恢复次数

∙L2（慢）恢复

恢复时间

∙BusOffDTC

∙对其他通信丢失类DTC的影响

后感

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

∙单一职责

∙对扩展打开，对修改关闭

应用到的设计模式：

封装，封装下层驱动接口，是上层隔离下层驱动的变化。

切换MCU平台时，不影响上层逻辑。

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

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

标准之所以可以成为标准，在于其可以拥抱变化。

也许你会说，这么写代码，得占用多少ROM啊？

诚然，为CAN驱动，加上层层的封装，增加了很多冗余代码。

不如直接访问底层驱动，多么简单！

如果你经历过产品换了一个芯片平台，你就会认识到这个设计的意义所在。

或者说，我们做的产品只有一个CAN通道，不需要写这么复杂吧？

为了适配这种更复杂的硬件平台，AUTOSAR确实增加了冗余代码，

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