3. Robotaxi系统总体架构

Robotaxi 不是“把几个算法模块串起来”的软件集合,而是一套在开放道路上持续闭环运行的安全关键系统。理解其总体架构,关键不在于记住模块名称,而在于看清层次划分与接口关系:谁向谁提供什么数据、以什么频率、在什么约束下、失效时如何降级。下面从分层模型、接口契约、数据流与安全冗余四个角度展开。

一、核心原理:三层架构与两条闭环

工程上通常把 Robotaxi 划分为三层:车端实时层、车云协同层与云端运营层。车端实时层包含感知、定位、预测、规划、控制五个核心模块,运行在车载计算平台上,要求毫秒级确定性;车云协同层负责通信、远程协助、OTA 与数据回传;云端运营层承担调度、监控、仿真、地图与安全分析。

架构中存在两条闭环:一条是控制闭环——感知→定位→预测→规划→控制→车辆执行,周期通常在 50~100 ms;另一条是数据闭环——车端事件与影子数据→云端挖掘→模型训练→OTA 下发→车端更新,周期以天或周计。两条闭环的时间尺度相差三个数量级,因此接口设计必须区分“硬实时”与“准实时/离线”。

架构判断准则:任何模块的接口都应明确四要素——数据语义、更新频率、时间戳基准、失效降级策略。缺少任一项,都会在系统集成阶段暴露为难以定位的时序缺陷。

二、层次划分与接口关系

车端实时层内部并非简单串联。感知输出目标级与占据栅格两类结果;定位输出自车位姿、速度与协方差;预测消费感知与定位结果,输出多模态轨迹及概率;规划消费预测、定位、地图与路由,输出时空轨迹;控制消费规划轨迹与车辆状态,输出油门、制动、转向指令。各模块通过中间件(如 DDS、SOME/IP 或自研共享内存)通信,接口以 IDL 定义并版本化管理。

车云接口则更强调带宽与可靠性权衡。上行包括脱困请求、事件片段、诊断日志与影子模式数据;下行包括远程协助指令、调度任务、高精地图增量与 OTA 包。通信层需支持多链路冗余(如双 5G/4G + V2X),并在链路抖动时保证关键指令的优先级。

Robotaxi 总体架构:层次划分与接口关系 云端运营层(准实时 / 离线) 调度与派单 订单 / 路径 / 运力 监控与安全 事件 / 告警 / 审计 仿真与训练 场景 / 模型 / 回归 高精地图 增量 / 版本 / 校验 OTA 管理 灰度 / 回滚 / 签名 车云协同层(通信与远程协助) 多链路通信(5G/4G + V2X) 远程协助(脱困 / 接管) 数据回传(事件 / 影子) 时间同步 / 证书 车端实时层(硬实时,50~100 ms 控制闭环) 感知 目标 / 车道线 / 栅格 相机·激光·毫米波 定位 位姿 / 速度 / 协方差 GNSS·IMU·SLAM 预测 多模态轨迹 + 概率 交互 / 意图 / 不确定性 规划 路由 / 行为 / 轨迹 安全 / 舒适 / 交规 控制 油门 / 制动 / 转向 横纵向解耦 / 执行器 车辆状态 / 执行反馈(闭环校正) 安全冗余层:双电源 · 双制动 · 双转向 · 双计算 · 最小风险策略(MRM)· 安全监控器 下行:任务 / 地图 / OTA 上行:事件 / 诊断 / 影子 运营层 协同层 实时层

三、方法流程:从需求到接口冻结

架构设计不是一次性画图,而是一个逐步收敛的流程。典型步骤包括:

  1. 场景与 ODD 定义:明确运行设计域,决定传感器配置与冗余等级。
  2. 功能分解与分配:把“安全到达”分解为感知、定位、预测、规划、控制子功能,并分配到车端或云端。
  3. 接口契约设计:定义消息 IDL、频率、时间戳、坐标系、单位与失效语义。
  4. 时序与资源预算:为每个模块分配 CPU/GPU、内存与端到端延迟预算。
  5. 安全分析与降级设计:通过 FMEA、STPA 识别失效模式,设计 MRM 与冗余切换。
  6. 集成与回归:在 HIL、封闭场地与仿真中验证接口一致性与时序。

其中第 3 步最容易被低估。接口一旦冻结,后续变更成本极高,因此建议在项目早期就建立接口版本矩阵,并让上下游模块共同评审。

四、案例与场景:一次“通信抖动”的复盘

某次路测中,车辆在路口突然减速并请求远程协助。日志显示:感知与规划均正常,但通信层在 1.2 s 内出现 5G 链路抖动,导致云端下发的“路口放行”指令延迟到达。规划模块因未收到确认,按保守策略触发 MRM 靠边停车。

[2024-06-11 14:32:07.118] comm: 5G link RSRP -108 dBm, jitter 320 ms
[2024-06-11 14:32:07.442] plan: waiting cloud_confirm, timeout 800 ms
[2024-06-11 14:32:08.201] safety: MRM triggered, reason=cloud_confirm_timeout
[2024-06-11 14:32:08.205] ctrl: decel 1.5 m/s², pull over to shoulder

复盘结论有三点:其一,云端确认不应作为路口通行的强依赖,车端应具备本地决策能力;其二,通信层需向规划层提供链路质量与置信度,而非只给“收到/未收到”;其三,MRM 触发阈值应与车速、路口类型联动,避免过度保守造成通行效率下降。

常见误区:把云端当作“实时控制器”。云端适合做调度、监控与训练,不应进入 100 ms 级控制闭环。任何跨云的关键指令都必须有车端本地兜底策略。

五、安全冗余与接口清单

安全冗余不是“多装一套”,而是在接口层面定义降级路径。下表给出关键模块的冗余对象与接口约束。

模块 主通道 冗余/降级 关键接口约束
感知 相机 + 激光雷达 毫米波雷达兜底,降速运行 目标级输出带置信度与时间戳
定位 GNSS + IMU + SLAM 航迹推算,限制 ODD 位姿必须带协方差,供规划评估
预测 多模态轨迹 保守单模态,扩大安全距离 输出概率与预测时域
规划 行为 + 轨迹规划 MRM 靠边停车 轨迹需满足动力学与交规约束
控制 线控执行器 双制动/双转向切换 指令带心跳与超时保护
通信 5G/4G + V2X 多链路切换,本地缓存 关键指令优先级与重传策略
云平台 调度与监控 车端自治,云端只做辅助 下行指令必须可被车端否决

最后强调一点:架构的优劣不取决于模块数量,而取决于接口是否清晰、时序是否可验证、失效是否可降级。当感知、定位、预测、规划、控制、通信、云平台与安全冗余各司其职、边界明确时,Robotaxi 才能在开放道路上稳定运行。