CAN总线负载为何一高就抖？调度怎么排？

平均负载看着还行，控制量却一到高峰就抖，这说明系统缺的不是名义带宽，而是最坏时刻的调度边界。CAN总线负载一高就发虚，往往是因为把平均值当成了实时保证。

总线负载率本身只是起点，不是结论。一个报文真正占掉的时间不只包括ID、数据和CRC，还要考虑位填充、仲裁等待、重发以及帧间隔。若预算只按理想位数估算，高优先级流一旦增多，实际占用会比表格上更快逼近上限。

周期帧的问题在于会扎堆。多个任务若被同一毫秒节拍唤醒，即便单条报文都不长，也可能在某个瞬间同时冲向总线，把延迟尖峰集中到固定相位上。系统表面看像“偶发抖动”，实则是调度节拍本来就在反复撞车。

事件帧则会把尖峰拉得更高。报警、状态变化、重发确认或网关转发只要在忙时段叠加进来，原本靠平均负载勉强过关的计划立刻就会失守。很多控制抖动不是长期过载造成，而是某类事件报文在错误时间里抢占了本就脆弱的周期窗口。

对CAN总线来说，调度优化首先要从端到端时延倒推，而不是从“还有多少空余带宽”正推。优先级、周期、数据长度和相位应共同规划：该错峰的错峰，该合并的合并，该下放到另一条链路的下放。只看单条报文“是否重要”，而不看它与别人同时出现的方式，调度通常越补越乱。

报文合并和信号打包虽然能省帧数，但也会引入新的代价。打包过重时，某个高频小信号会被迫等低频大帧一起发，反而抬高控制延迟；拆得过碎时，仲裁和帧头开销又把总负载抬上去。真正合适的粒度，应围绕刷新节拍和时延边界来定，而不是围绕软件模块边界来定。

验证时最好同时看平均负载和最坏窗口负载，再把关键报文的排队时间分布拉出来。只要关键帧在某些周期点总是延迟更大，就说明问题是调度相位而不是随机拥塞。把这类相位性抖动抓出来，往往比继续压缩几分之一个负载百分点更有效。

后续新增功能时，也不能只做“再塞一条报文是否还发得出”的判断，而应重算关键时序是否仍有余量。许多后装功能看似轻量，真正吃掉的却是原本留给抖动吸收的最后一点缓冲。

如果系统还跨网关转发，最好把网关缓存和任务调度一起纳入同一张时序图。因为总线上的抖动有时不是在本段产生，而是在上游挤压后成批落到这里。

对调度器来说，最值钱的不是把每一分带宽都塞满，而是始终留出能吸收异常流量的缓冲槽。没有这点缓冲，任何事件峰值都会直接转成控制抖动，而不是被系统平滑掉。

能跑满不等于能稳跑，调度预算里必须给最坏时刻留活口。关键帧的余量，本质上也是一种带宽资产。没有余量就没有稳定，更没有恢复空间，忙时更是如此，高峰一来就见真章。拖延会先出现，而且先乱。

所以，负载高并不必然出问题，但把平均负载当作实时性证明几乎一定会出问题。把周期、相位和最坏窗口一起排好，总线才不会一忙就抖。