第3章网络拓扑设计

3、网络拓扑设计：Zonal架构下的以太网骨干网设计原则、TSN时间敏感网络的应用

好，我们进入第三个核心话题——网络拓扑设计。

说实话，Zonal架构里最让我头疼的，就是以太网骨干网怎么搭。你想想看，以前分布式架构，各个ECU之间各聊各的，CAN、LIN、FlexRay混着用，虽然乱，但至少不堵车。现在倒好，所有数据都往一根以太网线上挤，摄像头流、雷达点云、控制指令、OTA升级包……稍不留神，网络就崩了。

3.1 以太网骨干网设计原则

我个人习惯，设计骨干网时先问自己三个问题：

带宽够不够？ 别只看峰值，要看持续吞吐。
延迟稳不稳？ 控制指令丢一个包，可能就出事故。
扩展行不行？ 今天加个激光雷达，明天加个域控，网络不能重做。

基于这三点，我总结了几条硬性原则：

原则一：分层设计，别搞扁平化

Zonal架构的骨干网，我建议至少分两层：

Zone层： 每个Zone内部用千兆以太网，连接本区域的传感器和执行器。
中央层： 中央网关或高性能计算平台，用万兆甚至更高速率互联。

我在项目里见过有人图省事，把所有节点都挂在一根千兆线上。结果呢？摄像头一开，控制指令延迟直接飙到10ms以上。嗯，后来全改了。

原则二：冗余设计，别省那两根线

对于L3以上的自动驾驶，骨干网必须冗余。我常用的方案是双环形拓扑：

Zone1 ──┬── Zone2 ──┬── Zone3
        │            │
    [中央网关A]  [中央网关B]
        │            │
Zone4 ──┴── Zone5 ──┴── Zone6

这样任意一根光纤断了，数据还能从另一条路走。我曾经吃过亏——某次路测，一根线被老鼠咬断，整车直接降级到L2，吓得我连夜改了设计。

原则三：流量隔离，别让控制流和数据流打架

我习惯把骨干网分成三个逻辑平面：

平面	承载内容	优先级	典型带宽
控制平面	制动、转向、加速指令	最高	10Mbps
数据平面	摄像头、激光雷达、超声波	中	1-10Gbps
服务平面	OTA、诊断、日志	低	100Mbps

说白了，控制指令必须走专用VLAN，不能跟视频流抢带宽。我见过一个反面案例——OTA升级时把网络占满了，结果刹车指令延迟了20ms……还好是台测试车。

3.2 TSN时间敏感网络的应用

说到延迟，就不得不提TSN。很多朋友问我：「TSN到底解决了什么问题？」

我的回答是：它让以太网变得「守时」了。

传统以太网是尽力而为的——你发一个包，它尽量帮你送到，但不保证什么时候到。但车里不行啊，转向指令必须在1ms内到达，晚一点都不行。TSN就是给以太网加了一套「交通管制系统」。

3.2.1 TSN的核心机制

我个人最常用的三个TSN标准：

IEEE 802.1Qbv（时间感知整形）： 给每个流量类型分配一个时间窗口。比如每1ms里，前100μs只走控制流，后900μs走数据流。这样控制流永远不会被堵住。
IEEE 802.1Qbu（帧抢占）： 低优先级帧正在传输时，高优先级帧可以打断它。嗯，有点像VIP通道。
IEEE 802.1AS（时钟同步）： 全网节点同步到纳秒级。没有这个，Qbv就是空谈。

关键配置示例（基于Linux tc工具）：

# 配置Qbv门控列表，周期1ms
tc qdisc add dev eth0 parent root handle 1: taprio \
    num_tc 4 \
    map 0 1 2 3 \
    queues 1@0 1@1 1@2 1@3 \
    base-time 0 \
    sched-entry S 0x01 100000 \  # 控制流窗口：100μs
    sched-entry S 0x02 200000 \  # 数据流窗口：200μs
    sched-entry S 0x04 700000    # 尽力而为窗口：700μs
    flags 0x02

我在实际项目中踩过一个坑：Qbv的基准时间必须跟802.1AS同步，否则所有门控都错位。有一次我忘了配置gPTP，结果控制流和数据流的时间窗口完全重叠，延迟反而更差了。后来我学乖了，每次部署TSN前，先拿示波器量一下PTP同步精度。

3.2.2 TSN在Zonal架构中的典型部署

我推荐的分层部署方案：

Zone内部： 用TSN交换机做流量整形。每个Zone的传感器数据先本地整形，再发往中央。
骨干网： 中央网关启用Qbv和帧抢占。控制流走最高优先级队列，视频流走中优先级，OTA走最低。
端节点： 摄像头、雷达等传感器支持802.1AS，确保时间戳一致。

避坑指南：

我曾经在某个项目里，所有TSN配置都对了，但摄像头数据还是抖动。查了三天，发现是摄像头晶振精度不够，导致PTP同步误差累积。后来换了温补晶振，问题解决。所以记住：TSN的精度，取决于最差的那个时钟源。

3.2.3 带宽与延迟的权衡

你可能会问：「TSN会不会浪费带宽？」

会，但值得。我举个例子：

配置	控制流延迟	数据流吞吐	总带宽利用率
无TSN	5-20ms（抖动大）	950Mbps	95%
有TSN（Qbv）	<1ms（确定）	800Mbps	80%

说白了，用15%的带宽换来了20倍的延迟确定性。对于L3以上的车，这笔买卖太划算了。

注意： TSN不是万能药。如果你的骨干网带宽利用率已经超过70%，再好的TSN也救不了。我建议预留30%的余量，给未来的功能升级。

3.3 我的设计检查清单

最后，分享一份我每次评审网络设计时必查的清单：

骨干网是否支持至少1Gbps（建议2.5G或5G）？
控制流和数据流是否做了VLAN隔离？
TSN的时钟同步精度是否达到±100ns以内？
Qbv的门控周期是否覆盖了所有关键流？
冗余链路切换时间是否小于50ms？
有没有为OTA预留独立的带宽通道？

嗯，就这些。下一章我们聊聊「Zonal架构下的电源管理与休眠唤醒设计」，那也是个容易翻车的地方。