L4自动驾驶的MRM策略-最后安全底牌(下)

上篇链接：L4自动驾驶的MRM策略-最后安全底牌（上）

相关链接：GB 44721 : 旨在构建自动驾驶系统可验证安全体系

本篇目录：

九、MRM轨迹规划：“保守”但“不笨”

MRM 不应直接复用完整正常驾驶行为规划栈，而应使用经过约束、降阶和可验证的 fallback planning stack。该栈可以调用健康的感知、定位、地图和预测模块，但必须通过能力账本声明可信边界，并限制动作集合、速度域、横向侵入范围、预测时域和交互复杂度。

也不能过度简单：一律当前车道刹停。虽然容易验证，却会在路口、隧道、坡顶、施工区等场景制造二次风险。

更好的方案是分层轨迹库：

十、MRM控制策略：让旁车可预测己方行为

MRM 执行阶段的“控制”容易被低估。

• 减速度过小，车辆无法及时脱离风险；

• 减速度过大，后车追尾风险上升，乘客可能受伤，低附着路面还会触发稳定性问题；

• 横向控制同样如此，靠边轨迹太柔和会拖长暴露时间，太激烈会给后车和旁车一种不可预测性、误判本车意图。

MRM 控制应设几类硬约束：

MRM 的目标是风险下降，“副作用”是交通扰动和二次事故。优秀控制策略旨在把车辆能量以可预测、可感知、可承受的方式释放掉。

十一、L4 MRM与MCU/SoC的关系

在量产架构里，SoC 负责感知、预测、规划，MCU 负责监控、执行兜底、供电和底盘安全链路，但不能误解为“MRM 只靠 MCU”。

如果完全依赖 MCU，系统只能做非常粗糙的停车反射，无法处理路口、施工区、硬路肩等场景。理想架构是“双层 MRM”：

SAE J3016 对 L4/L5 的 MRC 描述也支持这个思路：L4/L5 ADS 需要能自动达到 MRC，但达到 MRC 的方式会随失效类型、ODD 和具体运行条件变化，包括当前路径内停车、驶离冲突区域、返回调度设施等动作。 

1. 什么时候要 MCU 做？

场景	为什么用 MCU
SoC 心跳丢失、死锁、重启、过热、内存异常	SoC 已经不能作为可信决策源
SoC 输出超时、规划结果不可信	需要安全链路立即接管
感知/定位严重退化，无法支撑语义规划	复杂靠边、绕行、冲突区判断都不可靠
底盘、制动、转向、电源链路出现安全相关故障	MCU 更接近执行器和供电安全链路
时间预算极小，例如碰撞风险迫近	不能等复杂规划栈运行结束
上下文丢失，只剩车道保持/制动等低阶能力	只能执行预验证动作库

MCU 的关键是 独立、确定、可验证、低时延、失效隔离。应该至少能做：

减速、保持车道、打开双闪、靠边的受限简化版本、驻车、维持安全状态、监控执行器、在 SoC 失效时触发基础 MRM。

2. 什么时候用 SoC 做？

SoC 做 MRM 的前提是：SoC 本身仍然健康，且剩余感知、定位、预测、地图、规划能力足以支撑复杂 MRM。

典型场景包括：

场景	为什么需要 SoC
ODD 即将退出，但系统没崩	例如前方天气、道路类型、地图边界变化，需要提前确定 MRC
感知部分降级但仍可用	例如前摄被遮挡，但激光雷达、毫米波、定位仍可支撑低速靠边
当前车道停车风险更高	例如路口中央、隧道、盲弯、匝道汇入区，需要驶离冲突区后停
需要选择 MRC 位置质量	主路、辅路、硬路肩、港湾、停车区，哪个更安全需要语义评估
需要处理交通参与者交互	后车高速接近、右侧非机动车、施工锥桶、临停车辆等
需要执行 Safe-haven Routing	去预定义安全港湾或运营点，MCU 不适合做全局路径规划
远程协助给出语义许可或目标点	SoC 把远程给出的目标转成受限轨迹，MCU 负责安全监控
需要降低二次风险和交通扰动	SoC 可以综合后向风险、可见性、救援可达性做优化

SoC-MRM 是 nominal-fallback / graceful degradation；MCU-MRM 是 safety fallback / last resort。

层级	目标	典型动作	触发条件
SoC 语义 MRM	更低风险、更低扰动、更合理地撤出交通流	受限靠边、驶离冲突区、驶向安全港湾、远程确认后执行	SoC 健康，但 ODD、感知、定位、规划能力下降
MCU 安全 MRM	保证系统不会失去最后安全动作	车道内减速停车、保持航向、受限横向控制、驻车、灯光提示	SoC 不可信、通信异常、严重故障、时间预算不足

应优先使用 SoC 语义 MRM，因为能选择更合适的停车位置、更低的交通扰动和更小的二次风险。当 SoC 不可信或者时间预算不足时，切换到 MCU 安全 MRM。此时目标不是做出最优选择，而是保证车辆不会因为等待复杂决策而失去最后达到MRC的机会。GB 44721明显区分了L3和L4的MRC要求，L4首选“不妨碍交通的安全区域”，此处若引入全局规划，大概率还是得基于SoC来做。

十二、远程协助是救援队，不是驾驶员

L4 运营一般会引入远程协助，但远程协助与 MRM 的关系需要克制一点。

远程协助适合处理语义不确定性，例如场景出现施工人员手势、临时交通管制、道路被警车封控、乘客异常请求。不适合承担实时、紧急制动、毫秒级请求。

一个安全的远程协助设计应遵守三条边界：

1. 车辆在等待远程协助时必须已经处于低风险或风险受控状态；
2. 远程人员给的是许可、建议或目标，不是连续控制量，甚至不包含全局规划的目的地；
3. 通信失败时车辆仍能独立进入或保持 MRC。

十三、MRM验证：从故障触发到风险闭环的系统性验证

MRM 需要验证：系统在能力退化、环境变化、周围车辆响应不确定的情况下，是否仍能选择合理策略，并且把风险约束在可接受边界内。

MRM验证维度

MRM 的测试应从“单点触发”走向“故事线测试”。比如：

夜间城市主路，前向摄像头被污渍遮挡，激光雷达可用但定位协方差升高，车辆正接近无保护右转路口，后方有高速接近车辆，右侧有非机动车道和临停车辆。此时系统如何降级、是否继续进入路口、在哪里停车、如何提示后车、是否请求远程协助？

十四、评价指标：安全性、可用性和可恢复性

工程产品必须在安全性、可用性和可恢复性之间寻找可证明的平衡。

MRM关键指标体系

容易被忽视的指标：MRC 后的暴露时间。如果车停在主路上，双闪亮着但救援迟迟不到，它仍然在持续暴露风险。按照安全论证链条来推理的话，MRM 的生命周期不应止于 stop，而应延伸到“车辆被恢复、拖离或重新授权运行”。

十五、从规则系统走向风险操作系统

MRM 的发展方向是把风险管理变成系统能力。

1. 可达MRC集合：从“目标点”到“风险地形图”

传统设计会预设几个安全停车点。更先进的做法是实时计算可达 MRC 集合，把道路看成一张风险地形图。车辆不是寻找一个固定停车点，而是在风险地形里寻找“低洼地带”：交通流量低、冲突少、可见性好、救援方便的地方。

2. MRM前置到正常阶段（DDT）的最小风险规划

很多 MRM 失败是正常驾驶阶段没有留操作空间。例如车辆长时间贴近大型货车行驶，右侧持续无可用空间，后方车辆高速接近，一旦感知降级就只能原地刹停。

成熟系统会在正常驾驶时维持“逃生空间”。这类似优秀司机不会把车开进一个没有退路的位置。MRM 能力不是触发时才产生，而是在正常驾驶中被持续维护。就像建筑的紧急通道，平时走的少，但必须有并一直维持。

3. 风险预算：允许短时风险升高，但必须换取更大风险下降

有些场景下，立即停车和继续低速前行都不是零风险。系统需要判断是否允许短时风险上升，以换取整体风险下降。例如路口中央短暂停留很危险，低速驶离冲突区可能更合理。

这要求系统具备风险预算机制：任何延迟停车、换道、驶离冲突区的行为，都必须证明降低了整个事件窗口内的风险积分。

4. MRM与RSS/形式化安全边界结合

形式化安全模型的价值在于给行为决策提供硬边界。MRM 中可以利用类似安全距离、路权约束、有限视距规则等机制，把“不能做什么”明确下来。学习型规划器可以在边界内寻找更自然的动作，但不能越过边界。

5. 运营闭环驱动的MRM设计

Robotaxi 或无人物流的 MRM 不能只由车端算法决定。车辆停下后，乘客怎么处理、客服怎么沟通、远程运营怎么接管、救援车怎么到达、道路管理方是否需要通知，都会反过来影响 MRC 的优劣。

算法计算的安全停车点，如果乘客无法安全下车、救援车无法到达、道路长时间阻塞，在运营层面可能并不合格。最好把车端安全和运营安全打通。

十六、常见失败模式

MRM 最危险的状态是“看起来工作”。车停了，灯亮了，日志显示触发成功，但它停在高速弯道内侧、后方车辆来不及反应、乘客不知道是否能下车、远程平台没有救援流程。这样的 MRM 只是把风险换了个形态。

十七、推荐L4 MRM工程落地框架

可以把 L4 MRM 落地拆成五条主线：

这五条主线缺一不可。只做动作库，没有能力账本，会误触发；只有能力账本，没有运营闭环，车辆停下后处理不及时；只有仿真，没有实车故障注入，会漏掉执行器和底盘层面的物理问题；只有安全 MCU，没有语义 MRM，会简化成粗暴刹停。

十八、推荐MRM决策流程

这个流程强调两件事：上层负责更聪明的 MRM，下层负责更可靠的 MRM。

十九、与功能安全、SOTIF和安全案例的关系

MRM 不是孤立功能，它处在功能安全、预期功能安全和安全案例之间。

功能安全关注随机硬件故障和系统性故障，例如传感器失效、执行器故障、计算平台异常。SOTIF 更关注系统没有坏但认知不充分，例如感知误检、长尾场景、施工区语义不清。MRM 同时承接两类风险：系统明确异常时要启动，系统没坏但“不明确剩余能力”时也要启动。

这就要求 MRM 的安全论证至少要包含以下信息：

• 触发条件是否覆盖了合理可预见的失效和 ODD 越界？
• 系统如何评估自己剩余能力足以执行哪类 MRM？
• 为什么选择该 MRM 而不是其他 MRM？
• 该 MRM 是否会制造更高的二次风险？
• 如果 MRM 执行失败，是否存在更底层兜底？
• 到达 MRC 后，车辆如何保持运营闭环，即通知外界并获得即时救援？
• 事件数据是否足以支持复盘和持续改进？（GB 44721要求的DSSAD，自动驾驶数据记录系统）

如果这些问题答不上来，MRM只是一个触发停车的功能点。

二十、结语

以往，行业追求系统能处理更多场景、开得更像人、运营范围更大。但系统成熟的标志之一是能可解释、可信地判断自己“不该再开了”。