车路云一体化：当“大脑“宕机，“四肢“如何自救

近日，某自动驾驶出行平台在武汉发生大规模车辆集体停运事件，87辆无人驾驶出租车同时停在路中央，导致多条核心路段瘫痪近3小时。官方初步判定为"系统故障"，而业内分析将矛头指向了通信链路或云端系统。

作为工业物联网通信领域的从业者，我想从技术角度聊聊这件事——这锅，不该全由网络来背。

一、通信冗余做到了极致，为什么还会瘫？

智能网联汽车的通信系统设计，通常已经考虑了极高的可靠性：

表格

从通信层面看，这种设计确实"武装到了牙齿"。多车同时通信系统出问题的概率基本为零。

基站层面同样如此：密集城区每隔几百米就有一座基站，两家运营商的多个基站同时故障，概率极低。若核心网出问题，影响范围远不止几十辆车，而是整片区域的手机、企业专线全部中断——这会是更炸裂的新闻。

排除车端、路侧、网络的问题后，故障指向了云端。

二、车路云架构的"阿喀琉斯之踵"

自动驾驶有两条技术路线：

路线一：单车智能

感知、决策、执行全部在车内完成。云端只负责车队管理、地图更新、模型训练，不干预实时驾驶。

优势： 断网也能跑，核心能力不打折。

路线二：车路云一体化

表格

优势： 云端算力强大，车端硬件可以轻量化，成本更低，适合大规模部署；在港口、矿山、固定线路等场景，通行效率更高。

致命弱点： 如果云端宕机或通信链路中断，车端缺乏足够的本地兜底能力，就会导致大量车辆集体失能，造成系统性交通瘫痪。

三、高度中心化的风险

一些平台将L4级自动驾驶最核心的能力——路径规划、实时决策、风险处置、大模型推理——全部集中在云端。车端虽然搭载了高算力AI芯片、数十个传感器，号称多重安全冗余，但没有被赋予完整的离线决策权限。

结果：与云端断联后，连"安全靠边停车"都做不到，只能执行最保守的"原地停车"策略。

这在低密度场景或许可行，但在武汉这样的高密度城市高架、主干道，"原地停车"反而制造了更大的系统性风险——后车追尾、交通拥堵、乘客被困。

四、国标对"最小风险策略"的要求

现行国标 GB/T 44721-2024 规定：

当设计运行条件即将不满足，L4自动驾驶系统应及时执行最小风险策略，使车辆在不满足设计运行条件之前达到静止。

即将更新的《智能网联汽车自动驾驶系统安全要求》意见征集稿中，对此提出了更严格的要求：

表格

这意味着：类似事件再发生，自动驾驶汽车需要能自动变道，并把车安全停在路边。

五、给行业的启示

1. 本地主导，云端辅助才是正解

单车智能和车路云不是互斥的，应该互为补充：

• 单车智能作为安全底座，确保断网时车辆仍能自主决策

• 路侧和云端作为能力增强，提供超视距感知、全局优化

海外主流Robotaxi玩家均采用"单车智能为主，远程协助为辅"的路线，云端主要用于全局优化、远程监控和模型迭代，而非直接"微操"车辆行驶。

2. 安全兜底是底线，不是成本项

商业化运营追求高效与低成本，这无可厚非。但自动驾驶的底线永远是安全可靠。

表格

3. 给乘客的，不只是一次出行

当一位疲惫的乘客坐进没有司机的出租车时，他不关心产业发展的宏大叙事，他想要的只是在路上安心地眯一会，车就平稳安全地开到了家门口。

每一次故障，都是对这份信任的透支。

写在最后

车路云一体化架构在中国城市高密度、混合交通环境中具有独特优势，但驾驶决策不能高度依赖云端。给车辆本地在特定场景下自主驾驶的权限，是避免系统性风险的关键。

通信网络的冗余设计，解决的是"连得上"的问题；而本地智能的兜底能力，解决的是"断得了也跑得稳"的问题。两者缺一不可。