1. 课程导入
自动驾驶系统从L2辅助驾驶走向L3及以上有条件自动驾驶，最根本的工程变化不是"感知更强"或"算力更大"，而是系统必须在部分部件失效时仍然保证安全。当驾驶员不再持续监控道路，安全责任部分转移到车辆本身，计算平台就不能再是单点系统。冗余计算与故障切换工程，正是回答"当主计算通路失效时，车还能不能安全停下来"这一核心问题的技术体系。
一、核心概念：冗余、容错与故障切换
三个概念常被混用，但工程含义不同。冗余（Redundancy）指为同一功能配置额外的资源，包括硬件冗余（双SoC、双电源、双传感器）、信息冗余（多传感器交叉校验）、时间冗余（重复计算与回滚）和软件冗余（异构算法互检）。容错（Fault Tolerance）指系统在出现故障后仍能维持规定功能的能力，它依赖冗余资源与故障管理策略共同实现。故障切换（Failover）则是容错的具体动作：检测到故障后，把控制权、数据流或计算任务从失效通路迁移到备用通路。
需要特别区分三个易混术语：故障（Fault）是潜在的缺陷或异常原因，错误（Error）是故障导致的内在不正确状态，失效（Failure）是错误最终表现为系统对外功能的中断。冗余计算的目标，是在故障演化为失效之前完成检测与切换。
二、整体知识框架
本课程围绕"感知—决策—执行"全链路展开，冗余计算平台位于决策与执行之间的关键位置。下图给出课程的整体知识框架：从冗余硬件拓扑出发，经过故障检测与诊断，进入切换决策与执行，最终落到安全停车与验证闭环。
三、关键参数与工程指标
冗余计算不是"堆硬件"，而是用可量化的指标约束设计。下表列出工程中最常被追问的核心参数，它们贯穿本课程后续所有章节。
| 参数 | 含义 | 典型目标 | 影响 |
|---|---|---|---|
| 故障检测时间（FDT） | 从故障发生到被系统识别的时间 | < 100 ms | 决定切换窗口是否足够 |
| 切换时间（Failover Time） | 从确认故障到备用通路接管控制的时间 | < 200 ms | 直接影响安全停车距离 |
| 可用性（Availability） | 系统在任意时刻可正常工作的概率 | > 99.999% | 决定能否去掉驾驶员监控 |
| 共因失效（CCF） | 同一原因导致多条冗余通路同时失效 | 需专门分析 | 冗余设计的最大陷阱 |
| 安全完整性等级（ASIL） | ISO 26262 定义的功能安全等级 | ASIL D | 约束开发流程与验证深度 |
四、典型场景：一次主SoC失效的完整链路
假设车辆以 80 km/h 行驶，主SoC因过热触发降频并最终停止输出。此时系统应经历如下链路：安全MCU通过心跳超时在 60 ms 内检测到异常；交叉校验模块确认备用SoC的感知结果与主SoC最后有效帧一致；切换决策模块判定为"主通路失效、备通路可用"，触发状态迁移；备用SoC在 150 ms 内接管横向与纵向控制；系统向驾驶员发出接管请求，同时执行最小风险策略（MRM）减速靠边。整个过程若超过 500 ms，车辆在 80 km/h 下将多行驶约 11 米，可能直接决定事故是否发生。
[Fault Log 示例]
timestamp=2025-03-11T10:22:31.482Z
component=primary_soc
event=HEARTBEAT_TIMEOUT
detect_latency_ms=62
backup_state=READY
failover_triggered=true
failover_latency_ms=148
mrm_state=DECELERATING
driver_alert=HMI_TAKEOVER_REQUEST
五、常见误区与复盘要点
- 复盘要点1：故障检测是否覆盖了所有单点失效模式，包括电源、时钟、通信、内存。
- 复盘要点2：切换过程中是否存在控制空窗期，空窗期内车辆动力学是否可控。
- 复盘要点3：备用通路是否长期处于"冷备"状态，冷备切换时间往往远大于热备。
- 复盘要点4：故障注入测试是否覆盖了真实道路场景中的振动、温度与电磁干扰。
本课程后续将沿着"硬件拓扑—故障检测—切换策略—安全停车—验证闭环"这条主线逐层展开。掌握这条主线，就能在面对具体车型、具体芯片和具体法规时，快速判断冗余方案是否成立、切换逻辑是否可靠、验证是否充分。