面向预期功能安全的决策规划系统仿真测试方法

编者按：希望借此分享一下我们在依照ISO21448（Clause6-9）开展实践、对自动驾驶决策规划系统进行在环仿真测试、参与对ISO34502的修订讨论、和企业在SOTIF领域相关交流的过程中，所做的思考和梳理。错误、纰漏之处，还望读者不吝指正。

内容概览：

第一部分：背景——SOTIF分析与测试
第二部分：综述——面向SOTIF的决策规划系统仿真测试方法
第三部分：工具——场景文件自动生成器
第四部分：方法——基于场景“搜索”的加速测试
第五部分：讨论


摘要：在第一部分的背景介绍与分析中，提出了本文的关键问题：如何有效地针对决策规划系统进行预期功能安全分析与测试？在第二部分中，对比了两大类方法，提出了两个仿真测试方法选择的原则，通过分析归结到了采用黑箱优化的、基于场景搜索的加速测试方法。我们的具体实践作为该方法的示例，介绍在第三和第四部分中。最后在第五部分中，对贯穿其中的2个话题进行了讨论。

关键词：预期功能安全 自动驾驶汽车 决策规划系统 仿真测试 加速测试

1 背景——SOTIF分析与测试

从现有的分析框架来看，依据ISO21448开展SOTIF安全分析与测试验证的过程，可分为三大阶段，分别是：

第一阶段：安全分析阶段

第二阶段：已知危害场景下的评估（区域2）

第三阶段：未知危害场景下的评估（区域3）


图1. ISO21448的总体框架


图2. 区域2和区域3在开发之初与开发完成时的对比

其中第一阶段（安全分析）的输出应该是潜在危害场景。该阶段主要包含Clause6和Clause7两部分内容，分别完成危险识别、风险评估及触发条件识别等几个步骤，见图3。


图3. ISO21448的安全分析阶段（Clause6&7）

从被分析对象——自动驾驶汽车来看，可以将其系统分为两大类（见图4）：

其一是自动驾驶与其外部物理世界直接交互的系统，包括环境感知系统和控制执行系统（PERCEPTION & ConTROL SYSTEM）等；

其二是在自动驾驶汽车内部数字环境中完成输入输出的决策规划系统（DM&PP）。

当这些系统的性能局限遇到特定场景中的触发条件时，便可能导致危险，产生危害；一般而言，SOTIF问题即出现于此。

环境感知系统的触发条件主要来自感知干扰（Perception disturbance），决策规划系统的触发条件主要来自于动态交通干扰（Traffic disturbance），控制执行系统的触发条件则主要受到来自作用于轮胎的路面干扰和作用于车身的风干扰（统称Vehicle disturbance）等。


图4. 自动驾驶系统的SOTIF触发来源

为了更好地理解这两大类系统在依照ISO21448开展从Clause6到Clause7的分析工作时，所面临的不同状况，我们先简单地从系统的工任务、过程和目标等三方面对比一下环境感知系统和决策规划系统：

「环境感知系统」

·  任务：信息提取与加工（任务以片段为主）

·  过程：物理→数字→信息（实现的功能包括：检测与跟踪等）

·  目标：正确、准确（以物理世界为真值）

「决策规划系统」

·  任务：创造行驶的价值（安全、舒适、高效、节能地从A到B，任务以连续过程为主）

·  过程：信息→控制信号（实现的功能包括：场景理解、预测、价值计算等）

·  目标：好坏（价值高低）

可以看出，决策规划系统的任务是创造行驶的价值，其结果分优劣好坏，但没有真值作为参照；且工作过程连续，无法以切片化（时刻）的方式进行评价。

进一步地说，环境感知系统的任务大都是基于、围绕特定对象的，比如动静态障碍物、交通设施等；感知任务有一个绝对真值，所以感知求解的问题是尽量接近这个真值“点”；而决策规划系统的真值难以定义，甚至不存在绝对真值，决策规划求解的问题只需要一个可行解，而可行解是一个“集”。

故而，开展从Clause6到Clause7的分析工作，找寻触发条件的话，

「环境感知系统」：是比较可行的。因为，触发机制可分析、触发源可寻、触发条件与所产生的危害对应关系可判（控制执行系统，同理）

「决策规划系统」：比较不可行。因为，触发机制隐蔽、触发源往往不是独立要素（涉及到复合场景）、触发条件与所产生的危害对应关系不明（作用过程是连续的）

依据上述分析可知：针对环境感知系统分析触发条件是比较可行的；我们采用了基于事件链的分析框架，结合触发源本体模型进行推演，取得了一定的效果。然而，针对决策规划系统，想要提出类似的系统性分析方案则非常困难；对于L3+或及复杂场景下的自动驾驶系统而言，上述问题尤甚（注：对于简单环境中，执行简单行驶任务的自动驾驶系统而言，尚可进行一定程度的分析）。

由此引出了本文的关键问题：如何有效地针对决策规划系统进行预期功能安全分析与测试？

2 综述：面向SOTIF的决策规划系统仿真测试方法

由于决策规划系统的输入输出都是信息和信号，相对于整车在环或场地实车测试而言，系统在环仿真测试是对其进行测试的最主要手段（等效性高、测试效率高、成本低）。此外，在测试过程中，一般将决策规划系统视为“黑箱”处理。

以下继续围绕第一部分留下的关键问题，将现有的相关测试方法做分析和梳理，希望明确其中较为可行的仿真测试方法及其适用性。

在此借用一下哈贝马斯（Habermas）哲学分析理论里的两个概念：系统（System）与生活世界（Life world）；前者是人为设计的、规范的，而后者是自然发生的。各种面向决策规划系统的测试方法，也可以依据这两个概念进行分类：

「第一类方法」

将测试场景视作“系统（System）”——做设计；即，通过分析和定义场景里的关键对象、要素和变量及其取值范围，设计场景；

「第二类方法」

将测试场景视作“生活世界（Life world）”——使发生；即，通过具有自主行驶能力的智能体或智能体集群形成的动态背景车（Surrounding vehicles）与被测对象（Vehicle under test）发生交互，产生场景。

表1. 两大类仿真测试方法的对比


先说第二类方法，其中的关键工具就是生成动态背景车（及背景车系统）的机器学习算法；比较常见的包括不限于：深度强化学习、逆强化学习和对抗生成。需要强调两个特点：

「测试的高效性」

测试的高效性是这类方法主要追求的设计目标。

然而，在安全分析与验证的环节中，更为核心的诉求是关键场景的覆盖率（即全面性）；在这点上，该类方法仍缺乏理论证明的依据，故其用于安全性论证的能力较弱；

「场景的泛化性」

场景的泛化性是这类方法的独门秘笈。在一定的道路路网的支持下，基于机器学习算法的动态背景车模型可以形成多样化的功能场景变化，而不拘泥于特定的逻辑场景设定。

综上，该类方法可以被视作是一种混合了已知和未知场景范畴的补充测试方法；或者单独作为与公开道路测试相呼应的一种虚拟测试工具，寻找并发现unknown unsafe（未知危险）。

另有一个前提与一个补充：

「前提」

该类方法使用的最大前提是拟真性。脱离了这个前提，就变成了unreal & unsafe，也失去了测试的意义。真实性的问题，将留在最后一部分的讨论中，再做展开。

「补充」

同为机器学习领域内的、基于LSTM的动态背景车生成模型也颇为多见；不纳入上述范畴的原因是，基于深度学习的模型其核心是模仿学习，在行为动作的拟真性方面较有优势，而在测试效率（针对性）上并无优势；故用于一般的性能测试或许更合适。

再说第一类方法：采用三级场景模型层层细化定义测试场景，一直是最基础和通用的方法。当面向安全性论证的诉求时，也暴露出两个明显的问题：

「问题1」逻辑场景参数空间大

具体表现为场景关键对象、要素和变量多所导致的维数多，再加上取值范围大，决定了遍历逻辑场景空间的不可行（维数爆炸问题）；

「问题2」参数空间的粒度划分难

具体表现为，如果采用均匀采样，过细的粒度将加剧前一个维数爆炸的问题；而过粗的粒度，则势必漏掉关键场景。如果采用非均匀采样，又该如何最佳地实现“法网恢恢，疏而不漏”的效果呢？

由上述对于第一类方法和第二类方法的分析与比较，我们可以归纳出，面向安全分析与测试所需的仿真方法的选择原则：

✔【第一原则】关键场景的覆盖率高：即测试并发现尽可能多的关键场景

✔【第二原则】测试效率高：即非关键场景测试得少

再以上述原则审视一下，前面的第一类方法中具体的几种测试方法：

1. 随机采样测试

在逻辑场景的空间内通过随机采样，定义具体场景进行测试；⇨无法同时兼顾第一和二原则（若想符合第一原则，必然违背第二原则）

2. 基于随机梯度下降的测试

由于被测对象是黑箱（梯度不可知），且空间维数高，基本不具有可行性；⇨违背了第一和二原则

3. 基于NDS的加速测试（也称“强化测试”）

基于对自然驾驶数据分布的重要性采样，定义部分关键参数范围；该方法较适用于总体性能评估，而非安全论证（不解决长尾问题）；⇨违背了第一原则

4. 基于场景搜索的测试

可将场景搜索任务转化为优化目标，将各类优化算法用于实现搜索关键场景，从而服务于第二条原则（提高效率）；在搜索过程中，通过合理平衡探索（Exploration）与利用（Exploitation），从而服务于第一条原则（提高覆盖率）；综合实现面向安全需求的针对决策规划系统的仿真测试。

基于上述的分析，我们认为，目前在该类方法中具有同时兼顾两个原则可能性的是，采用黑箱优化的、基于场景搜索的加速测试方法。

该方法的实施需要两个重要的组件，分别是支持自动化测试的具体场景生成工具（自动生成场景），以及优化搜索算法（自动找到关键场景）；这两方面的实现方法不一而足，我们在这两方面的具体实践将作为示例在第三和第四部分展开介绍。


图5. 基于场景优化搜索算法与自动化测试结合的测试方法

3 工具——自动化场景文件生成器

第二部分提到的两个重要的组件之一就是支持自动化测试的具体场景生成工具。有两个目标需要被预先定义：

「输入的形式」

比较初级的解决方案一般是从逻辑场景作为输入；

比较完美的解决方案将是从功能场景或自动驾驶功能作为输入，即一站式完成服务于自然人的、语义化的场景需求到服务于仿真计算工具的、完全形式化的场景定义。

「输出的形式」一定格式的具体场景文件

OpenX系列标准是一套较为完整的仿真测试场景描述方案，包括OpenDRIVE、OpenCRG和OpenSCENARIO（OSC）等。OpenX系列标准将仿真测试场景统一化，提高了仿真场景在不同仿真软件内迁移进行测试的效率，也有利于对不同仿真软件测试进行统一的场景评估。对于本文所关注的——决策规划系统的仿真测试而言，重点在于仿真测试场景的动态部分（如车辆的行为），是由OSC文件描述的。

然而，基于XML的OSC格式较为底层，对应的文件描述过于复杂；导致人工编写场景文件耗时长、效率低。故需要一个更高级的接口来连接语义级别的场景定义与OSC格式。因此，开发了面向OSC的自动化场景文件生成器，以结合在环仿真测试系统，实现针对决策规划系统的自动化在环仿真测试；进而支撑了第四部分中介绍的基于场景搜索的加速测试方法的实现。

以下简介这个自动化OSC场景文件生成器的设计要点和具体架构。

OSC作为一种自动驾驶场景描述的DSL（domain-specific language，领域特定语言），对它的编译体系借鉴了传统编程语言的架构，分为OSC前端与OSC后端两个主要模块，如图6所示。


图6. OpenSCENARIO场景文件生成器执行工作流

OSC前端负责处理json语言定义的场景蓝图，蓝图中对较为固定的参数（如车辆尺寸）进行了默认设置，并支持场景关键参数的自定义。OSC后端负责根据前端的解析结果，构建OSC的DOM树（document Object Model，文档对象模型），进而编译产生最终用于仿真软件运行的目标xosc文件。

在OSC后端中，将OSC的本体使用OOP（Object Oriented Programming，面向对象编程）思想进行了形式化，可编译生成OSC中的任意节点组合，并且使用xsd文件对生成结果的正确性进行验证，以确保其完全符合OSC标准。此外，完整的编译流程还包括构建和编辑场景的输入接口，以及可运行xosc场景文件的仿真服务器等。

对于OSC场景文件生成器中最关键部分，即OSC后端部分，基于OSC结构设计了一个高效且易用的架构——句柄树，示例如图7所示。图中所有节点（Maneuver、Event、Action等）都继承自OSCNode基类（包含了打印、保存、流输出、更新等多个功能），可实现对OSC格式DOM树或者其任何子树的便捷操作。采用句柄树架构，可以优化编译器的空间复杂度。句柄树将所有数据集中存放于一个统一的堆内存，而下图的所有节点不包含实际的数据，仅包含一个指向实际数据的指针。


图7. OSC后端句柄树架构

此外，实际应用中往往需要一次性编译生成一个逻辑场景下对应的众多个具体场景，如果每次参数修改都需要重建句柄树将导致高昂的编译成本。因此，为确保快速输出最新的目标xosc文件，设计了链式更新机制，使任意节点的修改能自动向上级节点传递。

综上，该生成器实现的效果是，按照给定的逻辑场景和采样方法，可以批量地自动化生成所对应的OSC文件（具体场景），可直接被仿真测试工具读取；生成的时间成本几乎为0，大大降低了获得具体场景所需的时间和人力成本。

4 方法——基于场景“搜索”的加速测试

在安全分析时，关键场景主要是指安全性相关的危险场景。故而，基于场景“搜索”的测试方法目标是加速（体现：第二原则）找到“所有”危险场景（体现：­­第一原则）。
一般而言，该方法由三个部分构成：测试工具、搜索方法及成本函数。


图8. 基于场景“搜索”的加速测试方法基本构成

「测试工具」

由测试场景和在环仿真测试系统组成。其中，测试场景：每次根据采样的要求，由第三部分介绍的场景文件生成器自动输出需要仿真测试的具体场景。在环仿真测试系统则包含了仿真测试工具和被测对象，可以是决策规划系统软件在环的方式或者硬件在环的方式。

「搜索算法」

以是否基于代理模型分为了两大类。若不利用代理模型，则一般需要基于群体智能的算法实现探索与利用的有效平衡（比如遗传算法、粒子群算法等）。若使用代理模型，则使用各种机器学习方法进行模型建立，并利用贝叶斯优化思想设计算法，开展基于该代理模型的采样。

「成本函数」

对安全分析而言，直接的成本函数价值一般是危险或风险（如最常用的TTC、THW等）；

从计算的空间范围上看，比较常见的是一维（沿车辆行驶方向）和二维（道路空间内）的度量方式；

算法的操作层面上，还会需要考虑对得到的无效场景进行自动化合理排除的方法。

其中，以贝叶斯优化算法作为关键场景的搜索算法，做一示例，伪代码如下图所示：



以一个标准化测试函数（Hoelder Table）为例，初步分析一下采用贝叶斯优化搜索方法的可行性与潜力，即是否符合上述提出的覆盖率和效率的两大原则。

目标函数值在搜索空间上的分布如图9所示，图中用红色线框标出了目标关键场景占据的子空间（分别在四个角的位置附近）。真值结果是通过细粒度的均匀栅格扫掠测试获得的，用于作为基准对随机采样和贝叶斯优化搜索两种方法进行对比。


图9. Hoelder Table测试任务的真值

贝叶斯优化（Bayesian Optimization, BO）和随机采样（Random）在该问题上的表现如图10所示。为了降低结果的随机性，对于每种算法我们都重复进行了10次实验，图中展示了10次试验的最小值、最大值以及平均值。以90%覆盖率作为目标，贝叶斯优化方法相比随机采样可实现约10倍的加速效果（50000:5000），并且重复实验之间的方差较小，优化算法的稳定性更好。


图10. 贝叶斯优化和随机采样实验结果对比

以上仅为两参数的示例（规律性较强），在决策规划系统的测试场景（高维数的逻辑场景）中，存在更加复杂，较为分散的、“潜伏较深”的危害场景（比如多车多动作的场景），黑箱优化算法能够发挥出更好的搜索效果。

以图11为基本流程框架，可对决策规划系统进行在环加速测试；图12是在前车切入场景中，采用贝叶斯优化和随机采样方法的部分实验结果对比，表现出黑箱优化搜索算法在测试效率方面的潜力。该类方法的测试效果（覆盖率和效率）仍有很大的优化空间。


图11 流程框架示例——以VTD为在环仿真测试环境


图12. 在前车切入场景中，贝叶斯优化和随机采样的部分实验结果对比

5 讨论

「讨论1」System-based Safety evaluation与Scenario-based Safety evaluation

参照ISO21448进行System-based Safety evaluation是开展预期功能安全分析的一般途径；是以自动驾驶系统（功能和ODD等）为出发点，层层分析得到具象的测试场景集合（从少到多，从粗到细）。

然而，在实践中发现，面向本文所聚焦的决策规划系统很难依照Clause6&7的流程进行分析；以Scenario-based Safety evaluation，从大量场景（第一类方法）或大量场景可能性（第二类方法）中搜索或发现危险场景反倒是一条可行之路（从多到少）。

System-based Safety evaluation和Scenario-based Safety evaluation最终会是双剑合璧还是殊途同归呢？

「讨论2」真实性

真实性（拟真性、可还原性等）问题始终是仿真测试的根本，可能无限接近但永不达到。在第一类方法中，通过知识的方式定义了场景和其中的关键对象、要素、变量及其取值范围，间接地服务于了真实性目的。在第二类方法中，通过创造智能体（或智能体集群）的方式自动化生成场景，则需要更多对于真实性的考虑。

可观察的视角包括：决策的真实性（含角色的定义）和规划的真实性（包括Path planning、Maneuver planning、Trajectory planning等）等。

在安全验证的框架下，如何在仿真测试条件下，综合地实现覆盖、效率、拟真等多维目标仍需进一步的尝试和努力。