行家来信 | 功能安全会成为自动驾驶的紧箍咒吗？

量子位的朋友们 2019-09-21 12:34:52 来源：量子位

编者按：很快，我们就能够坐上无人车了。但我们怎么保证无人车能够安全驾驶？这背后需要考量什么？我们应该关注什么？

本期行家来信来自禾多科技研发总监李文俊，基于对ISO26262和ISO21448两个功能安全标准和冗余机制的梳理与讨论。

他回答了功能安全在自动驾驶技术发展中扮演的角色，希望能够为你带来启发。

以下为文章全文：

近年来自动驾驶相关的技术迅猛发展，自动驾驶成为交通运输发展的下一个重要阶段。

许多公司研发的自动驾驶方案可以在简单的环境条件下实现车辆的自动驾驶功能，但如果将这些自动驾驶车辆投放应用到真实的公共场景中，还有很长的路要走。

最重要的制约因素之一，就是安全性的问题。

自动驾驶的发展初衷就是为了提高车辆行驶的安全性，减少事故的发生。

有研究报告指出，人们对自动驾驶的安全性期望非常高。有数据显示：相较于一个正常的人类司机，人们对自动驾驶的安全性要求至少高4至5倍。

为了实现高安全性，我们在自动驾驶技术开发过程中，明确提出要满足功能安全的要求，其中之一就是需要满足ISO26262功能安全标准。

ISO26262

ISO26262，概括来说就是对整车电子电气系统的功能安全规范，为了确保即使发生失效情况也能保证整车的安全性。

ISO26262的规范指导文档长达几百页、数十个章节，对车辆电子电气系统开发过程中的概念设计、系统设计、软硬件设计、测试验证、确认评估等环节均作出了规定和指导。

同时也引入了诸如HAZOP、HARA、FMEA、FTA、FMEDA等一系列安全分析方法。最最重要的是，ISO26262会引入非常多的额外工作内容和条件限制，包括上面讲到的对应各种安全分析方法的工作以及一些文档工作。

举个例子：系统的故障树分析-FTA(Fault Tree Analyze)是功能安全里面几乎必实施的一个工作内容。具体来讲就是对系统中的某个安全目标(Safety Goal)进行自上而下的分析，层层拆分，直到分析到某个简单的功能是否失效。

比如为保障电源的供给，要一直分析到一个电阻是否失效。面对自动驾驶这样一个庞大的系统，如果要做整套的FTA，那么工作量无疑是巨大的。

不过从目前看来，自动驾驶的功能安全体系如何建立还没有公开的统一标准，业界也有越来越多声音认为：仅ISO26262这一标准，不能满足自动驾驶功能安全的需求。

ISO21448(SOTIF)

ISO26262覆盖的功能安全范围，是在车辆电子电气系统出现失效的情况下。在ISO26262的基础上，人们提出了另一套标准——ISO21448(SOTIF)，也被称为“预期功能安全”。

SOTIF (Safety of the Intended Functionality) 考虑的是系统预期的功能安全性。

ISO26262只包括整车电子电气(E/E)系统失效情况下的功能安全，但是自动驾驶的功能安全往往不仅仅和电子电气系统有关，还关系到非常多的其他要素，比如相关传感器自身性能的限制，车辆行驶环境的变化等等。

SOTIF考虑的情况便是在系统没有出现任何失效的情况下，由于系统功能不足所导致的危害，比如传感器无法正确识别道路场景。

ISO21448(SOTIF)的前身其实是ISO26262中的第14个章节，但随着ADAS的普及与自动驾驶技术的发展，人们发现在没有系统失效的情况下保证功能安全是一件非常复杂的事情，便将其单独作为一个新的标准发布。

例如，当一辆自动驾驶车辆行驶在结冰的路面上。

ISO26262负责当车辆刹车系统出现失效的情况时，车辆能保证在冰面上不打滑地安全停车。

而SOTIF所要解决的问题是车辆在没有任何问题的前提下在冰面上行驶时，是否应该保持和正常路面行驶一样的速度，因为在冰面上高速行驶有可能达到了车辆的安全边界。

SOTIF的作用之一，是减少未知的安全性风险。这个定义非常宽泛，而且难以证明其是否考虑到了所有存在潜在风险的安全边界。

因需要考虑的情况太过复杂，目前SOTIF还没有一个正式的版本诞生，只有草案。

冗余机制

另一个功能安全经常涉及的概念是冗余机制。

系统的冗余大家经常谈论，最简单的设计是将系统中所有的模块都做冗余备份，一旦一个系统出现失效，另一个系统便会接管车辆的操作。

但是这往往要在成本、系统的复杂度、鲁棒性和冗余上做出相对的平衡，因此不能做到完全的系统冗余备份。

在L2级别以下的辅助驾驶功能中往往不会要求系统的冗余，或者换一个说法，在这一类的辅助驾驶中，人类驾驶员就是系统最好的冗余备份。

因为在辅助驾驶功能工作时，驾驶员的注意力依然要时刻保持在车辆上。一旦上升到了L3级别的自动驾驶系统，冗余的设计就显得非常有必要了。

因为在L3级别的自动驾驶系统中，已经允许驾驶员的手长时间脱离方向盘，也不用时刻观察注意道路状况。所以从系统出现失效，到驾驶员反应过来去接管控制，是存在一定时间间隔的。

在这段时间间隔内，系统要确保车辆的安全性，需要做到某一个单元失效的情况下，启动冗余备份以保证车辆的安全。

整个自动驾驶系统的冗余机制又可以细分为以下几类：

• 电源的冗余：顾名思义，是指系统中关键模块的供电需要有冗余的设计，以防单点的电源失效造成事故。
• 执行机构的冗余：指的是车辆执行机构的冗余，如刹车、转向等。任何一个机构都可以独立的完成车辆的制动动作。像我们熟知的Bosch，在制动机构方面的冗余设计就是由iBooster和ESC/ESP构成的。
• 传感器的冗余：自动驾驶不能仅依靠某一类传感器来实现功能，既需要多种传感器的特性冗余，比如毫米波雷达的测速性和激光雷达的准确性，也需要检测范围内多种传感器的检测冗余，比如车辆行驶前方往往会有激光雷达、视觉和毫米波雷达的冗余检测。所以在自动驾驶系统中，这种冗余设计常常被提及和采用。
• 计算单元的冗余 : 如果说把执行机构形容为自动驾驶的四肢，传感器形容为自动驾驶的眼睛，那么计算单元就相当于自动驾驶的大脑。计算单元的冗余也往往是功能安全里所要求的。在Tesla最新的Autopilot域控制器上就采用了两块Tesla FSD，两颗处理器互相独立，即便一个出现问题，另一个也能照常执行。

为了满足功能安全的要求，除了上述提到的，要做的工作还很多。这些工作看似和自动驾驶的功能开发没有什么特别强的相关性，从某种角度来说，甚至会限制自动驾驶的功能开发。

如果把自动驾驶比喻成本领强大的孙悟空，功能安全可谓是孙悟空头上的紧箍咒，时时刻刻限制着孙悟空的发挥。

但从另一方面讲，孙悟空的任务是保护唐僧安全取得真经，就如自动驾驶的首要任务也是要保障乘客的安全。

受控于紧箍咒的限制，孙悟空不会做出出格的行为，而自动驾驶在功能安全的限制下，也会变得越来越安全，能更好地为乘客服务。