Apollo在功能安全方面的探索

在本次技术沙龙中，来自Apollo团队计算平台的资深研发工程师-杨凯老师带了关于Apollo 3.0功能安全的讲解。

这里，我们将整理后的内容分享给大家，没能到达现场的开发者可以通过以下内容资料来详细了解课程内容。

演讲概要：

安全是自动驾驶前行的保障，尤其是对于 L4 级别的自动驾驶系统，功能安全更是一个全新的领域与挑战。本演讲将分享 Apollo 在功能安全方面的探索。

Apollo 3.0 功能安全

1功能安全是什么

在2017年以前，百度在无人车领域主要考虑的是无人驾驶的主系统。主系统主要指感知、定位、规划、控制等几个主要方面。2017年以后，无人车进入量产，功能安全成为一个重要的课题。主要问题是如何在路上不发生碰撞，是我们在一年时间这是主要探索方向。

为什么要做功能安全？这是自动驾驶的几次事故，其中比较严重的一次是2018年3月18日美国Uber碰撞事件，导致人员死亡，另外还有Google等其他无人驾驶的事故。但中国每年都有数万人在车祸中丧生，长远看，无人驾驶可以减少这一数字。

为什么自动驾驶系统会造成事故呢？自动驾驶系统是由软件和硬件研发组成，硬件包括车辆、传感器限速等等，软件主要包括地图、感知、规划、定位等等。而软件是有缺陷率的，软件的缺陷率有两种，一种是Bug率，一种是程序输出的结果非预期，包括精确度、感知度和算法等，另外还有延迟，都有可能会造成事故。

硬件方面，除了有车企事故、传感器故障，还有功能机的故障、限速的故障。车辆安全法规要求车辆上的电子电气系统具备功能安全，对于使用了AI技术的复杂的自动驾驶系统，安全要求更为严格谨慎。尤其是对于无人驾驶的车辆，需要自动驾驶系统在自身或者车辆发生故障时能够安全控制车辆。

首先，我们需要了解下功能安全是什么？无人车主要分为两大块，一是网络安全，指不被黑客窃取，比如黑客窃取了驾驶软件信息会造成危险；二是功能安全，在整个无人车生命周期内，在整个软硬件系统中的所有零部件都系降低到风险。还有就是构建功能安全系统，预知故障，降低风险水平。

2功能安全如何做

具体来说，我们采用电子电器行业标准ISO26262。在全方面落实ISO26262搭建安全流程的同时，系统地分析解决系统风险点，把风险点解决在系统搭建的时候。此外，在局部上建立无人驾驶安全系统，召回软硬件故障，建立安全防线。

ISO26262是国际标准化组织(ISO)2011年公告最新车电系统之功能安全国际标准。

ISO26262涵盖车辆整个生命周期，称为安全生命周期(Safety Lifecycle)，由管理、开发、生产、经营、维修至报废皆有相应的要求，本标准包含十个章节，计有Part 1名词解释(Vocabulary)、Part 2功能安全管理(Management of Functional Safety)、Part 3概念阶段(Concept Phase)、Part 4产品开发在系统层级(Product Development at the System Level)、Part 5产品开发在硬件层级(Product Development at the Hardware Level)、Part 6产品开发在软件层级(Product Development at the Software Level)、Part 7生产与操作(Production and Operation)、Part 8支持流程(Supporting Processes)、Part 9车辆安全完整性等级导向与安全导向分析(Automotive Safety Integrity Level-oriented and Safety-oriented Analyses)、Part 10 ISO 26262指南(Guideline on ISO 26262)。

SOTIF是预期功能的安全性标准，预计2021年正式发布标准，是后续功能安全的主要标准。SOTIF和ISO26262的主要区别是什么呢？ISO26262更强调系统失效，软件出错，程序的故障可以被认为是系统失效。而SOTIF更加注重技术的缺陷及系统相关定义。如图像识别的精度，雷达的抗干扰性。另外，由于功能传感逻辑不合理，导致规划的失败，也属于SOTIF的范围。功能安全要结合ISO26262和SOTIF。

那么如何落实ISO26262呢？上图是ISO26262的介绍，ISO26262把整个生命周期分为三个阶段，黑线以上是概念阶段，中间部分是产品开发阶段，最后是产品交付阶段。

ISO26262的第一章主要介绍基本概念，第二章介绍功能安全管理，第三章介绍概念管理，第四章介绍产品开发，第五章介绍硬件开发，第六章介绍软件。ISO26262主要基于项目定义，然后在HARA基础上做危险分析和做风险评估，再做安全目标，然后产生功能安全需求和技术安全需求。举个例子，比如现在场景是车辆启动，车辆启动的时候需要分析启动时的碰撞风险，提出HARA启动风险，Safety goals是系统风险，FSR是功能安全需求的盲区，避免加速。然后提出TSR，比如硬件传感去覆盖区域，再到软件区域，前方的感知要覆盖到前方安全区域。

针对ISO26262，Apollo对整个系统流程进行了分工和重新定义。首先是产品经理对整个系统进行全新定义，接着安全架构师进行系统分析和风险评估，然后系统架构师设计搭建软件系统和硬件系统，最后进入研发阶段。目前我们的流程已经通过了ISO26262的认证。

介绍一下Waymo的方案， Elektrobit，NVIDIA的安全方案，可以看出，主要是通过冗余来提升系统的安全性。

冗余的方案在ISO26262中里面也有支持，ISO26262会将所有的安全等级分为ASILA、B、C、D等级。

ASIL可作为产品开发之安全目标。ASIL由严重度(Severity)、暴露机率(Probability of Exposure)与可控度(Controllability)决定，等级分为QM(Quality Management)与ASIL A至D五种，QM等级无须适用ISO 26262。

这里我们要讲到冗余的一个反例，共因失效。冗余系统（或容错系统）优点是当一个模块发生失效时，由于容错系统同时配有两个以上相同的模块，所以可以避免系统发生失效。但是，共因失效的出现抵消了冗余系统的优点，当一个单独的应力导致两个以上相同的模块同时发生故障，那么冗余系统也会发生故障来提高强度。设计特点都会增加强度。元器件失效率低的系统，共因失效率也低。

多样性强调两个算法，比如业界比较流行的算法是CNN，机器学习。但是机器学习算法有个缺陷，没有学习过的东西识别不出来，所以会造成一个问题——它进行学习的大部分都是路上经常遇到的物体，比如人、车的交通案例，但是对于一些类似小石坑的识别不处理。但是可以用MST算法多样性布线，避免发生交规，用强化设计和测试去避免存在问题。

3功能安全子系统

这是功能安全的主系统思路。把系统比成一个人，感知是大脑，控制是手和脚。它的心脏有反应，就无法驾驶车辆，有安全风险。反应慢，也有可能造成安全风险。假如现在这个人是健康的，但也有可能错误决定造成安全隐患，比如突然右转。处理方法就是做故障检测，故障检测之后会进行故障处理，分等级处理，第一个等级警告。然后，就是减速，系统延迟比较大时，只能降速行使，因为高速会发生危险。之后是停车，比如传感器失效，紧急停车。否能够靠边停车是由发生的故障决定，比如感知系统失效就不能前后靠边停车。

还有主系统坏了后有一个备用系统进行巡视。根据故障可以进行分类，分成人的故障和车的行为故障。如果车软硬件发生故障，相当于车的健康率发生故障，就不能行使。另外，根据故障分成几类，有碰撞风险是急刹，导盲故障。还有是碰撞检测，这种可以根据障碍物进行缓刹和非急刹的策略。还有一种是无碰撞风险障碍。

4熔断机制 & 碰撞检测

在没有功能安全系统时，功能安全的熔断机制是把感知发给规划，规划再发给行动，行动再控制车。增加了安全后，进行了熔断，是把主系统的控制权给安全系统进行接管。

右面是碰撞检测，绿色区域是规划距离，正常的车在规划过程中会与行车保持安全距离，这个距离要远于功能安全的检测距离来看。红色区域是安全的检测碰撞区域，比如安全下面的公式，参考Mobileye RSS。另外还有多样性感知算法，比如说CNN感知算法。

Apollo在搭建功能安全子系统时有这样一个思考，安全子系统，必然会带来系统复杂度的上升，但是为了安全性牺牲复杂度现在看起来也是有必要的。

另外，准确率与召回率，是功能安全的两个核心指标。为了好的乘车体验，要做到高准确性，为了安全又要做到高召回率。