一个高度自动化汽车的安全验证架构
*本文翻译自Juan R. Pimental所著Safety of the Intended Functionality (SOTIF) Book 3 - Automated Vehicle Safety Series，中文版权归轩辕实验室所有
验证高度自动化车辆(HAVs)的安全性是一项重大的自动驾驶挑战。HAV安全验证策略仅仅基于原始的道路测试是不可行的。虽然模拟和使用边缘案例场景可以帮助降低验证成本，但如果不采用验证数据收集和安全分析的更细致的观点，仅使用这些技术不太可能为全面部署提供足够的保证。验证方法可以通过使用高保真度测试来显式验证低保真度测试的假设和简化，而不仅仅是获得低保真度测试结果的抽样复制，从而得到改进。分离多个测试目标可以通过分离需求的验证过程、环境模型的充分性、自治正确性、自治健壮性和测试场景的可靠性来提供帮助。对于具有隐式设计和需求的自主方法，如机器学习训练数据集，在主要结构中建立观察点可以帮助确保车辆在正确的原因下通过正确的测试。这些原则可以提高证明HAV安全性的效率和效率，作为包括驱动测试和生命周期监控以及阶段性验证计划（用于明确管理验证不确定性的）的一部分。
1 简介
尽管面临着跨学科的重大挑战，高自动化车辆(HAVs)的大规模部署似乎迫在眉睫。目前，还没有就验证这些车辆的非传统软件方面的安全性的技术策略达成普遍共识。考虑到NHTSA（国家公路交通安全管理局）对自动车辆技术安全的非监管方法，似乎只要开发团队认为他们的车辆准备好了，就会部署许多HAV，然后他们就会看到公共道路上的情况如何。即使试点部署的事故发生率低到可以接受的程度，但仍存在一个问题：有限规模的部署能否准确预测更大规模部署的安全性，以及随之而来的软件更新。
我们经常看到这样的声明：累积道路里程将验证HAV系统的安全性，特别是在试图描述开发工作进展的情况下。即使提到了其他形式的验证，对这个主题更全面的讨论仍然倾向于着重强调测试的作用。然而，即使使用封闭的车道和高可靠性的模拟，在部署之前进行的车辆水平测试的数量也是有限制的。
本文的范围是验证需要超越ISO 26262规范，并强调SAE 4级自动驾驶。第4级HAV只需要在指定的运行设计域(ODD)内进行自主操作，这就避免了系统在特定的条件下运行。
一种超越里程积累的HAV自主安全验证方法是非常可取的。最好，它还应该基于一个伪造的方法，包括具体的，可测试的安全目标和要求。本文提出了一些方法来提高HAV有效性，从而得到一个更合理的安全论证。分层的验证步骤可以帮助支持这样一个结论，即HAV系统是可接受的安全的，即使在没有完全规定的自动功能的传统功能需求集的情况下也是如此。
我们相信，HAV的验证工作可以通过应用以下理念得到显著加强:
1．通过分别管理需求验证和设计验证，将测试的不同目标分开。
2．在低保真度模拟和测试中，使用高保真度模拟和测试来减少由于假设和差异而产生的剩余风险。
3．在HAV体系结构中提供可观察性，来确保测试以合理的原因通过。
4．在安全参数中明确不确定性的管理。
尽管这些想法是基于某些领域的现有实践，但是HAV技术的新颖性和HAV商业化的速度促使我们对如何应用这些想法来管理和降低HAV部署的风险进行清晰、统一的描述。
术语
我们的术语通常与ISO 26262兼容。下列用语特别相关:
风险:对可能导致损失的事故的概率和后果的综合衡量。
安全:没有造成损失的意外事故的不合理风险。4级HAV损失事件包括可能由于HAV设计缺陷或操作故障而导致的死亡。对于最初的HAV部署，公共政策会对可能构成合理风险的评估产生影响。
安全验证:证明系统级安全需求(安全目标)是确保一个可接受的安全水平的关键，并且已经实现。
安全论证(安全案例):支持安全验证的书面论证和证据。
机器学习(ML):在系统设计中使用归纳学习的一种方法，其中运行时系统使用学习过程的结果来执行算法操作(例如，运行具有预先计算的权值的深度卷积神经网络)。本文假设在验证之前权重是固定的。验证在运行时修改权重或以其他方式学习的动态自适应ML系统超出了本文的范围。
2 汽车的测试和仿真
在描述提出的验证策略之前，首先回顾当前HAV安全评估方法中测试和仿真的典型应用。
在ISO 26262之外
处理许多潜在的设计和实现缺陷可以，而且应该通过使用已建立的安全标准，如ISO 26262来完成。对于那些即使是一个完美工作的系统也可能不能提供完全安全的功能的领域，可以使用[9]来覆盖预期功能的安全性(SOTIF)的新标准。SOTIF标准可能提供一种方法来处理具有统计有效功能的函数，例如基于雷达的障碍检测函数。如[10]中所讨论的，还必须解决针对基于MLB的系统的其他问题。总的来说，在功能性安全方法中，根据V模型进行验证的典型问题是ML系统功能对人是不透明的。这使得可跟踪性问题执行可跟踪性分析的人员不能分析设计工件。
我们并没有根据V模型尝试设计到测试的可跟踪性方法，相反，我们探索了以测试为中心的方法在ISO 26262和SOTIF标准的实际应用范围之外可以做什么，这些标准并不是为ML验证设计的。
在自动驾驶汽车原型设计中，道路测试一直是重点。机器人领域严重依赖于真实世界的测试，以便了解机器人需要什么特性。然而，随着汽车从原型过渡到生产，验证方法必须变得更加全面。
将HAV安全论证完全建立在累积道路里程的基础上是验证安全的一种不切实际的方法。这种方法需要大量的里程才能得出可信的统计数据。除此之外，累积的道路测试证据的有效性也会随着软件的变化而受到潜在的破坏，无论是对训练数据的更新，新行为的添加，还是仅仅是一个安全补丁。
作为一个实际问题，如果在数十亿英里的道路测试和模拟后，数据显示HAV没有达到预期的安全目标，会发生什么?开发团队(或者他们应该)在发现任何观察到的缺陷后，进行另外的十几亿英里的道路测试吗?或者团队只是修补那些容易复制的bug，测试几英里，然后宣布胜利，然后继续部署?来自市场竞争的巨大压力的现实将如何影响团队对结果的解释和验证方法?
基本上，所有其他行业的软件系统的功能安全验证都不是基于试用部署，而是基于测试和其他可以由独立评估人员进行评估的验证方法。如果HAV行业希望遵循这些先例，它将需要一种方法来建立一个系统的、可辩护的安全论证，可以由独立的一方进行评估，尽管存在许多独特的验证挑战。
实际上，不可能执行足够的普通系统级测试来确保生命关键系统的安全性。一般来说，这是因为汽车车队暴露在空气中的时间太长，对生命安全的要求又太严格，所以检测无法积累足够的暴露时间来证明安全性。
对于高速公路，测试不可行性问题的一个表现是，异常情况必须安全处理，但在正常驾驶中相对少见。道路测试是观察偶然发生的罕见事件的一种无效方法。通过将它们设置为明确设计的测试场景（例如，封闭过程测试）可以加速对已知罕见事件的暴露。通过将测试用例的分布向更复杂的已知场景倾斜，可以进一步加速评估。例如，Waymo除了道路测试程序外，还使用封闭课程测试和广泛的模拟。
由于资源的限制，即使覆盖已知的场景也可能是具有挑战性的，如果它只涉及到使用物理车辆。基于软件的车辆仿真可以通过在多台计算机上并行运行仿真来扩大测试场景的覆盖范围，但不可避免地会涉及保真度与运行时成本之间的权衡，以及关于软件模型的完整性和准确性的问题。模拟不包括模拟未预料到的情况(例如，未知的安全相关的罕见事件)的可能性。
影子模式驾驶和SAE 3级自动驾驶部署可以通过监视部署的车队来增加对真实驾驶场景的暴露，其中人类驾驶员负责安全。然而，在三级系统中，人类驾驶员是否能够有效地监督安全存在争议。
道路测试、封闭过程测试、仿真和对人工系统的监控在演示HAV安全性方面都具有重要的地位。然而，为了同时有效和高效，它们应该以一种互补的方式组织起来。(我们认识到许多HAV开发人员都有复杂但专用的验证方法。在本文中，我们假设一个朴素的里程计算基线方法来说明这些问题。)
仿真现实本身是低效的
当被问及为什么用真实车辆进行道路测试比模拟测试更好时，一个典型的回答是它更真实。最终，在现实世界中测试一辆真实的汽车是很重要的。但是现实主义本身是对测试资源的无效的，并且最终是不可避免的。
仿真有效性的关键是具有适当的真实性(仿真可靠性)来完成工作。众所周知，所有的模型都是错误的，但有些模型是有用的。由于模拟涉及系统模型、环境模型和系统使用模型，因此没有模拟是完美的。
仿真的可靠性水平是对系统行为进行简化和假设的程度。低保真度仿真通常通过使用简化的系统表示(有时称为降阶模型)来快速执行，因此在某种意义上是错误的。高可靠性仿真通常更复杂，执行起来也更昂贵，但是包含的简化和假设更少，因此错误更少。但是这两种模型都是有用的。
提高测试效率的关键是要认识到，并不是所有的现实主义对所有测试都有用。作为一个简单的例子，模拟路面摩擦系数通常与确定计算机视觉能力是否能看到路上的孩子无关。(摩擦系数可能与车辆是否能及时停车有关，但与特定的几何和环境场景是否能检测到儿童无关。)无论测试是在软件模拟中(通过对不同路面进行建模)，还是在模拟测试轨道场景中(通过在停机坪上的沙子或冰)，都是如此。
有效的仿真的关键是不仅要考虑被验证的系统，还要考虑系统和操作环境的各种可靠性模型所作的假设。因此，任何实际的验证都应该被看作是一系列不同抽象和可靠性层次的模型。从这个角度看，封闭过程测试是模拟的一种形式，因为即使涉及的障碍和车辆可能是真实的，场景也是模拟的。验证HAV安全性不仅需要确保HAV系统模型非常准确，还需要验证用于创建测试计划和测试模拟的环境和使用模型。
3 明确测试的目标
一个具有健壮性的安全验证计划必须至少解决以下类型的缺陷，这些缺陷包含了系统、环境和系统使用中的潜在故障:
•需求缺陷:系统被要求做错误的事情(缺陷)，不被要求做正确的事情(缺口)，或者有一个运行设计域类型的缺口。
•设计缺陷:系统未能满足其安全要求(例如，由于实现缺陷)，或未能正确响应所定义的运行设计域。
•测试计划缺陷:测试计划未能在需求或设计中执行个别用例，或者存在其他缺陷。
•鲁棒性问题:无效的输入或损坏的系统状态会导致不安全的系统行为或故障(例如，传感器噪音、组件故障、软件缺陷)，或由于外力导致的超出正常范围的偏移。
HAV验证面临的挑战包括不完整的需求以及需求和设计的隐式表示。不确定的系统行为进一步使问题复杂化。这些挑战必然会影响系统测试的方法和目标(以前的文章集中于确定在验证自治、运行时监视方法和故障操作方法方面的挑战。我们在前面的工作的基础上讨论了验证方法的各个部分)。
一般来说，将传统的功能性安全方法应用到某些HAV功能上的差异会促使我们考虑测试在整个安全性验证过程中可能扮演的不同角色，以及处理需求不完全的问题。
HAV需求是不完整的
HAV验证的一个关键挑战是，需要开发一组完整的行为需求，然后才能测量行为正确性，从而为测试提供通过/失败的标准。例如,尽管努力正在记录车辆行为和场景(例如,飞马项目),没有一个完整的、公共的机器——可判断的交通法规,包括异常处理规则(例如,何时以及如何可以车辆交叉中心分界线,如果存在,为了避免车道阻塞?)。我们在本文中使用术语需求主要是指系统级的行为需求，尽管这些概念也可以应用于其他方面。
需求缺口是道路车辆数据收集操作的主要动机，有时称为车辆测试。从道路测试数据推断系统需求的一般策略也影响了测试计划的完整性，因为在系统行为需求(例如，未知的，因此缺失的行为场景)中会有与之对应的测试缺口。
需要注意的是，严格地说，使用道路数据作为训练机器学习基础的系统从来不会识别需求本身。相反，培训数据集是类似于需求的代理。在其他情况下，对道路数据的分析可能被用来构建某种程度的明确声明的需求。成功地验证HAV需要测试计划捕获并执行所需的行为，即使是隐式表达的。不管采用何种形式，对于许多初始HAV部署来说，这些需求或需求代理都可能是不完整的。
用于调试的车辆测试
系统级测试的一个常见观点是，它是一种发现软件缺陷(bug)并删除它们的方法。然而，在明确85个车辆水平测试的目标方面存在一个急剧下降的问题。一旦发现了涉及典型驾驶场景的bug，就会戏剧性地发现更多的缺陷。特别是对于那些需要非常精确地指定初始条件的缺陷，包括时序竞争条件，或者从计算运行时故障中恢复的缺陷，这些缺陷很难用普通的车辆接口来诱导。这一问题在机器人领域更为严重，我们已经观察到，光线和几何形状的微小变化会触发无法复制的bug。一般来说，可以预期，在任何合理数量的车辆测试中，许多这种微小的bug将无法被检测和诊断，并且在实际应用中是不可重现的。然而，它们肯定会在诸如汽车系统等高曝光应用领域出现。
除了效率问题外，任何使用车辆测试作为其主要缺陷消除机制的项目在其安全世界观中都有一个根本问题。测试可以证明bug的存在，但不能证明它们没有。此外，当通过测试发现的所有bug都被修复后，剩下的bug就是那些测试程序没有设计来发现的bug(农药悖论)。因此，即使车辆级别的测试没有发现任何问题，这并不意味着车辆的软件一定是安全的。这条推理线只是得出结论的另一条路径，即仅进行车辆级别的测试是证明系统安全性的一种站不住脚的方法。
用于发现需求的车辆测试
一些形式的“车辆测试”实际上是针对需求发现的。尚未成熟的HAV开发工作很可能存在需求缺口的领域包括:
•检测和规避新的道路危险
•处理需要违反正常交通规则的异常情况
•不寻常的车辆配置、表面和油漆作业
•具有误导性但格式良好的地图数据
•针对微位置或事件的新颖路标和交通管理机制
•不寻常的道路标记和破坏行为
•由HAV行为引起的突发交通事故
•恶意车辆行为(人类;妥协HAV)
HAV设计人员应该针对已知的需求进行设计，而在可预见的未来，在现实世界中不断出现新的操作意外是不可避免的。第4级自动化而不是第5级完全自治的一个基本原理是，HAV不必处理所有可能的场景。相反，4级自动化的一个重要的可行性好处是，只要故障响应是安全的，就允许它在运行设计域故障之外表现出此类故障。事实上，从长远来看，如果5级自动化仍然是一个难以捉摸的目标，4级自动化在逐渐接近它，但实际上从未在所有可能的操作条件和场景中实现完全自动化，这并不奇怪。
需要指出的是，4级自动化并不能免除HAV安全保证的争论，因为它必须处理所有可能的场景，包括运行设计域的违规和新奇的场景。运行设计域的一般概念似乎假定下列两种情况之一为真:(1) HAV将不会遇到由于高可靠的运行设计域约束而不能很好地处理的情况(例如, 北美公共道路上通常不需要对袋鼠的道路危险行为进行稳健预测),（2)HAV会可靠地检测到外面的情况,使车辆保持安全的状态(例如,未被列入袋鼠公路危险等级的车辆可能被用土墙隔离在野生动物公园和澳大利亚大陆之外)。在现实中，由于对运行设计域的完整范围的理解存在差异(例如，设计者从未首先考虑过袋鼠)，或者验证计划中遗漏了对相关运行设计域约束的测试，所以运行设计域有可能在未被检测到的情况下被破坏。
在公路上作业的一个适当的用途是发现需求缺口。遇到一些意想不到的场景将导致需求更新，而其他的将导致运行设计域参数或冲突检测需求的修改。重要的是，当它第一次遇到这样一个意外时，必须是可以接受的安全。实现这一点是有问题的，因为通过定义，这样的场景是意料之外的，因此不是任何测试计划的设计部分。
由于没有一种验证方法是完美的，一些设计缺陷很可能会通过道路测试，甚至在已部署的车辆中被发现。然而，这应该是系统中发现的缺陷总数中非常小的一部分，并且这些缺陷应该导致安全行为，即使该行为确实导致了系统安全关闭或其他可用性损失。如果过多的缺陷部分在开发周期中逃脱了检测，并且直到道路测试才被发现，那么这就表明了需求、测试计划或验证方法的其他一些元素存在系统问题。与任何安全关键的设计过程一样，缺陷转移到生产系统应该引起重大响应，以纠正导致这种情况的任何安全过程问题。
分离需求发现和测试设计
因此，减少HAV验证的时间和费用的一种方法是将(1)在路上的需求收集与(2)设计和实现验证分开。要想找出特殊且危险、需要通过系统安全要求加以缓解的事件，显然没有办法绕过需要数十亿英里的道路经验。但这并不意味着设计验证需要对每一次设计更改重新进行数十亿英里的测试，至少在采用了比蛮力系统级测试更复杂的方法的情况下是如此。
车辆测试以减少剩余风险
我们可以推广这样的概念，即道路测试应该主要强调需求验证，而较低级别的模拟和测试应该强调设计和实现的验证。一般来说，任何级别的模拟(包括车辆测试的模拟方面)都具有前面讨论过的特定级别的可靠性。这意味着它也是错误的，就像所有的模型在某些方面都是错误的，因为它的简化和假设。
提高测试效率的方法是将测试计划集中在各个层次的测试上，检查仿真的低层次的假设和简化。同时，尽可能地将仿真工作推到最低的实际水平，可以降低仿真成本。例如，应该在子系统模拟中发现简单的编码缺陷(或者甚至通过传统的软件单元测试和同行评审进行预模拟)。另一方面，如果它们是由不可预见的因素引起的，那么在路上测试中发现的罕见事件需求缺口可能是最好的。正如下面一节所讨论的，它导致了一种基于降低每个级别的模拟可靠性的剩余风险的方法。
4 一个分层处理剩余风险的方法
由于完整的人类可解释的设计和需求信息在短期内不太可能用于HAV，因此必须使用传统的V模型之外的其他方法来进行验证。要做到这一点，我们需要至少从一套(可能不完整的)安全要求开始。然后我们必须找到一种方法，将道路测试、封闭过程测试和模拟结果的某些组合追溯到那些安全要求。
根据安全需求进行验证
在最高级别上，我们需要某种类型的系统需求来确定测试是否真正通过或失败。如果功能需求没有被完全阐明，那么我们需要一些其他的东西。好消息是，提供安全性可能不需要最优性能。更简单的要求可能足以防御安全操作。
例如，我们发现基于安全信封的不安全行为列表对于某些自动驾驶车辆行为是足够的。在这种情况下，测试可以追溯到明确声明的安全需求，即使功能需求本身是不透明的或没有文档记录的。指定安全信封的一种方法是使用分配给不同安全检查器功能块的运行时不变量。举个简单的例子，车道保持的安全范围可以是车辆停留在它的车道边界内，加上一些安全系数。这比检查一个复杂算法的完美实现要简单得多，该算法根据道路几何形状和交通状况优化车辆的车道位置。
虽然根据规定的安全要求跟踪测试可能是有帮助的，但我们通过经验发现，人们并不理解安全需求，甚至没有以有用的详细程度记录下来。虽然防止发生车祸的模糊概念是一个起点，但也必须有一个具体的、特殊的方法来确定一个测试是否表明了一个系统是安全的。在实践中，我们发现一组指定安全与不安全的系统状态空间信封组合的部分运行时，不变量可以随着时间的推移在响应测试和仿真结果的持续改进方法中得到演化。换句话说，解决安全需求缺失问题的一种方法是从简单的规则集开始，并随着时间的推移对违反这些简单规则的测试进行详细的说明。假阳性和假阴性的违反规则的行为可以细化规则集。一般来说，如果一开始就对安全操作的信封（增加高假阳性率）有一个较低的近似值，并且在分析表明这样做是增加信封可容性的一种安全方法时，逐步增加额外的信封面积，那么这种演进的效果最好。
如果HAV设计团队试图通过基于机器学习的方法来确定安全需求，那么对他们来说，以一种可被人类安全参数评审员理解的方式来表达结果将是非常重要的。然而，目前还不清楚这将如何实现。在这一点上，我们建议使用更传统的工程方法来防御安全需求，以避免同样的不可思议的问题落在基于MLB的功能上。
基于剩余风险的验证
虽然安全信封方法可以简化创建用于通过/失败标准的需求模型的复杂性，但是HAV测试仍然需要运行大量的场景来获得合理的覆盖率。理想情况下，尽可能多地使用成本较低、低保真度的模拟。该方法不仅要考虑未区分的“现实主义”，而且要考虑减少由低保真度模拟的简化所带来的剩余风险。
剩余风险管理
高保真度和低保真度模拟运行之间的重要关系不应该是完整性检查或统计抽样，而应该是强调在低保真度水平上假设和简化的正确性和有效性。换句话说，对于某一特定级别的可靠性模型在某些方面存在错误的每个方面，高保真度模拟(包括可能的各种类型的物理车辆测试)应该承担起减轻剩余安全验证风险的责任。
这种方法在重要方面不同于通常的模型验证概念。较高的保真度仿真不仅用于验证较低保真度模型的正确性，而且还必须明确地设计来强调对假设和简化的检查，这些假设和简化是在运行仿真时出现的。高保真度模型的一个主要目标应该是通过检查低保真度模拟结果的准确性，以及检查在进行高保真度模拟时，低保真度模型所做的假设是否被违背，从而降低剩余风险。作一个简单的例子，如果一个简化的模型假设80%的雷达脉冲探测到一个目标，如果只有75%的脉冲探测到一个目标，那么高保真度模型或车辆测试应该会出现故障——即使车辆恰好按照高保真度模型安全运行。假设80%的检出率是一个有剩余风险的低保真度模拟。违反这一假设将使安全论证无效，即使特定的测试场景碰巧幸运地避免了事故。
这种方法从根本上影响了模拟和测试的设计。例如，考虑一个模拟，它探索视野中的障碍位置。该模拟以非常精确的分辨率布置环境中的障碍物，但仅使用粗糙的粘胶状物体模拟固定方向的静态行人物体。在不同的障碍物放置情况下，进行数千次额外的高保真度车辆测试，相对于详尽的模拟结果而言，预期将产生较低的边际验证收益，特别是当模拟运行实际的几何处理代码时，这些代码将部署在HAV中。这是因为在这个例子中，障碍物相对于车辆的位置并不是模拟完成后剩余风险的主要来源。主要的剩余风险围绕着行人。低保真模拟假设是假人，因此忽略了携带大型物体的人、穿着会严重扭曲传感器信号的衣服的人、车辆传感器的不同旋转位置等等。
同样地，任何对仿真能力的改进，都不应仅仅是力求使仿真在每个可能的维度上都具有更高的可靠性。例如，将道路障碍的放置建模到纳米级别，而不是毫米级别，不太可能有效地使用模拟资源。相反，仿真保真度的改进应该用仿真代替所需的系统级测试(例如，为前面的简笔画示例添加表面纹理功能以及更广泛的几何形状和方向)。
这并不意味着仿真模型验证和校验应该被忽略。相反，关键是即使在特定抽象级别上的一个完美验证的模型也会留下剩余风险。风险的一部分是由于一个不完整的测试活动的可能性，这等于没有完全减少从低保真模拟继承的风险，或者没有完全覆盖分配给问题保真级别的区域。风险的另一部分是由于在特定抽象级别上有意排除的安全考虑，这对应于向上传递到下一个更高级别的风险。
因此，使用各种模拟保真度的历史悠久的方法仍然对HAV有意义。其关键之处在于确保低保真度测试中的简化被明确地管理，并作为验证风险而减轻。
通过对不同场景的偏置测试来加速评估的方法是对剩余风险方法的补充。强调困难的场景是为了从测试集中筛选冗余的名义路径测试，同时仍然覆盖名义行为、边缘情况和复杂的环境交互作用。另一方面，由于模拟和测试计划的较低可靠性层简化和未经检查的假设，剩余风险降低解决了潜在的风险问题。
剩余风险的例子
表1显示了在HAV测试和模拟计划中应该考虑的剩余风险的简化示例。表格顶部的剩余风险倾向于需求缺口(意外的场景和意外的环境条件)。相比之下，其他剩余风险倾向于在中级水平上由速度/可靠性模拟交易(例如，传感器数据质量)驱动的简化和在最低水平上的潜在设计问题(例如，子系统交互)的组合。
回顾前面的障碍物检测示例，这意味着更高的保真度级别(如物理车辆测试)不应该主要关注不同的大小和障碍物的位置。相反，他们应该专注于物体和传感器上的污垢，以及其他可能无法由纯软件仿真工具处理的方面。换句话说，车辆测试的重点不应该是再现仿真结果，而应该是挑战仿真方法的任何已知弱点。
细节会有所不同。关键是所有的仿真工具都有一些需要进一步验证的限制。
对于表1所示的示例，封闭路线测试不应该关注意外的人类驾驶员行为、退化的基础设施或道路危险，因为减轻这些威胁是进行部署前道路测试的主要原因。应该通过测试和模拟来处理预期的行为、道路危险等。它是无法处理的意外问题，因为根据定义，意外问题不是可以显式包含在测试计划中的东西。
在处理应该在较低级别适当处理的风险时，避免给较高级别的系统测试带来负担是很重要的。继续这个例子，封闭过程测试不应该与正常的车辆动力学、传感器数据质量和执行器影响等普通问题密切相关，因为这些问题可以通过基于软件的仿真来解决。车辆测试也不应该被用于暴力测试障碍的位置和几何形状，可以用更节省成本的方式处理，简化的车辆和环境模拟，只练习车辆的障碍处理代码。在验证仿真能力时，在封闭的赛道上使用真实车辆进行原型测试可能是有意义的。但执行实际车辆仿真保真度的各个方面的测试计划，尽可能减少时间和成本。
总体思想是，每一层验证的主要重点应该是下一层遗留下来的风险，特别是在已修改的系统上重新运行现有的模拟测试套件以确保系统仍然是安全的时候。如果随机抽样不能覆盖剩余的风险，那么大量的重复低保真模拟和测试结果的抽样在最好的情况下是无用的，在最坏的情况下会给人一种错误的安全感。
表1 假设的验证活动和对有效性的威胁
5 提高可观察性
给定一个完整的模拟和基于车辆的测试计划，必须提供可靠的可控性和可观测性，以产生可靠的安全验证结果。
可控性和可观察性
可控性是测试人员控制被测系统执行的初始状态和工作负载的能力。可观察性是测试人员观察系统状态以确定测试是否通过或失败的能力。
控制测试场景以引发特定的自主系统行为是不同的。这是由于使用了随机方法(例如，随机路径规划器)、对初始条件的敏感性(例如，在测试环境中精确地重复传感器校准)、执行器输出的可变性(例如，与执行器的环境交互中的意外变化)和计算时间变化的组合。
提高可控性的一个有用的方法是使用仿真来避免物理世界的随机性和约束。除此之外，还可以提供一个系统测试接口，强制定义系统进入测试的初始状态。例如，如果可以将路径规划器的内部伪随机数生成器设置为预定的种子值，则可以以可重复的方式对其进行测试。作为一个实际问题，确定性测试要求HAV软件被有意地设计成提供确定的测试能力。在软件构建之后，很难减少非决定论的来源。
可观察性可能是一个更复杂的问题。例如，在一个汽车水平的障碍测试中，车辆要么通过一个障碍，要么不通过。但是，即使系统通过了没有碰撞的测试，那也可能仅仅是因为系统幸运地避开了它甚至不知道存在的障碍。系统可能会在下一次测试运行时遇到障碍，或者可能在2000年以后的测试运行中遇到障碍。这种可观察性的缺乏是机器人易读性问题的一个方面，它认识到人类理解机器人系统的设计、操作和意图的多样性(易读性在与人类驾驶员的HAV交互中的额外作用是重要的，但超出了本文的范围)。
虽然有人可能会说，一个系统不太可能靠运气反复通过测试，但是涉及的测试参数的绝对数量会让反复通过的部分变得昂贵。而且，不管运行了多少次测试，都很难通过对生命关键的保证级别的测试来实现极端水平的统计显著性。(即使系统在人行横道上避开被发现的儿童的99.99%的置信水平似乎也有问题，如果它可能导致10000个儿童中有一个被击中的话。)因此，由于幸运而不是由于安全的设计，场景元素的某些组合总是存在重复通过测试的剩余风险。
与其仅仅依靠系统级的行为和蛮力重复来确定一个测试是否通过，更有效的测试方法是将软件测试点插入到系统中来提高可观察性。例如，如果传感器融合的可靠性是由于仿真的局限性而产生的剩余风险，那么封闭航向车辆仿真的一个相关测试点就是监控计算出的传感器融合结果的置信度。这将提供有关测试障碍是否在预期误差范围内被避免的信息，而不是靠运气。软件测试点可能干扰被测系统的问题可以通过将测试点架构为系统的永久部分来解决。这将有助在已部署的系统内收集数据。)
软件测试点还有助于监测安全参数假设违反期间的车队部署。前面讨论的80%检测率假设示例不仅可以在测试期间进行监视，还可以在整个车辆部署期间进行监视，以检测逃逸到扫描系统中的假设违反情况。
通过测试的正确原因
当一个人参加驾驶考试时，考官对驾驶员有一个相当准确(或至少有用)的心理模型。如果驾驶员在换车道时没有与后视镜进行目光接触，或者没有检查目的车道上的车辆，考官就会知道驾驶员在没有碰撞的情况下换车道是幸运的，而不是因为规范操作。对于HAV，这种类型的评估更加困难，因为对于表现出安全行为的机器和表现出不安全行为的幸运机器来说，还不清楚什么是指示。如果需求和设计无法通过基于v的安全流程进行跟踪，则尤其如此。
如果HAV的安全性部分基于驾驶测试类型的事件，那么审查员必须知道HAV不仅行为正确，而且出于正确的原因行为正确。即使没有一个正式的驱动测试，能够从显式的系统信息中合理地推断出行为的因果关系，与蛮力统计方法相比，可以降低测试成本。拥有一个突出的、对象上的边框等HAV自我报告区域并不是一个新想法。然而，如果使用正确的方式，在安全参数中明确包含这些功能可以降低测试成本。这可能激发进一步的工作，以验证自我报告和可解释机制的可靠性。
将场景与行为耦合的一种方法是让HAV自我报告它认为自己所处的场景，或者它认为正在发挥作用的各种场景元素。例如在车辆想变道时，车辆可能会报告:“我想改变车道，我发现目的车道有一辆车,但远远落后于我，我开始改变车道，继续监控车道，我后面的那辆车正在加快缩小差距等等”。一些HAV架构可能已经提供了这种级别的可观察性。问题是验证策略如何正式地使用这些信息。此外，许多流行的方法(例如，端到端深度学习)明确地避开了架构模块化，这往往会降低可观察性。他们这样做的目的是实现更高的性能、更紧凑的实现和更少的开发工作。缺乏可观察性可能会在验证工作或此类系统的部署风险方面造成很高的代价。
一个有效的驾驶考试不仅需要正确的行为，而且需要一个正确的内省的叙述，为什么HAV是这样的行为。答:这是一个好的开始，但我们必须质疑机器对其行为的解释的完整性。然而，我们认为，决定是否相信一个明确的解释比通过行为观察推断(然后相信)一个不透明的隐含解释更容易解决问题。无论哪种方式，都必须决定车辆在与训练和测试数据集不完全匹配的未来环境中是否会做正确的事情。一个明确的解释的优点是，如果需要匹配测试计划的描述，那么该机制的有效性是可以伪造的。在设计安全关键系统时，我们更喜欢显式的、可验证的、简单的模式，与那些高度优化但不透明的模式相比，这些模式的性能可能更差。我们有理由相信，在考虑尝试部署难以验证的系统的后果时，HAV也会出现这种趋势。
为了验证的目的，设计这样一个系统将需要引入或识别可观察性。这可以通过一个工具来实现，该工具可以将现有的数据转换为可人工解释的形式，向系统体系结构添加一个测试点，或者重新设计系统的体系结构来有意地创建新的可人工解释的数据形式(图1)。
对于机器学习系统，这种方法提出了一种有点不寻常的设计策略。与其让ML系统学习它自己的特性集来实现某个结果，不如让它同时满足两个目标:(1)显示正确的行为，(2)显示一组叙述
符合其行为的描述或其他解释。实现此目的的一种方法是使用环境和使用场景的模型来确定必须学习的ML输出集。虽然这可能被视为额外的设计负担和开销，但这可能是了解车辆是否足够安全以进行部署的代价。
为了避免行为和叙述之间的不匹配，一种可能性是安排ML系统，使其在两个互不关联的阶段中运行:首先创建叙述，然后使用叙述作为其行为的输入，如图1所示。第一阶段可能建立在现有工作的基础上，即创建场景的描述和层次分类。系统驱动应通过使第二阶段完全依赖于第一阶段的输出来响应叙述。这种依赖性降低了生成与系统驱动策略不匹配的并行叙事结构的风险。
6 不确定性的应对
已知和未知
即使是经过验证的、表面上没有缺陷的系统，由于对系统及其需求的不完全理解，仍然存在来自问题的剩余风险。这些问题至少包括以下潜在类型的问题:
•在安全性基于隐含独立性假设的区域出现意外的相关故障
•场景和环境的异常很少发生，无法通过部署前的道路测试进行诊断
•被认为极其罕见的未减轻危险的到达率的不确定性
毫无疑问，还有其他类型的缺陷没有在上面列出，也没有包括在至少一些HAV验证计划中。这些都是著名的“未知的未知”，可能危及安全，并导致其他系统故障。
处理未知缺陷
虽然诸如安全信封之类的方法可能有所帮助，但是最终，没有方法能够完全降低来自未知类型缺陷的剩余风险。然而，可以监测意外故障的到来，从而随着时间的推移增加可信度，使剩余风险非常低。必须认识到，未知的问题是一种剩余风险，必须在足部的整个生命周期中进行监测和必要的缓解。一个已经扩展到包含未知的信任评估框架是一种管理剩余风险的方法。
每当一个意外事件导致一个安全问题时，都应该采取额外的步骤来处理由于新发现的问题而失效的底层系统和安全论证假设(这是根据现有的安全实践。重要的是做一个意想不到的故障根源分析至少确定一个问题是一个已知的未知(在这种情况下,现在关于它你知道更多),或者一个未知的未知(在这种情况下,需要添加一个类别的缺陷类型验证计划和安全参数地址这一新的意想不到的问题)。
HAV的成熟性
将驾驶考试作为HAV验证的一部分具有相当大的直观吸引力。然而，将HAV拿出来进行类似于人类驾驶测试的路考的类比并不恰当，因为人类驾驶测试实际上有两个关键要素。第一个要素是显而易见的，公开的要求，司机必须显示基本的驾驶知识和专业能力，包括驾驶技能测试。
通过驾驶考试的第二个更微妙的部分是，司机必须大约16岁，这取决于地区。这个年龄要求可以作为一个代理，代表着拥有合理成熟的判断能力，能够处理异常情况，并在遇到新奇的非结构化情况时通常以合理的方式行事。在现实世界中，正确的车辆操作部分取决于交通法规。然而，这也取决于警察是否熟练，虽然主观上，认为司机的行为是一个合理的和负责任的情况下。(与他人相处融洽是一个重要的性格特点，尤其是在与人交往中。)
虽然有可能(有些人说是肯定的)，考虑到人类的弱点，HAV行为可能比一个人更安全，但如何衡量HAV成熟度，以确保完全达到这一理想结果，仍然是一个有待解决的问题。
度量HAV成熟度的一种方法是部署车辆，并观察它们的表现。这是部署SAE 3级自动化的争论之一，它实际上使用一个人作为成年人的角色，在初学者许可操作期间监视初级驾驶员。然而，有一个合理的担心，由于司机辍学司机监督将是无效，特别是当自动化故障很少的情况下。
我们提出了两种不同的方法来评估HAV成熟度，这超出了开发人员遵循传统安全软件工程原则的范围。第一种方法是确保HAV以正确的理由通过详细的技术驾驶技能测试，第二种方法是观察HAV验证假设和剩余风险观测在实际应用中是否有效。换句话说，如果车辆能够以一种对人有意义的方式解释其行为，并且其安全案例假设在运行中成立，那么系统设计可能被认为是成熟的。
HAV试用：监控假设
任何负责任的HAV部署决策都必须比简单地说“我们修复了所有发现的bug，所以我们必须是完美的”要复杂得多，因为这绝不是对现实的反映，总是有一个额外的bug未被发现。相反，基于阶段性验证的安全论证至少应该基于对每个验证阶段的缺陷转化率的测量。这表明，可观察性测试点应该被保留，并一直监控到车队的部署。这样做可以确保不存在使假设失效的车辆操作情况，从而允许监视系统设计的成熟度。如果运行时监视检测到较高的假设违反率，则可以为安全裕度受损的设计团队提供有价值的反馈。通过这种方式，即使没有发生任何实际的事故，也可以确定安全论证的问题。
除了前面讨论的违反假设的例子之外，还有另一个例子，考虑HAV道路测试的脱离约定报告这个有争议的话题。显然，并不是所有的脱离都是平等的，特别是考虑到不同的团队可能有不同的触发脱离的假阳性率。
使用诸如正交缺陷分类(ODC)这样的方法可能会发现，例如，一些分离是由子系统模拟中应该被捕获的问题引起的，而其他的分离是由于在最高级别上发现了需求或场景缺口。当一个预计,HAV脱离开发团队做一些分析,系统的分析缺陷映射回剩余风险识别验证计划的潜在好处,比如提供一个安全卫生指标参数,HAV的整体成熟度级别。
通过为每个验证阶段提供一组合理的风险缓解目标，该方法可以支持对自动驾驶验证的外部评估。这些可以与在模拟、车辆测试和部署期间由相关的可观测点测量的缺陷转义数据相匹配。所有这些都意味着“驱动程序测试”实际上不是一次性的事件，而是一个持续的“许可证”更新过程，该过程基于收集和分析系统生命周期中缺陷转义的字段数据。
剩余风险的部署
重要的是要承认，这个讨论已经考虑到有剩余风险的HAV，特别是在需求和设计验证方面的潜在差距。这是所部署的领域和技术所固有的。需要一段时间，才能收集到足够的数据，证明剩余风险低于通常的安全临界系统安全阈值(例如，低于每109或1010个操作小时发生一次灾难性的车辆事故)。鉴于目前的HAV市场和监管环境，在收集这些数据之前，公共部署似乎可能会扩大。
不管部署HAV的吸引力如何，以负责任的方式进行部署是至关重要的。尤其不能盲目接受剩余风险。相反，应该明确地理解所有级别的剩余验证风险，并在部署期间进行监视。举个例子，一些可信的观点认为，某一特定类别的剩余风险可能会导致低后果、高存活率或极罕见的灾难，这可能是一个合理的动机，让我们确定这些风险是可以接受的，即使风险的全部范围还不清楚。但是，任何这类论点都应得到监测现场反馈数据的支持，以确定支持接受这类风险的假设实际上是否正确，最好不要等待严重损失事件的累积。
最终会出现伦理问题，比如如果预期可以节省车辆的寿命，那么部署不完善的技术是否更好。安全专业人员特别是面临一个务实的选择,是否参与发布安全性至关重要的系统未知的(和不可知的,在短期内),但安全风险,或者他们错过了一个机会来提高相对安全的HAV,注定要被部署有或没有他们的帮助。本文的目标是提供一个框架，以便在部署这些系统之前对它们进行验证，从而提高开发人员识别和管理可接受风险的能力。
7 总结
综上所述，我们描述了一种HAV验证方法，该方法包括以下元素:
•一种分阶段的模拟和测试方法，强调通过测试来降低前一阶段的验证风险，同时利用测试和模拟中固有的速度和保真度可伸缩性特性。
•可观察性观测点，以产生可被人理解的数据，这些数据既能检测出从较低保真度仿真阶段遗留的缺陷，又能证明系统正在以正确的理由做正确的事情。
•明确区分测试的不同角色，从检查需求缺口到检查设计错误，并将每种类型的测试与阶段性验证方法的相关部分进行匹配。
该方法还可以期望通过将测试的每个阶段集中在减轻从前一阶段继承的风险上来提高测试效率，而不浪费资源来重新访问低风险的结论或试图处理属于其他测试阶段的范围外的风险。(除了测试之外的其他形式的验证也很重要，比如对系统功能的适当部分使用ISO 26262方法。)
我们认识到，由于最终建立机器学习函数的安全性的挑战，这里提出的方法将产生一个不断迭代改进的过程，而不是安全的无懈可击的证明。然而，该方法将有助于强调在哪些地方正在作出假设，以及在哪些地方安全案例证据缺失。验证方法和系统的一种方法是创建一个目标结构化标记组织的安全案例，并包括明确声明的假设来完成论证。每个假设都确定了测试或模拟技术的剩余风险。由其他验证方法验证的假设是安全参数链的一部分。无法在设计时验证的假设是残留风险，对于已部署系统中的运行时监视来说，这些风险尤其重要。
在某种程度上，设计师将不得不决定一个负责任的部署计划，该计划可能涉及到根据一些可辩护的技术和社会标准来判断是否可以接受的风险。为了最大限度地减少未减轻的剩余风险，我们建议避免使用传统安全方法无法验证的自主权
是确保操作安全的唯一手段。一种替代方法是使用安全检查器
可根据ISO26262进行适当的评级，如安全外壳监视器。
虽然确保所有剩余的风险都是已知的并降低可接受的水平总是更好的，但是很明显，即使存在包含未被完全理解的风险的争论，HAV也将被部署。本文讨论的方法为建立一个基于多级仿真和测试保真度的初始安全参数提供了一个框架。它还提供了在测试和部署过程中基于监视假设违背和其他剩余验证风险的持续改进挂钩。
我们接下来的步骤是改进技术，建立从安全需求到测试和模拟计划的可追溯性，并将此方法应用于大规模验证活动。
- 用户评论
