自动驾驶真正的安全瓶颈，到底卡在哪？——不是算法，而是“系统安全闭环”

过去几年，自动驾驶的讨论高度集中在：

算法行不行

感知准不准

算力够不够

但在真实项目和事故复盘中，行业越来越清楚地看到一个事实：自动驾驶的安全瓶颈，并不在“能不能跑”，而在“出问题时怎么办”。

这是一个系统安全问题，而不是单点技术问题。

一、先给结论：三大核心瓶颈

如果用一句话概括：

自动驾驶的安全，真正卡在“系统无法证明自己是安全的”。

具体拆解，主要集中在三大瓶颈：

1️⃣ 失效模式无限，但工程能力有限
2️⃣ 人机交互是最薄弱的安全环节
3️⃣ 缺乏“运行中安全”的闭环能力

下面逐一展开。

二、瓶颈一：系统复杂性已超过人类“想象极限”

1️⃣ 自动驾驶的失效不是“坏一个零件”

在传统功能安全中，我们习惯于：

一个传感器坏了

一个 ECU 重启

一条 CAN 通信丢失

这些是离散、可枚举的故障。

但自动驾驶系统的失效往往是：

多源感知在边界条件下“同时偏差”

算法在罕见场景中形成错误闭环

系统整体行为偏离预期，但没有明显“故障点”

这是“系统性失效”，而不是器件级失效。

2️⃣ 失效模式数量呈指数级增长

自动驾驶系统通常包含：

多传感器融合

高度耦合的软件栈

动态决策与控制闭环

结果是：

系统状态空间，远超人工分析能力。

这直接导致：

FMEA、FTA 覆盖能力下降

HAZOP 依赖经验，无法穷举

很多“危险路径”事前无法被识别

我们不是不知道风险，而是不知道“还有多少不知道的风险”。

三、瓶颈二：人机交互（HMI）是最大的“安全黑洞”

这是行业内最容易被低估、但事故占比极高的一点。

1️⃣ 当前系统严重依赖“人类作为安全冗余”

在 L2/L3 阶段，普遍假设：

系统不行时，人可以接管。

但从安全工程角度看，这是一个问题重重的假设。

人不是实时监控系统

人的注意力不可验证

人的响应时间不稳定

“人”是一个无法被安全验证的组件。

2️⃣ 接管请求 ≠ 接管成功

在很多事故中可以看到：

系统发出了接管提示

人也看到了提示

但并没有形成有效控制

原因包括：

驾驶员不知道为什么接管

对当前风险严重性缺乏认知

接管时系统状态不可预期

从功能安全角度看：这不是“提示问题”，而是“安全机制失效”。

3️⃣ 人机交互缺乏可验证性

在 ISO 26262 体系中，安全机制需要：

可定义

可验证

可确认

但“人是否会正确接管”：

无法设计冗余

无法验证覆盖率

无法量化失效概率

这使得 HMI 成为整个系统中最不安全的一环。

四、瓶颈三：缺乏“运行中安全”的系统闭环

这是目前自动驾驶安全最核心、也最难突破的地方。

1️⃣ 多数安全分析是“设计时”的

当前主流安全工作集中在：

设计阶段分析风险

定义安全目标

设计安全架构

但现实世界是：

危险往往发生在“设计之外”。

极端天气

罕见交通行为

系统老化、偏移、组合效应

2️⃣ ODD 边界在现实中是“模糊的”

理论上：

在 ODD 内运行

超出 ODD 退出

现实中：

ODD 是连续变化的

边界不可精确感知

系统往往“以为还在 ODD 内”

很多事故不是“超出能力”，而是“不知道自己已经超出了能力”。

3️⃣ 缺乏实时“安全自知能力”

真正的安全系统应该具备：

对自身能力的实时评估

对风险趋势的提前感知

对失控风险的主动降级

但目前大多数系统：

更擅长“继续跑”

不擅长“及时停”

不会停，比不会跑更危险。

五、为什么“通过标准”≠“真的安全”

这是很多管理层容易产生错觉的地方。

通过 ISO 26262

做了 SOTIF 分析

有完整文档

但这些更多意味着：

你在“已知范围内”是合规的。

而自动驾驶的风险恰恰集中在：

未知场景

系统耦合

动态演化

安全不是一个“交付物”，而是一种持续能力。

六、真正的突破方向在哪里？

从专业角度看，行业正在逐步形成共识：

1️⃣ 从“设计安全”走向“运行安全”

在线监控

动态风险评估

主动降级策略

2️⃣ 从“人兜底”走向“系统自兜底”

最小风险状态（MRC）

自主退出策略

清晰的责任边界

3️⃣ 从“功能正确”走向“行为可解释”

安全约束的决策层

可验证的行为边界

安全优先于效率

七、总结

自动驾驶真正的安全瓶颈，不是“它够不够聪明”，而是“它在不聪明的时候，是否知道该停下来”。