4、AVB/TSN协议族：gPTP时间同步协议、SRP流预留协议、FQTSS队列调度

AVB/TSN协议族，说白了就是车载以太网里用来保证「实时性」的那一套组合拳。我刚开始接触这个领域的时候，总觉得车载网络嘛，能传数据不就行了？后来在实车上调试ADAS摄像头数据流，才发现没有时间同步和带宽保障，画面卡顿、丢帧简直是家常便饭。

这一章我们重点聊三个核心协议：gPTP（时间同步）、SRP（流预留）、FQTSS（队列调度）。它们三个配合起来，才能让音视频数据在车载网络里「准时、不丢、不卡」地跑起来。

4.1 gPTP：让所有节点「看同一个表」

gPTP（广义精确时间同步协议）是IEEE 802.1AS标准定义的。它的任务很简单：让网络里所有设备都使用同一个时钟源。你想想看，如果摄像头和域控制器的时间差了几毫秒，那视频流里的时间戳就全乱了。

我个人习惯把gPTP的工作流程拆成三步来理解：

1. 主时钟选举：网络里选出一个「最准」的节点当老大（Grandmaster），其他节点都跟着它走。
2. 链路延迟测量：每个节点测量自己到主时钟的链路延迟，说白了就是算算报文在路上花了多少时间。
3. 时钟同步：节点根据延迟值调整自己的本地时钟，让所有设备的时间误差控制在纳秒级。

4.2 SRP：给音视频流「预定座位」

SRP（流预留协议）对应IEEE 802.1Qat标准。它的作用是在数据流传输之前，先跟沿途的交换机「打个招呼」：我要发一路4K视频流，带宽需要XX Mbps，请帮我预留好资源。

SRP里有两个关键角色：

• Talker：数据发送方，负责发起流预留请求。
• Listener：数据接收方，负责确认是否接收该流。

整个流程是这样的：Talker发出一个声明报文，告诉网络「我要发流了」。沿途的交换机检查自己的带宽够不够，如果够就转发声明，不够就拒绝。Listener收到声明后，如果愿意接收，就回复一个注册报文。这样一路确认下来，整条路径上的带宽就预留好了。

我在项目中遇到过一个问题：某个摄像头频繁发送流预留请求，导致交换机CPU负载飙升。后来发现是应用层代码里有个bug，每次断流重连都会重新发起SRP请求。嗯，这种问题在实车测试时特别容易踩坑。

4.3 FQTSS：让高优先级数据「插队」

FQTSS（前向时间感知整形器）是IEEE 802.1Qav标准定义的。它的核心思想是：给不同优先级的数据流分配不同的发送带宽，确保高优先级流（比如音视频）不会被低优先级流（比如诊断数据）堵住。

FQTSS使用一种叫「信用值整形」的算法。我简单解释一下：

• 每个优先级队列都有一个「信用值」，相当于它的发送配额。
• 队列每发送一个字节，信用值就减少；没发送时，信用值慢慢恢复。
• 信用值大于0时才能发送数据，小于0时就得等着。

这样做的好处是：高优先级队列的信用值恢复得快，所以它能频繁发送；低优先级队列的信用值恢复得慢，自然就被限速了。说白了，这就是一种「软性」的带宽分配机制。

4.4 三个协议如何配合工作？

我画个场景你就明白了：

假设一辆智能汽车，前视摄像头要往域控制器发送一路1080P视频流。

1. gPTP先干活：摄像头和域控制器先完成时间同步，确保两边的时间戳一致。
2. SRP接着上：摄像头作为Talker，向交换机发起流预留请求，申请50Mbps的带宽。交换机检查端口带宽够用，就批准了。
3. FQTSS最后兜底：视频流开始传输后，交换机在出口处用FQTSS调度，确保视频帧走高优先级队列，不会被其他数据干扰。

你看，这三个协议是环环相扣的。没有gPTP，SRP预留的时间基准就是乱的；没有SRP，FQTSS不知道给谁分配带宽；没有FQTSS，预留了带宽也保证不了延迟。

4.5 常见问题与排查思路

现象	可能原因	排查方向
视频流卡顿/丢帧	gPTP同步精度不足	检查主时钟选举、链路延迟测量值
流预留失败	交换机带宽不足或SRP报文丢失	抓SRP报文，检查Talker/Listener交互
高优先级流延迟抖动大	FQTSS队列配置错误	检查信用值参数、优先级映射表
gPTP报文被丢弃	交换机未配置PTP优先级	确认gPTP报文走最高优先级队列

说实话，AVB/TSN协议族在车载领域已经相当成熟了。但成熟不代表简单，尤其是三个协议配合起来的时候，任何一个环节出问题，整个实时通信链路都会崩。我建议你在测试时，先从单协议验证开始，再逐步做联合调试。

好了，这一章的内容就到这里。记住：gPTP是时间基础，SRP是资源保障，FQTSS是执行机制。三者缺一不可。

---

公众号:蓝海资料掘金营，微信deep3321