?自动驾驶测试与验证的挑战

一篇关于自动驾驶测试的文献翻译。

引 言

最近自动驾驶汽车成为一个热门话题，不过实际上它们背后的技术已经发展了几十年了，最早可追溯到自动化公路系统项目。从这些早期的示范算起，自动驾驶技术已经发展了成熟的驾驶员辅助系统(ADAS)。像自动车道保持和智能巡航控制也已经是许多车辆的标准了。除此之外，现在还有许多处于不同的发展阶段的不同级别的自动驾驶车辆项目。

如果有人相信所谓专家的话，那么无人驾驶汽车好像呼之欲出。但事实上，搞传统汽车行业的都知道，在拥有专业的安全驾驶人员的情况下，制造几辆车以在合理且有利的条件下运行，与在不受约束的世界里运行数百万辆车之间，有着巨大的鸿沟。

有人会说，（自动驾驶汽车）成功的示范和几千公里(甚至几十万公里)的成功驾驶里程意味着自动驾驶技术基本上已经做好全面部署的准备。但是，很难仅仅从这样的测试就能得出这足以确保安全性的结论。实际上，至少有一些开发人员已经在做更多相关的测试工作，但问题是还需要做多少工作，以及我们如何才能知道现在的车辆已经足够安全到可以上路了呢p>

完全基于计算机的系统应该是不安全的，这是一个可以确认的，除非你有令人信服的相反论点来论证。总之，自动驾驶汽车不能被认为是安全的，除非它们能被显示符合或可以被映射到ISO26262或其他一些合适的、被广泛接受的软件安全标准。

作为起点的V模型

因为系统级测试不能完成上述工作，我们需要更多相关测试，这正是创建更健壮的安全软件的开发框架的意义所在。V软件开发模型长期以来一直适用于汽车。它是20多年前纳入MISRA指导方针的发展参考模型之一。最近，它被推广为构成ISO26262基础的参考模型。

通常，V模型表示一个有条理的创建过程和验证过程。V的左侧包括从需求到设计再到实现的过程。在每个步骤中，系统被划分为并行处理的典型的子系统（例如，有一组系统需求，但是每个子系统都有单独的设计)。V的右侧迭代地验证和验证越来越大的系统，它是从小的组件过渡到到系统级的评估的一个过程。虽然ISO2626262对这个模型进行了详细的阐述，但是我们这里保留一些通用的框架，以方便讨论拓展。

尽管ISO 26262和它的V框架已经明朗了在确保汽车安全方面的公认做法，但在将全自动车辆的技术映射到V方法这方面依然有很多挑战。

复杂的需求

V开发模型的一个基本特征是，V的右侧提供了一种可追溯的方式来检查左侧的结果(验证和验证)。但是，这种检查的概念是基于一个假设，即需求实际上是已知的，正确的、完整的、明确指定的。这种假设给自动驾驶汽车带来了挑战。

需求挑战

如前所述，从控制系统中去掉司机意味着软件必须能处理异常，包括天气、环境危害和设备故障。会有很多不同类型的故障，从恶劣天气(洪水、雾、雪、烟，龙卷风)，违反交通规则(错误的方向公路上一个汽车，其他司机闯红灯，被偷走的交通标志),到当地驾驶约定（靠左行驶），动物危害(蝗灾、鹿、犰狳)。

任何一个开了足够长时间车的人，都会有自己的故事，他们会讲述他们在路上看到过的怪异事件。总的来说，车辆数目多的话很可能会经历所有这类事件，甚至更多。更糟糕的是，恶性事件和驾驶条件的组合可能会出现，而在经典的书面需求规范中，这些组合实在是太多了。如果这些组合的结果可能是无害的，那么可能不需要涵盖所有这种极其罕见的组合，但是需求应该清楚地知道什么是系统设计范围内的要处理的故障，什么不是。因此，以列举所有系统需求的文档为起点的经典V进程似乎不太可能以狭义的方式扩展到自动车辆异常处理系统上，至少在不久的将来会一直是这样。

操作概念的方法

管理需求的复杂性的一种方法是约束操作概念并进行需求的分阶段扩展。这已经由开发人员完成了，他们可能会在特定的地理区域集中进行道路测试（例如，仅在硅谷的高速公路上进行白天的驾驶，因为那里的降水有限，天气寒冷)。采用约束概念的想法可以从多个维度扩展

典型的可以利用限制操作概念轴（维度）包括:

• 道路可达:限制到达的高速公路，共乘车道，农村道路、郊区，封闭校园，城市街道，等；

• 可见性:白天，晚上，雾，霾、吸烟，雨，雪；

• 车载环境:在一个封闭的车库内没有其他车辆移动，仅允许自动驾驶的车道，非自动驾驶车辆上的标记应答器等；

• 外部环境:基础设施的支持，预先规划的道路，由人驾驶的汽车；

• 速度:较低的速度可能产生更小的故障后果和更大的恢复空间。

虽然上述自由度仍然有很多组合(当然还有更多的组合是不可想象的)，但是从可能的操作概念中进行选择的目的不是增加复杂性，而是减少复杂性。减少需求的复杂性可以通过在特定的情况下应用自主系统来实现，在这些情况下的需求应该是完全被理解的(并确保对这些有效的操作条件的识别是正确的)。

因此，限制操作概念成为一种引导策略，用于在逐渐复杂的操作中部署更复杂的技术能力。一旦确定对某一特定业务概念的需求有了充分的了解，就会有更多类似的需求。随着时间的推移，可以添加操作概念来扩展允许的自动化场景的范围。但这并不能完全消除复杂需求的问题，但是它可以帮助减轻组合爆炸的需求和例外情况

安全需求和约束条件

即使使用了受限的操作概念，使用传统的与安全相关的需求方法似乎也是不切实际的。这种方法或多或少是按以下这种方式进行的：首先创建功能需求。在执行了一些风险评估过程后，对安全性相关的需求进行评注(annotation)。将这些与安全相关的需求分配给安全关键子系统。设计安全关键子系统以满足分配的需求。最后，通过重复循环来找到并减少不在预期内的紧急子系统表现。

对安全关键需求进行评注对于自主应用程序来说可能不切实际，这里至少有两个原因。

一个原因是，许多需求可能只与部分安全相关，并且与功能性能密不可分。例如，当汽车行驶时，使用停车制动的许多条件可能是一组初始(基础)需求。然而这些需求的某些方面实际上是安全的关键，而这些方面在很大程度上是受其他交互功能的紧急影响。考虑停车制动的情况，停车制动很可能被许多功能需求所描述。但是让我们来简化问题，在减速模式中唯一安全的关键操作可能是在其他需求的紧急交互下必须避免在减速过程中锁住车轮。

用于识别安全相关需求的需求注释可能失败的第二个原因是，在使用机器学习技术时是不可能进行评注的。这是因为需求采用了一组训练数据的形式，这些数据列举了一组输入值和正确的系统输出。这些通常不是传统需求的形式，因此需要对需求管理和验证采用不同的方法。

与其试图在安全性和非安全性子系统之间分配功能需求，不如创建一组严格与安全性相关的独立的、并行的需求集。这些需求的形式往往是约束条件，它们指定了安全所需的系统状态。这种方法可以解决性能和优化问题(最短路径是什么最优燃料消耗的速度是多少安全的角度来看(我们会撞上什么东西吗/h5>

使用这种方法可以将需求集划分为V模型的两个部分。第一组的需求将是一组非安全相关的功能需求，这可能是传统的格式或一种非传统的格式如机器学习训练集。

第二组需求将是一组纯粹的安全需求，它们完全明确地定义了安全对于系统的意义，相对独立于最优系统行为的细节。这种需求可以采取安全操作信封的形式，适用于不同的操作模式，系统可以自由地在操作信封内优化其性能。显然，这样的信封至少可以在某些情况下使用(例如，执行速度限制或设置最小的跟随距离。这个概念是相当笼统的，但也说明这可能是未来的工作。

采用一组与功能需求正交的安全需求的一个令人信服的理由是，这种方法可以清晰地映射到观测/执行器体系结构上。功能需求可以分配给低汽车安全完整性等级执行器功能块，而安全需求可以分配给高汽车安全完整性等级监视器。这个想法作为监视器/执行器设计模式的一部分已经被非正式地使用多年了。我们建议将这种方法提升为一种主要的策略，用于设计自动车辆的设计、需求和安全案例，而不是降级为一种详细的实现冗余策略。

机器学习系统

只有在正确地做出一系列复杂的感知和控制决策的情况下，自动驾驶汽车才有可能采取正确的行为。要实现这一目标，通常需要对参数进行适当的调整，包括从每个相机镜头的校准模型，到为避免高速公路上的障碍而转向或停车的风险的适当加权。这里的挑战是找到校准模型或权重的比值，从而使某些误差函数最小化。近年来，大多数机器人应用都转向机器学习来实现这一点，因为多维优化的复杂性使得手工工作不太可能产生理想的性能水平。

机器学习方法的细节有很多，例如，有监督学习、强化学习等，但总之所有这些方法都涉及归纳学习，在归纳学习中，训练集被用来推导一个模型。

例如，考虑在单目图像中检测行人的情况。使用一组大型图像训练集，分类器可以学习一种决策规则，该规则将行人在一组单独的图像验证集中被检测到的概率降至最低。为了我们的目的，一个基本要素是训练集实际上是系统的需求集合，而规则是系统设计的结果。(机器学习算法本身和分类器算法都比传统的验证技术更容易修改。然而，这些都是通用的软件引擎，最终的系统行为是由用于学习的训练数据决定的。)

可以尝试通过创建一组训练数据的需求来回避训练集数据形成实际需求的问题。但这最终只是将同样的挑战推到了一个抽象层次上。需求不应是典型V系统本身的一组功能需求，而是以一组训练数据或收集训练数据集的计划的形式

验证归纳学习的挑战

归纳学习方法的性能可以通过从收集的总体数据集中保留一些样本并使用这些样本进行验证来测试。假设有以下这种情况，如果把训练集作为系统需求(V的左边)看，可以用一组独立的验证数据来确保满足测试的需求(V的右边)。训练数据不能有意外的相关性与所需的行为，否则系统将过拟合。类似地，验证数据必须独立于训练数据，并且在除所需的特性之外的所有方面都与训练数据不同，否则在验证过程中会检测到过拟合。当然目前尚不清楚如何论证机器学习系统没有产生过拟合。

机器学习在实践中的一个重要限制是，如果使用带标签的数据，每个数据点都可能很昂贵。(创建标签必须由某人或某物来完成。无监督学习技术也是可能的，但需要一个巧妙的映射来解决特定的问题。此外，如果训练集有问题或所学习的规则有问题，那么就需要收集更多的验证数据并用于验证更新的系统。这是必要的，因为即使对训练数据做一个小的更改，也会产生一个完全不同的学习规则集。

由于自主系统的需求非常复杂，很可能会出现一些罕见的边缘案例，在那里学习将会发生问题。然而，由于它们的稀缺性，收集描述这种不寻常情况的数据可能是昂贵的，而且很难衡量。(模拟和合成数据可以帮助解决这一问题，但在模拟数据中存在偏差的风险，以及对仿真工件的过度拟合。)

验证机器学习的另一个问题是，一般来说，人类不能直观地理解过程。例如，卷积神经 络的内部结构可能不能让人类观察者更直观地了解已经学会的决策规则。虽然可能有一些特殊的情况，但一般来说，机器学习的易读性问题即能够用人类的术语解释系统的行为这个问题还没有解决办法。这使得除了昂贵的蛮力测试之外很难预测的技术如何应用于机器学习系统的验证。(也许有些组织确实有资源进行广泛的蛮力测试。但即使在这种情况下，训练数据的准确性、有效性和代表性也必须被证明为是安全论证的一部分。)

由于机器学习系统的易读性一般较差，而且由于过度拟合的危险是真实存在的，因此在这样的系统中存在着严重影响安全性的失效模式。特别值得关注的是在训练集数据中出现的偶然相关性，但人类往往注意不到这种相关性。例如，考虑使用经过训练的可变形部件模型来检测图像中的行人的方法，这在现实世界的数据集中已被证明是相当有效的。如果训练数据集中没有(或很少)行人坐轮椅的图像，那么这样的系统很可能会将行人的标签与用两条腿走路的人错误地联系起来。

归纳学习的解决方案

归纳学习怎么进行测试是很困难的。首先是黑天鹅问题，故事是这样的，在18世纪末之前，在欧洲观察到的所有的天鹅都是白色的，因此一个使用归纳逻辑的观察者会得出结论，所有的天鹅都是白色的。然而，这名观察者在访问澳大利亚时，会经历这种信念的挑战，因为那里有大量的黑天鹅。换句话说，如果系统没有看到一个特殊的情况，它就不能学习这个情况。这是对归纳学习方法的一个基本限制。此外，由于机器学习严重缺乏易读性，人类审查员很难或不可能想象在这样一个系统中出现类似黑天鹅的偏差。

验证一个归纳学习系统似乎是一个极具挑战性的问题。我们可能会使用广泛的测试，但需要保证黑天鹅数据随机独立到达率的假设，并对相应大小的数据集进行测试。如果有足够的资源，这可能是可行的，但是总会有新的黑天鹅，所以需要对大量的操作场景和输入值进行概率评估，以确保系统故障的低水平。

另一种验证归纳学习系统到高汽车安全完整性等级水平的方法是将一种基于归纳的低汽车安全完整性等级算法配对，该算法将命令发送给执行器，并使用基于高汽车安全完整性等级演绎的监视器。这将回避驱动算法的大部分验证问题，因为控制执行器的诱导算法的失败将被基于演绎生成的安全信封等概念的非感应监视器捕获。因此，执行器算法失败将是一个可用性问题(假定有足够的故障转移能力，系统安全关闭)，而不是安全问题。

非技术性因素

重要的是要确保法分析考虑到，仅仅因为雷达没有探测到行人，并不意味着行人不在那里(例如95%检测可能意味着每20个行人中就有一个不会被检测到)。

看起来，由于自动车辆的固有复杂性，以及无法通过测试证明完备性，开发人员必须以保证案例的形式创建安全保证参数。这样的保证论证对于维护和解释系统的完整性是必要的，并且它能够可靠地解释系统对不可避免的危险情况的反应。确保证据的完整性是应该解决的一个特殊问题，因为借此可确定由于发生特殊情况而造成的事故是否是不可避免的。其他需要关注的重要的问题是，事故是否由系统需求的缺陷、合理可预见和可避免的设计缺陷、实施的缺陷或其他原因引起的。

结 论

根据V过程开发的安全自主车辆会遇到很多大挑战。但是为了确保车辆是安全的，仍然需要遵循ISO26262v流程，或者证明一套同样严格的流程和技术实践。假设应用了V过程，有一下三种看起来比较有意义的方法。

分阶段部署

在不受限制的真实环境中(包括特殊情况)，开发和部署一辆自动驾驶汽车来处理所有可能的场景组合似乎是不切实际的。当下正如在汽车系统中常见的那样，基于当前开发人员实践的分阶段部署方法似乎是一种更为合理的方法。

可以将分阶段部署绑定到V流程，通过指定良好的操作概念来限制操作范围，从而限制必要的需求范围。这会包括环境、系统和操作约束的限制，这些限制必须用于满足于实现自主操作。验证这些操作约束是否被执行是确保安全性的重要部分，在V过程中它必须显示为一组包括操作需求、验证和潜在运行时的机制。

例如，在运行时监控不仅需要监控系统状态是否允许自主授权，而且需要假设关于安全的操作场景参数实际上是否满足，以及操作场景的系统实际上是否认为它是被满足的。

需要特别注意的受限操作概念的一个方面是，需要确保在操作场景突然失效时维护安全性，例如，由于意外的天气事件或基础设施故障引起的操作场景失效。当系统偏移在允许的自主操作场景之外时，异常转换机制需要成功地执行系统恢复或故障转移任务，目前尚不清楚的是，分阶段部署方法是否为实现自主驾驶提供一条完整的道路。但是，这样的方法至少提供了一种方法来取得进展，而且带来了一些好处，与此同时因为系统看到了更多的现实世界的情况。这种方法帮我们对困难的边界情况和未预料到的情况有更多的了解。

监控/执行机构

使用监控/执行机构架构是一种常见的方法，可以帮助减轻自动车辆安全的许多挑战。正如所讨论的，这种架构风格能满足很高的复杂性需求(只有监视器本质上是完美的)，并部署归纳算法(通过限制对执行器的使用，并使用基于演绎的监视器)。此外，使用故障转移任务策略可以允许自主系统监视器检测主系统故障，而不必确保故障操作行为。更简单、高度完整性的故障转移自主系统可以使车辆到达安全状态。这样的系统可能具有足够短的故障转移任务，只要能够确保在启动故障转移任务时整个系统是无故障的，就可以使故障转移操作的冗余最小化。

故障注入

为了确保系统的可靠性，单独的故障注入测试是不可行的。自动驾驶汽车增加了这一问题的复杂困难性，因为自动驾驶汽车能自动对高度复杂的环境做出反应，并引入诸如机器学习等难以测试和测试费用高昂的技术。因此由于缺乏人驾驶监督，自动驾驶系统必须有一个很高的汽车安全完整性等级。制作普通的系统测试，似乎很难获得对合理的水平的保证。故障注入可以作为验证策略的一部分发挥相当的作用，验证策略包括传统的测试和非测试验证。特别是当故障注入应用于多个抽象级别，而不仅仅是在电气连接器的层面上时，这一点就显得尤为重要。

未来工作

文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览34803 人正在系统学习中