4、汽车TSN网络架构：域控制器架构下的TSN部署、Zone架构下的TSN部署、混合架构

聊到TSN在车上的部署，其实绕不开一个根本问题：你的网络架构长什么样？

我这些年接触过的项目，从早期的分布式ECU，到后来的域控，再到现在的Zone架构，几乎都走了一遍。说实话，每种架构下TSN的玩法都不一样。你想想看，网络拓扑变了，时钟同步的路径变了，流量调度的策略也得跟着变。

这一节，我就把三种主流架构下的TSN部署经验掰开揉碎讲给你听。

4.1 域控制器架构下的TSN部署

域控制器架构，说白了就是把功能相近的ECU归到一个域里，由域控制器统一管理。比如智能驾驶域、座舱域、车身域、动力域。

这种架构下，TSN的部署重点在域内和域间两个层面。

4.1.1 域内TSN：局部精准同步

域内通信，通常是域控制器和几个传感器或执行器之间的数据交换。比如智驾域里，摄像头、激光雷达、域控之间需要低延迟的视频流。

我个人习惯在域内采用802.1AS（gPTP）做时钟同步。为什么？因为域内节点少，链路短，同步精度容易做到亚微秒级。

域内流量调度，我建议用802.1Qbv（时间感知整形）。把摄像头数据流设为高优先级，控制指令设为最高优先级，其他诊断类流量放低优先级。这样能保证关键数据不丢包。

// 域内Qbv配置示例（简化）
// 智驾域：摄像头数据流
tc0: 控制指令（最高优先级）
tc1: 摄像头视频流（高优先级）
tc2: 雷达点云数据（中优先级）
tc3: 诊断/日志（低优先级）

// 门控列表（Gate Control List）
周期 = 1ms
t0-t0.8ms: tc1开启（摄像头传输窗口）
t0.8ms-t0.9ms: tc0开启（控制指令窗口）
t0.9ms-t1.0ms: tc2/tc3共享（尽力而为窗口）

4.1.2 域间TSN：跨域桥接的挑战

域间通信就麻烦一些。不同域之间可能有不同的时钟域，比如智驾域用PPS同步，座舱域用网络同步。

我曾经踩过一个坑：智驾域和座舱域之间通过一个交换机连接，两边各自跑了gPTP，结果交换机的桥接延迟没处理好，导致视频流到座舱显示时，画面和声音对不上。

域间流量调度，我推荐用802.1Qci（流过滤与监管）。因为域间流量复杂，可能有恶意或异常流量。Qci可以在入口处就把不合规的帧丢掉，保护骨干网络。

4.2 Zone架构下的TSN部署

Zone架构是近几年兴起的。它不再按功能划分，而是按物理位置划分。比如左前Zone、右前Zone、左后Zone、右后Zone。每个Zone负责管理附近的所有传感器和执行器。

这种架构下，TSN的部署逻辑完全变了。嗯，这里要注意：Zone架构的核心是中央计算平台 + 区域网关。

4.2.1 Zone内TSN：短距离高带宽

Zone内通信，主要是区域网关和本Zone内的设备。比如左前Zone里，有左前摄像头、左前毫米波雷达、左前大灯等。

我个人建议在Zone内使用802.1Qbu（帧抢占）。为什么？因为Zone内有很多低延迟的传感器数据，比如摄像头触发信号、雷达点云。帧抢占可以让高优先级帧打断低优先级帧的传输，延迟能降到几十微秒。

4.2.2 跨Zone TSN：环形或星形骨干

跨Zone通信，通常走骨干网络。骨干网络可以是环形（冗余），也可以是星形（简单）。

我参与过一个项目，用的是环形骨干。好处是链路冗余，坏处是时钟同步容易形成环路。当时我们配置gPTP时，差点被环路的时钟路径搞疯掉。

// 环形骨干gPTP配置要点
1. 必须启用802.1AS-2020的快速收敛机制
2. 每个Zone网关配置为边界时钟
3. 主时钟（GM）放在中央计算平台
4. 备份GM放在右后Zone网关（物理位置最远）
5. 环路检测：使用MRP或RSTP防止时钟风暴

跨Zone的流量调度，我推荐用802.1Qch（循环排队转发）。CQF可以把端到端延迟控制在确定的几个周期内，非常适合ADAS和底盘控制这类确定性要求高的场景。

4.3 混合架构

混合架构，说白了就是域控和Zone架构的融合。比如中央计算平台 + 几个域控制器 + 几个Zone网关。这种架构在目前的高端车型上很常见。

你想想看，为什么会出现混合架构？因为纯域控架构的线束太重，纯Zone架构的算力分布又太散。混合架构试图取两者的优点。

4.3.1 混合架构下的TSN分层

混合架构下，TSN需要分层部署：

• 第一层：Zone内TSN - 使用帧抢占和CQF，保证传感器数据的低延迟
• 第二层：域内TSN - 使用Qbv和gPTP，保证域内计算节点间的同步
• 第三层：骨干TSN - 使用CQF和802.1CB（冗余），保证跨域跨Zone的可靠传输

我个人习惯在混合架构里，把中央计算平台作为整个网络的主时钟。所有Zone网关和域控制器都同步到它。这样能避免多主时钟的混乱。

4.3.2 流量分类与优先级映射

混合架构下，流量种类多，优先级映射必须统一。我建议用以下映射表：

流量类型	示例	优先级	TSN机制
安全关键控制	制动、转向指令	7（最高）	Qbv + 帧抢占
传感器数据流	摄像头、激光雷达	6	CQF + Qci
同步信号	gPTP事件消息	5	802.1AS
诊断/OTA	日志、固件升级	2-3	尽力而为
背景流量	娱乐、导航	0-1	无保障

4.3.3 混合架构的冗余设计

混合架构的冗余，我建议用802.1CB（FRER）。FRER可以在两条路径上同时发送相同的数据帧，接收端去重。这样即使一条链路断了，数据也不会丢。

我记得有一次，客户要求ADAS系统的可用性达到99.999%。我们就是用FRER + 环形骨干实现的。两条路径的延迟差控制在50微秒以内，接收端用序列号去重，效果很好。

// FRER配置示例（混合架构）
// 路径1：左前Zone -> 中央计算 -> 右后Zone
// 路径2：左前Zone -> 骨干环 -> 右后Zone

// 发送端配置
stream_handle: 0x1001
sequence_number: 递增
redundancy: 启用（两条路径同时发送）

// 接收端配置
stream_handle: 0x1001
window_size: 4（最多容忍4个帧乱序）
recovery_algorithm: 序列号去重

好了，三种架构下的TSN部署就聊到这里。说实话，没有一种架构是完美的。域控架构简单但扩展性差，Zone架构灵活但同步复杂，混合架构强大但配置繁琐。

我个人建议：如果你做的是L2+级别的车，域控架构就够了。如果是L3以上，Zone架构或混合架构是必须的。具体选哪种，还得看你的线束成本、算力分布和功能安全要求。

下一节，我会讲TSN的时钟同步测试，那是整个一致性测试里最容易出问题的地方。到时候我会分享几个我踩过的坑，保证让你少走弯路。