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

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

摘要

一般来说软件测试常常只是寻找bug，而不是通过精密的实验来保证产品质量。一个相比简单的系统级的测试，即测试—失败—补丁（改进）—测试更好的方法已经开始大规模部署在无人驾驶汽车上。ISO26262的v模型建立了一个框架，该框架将每种类型的测试与相应的设计或需求文档联系起来，但该模式在处理自动驾驶汽车面临的各种新测试问题时会遇到挑战。本文根据自主车辆的V模型确定了测试中的五个主要挑战领域:驾驶员不在环、复杂需求、非确定性算法、归纳学习算法和故障操作系统。

有希望在这些不同的挑战领域中实现的通用解决方案包括:使用逐步减少约束的操作场景进行分阶段部署，使用观测器/执行器架构把复杂的自动驾驶功能从相对简单的安全功能分离出来，采用故障注入来执行更多的的边缘案例测试。尽管为高等级的自动驾驶算法提供安全认证安全仍然存在重大的挑战，但似乎可以采用现有的软件安全方法来构建系统和与其相对应的设计过程。

引言

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

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

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

在本文中，我们将探讨一些正在等待开发人员解决的挑战，这些开发人员正试图开发完全自主的L4级别车辆并进行大规模部署。因此，我们跳过了过去可能采用的半自动化方法，即在这种情形下，司机根本不用负责操作车辆。对研究对象我们进行了进一步限制了范围，只考虑在ISO26262v框架内设计和验证的车辆。采取这种限制的原因是这是一种可接受的确保安全的框架。

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

完全测试的不可行性

人们早就知道不可能彻底地测试系统以确保系统的可靠性（冗余）。例如，假设有一个100万辆汽车的车队每天运行一个小时。如果安全目标是这个车队每1000天发生一次灾难性的计算故障，即每次发生灾难性故障之间的平均时间应该为10亿小时，这与飞机的允许故障率相当。

为了验证发生灾难性事故的频率，最少得进行长达十亿小时的测试，更有甚者也可能是几倍的时间，重复多次测试可以达到统计学意义。但即使这样，这也是假定测试环境是基于真实世界部署的，具有高度代表性的并且导致错误的环境部署以随机的、独立的方式出现。

但是，建造一个足够大的、能够在具有代表性的测试环境中运行数十亿小时而又不会危及公众的车队是不切实际的。因此，我们需要替代的验证方法，可能包括模拟仿真、故障注入、面向不断增加的车队规模的自适应、在非极端工况中获得组件的实际工作状况以及人工评审等方法。（组件级的测试也发挥了作用，但是为物理硬件设备积累十亿小时的部署前测试仍然是不切实际的)

考虑到自主系统的测试比日常软件系统的测试更困难，这会让事情会变得更糟。

对于相对非关键的计算系统来说，可以将测试作为确认其安全级别的主要依据。这是因为低严重程度和低暴露性的故障相比灾难性故障更容易发生。例如，如果每1000小时发生一次特定类型的故障是可以接受的(因为这种故障会导致最低成本的事故或轻微的中断)，那么通过数千小时的测试，就可以可靠地验证该故障的故障率。这并不是说对这些系统而言，所有的（必要）保证软件质量的步骤可以放着不管了，而是一个合适的测试和故障监控策略可能能够验证一个事实，即如果平均故障间隔时间要求相对宽松的话，一个质量合适的组件确实已经被确认为拥有一个可以接受的低故障率。

作为起点的V模型

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

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

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

驾驶员不在环

在全自动驾驶汽车中，最明显的挑战可能就是司机不再真正驾驶汽车。这意味着，根据定义，不能再指望司机在运行过程中为车辆提供控制输入。

可控性挑战

对于低完整性设备来说，典型的汽车安全可能取决于驾驶员的控制能力。例如，在一个高级驱动辅助系统(ADAS)中，如果一个软件故障导致一个潜在的危险情况，司机可能会被期望越过软件功能直接将车辆恢复到安全状态。司机有时候也被希望能把汽车从严重的机械故障中恢复过来，比如轮胎爆裂等问题。换句话说，在人类驾驶的汽车中，司机会负责采取正确的纠正措施。但在现在这种情况下，司机没有能力采取纠正措施，也就是说车辆缺乏可控性，因此必须设计更高的汽车安全完整性水平，或汽车安全完整性等级。

一款完全自动化驾驶的汽车不指望司机处理特殊情况。当故障发生时和出现超出指定的操作条件能处理的情况时，计算机系统必须被指定为故障的处理者。与ADAS系统相比，让计算机负责异常处理会显著增加自动化的复杂性。组合的ADAS系统技术如车道保持和智能巡航控制，似乎非常接近全自动操作，然而，完全自动驾驶的车辆必须处理所有可能出现的问题，它具有更高的复杂性。因为，现在确实已经没有接管方向盘和踩刹车的司机了。

自主架构方法

在ISO2626262环境下的自主体系结构方法中，让计算机负责管理需要以下两种评估风险的策略之一。

一种策略是将风险评估的可控性部分设置为C3，即难以控制或无法控制。如果严重程度和暴露度很低，这可能是一个可行的选择。但是，在严重程度中等或高的情况下，系统必须设计成更高的汽车安全完整性水平(汽车安全完整性等级)。(有人可能会认为应该有更高的可控性分类C4，因为自动化系统有可能采取主动的危险行动，而不是简单地不能提供安全功能。)但我们假设现有的C3就足够了。

另一种处理潜在的汽车高安全完整性等级自主功能的方法是使用分解，具体方法要接着观测器/执行器架构和冗余的组合。观测/执行器架构是指主要功能为：一个模块(执行器)负责执行，而另一个模块(监视器)执行验收测试或其他行为验证。如果执行器行为不当，观测器会关闭整个功能(两个模块)，从而形成一个故障静默系统。

如果观测器/执行器对(图2)设计正确，那么只要观测器有足够高的汽车安全完整性等级并检测所有可能的故障，执行器就可以设计成低汽车安全完整性等级。(还要求检测观测器中的潜在故障，以避免损坏的观测器未能检测到驱动器故障的问题。)如果可以使观测器比执行器简单得多，则可以减少观测器的规模，并允许将大部分复杂功能放置到较低的汽车安全完整性等级执行器中，这种体系结构模式是相当有利。

观测器/执行器对的优点和缺点都是它创建了一个故障静默构建块(如果有错误，它就会关闭)。异构冗余的使用，即观测器和执行器的使用是为了防止由于执行器故障而发出危险的命令。
至少，提供故障操作行为需要更多的冗余(即多个观测/执行器对)，并且需要满足多样性，从而使同一模式的软件设计故障不会造成整个系统故障。这对于避免出现Arianne5航班501的丢失这样的情况是很重要的，这是由于主系统和备份系统都出现了相同的未处理异常操作条件而导致的故障。

应该指出的是，因为例如实现不同的组件时有脆弱性等问题，实现多样性并不一定是简单的，对于非自主软件也是如此。还需要注意的是，故障/执行器对的故障沉默需求是基于故障独立性的假设。
一个关键的点是无论采用什么方法，总需要有一种方法来检测当自主功能不正常工作的状态(无论是由于硬件故障、软件故障，还是需求缺陷)，并以某种方式把系统转移到一个安全的状态。

复杂的需求

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

需求挑战

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

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

操作概念的方法

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

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

道路可达:限制到达的高速公路，共乘车道，农村道路、郊区，封闭校园，城市街道，等。
可见性:白天，晚上，雾，霾、吸烟，雨，雪
车载环境:在一个封闭的车库内没有其他车辆移动，仅允许自动驾驶的车道，非自动驾驶车辆上的标记应答器等。
外部环境:基础设施的支持，预先规划的道路，由人驾驶的汽车
速度:较低的速度可能产生更小的故障后果和更大的恢复空间
虽然上述自由度仍然有很多组合(当然还有更多的组合是不可想象的)，但是从可能的操作概念中进行选择的目的不是增加复杂性，而是减少复杂性。减少需求的复杂性可以通过在特定的情况下应用自主系统来实现，在这些情况下的需求应该是完全被理解的(并确保对这些有效的操作条件的识别是正确的)

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

安全需求和约束条件

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

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

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

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

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

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

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

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

非确定性和统计算法

自动驾驶车辆使用的一些技术本质上是统计的。一般来说，它们往往是不确定的(不可重复的)，并且可能只在一个概率可以被分配的情况下给出基于概率正确的答案。验证这样的系统会带来一些挑战，这些挑战通常不会出现在更确定的、传统的汽车控制系统中

随机系统的挑战

随机系统非确定性计算的挑战包括一些算法，如规划算法，它们可能通过对许多随机选择的候选者的结果进行排名来工作。由于该算法的核心操作是基于随机生成，因此很难进行复制。虽然在单元测试中使用可重复的伪随机数流等技术可能有帮助，但是在集成系统中创建完全确定的行为可能是不现实的，尤其是当初始条件的微小变化导致系统行为的发散状态时。这意味着，尽管尝试使用名义上相同的测试用例，但每一辆车测试都可能导致不同的结果。

成功的感知算法也往往是概率的。例如，证据网格框架(evidence grid framework)将来自单个、不确定的传感器读数的扩散累积，使得机器人对周围环境越来越能建立一个更加详细的地图。这种方法产生一个对象存在的可能性，但是时候不能完全保证的。此外，这些算法基于先前的传感器物理模型(如多路径返回)和噪声模型本身就是概率性的，对环境条件的微小变化敏感。

除了对环境的几何建模之外，其他算法还从感知到的数据中提取标签。其中突出的例子包括行人检测。这样的系统即使在无噪声数据的情况下，也可能出现潜在的不可预测的故障模式。例如，视觉系统可能难以消除由于阴影而产生的颜色变化，而且在大型反射表面的存在中，视觉系统很难确定物体的位置。(公平地说，这些对人类来说都是挑战。)此外，任何分类过程都显示了假阴性和假阳性之间的权衡，其中一个的数量越少，另一个的数量就越多。测试的含义是这样的算法不会在百分之百的时间内有效，而且根据构造的不同，它们可能会报告一个特定的情况是真实的，而这个情况实际是真实的可能性只是中等。

测试中的非决定论

处理测试中的非决定论很困难至少有两个原因。

第一个是很难实施特定的边缘情况。这是因为，只有当系统接收到来自世界的非常特定的输入序列时，系统才可能以激活边缘情况的方式运行。由于前面讨论过的一些因素，例如计时器对输入的微小变化的响应可能存在显著差异，因此很难设计出一种情况，在这种情况下，环境可靠地提供适当的条件来运行特定所需的测试用例。作为一个简单的例子，车辆可能更喜欢在宽阔的道路上行驶更迂回的路线，而不是在一条狭窄的巷子里走捷径。为了评估在狭窄的巷道中导航的性能，测试人员需要设计一种使宽阔的巷道对计划者没有吸引力的情况。但是，这样做需要对测试计划给予额外的成本，并且可能(手动地)将车辆移动到它通常不会进入的情况以强制执行所需的响应。

测试中不确定性的第二个困难是很难评估测试结果是否正确，因为对于一个给定的测试用例来说，没有唯一的正确系统行为。因此，正确性标准可能必须采用与前面讨论的安全信封类似的形式，如果最终系统状态在可接受的测试通行信封内，则测试通过。一般情况下可能需要多个测试来建立信任。
概率系统行为对验证提出了类似的挑战，因为通过一次测试并不意味着每次都能通过测试。事实上，有了概率行为我们可能会认为至少某些类型的测试会在一定程度上失败。因此，测试可能不是为了确定行为是否正确，而是为了验证行为的统计特征是否被精确地指定(例如，假阴性检出率不大于相关安全参数中假定的检出率)。比起简单的功能验证，这可能需要更多的测试，特别是如果问题中的行为是关键的安全部分且在预期中会有极低的失败率。

从概率系统中获得极高的性能可能需要多个子系统在发生完全独立的故障时有低的失败率。例如，可以将复合雷达和视觉系统结合起来，以确保在极低的概率范围内没有遗漏的障碍物。这种方法不仅适用于传感模式，而且也适用于规划和执行中的其他各种算法方案。如果这样的方法是成功的，那么很有可能失败的概率非常低，以至于测试验证复合性能几乎是不可行的。例如，如果两个系统必须每十亿次检测就会遗漏一次障碍，那么必须运行数十亿次有代表性的测试来验证这种性能。为了验证复合不同算法的低故障率，可以尝试分别验证每种算法更频繁的允许故障率。但这是不够的。我们还必须验证失败之间独立的假设，这很可能必须基于分析和测试才能进行。

机器学习系统

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

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

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

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

验证归纳学习的挑战

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

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

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

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

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

归纳学习的解决方案

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

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

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

关键任务的操作需求

现在让我们回到先前讨论过的地方，即计算机最终控制着车辆，而不是控制着人。这意味着至少部分车辆必须是基于故障操作而不是面对故障停止。

故障操作系统设计的挑战

故障操作系统设计已经在航空航天和其他环境中成功地完成了几十年，但是由于以下几个原因仍然是困难的。第一个原因是显而易见的，即必须提供冗余，以便当一个组件失败时，另一个组件可以接管。实现这一点需要至少两个独立的、冗余的故障停止行为子系统。

实现故障操作系统反过来需要至少三个冗余的故障任意组件，以便在发出不正确的输出而不是在组件级别发出静默失败的情况下确定故障源。对于必须容忍任意错误故障的系统，根据相关的故障模型，可能需要一个具有4个冗余组件的复杂容错系统。

冗余的结构变化取决于设计方法，和可能包括配置如三冗余系统成员(在这种情况下，成员必须确保不被一个单点故障)，或两个二对二系统，或者使用四台电脑。这些方法除了引入的明显开销之外，还存在一个测试问题，即如何确保故障检测和恢复工作的有效性，确保故障的独立性，并确保在驱动任务开始时所有冗余组件都是无故障的。冗余似乎不太可能被避免，但为了确保安全，可能会降低提供足够冗余的复杂性和成本

在典型的故障操作系统(如飞机)中，所有冗余部件本质上都是相同的，它都能够执行扩展任务。例如，商用飞机通常配置两个喷气发动机，每个喷气发动机至少有一个双冗余计算机控制。如果一台发动机上的两台计算机由于持续的交叉检测故障而关闭，那么就会有第二个独立的引擎来维持飞机的飞行。即便如此，对引擎可靠性的要求还是非常严格的，因为在第一个引擎故障后，飞机可能需要飞行几个小时才能到达最近的机场。这就对每个引擎提出了显著的可靠性要求，从而增加了组件成本。

虽然汽车是出了名的价格敏感的，但它们也有一个优势，即故障转移任务的时间可以很短(例如，把车停在路边，或者在必要时停在一条旅游线路上)，故障转移任务的持续时间是以秒而不是小时为单位度量的。此外，用于停止车辆的故障转移任务可能比完全自主操作的功能要少得多。这可以简化需求复杂性、计算冗余、传感器需求和验证需求。(作为一个简单的例子，故障转移任务控制系统可能不支持变道，这极大地简化了传感器需求和控制算法)因此，设计一个具有故障停止主控制器和更简单的故障操作故障转移控制器的自动车辆可能在硬件成本和设计/验证成本方面都具有吸引力。

它也可能不是基于完全的自主系统，而是就是完全的自主系统，在完全的自主系统中有一个检测器.这将使故障探测器本身拥有高水平，但可能允许正常的自主功能为低汽车安全完整性等级。这种方法可以很好地映射到主自主系统的监视/执行器体系结构。故障转移的自主性也必须以安全的方式设计，并根据其复杂性和计算的可靠性需求采用适当的体系结构方法。如果仅持续几秒钟的短暂故障转移任务中发生故障的可能性足够低，那么甚至可以使用单通道故障转移系统。

非技术性因素

在部署自动驾驶时遇到的一些挑战是非技术性的，例如经常提到的责任问题(当发生事故时谁负责赔偿?)以及法律通常如何对待所有权、操作、维护和其他方面的车辆的问题。深入研究这个问题显然超出了本文的范围。然而，对非技术挑战的决议很可能对技术解决方案产生影响。例如，对事故重建数据的自主系统可能有法律要求，需要对这些数据的来源进行仔细的分析，以确保正确使用这些数据。举个简单的例子，假设雷达探测概率为95%，那么它的输出可能仍然会被记录在系统中，以判断是否检测到障碍物，表面上这意味着探测的确定性。

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

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

故障注入

从前面的讨论中可以明显看出，传统的功能测试在面对一个完整的系统时会遇到困难，尤其是在不寻常的操作条件下，很难去执行异常的组合。虽然测试人员可以定义一些非名义上的测试用例，但由于异常、操作场景和其他相关因素的组合爆炸，该测试的可扩展性存在问题。

此外，研究还表明，即使是非常优秀的设计人员，在相对简单的软件系统中，也经常会出现盲点和错过异常情况。

故障注入和鲁棒性测试是在异常情况下评估系统性能的较为成熟的技术，在测试异常情况响应时可以避免设计人员和测试人员的盲点。传统的故障注入包括将位翻转插入到内存和通信网络中。最近的技术增加了抽象的层次，包括基于数据类型的故障字典，并确保了故障的代表性。这些技术已经被成功地用于自动驾驶汽车的缺陷的发现和特征。

这是一种很有希望帮助验证自主性的方法，它在组件的抽象级别执行故障注入，作为试图伪造安全性声明的策略的一部分。这不仅涉及到对主要传感器输入的对象进行模拟，还涉及到插入异常条件以测试系统的健壮性(例如，在映射中插入无效数据)。执行此类故障注入的目的不是验证功能，而是通过探查不可预见的情况激活弱点。这种故障注入也可以ISO 26262过程中跨层执行。

结论

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

分阶段部署

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

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

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

需要特别注意的受限操作概念的一个方面是，需要确保在操作场景突然失效时维护安全性，例如，由于意外的天气事件或基础设施故障引起的操作场景失效。当系统偏移在允许的自主操作场景之外时，异常转换机制需要成功地执行系统恢复或故障转移任务，

目前尚不清楚的是，分阶段部署方法是否为实现自主驾驶提供一条完整的道路。但是，这样的方法至少提供了一种方法来取得进展，而且带来了一些好处，与此同时因为系统看到了更多的现实世界的情况。这种方法帮我们对困难的边界情况和未预料到的情况有更多的了解。

监控/执行机构

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

故障注入

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

未来工作

本文讨论了如何在基于ISO 26262的V框架内实现自动车辆安全的保障。但是，事实上使用架构模式(如监视/执行器方法)和通过故障注入进行验证将限制操作性能。换句话说，我们可能需要通过收束自动驾驶汽车的功能，以适应当下的测试技术的限制。如果想放宽这些限制，需要在以下方面取得进展：描述与预期操作环境相符的机器学习训练数据的覆盖范围，对基于异常驾驶条件的安全需求有信心，以及能够验证带有冗余的归纳系统中故障的独立性。

本文作者： 鲨鱼观海
本文链接： http://iamwxy.com/自动驾驶测试与验证的挑战.html
版权声明： 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 3.0 许可协议。转载请注明出处！