两万字论文-面向高度自动化的自动驾驶车辆安全验证框架

‍原文作者 PhilipKoopman&MichaelWagner 翻译 小明师兄

摘要

验证高度自动化车辆（HAVs）的安全性是自动驾驶面临的一个非常重要的挑战。仅依赖大规模道路测试活动的HAV安全验证策略是不太可行的。虽然仿真和进行边缘案例场景测试可以帮助降低验证成本，但单独使用这些技术可能无法为全面部署提供足够的保障，除非采用更为细致入微的验证数据收集和安全分析方法。可以通过使用更高精度的测试来明确验证较低精度测试的假设和简化，而不仅仅是获得较低精度结果的采样复制。将多个测试目标分开可以帮助验证流程，包括需求、环境模型充分性、自主性正确性、自主性稳健性和测试场景充分性。对于隐式设计和要求的自主性方法，例如机器学习训练数据集，可以在架构中建立可观测点，以确保车辆通过正确的测试出于正确的原因。这些原则可以提高HAV安全性验证的效率和效果，作为一个包括“驾驶员测试”和生命周期监测的分阶段验证计划的一部分，并明确管理验证不确定性。

概述

尽管面临重大跨学科挑战，高度自动化车辆（HAVs）的广泛部署似乎也近在眼前。目前，关于验证这些车辆的非传统软件方面安全性的技术策略尚无共识。鉴于美国国家公路交通安全管理局（NHTSA）采取的“自动驾驶车辆技术安全的非监管方法”，许多HAVs似乎会在开发团队认为车辆已经就绪的时候立即投入使用，然后再看在公共道路上的表现。即使试点部署显示出可接受的低事故率，仍然存在一个问题，即有限规模的部署是否能准确预测更大规模的部署以及随之而来的未来软件更新的安全性。

通常可以看到有关积累道路里程将验证HAV系统安全性的说法，特别是在试图评估开发工作进展的背景下。然而，即使涉及其他形式的验证，更全面的讨论仍然倾向于强调测试的作用。然而，即使在封闭赛道和高保真度仿真的情况下，部署前可以进行的车辆级测试仍然受到限制。

本文的范围是在ISO 26262合规性之外所需的验证，重点是SAE Level 4自主性。Level 4 HAVs只需要在定义的运行设计域（ODD）内自主操作，该域定义了系统预期运行的特定条件。

对HAV自主性的安全验证方法需要超越里程积累，这是非常可取的。最好是基于一种包括具体、可测试的安全目标和要求的反证法。本文提出了一些提高HAV验证效率、增加有效性并形成更具可辩护性安全论证的方法。分层的验证步骤系列可以帮助支持结论，即HAV系统在没有完全规定的传统自主性功能要求集的情况下是可接受安全的。

方法

文章认为，通过应用以下观点，可以显著增强HAV验证工作：

1. 通过分别管理需求验证和设计验证，将测试的不同目标分开。

2. 使用更高保真度的仿真和测试，减少由于较低保真度仿真和测试中的假设和差距而产生的残余风险。

3. 在HAV架构中提供可观察性，确保测试通过的原因是正确的。

4. 明确地管理安全论证中的不确定性。

尽管这些观点基于某些领域现有的实践，HAV技术的新颖性和HAV商业化的速度促使我们清晰地、统一地描述如何应用这些观点，以管理和降低激进HAV部署的风险。

术语

本文的术语通常与ISO 26262兼容。以下术语特别相关：风险：是可能导致损失事件的事故发生的概率和后果的综合度量。

安全：是指没有不合理风险导致损失事件的状态。Level 4自动驾驶车辆的损失事件可能包括可能归因于自动驾驶车辆设计缺陷或操作失误的致命事故。对于初期的自动驾驶车辆部署，关于“合理风险”的界定将受到公共政策决策的影响。

安全验证：证明系统级别的安全要求（安全目标）足以确保可接受的安全水平，并已经实现的过程。

安全论证（安全案例）：支持安全验证的书面论证和证据。

机器学习（ML）：一种采用归纳学习进行系统设计的方法，其中运行时系统使用学习过程的结果执行算法操作（例如，运行具有预先计算权重的深度卷积神经网络）。

本文假定在验证之前权重是固定的。对于在运行时修改权重或以其他方式学习的动态自适应ML系统的验证超出了本文的范围。

车辆测试和仿真的作用

在描述拟议的验证策略之前，回顾当前高度自动化车辆（HAV）安全评估方法中测试和仿真的典型用途将会有所帮助。.

超越 ISO 26262

处理许多潜在设计和实施缺陷可以并且应该通过采用已建立的安全标准，例如ISO 26262来完成。对于即使是一个完全工作的系统也可能无法提供完全安全功能的领域，可以使用覆盖“预期功能安全”（Safety of the Intended Functionality，SOTIF）的新兴标准。SOTIF标准可能提供了一种处理具有统计上有效功能的方法，例如基于雷达的障碍物检测功能。ML系统特有的其他问题也必须得到解决，如所述。总的来说，在功能安全方法中通常采用的V模型验证的问题在于，ML系统的功能对人类来说可能是不透明的。这使得可追溯性成为一个问题，到了人类进行追溯分析时，他们无法分析设计文档。

我们不试图按照V模型尝试设计到测试的可追溯性方法，相反，我们探讨了在ISO 26262和SOTIF标准的实际应用范围之外，特别是对于ML验证而言的，基于测试的方法可以做些什么。

系统测试/调试/优化作为基本策略

在原型自动驾驶车辆的制造过程中，历史上一直强调在道路上的测试。机器人领域严重依赖于“现实世界”测试，以便了解机器人需要的功能。然而，随着车辆从原型制造过程过渡到量产，验证的方法必须变得更加全面。

仅仅依靠累积道路里程来构建HAV安全性论证是一种不切实际的验证方法。这种蛮力的方法需要大量的里程才能形成一个可信的统计论证。而且，随着每次软件更改，无论是更新训练数据，添加新行为，还是进行安全修补，累积的道路测试证据的有效性都可能受到破坏。

实际上，如果经过数十亿英里的道路测试和仿真后的数据显示HAV未达到期望的安全目标，会发生什么？开发团队（或者说他们应该）在修复了任何观察到的缺陷后，是否会再进行数十亿英里的道路测试？还是团队只会修复那些可以容易地再现的错误，测试几英里，宣告胜利，然后开始部署？而市场竞争的压力将如何影响团队对结果的解释和验证方法？

实际上，几乎所有其他行业在软件系统的功能安全验证上，不是依赖试验部署，而是依赖测试和其他可以由独立评估人员评估的验证方法。如果自动驾驶汽车行业希望遵循这些先例，它将需要一种建立系统性、可辩护的安全论证的方法，尽管会遇到独特的验证挑战。

车辆级别测试和仿真的局限性

实际上，进行足够的普通系统级测试以确保生命关键系统的安全是不可能的。总的来说，这是因为汽车车队的暴露度非常高，生命关键的安全要求非常严格，因此测试无法积累足够的小时数来统计证明安全性。

对于HAVs，测试不可行性问题的一种表现是，必须安全地处理不寻常的情况，但在正常驾驶中这种情况相对较少。在道路上测试是观察偶发出现的罕见事件的一种低效方式。封闭赛道测试可以通过将它们设置为明确设计的测试场景，将已知的罕见事件设置为加速暴露的方式。例如，Waymo除了其道路测试项目外，还使用封闭赛道测试和大规模仿真进行测试。

即使是覆盖已知场景也可能面临资源限制的挑战，尤其是如果它仅涉及使用实体车辆。基于软件的车辆仿真可以通过在多台计算机上并行运行仿真来扩展测试场景的覆盖范围，但不可避免地涉及保真度与运行时成本之间的权衡，以及软件模型的完整性和准确性的问题。仿真可能无法仿真未预料到的情况（例如，未知的与安全相关的罕见事件）。

“影子模式”驾驶和SAE Level 3自动驾驶部署可以通过监控一个由人类驾驶员负责安全性的部署车队，增加暴露到现实世界驾驶场景的机会。然而，关于人类驾驶员是否能有效监督Level 3系统的安全性存在争议。

道路测试、封闭赛道测试、仿真和人工驾驶系统的监控在展示HAV安全性方面都有重要作用。然而，为了既有效又高效，它们应该以一种互补的方式组织在一起。（我们承认许多HAV开发者在验证方面采用了先进但专有的方法。在本文中，我们假定采用了一个基础的里程积累方法，以说明这些问题。）

为了仿真的真实性而仿真是低效的

当问到为什么在道路上使用真实车辆进行测试比仿真更好时，通常的答案是因为它更“真实”。毫无疑问，在真实世界中测试真实车辆至关重要。但是仅仅追求真实性本身是对测试资源的一种低效，最终是不可负担的使用方式。

仿真的有效性关键在于具有足够的真实性（仿真逼真度）以完成任务。有人著名地说过：“所有模型都是错误的，但有些是有用的。”由于仿真涉及系统的模型、环境的模型以及系统使用的模型，可以得出没有仿真是完美的。

仿真的逼真度是仿真在系统行为方面进行简化和假设的程度。低逼真度的仿真通常通过使用系统的简化表示（有时称为降阶模型）来快速执行，因此在某种程度上是“错误的”。高逼真度的仿真通常更复杂，执行成本更高，但包含的简化和假设较少，因此“错误性”较低。但是，这两种类型的模型都可以是有用的。

提高测试效率的关键在于认识到并非所有的真实性对所有测试都是有用的。举个简单的例子，对于确定计算机视觉功能是否能够看到道路上的孩子，建模道路表面摩擦系数通常是无关紧要的（摩擦系数可能与车辆能否及时停下来有关，但与是否能够检测到特定几何和环境场景是否会导致检测到孩子无关）。无论是在软件仿真（通过对不同道路表面进行建模）还是在仿真测试轨道场景（通过在柏油路上放置沙子或冰）中进行测试，都是如此。

有效和高效的仿真的关键在于考虑到被验证系统、各种逼真度模型以及操作环境的假设。因此，任何实际的验证工作都应该被视为一系列层次分明的抽象程度和逼真度的模型。以这种方式看，封闭场地测试是一种仿真，因为即使涉及的障碍和车辆是真实的，场景也是“仿真的”。验证HAV的安全性将需要确保HAV系统模型足够准确，同时还需要验证用于创建测试计划和测试仿真的环境和使用模型。

明确测试的目标一个强大的安全验证计划必须至少解决以下类型的缺陷，这些缺陷涵盖了系统、环境和系统使用方面的潜在故障：• 需求缺陷：系统需要做错误的事情（缺陷），不需要做正确的事情（间隙），或者具有ODD描述间隙。• 设计缺陷：系统未能满足其安全要求（例如，由于实现缺陷而导致），或未能适当地响应对定义的ODD的违规行为。• 测试计划缺陷：测试计划未能测试要求或设计中的特殊情况，或者有其他缺陷。• 鲁棒性问题：无效输入或受损系统状态导致不安全的系统行为或故障（例如，传感器噪声、组件故障、软件缺陷），或由于外部力量导致超出ODD的情况。HAV验证面临的挑战之一是不完整的需求和隐含的需求和设计表示。非确定性的系统行为进一步加大了问题的复杂性。这些挑战将必然影响到系统测试的方法和目标。（该前期研究侧重于识别验证自主性、运行时监视方法和失效操作方法方面的挑战。我们在这里构建在之前的研究基础上，讨论了验证方法的各个方面。）一般来说，将传统的功能安全方法应用于至少某些HAV功能时遇到的困难，促使我们考虑测试在整体安全验证过程中的不同可能角色，以及如何处理需求不完整的问题。

HAV的需求将不完整

HAV验证面临的主要挑战之一是，在可以测量行为正确性并为测试提供通过/不通过标准的情况下，需要开发一套完整的行为需求。例如，虽然一些工作正在进行中，以记录车辆的行为和场景，但并没有包含交通法规的完整、公开的机器可读性版本，其中还包括了异常情况的处理规则（例如，当以及如何穿越中央分隔线以避开道路障碍物？）。在本文中，“需求”一词主要是指系统级的行为需求，尽管这些概念也可以以其他方式应用。

需求间隙是进行道路测试数据收集操作的主要动机，这种操作有时被宽泛地称为“车辆测试”。从道路测试数据中推导系统需求的一般策略也会影响测试计划的完整性，因为将会有与系统行为需求（例如未知的和因此缺失的行为场景）对应的测试间隙。

重要的是要指出，严格来说，使用道路数据作为基础来训练机器学习的系统从未真正确定过需求。相反，训练数据集是某种代理，用于类似需求的内容。在其他情况下，分析道路数据可能被用于构建某种明确陈述的需求级别。成功验证HAV需要测试计划捕获和执行所需的行为，即使这些行为是隐含地表达的。无论形式如何，这些需求或需求代理对于许多初始HAV部署来说可能是不完整的。

作为调试的车辆测试可能不够有效

关于系统级测试的一种普遍观点是，它是发现软件缺陷（“错误”）并将其排除的一种方法。然而，车辆级别测试存在一个严峻的退化问题。一旦发现了涉及典型驾驶场景的易发现缺陷，要找到其他缺陷就会变得难上加难。特别是对于需要非常精确指定初始条件、涉及时间竞争条件或涉及计算运行时故障恢复的缺陷，这一点尤为明显，这些缺陷难以使用普通车辆接口诱发。在机器人领域，这个问题更严重，我们观察到微小的光照和几何变化可以触发不可重现的错误。通常情况下，可以预期许多这样的微妙错误在任何合理数量的车辆测试期间都会逃脱检测和诊断，并且在高度暴露的应用中，例如汽车系统，它们肯定会在实际场地中出现。

除了效率问题之外，任何将车辆测试作为缺陷排除的主要机制的项目在其安全世界观中存在根本问题。测试可以证明错误的存在，但不能证明错误的不存在。此外，当测试发现的所有缺陷都已经修复时，剩下的缺陷是测试程序无法发现的缺陷。因此，即使车辆级别测试完全找不到问题，也不意味着车辆的软件一定是安全的。这种推理方式实际上是得出结论：仅通过车辆级别测试来证明系统安全是不可行的方法。

车辆测试作为需求发现

一些形式的“车辆测试”实际上旨在发现需求。HAV开发工作中仍然在不断成熟的领域，可能存在需求间隙的示例包括：

• 检测和规避新的道路危险• 处理需要违反正常交通规则的特殊情况• 不寻常的车辆配置、表面和油漆作业• 误导性但格式良好的地图数据• 新颖的道路标志和特定于微观位置或事件的交通管理机制• 不寻常的道路标记和破坏• 由于HAV行为而引起的交通紧急情况• 恶意车辆行为（人类；受损的HAV）

虽然高度自动化车辆（HAV）的设计者应该设计以满足已知需求，但在可预见的未来，现实世界中将不可避免地出现不断的新型操作“意外”。相对于完全的第5级自动化，选择L4级自动化的主要理由在于HAV不必处理所有可能的情况。实际上，第4级自动化的一个重要可行性优势在于，在超出其操作设计域（ODD）时，只要其故障响应是安全的，它被允许展现出一种优雅的故障响应。事实上，如果L5级自动化在长期内仍然是一个难以实现的目标，也就不足为奇了。在所有可能的操作条件和场景中，L4级自动化可能逐渐接近但永远不会真正达到完全自动化。

需要指出的是，L4级自动化并不意味着HAV的安全保障论就不必考虑所有可能的情况，包括ODD违规和新型情况。一般的ODD概念似乎假设以下两种情况之一必须成立：（1）由于高度可靠的ODD约束（例如，在北美公共道路上通常不需要对袋鼠的道路危险行为进行强壮的预测），HAV不会遇到它无法处理的情况，或者（2）HAV将可靠地检测到它处于ODD之外的情况并将车辆带到安全状态（例如，不适用于袋鼠道路危险的车辆可能被地理围栏隔离在野生动物园和澳大利亚大陆之外）。实际上，ODD可能会在不被察觉的情况下被违反，这是由于对ODD范围的完全理解存在差距（例如，设计者根本没有考虑到袋鼠），或者验证计划中存在漏洞，漏掉了测试相关的ODD约束。

在道路操作中的适当应用是发现需求差距。遇到一些意外情况将导致需求更新，而其他情况则可能导致ODD参数或ODD违规检测需求的修改。在HAV首次遇到这种ODD“意外”时，HAV必须是可以接受的安全的。实现这一点是有问题的，因为按定义，这种情况是意外的，因此不是任何测试计划的设计部分。

由于没有完美的验证方法，一些设计缺陷可能会逃脱并通过道路测试或甚至在投入使用的车辆中被发现。然而，这应该是系统中发现的缺陷总数的非常小的一部分，而且即使这些缺陷导致系统安全关机或其他可用性丧失，也应该导致安全行为。如果在开发周期中有过多的缺陷逃脱并且直到道路测试时才被发现，那就表明需求、测试计划或验证方法的某些元素存在系统性问题。与任何安全关键设计过程一样，缺陷逃脱到生产系统中应该引发重大的响应，以纠正任何与导致这种情况的安全过程有关的问题。

区分需求发现和设计测试

关于道路测试的作用，一个关键的观点是，在寻找缺失需求方面累积车辆里程实际上并不是传统意义上的“车辆测试”。它是一个需求收集和验证的过程。另一方面，无论是道路数据还是仿真、合成数据和记录数据的组合是测试特定HAV设计的主要手段，更多地取决于设计团队的选择。只要设计经过了充分完整的需求验证，道路测试就不需要（实际上也不应该）是唯一的测试方式。

因此，减少HAV验证的时间和费用的一种方法是将（1）用于需求收集的道路测试与（2）用于设计和实施验证的测试分开。需要明确的是，为了寻找需要通过系统安全需求减轻的罕见但危险事件，需要进行数十亿英里的道路经验是不可避免的。但这并不意味着每次设计更改都需要重新进行那些数十亿英里的测试，至少如果采取比单纯的系统级测试更为复杂的方法的话。

车辆测试来减轻残余风险

我们可以概括一下这样一个观点：道路测试应该主要强调需求验证，而较低级别的仿真和测试应该强调设计和实施的验证。一般来说，任何级别的仿真（包括车辆测试的“仿真”方面）都有一定程度的保真度，正如前面所讨论的。这意味着它在某些方面也是“错误”的——正如所有模型都是错误的——这是由于其简化和假设。

通过集中测试计划，可以提高测试效率，检查较低保真度级别的仿真的假设和简化。与此同时，将尽可能多的仿真推向最低保真度的实际水平将减少仿真成本。例如，简单的编码缺陷应该在子系统仿真（甚至是传统软件单元测试和同行评审之前的预仿真）中被发现。另一方面，如果罕见事件的需求缺口是由于无法预见的因素导致的，那么最好在道路测试中发现它们。这导致了一种基于减轻每个仿真保真度级别的残余风险的方法，如下一节所讨论的。

分层残余风险方法

由于在短期内高度自动驾驶车辆（HAVs）的设计和需求信息通常不太可能是人类可解释的，因此必须使用除传统V模型之外的某种方法进行验证。为此，我们需要至少有一组（可能不完整的）安全需求。然后，我们必须找到一种方法，将一些组合的道路测试、封闭测试和仿真结果追溯到这些安全需求。

根据安全需求进行验证

在最高层面上，我们需要一些类型的系统需求，以确定测试实际上是否通过或失败。如果功能需求没有完全明确，那么我们需要其他东西。好消息是，可能不需要最佳性能来提供安全性。相反，更简单的需求可能足以定义安全操作。

例如，我们发现，基于安全范围禁止的一组不安全行为列表可能对某些自动驾驶车辆行为足够。在这种情况下，测试可以追溯到明确规定的安全需求，即使功能需求本身是不透明或未经记录的。指定安全范围的一种方法是使用分配给不同安全检查功能块的运行时不变量。作为一个简单的例子，车道保持的安全范围可以是车辆保持在其车道边界内外加上一定的安全边距。与根据道路几何和交通优化车辆车道位置的复杂算法的完美实现相比，这种方法更简单，更容易用作测试成功的判断标准。

尽管将测试追溯到明确定义的安全需求可能会有所帮助，但我们通过经验发现，安全需求通常难以理解，甚至在有用的详细级别上都没有记录。虽然对于不幸事件不应该发生的模糊概念是一个起点，但还必须有一种具体和具体的方法来确定一个测试是否表明系统是安全的。实际上，我们发现，一组部分的运行时不变量，它们指定了一种安全和不安全的系统状态空间包络的组合，可以根据测试和仿真结果不断改进，采取持续改进的方法。换句话说，解决缺失安全需求的问题的一种方法是从一组简单的规则开始，并随着测试违反这些简单规则的结果而随时间推移地加以完善。假阳性和假阴性的规则违反可以驱动规则集的细化。一般来说，如果从安全操作包络的安全性的角度来看，这种进化在开始时以对安全操作包络的过度近似（增加高假阳性率）为特点，并且当分析显示这样做是提高包络允许度的安全方式时，逐渐增加额外的包络区域（和伴随的测试成功标准细节）。

如果HAV设计团队试图通过基于机器学习的方法确定安全需求，那么对于人类安全论审查者来说，重要的是以一种可解释的方式表达结果。然而，目前还不清楚如何做到这一点。在这一点上，我们建议使用更传统的工程方法来定义安全需求，以避免ML-based功能陷入不可解释性的同样问题。

基于残余风险进行验证

尽管安全边界方法可以简化用于通过/不通过标准的需求模型的复杂性，但自动驾驶车辆（HAV）的测试仍需要运行大量场景，以获得合理的覆盖率。理想情况下，尽可能多的测试应该使用成本相对较低、保真度较低的仿真进行。然后，该方法应该增加保真度，不仅仅是为了无差别的“真实性”，而是为了减少低保真度仿真所做简化带来的残余风险。

管理残余风险

高保真度和低保真度仿真运行之间的重要关系不应该是“合理性检查”或统计抽样，而应该是强调验证在低保真度级别所做的假设和简化的正确性。换句话说，对于低保真度模型在某些方面“错误”的每个方面，较高保真度仿真（包括潜在的各种类型的物理车辆测试）应该负担减轻那个残余安全验证风险的责任。

这种方法在模型验证的重要方面与通常的观念不同。较高保真度级别的仿真不仅用于验证较低保真度模型的正确性，而且必须明确地设计为强调在仿真运行时已知存在的假设和简化的检查。较高保真度模型的主要目标应该是通过不仅检查较低保真度仿真结果的准确性，还要检查较低保真度模型所做的假设在进行较高保真度仿真时是否被违反，从而减轻那个残余风险。举个简单的例子，如果一个简化模型假设80%的雷达脉冲可以检测到一个目标，那么较高保真度的模型或车辆测试应该在只有75%的脉冲检测到目标时标志一个故障，即使车辆在较高保真度模型中表现得很安全。80%检测率的假设是低保真度仿真的一个残余风险，它做了这个假设。违反这个假设会使安全论无效，即使特定的测试场景碰巧幸免于不幸。

这种方法从根本上影响了仿真和测试活动的设计。例如，考虑一个探讨视野中障碍物摆放的仿真。仿真以非常精确的分辨率在环境中安排障碍物，但在固定方向上使用了只是简化的静态位置的基本图示行人对象。在改变障碍物摆放的同时进行数千次高保真度车辆测试，预计将在详尽的仿真结果之上产生很低的边际验证效益，特别是如果仿真运用了将在HAV中部署的实际几何处理代码。因为在这个例子中，障碍物相对于车辆的摆放位置在仿真完成后不再是残余风险的主要来源。主要的残余风险集中在行人身上。低保真度仿真假设图示人，从而忽略了携带大型物体的人、穿着显著扭曲传感器信号的服装的人、与车辆传感器的不同旋转位置等情况。

同样，任何提高仿真能力的改进都不应该仅仅追求使仿真在每个可能的维度上更高的保真度。例如，在仿真资源中，将道路障碍物摆放建模到纳米级别而不是毫米级别不太可能是一种普遍有效的使用。相反，仿真保真度的改进应该是为了用仿真替代必需的系统级别测试（例如，在前述基本图示例子中增加了表面纹理功能以及更多种类的几何形状和方向）。

这并不意味着仿真模型的验证和验证应该被忽视。相反，重点在于，即使在特定抽象级别上验证的模型完全有效，也会存在残余风险。这部分风险是由于可能存在不完整的测试活动，即未能完全减轻从较低保真度仿真继承的风险，或者未能充分覆盖分配给相应保真度级别的区域。另一部分风险是由于在特定抽象级别上故意排除的安全考虑，这对应于向上传递给更高保真度级别的风险。

因此，使用各种仿真保真度的运行的传统方法在HAV中仍然是有意义的。艺术在于确保在低保真度测试中的简化是得到明确处理和减轻的验证风险。

通过将测试偏向困难情景的加速评估方法与残余风险方法是互补的。强调困难情景旨在从测试集中剔除多余的正常路径测试，同时仍然覆盖非正常行为、边缘案例和复杂环境交互。另一方面，残余风险缓解方法解决了由低保真度层次的仿真和测试计划中所做的简化和未经检查假设带来的风险潜在问题。

残余风险的一个例子

表1显示了HAV测试和仿真计划中应该考虑的残余风险的简化示例。表格顶部的残余风险倾向于需求缺口（意外情景和意外环境条件）。相比之下，其他残余风险倾向于速度/保真度仿真权衡（例如，传感器数据质量）驱动的简化和潜在的设计问题（例如，子系统相互作用）在较低级别。

表格1. 假设的验证活动和对有效性的威胁。

回顾之前的障碍物检测示例，这意味着更高保真度级别，比如物理车辆测试，不应该主要关注障碍物的不同大小和摆放位置。相反，它们应该关注诸如物体和传感器上的污垢等其他在仅依赖软件仿真工具无法处理的方面。换句话说，车辆测试主要应该集中精力不是用于复制仿真结果，而是挑战仿真方法的任何已知弱点。具体情况会有所不同。关键是所有仿真工具都有某种限制，需要进一步的验证工作。

对于表格1中所示的例子，封闭场地测试不应该主要关注意外的人类驾驶员行为、恶化的基础设施或道路危险，因为减轻这些威胁是进行预部署道路测试的主要原因。预期的行为、道路危险等应该通过测试和仿真来处理。无法解决的意外问题无法在测试计划中明确包含，因为意外问题定义上不是测试计划中可以明确包含的内容。

在每个验证级别中，主要的重点应该放在从下一个更低级别继承的残余风险上，尤其是在修改了系统以确保系统仍然安全的情况下重新运行现有的仿真测试套件。通过测试来详尽地复制较低保真度仿真和测试的结果是低效的，而且如果随机抽样未能覆盖残余风险，这样做最多会产生一种虚假的安全感。

提高可观察性

在进行了彻底的仿真和车辆测试计划之后，必须提供足够的可控性和可观察性，以产生可信的安全验证结果。

可控性和可观察性

可控性是测试员控制被测试系统的初始状态和工作负载的能力。可观察性是测试员观察系统状态以确定测试是否通过的能力。

控制测试场景以引发特定自主系统行为是困难的。这是由于随机方法的使用（例如，随机路径规划器），对初始条件的敏感性（例如，在测试环境内完全可重复的传感器对准），执行器输出的变异性（例如，执行器与环境的非预期交互的变化）和计算时间的变化。

提高可控性的一个有用方法是使用可以避免物理世界随机性和约束的仿真。除此之外，可以提供一个系统测试接口，将系统强制置于测试的初始状态。例如，如果路径规划器的内部伪随机数生成器可以设置为预定的种子值，那么它就可以以可重复的方式进行测试。作为实际问题，确定性测试要求HAV软件有意地设计为提供确定性测试能力。在构建软件后，难以消除软件中的非确定性来源。

可观察性可能是一个更为困难的问题。例如，在车辆级别的障碍物测试中，车辆要么在通过障碍物时保持足够的间隙，要么不保持。但是，即使系统通过“通过”测试，避免与障碍物碰撞可能仅仅是因为系统在避免一个它甚至不知道存在的障碍物时运气好。系统可能会在下一次测试运行中撞上障碍物，或者可能在2000次测试运行后撞上它。这种缺乏可观察性是机器可读性问题的一个方面，该问题认识到人类理解机器系统的设计、操作和“意图”的困难。（机器与人类驾驶员的交互作用中机器可读性的额外作用是重要的，但超出了本文的范围。）

虽然可以说系统将不太可能因为愚蠢的运气而重复通过测试，但涉及到的测试参数数量庞大，这种论断中的“重复”部分会显得非常昂贵。而且，无论运行多少次测试，要在生命安全保障级别的测试中获得极高的统计显著性是困难的。（即使一个系统在检测到人行横道上的儿童时避免发生事故的置信水平为99.99%，如果可能导致1万个儿童中有一个被撞到，这似乎也是有问题的。）因此，总会存在这样一个残余风险，即某些组合的场景元素之间由于幸运连胜而通过测试，而不是由于安全设计。

软件测试点

与其仅依赖系统级别行为和简单的重复来确定测试是否通过，更高效的测试方法是在系统中插入软件测试点以提高可观察性。例如，如果传感器融合的可靠性是由于仿真限制而导致的残余风险，那么封闭场地车辆仿真的相关测试点将是监控传感器融合结果的计算确定性级别。这将提供关于测试障碍物是否以预定的误差边界避免而不仅仅是运气的信息。(软件测试点可能干扰系统测试是因为测试点被设计为系统的永久组成部分。这将进一步促进在部署系统中进行数据收集。)

软件测试点还可以方便在车队部署期间监控安全论点假设的违反情况。先前讨论的80%的检测率假设的例子不仅可以在测试期间监控，而且还可以在全面部署车辆上监控，以便检测假设违反是否已经传递到了实际系统。

通过正确的原因来进行测试

当人类参加驾驶测试时，测试考官对驾驶员在方向盘后的行为有一个相当准确（或者至少是有用的）的心理模型。如果驾驶员在变道时没有与后视镜进行眼神交流或者未在目标车道内检查其他车辆就变道，考官知道驾驶员之所以没有发生碰撞是因为侥幸而不是正确行为。但是对于高度自动化车辆（HAV），这种评估更加困难，因为不清楚机器表现安全行为与侥幸避免危险行为之间的“线索”是什么。特别是如果要求和设计无法通过基于V形安全过程的追踪得知，这一问题就更为复杂。

如果HAV的安全性部分基于类似驾驶测试的事件，那么考官必须知道HAV不仅要以正确的方式行为，而且必须有正确的原因。即使没有正式的驾驶测试，通过从明确的系统信息中合理推断行为的因果关系可以降低测试成本，而不是采用粗糙的统计方法。HAV自报显著区域、物体边界框等功能并不是一个新的想法。然而，如果能够在安全论证中明确包含这些功能，可以在正确的情况下降低测试成本。这可能会激励进一步的工作，以验证自我报告和可解释性机制的可靠性。

将情景与行为相结合的一种方法是让HAV自行报告它认为自己所处的情境，或者认为自己所处情境中的各种元素。例如，车辆在可以变道时，不仅仅是进行车道变更，它还可以报告：“我想要变道……我正在检查下一个车道，有一辆车在那里，但是它离我足够远，我可以顺利变道……我开始变道……我继续监视车道确保它仍然是空的……后面的车在加速缩小间隙……”等等。一些HAV架构可能已经提供了这种程度的可观察性。问题在于这种信息在验证策略中是否被正式使用。而且，许多流行的方法（例如端到端深度学习）明确避免了架构的模块化，这样做可能会降低可观察性。他们这样做的目的是为了实现更高的性能、更紧密的实现和更少的开发工作。缺乏可观察性可能会在验证工作或系统部署风险方面付出高昂的代价。

一个有效的驾驶测试不仅应该要求正确的行为，还应该要求HAV正确地阐述它的行为原因。这只是一个好的开始，但我们必须质疑机器对其行为解释的真实性。然而，我们认为决定是否相信明确的解释相比通过行为观察来推断（然后相信）不透明的隐式解释更容易解决。无论哪种方式，都必须决定车辆在未来的情况下是否会采取正确的行动，而这些情况与培训和测试数据集并不完全相匹配。明确解释的优势在于，如果需要与测试计划的叙述相匹配，那么该机制的有效性是可以被证伪的。在设计安全关键系统时，我们更喜欢明确、可验证、简单的模式，即使它们的性能可能较差，而不是那些高度优化但不透明的模式。我们有理由相信，考虑到试图部署难以验证的系统可能带来的后果，这种趋势在HAV中也会持续存在。

设计这样一个系统将需要引入或确定可观察性以进行验证。这可以通过将现有数据转换为人类可解释的形式的工具，将测试点添加到系统架构中，或者重新设计系统以有意地创建新形式的人类可解释数据来实现。（图1）

图1：系统验证应确保系统出于正确的原因做出正确的事情

对于机器学习系统，这种方法提出了一种相对不寻常的设计策略。与其让机器学习系统学习实现某个结果所需的特征集，不如让它同时实现两个并行目标：（1）展现正确的行为，以及（2）展现与其行为相匹配的一组叙述描述或其他解释。实现这一目标的方法之一是使用环境和使用场景的模型来定义必须学习的机器学习输出集合。虽然这可能被视为额外的设计负担和开销，但这可能是确保车辆是否足够安全以投入使用的代价。

为了避免行为与叙述不匹配，一个可能的方法是将机器学习系统分为两个不相交的阶段进行操作：首先创建叙述，然后使用叙述作为其行为的输入，如图1所示。第一阶段可以建立在已有的关于场景描述和层次分类的工作上。系统的执行应该对叙述做出响应，第二阶段应该完全依赖于第一阶段的输出。这种依赖性可以减轻生成与系统行为策略不匹配的并行叙述的风险。

应对不确定性

已知和未知

即使是经过验证并且表面上没有缺陷的系统，由于对系统及其需求了解不完全，仍然存在由此产生的问题的剩余风险。这些问题包括但不限于以下几种潜在类型的问题：

未在适当验证阶段考虑的新出现的系统属性和相互作用。在安全性依赖于隐含独立性假设的区域中，未预料到的相关故障。发生得太少以至于无法通过部署前道路测试进行诊断的情景和环境异常。对未缓解危险的到达率存在不确定性，而这些危险被假定为极为罕见。在ML组件中激活不明缺陷的系统输入。

当然，上述未列出且至少在某些HAV验证计划中没有包含的其他类型的缺陷可能存在。这就是那些可能危及安全性并导致其他系统故障的“未知未知”。处理未知缺陷

即使采用安全边界等方法，最终仍然无法完全消除来自未知类型缺陷的剩余风险。然而，可以通过监控意外故障的到来来增加对剩余风险足够低的信心。必须认识到未知问题是一种必须在车队的整个生命周期中进行监视和必要时进行缓解的剩余风险。扩展至包括未知未知的信心评估框架是一种方法，它可以提供一种管理剩余风险的途径。

每当一个意外事件导致安全问题时，都应该采取额外措施来处理由新发现的问题无效化的底层系统和安全论证假设（这符合现有的安全实践）。必须对意外故障进行根本原因分析，以至少确定该问题是一个已知未知（在这种情况下，你现在更了解它了），还是一个未知未知（在这种情况下，你需要为你的验证计划和安全论证添加一个新的问题类别，以解决这个新的意外问题的来源）。

HAV成熟度

将“驾驶测试”作为HAV验证的一部分具有相当直观的吸引力。然而，类似于将HAV带出进行道路测试，就像进行人类驾驶测试一样，这个类比并不足够，因为人类驾驶测试实际上包含两个关键元素。第一个元素是明显的，明确要求驾驶员必须展示基本的驾驶知识和熟练技能，包括驾驶技能测试。

通过驾驶测试的第二个更微妙的部分是，驾驶员必须年满16岁，根据地区的不同，这个年龄要求作为具有合理成熟判断力的代理，可以处理特殊情况，并在遇到新的非结构化情况时通常表现出合理的行为。在现实世界中，正确的车辆操作部分依赖于交通法规。然而，它也取决于警察是否能够以熟练但主观的方式判断驾驶员在特定情况下是否表现出合理和负责任的行为（在混合人类/自动驾驶交通中，“与他人相处得好”是一种重要的HAV特性）。

虽然有可能（有人说是肯定的）HAV的行为可能比人类更安全，但如何衡量HAV的“成熟度”，以确保实现这一理想的结果，目前仍然是一个未解之谜。

衡量HAV的成熟度的一种方法是部署车辆并观察它们的表现。这就是支持部署SAE Level 3自动驾驶技术的一个论点，该技术实际上使用了一个成年监护人的角色，在学习许可证操作期间，监视初学驾驶员。然而，人们担心，在长时间曝露下，由于驾驶员退出，驾驶员监督可能会变得无效，尤其是当自动化发生罕见故障时。

我们提出了两种不同的方法，用于评估HAV的成熟度，超越了开发者遵守传统安全关键软件工程原则。第一种方法是确保HAV以正确的原因通过详细的技术驾驶技能测试，并且第二种方法是监测在实际应用中HAV验证的假设和剩余风险是否持续有效。换句话说，如果车辆能够以对人类有意义的方式解释其行为，并且在实际操作中，其安全性论证假设是成立的，那么可以认为系统设计是成熟的。

HAV试用期：监控假设

任何负责任的HAV部署决策都不能简单地接受“我们修复了所有我们找到的错误，所以我们肯定是完美的”这种说法，因为这从来不是现实的反映。总是会有一个新的错误。相反，基于分阶段验证的安全论证至少应该基于从每个验证阶段的缺陷逃逸率进行测量的数据。这表明，观察性测试点应该被保留，并在整个车队部署过程中进行监视。这样做可以通过确保没有使假设无效的车辆操作情况，来监控系统设计的成熟度。如果通过运行时监控检测到大量假设违反，那么这可以为设计团队提供对受损安全边际的宝贵反馈。通过这种方式，即使没有发生实际事故，也可以识别安全论证的问题。

以HAV道路测试为例，这是前面讨论过的假设违反的另一个例子。显然，并非所有的中断都是相等的，特别是考虑到各个团队可能会因为触发中断的误报率不同而有所不同。

使用诸如正交缺陷分类（ODC）的方法可能会揭示，例如，某些中断是由于应该在子系统仿真中捕获的问题引起的，而其他中断则是由于在最高级别发现的需求或场景差距。虽然我们希望HAV开发团队会对中断进行一些分析，但是将缺陷映射回验证计划中的剩余风险的系统性分析具有显著的潜在好处，比如为安全论证和HAV的整体成熟度提供健康指示。

这种方法可以通过呈现每个验证阶段的风险缓解目标的一组经过良好推理的数据来支持对自主验证的外部评估。这些目标可以与通过仿真、车辆测试和部署期间的相关可观察性点测量的缺陷逃逸数据配对使用。所有这些都意味着“驾驶测试”实际上不是一个一次性事件，而是一个基于在系统的生命周期中收集和分析缺陷逃逸领域数据的持续“驾驶执照”更新过程。

带有剩余风险部署

必须承认，本文讨论的是在HAV中存在剩余风险的情况下进行部署，尤其是在需求和设计验证中可能存在的缺陷。这是与该领域和所部署技术固有的。在能够提出剩余风险可以下降到通常的安全性阈值以下的统计学依据之前，积累统计上具有辩护性的数据可能需要一段时间（例如，在每10的9次方或10的10次方操作小时中发生的灾难性车辆事故的数量）。鉴于当前HAV市场和法规环境，似乎可能在收集到这样的数据之前，就已经开始大规模公开部署。

无论多么吸引人，部署HAV都必须以负责任的方式进行。特别是，不应该盲目接受剩余风险。相反，所有级别的剩余验证风险都应该被明确理解，并且在部署过程中进行监视。例如，一个可信的论据，即特定类别的剩余风险可能导致低后果、高生存率或极为罕见的事故，可能是确定其“可接受性”的合法动机，即使风险的全部范围不清楚。然而，任何这样的论据应该得到实地反馈数据的支持，以确定支持接受此类风险的假设是否实际成立，最好不要等到严重损失事件积累起来。

部署时存在残余风险

重要的是要承认，本讨论考虑的是部署具有残余风险的高度自动化车辆（HAVs），特别是在需求和设计验证方面可能存在的差距。这是与该领域和正在部署的技术固有的。在能够提供统计上可靠的数据以证明残余风险降低到通常的安全关键系统安全阈值之下（例如，每10^9或10^10操作小时内发生一次灾难性车辆事故）之前，需要一段时间。考虑到当前HAV市场和监管环境，似乎公开部署将在收集到这样的数据之前进行扩大。

无论高度自动化车辆的吸引力有多大，都必须以负责任的方式进行部署。特别是，不应该盲目地接受残余风险。相反，残余验证风险在各个层面上都应该得到明确理解，并且在部署过程中进行监测。例如，可靠的论据，表明某种类别的残余风险可能导致后果轻微、高度可生存或极为罕见的事故，可能是确定其“可接受性”的合理动机，即使风险的全部范围不清楚。然而，任何这种论据都应该得到实地反馈数据的支持，以确定支持接受此类风险的假设是否真实，最好是在等待严重损失事件积累之前。

最终会涉及到伦理问题，例如，如果预期通过部署不完美的技术能够节省生命，那么是否更好。特别是，安全专业人员面临着一个实际选择，即是否参与发布一个具有未知（并且在短期内无法知道）但存在安全风险的安全关键系统，或者他们错过了提高高度自动化车辆相对安全性的机会，而这些车辆必然会在有或无他们的帮助下进行部署。本文的目标之一是提供一个在这些系统部署之前验证这些系统的框架，以提高开发者识别和管理接受的风险的能力。

结论

总结一下，我们描述了一种HAV验证方法，包括以下几个元素：

• 一个分阶段的仿真和测试方法，强调通过测试来减轻前一阶段残余验证风险，同时利用了在测试和仿真中固有的速度与准确度的可伸缩性。• 观测点产生人类可解释的数据，既可以检测低保真度仿真阶段中的缺陷，又可以证明系统出于正确的原因正在做正确的事情。• 明确区分测试的各种角色，从检查需求差距到检查设计缺陷，将每种类型的测试与分阶段验证方法的相关部分相匹配。• 一种用于管理已识别风险的运行时监控方法，捕获在部署系统中出现的假设违规和未知未知因素。

这种方法可以预期相对于蛮力测试活动而言，提高了验证效果，因为它明确地将测试和仿真活动与正在减轻的风险联系起来。这反过来又使得可以集中精力在每个特定仿真和测试准确度水平的缺陷检测的“甜蜜点”上。该方法还可以预期提高测试效率，因为每个测试阶段都可以集中精力在减轻从前一阶段继承的风险上，而不会浪费资源重新审查低风险结论或试图处理属于其他测试阶段的范围之外的风险（其他验证形式也很重要，比如对系统功能的适当部分使用ISO 26262方法。）

我们认识到，由于确定性地建立机器学习功能的安全性存在挑战，这里提出的方法将产生一个持续改进的过程，而不是完全确凿的安全性证明。然而，该方法将强调出做了哪些假设，以及哪些安全案例证据缺失。验证该方法和系统的一种方式是创建一个按照目标结构化标注组织的安全案例（例如，从开始），并包含明确陈述的假设以完成论证。每个假设都确定了一个测试或仿真技术的残余风险。由其他验证方法检查的假设形成安全论证链的一部分。在设计时无法验证的假设是部署系统中非常重要的残余风险，特别适合进行运行时监控。

在某个时刻，设计者将不得不决定一个负责任的部署计划，该计划可能涉及接受根据一组可辩护的技术和社会标准判断为可接受的风险。为了最小化无法减轻的残余风险，我们建议避免使用只能通过传统安全方法验证的自治架构作为确保操作安全性的唯一手段。一个替代方案是使用可以根据ISO26262适当评估的安全检查器，比如安全包络监控器。

虽然确保所有残余风险都已知并减轻到可接受的水平总是更好的，但明显的是，即使在安全论证中存在风险不完全明了的地方，HAVs也将被部署。本文讨论的方法提供了一个基于多个仿真和测试准确度水平的初步安全论证的框架。它还为基于监测假设违规和测试部署过程中的其他残余验证风险的持续改进提供了依据。

我们的下一步是完善建立安全需求与测试和仿真计划之间可追溯性的技术，并将此方法应用于大规模验证活动。

（欢迎申请加入智能驾驶交流学习群，加小编微信号zhijiashexiaoming）