解决什么问题
TSN 项目最早的错误，常常不是配置错，而是需求没有说清楚。应用说“要稳定”“要实时”“不要丢”，这些词对网络来说还不够。你必须继续追问：周期是多少，最大帧长是多少，deadline 是多少，允许多少抖动，能否接受偶发丢包，要覆盖哪类故障，测试要留下什么证据。
如果需求没有被翻译成边界，后续机制选择就会变成猜测。有人会一上来就用 Qbv，有人会只加优先级，有人会复制两条路径，但这些动作是否必要、是否足够，都没有依据。
背景与直觉
把 TSN 需求想成医生问诊。病人说“我不舒服”不是诊断，必须继续问部位、频率、诱因和指标。网络需求也是一样，“实时”只是入口，真正能指导设计的是可计算和可验证的条件。
一条关键流至少要说清这些字段：talker 和 listener 是谁，周期和最大帧长是多少，deadline 从哪里开始算，抖动会影响什么控制效果，背景流量是什么，故障下是否要继续工作。
怎么解决
可以用一张需求翻译表作为起点。
| 业务说法 | 网络要追问 | 可能影响的机制 |
|---|---|---|
| 要实时 | deadline、周期、最大帧长 | Qbv、gPTP、guard band |
| 要稳定 | 抖动范围、尾延迟、背景压力 | CBS、Qbv、队列映射 |
| 不能中断 | 故障模型、恢复时间、路径独立性 | FRER、Qcc、验证 |
| 流很多 | 流数量、路径、资源冲突 | Qcc、调度算法 |
| 要证明 | 时间戳精度、样本量、故障注入 | 验证计划 |
需求翻译完成后，再去选择机制。比如周期很宽松但突发明显，CBS 可能先解决主要问题；deadline 很硬且多跳路径稳定，Qbv 才有必要进入；单链路故障不能中断，FRER 才成为设计项。
带来了什么新问题
需求写清楚以后，项目会暴露更多约束。业务可能发现原本的 deadline 过于激进，设备可能不支持需要的队列数量，网络可能没有足够独立的路径，测试工具可能没有足够精度。这不是坏事，越早暴露越容易修正。
另一个新问题是需求会变化。TSN 配置不是一次性文档，流量规格、拓扑、设备版本和业务周期变化后，原来的边界可能要重新证明。
检查点
- 把“这条控制流要稳定”改写成至少 5 个可测试字段。
- 如果一个需求只给平均带宽，不给最大帧长和周期，后续调度会缺少什么依据？