最近，我们的自动驾驶仪登场了，ADS不再是一个神秘的组织。从几年前还不太好的demo，到今天还不算太成熟的产品，毫不夸张地说，每一个领域，从概念到设计，都不止一次经历过翻天覆地的冲击和重构。今天回过头来看，这是一个极其痛苦但又必不可少的锤炼一个创新产品的过程。安全领域也不例外。这个过程迫使我们抛开所有的标准和规范，扪心自问：从本质上讲，自动驾驶的安全风险从何而来？我觉得这张图大概表达了我们的理解：这张图直观的表达了安全风险的来源：用户期望和系统能力之间的偏差。低端的传统ADAS，用过一次就知道只能偶尔放松一下，不会有误以为它有更高级的功能。系统能力低，用户期望低，安全性好。问题是产品没用。从高端到无人驾驶，系统能力高，用户期望高，安全上没有问题。问题是这样的产品还不存在。问题是从最低点到最高点。市面上所有的自动驾驶系统都处于这个阶段，力求更持续的用户体验，并试图提高用户的期望值。系统性风险也在这个攀升过程中积累。用户很容易对系统的单点和短期能力感到满意。当系统成功越狱小电驴后，用户将默认系统的无所不能。当系统一周没有被接管时，司机的信任度会急剧上升，然后就会开始看手机打瞌睡。用户期望的增长速度必须远远超过系统能力的增长速度。我们的考虑和出发点都是为了弥合这个差距。首先，传统的功能安全设计必不可少。从本质上讲，传统的功能安全设计确保了系统能力之外的风险（灰色区域）可以被其他人覆盖。具体来说，它保证了两件事：第一，司机可以随时接管。第二，避免对公共安全造成无法避免的危害。每个人对交通行为都有预期，而当汽车的行为在短时间内极大地破坏了这种预期时，人们就很难及时做出反应和规避。虽然目的相同，但对于高级别自动驾驶来说，这部分设计也与传统ADAS有很大区别。但无非是将功能安全理念应用到ADS这个新物种上。相信会是一块逐渐成熟的行业研究，就不多说了。二、适当的核心冗余业界经常提到的fail-operation来自L3的定义：当系统发生故障时，需要预留足够的时间让driver接管（通常为10s）。这个定义的悖论在业界已经讨论得够多了，这里不是讨论的重点。关键是由于SAE对L3的严格定义，fail-operation几乎等同于fullredundancy，完全背离了冗余设计的方向。有意思的是，前两天参加了一个自动驾驶的研讨会，看到主流行业有一个明显的共识：L2/L3/L4没有人在争论，都聚焦在市区、泛化场景和用户体验上。那么，这是否意味着可以完全忽略冗余设计呢？问题还是出在系统能力和用户预期之间的差距。当用户足够信任系统时，他很难瞬间接管系统。这就是系统冗余需求的来源。但另一方面，冗余是一把双刃剑。冗余意味着成本增加，架构复杂，切换过程中坑数不胜数。使用下图，您可以了解一个主要OEM自动驾驶系统的冗余架构。不知道这个架构是否已经落地。以我的判断，这个架构一定是失败的，没有竞争力的。第三，重新定义“系统交付”的传统产品开发流程，确保系统能力、可靠性、安全性在“SOP”时刻达到高度成熟。但针对自动驾驶的特性，“SOP”绝非产品开发的终点。系统能力不断攀升的过程，甚至很大程度上发生在SOP之后。这是对传统安全设计“系统思维”的颠覆性影响。这意味着按照传统的方法，在SOP之前，把所有的需求都罗列出来，按照V模型开发交付，既不现实也没有必要。“数据驱动改进”这个词在自动驾驶领域非常流行，也是该领域主流玩家一致认可的系统演进方向。对于安全设计，要应对这一趋势，一个是能够确定每个阶段的关键交付目标。同时，数据闭环的时效性非常重要，这也是我们“数据驱动改进”解决方案要解决的问题。还有一点不容忽视的是，在系统爬升的过程中，需要通过合理的人机交互设计来控制整个系统的风险。这也就引出了最后一点，也是我认为最难的一点：通过人机交互设计，让用户的期望和系统能力尽可能保持一致。难点在于“用户体验”和“用户期望”之间的平衡。从用户体验的角度，我们希望用户尽可能不受干扰，彻底解放。从产品安全的角度，用户需要随时处理系统能力的边界，做好接管的准备。这两方面的诉求对人机交互设计提出了非常高的要求：没有必要的时候，尽量不要打扰用户；提醒尽可能准确直观；基于系统能力的演进，不断调整和进化人机交互。..你可能没有意识到，这个领域的设计难度和工作量并不比算法开发容易。最后，在过去的几年里，我总是听到人们抱怨传统的功能安全方法无法有效应对新技术的发展。希望能够抛砖引玉，为大家提供一些解决这个问题的新思路。毕竟产品的用户体验是自动驾驶赛道最关键的核心竞争力，而安全也是这条马拉松赛道笑到最后的保证。
