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