作者:陈云培

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

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

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

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

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

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

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

完全测试的不可行性

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

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

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

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

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

作为起点的V模型

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

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

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

驾驶员不在环

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

可控性挑战

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

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

自主架构方法

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

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

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

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

观测器/执行器对的优点和缺点都是它创建了一个故障静默构建块(如果有错误，它就会关闭)。异构冗余的使用，即观测器和执行器的使用是为了防止由于执行器故障而发出危险的命令。

至少，提供故障操作行为需要更多的冗余(即多个观测/执行器对)，并且需要满足多样性，从而使同一模式的软件设计故障不会造成整个系统故障。这对于避免出现Arianne5航班的丢失这样的情况是很重要的，这是由于主系统和备份系统都出现了相同的未处理异常操作条件而导致的故障。

应该指出的是，因为例如实现不同的组件时有脆弱性等问题，实现多样性并不一定是简单的，对于非自主软件也是如此。还需要注意的是，故障/执行器对的故障沉默需求是基于故障独立性的假设。

一个关键的点是无论采用什么方法，总需要有一种方法来检测当自主功能不正常工作的状态(无论是由于硬件故障、软件故障，还是需求缺陷)，并以某种方式把系统转移到一个安全的状态。

复杂的需求

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

需求挑战

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

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

操作概念的方法

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

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

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

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

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

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

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

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

安全需求和约束条件

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

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

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

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

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

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

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

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

非确定性和统计算法

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

随机系统的挑战

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

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

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

测试中的非决定论

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

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

测试中不确定性的第二个困难是很难评估测试结果是否正确，因为对于一个给定的测试用例来说，没有唯一的正确系统行为。因此，正确性标准可能必须采用与前面讨论的安全信封类似的形式，如果最终系统状态在可接受的测试通行信封内，则测试通过。一般情况下可能需要多个测试来建立信任。

概率系统行为对验证提出了类似的挑战，因为通过一次测试并不意味着每次都能通过测试。事实上，有了概率行为我们可能会认为至少某些类型的测试会在一定程度上失败。因此，测试可能不是为了确定行为是否正确，而是为了验证行为的统计特征是否被精确地指定(例如，假阴性检出率不大于相关安全参数中假定的检出率)。比起简单的功能验证，这可能需要更多的测试，特别是如果问题中的行为是关键的安全部分且在预期中会有极低的失败率。

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

机器学习系统

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

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

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

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

验证归纳学习的挑战

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

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

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

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

由于机器学习系统的易读性一般较差，而且由于过度拟合的危险是真实存在的，因此在这样的系统中存在着严重影响安全性的失效模式。特别值得

转载请注明:http://www.aideyishus.com/lkgx/4718.html