导 读

最近我们的自动驾驶首发刷屏，ADS终于不是什么神秘组织了。从几年前不太拿得出手的demo，到今天的成熟度还可以的产品，毫不夸张的说，每一个领域，从理念到设计，都经历过不止一次的翻天覆地的冲击和重构。今天回头看，这是锤炼一个创新产品的及其痛苦但又必须经历的过程。

安全领域也不例外。

正文

这个过程，迫使我们抛开所有的标准、规范，拷问自己：本质上，自动驾驶的安全风险来自于哪里？

我想，这个图大致表达了我们的认识：

这个图直观的表达了安全风险的来源：用户预期和系统能力的偏差。

低阶传统ADAS，大家上手一用，就知道它只能用来偶尔松松脚，不会有任何误解，以为它有更多的高阶功能。系统能力low，用户期望low，安全反倒没毛病。毛病是产品没啥用。

高阶到无人驾驶，系统能力high，用户期望high，安全也没毛病，毛病是这样的产品还不存在。

麻烦的是从最低点走到最高点的过程。市面上所有的自动驾驶系统，都在这个阶段，都在争取更连续的用户体验，都在试图拔高用户预期。系统的风险也累积在在这个爬坡的过程中。

用户是很容易被系统的单点和短期能力取悦的。当系统成功闪开一个小电驴，用户会默认系统无所不能。当系统一个星期都没让人接管，司机信任会急剧增长，然后开始看手机打瞌睡。用户的预期一定会比系统能力增长快的多。

我们的考量，出发点都在弥合这个gap。

首先，传统的功能安全设计必不可少

本质上，传统的功能安全设计，保证了系统能力以外的风险（灰色区域），能够被人cover。

具体来说，它在保证两件事情：第一，司机能够在任何时候接管。第二，避免对公共安全造成无法避开的伤害。所有人都对交通行为有预期，当自车行为在很短时间内，极大的破坏了这个预期，人是很难及时反应和规避的。

虽然目的一样，对于高阶自动驾驶，这部分设计和传统ADAS也有很大的不同。但无非也只是功能安全理念在ADS这个新物种上的应用，我相信会是业界研究逐渐趋于成熟的一块，就不展开多讲了。

第二，恰到好处的核心冗余

业界常提的fail-operation，出处是为应对L3的定义：系统故障时，需要给司机预留足够的时间来接管（通常是10s）。关于这个定义的悖论，业界已经讨论的足够多，也不是这里要讨论的重点。重点是，由于SAE对L3的严苛定义，导致fail-operation几乎等同于全冗余，把冗余设计的方向全部带偏了。

有趣的是，我前两天参加一个自动驾驶的讨论会，看到业界主流显而易见的共识：没有人再争论L2/L3/L4，一致把目标对准了城区、泛化场景和用户体验。那么，这是否意味着冗余设计可以彻底不考虑了呢？

问题仍然出在系统能力和用户预期的gap。当用户足够信任系统，他就难以在瞬间接管系统。这是系统冗余要求的根源。

但另一方面，冗余是一把双刃剑。冗余意味着成本升高、架构复杂、切换过程的无数深坑。用下面这个图，大家可以围观一下某大厂OEM针对自动驾驶系统的冗余架构。不知道这个架构是否已经落地了，我的判断，这个架构必然是失败和没有竞争力的。

第三，重新定义“系统交付”

传统产品开发过程，是要保证“SOP”那一刻，系统能力、可靠性、安全性达到一个很高的成熟度。但自动驾驶的特点，“SOP”绝不意味着产品开发的结束。系统能力不断爬坡的过程，甚至很大程度发生在SOP之后。这对于传统安全设计的“系统思维”，是一个颠覆性的冲击。这意味着按照传统的方法，列出所有的需求，在SOP前按V模型开发交付落地，既不现实，也无必要。

“数据驱动改进“的提法在自动驾驶领域很流行，也是领域主流玩家一致认可的系统进化方向。对于安全设计来说，要应对这个趋势，一是能够在每个阶段，识别出关键的交付目标。同时，数据闭环的及时性相当重要，这也是我们“Data Driven Improvement”方案要解决的问题。还有一点决不可忽视，在系统爬坡的过程中，需要使用合理的人机交互设计，控制整体系统的风险。

这也引出了最后一点，也是我认为最难的一点：通过人机交互设计，让用户预期和系统能力尽可能趋于一致。

这个难点在于“用户体验”和“用户预期”之间的平衡。从用户体验角度，希望用户尽可能不受干扰，彻底解放。从产品安全的角度，又需要用户随时应对系统能力边界，做好接管的准备。这两个方面的诉求，对人机交互设计提出了非常高的要求：非必要的时候，尽可能不干扰用户；提醒尽可能精准和直观；基于系统能力演进，不断调整和进化人机交互。。。可能大家没有意识到，这个领域的设计难度和工作量，一点不比算法开发容易。

最后，这几年总是听到大家在吐槽，传统的功能安全方法不能有效应对新技术的发展。希望能够抛砖引玉，给大家提供一些新的思路，来解这个问题。毕竟，产品的用户体验是自动驾驶赛道的关键核心竞争力，安全性同样是这个马拉松赛道上，笑到最后的保证。