2、Schedule Table核心概念
各位好，我是老周。今天咱们聊聊调度表最核心的几个概念。说实话，我刚接触LIN总线那会儿，也被这些术语绕得头晕。但搞清楚了，你会发现调度表其实就是一张“时间表”——告诉总线什么时候该干什么事。
2.1 什么是Schedule Table
调度表，英文叫Schedule Table。说白了，它是一张预定义好的“消息发送时刻表”。这张表里按顺序列出了：
- 哪个帧（Frame ID）要发送
- 什么时间（相对于调度表起点）发送
- 帧的类型（无条件帧、事件触发帧、偶发帧等）
我习惯把调度表想象成公交车的时刻表。公交车不会乱开，它按站牌上的时间到站。LIN总线也一样——主节点按调度表的时间点，挨个把帧发出去。
一句话总结：调度表 = 主节点发送报文的“剧本”。剧本怎么写，总线就怎么演。
2.2 Schedule Table的作用
调度表到底有什么用？我归纳了三点：
| 作用 | 说明 | 我踩过的坑 |
|---|---|---|
| 确定总线时序 | 每个帧的发送时刻是确定的，不会乱 | 曾经有个项目，调度表没算好时间，导致两个帧间隔太短，从节点来不及响应 |
| 保证实时性 | 关键信号（如刹车、转向）可以放在高优先级位置 | —— |
| 降低总线负载 | 不需要的帧不发，节省带宽 | —— |
你想想看，如果没有调度表，主节点想发什么就发什么，那从节点根本不知道什么时候该响应。整个总线就乱套了。
2.3 调度表与总线状态机的关系
这里有个关键点：调度表不是独立存在的。它和LIN总线的状态机紧密绑定。
LIN总线的状态机，我画个图你就明白了：
嗯，这里要注意：调度表只在运行态执行。其他三个状态——空闲、睡眠、唤醒——调度表是不工作的。
我记得有个项目，调试时发现总线一直没反应。查了半天，原来是主节点在睡眠态没出来。后来加了唤醒逻辑才搞定。所以，调度表能不能跑起来，先看状态机对不对。
2.4 调度表的执行机制
调度表怎么执行的？我拆成几步来讲：
- 主节点读取调度表——从当前表项开始
- 发送帧头——主节点发出同步间隔、同步字节、PID
- 等待响应——从节点回复数据（如果是无条件帧）
- 检查时间——看当前表项的时间槽是否用完
- 切换到下一表项——继续执行，直到表尾
- 循环或停止——如果是循环调度表，回到表头重新开始
每个表项都有一个时间槽（Slot Time）。这个时间槽决定了：从帧头发送到帧响应结束，最多能用多长时间。
小技巧：时间槽不能设得太紧。我一般留10%~20%的余量。比如理论上需要5ms，我就设6ms。这样即使从节点有点延迟，也不会超时。
来看一个实际的调度表例子：
// 调度表定义示例
ScheduleTable MainSchedule {
// 帧ID 时间槽(ms) 帧类型
Frame 0x01, 10, 无条件帧 // 方向盘角度
Frame 0x02, 10, 无条件帧 // 车速信号
Frame 0x03, 20, 无条件帧 // 发动机转速
Frame 0x04, 10, 无条件帧 // 制动状态
Frame 0x05, 10, 无条件帧 // 灯光控制
// 总周期 = 60ms
}这个调度表总周期60ms。主节点每10ms发一个帧，5个帧发完，一轮结束。如果设成循环模式，就从头再来。
注意：调度表的总周期不能超过应用层要求的最大响应时间。比如某个信号要求50ms内更新一次，那你的调度表周期就不能超过50ms。否则，信号就过时了。
我曾经遇到过一个案例：车身控制模块的灯光信号，调度表周期设了100ms。结果驾驶员按了转向灯，要等100ms灯才亮。客户投诉说“反应太慢”。后来我把灯光帧放到调度表前面，周期压到20ms，问题就解决了。
所以，调度表的执行机制，核心就是时间槽 + 帧顺序。时间槽保证每个帧有足够时间发送，帧顺序保证关键信号优先。
2.5 调度表的类型
调度表不是只有一种。我常用的有三种：
| 类型 | 特点 | 适用场景 |
|---|---|---|
| 循环调度表 | 执行完最后一帧，自动回到第一帧 | 周期性信号（车速、转速等） |
| 单次调度表 | 执行完就停，不再重复 | 诊断请求、配置写入 |
| 条件调度表 | 满足某个条件才执行 | 故障模式、特殊工况 |
我个人习惯：正常运行时用循环调度表，诊断或配置时用单次调度表。条件调度表用得少，但遇到复杂项目时很管用——比如检测到碰撞后，切换到“碰撞后调度表”，只发安全气囊和门锁信号。
好了，调度表的核心概念就这些。记住：调度表是LIN总线的“指挥棒”，状态机是“舞台”，两者配合好，总线才能演好这场戏。