CAN周期波动优化方法

lidenghui

对于车载控制器来说，CAN周期的波动通常是有严格的标准，国标要求如下，基于国标，各个主机厂在这一块稍微有些差异，不过大部分要求是不超过10%，比如10ms的报文，周期波动范围是9~11ms。



▲图1 GBT 34658-2017中要求

那如果遇到报文周期偏大的问题该从何下手，或者说有哪些解决办法呢？

首先来梳理一下CAN报文的发送流程，CAN通信协议栈的整体架构如下图所示，包括应用层，交互层，网络层，数据链路层，物理层。



▲图2 CAN通信从应用层到硬件的流程(来源CSDN)

从各层的交互接口来看，报文接收polling接收方式的流程如下图所示。

Can_MainFunction_Read函数周期调用访问CanController（硬件）的寄存器，并读取这些寄存器的数据；数据读取结束后，继续调用CAN Interface模块的CanIf_RxIndication函数，将数据传给CanIf模块；CanIf再调用PduR模块的PduR_RxIndication函数，将数据传到PduR模块；PduR模块路由到COM模块，调用Com_RxIndication函数，将数据传到COM模块，COM模块将会把数据存入其缓存，供应用层软件读取使用。

如果是CAN报文的接收采用的是中断方式，数据则是在中断中接收，并调用 CanIf_RxIndication将数据向上传递。



▲图3 CAN报文接收流程

报文发送流程如下图所示。通过Com_ManfunctionTx将数据一层一层传递到CAN模块，并且通过Polling或者中断的形式将数据发送出去。



▲图4 CAN报文发送流程

上述基本梳理了一下CAN报文收发的流程，那下面就来分析一下总线报文周期波动过大问题的可能问题点。

第一种可能是同一节点发送报文很多，并且大部分报文周期都相同，这就导致同一时刻，大量报文需要发送，导致报文发送阻塞。如果是这种情况的话，可以在Com层对报文的发送增加offset，offset一般是Com周期的倍速，这里可以适当地调低Com Mainfunction的周期。

第二种可能就是需要检查Canif和CAN是否大量报文发送仅使用一个发送缓冲区，并且采用FIFO的方式进出，这样就会出现报文周期波动，其影响的原因是，假如大CANID的报文在前，小CANID的报文在后，大ID由于总线仲裁，无法发送，会导致小CANID的无法发送，从现象来看就是报文优先就翻转。



▲图4 内部优先级翻转

这里还可以从总线log来分析，查看小CANID周期间隔点，发送的报文是哪些，如果那会儿大ID在发，那就有可能是这种原因。

第三种有可能系统负载的原因，比如系统负载过高，导致Com_MainFuncionTx的调度发生波动，导致总线上报文周期波动，或者是以中断的模式发送，中断优先级过低，导致被其他高优先级的中断打断，导致报文无法发送，这里可以通过打时间戳的形式来确认，在任务中打时间搓或者是在idle 任务中打来实锤。

如果是这种，从问题角度来看，就是降负载，或者调高任务或者中断的优先级。更深层次来看，就是系统设计有问题，导致基本的报文发送波动，需要从系统层面优化。

以上就是一些简单的经验梳理总结，有问题的地方大家可以在留言指正。

t007

针对CAN报文周期波动偏大问题，首先需深入分析各层级交互过程中的潜在瓶颈。在应用层，需检查报文数据处理逻辑和计算复杂度，优化算法以减少处理延迟。在交互层和网络层，关注报文传输路径上的瓶颈和冲突，优化调度策略以减少延迟。数据链路层和物理层方面，关注硬件性能和网络环境对报文传输的影响。此外，建议对CAN通信协议栈进行全面测试，识别瓶颈环节并针对性优化。具体方法包括优化算法、调整硬件资源配置、改善网络环境等。最终目标是确保报文周期波动满足国标要求，保障车载控制器通信的实时性和稳定性。

针对CAN报文周期波动的问题，优化方法可以从以下几个方面入手：

首先，从应用层开始，优化数据处理和发送逻辑，减少数据处理的复杂性，提高处理效率，从而减少报文发送的延迟。其次，在交互层和网络层，优化报文传输策略，如优先级分配和流量控制，确保关键报文能够优先传输。此外，对于数据链路层和物理层，应关注硬件性能和通信质量的优化，确保信号的稳定和准确传输。若遇到报文周期偏大的问题，可以通过调整发送频率、优化网络拓扑结构、升级硬件性能等方法来解决。同时，建议参考GBT 34658-2017等相关标准，确保改进措施符合国标要求。通过这些方法可以有效减少CAN周期波动，提高车载控制器的工作效率和稳定性。