对于车载控制器来说，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 任务中打来实锤。
如果是这种，从问题角度来看，就是降负载，或者调高任务或者中断的优先级。更深层次来看，就是系统设计有问题，导致基本的报文发送波动，需要从系统层面优化。
以上就是一些简单的经验梳理总结，有问题的地方大家可以在留言指正。
聊聊自动驾驶应用层软件开发
一文搞懂CAN收发器TJA1145
车载抬头显示系统(HUD)历史及发展
车身控制器功能规范
小鹏P7的热管理系统详解
大众ID4.X内部ECU技术细节整理
比亚迪海豹整车技术整理
揭秘理想的整车电子电气架构
国内主机整车EEA架构汇总
谈谈Bootloader自更新
谈谈对两家AUTOSAR工具看法
汽车软件需求是如何变成用户功能？
汽车E/E架构的网络安全分析
电子电气架构设计需要考虑哪些方面？
分享不易，恳请点个【👍】和【在看】
