近日，某自动驾驶出行平台在武汉发生大规模车辆集体停运事件，87辆无人驾驶出租车同时停在路中央，导致多条核心路段瘫痪近3小时。官方初步判定为"系统故障"，而业内分析将矛头指向了通信链路或云端系统。
作为工业物联网通信领域的从业者，我想从技术角度聊聊这件事——这锅，不该全由网络来背。
一、通信冗余做到了极致，为什么还会瘫？
智能网联汽车的通信系统设计，通常已经考虑了极高的可靠性：
表格
| 冗余层级 | 设计 | 作用 |
|---|---|---|
| 模组冗余 | 双独立5G通信模组 | 任一模组故障不影响运行 |
| 运营商冗余 | 双SIM卡，双运营商 | 一家断网，另一家接管 |
| 频段冗余 | 双频并发 | 一个小区故障，另一个保障 |
| 链路切换 | 毫秒级自动切换 | 主链路质量下降时无缝切换 |
从通信层面看，这种设计确实"武装到了牙齿"。多车同时通信系统出问题的概率基本为零。
基站层面同样如此：密集城区每隔几百米就有一座基站，两家运营商的多个基站同时故障，概率极低。若核心网出问题，影响范围远不止几十辆车，而是整片区域的手机、企业专线全部中断——这会是更炸裂的新闻。
排除车端、路侧、网络的问题后，故障指向了云端。
二、车路云架构的"阿喀琉斯之踵"
自动驾驶有两条技术路线：
路线一：单车智能
感知、决策、执行全部在车内完成。云端只负责车队管理、地图更新、模型训练，不干预实时驾驶。
优势：断网也能跑，核心能力不打折。
路线二：车路云一体化
表格
| 层级 | 功能 |
|---|---|
| 车端 | 接收路侧和云端数据，执行指令 |
| 路侧 | 激光雷达、毫米波雷达等，提供"上帝视角" |
| 云端 | 运行大模型，负责全局调度、路径规划、直接下发驾驶指令 |
| 网络 | C-V2X蜂窝车联网，低时延高可靠连接 |
优势：云端算力强大，车端硬件可以轻量化，成本更低，适合大规模部署；在港口、矿山、固定线路等场景，通行效率更高。
致命弱点：如果云端宕机或通信链路中断，车端缺乏足够的本地兜底能力，就会导致大量车辆集体失能，造成系统性交通瘫痪。
三、高度中心化的风险
一些平台将L4级自动驾驶最核心的能力——路径规划、实时决策、风险处置、大模型推理——全部集中在云端。车端虽然搭载了高算力AI芯片、数十个传感器，号称多重安全冗余，但没有被赋予完整的离线决策权限。
结果：与云端断联后，连"安全靠边停车"都做不到，只能执行最保守的"原地停车"策略。
这在低密度场景或许可行，但在武汉这样的高密度城市高架、主干道，"原地停车"反而制造了更大的系统性风险——后车追尾、交通拥堵、乘客被困。
四、国标对"最小风险策略"的要求
现行国标 GB/T 44721-2024 规定：
当设计运行条件即将不满足，L4自动驾驶系统应及时执行最小风险策略，使车辆在不满足设计运行条件之前达到静止。
即将更新的《智能网联汽车自动驾驶系统安全要求》意见征集稿中，对此提出了更严格的要求：
表格
| 新要求 | 含义 |
|---|---|
| 具备执行变更车道过程的能力 | 不能只会"原地停" |
| 最小化对用户和其他道路使用者的安全风险 | 考虑全局，不只是自身 |
| 旨在将车辆移至不妨碍交通的地方静止 | 必须靠边，不能堵路 |
这意味着：类似事件再发生，自动驾驶汽车需要能自动变道，并把车安全停在路边。
五、给行业的启示
1. 本地主导，云端辅助才是正解
单车智能和车路云不是互斥的，应该互为补充：
单车智能作为安全底座，确保断网时车辆仍能自主决策
路侧和云端作为能力增强，提供超视距感知、全局优化
海外主流Robotaxi玩家均采用"单车智能为主，远程协助为辅"的路线，云端主要用于全局优化、远程监控和模型迭代，而非直接"微操"车辆行驶。
2. 安全兜底是底线，不是成本项
商业化运营追求高效与低成本，这无可厚非。但自动驾驶的底线永远是安全可靠。
表格
| 层面 | 要求 |
|---|---|
| 车端 | 必须具备完整的离线决策能力，能独立执行最小风险策略 |
| 通信 | 冗余设计是必要的，但不能替代本地智能 |
| 云端 | 故障时系统应优雅降级，而非彻底瘫痪 |
3. 给乘客的，不只是一次出行
当一位疲惫的乘客坐进没有司机的出租车时，他不关心产业发展的宏大叙事，他想要的只是在路上安心地眯一会，车就平稳安全地开到了家门口。
每一次故障，都是对这份信任的透支。
写在最后
车路云一体化架构在中国城市高密度、混合交通环境中具有独特优势，但驾驶决策不能高度依赖云端。给车辆本地在特定场景下自主驾驶的权限，是避免系统性风险的关键。
通信网络的冗余设计，解决的是"连得上"的问题；而本地智能的兜底能力，解决的是"断得了也跑得稳"的问题。两者缺一不可。
