SOTIF:一个高度自动化汽车的安全验证架构(2)

*本文翻译自Juan R.Pimental所著Safety of the Intended Functionality (SOTIF) Book 3 - Automated Vehicle Safety Series，中文版权归轩辕实验室所有
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设计的主要手段，更多的是由设计团队决定的。只要根据充分完整的需求集对设计进行验证，就不需要(实际上也不应该)进行现场测试。
因此，减少HAV验证的时间和费用的一种方法是将(1)在路上的需求收集与(2)设计和实现验证分开。要想找出特殊且危险、需要通过系统安全要求加以缓解的事件，显然没有办法绕过需要数十亿英里的道路经验。但这并不意味着设计验证需要对每一次设计更改重新进行数十亿英里的测试，至少在采用了比蛮力系统级测试更复杂的方法的情况下是如此。
车辆测试以减少剩余风险

我们可以推广这样的概念，即道路测试应该主要强调需求验证，而较低级别的模拟和测试应该强调设计和实现的验证。一般来说，任何级别的模拟(包括车辆测试的模拟方面)都具有前面讨论过的特定级别的可靠性。这意味着它也是错误的，就像所有的模型在某些方面都是错误的，因为它的简化和假设。
提高测试效率的方法是将测试计划集中在各个层次的测试上，检查仿真的低层次的假设和简化。同时，尽可能地将仿真工作推到最低的实际水平，可以降低仿真成本。例如，应该在子系统模拟中发现简单的编码缺陷(或者甚至通过传统的软件单元测试和同行评审进行预模拟)。另一方面，如果它们是由不可预见的因素引起的，那么在路上测试中发现的罕见事件需求缺口可能是最好的。正如下面一节所讨论的，它导致了一种基于降低每个级别的模拟可靠性的剩余风险的方法。
4 一个分层处理剩余风险的方法

由于完整的人类可解释的设计和需求信息在短期内不太可能用于HAV，因此必须使用传统的V模型之外的其他方法来进行验证。要做到这一点，我们需要至少从一套(可能不完整的)安全要求开始。然后我们必须找到一种方法，将道路测试、封闭过程测试和模拟结果的某些组合追溯到那些安全要求。
根据安全需求进行验证

在最高级别上，我们需要某种类型的系统需求来确定测试是否真正通过或失败。如果功能需求没有被完全阐明，那么我们需要一些其他的东西。好消息是，提供安全性可能不需要最优性能。更简单的要求可能足以防御安全操作。
例如，我们发现基于安全信封的不安全行为列表对于某些自动驾驶车辆行为是足够的。在这种情况下，测试可以追溯到明确声明的安全需求，即使功能需求本身是不透明的或没有文档记录的。指定安全信封的一种方法是使用分配给不同安全检查器功能块的运行时不变量。举个简单的例子，车道保持的安全范围可以是车辆停留在它的车道边界内，加上一些安全系数。这比检查一个复杂算法的完美实现要简单得多，该算法根据道路几何形状和交通状况优化车辆的车道位置。
虽然根据规定的安全要求跟踪测试可能是有帮助的，但我们通过经验发现，人们并不理解安全需求，甚至没有以有用的详细程度记录下来。虽然防止发生车祸的模糊概念是一个起点，但也必须有一个具体的、特殊的方法来确定一个测试是否表明了一个系统是安全的。在实践中，我们发现一组指定安全与不安全的系统状态空间信封组合的部分运行时，不变量可以随着时间的推移在响应测试和仿真结果的持续改进方法中得到演化。换句话说，解决安全需求缺失问题的一种方法是从简单的规则集开始，并随着时间的推移对违反这些简单规则的测试进行详细的说明。假阳性和假阴性的违反规则的行为可以细化规则集。一般来说，如果一开始就对安全操作的信封（增加高假阳性率）有一个较低的近似值，并且在分析表明这样做是增加信封可容性的一种安全方法时，逐步增加额外的信封面积，那么这种演进的效果最好。
如果HAV设计团队试图通过基于机器学习的方法来确定安全需求，那么对他们来说，以一种可被人类安全参数评审员理解的方式来表达结果将是非常重要的。然而，目前还不清楚这将如何实现。在这一点上，我们建议使用更传统的工程方法来防御安全需求，以避免同样的不可思议的问题落在基于MLB的功能上。
基于剩余风险的验证

虽然安全信封方法可以简化创建用于通过/失败标准的需求模型的复杂性，但是HAV测试仍然需要运行大量的场景来获得合理的覆盖率。理想情况下，尽可能多地使用成本较低、低保真度的模拟。该方法不仅要考虑未区分的“现实主义”，而且要考虑减少由低保真度模拟的简化所带来的剩余风险。
剩余风险管理

高保真度和低保真度模拟运行之间的重要关系不应该是完整性检查或统计抽样，而应该是强调在低保真度水平上假设和简化的正确性和有效性。换句话说，对于某一特定级别的可靠性模型在某些方面存在错误的每个方面，高保真度模拟(包括可能的各种类型的物理车辆测试)应该承担起减轻剩余安全验证风险的责任。
这种方法在重要方面不同于通常的模型验证概念。较高的保真度仿真不仅用于验证较低保真度模型的正确性，而且还必须明确地设计来强调对假设和简化的检查，这些假设和简化是在运行仿真时出现的。高保真度模型的一个主要目标应该是通过检查低保真度模拟结果的准确性，以及检查在进行高保真度模拟时，低保真度模型所做的假设是否被违背，从而降低剩余风险。作一个简单的例子，如果一个简化的模型假设80%的雷达脉冲探测到一个目标，如果只有75%的脉冲探测到一个目标，那么高保真度模型或车辆测试应该会出现故障——即使车辆恰好按照高保真度模型安全运行。假设80%的检出率是一个有剩余风险的低保真度模拟。违反这一假设将使安全论证无效，即使特定的测试场景碰巧幸运地避免了事故。
这种方法从根本上影响了模拟和测试的设计。例如，考虑一个模拟，它探索视野中的障碍位置。该模拟以非常精确的分辨率布置环境中的障碍物，但仅使用粗糙的粘胶状物体模拟固定方向的静态行人物体。在不同的障碍物放置情况下，进行数千次额外的高保真度车辆测试，相对于详尽的模拟结果而言，预期将产生较低的边际验证收益，特别是当模拟运行实际的几何处理代码时，这些代码将部署在HAV中。这是因为在这个例子中，障碍物相对于车辆的位置并不是模拟完成后剩余风险的主要来源。主要的剩余风险围绕着行人。低保真模拟假设是假人，因此忽略了携带大型物体的人、穿着会严重扭曲传感器信号的衣服的人、车辆传感器的不同旋转位置等等。
同样地，任何对仿真能力的改进，都不应仅仅是力求使仿真在每个可能的维度上都具有更高的可靠性。例如，将道路障碍的放置建模到纳米级别，而不是毫米级别，不太可能有效地使用模拟资源。相反，仿真保真度的改进应该用仿真代替所需的系统级测试(例如，为前面的简笔画示例添加表面纹理功能以及更广泛的几何形状和方向)。
这并不意味着仿真模型验证和校验应该被忽略。相反，关键是即使在特定抽象级别上的一个完美验证的模型也会留下剩余风险。风险的一部分是由于一个不完整的测试活动的可能性，这等于没有完全减少从低保真模拟继承的风险，或者没有完全覆盖分配给问题保真级别的区域。风险的另一部分是由于在特定抽象级别上有意排除的安全考虑，这对应于向上传递到下一个更高级别的风险。
因此，使用各种模拟保真度的历史悠久的方法仍然对HAV有意义。其关键之处在于确保低保真度测试中的简化被明确地管理，并作为验证风险而减轻。
通过对不同场景的偏置测试来加速评估的方法是对剩余风险方法的补充。强调困难的场景是为了从测试集中筛选冗余的名义路径测试，同时仍然覆盖名义行为、边缘情况和复杂的环境交互作用。另一方面，由于模拟和测试计划的较低可靠性层简化和未经检查的假设，剩余风险降低解决了潜在的风险问题。
剩余风险的例子

表1显示了在HAV测试和模拟计划中应该考虑的剩余风险的简化示例。表格顶部的剩余风险倾向于需求缺口(意外的场景和意外的环境条件)。相比之下，其他剩余风险倾向于在中级水平上由速度/可靠性模拟交易(例如，传感器数据质量)驱动的简化和在最低水平上的潜在设计问题(例如，子系统交互)的组合。
回顾前面的障碍物检测示例，这意味着更高的保真度级别(如物理车辆测试)不应该主要关注不同的大小和障碍物的位置。相反，他们应该专注于物体和传感器上的污垢，以及其他可能无法由纯软件仿真工具处理的方面。换句话说，车辆测试的重点不应该是再现仿真结果，而应该是挑战仿真方法的任何已知弱点。细节会有所不同。关键是所有的仿真工具都有一些需要进一步验证的限制。
对于表1所示的示例，封闭路线测试不应该关注意外的人类驾驶员行为、退化的基础设施或道路危险，因为减轻这些威胁是进行部署前道路测试的主要原因。应该通过测试和模拟来处理预期的行为、道路危险等。它是无法处理的意外问题，因为根据定义，意外问题不是可以显式包含在测试计划中的东西。
在处理应该在较低级别适当处理的风险时，避免给较高级别的系统测试带来负担是很重要的。继续这个例子，封闭过程测试不应该与正常的车辆动力学、传感器数据质量和执行器影响等普通问题密切相关，因为这些问题可以通过基于软件的仿真来解决。车辆测试也不应该被用于暴力测试障碍的位置和几何形状，可以用更节省成本的方式处理，简化的车辆和环境模拟，只练习车辆的障碍处理代码。在验证仿真能力时，在封闭的赛道上使用真实车辆进行原型测试可能是有意义的。但执行实际车辆仿真保真度的各个方面的测试计划，尽可能减少时间和成本。
总体思想是，每一层验证的主要重点应该是下一层遗留下来的风险，特别是在已修改的系统上重新运行现有的模拟测试套件以确保系统仍然是安全的时候。如果随机抽样不能覆盖剩余的风险，那么大量的重复低保真模拟和测试结果的抽样在最好的情况下是无用的，在最坏的情况下会给人一种错误的安全感。

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