在前面七讲里，我们反复讨论一个概念：安全状态。系统探测到故障后，进入一个“伤害风险足够低”的状态——比如制动助力失效后，驾驶员仍能用力踩下机械备份；EPS失去助力后，方向盘仍保留纯机械连接。这被称为 Fail‑Safe（故障安全） ：出故障了，系统退化成安全模式，让人类驾驶员接管。
但这句话有一个沉默的前提：车里始终坐着一位清醒、有能力、愿意接管的人类驾驶员。
到了L3级及以上自动驾驶，这个前提消失了。车辆自己开着，驾驶员可能在刷手机、打瞌睡甚至离开驾驶座。这时候如果系统说“我坏了，你来接手”，后果可能是灾难性的——人类反应不过来，或者根本不在循环内。
于是，安全状态的定义被彻底改写了：从“故障后安全停车”变成了“故障后继续运行，直到能把控制权交给一个安全的环境”。 这就是 Fail‑Operational（故障可运行） 的由来。

从Fail-Safe到Fail-Operational：一道分水岭

先厘清几个容易混淆的概念：

• Fail‑Silent（故障静默） ：探测到故障后，组件完全停止输出。适用于非安全相关或冗余架构中可被其他通道覆盖的部件。
• Fail‑Safe（故障安全） ：探测到故障后，系统进入一个预定义的安全状态，通常是降级或关闭功能，由人类接管。现阶段的L0‑L2辅助驾驶大多采用Fail‑Safe。
• Fail‑Operational（故障可运行） ：探测到故障后，系统仍能维持全部或足够长时间的基本功能，直到任务可以安全终止（例如靠边停车、到达服务区、由远程驾驶员接管）。L3及以上必须实现Fail‑Operational。

用一句话概括区别：
Fail‑Safe 回答的是“故障来了，怎么少死人”；Fail‑Operational 回答的是“故障来了，怎么还能继续开到安全的地方”。

为什么L3是分水岭？根据SAE J3016定义：

• L2及以下，驾驶员全程负责动态驾驶任务，系统只是辅助。故障发生时，驾驶员预期立即接管——虽然现实证明人类接管需要数秒甚至更长，但标准仍假设“驾驶员在场且有能力”。
• L3，系统在特定条件下承担全部驾驶任务，但要求当系统发出接管请求时，驾驶员需在足够的时间裕量内（通常几十秒）接管。然而，如果故障本身导致系统无法再安全运行几秒钟（例如感知失效、执行器卡死），它可能等不到驾驶员反应。
• L4/L5，系统根本不允许将不安全的控制权甩给人类。任何故障下，车辆必须自己完成最小风险机动（MRM，Minimal Risk Maneuver），例如变道至路肩、靠边停车。

因此，Fail‑Operational 是自动驾驶从“玩具”变成“交通工具”的硬性门槛。

典型的Fail-Operational架构模式

要实现故障后可运行，最经典的手段是冗余（Redundancy） 。但冗余的形态和粒度决定了成本和能效。下面介绍几种常见架构模式。

1. 1oo2D（一取二带诊断）

两个通道完全独立，每个通道都能独立完成全部功能。正常工作时，两者输出经过比较器——一致则执行，不一致则诊断出故障通道。任一通道故障，另一个通道仍能100%工作。

这就是Fail‑Operational的黄金范式：单个故障不会导致功能丧失。代价是成本翻倍：两套传感器、两套控制器、两套执行器……一辆L4级Robotaxi如果这样做，BOM（物料清单）会高得离谱。

2. 异构冗余 / 多样性冗余

1oo2D的两个通道如果完全相同（同型号芯片、同版本软件），可能被同一个系统性缺陷击倒（例如共因失效）。多样性冗余强制要求：不同型号的处理器（比如英飞凌+瑞萨）、不同编译器工具链、甚至不同算法的感知软件。这样，一个通道的软件bug几乎不可能同时出现在另一个通道。

3. 降级运行：3-2-1架构

全冗余成本太高，折中方案是“降级运行”：系统设计为三重冗余，单点故障后降级为双重冗余，再故障后降级为单通道——至少还能撑到安全停车。这被称作 3‑2‑1架构（3个计算单元 → 2个 → 1个最小风险单元）。典型代表：Waymo第五代自动驾驶系统配备了三套独立的计算单元，每个单元内又有锁步核。

4. 部分Fail-Operational + 部分Fail-Safe

并非所有功能都需要Fail-Operational。根据危害分析，转向和制动必须Fail-Operational——因为它们直接控制车辆运动；感知和规划可以有短暂的降级（例如切换至冗余传感器）；网联娱乐完全可以是Fail‑Silent。因此，现代自动驾驶安全架构采用“分级冗余”：核心运动控制功能全冗余，其他功能降级或静默。

执行器的Fail-Operational：线控技术的硬骨头

冗余最容易实现的是计算单元——多放几块芯片、跑几个软件实例即可。但执行器（制动、转向）的Fail-Operational要棘手得多，因为它们涉及物理能量和机械结构。

线控制动（Brake‑by‑Wire）的典型Fail-Operational方案：

• 双绕组电机：制动助力电机内有两套独立的绕组和功率晶体管。一套短路，另一套仍能提供70%以上的助力。
• 双电源：a 12V车载电池 + 备份电容或第二电池，确保主电源跌落时制动器仍能工作数次。
• 机械备份：法规要求必须保留纯液压机械链路——极端情况下，驾驶员猛踩踏板能直接推动制动主缸。这是最后的物理防线。

线控转向（Steer‑by‑Wire）的冗余设计：

• 双电机+双控制器：两个电机通过行星齿轮耦合到转向柱。一个电机坏掉，另一个可独自输出足够扭矩。
• 不同原理的转角传感器：一个磁性编码器 + 一个电感式传感器，避免共因失效。
• 机械解耦：方向盘和车轮之间没有物理连杆，因此转向系统的Fail-Operational完全依赖电气冗余。这使得线控转向的安全设计比线控制动更难。

供电与通信的“隐形”冗余

执行器和计算单元再可靠，如果电源或通信链路单点失效，一切归零。因此，完整的Fail-Operational架构必须包括：

• 冗余供电网络：双电池（12V主电池+48V隔离DC‑DC备份，或主电池+超级电容），独立配电盒。关键负载从两个电池取电，或能无缝切换。
• 冗余通信骨干：至少两条物理上独立的CAN/CAN FD或车载以太网链路，故障时自动切换。同时通信协议（如E2E、IEEE 802.1CB）支持冗余传输。

诊断覆盖率的新高度：从“检测到”到“预测到”

在传统Fail‑Safe系统中，我们接受一个事实：有些故障只有在发生后才能被检测到（比如开路、卡滞）。但对于Fail‑Operational系统，故障发生后必须还要能继续运行，这意味着系统必须在故障发生后立即识别故障位置、评估剩余能力、并动态调整控制策略。

这推动了两项技术：

(1) 故障预测与健康管理（PHM）
不是等故障发生了再反应，而是通过监测温度、电压、电流、振动等特征，预测剩余使用寿命（RUL）。例如，功率 MOSFET 的导通电阻随着老化缓慢上升，PHM算法可以在它彻底断路前几十个小时就发出警告，车队管理可以安排预防性维护。

(2) 在线自修复与重构
对于多冗余系统，故障发生后，软件需要自动重新配置资源。例如，一个六相电机控制器中，某一相功率管烧毁，系统立即将剩余五相重新配置为新的控制算法，仍然输出平滑的扭矩。这叫 故障后仍可运行的容错控制。

标准与认证的挑战

ISO 26262第二版（2018）已经部分涵盖Fail‑Operational的概念，但在一些专项上仍显不足。例如，对于随机硬件失效的PMHF目标（ASIL D要求<10⁻⁸ h⁻¹），仍然预设了“单点故障可导致安全状态进入”。但在Fail‑Operational系统中，单点故障后系统还要继续行驶一段时间，这段时间里系统暴露在“双重故障”的风险下——而双重故障概率可能比10⁻⁸高得多。

行业目前的做法是：将完整的旅程（从故障发生到最终安全停车）分解为多个阶段，对每个阶段分别计算风险。本质上要求：即使发生一个随机硬件故障，系统在剩余行驶时间内将双重故障风险保持在可接受水平内。

真实案例：某L4级Robotaxi的Fail-Operational架构

下面是一个典型的高阶自动驾驶平台安全架构摘要：

子系统	冗余方案	Fail-Operational能力
感知	3个激光雷达+8个摄像头+5个毫米波雷达，异构融合	单个传感器故障，冗余传感器覆盖，功能无降级
计算	3个独立计算单元（每单元含ASIL D安全岛），采用1oo3仲裁	一个单元故障，另外两个继续运行，性能不变
制动	双绕组电机+双电源+机械备份	单个电气故障，制动距离增加<20%，仍具备自动紧急制动
转向	双电机+双位置传感器+机械限位	单个电机故障，转向手力增加<5Nm，仍能完成变道
供电	12V主电池+48V备份DC‑DC（隔离）+ 超级电容	主电池断路，备份DC‑DC在100μs内接管，维持40秒运行
通信	双冗余环形以太网，支持802.1CB无缝冗余	任一链路断线，冗余帧自动到达，无丢包

这一整套的成本可想而知。所以目前只有Robotaxi和高端乘用车的L3/L4选装包才敢这么堆料。

结语：从“不撞”到“不会因故障而撞”

功能安全在自动驾驶时代被赋予了一个新的内涵：不再是简单的“防止电子系统乱动作”，而是要确保系统在任何单一故障下，仍有足够的能力把自己和乘客带到安全地带。这就像飞机设计中的“双发失效后还能滑翔”一样，是一种极致的安全冗余哲学。

当然，Fail‑Operational不是万能钥匙。它需要从传感器、计算、执行器到供电、通信的全链路冗余，成本高昂。但对自动驾驶来说，当人类不再手握方向盘时，这是唯一的出路。

下一篇预告：我们已经走过了从系统架构到硬件、软件、通信、操作系统的完整道路，只剩下最后一个环节——如何证明我们做的一切都是对的？第9篇《安全测试的炼狱 —— 如何证明“车不会杀人”？》将深入故障注入测试、HIL仿真、MC/DC覆盖率等验证手段，告诉你TÜV审核员是怎么审你的。

---

思考题：假设你设计一个L4级自动代客泊车系统（AVP），车辆在停车场内无人驾驶。如果执行器（转向/制动）发生单点失效但电机还能输出50%扭矩，你会采用什么策略来完成最小风险机动（MRM）？是立即刹车停在原位，还是尝试以极慢速度继续驶向空车位？为什么？