解决什么问题
TSN 最终要落到证据。配置界面显示启用 Qbv，不等于关键帧真的按窗口通过；一次 ping 成功，不等于延迟边界成立；抓到一帧准时，不等于高负载下仍然准时。可观测性计划解决的是“如何证明”。
它要求你把测试当成工程实验，而不是演示。实验必须说明输入、变量、测量方法和结论边界。没有这些材料，别人无法判断你的结果是稳定边界，还是一次偶然成功。
背景与直觉
普通网络测试常问“能不能通、吞吐多少、平均延迟多少”。TSN 测试要继续追问：最坏延迟是多少，抖动范围是多少，关键帧是否命中窗口，背景流量如何施加，时间戳精度够不够，故障时哪条路径接管，重复帧是否被正确消除。
把验证报告想成一条证据链。拓扑和配置说明实验条件；流量模型说明输入；抓包、时间戳和计数器说明网络实际行为；统计和故障注入说明边界。链条中任何一段断掉，结论都会变弱。
怎么解决
一份基础验证计划可以按八块组织。
| 模块 | 需要记录什么 | 它支持什么结论 |
|---|---|---|
| 拓扑 | 节点、端口、链路速率、路径、故障域 | 结果适用于哪条网络 |
| 设备能力 | 型号、固件、TSN 功能、队列数量 | 机制是否真的被支持 |
| 流量模型 | 周期、最大帧长、deadline、优先级、路径 | 输入是否符合设计假设 |
| 配置快照 | gPTP、GCL、CBS、抢占、FRER、Qcc 输出 | 设备是否按计划配置 |
| 背景压力 | 流量类型、突发模式、负载比例、持续时间 | 是否覆盖竞争场景 |
| 测量方法 | 抓包点、硬件/软件时间戳、时钟源、精度 | 延迟和抖动是否可信 |
| 统计结果 | 最大值、分位数、deadline miss、丢包、重复消除 | 边界是否成立 |
| 故障注入 | 断链、端口 down、设备重启、恢复过程 | 故障下是否连续 |
这八块不一定每次都写成长报告，但每块都应该有答案。尤其是测量方法要写清楚。硬件时间戳和软件时间戳的可信度不同；镜像端口可能丢包；抓包机的时钟可能和 DUT 不同；测试工具本身可能成为瓶颈。
一个最小验证场景
假设你要验证一条 1 ms 周期、deadline 300 us 的控制流，路径经过 3 台交换机，使用 gPTP + Qbv + FRER。
第一步固定输入：记录 talker/listener、路径、最大帧长、周期、deadline、背景流量模型和设备版本。
第二步固定配置：导出或截图 gPTP 状态、GCL、队列映射、FRER 序列恢复状态和 Qcc 生成的路径配置。
第三步运行轻载测试：确认关键流在无背景压力下稳定到达，并记录 baseline 延迟分布。
第四步运行重载测试：施加背景突发流量，观察关键帧最大延迟、分位数、miss count 和窗口命中情况。
第五步故障注入：断开主路径一条链路，检查备用副本是否继续到达，恢复后是否出现重复交付或乱序误判。
第六步写边界：说明样本数量、持续时间、测量精度、最大观测延迟、是否观察到 miss、哪些故障被覆盖、哪些故障没有覆盖。
带来了什么新问题
验证本身会引入误差。抓包点越远，越难判断某一跳发生了什么；软件时间戳可能被系统调度抖动污染；镜像端口可能在高负载下丢包；背景流量生成器可能达不到声明速率；测试时间太短会漏掉尾部情况。
另一个问题是结论边界。你测试了 1 条关键流，不代表 100 条都可行；测试了某个固件版本，不代表升级后仍然一致；测试了单链路断开，不代表供电或线束级共因故障被覆盖。验证报告必须把这些边界写出来。
检查点
- 如果一份报告只给“平均延迟 80 us”，你还需要哪些指标才能判断 deadline 是否可靠？
- 为什么镜像口抓包和硬件时间戳的证据强度不同？
- 设计一个 FRER 故障注入测试：你会断开哪里，采集什么，怎样判断重复消除是否正确？