面向复杂特定场景的自动驾驶功能安全研究

周锐 魏亚 孙佳优

1.青岛慧拓智能机器有限公司 山东省青岛市 266000 2.深圳慧拓无限科技有限公司 广东省深圳市 518000

1 引言

从当前情况来看，自动驾驶汽车已完成功能实现阶段指标，但是在安全保障方面仍存在制约其产业应用的难题，尤其是在矿山、港口等率先投入产业化运营的复杂特定场景下，如何能够在保障自动驾驶系统功能定义需求实现的基础上，通过科学的技术手段与流程把控保障其系统的功能安全成为影响自动驾驶产业未来发展的重要科学问题。同时考虑到L3-L5 级别自动驾驶系统和传统的ADAS 系统（L1-L2 级别）在功能的要求上有很大的区别，所以也对复杂特定场景下的自动驾驶系统（多为L3-L5 级别）的功能安全研究提出了新的挑战。

2 面向复杂特定场景的自动驾驶功能安全方法

功能安全是通过技术和流程上的安全措施，在汽车的整个生命周期内保障对由汽车的电子电器功能失效或者错误引起的有可能对人身照成伤害的安全风险处在可接受的范围之内。以下为L3-L5 系统在功能安全领域所需要考虑的特别之处：

● L3-L5 的自动驾驶系统比传统的ADAS 系统所面临的场景更加复杂。传统的ADAS 系统所需要考虑的场景往往相对单一，对驾驶员进行辅助；而高级别的自动驾驶系统需要考虑到其ODD（Operational Design Domain）范围内的所有场景，在这些场景中，自动驾驶系统必须能够完全的代替人来操控车辆。更加复杂的场景会导致系统需要考虑更多的Hazard Situation（危险状况），相应的产生更多的功能安全需求。

● L3-L5 自动驾驶系统要求车辆拥有线控系统。汽车线控系统就是将驾驶员的操纵动作经过传感器变成电信号，通过电缆直接传输到执行机构的一种系统。而线控系统本身就拥有很高级别的功能安全需求，要保障整个系统的功能安全，首先就必须保障线控系统的功能安全。

● ECU（Electronic Control Unit）随着自动驾驶系统的级别越来越高，会由分布式向集中式发展，传统ADAS 系统中各个辅助功能所需要的ECU 相对独立，系统之间的交互耦合度相对较低；高级别自动驾驶所需求的集中式ECU 功能更加集中，系统复杂度和耦合度更高，无论从硬件还是软件方面都对功能安全提出了更高的要求。

● 从传统ADAS 系统到高级别自动驾驶，从人类驾驶员在回路到人类驾驶员不在回路，从在操控系统主导作用到需要驾驶员紧急接管再到完全不需要介入，这也为功能安全提出了新一个层次的任务。

接下来研究者会按照实现功能安全步骤具体分析L3-L5 自动驾驶系统为了达到功能安全需求所需要的方法。

2.1 场景分析

为了得到功能安全需求，首先要对系统的场景进行分析，得到系统的所会面临的危险状况。那么如何有条理的对场景进行分解和归类，就成为达到功能安全目标的第一步。如下图所示，研究者借鉴德国的PEGASUS 项目（无人驾驶汽车 -确保道路安全项目）中提出的场景分析方法：

图1 Pegasus 场景库整体架构

为了能够遍历在系统定义的ODD 范围内的场景，然后分析出所有场景中可能包含的危险状况，需要对场景进行分析。这些场景分析来自于以下这些方面：

● 来源于法律规定，标准要求，以及业内先验性知识的场景需求，这一类场景的描述比较清晰，只需要简单的对场景进行分析，就能够导出相应的危险状况。

● 来源于真实路况驾驶测试的场景。这一类场景由于每个自动驾驶公司对自己的数据的保密，往往是比较难以得到的，但是该类场景又是做场景分析中最直接，最重要的部分。

● 来源于仿真测试的场景。这类场景的数量是最多的，通过大量的仿真可以用较小的成本得到自动驾驶系统所需要面临的危险状况。

● FOT（Field Operational Test，道路运行测试）/NDS（Naturalistic Driving Study，自然驾驶研究）。该类场景目前在中国尚未建立相关的数据库。

● 事故分析。显而易见，这类数据是最直接的，也是功能安全场景分析中最需要的。

2.2 危险分析

有了场景分析，接下来就需要对危险状况进行分析，对于高级别自动驾驶的危险状况分析，FTA（Fault Tree Analysis，事故树分析方法）是一种非常有效的方法。FTA 是由上往下的演绎式失效分析法，利用布林逻辑组合低阶事件，分析系统中不希望出现的状态。故障树分析主要用在安全工程以及可靠度工程的领域，用来了解系统失效的原因，并且找到最好的方式降低风险，或是确认某一安全事故或是特定系统失效的发生率。下图为自动驾驶中对于“自转向”这一事件的FTA 例子。

图2 自动驾驶系统自转向FTA 分析[3]

2.3 ASIL 等级确认

在进行了危险分析后，我们能得到相应了危险状况（Hazard Situation），我们还需要对这些危险状况的危险程度进行评级，方便按照该等级进行不同程度的应对。这里需要用到ASIL 等级（Automotive Safety Integrity Level，汽车安全等级）概念。为了更好的进行解释，这里需要引入几个ISO26262 中定义的几个概念：

Exposure（E）：是指故障发生的时长占平均时长的比例，用来表征故障发生的概率的大小，E 越大则故障发生的概率越大。

Severity（S）：是指故障的严重程度。S 值越大则故障越严重。

Controllability（C）：是指故障发生以后，驾驶员是否可以人为的对故障状态加以控制。C 值越大则越难以控制。

当对每个危险状况的E，S，C 值进行定义了之后，就能够对系统特定功能的ASIL 等级进行确认。对于高级别的自动驾驶系统，E 和S 值的确认相对简单，但是由于L4，L5 的自动驾驶系统人类驾驶员不在回路中，所以其发送事故后基本不可控，C 值的定义成为一个难点。按照C 值的原始定义，我们可以把所有L4，L5 级自动驾驶系统的C 等级直接设置为最高的C3。这样做就带来一个问题，即不同故障状态的可控度没有区分，这种方式直接把可控度低的危险和可控度高的危险作为同等可控度进行处理，违背了ASIL 等级定义的原意。

为了解决这一问题，本文提出一种新的高级别自动驾驶的C 的定义方式，即是指故障发生以后，系统进入MRC（Minimal Risk Condition 最后的安全措施）的可控程度。MRC 是指当系统所有措施都采取后依然不能继续安全工作后所采取的最后措施，可以是“驾驶员接管”（对L3 自动驾驶），“靠边停车，同时乘客能够从自动驾驶车辆中走出到安全区域”或者“远程驾驶员遥控驾驶”。使用该定义方式，我们就能够对高等级自动驾驶系统的C 值进行很好的量化区分。

表1 ASIL 等级定义

2.4 功能安全目标和功能安全需求确定

当我们对所有的危险状况确定了不同的ASIL 等级后，需要对应这些ASIL 等级确定不同的功能安全目标，ASIL 等级越高，所要求的功能安全目标越高。有了确定的功能安全目标，就可以从中导出功能安全需求，把功能安全需求在和具体的硬件设计，软件设计向结合，就能导出最后我们系统所需的软硬件的功能安全方面的技术需求。

对于高级别自动驾驶功能安全目标的确定和传统ADAS 系统的区别在于高级别自动驾驶系统的功能安全目标会设置的更高。如下图所示，传统ADAS 系统的功能安全目标更多的强调Fail Safe（失效安全），即系统即使有特定失效下，也不会造成对人员或其他设备的伤害。而高级别自动驾驶更加倾向于Fail Operational（失效可操作），即在其重要或主要系统损坏时，仍可正常完成正常或最终的重要动作。这是因为高级别自动驾驶系统没有了驾驶员的介入，要求功能安全的目标也需要完成没有人在回路中也能继续工作（一段时间），把乘客带到安全状态。

图3 高等级自动驾驶功能安全目标[5]

当确定了功能安全目标后，就可以导出相应的功能安全需求用于系统的开发，在该步骤中，传统系统的功能安全需求方法是可以借鉴的。如下图所示为Autosar（AUTomotive Open System ARchitecture）提出的车灯管理系统（L1自动驾驶系统）的功能安全架构。

图4 车灯管理系统功能安全构架

同样的，在高级别自动驾驶系统中，我们从功能安全目标中提取的功能安全需求最少要包含以下信息：

● 如何识别和检测错误

● 如何进入Safe State（安全状态）

● Safe State 的定义

● 如何对故障进行冗余设置

● 如何进行人机交互，告知车内人员相应的功能安全信息

有了功能那个安全的需求，研究者就能够按照软硬件开发的流程进行系统开发，在此过程中还需要注意以下几点：

● 功能安全需求也要和其他系统功能需求一样进行测试，这里可以使用故障注入的方法，即向受控实验向系统中刻意引入故障，并观察系统中存在故障时的行为。

● 信息安全同等重要，研究者考虑功能安全需求的同时，信息安全是功能安全的基础，特别是在和环境交互的V2x 系统的信息安全，以及车内和自动驾驶ECU通信的车内通信系统的信息安全。

3 矿区自动驾驶功能安全分析示例

以下以矿山排土场无人矿卡排土场景为例叙述功能安全分析方法的实际应用：

第一步是需要通过不同的情况，不同的环境确定在ODD 范围内的场景。这些场景可以来源于法律规定、行业标准要求以及业内先验性知识，也可以来源于真实路况驾驶测试或仿真测试，还有一部分是直接来源于事故数据。在本示例中可以看到排土场景属于业内先验知识。

第二步是寻找不同场景下可能发生的事故所引起的危险情况（Hazard Situation）。对于示例场景而言存在以下可能：

①排土过程中发生掩埋人员事故；

② 撞到行人；

③撞到排土场指挥调度人员；

④ 和有人车发生碰撞；

⑤ 和推土机发生碰撞。

第三步是确定危险情况的ASIL 等级。对于矿山场景而言，在本文2.3 描述的定级基础上，对于无人矿卡C 值有了新的定义，故障发生以后，系统进入MRC（Minimal Risk Condition 最后的安全措施）的可控程度。MRC 是指当系统所有措施都采取后依然不能继续安全工作后所采取的最后措施 可以是：“靠边停车”或者“远程驾驶员遥控驾驶”。

表2 “撞到行人”ASIL 等级确定

第四步是根据ASIL 等级设定不同的安全目标，使得ASIL 等级为B 的危险情况降低为QM。本示例中“撞到行人”的降级目标为降低无人矿卡在排土场碰撞到行人的概率。

第五步是根据安全目标进行FTA 分析导出安全需求。FTA 分析又称故障树分析，是一种由上往下的演绎式失效分析法，利用布林逻辑组合低阶事件，分析系统中不希望出现的状态。在此示例中，“撞到行人”发生的一级原因是车辆是否感知到行人。若为未感知到行人，那么次级原因可能是激光雷达硬件故障或激光雷达软件算法故障；若为感知到行人但认为是误检测，那么次级原因可能是行人特征不够明显或是感知算法故障。以此为例进行事故原因推演可以得到避免此事故发生的安全需求。

第六步是根据安全需求进行软件和硬件的设计开发。如在示例中为避免因激光雷达硬件故障而发生“撞到行人”事故，可以通过加装备用雷达的方式做冗余处理，在主雷达硬件Diagnostic 信号为True 时，启动备用雷达再次检测；或是为避免因激光雷达软件算法故障而发生“撞到行人”事故，可以通过使用独立备用算法重复检测后比较两次检验结果的方式保证安全。

4 总结

单纯的功能测试并不能满足高等级自动驾驶的功能安全需求，而高级别的自动驾驶相对于传统的ADAS 系统复杂度更高，面临的场景更加复杂，ECU 功能相对集中，对线控系统有较高要求，同时驾驶员在环路中的角色也完全不同，导致高级别自动驾驶系统在功能安全方面也有了更高的挑战，本文详细分析了实现系统功能安全过程中所需要的过程，并且提出了对于高级别自动驾驶系统在该过程中需要注意的问题和可以使用的方法。

本文提出的方法并非唯一，也有其他的方法论也可以对高等级自动驾驶系统功能安全进行补充，如Intel 和Mobileye 提出的RSS（Responsibility-Sensitive Safety）方法，该方法更多的考虑了和自动驾驶车辆交互的其他车辆的信息，确认了危险状况后，找出相应的原因，然后来解决；还有李力、彭新宇等人基于责任敏感安全研究提出的跟踪防碰撞策略,该策略旨在保持交通安全和效率之间的良好平衡，同时还考虑到车辆和其他驾驶员的位置/ 速度感知/ 测量不可避免的不确定性。