3. 流量调度模型差异（CBS vs Qbv）
好，咱们来聊聊TSN里最核心的一个话题——流量调度。工业场景和车载场景，虽然都叫TSN，但调度逻辑完全是两套思路。我最早接触车载TSN时，就踩过这个坑，以为工业那套CBS直接搬过去就行，结果发现根本跑不通。
为什么会这样？说白了，工业网络追求的是“公平”，车载网络追求的是“确定”。一个像公交车，大家排队上车；另一个像高铁，准时准点发车。咱们今天就把这两个模型掰开揉碎讲清楚。
3.1 工业CBS（Credit-Based Shaper）原理
CBS，全称Credit-Based Shaper，基于信用的整形器。我习惯叫它“积分调度”。
它的核心思想很简单：每个流都有一个“信用值”。发送数据时，信用值减少；等待时，信用值增加。信用值不能为负，也不能超过上限。说白了，就是谁攒的积分多，谁就先发。
关键参数：
- idleSlope：空闲时信用值增加的速度（单位：bits/s）
- sendSlope：发送时信用值减少的速度（单位：bits/s）
- hiCredit：信用值上限
- loCredit：信用值下限（通常为0）
我在一个工业视觉检测项目中遇到过这种情况：多台相机同时上传图像，如果不用CBS，带宽全被一台相机抢走，其他相机直接超时。用了CBS后，每台相机都能分到合理的带宽，虽然单台速度慢了，但整体系统稳定了。
CBS的数学模型是这样的：
// 信用值更新逻辑（简化版）
if (队列非空 && 信用值 >= 0) {
发送一个帧；
信用值 -= sendSlope * 帧长；
} else {
信用值 += idleSlope * 时间间隔；
信用值 = min(信用值, hiCredit);
}嗯，这里要注意：CBS只保证带宽分配，不保证延迟上限。你想想看，如果多个CBS流同时竞争，高优先级的流可能会让低优先级的流等很久。所以工业场景里，CBS通常配合优先级队列一起用。
避坑指南：我曾经把CBS的idleSlope设得太大，结果信用值涨得飞快，发送时又降不下来，导致网络抖动特别大。建议idleSlope和sendSlope的比例控制在1:2到1:4之间。
3.2 车载Qbv（Time-Aware Shaper）门控调度
车载场景就不一样了。你想想，自动驾驶的刹车指令，能等吗？不能。所以车载TSN用了另一种思路——Qbv，也叫时间感知整形器。
Qbv的核心是“门控列表”（Gate Control List，GCL）。每个队列前面有个门，门开才能发，门关就等着。门什么时候开？由GCL精确控制，精度能达到纳秒级。
我参与过一个ADAS项目，要求摄像头数据从采集到显示，延迟不能超过2毫秒。用CBS根本做不到，因为CBS的延迟是统计意义上的。但Qbv可以——只要把摄像头流的发送时间窗精确排好，延迟就是确定的。
GCL的配置示例：
// GCL配置（8个队列，周期100μs）
// 时间单位：纳秒
GCL = [
{ time: 0, gates: [1,0,0,0,0,0,0,0] }, // 队列0开门，发控制流
{ time: 20000, gates: [0,1,1,0,0,0,0,0] }, // 队列1和2开门，发传感器流
{ time: 50000, gates: [0,0,0,1,1,1,1,1] }, // 其他队列开门，发尽力而为流
{ time: 100000, gates: [1,0,0,0,0,0,0,0] }, // 周期结束，回到起点
];说白了，Qbv就是把时间切成片，每个时间片只允许特定类型的流量通过。这样做的好处是延迟完全确定，坏处是带宽利用率可能不高——如果某个时间片里没有数据，那段时间就浪费了。
注意：Qbv要求全网所有设备的时钟必须同步，误差不能超过1微秒。我曾经在测试时发现，两台交换机的时钟偏差了500纳秒，结果门控时间错位，数据全丢了。所以802.1AS（gPTP）时间同步是Qbv的前提，千万别忽略。
3.3 混合流量调度策略
现实中的网络，往往是工业流和车载流混在一起的。比如一个智能工厂里，既有工业控制流（需要CBS的公平性），又有车载AGV的导航流（需要Qbv的确定性）。怎么办？
我个人习惯的做法是：分层调度。
第一层：Qbv做时间隔离。先把时间切成大块，比如前30%的时间给车载流，后70%的时间给工业流。这样两类流量在时间上就不冲突了。
第二层：CBS做带宽分配。在工业流的时间片里，再用CBS给不同的工业流分配带宽。在车载流的时间片里，可以用优先级队列或者CBS进一步细分。
我做过一个混合调度的项目，配置大概是这样的：
| 时间片 | 时长 | 允许的流量 | 内部调度 |
|---|---|---|---|
| 时间片0 | 30μs | 车载控制流（Qbv） | 严格优先级 |
| 时间片1 | 50μs | 工业传感器流（CBS） | CBS + 优先级 |
| 时间片2 | 20μs | 尽力而为流 | 无调度 |
你想想看，这样做的好处是什么？车载流得到了确定的延迟，工业流得到了公平的带宽，两者互不干扰。当然，代价是配置复杂度上去了——你得同时懂Qbv和CBS，还得会调GCL和信用参数。
我的经验：混合调度时，建议先用仿真工具（比如OMNeT++或ns-3）跑一遍，看看有没有时间片重叠或者信用值溢出的情况。我曾经直接在硬件上调试，结果烧了一块交换机的FPGA配置，教训深刻。
最后总结一下：CBS适合带宽敏感、延迟不敏感的场景；Qbv适合延迟敏感、带宽可以牺牲的场景。混合调度时，用Qbv做宏观时间隔离，用CBS做微观带宽分配。嗯，这个思路基本能覆盖90%的工业与车载融合场景。