五、灰度
MRM 的状态机如果只设计成 Normal → MRM → Stop，工程上通常不够。发生问题时系统不是从健康突变至死亡，而是经历能力衰退、风险累积、可选动作逐渐变少的过程。
L4 自动驾驶的 MRM 状态机要表达的不是“系统当前在哪个模式”，而是系统对自身驾驶资格的判断过程，需要明确：
- 到达 MRC 后，是否允许恢复？由谁允许？依据是什么？
这使 MRM 状态机更像 ICU 监护，而不是软件异常处理。医生不会等病人心跳停止才处理，也不会因为一个指标轻微波动就推进抢救室。状态机的价值就在于把“轻微异常、风险升高、能力退化、必须撤离、兜底止损”分成不同等级，给每个等级匹配不同的行为权限。
5.1 不只切换模式，还管理行为权限
正常驾驶行为集合：跟车、换道、避让、绕行、无保护转弯、路口博弈、靠边上下客等。进入降级或 MRM 相关状态后，系统应逐步收缩行为集合。
关键是“行为权限收缩”。状态越靠近 MRM，允许系统做的事情越少，动作越可验证，控制越保守。MRM 状态机不是为了让车显得聪明，而是为了让车在变笨时仍然可靠。
5.2 工程例子
图里有几个关键工程细节：
Protective Driving 最容易被低估的状态。决定了 MRM 是否有空间执行。很多事故不是因为系统不会停车，而是因为系统在正常驾驶阶段开进了没有退路的位置：前方复杂、右侧不可用、后方高速逼近、车速又偏高。Protective Driving 的目的就是提前铺垫“撤离走廊”。
MRM Preparation 另一个关键状态。不应在异常瞬间就执行最终动作。合理做法是先完成候选 MRC 选择、可达性验证、后向风险评估、灯光提示、乘客提示、远程通知和控制资源预留，降低不可逆动作的失败概率。
Emergency Stop 不应当作常规 MRM。只在候选 MRC 不存在、执行路径被阻断、上层规划失效或碰撞风险快速恶化时启用。前面的风险识别和降级策略打磨的好，会避免频繁进入 Emergency Stop。
5.3 切换不只看故障码
早期系统用故障码直接驱动状态机，例如摄像头离线、定位异常、规划失败均进入 MRM。这种适合实验车阶段，不适合 L4 量产。因为同一故障在不同场景的安全含义不同。
前向摄像头短时不可用：
定位协方差升高：
因此，状态切换应由“故障严重度 + 场景风险 + 剩余能力 + 时间预算”等共同决定。可以理解成“驾驶资格评分”，问自己此刻还剩多少驾驶资格。模块故障只是扣分项，场景复杂度会放大扣分，冗余能力会抵消部分扣分，时间预算决定是否有机会撤离。
5.4 滞回，防止在边界状态抖动
工程上常见的一类问题是状态抖动。刚进入降级状态，指标稍恢复，系统又切回正常；几秒后指标再次波动，系统又重新降级。因此MRM 状态机必须设计滞回机制，进入和退出某状态不能使用同一阈值，也不能只看瞬时值。
| | |
|---|
| | 定位误差 > A 进入降级，只有 < B 才允许恢复，且 B < A |
| | |
| | |
| | 进入 MRM Preparation 后至少完成一次完整评估 |
| | |
| | |
滞回机制就像水库闸门，水位超过上限开闸，但不能水位低一点就马上关闸。
5.5 “可逆”和“不可逆”
Protective Driving 和 Degraded Driving 通常可逆，只要能力恢复、风险降低，系统可回到正常驾驶。但 MRM Execution 一旦开始，往往应该被视为半不可逆甚至不可逆。
原因在于，MRM Execution 对外部交通已经释放了强烈意图：车辆减速、靠边、打双闪、可能改变车道。此时如果取消 MRM，就会被后车、旁车、乘客和远程运营误解。若MRM 进入执行阶段，除非原动作本身变得危险，否则应优先完成MRM整套动作。
原则：准备阶段可以犹豫，执行阶段要坚定。犹豫发生在决策前，不能发生在动作已影响交通后。
5.6 恢复准入比触发更难
“什么时候可以退出 MRM”经常被忽视。实际上，恢复准入更危险。触发 MRM 是把车辆从复杂交通中撤出，恢复则是把车辆重新放回交通，重新承担风险。
完备的恢复准入机制至少应检查：
恢复策略可以分为三类：
不允许“故障码清零即恢复驾驶”，L4 需要保守的恢复过程。
5.7 状态机要与日志、安全案例绑定
MRM 状态机会是测试、事故复盘、法规沟通和安全案例的支撑。状态机需要记录每次状态切换的原因：从 Degraded Driving 进 MRM Preparation，或者为什么没有选择靠边而选择原车道停车。目标是支撑安全论证。
每次切换应记录的结构化信息：
| |
|---|
| Degraded Driving → MRM Preparation |
| |
| |
| |
| |
| |
| |
| |
| |
从而实现系统可学习。没有结构化日志，MRM 事件就只能靠人工看视频猜；有了结构化日志，才能统计误触发、漏触发、候选 MRC 失败原因和状态机抖动问题。
5.8 状态机安全边界：上层聪明，下层可靠
L4 MRM 状态机通常不只存在于 SoC 。SoC 可以维护复杂状态机，结合场景语义做精细化判断；MCU 或安全控制器则应维护一个简化但独立的安全状态机，用于处理 SoC 卡死、心跳丢失、通信异常、电源异常等情况。
设计关键是可靠性。SoC 状态机能够区分路口、隧道、施工区、路肩可用性；而MCU 状态机必须足够简单，能够在上层失效时完成基础制动、灯光、驻车和执行器安全控制。
5.9 典型设计陷阱
5.10 逐渐变保守
MRM 状态机的目标不是让系统在异常时立即停车，而是让系统随能力下降逐渐变保守。轻微异常时，扩大/增加安全约束；能力下降时，缩减可选行为集合；撤离开始后，完整执行；停稳之后，谨慎恢复。
灰度机制是 L4 MRM 与简单故障停车之间的分水岭。
10个月宝宝每天需要喝多少奶粉？
