自动驾驶的“另类”安全观
来源:公众号“焉知自动驾驶”
2021-06-29
913
最近华为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”方案要解决的问题。最后但仍然重要的一点,在系统爬坡的过程中,需要使用合理的人机交互设计,控制整体系统的风险。这也引出了最后一点,也是我认为最难的一点:通过人机交互设计,让用户预期和系统能力尽可能趋于一致。这个难点在于“用户体验”和“用户预期”之间的平衡。从用户体验角度,希望用户尽可能不受干扰,彻底解放。从产品安全的角度,又需要用户随时应对系统能力边界,做好接管的准备。这两个方面的诉求,对人机交互设计提出了非常高的要求:可能大家没有意识到,这个领域的设计难度和工作量,一点不比算法开发容易。最后,这几年总是听到大家在吐槽,传统的功能安全方法不能有效应对新技术的发展。希望能够抛砖引玉,给大家提供一些新的思路,来解这个问题。毕竟,产品的用户体验是自动驾驶赛道的关键核心竞争力,在这样一个类似马拉松比赛中,安全性同样是产品坚持到最后的保证。