自动驾驶的“另类”安全观
来源：公众号“焉知自动驾驶”
2021-06-29
885
最近华为ADS高阶自动驾驶首次公开试乘刷屏，我们ADS终于不是什么神秘组织了。从几年前不太拿得出手的demo，到今天成熟度还可以的产品，毫不夸张的说，每一个领域，从理念到设计，都经历过不止一次的翻天覆地的冲击和重构。今天回头看，这是锤炼一个创新产品的及其痛苦但又必须经历的过程。这个过程，迫使我们抛开所有的标准、规范，拷问自己：本质上，自动驾驶的安全风险来自于哪里？这个图直观的表达了安全风险的来源：用户预期和系统能力的偏差。
低阶自动驾驶或者说传统意义上的ADAS，大家上手一用，就知道它只能用来偶尔松松脚，不会对此有任何误解，以为它有更多的高阶功能。系统能力越低，用户期望越低，安全反倒没风险，唯一缺点是产品实用性不高。从高阶自动驾驶到无人驾驶，系统能力越高，用户期望越高，安全也没风险，唯一缺点是这样的产品还不存在。最具挑战的反而是从低阶走向高阶的过程。市面上所有的自动驾驶系统，都在这个阶段，都在争取更连续的用户体验，都在试图拔高用户预期。在这个爬坡过程中，系统的风险在不断累积。用户是很容易被系统的单点和短期能力取悦的。当系统成功闪开一个小电驴，用户会默认系统无所不能。当系统一个星期都没让人接管，司机信任会急速增长，然后开始看手机打瞌睡。用户的预期一定会比系统能力增长快的多。第一，传统的功能安全设计必不可少。
本质上，传统的功能安全设计，保证了系统能力以外的风险（灰色区域），能够被人cover。第二，避免对公共安全造成无法避开的伤害。所有人都对交通行为有预期，当自车行为在很短时间内，极大的破坏了这个预期，人是很难及时反应和规避的。虽然目的一样，对于高阶自动驾驶，这部分设计和传统ADAS也有很大的不同。但无非也只是功能安全理念在ADS这个新物种上的应用，我相信会是业界研究逐渐趋于成熟的一块，就不展开多讲了。业界常提的fail-operation，出处是为应对L3的定义：系统故障时，需要给司机预留足够的时间来接管（通常是10s）。关于这个定义的悖论，业界已经讨论的足够多，也不是这里要讨论的重点。重点是，由于SAE对L3的严苛定义，导致fail-operation几乎等同于全冗余，把冗余设计的方向全部带偏了。有趣的是，我前两天参加一个自动驾驶的讨论会，看到业界主流显而易见的共识：没有人再争论L2/L3/L4，一致把目标对准了城区、泛化场景和用户体验。那么，这是否意味着冗余设计可以彻底不考虑了呢？问题仍然出在系统能力和用户预期的gap。当用户足够信任系统，他就难以在瞬间接管系统。这是系统冗余要求的根源。但另一方面，冗余是一把双刃剑。冗余意味着成本升高、架构复杂、切换过程的无数深坑。大家可以了解一下市面上针对自动驾驶系统的复杂冗余架构，不知道这个架构是否已经落地，以我的判断，这个架构必然是失败和没有竞争力的。传统产品开发过程，是要保证“SOP”那一刻，系统能力、可靠性、安全性达到一个很高的成熟度。但自动驾驶的特点，“SOP”绝不意味着产品开发的结束。在SOP之后，系统能力仍会持续不断。这对于传统安全设计的“系统思维”，是一个颠覆性的冲击。这意味着按照传统的方法，列出所有的需求，在SOP前按V模型开发交付落地，既不现实，也无必要。“数据驱动改进“的提法在自动驾驶领域很流行，也是领域主流玩家一致认可的系统进化方向。对于安全设计来说，要应对这个趋势，一是能够在每个阶段，识别出关键的交付目标；二是数据闭环的及时性，这也是我们“Data Driven Improvement”方案要解决的问题。最后但仍然重要的一点，在系统爬坡的过程中，需要使用合理的人机交互设计，控制整体系统的风险。这也引出了最后一点，也是我认为最难的一点：通过人机交互设计，让用户预期和系统能力尽可能趋于一致。这个难点在于“用户体验”和“用户预期”之间的平衡。从用户体验角度，希望用户尽可能不受干扰，彻底解放。从产品安全的角度，又需要用户随时应对系统能力边界，做好接管的准备。这两个方面的诉求，对人机交互设计提出了非常高的要求：可能大家没有意识到，这个领域的设计难度和工作量，一点不比算法开发容易。最后，这几年总是听到大家在吐槽，传统的功能安全方法不能有效应对新技术的发展。希望能够抛砖引玉，给大家提供一些新的思路，来解这个问题。毕竟，产品的用户体验是自动驾驶赛道的关键核心竞争力，在这样一个类似马拉松比赛中，安全性同样是产品坚持到最后的保证。
