未来的智能汽车在安全上的突破

未来的智能汽车在安全上的突破

但是，除了给驾驶员带来便利以外，智能汽车更核心的愿景是减少交通事故，为人类创造更美好的生活。如果解放了驾驶员的同时却不能保证驾驶员的安全，个人认为智能汽车上的黑科技更多的是锦上添花，而没有大规模推广的意义。

未来的智能汽车在安全上的突破，就是找到这三个方向在汽车上落地量产的可行性方案。而这三个方向的落地之难，从某种程度上也折射出智能驾驶距离终极目标的距离还很远。本文将对这三个方向的内容以及发展现状做简单介绍，尝试回答落地难在何处，希望给读者们带来一些有价值的参考。

1. 功能安全 （Functional Safety）

1.1. 什么是功能安全？

ISO 26262中对功能安全的定义为：

ISO 26262：absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.（不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险）

简而言之，功能安全聚焦系统故障后怎么做。危害有很多类型，如人身伤害或者财产损失等等。功能安全所关注的危害指对驾驶员或者路人或周边车辆内人员（注意：不仅仅是驾驶员）造成的健康伤害。换句话说，功能安全开发目的是避免伤人。

功能安全的定义中有一个关键词“unreasonable”，即“不可被接受的”。就像世界上没有永动机一样，世界上也没有100%安全的系统，因此功能安全追求的是将危害控制在可被接受的范围。而是否可被接受，需要从两个维度去衡量：危害的严重性和危害发生的频率。举例来说，飞机失事几乎无人生还，但是正因为飞机失事的概率非常低，所以不影响它成为最重要的交通工具之一；电动车窗发生卡滞故障的频率比较高，但是故障不会让人受伤，因此很多司机甚至只有等到下个月去4S店时才想起来维修它。但是，如果你的车突然在高速上自动加速，估计你马上停在紧急带，惊魂未定便马上打电话给4S店喊着要退车了，因为这种原本可以通过设计规避的故障是不可接受的。这也正是功能安全开发期望避免的故障。

1.2. 功能安全的发展现状

但是，随着更高阶的自动驾驶的开发思路越来越清晰，功能安全也渐露窘色。

相比较辅助驾驶，自动驾驶最大的难点在于系统在出现故障之后，需要系统来自己操作避免事故（自动驾驶等级越高，驾驶员可以越晚介入接管甚至是完全不用接管），出了事故是厂家的责任而不是驾驶员的责任。

故障发生后，系统从报警变成了继续进行安全控制，可以预见，功能安全的开发难度以及功能安全对系统架构的要求都产生了质的改变。汽车实现自动驾驶实际上和已经实现了自动驾驶的飞机的设计思路类似。飞机的自动驾驶是怎么保证的呢？除了尽可能保证零部件可靠性之外，飞机会有两个发动机，保证在一个发动机故障以后另一个仍能保证安全飞行。这就是“冗余设计”的概念。冗余设计在飞机上到处可见，比如两个独立运行的计算机系统，两套独立的供电系统等等。

回到汽车自动驾驶上，同样对关键部件采用冗余设计，保证当故障发生后备份系统仍能保证车辆正常运行。可以预见的是，自动驾驶的大脑控制系统、制动系统、转向系统、供电系统等都需要冗余。

但是，冗余一方面意味着部件数量增加，成本上升；另一方面，功能安全中会对系统故障可能导致的危害事件进行分级，简单来说从ASIL A到ASIL D危害程度逐渐升高。那么开发要求也逐渐升高。比如单就硬件开发而言，ASIL D对单点故障度量（SPFM, signal point fault metrics）、潜在故障度量(LFM, Latent fault metrics)等的指标要求近乎苛刻。

ISO 26262对不同ASIL等级的硬件开发指标

而对于需要冗余的制动系统、转向系统、大脑控制系统等而言，它们的失效都会引起一些ASIL D的危害事件，换句话说，这些系统的开发需求中至少有一部分是有最严苛的ASIL D要求的。如今两套冗余都需要满足这些要求，无疑增加了开发难度和开发成本。

但是汽车开发又不得不面对这样的现实：和飞机不同，汽车的利润比飞机的利润低得多，全靠走量，如果不计成本，那么即使实现了安全系数很高的自动驾驶系统，也会因为价格过高而不被市场认可。如何在功能和安全之间找到平衡，是功能安全在自动驾驶汽车上面临的挑战之一，也是未来在智能驾驶汽车上真正落地功能安全的关键。

2. 预期功能安全 （SOTIF, Safety of the Intended Functionality）

2.1. 什么是SOTIF?

在回答这个问题之前，先问一个问题：就算不计成本地保证了智能驾驶系统的功能安全，这个系统是否就足够安全了呢？

我们不妨先来看一个召回的案例。

因此，这次召回不是因为系统故障导致的，而是传感器本身的功能局限导致的。ISO 26262功能安全旨在避免电子电气系统故障导致功能异常而引起的不合理的危害，功能受限ISO 26262的范畴。为弥补功能安全的局限，预期功能安全SOTIF (Safety of the Intended Functionality)以及标准ISO 21448便诞生了。

简单来说，SOTIF强调的是避免因为预期的功能表现局限而导致不合理的风险。

而从另一个维度，“功能表现”可以概括为4类： （1）在危险场景介入 （正常工作） （2）在非危险场景介入 （误触发） （3）在危险场景不介入 （漏触发） （4）在非危险场景不介入（正常关闭）

第1种和第4种情况没有危害，而其余两种则有危害，也正是SOTIF关注的危害。要有效避免误触发和漏触发，第一步是识别场景并进行分类，确定哪些场景下功能触发是安全的，而哪些场景下功能不触发是安全的。在OTIF将所有的场景划分成下图所示四个部分，且目标为：最大可能减小Area2 (known unsafe scenarios) 和Area3 (unknown unsafe scenarios) 的范围。

图片来自ISO 21448

2.2. SOTIF的发展现状

目前SOTIF的标准ISO 21448还是draft版本，按照计划在2022年3月正式发布。目前对于一些关键问题仍然存在争议，这也是ISO 21448迟迟没有发布的重要原因。

ISO 21448计划表

举例来说，而对于Area3(unknown unsafe scenarios)，处理起来则相对棘手很多。举个例子，这就好比我们在开发一辆将来投放在中国市场的车，需要在开发初期事先识别出一辆车在中国路况下可能会碰到的各种场景。我想即使让全世界顶尖的安全专家坐一起产出也极其有限。

SOTIF对降低Area3，大体思路如下：

（1）提高系统和零部件功能的可信度。

（2）endurance run。

积累实车路试和仿真测试数据是一件耗时耗力耗材的大规模工程。这无疑又给智能驾驶的安全开发增加了成本，另外，搭建可信度高的仿真测试平台也需要巨额成本，成本因素会给SOTIF的推广带来比较大的挑战。另一方面，ISO 26262从诞生到被行业普遍认可用并较为熟练运用经历了9年，SOTI又会如何目前仍是一个问号。

3. 信息安全 （Cyber Security）

3.1. 什么是信息安全？

功能安全和SOTIF研究的对象是智能驾驶系统自身可能产生的失效，还有另一类失效也是未来智能驾驶不可忽略的——黑客攻击。

为了应对这一种情况，已经在互联网领域发展很成熟的信息安全正在被运用到汽车开发中。智能驾驶的智能化程度越高，可能被黑客攻击的点就越多，对信息安全的需求量更大。

这里需要强调一点，功能安全和SOTIF以人身安全为核心，但是不是所有的信息安全问题都会导致人身安全。换句话说，信息安全除了要考虑人身安全以外，还需要考虑黑客攻击带来的其他风险，比如车辆被偷导致的财产损失以及隐私泄露风险。

3.2. 信息安全的发展现状

对于该标准如何落地，业界尚在摸索中。于此同时，信息安全既然也包括了对人身伤害的预防，那么必然和功能安全以及SOTIF有交集，如何将三者的开发有机联系起来目前还没有成熟的方案，这也是亟需解决的关键问题。

4. 结论和展望

通过上面的介绍可以看到，要保证智能汽车的安全性任重道远。希望大家在重视智能汽车便利性的同时，也更多的关注智能汽车的安全性。毕竟安全是智能汽车的核心。只有建立在安全的基础上，其他的技术才可以称之为锦上添花而不是鸡肋。

当然，我们也可以看到，在经历了初期的狂热后，工程思维的理智慢慢将行业拉回脚踏实地的轨道。如今安全越来越受到汽车行业的重视，一大批工程师正在为智能驾驶的安全而努力，相信在未来足够安全的智能汽车将“飞入寻常百姓家”，造福人类。