特约专栏|浅谈自动驾驶安全评估

在评估自动驾驶汽车的安全性时，必须考虑各个方面。首先，必须确保安全功能（即所谓的预期功能安全，SOTIF），它侧重于在没有EE故障的情况下可能因功能不足而引发危险的预期功能。另一方面是确保预期功能不会因系统硬件或软件中的随机和系统故障（功能安全），而引起危害。本文确定将主要关注前者，即预期功能安全评估。^[1]

值得注意的是，在Scenario based test方法中，首先需对系统的安全性做出微观评估，即MiR指标评估，然后必须将其转化为宏观评估，MaR（Macroscopic Risk）评估，对应上一篇文章提到的可接受准则，比如ADS事故率。这里可能不太好理解，举个例子，比如我们要评估ADS功能导致追尾这类危害场景的事故率，使用TTC作为风险评估的MiR危险度量（critical metric），通过对场景数据的采集，分层，泛化得到具体场景，然后对ADS算法进行仿真测试，可以得到各参数（距离，速度等）概率分布下具体场景的危急指标（critical metric）。然后基于场景的概率以及critical metric，推导出ADS功能引起追尾的总体事故率MaR。

如何推导，可以采用极值理论（extreme value theory，EVT）来推测极端事件（在这里指交通事故）发生的概率。极值理论 (EVT) 通常用于将测量结果（这里可以理解为critical metric）外推到观察时间内未发生的不太可能的事件，核心思想利用统计学中的概率分布。它在金融和保险数学中很流行。而AD 安全评估的挑战与此示例类似：很难收集足够的数据来估计严重事故的概率，因为它们极为罕见。如果发现危急指标从危急情况指向某一类别的事故，则可以使用 EVT 推断其可能性。收集足够危急情况所需的里程低于收集事故信息所需的里程。^[10]

MaR指系统的平均风险，例如致命事故的发生率，被称为宏观风险（Macroscopic Risk，MaR）。我们可以用单位时间（每年）事故发生的次数，如10^-6/a，或者单位里程事故发生的次数，如10^-6/Km。MiR指单一交通场景（如cut in，crossroads）中的风险称为微观风险（Microscopic Risk，MiR），比如我们常见的纵向风险指标TTC（Time to collision），横向指标TTLC（Time to lane change）。

回到安全评估，以下将介绍图1中各类方法的优缺点。

实际道路测试指使用带ADS功能的测试车辆在真实环境中测试，需要预先设计测试的里程以及测试场景。测试里程通常由可接受准则推导得出，而测试场景中应考虑目标物的类型，目标物动态行为，道路与车道结构类型，光线，天气等要素及其比例。在实际交通中测试足够里程的情况下，可以估计两次事故之间的平均距离（例如，使用泊松分布）。为了能够充分说明ADS在一定程度上优于人类，根据论文^[8]的数据，则需要大约88亿英里的测试。

此方法的优点是，整个系统是在现实条件下测试的，可以反映ADS在真实环境的系统表现。然而，经济代价较大，可以触发具有挑战性的情况但难以找全。

分阶段引入ADS的方法，首先仍然是基于real world test，其目的是通过限制车辆的ODD，以限制发生的交通状况的数量，从而以经济可行的方式逐步增加功能可用的区域。比较严格的ODD例如，只有在良好的环境条件下，路中有物理隔离带的结构化道路的固定路段（如G2京沪高速）。在固定路段完成足够的现场测试里程后再逐步推广到其他高速公路。此外，也可以在测试车辆上配置安全员，如果系统出错时，他可以立即干预。经过一定里程后车辆被评估为安全的，则可以逐渐增加ODD和／或取消安全员。许多传统的Tier1，OEM，主要采用此方式，比如戴姆勒和博世。很多L4的公司，也在固定区域配置安全员进行无人载客的尝试。但其实此方法仍然需要大量的实际道路测试，总体成本较高。^[1]

形式验证为系统提供了抽象数学模型的形式证明，换句话说，如果系统表现能满足设计的数学模型，则认为其是安全可靠的。比较有代表性的是 Mobileye的RSS模型与英伟Safety Force Field（安全力场理论）。

RSS定义了自动驾驶汽车应遵循的五大准则，这些准则参照主流交通规则和驾驶常识，同时形式化定义了自动驾驶的危险场景，形式化定义了自动驾驶汽车在危险场景下应做出的合理行为，并声称如果所有车辆（包括人类驾驶的车）都遵循RSS模型，则不会出现任何事故。

形式验证是简单有效的方法，但RSS基于的假设是感知输入的数据不会出错，因此更适合对决策规划进行安全评估，或者与其他评估方法联合使用。

基于场景的测试是目前安全评估研究的重要方向。首先要区分几个概念，scene，scenario，situation（详见文献[4]），scenario是scene的时间序列，场景包括静态和动态元素，以及所有交通参与者，和这些参与者之间的关系。基于场景的测试将被测对象暴露于（预）定义的场景，并评估其反应^[2]。国外比较有名的PEGASUS项目就是基于场景的测试方法，其主要步骤如下：

1. 建立场景数据集：基于实际数据与知识经验得到数据集；

2. 构建具体测试场景：由功能场景，逻辑场景，逐步细化得到可执行测试的具体场景，其中涉及到危险场景的识别与具体场景参数的泛化；

3. 测试评估自动驾驶功能：通过合理分配仿真测试，场地测试，现场测试，验证ADS功能；

4. 安全论证：收集论点，对ADS功能安全性形式化论证。

基于场景的测试在汽车行业中已经是一种比较成熟的测试方法，用于开发、认证和评级目的，尽管它的名称不同。基于场景的 ADAS 和 AD 测试之间的主要区别在于场景抽象级别（相关参数的数量）和定义相关场景的来源。ADAS 场景主要基于事故统计数据，出于评级目的 (NCAP)，场景被显著简化（例如，理想的传感条件、广阔的试验场等）。AD 场景基于各种来源，事故统计的经验数据、现场测试/自然驾驶研究和以前的测试（包括模拟）结果，以及基于头脑风暴、经验、演绎。^[2]

个人理解，基于场景的测试有以下几个难点和重点：

1. 不论是实际路采数据，专家经验还是事故数据，组成的场景数据库，如何保证场景库（scenario database）的完整性？

2. 以高速公路为例，单调低风险的场景占大多数，如何从场景数据集中筛选出危险场景构建场景库？比如通过 critical metric（类似TTC这些指标）筛选场景，如何设计 critical metric以适应各类场景下的危险度量？

3. 当筛选出危险场景后，如何对场景特征参数泛化以达到足够的场景覆盖度，以及场景的概率分布如何提取，特征参数之间的物理约束如何考虑？

4. 测试方式包括基于仿真，场地，实际道路测试，仿真环境下如何保证传感器模型与实际

5. 物理表现一致，需要做哪些 qualification？实际道路测试又需要对哪些场景采样，对应的比例需要如何设计？

6. 测试覆盖度如何保证，才能声明基于场景的ADS功能测试是充分的？

7. 基于场景的测试得到的是具体场景的危险度量，也就是微观指标（MiR），如何推导出系统的平均风险度量（MaR）？

其中有些问题PEGASUS及其他类似项目已经给出部分解决方案，有些仍然还在探索，涉及的内容较多，在这里暂不展开讨论。

影子模式是特斯拉测试新功能的常用方法，指在有人驾驶状态下，系统包括传感器仍然运行但并不参与车辆控制，只是对决策算法进行验证——系统的算法在“影子模式”下做持续模拟决策，并且把决策与驾驶员的行为进行对比，一旦两者不一致，该场景便被判定为“极端工况”，进而触发数据回传。

然而，在模拟环境中其他道路使用者的行为与现实不相符，所以在验证ADS算法是有一定局限性。主要因为其他道路使用者也根据自动驾驶的行为规划他们的行动。如果某种情况下的人驾做出的决定与ADS不同，那么可能另一个道路使用者会做出不同的决定。

在基于功能的测试中，首先根据需求定义系统功能与use case，然后在测试场或模拟环境中进行测试。这是ADAS测试过程中常用的方式。当前的 ISO 标准（例如自适应巡航控制的 ISO 15622）和 UN ECE 法规（例如高级紧急制动系统的 UN ECE R131）遵循基于功能的方法，为各个系统定义了一些固定测试。但对ADS来说很难，因为不可能在每个可能的场景下定义ADS所需的功能。[1]

此外多种测试方式共同用于ADS的安全评估也得到越来越多的共识，有些传感器供应商对其产品的安全验证结合了Scenario-based Testing与Real world test，如图，Ibeo激光雷达的考虑了随机道路测试与基于场景测试，以达到最终的安全论证，发现基于场景的测试能更好地发现长尾场景。

所有方法都有不能忽视的缺点。在实际交通中进行的测试可能具有最好的有效性，但在SOP之前完成这项工作是不可行的。形式验证可以对决策与规划算法有较好的评估，但无法解决感知的limitation。基于场景的测试是一种经济有效的方法，但是需要有效的仿真模型，并且需要将微观指标转换为系统平均风险度量。个人认为，需要采用一种综合方法来最终安全论证引入ADS的残余风险是可接受的。以上就是个人的粗见，如有疏漏，还请各位专家见谅。

冯亚军、James Bian | 校阅