AUTOSAR架构下CAN BusOff问题分析

汽车安全 3年前 (2021) admin
1,588 1 0


前言

CanSM模块的概念详解和模块配置文章中已经对BusOff处理机制有了详细描述,最近实际项目中领到了一个BusOffBug,解决Bug的过程没多大阻碍,不过,借助这个机会,深入分析一下Can网络的BusOff产生及处理机制。本文将从以下几个方面进行分析。

AUTOSAR 通信服务-CanSM概念详解

AUTOSAR 通信服务-CanSM配置及代码分析

AUTOSAR架构下CAN BusOff问题分析

正文

1. 问题描述

测试问题:BusOff时间达到了191ms,也就是没有快恢复策略。

AUTOSAR架构下CAN BusOff问题分析

2. 复现问题

制造BusOf的方法:(1CAN_H, CAN_L短接;(2CAN_H或者CAN_L短接地;(3)工具,CAN DisturbanceVECTOR VH6501)干扰这里使用方法3.

 

搭建测试环境

控制器(ECU):热管理控制器TMC

仿真器器(IC5000):提供仿真环境,实时改代码编译调试

VN1630A:提供硬件lisence

VH6501: 物理层干扰控制器报文,触发BusOff

上位机CANOe 14.0:观测错误帧,及通过错误帧估算恢复时间

AUTOSAR架构下CAN BusOff问题分析

AUTOSAR架构下CAN BusOff问题分析

实测:Can BusOff后尝试恢复时间为192ms左右,现象上看是没有快恢复策略。

 

3. 查看CanSM模块配置

快恢复配置次数为3次,快恢复时间为30ms,慢恢复时间为200msBusOff Check时间(超时认为BusOff)为400ms. 配置是没有问题的。

AUTOSAR架构下CAN BusOff问题分析


4. 查看配置生成代码

四个重要的配置项(快恢复时间,快恢复次数,慢恢复时间,BusOff检测超时时间)都是不对的

AUTOSAR架构下CAN BusOff问题分析

原因:低级错误,没有把BSW生成的代码拷贝到项目的工程目录下。

 

5. 修改验证

快恢复时间:30ms

快恢复次数:3

慢恢复时间:200ms

BusOff检测超时时间:400ms

AUTOSAR架构下CAN BusOff问题分析


AUTOSAR架构下CAN BusOff问题分析

第一次BusOff恢复时间为94ms左右,第二次恢复时间为92ms左右,第三次恢复时间为93ms左右,第四次恢复时间为290ms左右.

 

问题:现象上看,3次快恢复然后进入慢恢复,但是快恢复时间(92ms左右)及慢恢复时间(290ms左右)和我们配置的参数(30ms, 200ms)差距很大,还是有问题吗?

:是没有问题的,BusOff快恢复还是慢恢复时间描述的是CAN控制器进入到BusOff状态后尝试恢复到正常状态的时间,但是我们使用了CAN报文的错误帧外发周期来衡量BusOff时间的,然而我们的报文外发周期是100ms的,也就是说BusOff快恢复时间到后(允许外发报文)到开始发生报文其实是有0-100ms的时间可能的,也就是说,这种测试方式只要保证快恢复时间100ms + 30ms = 130ms以内且慢恢复时间在100ms + 200ms = 300ms以内就算正常的了。

 

结论:使用正常的配置参数后,BusOff恢复策略达到要求

 

到这里就结束了吗? 请看下面的BusOff深入分析。


6. BusOff处理深入分析

BusOff状态机详细分析请参考本公众号的AUTOSAR 通信服务-CanSM概念详解一文。这里提出以下四个问题进行深入分析。

AUTOSAR架构下CAN BusOff问题分析


问题1. 发生BusOff事件后什么时间点将Can Controller设置为STOP模式?

AUTOSAR架构下CAN BusOff问题分析

AUTOSAR架构下CAN BusOff问题分析

AUTOSAR架构下CAN BusOff问题分析

答:发生BusOff事件后在BusOff的中断处理函数中将Can Controller设置为STOP模式。

 

问题2. 发生BusOff事件后什么时间点在哪个模块停止往CanDrve外发报文?

AUTOSAR架构下CAN BusOff问题分析

AUTOSAR架构下CAN BusOff问题分析

AUTOSAR架构下CAN BusOff问题分析

答:发生BusOff事件后在CanIf的回调函数CanIf_ControllerBusOff中停止往CanDrve外发报文,同时通知到CanSM模块发送BusOff事件。也对应图中的T_BUS_OFF

 

问题3. BusOff进入恢复阶段后什么时间点将Can Controller设置为START模式?

AUTOSAR架构下CAN BusOff问题分析

AUTOSAR架构下CAN BusOff问题分析

AUTOSAR架构下CAN BusOff问题分析

AUTOSAR架构下CAN BusOff问题分析


答:BusOff进入恢复阶段后进入S_RESART_CC子状态后立马将Can Controller设置为START模式。也对应图中的E_BUS_OFF

 

问题4. BusOff进入恢复阶段后什么时间点在哪个模块开始往CanDriver外发报文?

AUTOSAR架构下CAN BusOff问题分析

AUTOSAR架构下CAN BusOff问题分析

AUTOSAR架构下CAN BusOff问题分析


答:BusOff进入恢复阶段后如果快恢复次数小于等于配置次数且快恢复时间大于配置时间或者快恢复次数大于配置次数且慢恢复时间大于配置后开始往CanDriver外发报文。也对应图中的G_TX_ON


小结:CAN BusOff的恢复时间对应状态机中发生T_Bus_OFF事件后从S_BUS_OFF_CHECK状态机器切换到S_RESTART_CC状态机时刻到最后从S_TX_OFF状态机满足G_TX_ON条件切换到S_BUS_OFF_CHECK状态机时刻之间的时间


7.总结

1) CAN Controller检测到Bus Off事件发生后,通过中断向CAN Driver模块报告事件。

2) CAN Driver模块设置CAN Controller状态为STOPPED状态。

3) CAN Driver调用CanIf_ControllerBusOff()函数向上层模块CanIf通知BusOff事件。

4) CAN Interface模块收到信息后,更改Controller状态,设置所有PduModeOFFLINE

5) CAN Interface调用CanSM_ControllerBusOff()向上层CanSM模块报告Bus Off事件。

6) CanSM模块进行BusOff事件处理。

 

AUTOSAR架构下CAN BusOff问题分析


推荐阅读

Autosar架构下的模块详细设计及代码实现–基于配置的编程方法

AUTOSAR 通信服务-CanSM概念详解

AUTOSAR BswM(3)代码分析

AUTOSAR 通信服务-ComM配置及代码分析

AUTOSAR 通信服务-PDU Router

AUTOSAR CAN通信协议栈分析(2)-CanIf

Can通信协议栈分析(1)-Can Driver

Lin通信协议栈分析(2)-LIN Driver

C语言编程技巧(1)-表驱动法

CANoe工具使用(1)-实现CAN通道的收、发、录、回放报文

S32K平台学习(1)-S32K144启动流程分析


End




欢迎点赞,关注,转发,在看,您的每一次鼓励,都是我最大的动力!

汽车电子嵌入式

微信扫描二维码,关注我的公众号


原文始发于微信公众号(汽车电子嵌入式):AUTOSAR架构下CAN BusOff问题分析

版权声明:admin 发表于 2021年11月24日 下午11:30。
转载请注明:AUTOSAR架构下CAN BusOff问题分析 | CTF导航

相关文章

1 条评论

您必须登录才能参与评论!
立即登录
  • lv
    lv 游客

    我也有快恢复的时间比配置的时间要长的情况。但是出于验证的想法,我把一帧报文改成了1ms周期的,快恢复配的10ms,测试下来发现快恢复的时间在14ms-18ms之间变化。(L1->L2的次数是32次)