• 将学习从仿真迁移到物理环境：如图16所示，我们可以使用在AV工程中应用的特征随机化（DR）来弥合仿真与硬件实验分离产生的“现实差距”。我们通过在仿真器中随机渲染仿真图像来训练迁移到物理世界的模型。凭借仿真器中足够的可变性，物理世界对于模型而言可能只是另一种变体。该方法在没有对真实图像进行预先训练的情况下，首次成功将仅在仿真RGB图像上接受训练的控制DNN迁移到物理世界。随后，DR只使用源自带有非现实随机纹理的仿真器的数据，在没有对真实图像进行预先训练的情况下，成功训练了一个现实世界的目标检测器，结果精确到1.5cm，对干扰物和部分遮挡也比较稳健。

• 解读自动驾驶系统：基于DNN的组件是不透明的黑匣子，具有难以理解的决策逻辑。我们可以通过一次只分析单个逻辑场景来实现可解释性。一般可解释性范式使用可理解的替代模型，如GAM或决策树，通过仔细构造特定实例的变体来接近不透明的DNN行为。这需要从测试实例的目的构建群体中开展抽样。如图16所示，该方法对一个特定场景开展抽样以此应用到仿真模型中。

图16 ODD表示使用场景群体

图17 场景规范 

• 安全问题分解：实现驾乘安全要求车辆工程能够扩展到具体的规格之外，覆盖可预见的用途。功能安全条例通过功能性能分析来满足这一需求；该分析从未知限制和系统性失效开始，最终对它们做出详细量化。我们可以通过一次处理单个逻辑场景，实现功能性能分析。为了达到统计置信度，每个基础场景均扩展为一个类似场景群体，如图16所示。

• 灌输信任：为有效与机器人展开互动或监督一台机器人，人类需要对机器人的能力和行为建立一个准确的心智模型。对于多数任务而言，控制逻辑的本质可在数个关键状态中捕获，其中的动作选择（例如最大化TTM）十分关键。用户研究表明，分析这些关键状态可以增加信任。关键状态可以通过针对以特定目的构建的分布场景开展抽样来揭示，如图16所示。

要点17：用当前工程任务构建使用场景群体代表ODD，其中包含训练、测试、解释、安全验证。

事实上所有主要AV开发者都利用场景，并且所有安全标准均需要建立有一个需求规范建立过程，其中场景是最重要的。因此，Pegasus法定义了图17所示场景规范的以下等级：

• 功能场景：这是该场景的非正式规范，用到了模糊的自然语言。例如，这可能是“自动驾驶车辆倒向另一辆车”、“另一辆车倒向自动驾驶车辆”、“前车转向”。非正式规范可能包括针对ODD的非正式规范，如“在高速公路上”或“在十字路口处”。我们将其视作非正式规范。

• 逻辑场景：一旦有了模糊功能场景规范，我们便需要确定其中包含的特定变体。有必要指定道路是否存在弯道以及弯道半径。对于行人场景，有必要进一步描述行人与两车之间的相对距离。其他参数可能包括两车速度范围、行人行走方向、能见度条件、路曳力等。我们将具有完全指定参数范围列表的场景视作逻辑场景。这被视作该场景的半正式规范。因为它没有规定停车结构形状和道路标识等所有详细要求，所以它不是正式规范。

• 具体场景：一旦我们指定了逻辑场景，便需要正式确定场景规范的形式。这包括停车结构形状、道路标高图、减速带轮廓，精确几何图形等详细说明；其中精确几何图形包括车道、停车位、障碍物（如垃圾桶和墙壁）、道路标记（如人行横道）、当局人工放置的指示牌，以及许多其他没有包含在半正式逻辑规范中的详细信息。每项具体的场景规范均必须包括所有信息，以便可以直接在模拟器中执行。这被视作正式的场景规范。

实例7：例如，NHTSA规定了约100种不同的碰撞前功能场景。每个此类功能场景可能凭借Pegasus法与数千个逻辑场景相关。每个逻辑场景可能与数千个具体场景相关。总共大约有种具体场景，代表NHTSA所有碰撞前的功能场景。

NHTSA列出的碰撞前场景并不代表自动驾驶系统需要接受测试的所有可能场景。例如，NHTSA的碰撞前场景列表排除了停车场景、工作区域、悬崖边驾驶等许多其他重要场景。

场景需求过程必须从非正式功能场景开始，然后对代表ODD的场景进行说明，还要从一个可以在正式且具体的场景库开始以便在开展特定测试的模拟器上执行。

假设一个场景库C，我们可以用下式绑定与危害使用相关的残余风险。

这种很有吸引力的方法通过执行数百万个独立任务（每个具体场景算作一项任务）来分解量化分布的任务，并且使用后处理回归步骤组合这些结果。

构建有效的场景库不仅对开发很重要，对验证也十分关键。库的有效性源于其覆盖范围：此处的目标应该是开发最小的库实现足够的覆盖范围。如上所述，可以通过从车辆仪表和车联网公司采集的数据中提取场景特征来确定先前的P（scenario），从而估计P（carsh|scenario）和涵盖范围。

图18描述了建立具有可量化覆盖率的库的常规方法。该起点是一个基础场景。我们可以通过高清测绘技术扫描获得道路几何图形和“家具”等基于特定的真实世界环境的3D环境。对于特定的3D环境，我们可以添加交通参与方来实现各种逻辑场景。例如，对面其他车道上存在一辆或同时存在多辆车，以及占用交叉路口等可能情况。

如图18第2步所示，我们一旦完成基础场景，便可以对其做出参数化，从而代表ODD。此类参数化过程可以从逻辑场景中给出的参数分布中抽取样本，以此来指明天气、能见度状况、静态“道路设施”（如遮蔽巴士站和树木）位置、交通灯、指示灯、路标、交通参与方的初始位置、速度等。每项参数均与一个分布相关，并且可以使用车联网数据开展测量。

随后，一旦有了可用模板，我们便可生成大量变体，以此来代表大量类似但又具备充分差异的场景，从而能够分析安全与不安全驾驶行为之间的界限。这些变量中的每一项均得到执行，例如使用一个虚拟测试驾驶（VTD）模拟器。由此生成的日志可以存储在密集的HDF5格式等能够发现模式的数据格式中，以便提取和随后融入大型数据库。

最后，使用数据分析来确定ODD的覆盖范围以及安全边界覆盖范围的有效性。若边界未经识别，那我们可能需要添加其他场景。

图18 场景定义流程 

图19 风险量化过程

场景  对危害  残余风险的贡献小于该场景的先验概率。从测试库中排除一组场景，这样会导致估值误差小于，即

隐性风险量化过程如图19所示。期初，功能场景未知。在步骤2中，当场景得到识别后，它们被添加到已知功能场景列表中。随后，在步骤3中分析每个已知场景的暴露度情况，例如使用车联网数据。若确定的暴露度十分重要，那么执行第4步，构建场景并添加到测试库；这一步非常重要。随后，在步骤5中估计不安全情况的概率密度。最后，新增场景与其他场景一起用于系统版本的A/B比较。

我们需要最佳实践来确定场景识别和建立支持A/B比较的场景库的流程。

ODD描述了自动驾驶系统设计的可以正常运行的特定条件，其中包含道路类型、速度范围、环境条件（例如天气、白天/夜间）、现行交通法规等限制。

逻辑场景规范界定了具体场景群。将定义为该群体的控制参数，将表示为为所有这些变量赋值。我们通过添加一个约束集合来定义ODD，将变量值赋值映射为真/假，即。我们将不满足这些约束条件的ODD情形排除在外，即那些

图20 预期功能安全区域 

图21 预期功能安全机器语言分隔

实例8：考虑“前车转向”场景，自动驾驶车辆和前车的初始速度分别为，因此ODD群体对应于一个双变量分布。设：

起初，开发可专注于满足所有四项约束，即把自动驾驶车辆速度限制在每小时3英里以上但低于每小时35英里，以及自动驾驶车辆接近前车的相对速度小于每小时5英里。随后，开发活动可以继续去除，使初始速度达到每小时70英里。随后，继续去除，将范围扩大到包括自动驾驶车辆以每小时20英里的速度接近前车的情况。

使用受限场景群体代表ODD可以通过逐步消除约束实现增量扩展。

众所周知的机器学习范式可用于让现代工程在未知场景中有效地发展并且持续得到改良。我们从图20所示的SOTIF区域分解开始，采集ODD群体的样本，从而获得开发场景库。我们将该样本视作已知场景集合，可以将其划分为如图21所示的训练和验证子集。此类划分能够让我们在未知场景中评估AV驾驶员的统计性能，就好像在训练期间使用验证数据来评估机器学习模型的性能。图22所示的隐性开发过程使用ODD场景子集来训练模型，并且用不相交子集评估模型性能。

图22 机器学习范式在预期功能安全中的应用

图23 应用机器学习可解释性范式

随后，我们可以使用图23所示的架构来解释AV行为。我们可以使用从ODD群体采样的额外场景样本获得的仿真结果来训练解释器模型，比如GAM或Tree。我们可以用部分从属性分析方法予以解释。

与临界情况（通常称作预期范围之外的病理输入）相反，边缘情况是范围内的输入。例如，当处理一系列视频帧时，由于帧间输入变化，我们通常会看到对象检测边界框“闪烁”。边界框消失（只会在随后的画面中显现）的帧是范围内的故障，因此这被视作边缘情况。“闪烁”由目标跟踪算法来解决；该算法融合了来自多个传感器的数据，聚合各帧和在帧间插入检测。因此，目标检测消失的帧可以视作范围内输入失效案例，而跟踪则可以视作一种容错算法。

这个观点承认，尽管单个组件的帧级故障十分常见，但整个系统必须对此类故障具有稳健性。考虑到一个组件故障率可能大于10-2，那么自然行驶里程的系统总体故障率必须小于10-12帧（=108英里x大于1,000帧每英里（在无数传感器间））。

有必要量化数据融合降低单个部件故障率的速率。

图24a描绘了经简化的故障模型，表明在特定帧下，由于单个传感器发生足够量的故障致使整个系统发生故障的危害情况，但这一状况仅发生在融合（容错）算法也失效的时候。此类瞬间发生的危害情况在图24b中以稀疏的时间条形表示。残余风险随着危害情况持续时间的延长而逐渐增加。

图24 边缘情况的影响

有必要量化危害情况的持续时间，以控制残余风险。

预期功能安全规范将场景分为安全场景和不安全场景，已知场景和未知场景，如图20所示。尽管对单个场景结果的控制有限，但工程技术必须对性能统计数据的持续改进予以控制。因此，如图20所示，预期功能安全合规需要牺牲区域2、3、4来不断增加区域1。

预期功能安全区域1、2：测试运行的所有场景均被视作已知场景。P（h）概率过高的场景被视作不安全场景；所有其他场景均被视作安全场景。已知的安全比例（即与区域2相比区域1尺寸）是安全场景与不安全场景的比例，即：

注意，分别使用区域， 之比表示，因为之前的  消掉了。

预期功能安全区域3、4：兼容预期功能安全实现的一项关键挑战是对未知场景开展恰当分析。为了应对这一挑战，我们使用上述机器学习范式，假设未知场景中的危害发生分布与已知情况下的相应分布相似。借助这一假设：

在SOTIF中，我们将残余风险定义为不安全场景的先验总概率，即

图25 基于A/B的后期概率

在模型中将所有区域之和设为1，从而得到残余风险公式，可将上述方程并入以下两个方程：

于是便得到最终简化的残余风险公式：

在此  是覆盖范围。随着安全性的增加，趋于1，而  则趋于零，残余风险的变化主要受  的导数影响。

利用从车联网得到的和从仿真得到的来量化残余风险是足够的。

评估进展安全的核心。具体而言，有必要对版本A、B分别开展A/B分布 和  比较。这一比较在本质上必须附带条件，不能依靠和先前结果。

假设版本  经历了实际危害  ，将  表示为版本  没有经历实际危害  的概率分布。假设版本  没有经历实际危害 ，将  表示为版本  确实经历了实际危害  的概率分布。然后，如图25所示：

•  = B相对于A的改良

•  = B相对于A的回归

实例9：当接近0时，回归基本不存在。此时我们得到：

• 

•  暗示一处改良。

我们应该使用危害发生后验概率来比较该自动驾驶系统与人类或其他自动驾驶系统。

结 论

1. 提出了一个概率框架，以渐进的界定与自动驾驶系统相关的残余风险并实现进度量化。该方法扩展了主流以危险分析为基础的安全标准到覆盖多辆车。

2. 引入了动态危害的方法，根据自动驾驶系统对于紧急危险的动态监控，选择行动，最大限度地延长这些危害发生的时间 （TTM）。

3. 描述了危害建模方法，训练机器学习模型识别危害，估计其TTM，利用与物理测试数据的对比进行标定。

4. 提出了渐进式的场景库建设流程。

5. 解释了为什么主流机器学习方法可应用于针对未知场景进行开发，

6. 阐明了实现SOTIF中不断扩大区域1的方法，这种方法可以评估相对于人类驾驶员，自动驾驶系统的安全性。