从安全的角度看自动驾驶

作者 / 浪迹天涯
出品 / 焉知

站在2020年年尾回看智能驾驶，这一年黑科技层出不穷，无疑是一片琳琅满目的壮观景象：超大的显示屏娱乐功能强大、智能座舱高度数字化、OTA远程升级几乎是新车型标配、ADAS辅助驾驶功能也越来越丰富和实用......至于智能驾驶的终极目标——无人驾驶，在市场的狂热逐渐退烧后，各大厂家重新制定了自动驾驶计划。智能汽车正在朝着便利和解放驾驶员的方向上狂奔。

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

支撑所有智能驾驶技术的是全新的电子电器系统，而电子电器系统的基本组成是软件和硬件。从这个角度，智能驾驶的安全就是软件和硬件的安全。为了让软件和硬件足够安全，无数的汽车工程师正在行动，并在探索与合作的过程中逐步达成了共识，至少要从三个方面去保证安全：

功能安全 （Functional Safety）
预期功能安全（Safety of the Intended Functionality）
信息安全 （Cyber Security）

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

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. 功能安全的发展现状

相对于预期功能安全和信息安全，功能安全的发展是最成熟的。自2011年功能安全标准ISO 26262正式发布以来，已经过去了快10年。这这段时间里，在汽车智能化高速发展的驱动下，功能安全越来越被汽车行业接受，国内外各大主流汽车企业陆陆续续将ISO 26262的需求融入自己的研发体系和流程中，以保证安全能跟上电子电器系统快速变革的步伐，保证辅助驾驶功能不仅好用而且安全。借着这股东风，ISO 26262一路“平步青云”，功能安全俨然成为了汽车研发的新兴热门话题。

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

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

这正是为什么之前特斯拉被告虚假宣传，从而不得不将其宣称的“自动驾驶”改成“增强版辅助驾驶”的原因。因为特斯拉的Autopilot功能正常工作的时候，表现得确实是无人驾驶，而一旦出现异常，却是由驾驶员来担责。

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

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

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

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

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

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

2.1. 什么是SOTIF?

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

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

2020年3月19日，由于自动紧急制动系统（Autonomous Emergency Braking, AEB）存在故障，沃尔沃汽车宣布在全球范围内召回汽车近74万辆，共涉及9款在售车型。此次召回的原因，是因为一些场景下无法有效识别物体，导致AEB在该工作的时候不工作。一般AEB探测物体依赖传感器毫米波雷达和摄像头两个关键传感器的信息融合。因为多普勒效应，毫米波雷达不擅长识别静态物体；而摄像头在雾天或者光线不足等情况下探测度都会降低，这些因素都会导致在一些场景下无法正确识别物体从而激活AEB。

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

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

因为SOTIF诞生的背景是智能驾驶的发展，所以如果按照智能驾驶的功能链：感知——决策——执行来归类，“功能表现局限”体现在3个方面：
（1）传感器感知局限导致场景识别错误
（2）深度学习不够导致决策算法判断场景错误
（3）执行器功能局限导致与理想目标偏差

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

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

2.2. SOTIF的发展现状

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

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

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

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

Validation: set of activities ensuring and gaining confidence that a system is able to accomplish its intended use, goals, and objectives

Note to entry: ......Validation activities address mainly "area 3" of figure 7 including the validation of SOTIF in unknown use cases."

（2）endurance run。

概括来说就是通过实车路试和仿真测试积累大数据。当数据积累越多，越能够将unknown scenarios变成known scenarios。

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

3. 信息安全 （Cyber Security）

3.1. 什么是信息安全？

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

2015年7月，两名美国白帽黑客成功侵入一辆正在行驶的JEEP自由光SUV的CAN总线网络系统，向发动机、变速箱、制动、转向等系统发送错误指令，最终使这辆车开翻到马路边的斜坡下。这起案件导致吉普大规模召回。

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

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

3.2. 信息安全的发展现状

2020年车辆信息安全标准ISO 21434，Road Vehicle - Cybersecurity Engineering标准正式发布，该标准是基于SAE J3061制定的、针对车辆整个生命周期的标准。主要涵盖安全管理、基于项目的网络安全管理、持续的网络安全活动、相关风险评估方法、以及道路车辆概念验证阶段，产品开发阶段和开发完成后阶段的网络安全。

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

4. 结论和展望

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

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

本文转自：焉知自动驾驶，转载此文目的在于传递更多信息，版权归原作者所有。