简介：这份资源面向时间敏感网络（TSN）方向的研究生、工业网络工程师与仿真爱好者，提供基于TSNkit与OMNeT++的调度与仿真完整工程，帮助读者在离散事件仿真环境中搭建确定性网络场景、验证调度算法并分析时延与抖动表现。压缩包共约2000个文件，整体83.24MB，以1448个C++头文件、208个XML配置、58个Python脚本为主，辅以txt说明、prefs与ini参数文件、sh与bat运行脚本及md文档，覆盖源码、示例配置与仿真脚本等模块。已有403人学习下载。读者可据此理解时间同步、流量整形与IEEE 802.1Qbv优先级调度机制，参考EDF、WEDF等调度策略的实现方式，并借助Python接口完成控制脚本编写与结果后处理，从而掌握TSN网络建模、拓扑配置与性能评估的完整流程。
1. 从一次车载以太网调度翻车说起：TSNkit 和 OMNeT 到底能帮你做什么
车载以太网项目里，最让人头疼的不是物理链路通不通，而是几个优先级不同的流量挤在同一条链路上时，谁先走、谁等多久、端到端抖动能不能压住。我最早做 TSN 时间感知调度（IEEE 802.1Qbv）验证时，直接在交换机上配门控列表，结果一上量就翻车：视频流偶尔卡顿，控制报文时延抖动超过 200 微秒，抓包看门控窗口对不齐，根本不知道是调度算法算错了还是配置写错了。后来才把流程倒过来——先在仿真里把调度表跑通，再下发到真实交换芯片。TSNkit 和 OMNeT++ 就是干这个的组合：TSNkit 负责把流量、拓扑、调度约束建模成可求解的问题，OMNeT++ 负责把求解出来的门控列表放回离散事件仿真里跑，看端到端时延、队列积压和丢包到底长什么样。这套流程适合两类人：一类是做 TSN 交换芯片或端设备固件、需要验证门控调度可行性的工程师；另一类是在做车载、工业控制网络架构、要在部署前评估调度方案能不能满足确定性时延指标的从业者。它不解决“怎么配交换机”这种现场问题，但能让你在写第一行配置之前，就知道这套调度表在数学上是否可行、在仿真里是否稳定。下面按“建模—求解—仿真—排错”的顺序，把这条链路拆开讲清楚。
2. TSNkit 与 OMNeT++ 的分工：谁算调度表，谁跑时间线
2.1 为什么不能只靠 OMNeT++ 做 TSN 调度验证
OMNeT++ 本身是一个离散事件仿真框架，它擅长的是“给定一组事件和延迟，推演系统状态随时间的变化”。但 TSN 调度表不是仿真器能自己算出来的——它需要求解一个带约束的优化问题：每个队列的门控窗口在什么时间开、开多久，才能保证高优先级流量的截止时间不被低优先级流量破坏，同时又不让低优先级流量饿死。这个问题在流量规模稍大时就是 NP 难的，OMNeT++ 没有内置求解器，你只能手写门控列表去试，试错成本极高。
TSNkit 的定位正好补上这一环。它把网络拓扑、流量周期、帧长、截止时间、优先级这些输入整理成约束，调用求解器（常见做法是接 Gurobi 或 CPLEX，也有用启发式算法的版本）算出每个出端口每个队列的门控开闭时间。算完之后，TSNkit 可以导出成 OMNeT++ 能读的调度表格式，或者导出成 CSV 让你自己写解析代码。所以分工很明确：TSNkit 是“算”的，OMNeT++ 是“跑”的。你如果只想要一个大概的时延分布，可以只用 OMNeT++ 配固定门控；但要做调度可行性验证，两个都得用。
2.2 最小工作流：从拓扑描述到门控列表导出
我一般会按下面这个顺序搭第一版验证环境，不追求一次跑通大网络，先用一个交换机加两个终端把链路走通。
第一步，准备拓扑和流量描述文件。TSNkit 常见做法是读 JSON 或 CSV，里面写清楚节点数、链路速率、每条流的源、目的、周期、帧长、优先级、截止时间。下面是一个两节点一条流的例子：
{ "topology": { "nodes": ["ES1", "SW1", "ES2"], "links": [ {"src": "ES1", "dst": "SW1", "rate_mbps": 1000}, {"src": "SW1", "dst": "ES2", "rate_mbps": 1000} ] }, "flows": [ { "id": "f1", "src": "ES1", "dst": "ES2", "period_us": 1000, "frame_size_bytes": 500, "priority": 7, "deadline_us": 500 } ] }这段 JSON 里，period_us是流量周期，frame_size_bytes决定传输时间，priority对应 TSN 的优先级队列，deadline_us是端到端截止时间。TSNkit 求解时会检查在 1 毫秒周期内，500 字节的帧在 1 Gbps 链路上传输需要 4 微秒，加上交换机转发延迟，能不能在 500 微秒内到达。如果 deadline 设成 3 微秒，求解器会直接报不可行，这就是它比手配门控强的地方——先告诉你有没有解。
第二步，调用 TSNkit 的求解入口。不同版本接口不一样，常见做法是命令行传参或 Python 脚本调用。下面是一个 Python 调用的示意：
from tsnkit import ScheduleSolver solver = ScheduleSolver( topology_file="topo.json", flow_file="flows.json", solver="gurobi", time_limit_s=60, slot_granularity_us=1 ) result = solver.solve() if result.feasible: result.export_gcl("gcl_output.csv") else: print("不可行，冲突流:", result.conflicts)这里slot_granularity_us是门控时间片的粒度，设成 1 微秒意味着调度表的时间精度是 1 微秒。粒度越细，求解越慢，但门控窗口越贴合。time_limit_s是求解器超时，超过就返回当前最优或不可行。export_gcl导出的 CSV 一般包含端口、队列号、开时间、关时间四列。
第三步，把导出的 GCL 文件喂给 OMNeT++。OMNeT++ 侧需要有一个能读 CSV 并驱动门控模块的 TSN 仿真模型。常见做法是用 INET 框架里的 TSN 支持，或者自己写一个简单的门控应用层。下面是一个读取 GCL 并设置门控状态的代码片段：
// 在 OMNeT++ 模块初始化时读取 GCL std::ifstream gclFile("gcl_output.csv"); std::string line; while (std::getline(gclFile, line)) { // 格式: port,queue,open_time_us,close_time_us auto parts = split(line, ','); int port = std::stoi(parts[0]); int queue = std::stoi(parts[1]); double openUs = std::stod(parts[2]); double closeUs = std::stod(parts[3]); // 注册到门控调度器，仿真时间到达 openUs 时打开队列 gateScheduler[port][queue].addWindow(openUs, closeUs); }这段代码的关键是addWindow，它把每个队列的门控窗口按仿真时间注册进去。OMNeT++ 的仿真时间单位通常是秒，所以 CSV 里的微秒要除以 1e6 再传进去，否则门控永远不触发——这个单位坑我踩过不止一次。
2.3 参数怎么设：周期、粒度、求解器超时
TSNkit 侧最影响结果的是三个参数：流量周期、门控粒度和求解器超时。流量周期要和实际应用对齐，比如车载控制常用 1 毫秒或 2 毫秒，视频流可能 4 毫秒或 8 毫秒。周期设错，求解出来的调度表在仿真里会周期性丢包。门控粒度我一般从 1 微秒起步，如果求解超时再放宽到 2 微秒或 5 微秒，但不要超过最小帧传输时间的十分之一，否则门控窗口切得太粗，高优先级流量会被低优先级挤掉。求解器超时设 60 秒是个经验值，小网络通常几秒出解，大网络可能跑满 60 秒还只是可行解不是最优解，这时候要看result.conflicts里哪些流冲突，优先调整那些流的周期或截止时间。
OMNeT++ 侧要注意仿真时间和真实时间的映射。sim-time-limit一般设成所有流量周期的最小公倍数的几倍，比如周期是 1 毫秒和 2 毫秒，最小公倍数是 2 毫秒，仿真跑 100 毫秒就能看到 50 个周期，足够统计时延分布。统计时不要只看平均值，要看 99 分位和最大值，TSN 的确定性体现在最坏情况，不是平均情况。
3. 在 OMNeT++ 里把调度表跑起来：从 GCL 到端到端时延统计
3.1 搭建 TSN 仿真场景的四个必配模块
OMNeT++ 里跑 TSN 调度，不管用 INET 还是自建模型，有四个模块必须配对齐。第一个是时钟模块，所有节点要共享同一个仿真时间基准，否则门控窗口在不同节点上错位。第二个是队列模块，每个出端口至少要有 8 个优先级队列，队列的排队规则要和 TSNkit 建模时一致，比如都是严格优先级或者都是基于信用的整形。第三个是门控模块，它根据 GCL 控制每个队列的开关，关的时候队列不发送，开的时候按优先级发送。第四个是统计模块，记录每个流的端到端时延、队列积压和丢包。
我一般会在omnetpp.ini里把这些模块的参数写清楚：
[Config TSN_Schedule_Test] network = TSNNetwork sim-time-limit = 100ms *.clock.clockRate = 1e9 *.switch.queue[*].numQueues = 8 *.switch.gate.scheduleFile = "gcl_output.csv" *.switch.gate.granularity = 1us *.sink.statistic.recordHistogram = true *.sink.statistic.vectorRecording = trueclockRate设成 1e9 表示纳秒级时钟，和 TSN 的调度精度匹配。numQueues要和 TSNkit 里的优先级数量一致，不一致的话 GCL 里的队列号会越界。granularity是门控模块自己检查窗口的时间步长，设成 1 微秒和 TSNkit 的粒度对齐。recordHistogram打开后，仿真结束会输出时延直方图，直接看 99 分位。
3.2 用向量记录抓端到端时延：配置与解读
OMNeT++ 的向量记录（vector）是排查时延问题最直接的工具。你可以在发送端记录发送时间，在接收端记录到达时间，两者相减就是端到端时延。下面是一个在接收端记录时延的代码片段：
void Sink::handleMessage(cMessage *msg) { simtime_t arrival = simTime(); simtime_t sendTime = msg->par("sendTime").doubleValue(); simtime_t e2eDelay = arrival - sendTime; // 记录到向量文件，供后续分析 e2eDelayVector.record(e2eDelay); // 同时更新最大值和99分位统计 if (e2eDelay > maxDelay) maxDelay = e2eDelay; delayHistogram.collect(e2eDelay); delete msg; }sendTime是发送端在消息里塞的时间戳，e2eDelay就是端到端时延。e2eDelayVector.record会把每个包的时延写进.vec文件，用 OMNeT++ 的 IDE 或者 Python 的omnetpp库都能画图。delayHistogram.collect会生成直方图，仿真结束自动算均值、最大值和分位数。我一般会先看最大值有没有超过截止时间，再看 99 分位和均值的差距，差距大说明调度不稳定，可能是门控窗口和流量周期没对齐。
3.3 门控窗口与流量周期对齐的检查方法
调度表跑起来之后，最常见的问题是门控窗口和流量到达时间错位。比如流量每 1 毫秒到一次，门控窗口每 1 毫秒开一次，但开的时间比到达时间晚了几微秒，包就得等下一个窗口，时延直接翻倍。检查方法是在 OMNeT++ 里同时记录包到达队列的时间和门控打开的时间，看差值。
// 在队列模块里记录包到达和门控打开的时间差 void Queue::handleMessage(cMessage *msg) { if (msg->arrivedOn("in")) { simtime_t arrival = simTime(); simtime_t nextOpen = gateScheduler.getNextOpenTime(queueIndex); simtime_t wait = nextOpen - arrival; waitTimeVector.record(wait); // 如果等待时间超过一个周期，说明窗口错位严重 if (wait > flowPeriod) { EV_WARN << "队列 " << queueIndex << " 等待时间 " << wait << " 超过周期 " << flowPeriod << "\n"; } } }getNextOpenTime返回该队列下一次门控打开的时间，wait是包在队列里等的时间。如果wait接近一个周期，说明包到的时候窗口刚关，只能等下一轮。这时候要么调整 TSNkit 里的相位偏移，要么在 OMNeT++ 里给门控加一个提前量。我一般会在 TSNkit 求解时把相位作为变量放开，让求解器自己找对齐点，而不是手动调。
4. 避坑与排查：TSNkit 加 OMNeT 联调时最容易翻车的五件事
4.1 求解器报不可行但流量明明很轻
现象：TSNkit 返回feasible=false，但流量总带宽只占链路 10%，看起来不可能不可行。原因通常是截止时间设得太紧，或者门控粒度太粗导致窗口切不出来。比如 500 字节帧在 1 Gbps 链路上传输要 4 微秒，如果门控粒度是 5 微秒，最小窗口就是 5 微秒，但截止时间只有 3 微秒，求解器怎么切都满足不了。解决方法是先把截止时间放宽到传输时间的 10 倍以上，确认能出解，再逐步收紧，找到可行边界。另外检查slot_granularity_us是不是大于最小帧传输时间，是的话调小。
4.2 OMNeT++ 读 GCL 后门控不触发
现象：仿真跑完，所有包都按时到达，门控好像没起作用。原因多半是时间单位没换算。TSNkit 导出的 GCL 时间单位是微秒，OMNeT++ 的simTime()单位是秒，如果直接把微秒数当秒用，门控窗口在仿真开始后 1 微秒就关了，后面所有包都走默认队列。解决方法是读 CSV 时把时间除以 1e6，或者在omnetpp.ini里把sim-time-limit和门控时间都统一成微秒单位。我习惯在导出 GCL 时就转成秒，省得后面忘。
4.3 时延统计出现负值
现象：端到端时延向量里出现负数。原因通常是发送时间戳在接收端被覆盖，或者消息经过多个模块时sendTime参数被重新赋值。解决方法是发送时间戳只在源节点写一次，中间节点不要动这个参数。如果用了 INET 的UDPBasicApp，它自带的creationTime可以用，但要注意它记录的是应用层创建时间，不是物理层发送时间，两者差一个协议栈处理延迟。我一般会在 MAC 层出口重新打时间戳，保证测的是链路和队列时延。
4.4 仿真跑得极慢，一个周期要跑几分钟
现象：OMNeT++ 仿真速度远低于预期，100 毫秒仿真时间跑了几分钟。原因通常是门控粒度太细，比如设成 1 纳秒，每个包都要检查几千次门控状态。解决方法是把门控粒度调到 1 微秒或 10 微秒，和 TSNkit 的粒度一致。另外检查有没有在handleMessage里做复杂计算，比如每次都重新读 GCL 文件。GCL 应该在initialize()里读一次，存成内存结构，仿真过程中只查表。
4.5 调度表在仿真里可行但下发到交换机后失效
现象：TSNkit 求解可行，OMNeT++ 仿真时延也达标，但配到真实交换机后流量抖动变大。原因通常是仿真模型简化了交换芯片的内部延迟和队列行为。比如仿真里假设交换机转发延迟固定 2 微秒，真实芯片可能因为查表、整形、缓存管理多出几微秒抖动。解决方法是把仿真里的交换机延迟设成实测最坏值，而不是典型值。另外检查真实交换机的门控粒度是不是和仿真一致，有些芯片只支持 8 纳秒或 16 纳秒粒度，和仿真里的 1 微秒对不上，需要重新求解。
5. 把调度表从仿真推到硬件前的最后一道验证
仿真跑通之后，别急着把 GCL 下发到交换机。我一般会做一轮“边界压力测试”：把流量周期缩小 10%，把帧长放大 20%，把截止时间收紧 10%，再跑一次 TSNkit 求解和 OMNeT++ 仿真。如果还能出可行解且时延不超，说明调度表有裕量，下发到硬件后即使有额外抖动也不容易翻车。下面是一个批量跑边界条件的脚本示例：
import subprocess import json base_flows = json.load(open("flows.json")) margins = [0.9, 0.8, 0.7] # 周期缩小比例 for m in margins: for flow in base_flows["flows"]: flow["period_us"] = int(flow["period_us"] * m) flow["deadline_us"] = int(flow["deadline_us"] * m) json.dump(base_flows, open(f"flows_m{m}.json", "w")) # 调用 TSNkit 求解 ret = subprocess.run( ["python", "-m", "tsnkit.solve", "--topo", "topo.json", "--flows", f"flows_m{m}.json", "--output", f"gcl_m{m}.csv"], capture_output=True, text=True ) if "infeasible" in ret.stdout: print(f"余量 {m} 不可行，停止收紧") break # 调用 OMNeT++ 仿真 subprocess.run( ["opp_run", "-u", "Cmdenv", "-n", ".", "-l", "inet", f"--sim-time-limit=100ms", f"*.switch.gate.scheduleFile=\"gcl_m{m}.csv\""], capture_output=True )这段脚本先按比例收紧周期和截止时间，再依次跑 TSNkit 和 OMNeT++。margins从 0.9 开始，如果 0.9 就不可行，说明原始调度表余量很小，下发硬件风险高，需要回头调整流量优先级或增加链路带宽。如果 0.7 还能可行，说明余量充足，可以放心推。opp_run是 OMNeT++ 的命令行入口，-u Cmdenv表示用命令行模式跑，-n .指定 NED 文件路径，-l inet加载 INET 库。跑完看输出里有没有丢包和超时告警。
最后说一个我自己的习惯：每次求解完，我都会把 GCL 文件用 Python 画成甘特图，横轴时间，纵轴队列，每个窗口画一个色块。肉眼扫一遍就能看出有没有窗口重叠、有没有队列长时间关闭。这个图比看 CSV 快得多，也更容易发现求解器给出的“可行但奇怪”的解。TSN 调度这件事，仿真不是目的，目的是让你在下发配置之前心里有底。希望帮到你。
本文还有配套的精品资源，点击获取
